Web3D Porting – Emscripten VS FlasCC

前段時間有在搞一些C++到Web3D化相關的一些東西，最近也看到了emscripten，拋開成熟度等級的話不說，單就技術來說也是挺不錯的。其實現方法實際上跟FlasCC差不多，這裡對其作一簡單的對比總結。

1. 流程與環境配置

Emscripten的主要流程為：

• C/C++ -> LLVM -> Emscripten -> JavaScript/HTML

其編譯環境配置相對來說較為簡單，可以見這裡有比較詳細的介紹。本人蔘考在VS裡邊配置了一下但是沒有成功，不過不使用VS的話倒也沒什麼影響，簡單寫一個bat也可以完成編譯的流程。

FlasCC的主要流程為：

• C/C++ -> GCC -> LLVM -> FlasCC -> .abc -> SWF

FlasCC的編譯環境相對來說就比較高了，其它的如java，python等都不說了，除此外主要就是需要Cygwin的環境（這空間很可觀，跟NDK環境配置有得一拼）；還有一點就是FlasCC的64位環境要求，否則32位下的記憶體搞不定，囧。。。

整體來說FlasCC要求的編譯環境比Emscripten要高不少。

2. 編譯效率與效能

• 記憶體佔用：

Emscripten在編譯過程中並無太多的記憶體消耗；FlasCC編譯過程中出現上G記憶體佔用情況很常見（要不人要64位系統幹嘛呢。。）

• 編譯時間：

相對來說Emscripten編譯過程要比FlasCC快不少，經過對幾個工程的編譯實驗發現，Emscripten能比FlasCC編譯要快上兩三倍甚至更多。

3. 移植中的問題將傳統的C++程式向Web移植的過程中主要有這幾個問題需要特別考慮：

• Third-party libs

如果C/C++工程中使用了第三方的庫，那這個沒有辦法，必須要有這些庫的原始碼或來編譯或者有使用對應工程鏈編譯好的可連結檔案，否則無論Emscripten或FlasCC都無能為力；

• File System

由於安全性的原因，web系統對於檔案的處理採用的策略也較為特殊。這一點上，兩者的處理方式也不太相同。Emscripten中有兩種處理檔案系統的方法（這裡），一種是直接將要使用的檔案以preload的方法在編譯時間嵌入，這樣會產生一個跟html對應的.data檔案在檔案操作時直接使用，不過它用增加html的載入時間；另外一種方法就是把檔案放到伺服器上以http的形式傳輸過來使用；FlasCC中則統一Virtual
File System的方式實現，即使是本地的檔案其同樣會以一種類比的http方式載入到當前web應用端使用。在編譯過程中，FlasCC全使用sdk中一個genfs的工具把使用到的檔案進行VFS的預先處理操作（比如壓縮等，或檔案太大還會被分割），然後這些個資訊會產生到一個manifest.as檔案中並在產生swf時告訴如何來遠程負載檔案。相對來說，這一塊來說FlasCC裡邊的方式做得更好一些。

• Rendering API

如果是3D圖形渲染相關的工程來移植的話那麼渲染API也是一個很需要考慮的問題。Emscriptn使用WebGL來實現渲染，因而在原始C/C++工程中，只要渲染相關操作使用的是WebGL（或OGLes）相關的介面，直接轉都沒有問題；FlasCC轉換為swf之後對3D渲染的支援使用的是Stage3D，因而渲染介面需要進行一層再封裝，別外，還在就是其它語言格式的Shader也同樣需要轉換到Stage3D的Agal格式，這個過程的工作量也比較大。

這裡通過對之前的一個OGL工程進行了移植測試，emscripten可以很快搞定，但是FlasCC嘛。。。

當然，Emscripten和FlasCC從移植操作性的角度上來說各有優劣，但是單純對它們做對比可能並不太合適，畢竟兩個相當於Web3D化的不同方向：一個基於JS的WebGL，一個是運行於Flash player上的swf。如果在項目的需求中把移植的方向給確定，比如目標就只要flash，那麼這時不管emscripten有多好多快也沒什麼作用。