巧用友盟+U-APM 实现移动端性能优化—启动速度

移动端性能对用户体验、留存有着至关重要的影响，作为开发者是不是被这样吐槽过，“这个 APP 怎么这么大？”、“怎么一直在 APP 封面图转悠，点不进去”、“进入详情效果有些卡”、“用 4G 使用你们的 APP，我的流量有点不够啊”等等，这些问题都直观反映出，一个体验良好的应用，只有功能健全还不够，以下是我在性能优化上总结的几点：

• 启动速度优化

• 流畅度优化

• 资源优化

• 内存优化

• APK 体积优化

今天先聊聊，启动速度的那些事

应用启动流程

冷启动

从点击应用图标到UI界面完全显示且用户可操作的全部过程。

特点：耗时最多，衡量标准

启动流程：Click Event -> IPC -> Process.start -> ActivityThread -> bindApplication -> LifeCycle -> ViewRootImpl

热启动

因为会从已有的应用进程启动，所以不会再创建和初始化Application，只会重新创建并初始化Activity。

特点：耗时较少

启动流程：LifeCycle -> ViewRootImpl

因此判断应用启动速度的的标准是冷启动的速度，即杀掉应用后重新启动的速度，此项主要是和你的竞品对比。

不应在 Application 以及 Activity 的生命周期回调中做任何费时操作，具体指标大概是你在 onCreate，onResume，onStart 等回调中所花费的总时间最好不要超过 400ms，否则用户在桌面点击你的应用图标后，将感觉到明显的卡顿。

冷启动分析及优化方向

冷启动涉及的相关任务

冷启动之前

1. 首先，会启动 App

2. 然后，加载空白 Window

3. 最后，创建进程

需要注意的是，这些都是系统的行为，一般情况下我们是无法直接干预的。

随后任务

1. 首先，创建 Application

2. 启动主线程

3. 创建 MainActivity

4. 加载布局

5. 布置屏幕

6. 首帧绘制

通常到了界面首帧绘制完成后，我们就可以认为启动已经结束了。

下面是官方文档中的启动过程流程图，显示系统进程和应用进程之间如何交接工作。实际上对启动流程的简要概括。

优化方向

我们的优化方向就是 Application 和 Activity 的生命周期这个阶段，启动中的系统任务我们无法干预，能干预的就是在创建应用和创建 Activity 的过程中可能会出现的性能问题。这一过程具体就是：

• Application 的 attachBaseContext

• Application 的 onCreate

• activity 的 onCreate

• activity 的 onStart

• activity 的 onResume

activity 的 onResume 方法完成后才开始首帧的绘制。所以这些方法中的耗时操作我们是要极力避免的。并且，通常情况下，一个应用的主页的数据是需要进行网络请求的，那么用户启动应用是希望快速进入主页以及看到主页数据，这也是我们计算启动结束时间的一个依据。

U-APM 在启动优化上的应用

以前使用友盟统计来分析 App 日活、埋点等数据，发现友盟推出的 U-APM ，赶紧来尝尝鲜。

U-APM 是友盟+推出的 App 稳定性监控、性能监控和云真机测试平台。通过轻量级的集成接入即可拥有实时、可靠、全面的应用崩溃、ANR、自定义异常等捕获能力，及卡顿、启动分析等性能能力，支持多场景、多通道智能告警监控，帮助开发者高效还原异常、卡顿用户的访问路径和业务现场，缩短故障排查时间。就启动分析这项能力来看看，U-APM 都做了什么。

U-APM 支持启动趋势分析、慢启动分析、启动崩溃分析。

启动趋势分析

启动趋势较为直观的展示应用启动耗时的平均值、分位值、区间分布等数据，以及启动阶段的性能分解数据，也能分析出，多版本迭代后，启动时间的分布状况。