Android 性能优化(六)：启动优化的详细流程

书接上文，Android 性能优化（一）：闪退、卡顿、耗电、APK

从用户体验角度有四个性能优化方向：

追求稳定，防止崩溃
追求流畅，防止卡顿
追求续航，防止耗损
追求精简，防止臃肿

防止卡顿

卡顿的场景通常与用户交互体验最直接，分别为UI、启动、跳转、响应四个方面，如下图所示。

主要有两大因素：

界面绘制：层级深、元素复杂、频繁刷新等。由于这些原因导致卡顿的场景更多出现在启动后的初始界面以及跳转到页面的绘制上。
数据处理：数据处理量太大。一般分为三种情况，一是数据在处理 UI 线程，二是数据处理占用 CPU 高，导致主线程拿不到时间片，三是内存增加导致 GC 频繁，从而引起卡顿。

UI优化

主要是绘制和刷新的卡顿，典型表现在页面的列表的滑动加载和刷新。

针对绘制可以使用懒加载，针对刷新可以使用局部刷新。详情参考：

（四）RecycleView 滑动到置顶、Adapter局部刷新

（七）RecycleView 性能提升、卡顿优化

启动优化

启动速度是用户第一印象，过长会让用户失去耐心；根据行业数据统计，启动速度与用户留存有着直接相关；

对于开发者来说，通过各种技术手段来提升启动性能缩减启动时长，对整站业务的各项指标提升都会有较大帮助。因此，启动优化是各个客户端团队在体验优化方向上十分重要的一环。

评估量化

在计划优化立项之前，先确定两件事。

一、目标任务的启动是否值得优化？

衡量一个任务是否要启动有两个关键指标：“投入产出比”、“产出风险比”。

投入产出比：当完成优化任务需要 3人/天，收获90分位 100ms 的优化产出；另一个只收获90分位 10ms 的优化产出。显而易见选前者。因为优化的前期追求的的是优化收益，等到后续开启二期任务、三期任务需要做到更加极致时，才会考虑成本高但收益低的任务。
产出风险比：当做优化任务时，可能会有风险点影响某个业务，这时需要衡量风险影响范围的大小，然后和业务方商讨劣化和优化的抉择，最后敲定任务排期。

二、优化的预期结果是否可量化？

有个比较简单的方法就是对标，比如，竞品App或主流App。

当然，启动优化最终目标是“秒开”，即需要 1s 内完成用户的启动流程。

量化建设

工作的价值体现就在于建设丰富的数据大盘来明确以什么形式、从什么角度、监控什么指标。

启动优化的整体监控可以为：

秒开率、2秒开率、3秒开率...
90分位总体性能、90分位各阶段性能；（波动较小，不会被极端的case影响曲线）
分版本各阶段各项指标、整体各阶段各项指标、主版本各阶段各项指标
分场景，如有无广告等等
...

耗时定义

业内常见的app启动过程阶段一般分为「启动阶段」和「首刷阶段」。

启动阶段：指用户点击icon到见到app的首页，起点为Application的onCreate，终点Activity的 onWindowFocusChanged() 。
首刷阶段：指用户见到app的首页到首页列表内容展现起点为Activity的onCreate，终点列表的onAttachedToWindow() 。

为了确保启动优化量化指标的数据能稳定和完整。因此，排除其他启动场景的统计：

启动过程中App退后台
用户未登录场景
特殊场景下的开屏广告，比如有复杂的联动动效
站外push、deeplink拉起。

检测工具

Android Studio 自带的Profiler工具。

如果是 Android 10 及以上就用 Perfetto。

启动阶段

在App的启动流程中，有非常多的启动任务全部在Application的onCreate里被执行，有主线程的有非主线程的，但是不可避免的是，二者都会对启动的性能带来损耗。所以我们需要做的第一件重要的事情就是“启动任务重排与删减”。

可以把启动任务按优先级分类：

刚需高优任务：这类任务初始化，根本无法进入后续流程。所以，不可延迟，必须第一时间最高优先级执行。比如网络库、路由库、存储库等基础库的初始化。
非刚需高优任务：这类任务不初始化，不影响后续首页UI刷新，比如拉取ab实验配置、ip直连、push推送通知服务、长链接等基础建设项。
非刚需低优任务：这类任务对启动阶段后续流程无决定性影响，可以放在启动阶段结束之后再执行或懒加载。比如 x5内核、在线客服sdk、在线反馈SDK、登陆相关极验/深知SDK、LBS定位、搜索记录、城市json数据解析、Flutter/RN/Weex引擎初始化等。

可以考虑封装一个任务管理器，大致代码参考如下：

TaskManager.getInstance().beginWith(A)
                .then(B)
                .then(C, D)
                .then(E)
                .enqueue();
TaskManager.getInstance().runAfterStartup({ xxx; })

通过任务的大致非精细化的排布，我们不仅仅可以对启动任务能够很好的进行监控，还可以更加容易的找出不合理项。