Android 系统性能优化（72）-----App启动优化

App启动优化的一篇深度好文

原文地址：

http://www.jianshu.com/p/c056e63dc7a2

正文

对于Android平台上的线程优先级设置来说可以处理很多并发线程的阻塞问题，比如很多无关紧要的线程会占用大量的CPU时间，虽然通过了MultiThread来解决慢速I/O但是合理分配优先级对于并发编程来说十分重要。

Android在线程方面主要使用的是Java本身的Thread类，我们可以在Thread或Runnable接口中的run方法首句加入Process.setThreadPriority(Process.THREAD_PRIORITY_BACKGROUND); //设置线程优先级为后台，这样当多个线程并发后很多无关紧要的线程分配的CPU时间将会减少，有利于主线程的处理

现场优先级：

int THREAD_PRIORITY_AUDIO //标准音乐播放使用的线程优先级
int THREAD_PRIORITY_BACKGROUND //标准后台程序
int THREAD_PRIORITY_DEFAULT // 默认应用的优先级
int THREAD_PRIORITY_DISPLAY //标准显示系统优先级，主要是改善UI的刷新
int THREAD_PRIORITY_FOREGROUND //标准前台线程优先级
int THREAD_PRIORITY_LESS_FAVORABLE //低于favorable
int THREAD_PRIORITY_LOWEST //有效的线程最低的优先级
int THREAD_PRIORITY_MORE_FAVORABLE //高于favorable
int THREAD_PRIORITY_URGENT_AUDIO //标准较重要音频播放优先级
int THREAD_PRIORITY_URGENT_DISPLAY //标准较重要显示优先级，对于输入事件同样适用。

一、工具：adb 或Python

adb计算app启动时间:

adb shell am start -w packagename/activity

三个返回结果ThisTime，TotalTime，WaitTime

WaitTime就是app启动时间：WaitTime=startTime-endTime
startTime：记录的刚准备调用startActivityAndWait()的时间点
endTime：记录的是startActivityAndWait()函数调用返回的时间点

ThisTime、TotalTime 的计算在 frameworks\base\services\core\java\com\android\server\am\ActivityRecord.java 文件的 reportLaunchTimeLocked() 函数中。

curTime表示该函数调用的时间点.

displayStartTime表示一连串启动Activity中的最后一个Activity的启动时间点.

mLaunchStartTime表示一连串启动Activity中第一个Activity的启动时间点.

displayStartTime和mLaunchStartTime的区别：分两种情

第一种情况

正常情况下点击桌面图标只启动一个有界面的 Activity，此时 displayStartTime 与mLaunchStartTime 便指向同一时间点，此时 ThisTime=TotalTime。

第二种情况

另一种情况是点击桌面图标应用会先启动一个无界面的 Activity 做逻辑处理(如占位界面)，接着又启动一个有界面的Activity，在这种启动一连串 Activity 的情况下（知乎的启动就是属于这种情况），displayStartTime 便指向最后一个 Activity 的开始启动时间点，mLaunchStartTime 指向第一个无界面Activity的开始启动时间点，此时 ThisTime！=TotalTime。这两种情况如下图：

如果只关心某个应用自身启动耗时，参考TotalTime；如果关心系统启动应用耗时，参考WaitTime；如果关心应用有界面Activity启动耗时，参考ThisTime。

二、热启动

如果是你按Back键，并没有将应用进程杀掉的话，那么执行上述命令就会快一些，因为不用创建进程了，只需要启动一个Activity即可。这也就是我们说的应用热启动。

游戏启动的话，就不适用用命令行的方法来启动了，因为从用户点击桌面图标到登录界面，既有系统的部分也有游戏自己的部分。

系统部分：游戏也有一个 Activity，所以启动的时候还是会去启动这个 Activity，所以系统启动部分也就是用户点击桌面桌面响应到这个Activity启动。

游戏部分：一般游戏的主 Activity 启动后，还会做一些比较耗时的事情，这时候你看到的界面是不能操作的，比如：加载游戏数据、联网更新数据、读取和更新配置文件、游戏引擎初始化等操作。从游戏开发的角度来看，到了真正用户能操作的界面才算是一个游戏真正加载完成的时间。

那么这个时间，就得使用 Log 来记录了，因为加载游戏数据、联网更新数据、读取和更新配置文件、游戏引擎初始化这些操作，都是游戏自己的逻辑，与系统无关，所以得由游戏自己定义加载完成的点。

对于游戏的启动时间，我们更倾向于计算从点击桌面图标到用户可以与游戏进行交互这个时间段作为一个游戏的启动时间

三、冷启动

应用不在后台时第一次启动，系统和App本身都有更多的工作要从头开始！

应用在冷启动之前，要执行三个任务：

加载启动App；
App启动之后立即展示出一个空白的Window；
创建App的进程；

而这三个任务执行完毕之后会马上执行以下任务：

创建App对象；

启动Main Thread；

创建启动的Activity对象；

加载View；

布置屏幕；

进行第一次绘制；

而一旦App进程完成了第一次绘制，系统进程就会用Main Activity替换已经展示的Background Window，此时用户就可以使用App了。

总结

作为普通应用，App进程的创建等环节我们是无法主动控制的，可以优化的也就是Application、Activity创建以及回调等过程。

同样，Google也给出了启动加速的方向：

1、利用提前展示出来的Window，快速展示出来一个界面，给用户快速反馈的体验；

2、避免在启动时做密集沉重的初始化（Heavy app initialization）；

3、定位问题：避免I/O操作、反序列化、网络操作、布局嵌套等。

备注：

方向1 属于治标不治本，只是表面上快；

方向2、3可以真实的加快启动速度。

接下来我们就在项目中实际应用。