淘宝页面首帧优化的经验和心得_AI阅读总结 — 包阅AI

最近做了一些移动端页面的首帧优化的工作，有很多心得和感受，其中有很多共性的东西，总结成一篇文章希望可以帮助到更多业务，也希望引起读者一起讨论。

作为程序匠人，一直在努力追求做一款好的产品，打磨各个细节，做好用户体验，而首帧是用户接触到产品的第一个页面，是体验的重中之重。也正因是产品的第一个页面，转化率接近100%，从ROI的角度来说，做好首帧优化也是一个很划算的deal。

做好首帧优化，至少可以带来以下好处：

1. 建立用户好感度：良好的第一印象，提升品牌形象

2. 提升业务转化率：提升业务曝光率、点击率、带来更好的业务结果

3. 更小的资源消耗、减少成本：更长的首帧启动时间意味着更多的资源消耗，更多的成本投入。优化首帧可以减少一些不必要的资源开销和损耗，节省技术成本。

首帧口径和衡量标准

▐口径

做优化前我们需要先想想，用户对首帧体验预期是怎样的？首帧定义是什么，起始范围是什么。不同的口径会影响我们的指标，设计方案，工作量。定义了口径之后，我们可以确定优化事项范围以及边界。

Loading图：

即开始出现loading、展现灰底图或是页面框架图，如果这页面展示也比较久的话，则说明用户交互出现卡顿、假死，迟迟没收到反馈，用户交互被阻塞，属于严重影响用户体验的行为。所以建议在展示骨架图之前，除了framework以外，不要有io、网络等耗时的前置依赖，也不需要有中转页的行为逻辑。

内容主体呈现：

即页面大部分的内容已经渲染出来，用户可以得到足够的信息，这是一个比较符合用户体感的口径，大多数业务选取的就是这个口径。不过不同业务对于“大部分”，“主体”的定义有所不同，业务可以结合自身需求进行合理选择：

页面可交互：

这个阶段表示页面已经完全渲染完成，并且用户可以进一步交互，如点赞、分享、收藏、加购等行为。

▐衡量标准

绝对耗时：

指定口径下的绝对耗时时长，单位一般是ms，多是用于单机线下的验证和比较，不同机型之间、不同场景下的差异较大，如高端机与低端机之间的差别可以相差好几倍，如要反应样本的整体性，多用分位值或者秒开率来衡量。

分位值/秒开率：

取值标准：

▐了解现状

首先要掌握自身产品以及行业竞品的首帧数据，了解在行业中的一个排名情况，再决策是否要进一步做优化，做到什么样的程度。为了保证自身和竞品采用的同一种口径获取首帧耗时，我们这边采用了录屏的方式。

录屏分析方案：在同一台手机上使用特定帧率录屏（如30fps，即1帧33ms），再通过数帧数的方式来计算出首帧耗时的时间，录屏的越高越精确。

自动化脚本方案：

通过自动化录屏脚本工具、使用模拟点击 + OCR文字识别/图像识别的方案，识别首/尾帧、进而自动化生成耗时的中位数、平均值。

▐了解原理

在分析问题之前，我们要搞清楚系统是如何将首帧绘制在屏幕上的，了解了这些我们才能针对性的分析问题。

▐使用性能分析工具

1. 官方工具：

从代码、资源等细粒度的维度（如方法级别、事件级别），来定量分析程序对CPU、内存、网络IO等核心计算资源的消耗情况，可以比较完整、全面的分析启动过程，但这种方式得到的数据比较细碎、散点，需要经过一定的归纳、合并才能得到一个具体可实施的方案。

• TraceView：Instrumentation 模式下采用 AddListener 的方式注册 MethodError、MethodExited、MethodUnwind 的回调来采集方法起止时间；Sampling 模式下使用一个 SamplingThread 定时主权线程堆栈，通过对此的堆栈对比近似确定函数的进入和退出时间；虽然是官方提供的工具，但两种模式本身都存在比较大的性能损耗，可能带偏优化方向。

