Android App优化之提升App启动速度之理论基础

蔚落 2022-05-14 05:48 265阅读 0赞

*   *  一、欲善其事, 先利其器
        
         *  1.1 Traceview介绍
         *  1.2 Traceview指标
         *  1.3 Traceview使用
            
             *  1.3.1 通过DDMS
             *  1.3.2 通过代码
     *  二、App启动流程分析
     *  三、App启动方式
        
         *  3.1 冷启动
         *  3.2 热启动
         *  3.3 温启动
     *  四、App快速启动敌人
     *  五、结语

> 作者：anly\_jun  
> 链接：[https://www.jianshu.com/p/98c1656a357a][https_www.jianshu.com_p_98c1656a357a]  
> 声明：本文在原文基础上对内容和格式做了些许调整优化

## 一、欲善其事, 先利其器 ##

> 论语有云：工欲善其事，必先利其器。要想提升App的启动速度，我们需要先找到拖后腿的点，要想找到这些点，我们就需要借助我们的工具了。

[前文][Link 1]提到了很多工具, 今天我们使用`Traceview`来分析我们的启动过程。

### 1.1 Traceview介绍 ###

`Traceview`是一个性能分析工具，主要是分析当前线程情况，各个方法执行时间等。如下:  
![这里写图片描述][70]

### 1.2 Traceview指标 ###

指标说明:

*  Incl(Inclusive) Cpu Time：方法本身和其调用的所有子方法占用CPU时间.
 *  Excl(Exclusive) Cpu Time：方法本身占用CPU时间.
 *  Incl Real Time：方法(包含子方法)开始到结束用时.
 *  Excl Real Time：方法本身开始到结束用时.
 *  Call + Recursion Calls/Total：方法被调用次数 + 方法被递归调用次数.
 *  Cpu Time/Call：方法调用一次占用CPU时间.
 *  Real Time/Call：方法调用一次实际执行时间.

一般来说, 我们使用Real Time/Call排序来找出耗时多的方法。

> 有必要解释下CPU Time和Real Time:  
> CPU Time 方法实际执行时间(不包括io等待时间)  
> Real Time 方法开始结束时间差(包括等待时间)  
> 参考：[http://stackoverflow.com/questions/15760447/what-is-the-meaning-of-incl-cpu-time-excl-cpu-time-incl-real-cpu-time-excl-re/17902682\#17902682][http_stackoverflow.com_questions_15760447_what-is-the-meaning-of-incl-cpu-time-excl-cpu-time-incl-real-cpu-time-excl-re_17902682_17902682]  
> start

### 1.3 Traceview使用 ###

一般可以通过两种方式使用`Traceview`。

#### 1.3.1 通过DDMS ####

启动DDMS，如下：

![这里写图片描述][70 1]

点击开始时会弹出一个选择`trace`模式的框, 默认选中`Sample based profiling`即可：  
![这里写图片描述][70 2]

每项具体描述如下：

*  Sample based profiling(基于样本分析)  
    根据采样时间间隔来规律的打断VM来记录方法调用栈(Call Stack), 开销和采样频率成比例.
 *  Trace based profiling(基于完整trace数据分析)  
    记录每个方法的出入口, 每个方法执行时都开启记录, 无论多小的方法, 因此开销很大.

#### 1.3.2 通过代码 ####

// 在自己想要开始调试的地方start
    Debug.startMethodTracing("GithubApp");
    
    // 在合适的地方stop
    Debug.stopMethodTracing();

> 注: 以上方法开启trace的方式相当于”Trace based profiling”，会记录每个方法的执行。Android 4.4及以上可以调用startMethodTracingSampling()来用代码开启”Sample based profiling”的trace方式。

## 二、App启动流程分析 ##

要想优化App启动流程，必先了解其启动过程。  
具体过程请参看这篇译文： [Android Application启动流程分析][Android Application]

## 三、App启动方式 ##

通常来说, 一个App启动会分如下三中不同的状态：冷启动 热启动 温启动

### 3.1 冷启动 ###

App没有启动过或App进程被killed, 系统中不存在该App进程, 此时启动App即为冷启动。

冷启动的流程即为第2节所描述的App启动流程的全过程，需要创建App进程，加载相关资源，启动Main Thread，初始化首屏Activity等。

> 在这个过程中，屏幕会显示一个空白的窗口(颜色基于主题)，直至首屏Activity完全启动。

下图展示了冷启动的时间线：

![这里写图片描述][70 3]

### 3.2 热启动 ###

热启动意味着你的App进程只是处于后台, 系统只是将其从后台带到前台，展示给用户。

> 类同与冷启动, 在这个过程中，屏幕会显示一个空白的窗口(颜色基于主题), 直至activity渲染完毕。

### 3.3 温启动 ###

介于冷启动和热启动之间, 一般来说在以下两种情况下发生:

*  用户back退出了App, 然后又启动. App进程可能还在运行, 但是activity需要重建.
 *  用户退出App后, 系统可能由于内存原因将App杀死, 进程和activity都需要重启, 但是可以在onCreate中将被动杀死锁保存的状态(saved instance state)恢复.

通过三种启动状态的相关描述, 可以看出我们要做的启动优化其实就是针对冷启动. 热启动和温启动都相对较快。

## 四、App快速启动敌人 ##

根据冷启动的时间图, 可以看出, 对于App来说, 我们可以控制的启动时间线的点无外乎:

*  Application的onCreate
 *  首屏Activity的渲染

而我们现在的App动不动集成了很多第三方服务, 启动时需要检查广告, 注册状态等等一系列接口都是在Application的onCreate或是首屏的onCreate中做的.

> 很多第三方平台的SDK文档也都是这么建议的。

## 五、结语 ##

明白了App的启动原理, 也知道了App启动过程中哪些地方容易阻塞, 还知道了用什么工具来分析每个方法的执行时间, 那么接下来就很容易做了。

下一篇将完全以实例的方式来说明App启动优化该怎么分析, 怎么做。

[https_www.jianshu.com_p_98c1656a357a]: https://www.jianshu.com/p/98c1656a357a
[Link 1]: https://blog.csdn.net/u010358168/article/details/81949211
[70]: /images/20220514/908d1c60ea7247f588fee3e203c57af1.png
[http_stackoverflow.com_questions_15760447_what-is-the-meaning-of-incl-cpu-time-excl-cpu-time-incl-real-cpu-time-excl-re_17902682_17902682]: http://stackoverflow.com/questions/15760447/what-is-the-meaning-of-incl-cpu-time-excl-cpu-time-incl-real-cpu-time-excl-re/17902682#17902682
[70 1]: /images/20220514/1f90662d307748538449a0f4b7b8911e.png
[70 2]: /images/20220514/8865d9d145204e6cb8dcb4702c3116c6.png
[Android Application]: https://www.jianshu.com/p/a5532ecc8377
[70 3]: /images/20220514/1f470530f168420085b6c39d92003341.png