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有多好多快也没什么作用。