启动优化的目的
APP启动如果得到很好的优化，增强用户体验增加用户流量；如果app启动时间过长影响用户体验，从而会造成流失用户。所以做启动优化是有必须的。
谷歌官方针对以下三种启动方式做了详细的介绍，具体可以参考https://developer.android.com/topic/performance/vitals/launch-time。从官网得知APP启动所需的时间为：冷启动时间>温启动时间>热启动时间
启动分三种:
-
冷启动
当应用在设备开机或者系统主动 kill APP 进程之后，用户点击桌面icon图标启动，称之为冷启动。
-
温启动
温启动是APP进程还存活，因为内存不足Activity被回收了，当再次启动APP时就会重新执行Activity生命周期，布局绘制等操作。
-
热启动
当后台存在该应用的进程或者服务时，用户点击icon图标启动，称之为热启动。一般是用户按了home键回到桌面，或者返回键没有杀进程，或者app本身做了进程重启的机制。
冷启动
冷启动的的过程：
- 加载和启动APP
- 显示一个白色的Window窗口
- 创建APP进程
- 创建Application
- 创建MainActivity
- 加载布局
- 首帧绘制
应用的启动过程
冷启动启动流程——当点击app的启动图标时，安卓系统会从Zygote进程中fork创建出一个新的进程分配给该应用，之后会依次创建和初始化Application类（attachBaseContext()–>OnCreate()）、创建MainActivity类、加载主题样式Theme中的 windowBackground等属性设置给MainActivity以及配置Activity层级上的一些属性、再inflate布局、当onCreate/onStart/onResume方法都走完了，最后才进行contentView的measure/layout/draw显示在界面上，所以直到这里，应用的第一次启动才算完成，这时候看到的界面也就是首帧。
大致流程如下：
- 点击桌面图标，Launcher会启动程序默认的Acticity，之后再按照程序的逻辑启动各种Activity。
- 启动Activity通过应用程序框架层的ActivityManagerService服务启动(Service也是由ActivityManagerService来启动的)。ActivityManagerService是一个非常重要的接口，它负责启动和管理Activity和Service。
1. 无论是通过Launcher来启动Activity，还是通过Activity内部调用startActivity接口来启动新的Activity，都通过Binder进程间通信进入到ActivityManagerService进程中，并且调用ActivityManagerService.startActivity接口。
2. ActivityManagerService调用ActivityStack.startActivityMayWait来做准备要启动的Activity的相关信息。
3. ActivityStack通知ApplicationThread要进行Activity启动调度了，这里的ApplicationThread代表的是调用ActivityManagerService.startActivity接口的进程，对于通过点击应用程序图标的情景来说，这个进程就是Launcher了，而对于通过在Activity内部调用startActivity的情景来说，这个进程就是这个Activity所在的进程了。
4. ApplicationThread不执行真正的启动操作，它通过调用ActivityManagerService.activityPaused接口进入到ActivityManagerService进程中，看看是否需要创建新的进程来启动Activity。
5. 对于通过点击应用程序图标来启动Activity的情景来说，ActivityManagerService在这一步中，会调用startProcessLocked来创建一个新的进程，而对于通过在Activity内部调用startActivity来启动新的Activity来说，这一步是不需要执行的，因为新的Activity就在原来的Activity所在的进程中进行启动。
6. ActivityManagerServic调用ApplicationThread.scheduleLaunchActivity接口，通知相应的进程执行启动Activity的操作。
7. ApplicationThread把这个启动Activity的操作转发给ActivityThread，ActivityThread通过ClassLoader导入相应的Activity类，然后把它启动起来。
所以相应的优化方案
- 减少 onCreate方法的工作量。
- 不要让Application参与业务逻辑。
- 不要在Application中做耗时操作，一些初始化操作可以开启子线程来完成。
- 不要以静态变量方式在Application中保存数据。
- 布局优化/mainThread尽量延迟初始化。
- 启动画面的初始化可以使用设置主题背景的方式，速度回更快。
启动主题优化
冷启动阶段:
- 加载并启动应用程序。
- 启动后立即显示应用程序空白的启动窗口。
- 创建应用程序进程。
启动主题优化，就是应用程序在冷启动的时候(1~2阶段)，设置启动窗口的主题。因为现在 App 应用启动都会先进入一个闪屏页(LaunchActivity) 来展示应用信息。
默认主题情况
如果我们对App没有做处理(设置了默认主题)，并且在 Application 的onCreate()初始化了其它第三方的服务(假设需要加载2000ms)，那么系统默认会在启动应用程序的时候启动空白窗口 （产生一个白屏），直到 App 应用程序的入口 Activity 创建成功，视图绘制完毕。( 大概是onWindowFocusChanged方法回调的时候 )
解决白屏或黑屏问题
在默认主题的情况下并且Application初始化服务耗时过长就会出现白屏。如果出现白屏或黑屏闪现，查看设置Style的Theme。
透明主题优化
<style name="AppTheme2" parent="Theme.AppCompat.Light.DarkActionBar">
......
<item name="android:windowIsTranslucent">true</item>
<item name="android:windowNoTitle">true</item>
</style>
为了解决启动窗口白屏问题，许多开发者都是使用透明主题来解决这个问题，但是治标不治本。虽然解决了上面这个问题，但是仍然有些不足。已经测试虽然无白屏了，不过从点击到App仍然存在视觉延迟。
设置闪屏图片主题
<style name="AppTheme1" parent="Theme.AppCompat.Light.DarkActionBar">
<item name="android:windowBackground">@drawable/icon_bg</item>//闪屏页图片
<item name="android:windowFullscreen">true</item>
<item name="android:windowContentOverlay">@null</item>
</style>
为了更顺滑无缝衔接闪屏页，可以在启动 Activity 的 Theme中设置闪屏页图片（如上面代码），这样启动窗口的图片就会是闪屏页图片，而不是白屏。这样设置的话，就会在冷启动的时候，展示闪屏页的图片，等App进程初始化加载入口 Activity (也是闪屏页) 就可以无缝衔接。其实这种方式并没有真正的加速应用进程的启动速度，而只是通过用户视觉效果带来的优化体验。
代码优化
当然上面使用设置主题的方式优化用户体验效果治标不治本，关键还在于对代码的优化。首先我们可以统计一下应用冷启动的时间。
启动耗时的测量方式
- 通过adb 命令统计启动耗时时间
- 手动埋点计算时间差
adb 命令统计
adb命令 : adb shell am start -S -W 包名/启动类的全限定名 ， -S 表示重启当前应用
更多的ADB命令
G:\AS_Project_Work\Demo>adb shell am start -S -W com.lu.demo/com.lu.demo.MainActivity
Stopping: com.lu.demo
Starting: Intent { act=android.intent.action.MAIN cat=[android.intent.category.LAUNCHER] cmp=com.lu.demo/.MainActivity }
Status: ok
Activity: com.lu.demo/.MainActivity
ThisTime: 508
TotalTime: 508
WaitTime: 586
Complete
ThisTime : 最后一个 Activity 的启动耗时(例如从 LaunchActivity - >MainActivity「adb命令输入的Activity」 , 只统计 MainActivity 的启动耗时)。
TotalTime : 启动一连串的 Activity 总耗时.(有几个Activity 就统计几个)。
WaitTime : 应用进程的创建过程 + TotalTime 。
ThisTime<=TotalTime<=WaitTime
这时应用就启动了(注意：此时是冷启动)，当我点击home将应用切到后台之后，再次执行adb shell am start -W 包名/启动类的全限定名的命令，这时可以发现，这三个时间都缩短了，而且提示Warning: Activity not started, its current task has been brought to the front表示当前启动是一个热启动。
G:\AS_Project_Work\Demo>adb shell am start -W com.lu.demo/com.lu.demo.MainActivity
Stopping: com.lu.demo
Starting: Intent { act=android.intent.action.MAIN cat=[android.intent.category.LAUNCHER] cmp=com.lu.demo/.MainActivity }
Warning: Activity not started, its current task has been brought to the front
Status: ok
Activity: com.lu.demo/.MainActivity
ThisTime: 508
TotalTime: 508
WaitTime: 586
Complete
手动埋点计算时间差
手动埋点在什么时机开始计算时间，什么时候结束计算时间？一般会在 Application attachBaseContext 中开始埋点计算开始时间，然后在 Activity 中第一个 View 中preDraw 时结束埋点计算结束时间，两者之差就是启动耗时时间。从上面的启动过程得知，一般会在 Application attachBaseContext 中开始埋点计算开始时间，然后在启动MainActivity 中第一个 View 中preDraw 时结束埋点计算结束时间。参照启动过程下面开始代码实现：
//Application.java
@Override
protected void attachBaseContext(Context base) {
super.attachBaseContext(base);
//开始计算启动时间（埋点）
LaunchTime.startRecord();
}
//MainActivity.java
TextView text = findViewById(R.id.text);
text.getViewTreeObserver().addOnPreDrawListener(new ViewTreeObserver.OnPreDrawListener() {
@Override
public boolean onPreDraw() {
// 结束计算启动时间(埋点)
LaunchTime.stopRecord("TextView preDraw");
return true;
}
});
//LaunchTime.java
public class LaunchTime {
private static final String TAG = LaunchTime.class.getSimpleName();
private static long startTime = 0;
//开始记录计时
public static void startRecord() {
startTime = System.currentTimeMillis();
}
//停止计时 打印出时间差
public static void stopRecord(String tag) {
//打印日志
Log.e(TAG, tag + "CostTime:" + (System.currentTimeMillis() - startTime));
}
}
//打印日志
06-1267 21:38:37.230 1701-1701/? E/LaunchTime: TextView preDrawCostTime:398
手动计算启动耗时时间是比较精确的方式，可以带到线上使用，不过需要注意结束埋点的时机，这个时机也可以选择 addOnDrawListener 但是这个是在API16以上才能使用。
总结
- 记录启动优化日后好复习。
- 了解APP启动过程，更好设置优化方案。
- 了解主题启动优化方案处理白屏黑屏闪现等问题。
- 代码优化及启动耗时测量方式，方案选择。
