一、启动分析

1、启动过程分析

常见APP启动过程

T1预览窗口显示，系统启动应用之前，会根据应用的Theme属性创建预览窗口，当我们禁用预览窗口或改为透明时，显示的就是桌面
T2闪屏显示，APP进程和预览之后通常会有一个闪屏页面
T3主页显示
T4界面可操作，真正完成一个APP的启动，实现用户的可交互
2、启动问题分析
问题1：点击图标很久都不响应
如果禁用了预览窗口或者设置为透明，T1时刻会显示桌面，知道T2时刻才会显示应用界面，造成这段时间无响应的错觉，造成体验较差，尤其在低端机问题更加明显。
问题2：首页显示太慢
应用启动太复杂，闪屏广告、热修复框架、插件化框架等第三方sdk初始化，所有准备工作都需要集中到启动阶段完成
问题3：首页显示之后无法操作
可以考虑将部分业务通过异步的方式处理，精简业务

二、启动优化

1、优化工具
常见的工具中，Traceview性能损耗太大，得出的结果并不真实；Nanoscope非常真实，不是暂时只支持Nexus 6P和x86模拟器，无法针对中低端机做测试；Simpleperf的火焰图不适合做启动流程分析，systrace可以很方便地追踪关键系统调用的耗时情况，但是不支持应用程序代码耗时分析。
综合来看，“systrace + 函数插装”的方式比较理想，而且还可以看到系统的一些关键的事件，例如GC、System Server、CPU调度等。通过插装，我们可以看到应用主线程和其他线程的函数调用流程，实现方式为分别插入到每个方法的入口和出口。
2、优化方式

闪屏优化
预览窗口做成闪屏的效果，用户可以在很短的时间就可以看到“预览闪屏”，这种方式在高端机上体验非常好，但在中低端机上会把总的闪屏时间变得更长。推荐的做法是只在Android 6.0或者Android 7.0以上才启用“预览闪屏”方案，让性能好的手机用户获得更好的体验，另一个做法是将闪屏页和主页合并，减少一个页面的显示。
业务梳理
我们需要清楚当前启动过程正在运行的每一个模块，哪些是必须的，哪些是可以砍掉了，哪些是可以懒加载的，根据业务调整启动流程。、
业务优化
通过业务梳理之后，剩下的就是必须要保留的模块，我们需要针对这些做大量优化，抓住重点，考虑做适当的精简合并。
线程优化
线程的优化主要是减少CPU调度带来的波动，让应用启动时间更加稳定。具体来说一方面是控制线程数量，线程数量太多会相互竞争CPU资源，因此要有统一的线程池，并且根据手机性能来控制数量。另一方面是检查线程间的锁，排查锁等待是否可优化，特别要防止主线程出现长时间的空转。
GC优化
在启动过程中，尽量减少GC的次数，避免主线程长时间卡顿。
系统调用优化
在启动过程不要过早的拉起其他应用的进程，System Server和新的进程都会竞争CPU资源。
I/O优化
在负载过高的时候，I/O性能下降的比较快，特别是低端机，所以启动过程不建议出现I/O操作，磁盘I/O是启动优化要关注的点。减少启动过程读写的I/O文件，还有数据结构的选择，比如SharedPreference不是和大量的数据读写。
数据重排
Linux文件系统从磁盘读写数据，会议block为单位去磁盘读取，一般block的大小是4KB，也就是说一次读写大小至少为4KB，然后会把4KB数据放到页缓存Page Cache中。Dex文件用到的类和安装包APK里面各种资源一般比较小，但是读取非常频繁，我们可以利用这个机制将他们按照读取顺序重新排列，减少真实的I/O操作。
类重排：
Facebook提供的ReDex可以针对Dex文件进行优化
资源文件重排：
实现方式是通过修改Kernel源码，单独编译了一个特殊的ROM，这样做的目的有三个：
1）统计，统计应用启动过程加载了安装包中哪些资源文件，比如assets、drawable、layout等，跟类重排一样，我们可以得到一个资源文件的加载顺序
2）度量，在完成资源重排后吗，我们需要确定是否生效
3）自动化，通过定制ROM可以解放人工的方式，大大提高效率和准确性
类的加载
在类加载的过程中有一个verify class的步骤，它需要校验方法的每个指令，是一个比较耗时的操作，我们可以通过hook的方式去掉这个步骤，但这可能会头兼容性问题，尤其是ART虚拟机，同时可能引入未知问题。
黑科技慎重使用
保活、插件化和热修复方案慎重选择和使用，至少要了解实现原理，再决定使用

三、启动监控

1、实验室监控
视频录制可以非常客观的展示结果，但是难点是无法确认合适应用启动完成。当页码绘制超过80%的时候可以认为启动完成，手动输入一张图片，当实验系统认为当前屏幕有80%相似度就认为启动结束
2、线上监控
实验室的监控毕竟是有限的，无法满足日常需求，我们还是需要线上的结果。线上监控会更加复杂，Android Vitals可以对应用冷启动、温启动时间做监控。