基于 Webassembly 的一些问题

255 天前
 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:性能衰减问题,大概是多少体量,自我感觉能效不高,怕迁移完毕卡成狗。
3419 次点击
所在节点    程序员
52 条回复
F7TsdQL45E0jmoiG
255 天前
这...图啥啊
seanwhy
255 天前
@morenacl 只能说客户端被浏览器蚕食的太厉害了
duiying
255 天前
搞个简单版本运营看看咯
tool2d
255 天前
emscripten 对很多库支持并不好,比如 curl 就不太好编译。

wasm 只适合中等偏小的软件,运行巨型商业软件够呛,代码估计要大改。
seanwhy
255 天前
@tool2d curl 我编出来.a 了,gdal 也编出来了,但之前公司用的 opengl ,要改 opengles ,因此目前还跑不起来,所以趁机问问。
gam2046
255 天前
性能损耗应该是比较严重的,ffmpeg 是一个计算密集型的应用,wasm 版本的 ffmpeg 在转码方面,有时候只有 10%的速度。
tool2d
255 天前
@seanwhy 那你比较厉害,正常来说 curl 用的是标准 socket ,这在 wasm 浏览器里,都是不被支持的。

我以前遇到的最大问题,是内存管理方面。emscripten 粘合层,用了一种很奇怪的方法处理 fopen/fwrite ,文件大于 2 百兆就有问题,反正很折腾。
nieyujiang
255 天前
4g 内存这个目前无解.我司的程序目前也是身受其害.
w4ngzhen
255 天前
“只能说客户端被浏览器蚕食的太厉害了” 还是没有 Get 到真正的原因,公司是希望以后这块的软件都通过浏览器作为媒介来使用,因为它随时可用,方便快捷,不用下客户端?但假设你真正编译为了 wasm ,大小并不比原生应用小。当然,我只是作为旁观者提出的疑问😂。
johnhsm2333
255 天前
我们这边做 Web 视频编辑器的,也是大量使用 wasm 场景,感觉这里问题提的挺好的。
johnhsm2333
255 天前
w4ngzhen
255 天前
另外对于产品设计方面,看到贵司的软件是 C++三维软件,我假设是一款生产力软件,作为用户,我用客户端在 PC 上使用,明显比在浏览器上使用更加放心😂。
johnhsm2333
255 天前
@johnhsm2333 #11
1. wasm 体积不能太大,会影响网页首屏时间,这个要压缩到 10 到 20m 左右,然后利用客户端缓存。所以不建议是所有功能都打包进来,只包括 js 或浏览器接口无法使用的功能会好一些。
2.确实有
3.验证挺麻烦的,我们也是限制了浏览器版本,比如 safari 无法访问,chrome 和 edge 特定版本以上之类的;
4.项目劣化会挺明显,而且前端同学不懂 wasm 的话,很难优化,所以我们已经把很多功能都使用 js 实现一遍了,这样效果最好。
icyalala
255 天前
对于通用计算来说,性能可以认为是降低到 1/3~1/5 ; simd/gpu 加速的部分性能下降就更多了,至少降一个量级。
cat
255 天前
你司的三维软件是不是卖不出去??搞这幺蛾子
horizon
255 天前
你 wasm 打包压缩了吗,压缩完还 100 多 M ?
mightybruce
255 天前
https://mp.weixin.qq.com/s/1XmH55nqs7wavsWJNT-tSw
B 站 有 ffmpeg 编译成 wasm 的案例, 并有相关 git 地址
mightybruce
255 天前
wasm 其实是非常有用的, 服务器计算挪动到客户端计算,大大减轻了服务端的压力和资源消耗。
thinkershare
255 天前
基本要大改,完全重写。
seanwhy
255 天前
@gam2046 那一般情况呢,
@johnhsm2333 1.大小问题可以通过进度条规避,毕竟大型软件,对加载时间可以有一定的宽容; 4.软件设计基本无需外部前端参与,完全由内部 C++暴露接口供外部调用,前端只需要做界面美化和接口调用的事,可以理解为我们提供了一个二次开发的 sdk

这是一个专为移动设备优化的页面(即为了让你能够在 Google 搜索结果里秒开这个页面),如果你希望参与 V2EX 社区的讨论,你可以继续到 V2EX 上打开本讨论主题的完整版本。

https://www.v2ex.com/t/1022609

V2EX 是创意工作者们的社区,是一个分享自己正在做的有趣事物、交流想法,可以遇见新朋友甚至新机会的地方。

V2EX is a community of developers, designers and creative people.

© 2021 V2EX