移动端性能对用户体验、留存有着至关重要的影响，作为开发者是不是被这样吐槽过，“这个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支持启动趋势分析、慢启动分析、启动崩溃分析。
启动趋势分析
启动趋势较为直观的展示应用启动耗时的平均值、分位值、区间分布等数据，以及启动阶段的性能分解数据，也能分析出，多版本迭代后，启动时间的分布状况。
慢启动分析
慢启动分析，有助于开发者追根溯源，该功能展示慢启动情况的占比以及慢启动设备列表，您可以在启动设置中自定义慢启动的划分，默认首次启动/冷启动超过3秒为慢启动，热启动超过1秒为慢启动。
冷启动阶段的慢启动分析，直观表现出慢启动比例以及慢启动平均耗时。
慢启动分布，直观表现出，慢启动分布的设备、系统、运营商、版本、渠道、地域。
启动崩溃分析
归纳启动阶段中出现的崩溃信息，支持划分首次启动、冷启动、热启动状态下的崩溃，默认启动耗时上限为8秒，超出时间的崩溃不被划分至启动崩溃。
这对减少应用启动时间，提供了巨大帮助，官方已提供Demo
总结
移动端性能优化环环相扣，启动时间优化也是较为重要的一个环节，U-APM的出现，无疑是开发者的福利，帮助开发者及早发现问题，解决问题，至于U-APM其他功能，可以登录官方网站去体验。
作者：任裕斌