• CPU Profiler：整体通过 JVM Agent 实现，具有完成方法调用栈输出，且支持 Java、C/C++方法的耗时检测，上手比较简单，但其同样存在性能损耗较大的问题，且一般仅用于 debug 包，release 包需要额外添加 debuggable 的配置。

• Systrace：基于 Android 系统层的 Atrace 实现，Atrace 又基于 Linux kernal 层的 ftrace 实现，ftrace 在内核中通过函数插桩获取耗时；其自身性能损耗比较低、数据源丰富且具有较好的可视化页面，但其默认监控点较少，在 APP 自有代码中的监控点需要手动加入，比较麻烦。

2. 二方/三方工具：

如果我们的页面是通过第二/三方的页面框架所构建，如weex/rn/flutter等框架。我们可以通过第二方框架提供的性能分析工具、插件去分析和归因。

• rn：https://reactnative.dev/docs/performance

• flutter：https://docs.flutter.dev/perf/ui-performance

• compose ui:https://developer.android.com/develop/ui/compose/performance

3. 业务自定义工具：

有时为了弥补官方工具火焰图太细碎、难以聚类、需要花费更多时间去分析和追踪，我们可以根据业务视角、使用自定义的业务阶段/流程，去粗粒度的去分析各个阶段的耗时。

分析完原因后，我们需要对不同原因给出优化方案，首帧优化的核心思想用一句话总结是：在尽可能在短的时间里准备好首帧渲染所需要最小的资源模型。围绕“最短时间”和“最小的模型”两个中心思想下，总结了一些常见的优化策略：

▐预加载/缓存策略

在前置页面的合理时机（一般是闲时）提前获取数据、下载资源，并解析，然后缓存到内存或者磁盘里，以便后置页面快速读取数据和资源。

这个策略可能带来以下副作用：

▐延迟初始化（懒加载）

与首帧无关的代码逻辑、资源可以在首帧渲染后进行初始化，具体的初始化时机可以在使用时再初始化，如某些二级页面的创建、多余tab的创建等。

▐并行处理&异步化

并行处理：充分利用多核CPU，通过多线程并行处理耗时的任务，提升CPU的负荷。如容器初始化和数据请求解析可以同时进行。

异步化：一些比较耗时、IO任务，不要占用宝贵的主线程资源。

▐View渲染优化

Android里面ViewTree构建和渲染是比较耗时过程的，如下：

• 将 xml 文件解析到内存中 XmlResourceParser 的 IO 过程；
• 根据 XmlResourceParser 的 Tag name 获取 Class 的 Java 反射过程；
• View渲染：layout、measure、draw

• 层级优化/布局优化 （merge嵌套），减少布局层级，减少递归深度
• 使用ViewStub，延迟按需inflate，降低inflate耗时

▐数据借用

为了加快数据获取，我们可以从前一个页面借用一部分数据过来将主体内容做填充，随后再用真实数据刷新。这个方案多适用于列表进入详情的场景。

这里的数据不仅包含文字和图片，也可以延伸到媒体播放器、camera取景器等其他一些文件流、数据流，甚至可以是widget组件（共享元素动画）。

▐分块渲染

如果页面元素比较多，数据量比较大，一次性请求加载的时间比较长，这个时候我们可以通过分块的方式，将大页面拆成若干个小页面模块、将服务端接口拆成若干个小接口，各个页面模块独立渲染。可以有效降低服务端RT耗时，以及页面渲染耗时。

▐骨架图优化

使用骨架图作为打底图和纯白底图相比，有了布局样式等信息，更加接近于首帧的效果，正式数据刷新时，页面也不会出现明显刷新，体验比较好。

线下的优化，并不意味着线上真实用户也能同步看到优化的结果，因为业务路径的差异、机型的差异，你线下的优化可能不具备普遍性，所以需要线上真实结果的反馈。

1. 较全面信息的数据大盘建立：

