大文档首屏渲染方案的一些思考和尝试最近在处理一些优化方面的东西， 大文档渲染的优化方案。 这里简单记录分享一下。一、服务端渲染优点：服务端性能比较好，对移动端手机作用明显缺点：大文档渲染完可能体积比较大，网络传输占时间比之前多，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的渲染可能有一些作用，可以把主线程让给表格渲染。