大文档首屏渲染方案思考
一、服务端渲染
- 优点：服务端性能比较好，对移动端手机作用明显
- 缺点：大文档渲染完可能体积比较大，网络传输占时间比之前多，sheet还是得回到前端渲染，得维护一套node代码，增加成本
二、分片滑动加载渲染
- 优点：由于只渲染到首屏和预加载一到两屏的文档，速度炒鸡快，理论上不会有边界，可以渲染任意大小的文档
- 缺点：需要解决未加载完全复制全文的bug，拉滚动条可能卡顿（参考Sheet插入Doc性能后续优化点文中说的拉动卡顿问题 ），CMD + F 无法全文搜索，需要自己开发全文搜索的功能。需要修改Changeset计算的一些逻辑。
三、多线程分片拼接渲染
- 方案：利用webworker多线程，主线程将文档分为几个块，分发给worker，worker将这些块输出为字符串，最后拼接输出
- 优点：可以将主线程让给sheet并行渲染，渲染速度应该会快，不存在二中缺点
- 缺点：理论上还是存在边界，超级大的文档，还是渲染时间会有天花板
周日简单开发了一下方案三
将580行约2w6千字的文档，clientVars分为三块，分发给三个worker计算成html字符串。渲染的核心代码并没有加入插件模块，只简单输出字符串。
方案 render字符串出来的时间/ms
优化前: 380
方案三: 1200
尴尬的事情发生了，一顿操作猛于虎，一看战绩零杠五，竟然是负优化。。。。
难受之余，分析了一下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的渲染可能有一些作用，可以把主线程让给sheet渲染。