当App中的业务模块越来越多、越来越复杂,集成了更多的三方库,App启动也会越来越慢,因此我们希望能在业务扩张的同时,保持较优的启动速度,给用户带来良好的使用体验,那么我们就需要对APP的卡顿进行检测,bugly和友盟+U-APM都是对APP进行优化的工具,相比较使用,我还是觉得友盟+U-APM更加好用一点,友盟+U-APM有启动耗时统计这个功能,对APP冷启动优化还是有很大作用的。本文就借助友盟+U-APM这个平台来讨论一下APP冷启动优化。
热启动与冷启动
当用户按下home 键,App不会立刻被kill,而是存活一段时间,这段时间里用户再打开 App,App基本上不需要做什么,就能还原到退到后台前的状态。我们把App进程还在系统中,无需开启新进程的启动过程称为热启动。
而冷启动则是指App不在系统进程中,比如设备重启后,或是手动杀死App进程,又或是App长时间未打开过,用户再点击启动App的过程,这时需要创建一个新进程分配给App。我们可以将冷启动看作一次完整的App启动过程。
一、 冷启动概要
WWDC 2016 中首次出现了 App 启动优化的话题,其中提到:
• App启动最佳速度是400ms以内,因为从点击App图标启动,然后 Launch Screen 出现再消失的时间就是400ms;
• App启动最慢不得大于20s,否则进程会被系统杀死;(启动时间最好以App所支持的最低配置设备为准。)
冷启动的整个过程是指从用户唤起App开始到AppDelegate中的 didFinish