应用的启动速度对一个APP来说至关重要，会直接影响到用户体验，如果启动速度过慢会导致用户的流失，本文就启动速度优化分析，为优化启动速度提供一些思路。
1、应用启动分类
应用有三种启动状态，每种状态都会影响应用向用户显示所需的时间：冷启动、温启动和热启动。在冷启动中，应用从头开始启动。在另外两种状态中，系统需要将后台运行的应用带入前台。
1.1、冷启动
app冷启动可以分为两个阶段
第一阶段
1、加载并启动app
2、启动后立即显示一个空白的启动窗口
3、创建app进程
第二阶段
1、创建app对象
2、启动主线程
3、创建主Activity
4、加载布局
5、布置屏幕
6、首帧绘制
一旦应用进程完成首帧绘制，系统进程就会换掉当前显示的后台窗口，替换为主Activity。此时，用户可以开始使用应用
冷启动中，作为开发者，能干预的部分主要是Application的OnCreate阶段和Activity的onCreate阶段，如下图：
1.2、热启动
热启动时，系统将activity放到前台。如果应用程序的所有activity存在内存中，则应用程序可以避免重复对象初始化、渲染、绘制操作
1.3、温启动
温启动时，由于app的进程仍然存在，执行的是冷启动的第二阶段
1、创建app对象
2、启动主线程
3、创建主Activity
4、加载布局
5、布置屏幕
6、首帧绘制
温启动常见场景：
1、用户退出应用后又重启应用。进程可能继续运行。但应用从调用Activity的onCreate方法开始重新执行
2、内存不足，系统将应用杀死，然后用户重新启动。进程和Activity需要重启，但传递到onCreate的已保存的实例bundle对于完成启动有一定帮助
接下来来看下如何获得启动时间~
2、获取启动时间
2.1、使用adb命令获取
adb shell am start -W [packageName]/[packageName.xxActivity]
adb shell am start -W com.tg.test.gp/com.test.demo.MainActivity
Starting: Intent { act=android.intent.action.MAIN cat=[android.intent.category.LAUNCHER] cmp=com.tg.test.gp/com.test.demo.MainActivity }
Status: ok
LaunchState: COLD
Activity: com.tg.test.gp/com.test.demo.MainActivity
ThisTime: 1344
TotalTime: 1344
WaitTime: 1346
Complete
ThisTime: 最后一个Activity启动耗时
TotalTime: 启动时经历的所有Activity总耗时
WaitTime: AMS启动所有Activity的总时间（包括启动目标应用前的）
2.2、使用代码打点
public class LaunchTimer {
private static long sTime;
public static void startRecord() {
sTime = System.currentTimeMillis();
}
public static void endRecord() {
endRecord("");
}
public static void endRecord(String msg) {
long cost = System.currentTimeMillis() - sTime;
LogUtils.i(msg + "cost " + cost);
}
}
该方式一般为Application初始化attachBaseContext方法打启动开始时间戳，应用用户可操作界面完全展示可操作后打结束时间戳，两时间差即为启动耗时
但这种方式并不优雅，如果启动逻辑复杂，方法很多的情况下，最好采用aop进行优化。
3、应用启动优化分析工具
3.1、TraceView
Traceview是Android自带的性能分析工具，可图形化展示方法调用时间，调用栈，还可以查看所有线程信息，对分析方法耗时，调用链是非常好的工具
使用方法是采用代码埋点的方式：
1、在开始收集的位置，执行Debug.startMethodTracing("app_trace"),其中参数为自定义文件名
2、在结束收集的位置，执行Debug.endMethodTracing()
文件生成路径为/sdcard/Android/data/包名/files/文件名.trace，使用Android Studio可以打开该文件
举个例子：
我们来看下testAdd这个方法的耗时
public class MainActivity extends AppCompatActivity {
@Override
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.activity_main);
testAdd(3, 5);
}
private void testAdd(int a, int b) {
Debug.startMethodTracing("app_trace");
int c = a + b;
Log.i("Restart", "c = a + b = " + c);
Debug.stopMethodTracing();
}
}
运行程序后，找到/sdcard/Android/data/com.restart.perference/files/app_trace.trace文件，在AndroidStudio中双击它，是可以解析出文件中的信息的，打开后如下：
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-R2s1gpZz-1616421092820)(https://upload-images.jianshu.io/upload_images/25094154-7d9a059e870d906c.image?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)]
下面来看下，CallChart, FlameChart, Top Down, Bottom Up分别是怎么用的。首先要选择好时间区域，像本案例中，因为程序很简单，能分析的区域比较小，选中它后，可得到下图：
Call Chart得到的图形中，可以看到程序整个调用栈，同时可以看到方法耗时。
比如图中的testAdd方法，先后调用了Debug.startMethodTracing、Log.i、Debug.stopMethodTracing方法。同时从图中可以看出startMethodTracing方法比stopMethodTracing方法耗时长。在实际优化中，找到哪个方法耗时长，针对性优化是非常有作用的。
分析时，第三方程序，系统代码我们一般是优化不了的，CallChart非常贴心地用颜色帮我们区分哪些是我们自己写的代码。橙色的是系统API，蓝色一般是第三方API，绿色的才是我们自己写的。比如图中的testAdd方法，我们自己写的是可以通过调整优化的。
Flame Chart是Call Chart的倒序图，作用相似，图形如下：
Top Down可以看到每个方法内部调用了哪些方法，以及每个方法的耗时，耗时占比，相比于Call Chart的图形查找，Top Down则是更具体，有具体的方法耗时数据
图中的Total代表方法总共的耗时，self代表方法内非方法调用的代码耗时，Children代表方法内调用的其他方法的耗时。
同样以testAdd方法为例，testAdd方法总耗时为3840us，占程序运行时间97%，testAdd方法中自身代码耗时为342us，占比为8.65%，testAdd方法中调用的其他方法总共耗时3498us，占比88.52%
private void testAdd(int a, int b) {
Debug.startMethodTracing("app_trace");//算到Children中
int c = a + b;//这一句是算在self耗时中，耗时其实很短
Log.i("Restart", "c = a + b = " + c);//算到Children中
Debug.stopMethodTracing();//算到Children中
}
Bottom Up是Top Down的倒序图，可以看方法是被哪个方法调用的
TraceView中还有个选项值得注意，
在右上角有个Wall Clock Time和Thread Time的选项，其中Wall Clock Time的意思是方法执行的实际耗时，而Thread Time指的是CPU耗时。我们平时说的优化更多的是优化CPU时间，当有IO操作时，用Thread Time来分析耗时更合理
此外，使用TraceView需要关注TraceView的运行时开销，因为它自身耗时较长，就有可能会带偏我们的优化方向。
3.2、Systrace
Systrace结合Android内核的数据，生成HTML报告
systrace在Android/sdk/platform-tools/systrace目录中。使用前需要安装python，因为systrace是用python生成html
报告的，命令如下：
python systrace.py -b 32768 -t 10 -a 包名 -o perference.html sched gfx view wm am app
具体参数可参考：developer.android.google.cn/studio/prof…
执行命令后，打开报告,显示如下
要使用chrome浏览器打开，否则可能会显示白屏。如果使用chrome也显示白屏，可在chrome浏览器中输入chrome:tracing, 再Load文件进去显示
查看图时，A键是左移，D键右移， S键缩小，W键放大
4、常用优化
4.1、启动加载常见优化策略
一个应用越大，涉及模块越多，包含的服务甚至进程就会越多，如网络模块的初始化，底层数据初始化等，这些加载都需要提前准备好，有些不必要的就不要放到应用中。通常可以从以下四个维度整理启动的各个点：
1、必要且耗时：启动初始化，考虑用线程来初始化
2、必要不耗时：不用处理
3、非必要耗时，数据上报、插件初始化，按需处理
4、非必要不耗时：直接去掉，有需要的时候再加载
将应用启动时要执行的内容按上述分类，按需实现加载逻辑。那么常见的优化加载策略有哪些呢？
异步加载：耗时多的加载放到子线程中异步执行
延迟加载: 非必须的数据延迟加载
提前加载：利用ContentProvider提前进行初始化
下面分别介绍异步加载和延迟加载的一些常用处理
4.2、异步加载
异步加载，简单来说，就是使用子线程异步加载。在实际场景中，启动时常常需要对各种第三方库做初始化操作。通过将初始化放到子线程中进行，可以大大加快启动。
但是通常，有些业务逻辑是要再第三方库的初始化后才能正常运行的，这时候如果只是简单的放到子线程中跑，不做限制就很可能出现在没初始化完成就跑业务逻辑，导致异常。
这种较为复杂的情况下，可以采用CountDownLatch处理，或者是使用启动器的思想处理。
CountDownLatch使用
class MyApplication extends Application {
// 线程等待锁
private CountDownLatch mCountDownLatch = new CountDownLatch(1);
// CPU核数
private static final int CPU_COUNT = Runtime.getRuntime().availableProcessors();
// 核心线程数
private static final int CORE_POOL_SIZE = Math.max(2, Math.min(CPU_COUNT - 1, 4));
void onCreate() {
ExecutorService service = Executors.newFixedThreadPool(CORE_POOL_SIZE);
service.submit(new Runnable() {
@Override public void run() {
//初始化weex，因为Activity加载布局要用到需要提前初始化完成
initWeex();
mCountDownLatch.countDown();
}
});
service.submit(new Runnable() {
@Override public void run() {
//初始化Bugly,无需关心是否在界面绘制前初始化完
initBugly();
}
});
//提交其他库初始化，此处省略。。。
try {
//等待weex初始化完才走完onCreate
mCountDownLatch.await();
} catch (Exception e) {
e.printStackTrace();
}
}
}
使用CountDownLatch在初始化的逻辑不复杂的情况下推荐使用。但如果初始化的几个库之间又有相互依赖，逻辑复杂的情况下，则推荐使用加载器的方式。
启动器
启动器的核心如下：
- 充分利用CPU多核能力，自动梳理并顺序执行任务；
- 代码Task化，将启动任务抽象成各个task；
- 根据所有任务依赖关系排序生成一个有向无环图；
- 多线程按照线程优先级顺序执行
具体实现可参考：github.com/NoEndToLF/A…
4.3、延迟加载
有些第三方库的初始化其实优先级并不高，可以按需加载。或者是利用IdleHandler在主线程空闲的时候进行分批初始化。
按需加载可根据具体情况实现，这里不做赘述。这里介绍下使用IdleHandler的使用
private MessageQueue.IdleHandler mIdleHandler = new MessageQueue.IdleHandler() {
@Override
public boolean queueIdle() {
//当return true时，会移除掉该IdleHandler，不再回调，当为false，则下次主线程空闲时会再次回调
return false;
}
};
使用IdleHandler做分批初始化，为什么要分批？当主线程空闲时，执行IdleHandler，但如果IdleHandler内容太多，则还是会导致卡顿。因此最好是将初始化操作分批在主线程空闲时进行
public class DelayInitDispatcher {
private Queue<Task> mDelayTasks = new LinkedList<>();
private MessageQueue.IdleHandler mIdleHandler = new MessageQueue.IdleHandler() {
@Override
public boolean queueIdle() {
//每次执行一个Task，实现分批进行
if(mDelayTasks.size()>0){
Task task = mDelayTasks.poll();
new DispatchRunnable(task).run();
}
//当为空时，返回false，移除IdleHandler
return !mDelayTasks.isEmpty();
}
};
//添加初始化任务
public DelayInitDispatcher addTask(Task task){
mDelayTasks.add(task);
return this;
}
//给主线程添加IdleHandler
public void start(){
Looper.myQueue().addIdleHandler(mIdleHandler);
}
}
4.4、提前加载
上述方案中初始化最快的时机都是在Application的onCreate中进行，但还有更早的方式。ContentProvider的onCreate是在Application的attachBaseContext和onCreate方法中间进行的。也就是说它比Application的onCreate方法更早执行。所以可以利用这点来对第三方库的初始化进行提前加载。
androidx-startup使用
如何使用：
第一步，写一个类实现Initializer,泛型为返回的实例，如果不需要的话，就写Unit
class TimberInitializer : Initializer<Unit> {
//这里写初始化执行的内容，并返回初始化实例
override fun create(context: Context) {
if (BuildConfig.DEBUG) {
Timber.plant(Timber.DebugTree())
Timber.d("TimberInitializer is initialized.")
}
}
//这里写初始化的东西依赖的另外的初始化器，没有的时候返回空List
override fun dependencies(): List<Class<out Initializer<*>>> {
return emptyList()
}
}
第二步，在AndroidManifest中声明provider，并配置meta-data写初始化的类
<provider
android:name="androidx.startup.InitializationProvider"
android:authorities="com.test.pokedex.androidx-startup"
android:exported=“false"
//这里写merge是因为其他模块可能也有同样的provider声明，做合并操作
tools:node="merge">
//当有相互依赖的情况下，写顶层的初始化器就可以，其依赖的会自动搜索到
<meta-data
android:name="com.test.pokedex.initializer.TimberInitializer"
android:value="androidx.startup" />
</provider>
4.5、其他优化
1、在应用中，增加启动默认图或者自定义一个Theme，在Activity首先使用一个默认的界面解决部分启动短暂黑白屏问题。如android:theme="@style/Theme.AppStartLoad"
5、小结
1、冷启动、温启动、热启动主要进行的处理及他们的区别
2、如何获取启动时间，介绍了使用adb命令和代码打点这两种方式
3、如何使用工具找到程序中耗时较长的代码，介绍TraceView和Systrace的使用
4、常见的启动优化方式及实现介绍（异步加载，延迟加载，提前加载等），关键思想：异步、延迟、懒加载