大文档首屏渲染的一些思考和尝试

大文档首屏渲染方案的一些思考和尝试

最近在处理一些优化方面的东西， 大文档渲染的优化方案。 这里简单记录分享一下。

1、服务端渲染

• 优势：服务端性能比较好，对移动端手机做用明显
• 缺点：大文档渲染完可能体积比较大，网络传输占时间比以前多，sheet仍是得回到前端渲染，得维护一套node代码，增长成本

2、分片滑动加载渲染

• 优势：因为只渲染到首屏和预加载一到两屏的文档，速度炒鸡快，理论上不会有边界，能够渲染任意大小的文档
• 缺点：须要解决未加载彻底复制全文的bug，拉滚动条可能卡顿（参考Sheet插入Doc性能后续优化点文中说的拉动卡顿问题 ），CMD + F 没法全文搜索，须要本身开发全文搜索的功能。须要修改Changeset计算的一些逻辑。

3、多线程分片拼接渲染

• 方案：利用webworker多线程，主线程将文档分为几个块，分发给worker，worker将这些块输出为字符串，最后拼接输出
• 优势：能够将主线程让给sheet并行渲染，渲染速度应该会快，不存在二中缺点
• 缺点：理论上仍是存在边界，超级大的文档，仍是渲染时间会有天花板
• 我决定周末试一波

周日简单开发了一下方案三

将580行约2w6千字的文档，clientVars分为三块，分发给三个worker计算成html字符串。

渲染的核心代码并无加入插件模块，只简单输出字符串。

方案 render字符串出来的时间为 ms

优化前: 380 ms

方案三处理以后: 1200ms...

尴尬的事情发生了，一顿操做猛于虎，一看战绩零杠五，居然是负优化。。。。

难受之余，分析了一下1200ms时间的构成，发现从main thread到worker之间postMessage的时间是整个负优化的来源，多达900ms到1000ms。

看了worker的资料:

https://developers.google.com...

用Transferable Objects能大大提升postMessage的性能。

再试了一波，能把整个时间提高到780ms，仍然有400ms在的时间能够优化。为毛官方的 demo postMessage如此之快，我本身试的这么慢呢？

缘由是个人worker的js至关的复杂，体积很大，每一个worker启动的时候都须要去编译这些js，因此致使了这个负优化的产生。理论上咱们能够将各个plugin拆分为只render和其余的业务逻辑，能大大减小worker js的包体积。若是在包体积很差缩减的状况下，也能够采用预先初始化worker的方式来减小这个时间。这个方法能够在web容器化的方案里面使用.

后续

在文档1100多行（约4w字）的时候，全文渲染的时间达到520ms，而此时多线程渲染依然保持在220ms左右.

结论

对于超大的文档，多线程提高的结果是显著的，而小一些的文档500行左右，意义不大。对于Doc插sheet的渲染可能有一些做用，能够把主线程让给表格渲染。