冷, 温, 热启动
Android启动应用, 按官方说法分为冷启动, 温启动和热启动.
具体的定义可以看官方文档, 简单地说
冷启动就是应用进程不存在
- 系统需要从零开始启动应用, 一般是首次启动或者应用被系统终止后启动.
温(暖)启动就是应用进程还在, 但是Activity不在了
- 系统需要重新创建并恢复Activity页面, 典型场景是返回键退出了应用(页面被Finish了)后马上又进入应用, 或者离开应用后页面被系统移出内存(被kill了).
热启动就是进程和Activity都还在
- 系统只需要从把Activity带到前台展示即可, 典型场景是Home键退出应用后又进入应用.
冷启动优化
一般我们只需要关注冷启动即可.
#1 宏观原则
要想启动快, 硬件性能必然有影响, 在硬件一定的前提下, 我们要尽量降低启动应用时CPU的负载, 让CPU有更多的算力投入到启动流程中:
- 减少进程: 创建进程会耗费大量资源, 非必要的子进程应该延迟启动, 例如升级进程, 热修复进程
- 控制线程数量: 创建线程会耗费较多资源, 另外CPU是分时执行的, 线程数量多, 那么分给启动主线程的资源就少, 另外线程调度也是耗时的.
- 降低工作线程优先级: 一般来说优先级越低的线程, 被分配的执行时间越少, 所以我们可以将子进程优先级设置为
THREAD_PRIORITY_BACKGROUND, 这样子线程最多能获取到10%的时间片, 间接增加主线程的执行时间. - 减少线程锁等待时间, 特别需要注意的是, 对于系统服务, 例如AMS和WMS等, 很多操作都是带锁的, 有可能出现锁等待.
- 减少跨进程通信, 很多系统服务底层都是跨进程调用, 需要留意
- 减少磁盘IO和网络IO调用, 尤其当负载较高时, IO操作耗时会比平时多. 而且对于磁盘IO, 多线程读取效果有限, 所以需要我们对磁盘IO进行详细的分析, 包括读写了什么文件, 多少个字节, Buffer是多大, 使用了多长时间, 在什么线程等, 据此进行优化.
- 避免GC, GC会占用很多资源, 尤其在低版本机器上, 是造成卡顿的常见原因之一, 我们可以通过避免创建复杂对象, 或者复用对象, 使用Native实现来降低GC频率
#2 Application和Content Provider
在做好一些基本原则后, 接着看具体的流程优化点
在应用进程创建后, 首先必然是加载类, 此时一些静态变量就会初始化了, 因此我们应该
- 避免大量的静态变量
- 复杂的静态变量延迟初始化, 例如线程
类加载完毕后就是创建Application实例了, 因此我们应该
- 在
Application中避免在成员变量中初始化复杂对象 - 特别地, 对于多进程来说, 每个进程都会创建
Application对象, 所以需要注意只初始化该进程会使用到的对象
之后会先创建ContentProvider和执行ContentProvider.onCreate(), 因此我们应该
- 减少
ContentProvider的数量, 如果是SDK初始化可以使用Jetpack里面的StartUp库 - 避免在
ContentProvider中执行耗时操作, 因此它也是在主线程中执行
跟接着就会执行Application.onCreate()等方法, 因此我们应该
- 非必要步骤, 延迟初始化
- 耗时操作异步初始化
- 如果是多进程, 区分进程, 只初始化必需的步骤
- 避免启动其他组件, 例如后台service, 因为其他组件都在主线程中执行初始化, 同样耗费时间
#3 Activity
接着就进入Activity环节.
同样第一步会是创建实例, 因此我们应该
- 避免在成员变量中直接初始化启动过程不会使用的对象或者复杂对象
在Activity进程生命周期后, 第一步就是渲染(inflate)布局, 我们应该
- 偏平化布局, 例如使用约束布局
ConstraintLayout - 减少冗余, 例如移除重合的背景图
- 延迟渲染, 例如使用ViewStub替换启动阶段暂时不会显示的控件
- 使用自定义View, 因为主要耗时是读取和解析XML文件, 所以如果布局较为简单(一般不可能~), 可以考虑直接创建对象的方法来渲染布局
- 避免在控件的构造方法, 测量, 布局, 绘制等流程中进行耗时操作
- bitmap的加载和解码相对来说都比较耗时, 非必要的图片可以延迟展示
- 启动页少用VectorDrawable, 官网中特别提到VectorDrawable的栅格化比较耗时
#0
在应用启动的瞬间, 系统服务会先展示一个空白窗口, 等待应用第一帧绘制完毕后, 再从该窗口切换到应用, 如果启动耗时较长, 就会明显看到白屏, 对于这一点, 常见的操作有
- 通过
windowDisablePreview来禁用系统窗口, 也就是不再展示这个空白窗口, 那么就不会看见白屏了, 但是并不会对启动速度有帮助, 甚至更慢, 所以一般只在高性能的机器上这样做 - 更常见的是通过
windowBackground来让这个窗口显示指定的背景图, 这样可以让过渡更自然, 用户感官上好一点, 但是实际上不会对启动速度有帮助
关于延迟初始化
IdleHandler
可以使用IdleHandler, 在主线程空闲时再执行某些不重要的操作
关于异步初始化
实际上异步初始化只是不阻塞主线程, 但是子线程一样会占用CPU资源, 让主线程的执行时间变少, 所以不应该盲目地将所有工作放到子线程.
黑科技
优化做到最后, 就是在系统流程上做文章了
#1 类重排(Facebook)
原理是将启动时加载的类放到主dex，提升了这些类的内聚，让更多的类满足pre-verify的条件，在安装时就做了校验和优化，以减少首次加载的耗时，从而优化冷启动耗时。
Redex 初探与 Interdex：Andorid 冷启动优化
#2 安装包重排(阿里)
应用启动过程中会从apk压缩包中读取文件, 该优化的原理是利用Linux中的Pagecache机制, 让启动过程会用到的文件尽可能进入缓存中, 减少磁盘IO次数
支付宝 App 构建优化解析：通过安装包重排布优化 Android 端启动性能
#3 类加载优化
在Dalvik VM(Android5.0以前)加载类的时候会有一个类校验过程, 它需要校验方法的每一个指令, 是一个比较耗时的过程, 可以通过Hook去掉类加载过程中的类验证过程. 不过对于ART(Android5.0之后)来说, 这个过程在安装时已经做了, 所以用处不大.
#0 保活
不进入冷启动, 就不用优化了~
分析工具
CPU Proiler
这个Android Studio自带的工具, 可以看到启动过程中详细的方法执行流程, 但是采集数据本身会影响方法执行, 所以不能准确判断每个方法的耗时, 但是仍可以判断哪个方法相对来说耗时.
SysTrace
这个工具的好处是可以自定义事件, 可以指定需要采集的数据集, 可以看到线程间的状态等.
启动计时
启动优化的一个关键点在于定义启动结束的点, 以及如何测量启动时间.
ActivityManager提供的日志
在Android4.4以上, 系统进程会提供一个类似ActivityManager: Displayed ***: +3s534ms的日志, 表示从启动进程到首次绘制完毕所用的时间.
主动调用reportFullyDrawn
应用可以在任何时候调用该方法, 触发系统打印类似system_process I/ActivityManager: Fully drawn {package}/.MainActivity: +1s54ms的日志
onPreDraw/onDraw
应用可以通过ViewTreeObserver来监听绘制前回调来判断第一帧的绘制时机, 或者直接在控件树的末尾加一个简单的View, 它onDraw调用时即表示页面(差不多)绘制完毕.
Bonus
应用启动过程可以参考Android Vitals Series' Articles系列文章