【从入门到实用】android启动优化深入解析

今天一如既往，不做标题党，给大家介绍一些可以实用的启动优化方案~

对于android APP来说，启动时间是用户的第一体验，如果启动时间过长，很可能会流失用户，所以启动优化也是我们做性能优化的一个重要方向
本文主要包括以下内容
1.启动优化有哪些优化方向？
2.如何精准测量启动时间？
3.有哪些实用的优化手段？

启动优化有哪些优化方向？

应用有三种启动状态，每种状态都会影响应用向用户显示所需的时间：冷启动、温启动或热启动。在冷启动中，应用从头开始启动。在另外两种状态中，系统需要将后台运行的应用带入前台。
本文所说的启动优化都是指冷启动优化

要优化应用以实现快速启动，了解系统和应用层面的情况以及它们在各个状态中的互动方式很有帮助。

冷启动

冷启动是指应用从头开始启动：系统进程在冷启动后才创建应用进程。
发生冷启动的情况包括应用自设备启动后或系统终止应用后首次启动。
这种启动给最大限度地减少启动时间带来了最大的挑战，因为系统和应用要做的工作比在另外两种启动状态中更多。

在冷启动开始时，系统有三个任务，它们是：
1.加载并启动应用。
2.在启动后立即显示应用的空白启动窗口。
3.创建应用进程。

系统一创建应用进程，应用进程就负责后续阶段：
1.创建应用对象。
2.启动主线程。
3.创建主 Activity。
4.填充视图。
5.布局屏幕。
6.执行初始绘制。

一旦应用进程完成第一次绘制，系统进程就会换掉当前显示的后台窗口，替换为主 Activity。此时，用户可以开始使用应用。

如上所示，Application与Activity的生命周期就是我们的优化方向
一般为Application onCreate方法与首个Activity加载耗时

如何测量启动时间？

最简单方法

通过查看logcat可以快速了解启动时间
在Android Studio Logcat中过滤关键字Displayed，可以看到对应的冷启动耗时日志。

命令测量

for i in seq 1 10
do
adb shell am force-stop com.xx.xx
sleep 2
adb shell am start-activity -W -n 包名/activity名称 | grep “TotalTime” | cut -d ’ ’ -f 2
done

有时候我们需要统计app的冷启动性能，单次结果往往不准确 还需要多次统计以后做平均值
如上，使用脚本启动10次首页Activity,可以比较准确的获取冷启动性能

命令测量方式线下使用方便，可以测试竞品
但是不能带到线上,不能精准控制测量时间
所以我们通常还需要手动埋点

埋点测量

埋点测量关键点在于合适的开始与结束时间
我们一般使用Application attachBaseContext作为开始时间
而启动结束时间则有很多选择

IdleHandler

IdleHandler在MessageQueue空闲时会回调,也就是所在线程任务已经执行完时，线程处于空闲状态时才会执行Idle列表中的任务。
正常情况下，当主线程程处于空闲状态时，可以认为冷启动已经完成，是一个比较不错的打点时机
但有个问题，