基于 Webassembly 的一些问题

[seanwhy]

最近在迁移公司 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：性能衰减问题，大概是多少体量，自我感觉能效不高，怕迁移完毕卡成狗。

[seanwhy]

@sunzhuo 已有 webgl 产品线，我们这个属于 C++原生线，得弄些突破成果

[seanwhy]

@mahaoqu 好消息的三方库用的多，但方法用的又不多，纯属贪图其中某几个 API ，那感觉还有点戏

[seanwhy]

@kaiserzhang123 大佬细说，编译时加上什么标识呢

[seanwhy]

@guanzhangzhang 只要你的库有 configure 或者 cmake ，编出来应该不难啊

[seanwhy]

@gam2046 多线程这块用的是 C++标准库，实际内部调用走的还是 pthread ，初步实验感觉没什么问题

[seanwhy]

@churchill 已针对性剔除 OpenGL ，改用 OpenGLES 友好子集，应该问题不大

[jimrok]

感觉你要改设计，全部搬进 wasm 会崩溃的。建议 web 的版本先做简单的尝试，剥离最主要的功能，极简设计，看看效果。很多计算是不是可以用后端服务实现，这样不需要移植到浏览器上。

[seanwhy]

@opengg Google earth 网页版？

[jeesk]

wasm 很多实现，有点扯，比如网络请求转移成 fetch ， 太恶心了， 拿证书都拿不到，

[dode]

可以搞客户端，纯跑程序，客户端额外开一个 HTTP 服务，浏览器提供界面啊

[money1991]

我司也是搞客户端办公软件的，我把上千万行 c++代码编译到 wasm 了，并且也跑起来了。这块你也可以参考下 photoshop 或 libreoffice 的 wasm 版本，代码量都是这个级别的。
1. 先说体积，编译完大约 100M 左右，用 br 最高级压缩完 20M 左右，这个大小其实以目前网速不算大，配合缓存基本也仅影响首次。
2. 首次初始化稍慢，出去下载的时间，chrome 还会把它编译到一个二进制缓存，后续启动会非常快。
3. 性能我个人感觉能接受，但我司项目不依赖 opengl ，不算是强计算密集型项目，感觉应该有原生 50%左右的性能。
目前项目没有在搞了。。。老板觉得可能时机还有点早，有点遗憾。