前言
网上关于启动优化的文章多不胜数，内容千篇一律，大都是列举一些耗时操作，采用异步加载、懒加载等。
而在面试过程中，关于启动优化的问题，如果只是很表面地回答耗时操作应该放在子线程，显然太过于普通，无法跟竞争者拉开差距。如何让面试官知道你的“内功深厚”，那肯定是要往原理层面去回答。
应用启动流程优化内容
1.闪屏页优化
2.MultiDex 原理分析
3.ClassLoader 加载一个类的流程分析
4.热修复原理
5.MultiDex优化：
本文重点还是关注原理，冷启动优化这个问题能延伸到很多原理层面的知识点，本文比较有意思的地方是通过反编译今日头条App，研究大厂的启动优化方案。
介绍了两种方式，一种是直接在闪屏页开个子线程去加载dex，难维护，不推荐；一种是今日头条的方案，在单独一个进程加载dex，加载完主进程再继续。
快速启动Activity的方式：预创建Activity，预加载数据。
启动时间监控的方式：Systrace+插桩、BlockCanary。
讲启动优化之前，先看下应用的启动流程
一、应用启动流程
应用进程不存在的情况下，从点击桌面应用图标，到应用启动（冷启动），大概会经历以下流程：
Launcher startActivity
AMS startActivity
Zygote fork 进程
ActivityThread main()
4.1. ActivityThread attach
4.2. handleBindApplication
4.3attachBaseContext
4.4. installContentProviders
4.5.Application onCreate
ActivityThread 进入loop循环
Activity生命周期回调，onCreate、onStart、onResume...
整个启动流程我们能干预的主要是 4.3、4.5 和6，应用启动优化主要从这三个地方入手。理想状况下，这三个地方如果不做任何耗时操作，那么应用启动速度就是最快的，但是现实很骨感，很多开源库接入第一步一般都是在Application onCreate方法初始化，有的甚至直接内置ContentProvider，直接在ContentProvider中初始化框架，不给你优化的机会。
二、启动优化
直奔主题，常见的启动优化方式大概有这些：
闪屏页优化
MultipDex优化（本文重点）
第三方库懒加载
WebView优化
线程优化
系统调用优化
2.1 闪屏页优化
消除启动时的白屏/黑屏，市面上大部分App都采用了这种方法，非常简单，是一个障眼法，不会缩短实际冷启动时间，简单贴下实现方式吧。
<application
android:name=".MainApplication"
...
android:theme="@style/AppThemeWelcome>
styles.xml 增加一个主题叫AppThemeWelcome
<style name="AppThemeWelcome" parent="Theme.AppCompat.NoActionBar">
...
<item name="android:windowBackground">@drawable/logo</item> <!-- 默认背景-->
</style>
闪屏页设置这个主题，或者全局给Application设置
<activity android:name=".ui.activity.DemoSplashActivity"
android:configChanges="orientation|screenSize|keyboardHidden"
android:theme="@style/AppThemeWelcome"
android:screenOrientation="portrait">
<intent-filter>
<action android:name="android.intent.action.MAIN" />
<category android:name="android.intent.category.LAUNCHER" />
</intent-filter>
</activity>
这样的话启动Activity之后背景会一直在，所以在Activity的onCreate方法中切换成正常主题
protected void onCreate(@Nullable Bundle savedInstanceState) {
setTheme(R.style.AppTheme); //切换正常主题
super.onCreate(savedInstanceState);
这样打开桌面图标会马上显示logo，不会出现黑/白屏，直到Activity启动完成，替换主题，logo消失，但是总的启动时间并没有改变。
2.2 MultiDex 优化（本文重点）
说MultiDex之前，先梳理下apk编译流程
2.2.1 apk编译流程
Android Studio 按下编译按钮后发生了什么？
打包资源文件，生成R.java文件（使用工具AAPT）
处理AIDL文件，生成java代码（没有AIDL则忽略）
编译 java 文件，生成对应.class文件（java compiler）
.class 文件转换成dex文件（dex）
打包成没有签名的apk（使用工具apkbuilder）
使用签名工具给apk签名（使用工具Jarsigner）
对签名后的.apk文件进行对齐处理，不进行对齐处理不能发布到Google Market（使用工具zipalign）
在第4步，将class文件转换成dex文件，默认只会生成一个dex文件，单个dex文件中的方法数不能超过65536，不然编译会报错：
Unable to execute dex: method ID not in [0, 0xffff]: 65536
App集成一堆库之后，方法数一般都是超过65536的，解决办法就是：一个dex装不下，用多个dex来装，gradle增加一行配置即可。
multiDexEnabled true
这样解决了编译问题，在5.0以上手机运行正常，但是5.0以下手机运行直接crash，报错 Class NotFound xxx。
Android 5.0以下，ClassLoader加载类的时候只会从class.dex（主dex）里加载，ClassLoader不认识其它的class2.dex、class3.dex、...，当访问到不在主dex中的类的时候，就会报错:Class NotFound xxx，因此谷歌给出兼容方案，MultiDex。
2.2.2 MultiDex 原来这么耗时
在Android 4.4的机器打印MultiDex.install(context)耗时如下：
MultiDex.install 耗时：1320复制代码
平均耗时1秒以上，目前大部分应用应该还是会兼容5.0以下手机，那么MultiDex优化是冷启动优化的大头。
为什么MultiDex会这么耗时？老规矩，分析一下MultiDex原理~
2.2.3 MultiDex 原理
public static void install(Context context) {
Log.i("MultiDex", "Installing application");
if (IS_VM_MULTIDEX_CAPABLE) { //5.0 以上VM基本支持多dex，啥事都不用干
Log.i("MultiDex", "VM has multidex support, MultiDex support library is disabled.");
} else if (VERSION.SDK_INT < 4) { //
throw new RuntimeException("MultiDex installation failed. SDK " + VERSION.SDK_INT + " is unsupported. Min SDK version is " + 4 + ".");
} else {
...
doInstallation(context, new File(applicationInfo.sourceDir), new File(applicationInfo.dataDir), "secondary-dexes", "", true);
...
Log.i("MultiDex", "install done");
}
}
