最近在迁移公司 C/S 架构程序（ C++、三维软件），想往浏览器端迁移，目前正在施行的方案是用 emscripten 编译的 webassembly 模块。
公司程序用了大量的三方库比如：gdal 、ffmpeg 、opengles ，三方库又依赖了大量其他的库，比如 gdal 依赖了 geos 、proj 、curl 、libtiff 、sqlite3 等。因此编译采用的是静态链接，即所有.a 最终生成的是一个.wasm 文件。
我这里基本用了最新的版本，以防对 webassembly 缺乏支持。
那么问题来了：
问题 1：基于如此巨量的三方库以及自有实现代码，这个 wasm 文件会很巨大（百兆体量），浏览器能加载的出来吗，或者此种体量是否规范？
问题 2：据说 webassembly 使用内存上限有限制，大概 4GB ，有方法能突破限制吗？我司程序就是个吃内存的家伙
问题 3：如此多的三方库，是要一个个验证能否在浏览器上运行测试用例吗？还是说只要经过 emscripten 编译过，就基本认定在浏览器端运行基本没有问题？
问题 4：性能衰减问题，大概是多少体量，自我感觉能效不高，怕迁移完毕卡成狗。
公司程序用了大量的三方库比如：gdal 、ffmpeg 、opengles ，三方库又依赖了大量其他的库，比如 gdal 依赖了 geos 、proj 、curl 、libtiff 、sqlite3 等。因此编译采用的是静态链接，即所有.a 最终生成的是一个.wasm 文件。
我这里基本用了最新的版本，以防对 webassembly 缺乏支持。
那么问题来了：
问题 1：基于如此巨量的三方库以及自有实现代码，这个 wasm 文件会很巨大（百兆体量），浏览器能加载的出来吗，或者此种体量是否规范？
问题 2：据说 webassembly 使用内存上限有限制，大概 4GB ，有方法能突破限制吗？我司程序就是个吃内存的家伙
问题 3：如此多的三方库，是要一个个验证能否在浏览器上运行测试用例吗？还是说只要经过 emscripten 编译过，就基本认定在浏览器端运行基本没有问题？
问题 4：性能衰减问题，大概是多少体量，自我感觉能效不高，怕迁移完毕卡成狗。
1
Select Language