当通用优化已完成，我们应该做什么？---飞书文档移动端优化实践_UTF_8

邵鑫

背景去年下半年业务高速迭代，大量新 feature 上线，但同时带来的问题是首屏耗时数据日渐上涨，同学们纷纷表示"移动端文档打开越来越慢，太影响工作效率了"。于是去年年底我做了下优化：视频 1视频 2线上用户数据：可见，无论是用户体验还是指标数据都有了明显的优化。是不是我有神秘的魔法？并没有，甚至可以说魔法已经用完了。为什么这么说呢？我们先看飞书文档移动端(以下简称为 Doc )的现状：1.业界公认有效的通用优化基本已经完成。在大部分场景都可以实现：JS 加载/JS 解析/请求数据耗时为 0仅渲染前 50 行2.业务复杂。经历了4年迭代的大型前端项目，历史问题多。3.文档应用的业务特点导致优化困难。文档应用内容由用户自定义，因此影响打开性能的因素非常多，如长度、内容、设备性能、网络情况、用户使用习惯等等。第一条和第三条叠加特别致命，意味着只能根据文档应用的特点做优化，而且这样的针对性优化还存在困难且没有现成的经验，那么优化项的效果难以衡量。此外还有一个难题：不能做大型技术改造，原因是 PC 与移动端存在代码复用，改造成本过高，人力上不允许。那么摆在我面前的任务便是：在不影响质量的前提下，用尽可能少的代码量优化性能。那么工作的重点是：寻找优化项与安全地做优化。怎么找有效的优化项？做性能优化时，找优化项才是最难的，解决问题反而比较简单。前置步骤：我该优化哪里？在找优化前，我们首先要知道自己要优化什么。而上手业务最快的方式是画图：如图为 Doc 的打开流程：那可以哪一个流程是可以被优化的呢？在回答这个问题前，我们先看看前人为 Doc 做了什么优化。我们在前面说过，大多数场景下， Doc 可以做到：JS 加载/JS 解析/请求数据耗时为 0；仅渲染前 50 行。因此优化空间相对较大的节点只有如下图绿框所示中的一小块，而且这一小块也已存在大量优化。还记得上面说的吗？我的人力只允许我做较小的优化，那么问题就转换为：小优化怎么找？怎么判断小优化的收益？我们下面开始介绍如何解决这两个问题。科学分析我司对外的主要印象是：数据推动决策。那么，可以让数据驱动性能优化吗？这肯定可以的。比如，某天我突然想到一个 idea：“文档内容非常丰富，针对内容进行优化？”，但是怎么验证这个想法是否靠谱呢？首先是找数据，通过 Tea (Toutiao Event Analyze) ，我找到了文档打开耗时与各因素的关系：文档大小，block 类型，用户设备性能变化，缓存预加载比例，Webview 预加载比例等等。但问题也来了：茫茫数据的海洋里，能猜想出无数的优化点，哪个优化点是有效的？可以分成两步：分析一下试一试分析一下面对茫茫数据海洋，我选择两个符合直觉的线索进行分析：文档长度"打开 PV 的文档长度分布"与"不同长度文档的打开耗时"可以看出：大文档(大于 300 行) 在打开 PV 占比小于 10%(左图绿色)；大文档打开速度比较慢，可能是个优化点。(右图浅蓝色曲线，约 600ms)。分析收益如果大文档耗时可以优化掉 500ms，这样大盘数据的平均耗时可降低 50ms(500ms*10%)，看起来变化并不太明显。而且这个目标几乎是不可能的，因为由图中数据可以看出，降低 500ms 意味着耗时比中小文档还要小。结论优化大文档成本高，而且耗时优化少，ROI 低。文档内容Doc 有很多 block，比如 Table，@人名，Sheet，文件卡片，图片等等。这些 block 也会影响首屏性能。遗憾的是，由于设计埋点时缺少考虑，我们没法直观地通过 TEA 分析各类型 block 对首屏耗时的影响。我们换个角度，收集数据：通过 performance 工具分析发现，Table 比其他 block 渲染耗时长很多；此外在 TEA 中发现 Table 在打开 pv 中的渗透率是 30%，与其他 block 的渗透率相比较高；经验上 Doc 常用于会议中，会议文档 Table 通常较多。虽然无法完全确定优化效果，但分析下来是一个非常值得尝试的点。那就来到了下一步：试一试我花了点时间进行优化，将 Table 在首屏的渲染耗时降为原来 50%，上线后观察大盘数据：大盘前端平均耗时下降了 100ms。因此说明：优化渗透率超过 30% 的 block 是个比较有效的点。那么类似的 block 有哪些呢？@人名：35%+Sheet：40%+图片：70%+这样后续的优化计划便可以开始制定了，而且优化效果可预测，项目风险低。数据挖掘通过上述章节的方法能解决大多数用户的问题，但 Doc 作为一个 toB 应用，P99 用户的性能也是我们关注的重点，我们需要更细粒度的分析方法来解决这部分用户的问题，我们应该怎么做呢？我们先举个例子，在文档这一场景，我们凭经验可以推断出：高端手机理论上可以秒开任意文档小文档在大多数手机中可实现秒开那如果有一批线上用户的打开耗时违反了上面的经验呢？新的优化点!但这里有两个问题：怎么找到这部分用户怎么分析这用户问题通过 TEA 我们能找到可以筛选出"使用高端手机且打开文档耗时较长"的用户 id。而分析问题，则需要使用日志。日志首先，怎么记录日志呢？追查首屏性能至少需要以下信息：记录渲染各阶段耗时，比如 Doc 会记录以下信息：调用 render -> 开始获取数据开始获取数据 -> 获取数据完毕获取数据完毕 -> 开始渲染开始渲染 -> 渲染结束辅助排查的信息，比如：文档各 block 数量文档行数文档字数注意：不能在日志中收集用户隐私，文档内容，作者信息等都是信息红线。分析问题大多数情况下都可以通过复现来解决：制作一篇与日志内描述的内容差不多的文档;bytest (内部云真机平台) 上找一台性能差不多的手机打开该文档。大多数情况下都可以找到问题，前提是需要：对打开链路有影响的业务了如指掌熟悉打开过程的 performance trace/日志内容可能有人会问：为什么不直接请求用户协助？如前面所说，日志收集的信息非常有限，而且通过日志定位用户是违规的。那么，通过上面两种方法就能搞定优化了？还有更追求极致的方法吗？聚沙成塔思考一个灵魂问题：10ms 的优化有没有意义？下图是 Doc 打开流程的的 performance trace，火焰图最下方非常细碎(