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

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

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

一、服务端渲染

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

二、分片滑动加载渲染

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

三、多线程分片拼接渲染

• 方案：利用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的渲染可能有一些作用，可以把主线程让给表格渲染。