简介
相亲时第一印象非常重要，对于App来说启动速度就是它留给用户的第一印象，重要程度不言而喻。
本篇文章将从具体的项目实践出发，对启动流程、分析测量、启动优化、启动监控几个方面进行分析。
1 启动流程
1.1 启动模式
启动模式分析对比.png
三种启动模式中，冷启动模式启动耗时最长，因此以冷启动来衡量App的启动时间。
1.2 启动流程
1.2.1 第一步：app冷启动之前要执行3个任务
加载启动app、展示空白Window、创建新的进程
1.2.2 第二步：执行和开发者相关的任务
Application的创建；Activity的创建、View加载、屏幕绘制等
App完成第一次绘制后，系统会用绘制完的Activity替换Window的Background了。
总结：作为应用开发者，可以优化的也就是Application创建、Activity创建回调、View绘制的过程。
Google官方的启动加速方向
利用提前展示出来的Window，快速展示出来一个界面，给用户快速反馈的体验；
避免在启动时做密集沉重的初始化（Heavy app initialization）；
定位问题：避免I/O操作、反序列化、网络操作、布局嵌套等。
2 分析测量
2.1 启动时间的测量
2.1.1 命令行测量启动时间
adb shell am start -W 【packageName】/ Acitivity
-S 先停止目标再启动；-W 等待应用启动完毕； -n 启动次数
ThisTime:最后一个启动的Activity的启动耗时；
TotalTime:表示新应用启动的耗时，包括新进程的启动和 Activity 的启动，但不包括前一个应用 Activity pause 的耗时；
WaitTime: ActivityManagerService启动App的Activity时的总时间（包括当前Activity的onPause()和自己Activity的启动）。
2.1.2 代码埋点
在启动关键位置记录时间，进行测量。
如Application的attachBaseContext(); Activity的onCreate、onResume、onWindowFocusChanged（）等
onWindowFocusChanged:被执行起，用户可以与应用进行交互了,
执行顺序：onStart---->onResume---->onAttachedToWindow----------->onWindowVisibilityChanged--visibility=0--------onWindowFocusChanged(true)------->
2.1.3 抓取系统Log（ Displayed、reportFullyDrawn）。
Displayed
这个时间其实是Activity启动，到Layout全部显示的过程。但是这里并不包括数据的加载，很多app实用懒加载模式，数据拉去后再刷新UI。
reportFullyDrawn
系统定义的一个【自定义时间上报】
reportFullyDrawn.png
reportFullyDrawn由开发者自己调用,然后查看日志
@Override
public void onLoadFinished(Loader<Void> loader, Void data) {
// 加载数据
// ……
// 上报reportFullyDrawn
reportFullyDrawn();
}
ActivityManager: Displayed com.example.launcher/. LauncherActivity: +999ms
ActivityManager: Fully drawn com.example.launcher/. LauncherActivity: +1s999ms
2.1.4 Systrace统计开启时间
加入trace.begin()、trace.begin()自定义TAG，进行时间测量，更加精确。
2.1.5 Method Tracing （TraceView）
利用Systrace可大体上发现是否存在性能问题，但如果需要知道具体情况，就需要用到TraceView。
TraceView的作用:
1 查看跟踪代码的执行，分析哪些是耗时操作。
2 可以用于跟踪方法的调用，尤其是Android Framework层的方法调用关系。
3 可以方便的查看线程的执行情况，某个方法执行时间、调用次数、在总体中的占比等，从而定位性能点。
3 启动优化
3.1 布局精简
布局的复杂程度直接影响绘制的时间。
主要从布局嵌套、过度绘制、布局懒加载入手。
成果：布局阶段的布局较为简单，通过优化，可以减少50ms-100ms.
3.2 异步处理耗时任务
子线程处理耗时任务，减少UI线程的做的事情，早进入绘制阶段。
- 不在主线程做耗时任务，如经销商数据库文件加载、网络等。
- 启动阶段的初始化任务，尽量异步处理。（Application中初始化语音SDK比较耗时，第三方SDK初始化和配置也比较耗时，因为SDK中会用到Application中的Context，假若SDK初始化时间较长就会影响启动速度；如果SDK能修改，则分步骤初始化先核心服务再初始化辅助服务）。
- 数据库和IO操作都移动到子线程，优先级设置THREAD_PRIORITY_BACKGROUND，减少子线程获取时间片，保证主线程优先执行。
成果：根据业务的复杂程度，一般可以减少几百毫秒。
3.3 防止多线程抢占CPU
如果并发的子线程过多，UI线程也无法保证一直被调度，导致启动时间变长。
容易抢占CPU的场景：
image.png
通过对执行时间较久，执行频率的业务进行优化，将CPU占有率维持在合理的程度，会大幅减少启动时间，减少300ms以上。
3.4 将任务delay至首页绘制完成后
分析业务流程，将非必须的任务放到首页初始化完成后进行（比如二级页面需要的经销商数据、收藏的歌曲数据）。
进一步优化：可将业务逻辑细分为，首页绘制后5s、10s、20s几个阶段分别初始化（第一屏需要的数据5s后拉取；第二屏需要的数据10s后拉取，或者滑到第二屏时再拉取）。
成果：释放绘制阶段的CPU，绘制时间减少300ms。
3.5 Service初始化延后
App启动中过程中，经常进行Service初始化操作。由于它在主线程中运行，如果Service初始化过程比较耗时，也会影响App启动时间。可以对Service服务延后初始化。
4 启动监控
实时监控：通过埋点，大数据采样投递获取真实线上环境数据，从时间，机型，app版本，系统版本等各个纬度对启动时间进行监控。
【参考】https://www.jianshu.com/p/f5514b1a826c
https://mp.weixin.qq.com/s?__biz=MzI2OTQxMTM4OQ==&mid=2247488180&idx=1&sn=8b5884b5c7d756dca97213061905ebab&chksm=eae1e7e6dd966ef03b81f5b53557bfe9dc1eb268b7a7e60127864ce8f2153e821fc007855b9b&token=1972649905&lang=zh_CN#rd
网友评论