前言
网上关于启动优化的文章多不胜数，内容千篇一律，大都是列举一些耗时操作，采用异步加载、懒加载等。
而在面试过程中，关于启动优化的问题，如果只是很表面地回答耗时操作应该放在子线程，显然太过于普通，无法跟竞争者拉开差距。如何让面试官知道你的“内功深厚”，那肯定是要往原理层面去回答。
应用启动流程优化内容
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都采用了这种方法，非常简单，是一个障眼法，不会缩短实际冷启动时间，简单贴下实现方式吧。
android:name=".MainApplication" ... android:theme="@style/AppThemeWelcome> styles.xml 增加一个主题叫AppThemeWelcome 闪屏页设置这个主题，或者全局给Application设置 android:configChanges="orientation|screenSize|keyboardHidden" android:theme="@style/AppThemeWelcome" android:screenOrientation="portrait"> 这样的话启动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"); } }