包含：版本、设备分、业务场景、机型、时间等尽可能多的数据维度的数据大盘，可以尽量还原优化or劣化的信息全貌，提供更多的归因信息。

2. 分位值（数据聚合类别）：

长尾数据、小众case往往容易被整体数据给覆盖，不足以引起重视，为了我们应该分别分析中位数、分位数。

3. AB实验：

这样做不仅能控制变量确保优化项的严格有效，还能借此来观察性能优化所带来的业务指标收益，这些都可以作为规划后续启动优化方向的参考指导。

防劣化

人无完人，人都会失误犯错，绝对不能把系统性能交给某一个人身上，一个人犯错概率高，一群人都犯错的概率低，应该交给一群人共同协作的机制和流程。

防劣化相比于优化是更能持久有益的，所以更应该在较早期建立起防劣化机制：

• 大盘监控：趋势分析

• 分阶段监控：归因分析

• 监控告警：及时止损

▐持续迭代

首帧优化并非一蹴而就，而是一个需要持续迭代与打磨的过程，在初期阶段优化空间相对较大，只需要投入一些不多的资源，即可看到较大的收益，但随着优化不断深入，到了中期阶段，就需要有相当程度的投入，去攻坚各个难点，聚少成多，才能看到收益。后期随着业务越来越复杂，分支越来越多，要做防劣化工作，同时也要和业务一起做好精细化管理，将有限的资源，分配给最优先级的业务，要做好ab实验管控、优先级管理、及时下线等。

▐做好复杂度管理

为了将达到最优的启动速度，我们运用了各式各样的策略，将时间和空间塞得满满的，但是这改变了原来的常规流程，带来了额外代码复杂度提升，比如预加载策略，后面维护同学需要考虑，预加载失败以及成功两种情况，又或者是缓存策略，后面维护的同学需要考虑缓存命中、不命中的情况，如果不断使用if堆积代码，那代码最终将无法维护。所以我们需要通过框架来管理复杂度，尽量让业务层无感知。比如数据中间层，业务无需关心数据是否来自缓存还是实时请求，拿来使用即可。

▐全局意识

通常我们以启动速度来衡量启动性能。为了提升启动速度，我们可能会把一些原本在启动阶段执行的任务进行延后或者按需，这种方式能够有效优化启动速度，但同时也可能损害后续的使用体验。比如，如果将某个启动阶段的后台任务延后到后续使用时，如果首次使用是在主线程，则可能会造成使用卡顿。因此，我们在关注启动性能的同时，也需要关注其他可能影响的指标。性能上我们需要有一个能体现全局性能的宏观指标，以防止局部最优效应。

参考资料

• Profile性能追踪工具集：

  https://developer.android.com/studio/profile

• Android Performance 指南：

  https://developer.android.com/topic/performance/overview

• RN Performance 指南：

  https://reactnative.dev/docs/performance

• Flutter Performance 指南：

  https://docs.flutter.dev/perf/ui-performance

• Android Activity的创建流程：

  https://juejin.cn/post/7063699032144609287

• View 的渲染机制：

  https://blog.csdn.net/u012216131/article/details/115704825

• Android 底层渲染原理：

  https://www.cnblogs.com/mysweetAngleBaby/p/15549126.html

• 抖音Android启动优化之理论和工具篇：

  https://mp.weixin.qq.com/s?__biz=MzI1MzYzMjE0MQ==&mid=2247491335&idx=1&sn=e3eabd9253ab2f83925af974db3f3072

团队介绍

我们是淘天集团-内容技术团队，专注于推动淘宝内容生态和电商体验的深度融合。我们致力于为全球用户提供丰富、多样性、高品质的购物内容体验，旨在通过技术创新，更好地连接用户和商品，以提升用户的购物满意度和平台的商业价值。通过尖端技术提升内容创作、分发与消费的效率，赋能内容创作者、商家与消费者，构建一个繁荣、健康、可持续发展的内容生态圈。