网上关于启动优化的文章多不胜数，内容千篇一律，大都是列举一些耗时操作，采用异步加载、懒加载等。
而在面试过程中，关于启动优化的问题，如果只是很表面地回答耗时操作应该放在子线程，显然太过于普通，无法跟竞争者拉开差距。如何让面试官知道你的“内功深厚”，那肯定是要往原理层面去回答。
本文重点还是关注原理，冷启动优化这个问题能延伸到很多原理层面的知识点，本文比较有意思的地方是通过反编译今日头条App，研究大厂的启动优化方案。
讲启动优化之前，先看下应用的启动流程
应用进程不存在的情况下，从点击桌面应用图标，到应用启动（冷启动），大概会经历以下流程：
Launcher startActivity
AMS startActivity
Zygote fork 进程
ActivityThread main()
4.1. ActivityThread attach
4.2. handleBindApplication
4.3 attachBaseContext
4.4. installContentProviders
4.5. Application onCreate
ActivityThread 进入loop循环
Activity生命周期回调，onCreate、onStart、onResume...
整个启动流程我们能干预的主要是 4.3、4.5 和6，应用启动优化主要从这三个地方入手。理想状况下，这三个地方如果不做任何耗时操作，那么应用启动速度就是最快的，但是现实很骨感，很多开源库接入第一步一般都是在Application onCreate方法初始化，有的甚至直接内置ContentProvider，直接在ContentProvider中初始化框架，不给你优化的机会。
直奔主题，常见的启动优化方式大概有这些：
闪屏页优化
MultipDex优化（本文重点）
第三方库懒加载
WebView优化
线程优化
系统调用优化
消除启动时的白屏/黑屏，市面上大部分App都采用了这种方法，非常简单，是一个障眼法，不会缩短实际冷启动时间，简单贴下实现方式吧。
styles.xml 增加一个主题叫AppThemeWelcome
闪屏页设置这个主题，或者全局给Application设置
这样的话启动Activity之后背景会一直在，所以在Activity的onCreate方法中切换成正常主题
这样打开桌面图标会马上显示logo，不会出现黑/白屏，直到Activity启动完成，替换主题，logo消失，但是总的启动时间并没有改变。
说之前，先梳理下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，因此谷歌给出兼容方案，。
2.2.2 MultiDex 原来这么耗时
在Android 4.4的机器打印耗时如下：
平均耗时1秒以上，目前大部分应用应该还是会兼容5.0以下手机，那么MultiDex优化是冷启动优化的大头。
为什么会这么耗时？老规矩，分析一下MultiDex原理~
2.2.3 MultiDex 原理
下面看下的install 方法做了什么事
从入口的判断来看，如果虚拟机本身就支持加载多个dex文件，那就啥都不用做；如果是不支持加载多个dex（5.0以下是不支持的），则走到 方法。
先看注释1，
查找dex文件，有两个逻辑，有缓存就调用方法，没有缓存或者缓存读取失败就调用方法，然后再缓存起来。使用到缓存，那么 方法想必应该是很耗时的，分析一下代码：
这里的逻辑就是解压apk，遍历出里面的dex文件，例如class1.dex，class2.dex，然后又压缩成class1.zip，class2.zip...，然后返回zip文件列表。
思考为什么这里要压缩呢？ 后面涉及到ClassLoader加载类原理的时候会分析ClassLoader支持的文件格式。
第一次加载才会执行解压和压缩过程，第二次进来读取sp中保存的dex信息，直接返回file list，所以第一次启动的时候比较耗时。
dex文件列表找到了，回到上面方法的注释2，找到的dex文件列表，然后调用方法进行安装，怎么安装呢？方法点进去看SDK 19 以上的实现
反射ClassLoader 的 pathList 字段
找到pathList 字段对应的类的 方法
通过 这个方法扩展 数组，怎么扩展？看下代码：
就是创建一个新的数组，把原来数组内容（主dex）和要增加的内容（dex2、dex3...）拷贝进去，反射替换原来的为新的数组，如下图
?
?
看起来有点眼熟，Tinker热修复的原理也是通过反射将修复后的dex添加到这个dex数组去，不同的是热修复是添加到数组最前面，而MultiDex是添加到数组后面。这样讲可能还不是很好理解？来看看ClassLoader怎么加载一个类的就明白了~
2.2.4 ClassLoader 加载类原理
不管是 还是，都继承自，加载类的代码在 中
4.4 源码
/dalvik/src/main/java/dalvik/system/BaseDexClassLoader.java
?
?
构造方法通过传入dex路径，创建了。
ClassLoader的findClass方法最终是调用DexPathList 的findClass方法
接着看源码 /dalvik/src/main/java/dalvik/system/DexPathList.java
?
里面定义了一个 数组，方法中用到，看下
?
findClass方法逻辑很简单，就是遍历dexElements 数组，拿到里面的DexFile对象，通过DexFile的loadClassBinaryName方法加载一个类。
?
最终创建Class是通过native方法，就不追下去了，大家有兴趣可以看下native层是怎么创建Class对象的。DexFile.cpp
那么问题来了，5.0以下这个dexElements 里面只有主dex（可以认为是一个bug），没有dex2、dex3...，MultiDex是怎么把dex2添加进去呢? 答案就是反射的字段，然后把我们的dex2添加进去，当然，dexElements里面放的是Element对象，我们只有dex2的路径，必须转换成Element格式才行，所以反射DexPathList里面的makeDexElements 方法，将dex文件转换成Element对象即可。
?
?
?
dex2、dex3...通过方法转换成要新增的Element数组，最后一步就是反射DexPathList的dexElements字段，将原来的Element数组和新增的Element数组合并，然后反射赋值给dexElements变量，最后DexPathList的dexElements变量就包含我们新加的dex在里面了。
方法会判断file类型，上面讲dex提取的时候解压apk得到dex，然后又将dex压缩成zip，压缩成zip，就会走到第二个判断里去。仔细想想，其实dex不压缩成zip，走第一个判断也没啥问题吧，那谷歌的MultiDex为什么要将dex压缩成zip呢？在Android开发高手课中看到张绍文也提到这一点
?
?
然后我在反编译头条App的时候，发现头条参考谷歌的MultiDex，自己写了一套，猜想可能是优化这个多余的压缩过程，头条的方案下面会介绍。
2.2.5 原理小结
ClassLoader 加载类原理：
ClassLoader.loadClass -> DexPathList.loadClass -> 遍历dexElements数组 ->DexFile.loadClassBinaryName
通俗点说就是：ClassLoader加载类的时候是通过遍历dex数组，从dex文件里面去加载一个类，加载成功就返回，加载失败则抛出Class Not Found 异常。
MultiDex原理：
在明白ClassLoader加载类原理之后，我们可以通过反射dexElements数组，将新增的dex添加到数组后面，这样就保证ClassLoader加载类的时候可以从新增的dex中加载到目标类，经过分析后最终MultipDex原理图如下：
2.2.6 MultiDex 优化（两种方案）
知道了MultiDex原理之后，可以理解install过程为什么耗时，因为涉及到解压apk取出dex、压缩dex、将dex文件通过反射转换成DexFile对象、反射替换数组。
那么MultiDex到底应该怎么优化呢，放子线程可行吗？
方案1：子线程install（不推荐）
这个方法大家很容易就能想到，在闪屏页开一个子线程去执行，然后加载完才跳转到主页。需要注意的是闪屏页的Activity，包括闪屏页中引用到的其它类必须在主dex中，不然在之前加载这些不在主dex中的类会报错Class Not Found。这个可以通过gradle配置，如下：
maindexlist.txt 文件指定哪些类要打包到主dex中，内容格式如下
在已有项目中用这种方式，一顿操作猛如虎之后，编译运行在4.4的机器上，启动闪屏页，加载完准备进入主页直接崩掉了。
?
报错，一般都是该类没有在主dex中，要在maindexlist.txt 将配置指定在主dex。 **第三方库中的ContentProvider必须指定在主dex中，否则也会找不到，为什么？**文章开头说过应用的启动流程，ContentProvider 初始化时机如下图：
?
?
?
ContentProvider初始化太早了，如果不在主dex中，还没启动闪屏页就已经crash了。
所以这种方案的缺点很明显：
MultiDex加载逻辑放在闪屏页的话，闪屏页中引用到的类都要配置在主dex。
ContentProvider必须在主dex，一些第三方库自带ContentProvider，维护比较麻烦，要一个一个配置。
这时候就思考一下，有没有其它更好的方案呢？大厂是怎么做的？今日头条肯定要对MultiDex进行优化吧，反编译瞧瞧？
?
?
?
点了一根烟之后，开始偷代码...
MultiDex优化方案2：今日头条方案
今日头条没有加固，反编译后很容易通过关键字搜索找到这个类，
?
?
?
看注释1的这个方法，代码虽然混淆了，但是方法内部的代码还是可以看出是干嘛的，继续跟这个方法，为了不影响阅读，我对混淆做了一些处理，改成正常的方法名。
?
?
每个方法开头都有这个if判断，这个是美团Robust热修复生成的代码，今日头条没有自己的热修复框架，没有用Tinker，而是用美团的，想了解关于Robust细节可以参考文末链接。Robust直接跳过，看else代码块即可。
?
继续看方法
?
逻辑如下：
1. 创建临时文件，作为判断MultiDex是否加载完的条件
2. 启动LoadDexActivity去加载MultiDex（LoadDexActivity在单独进程），加载完会删除临时文件
3. 开启while循环，直到临时文件不存在才跳出循环，进入Application的onCreate
创建临时文件代码
?
while循环代码
LoadDexActivity 只有一个加载框，加载完再跳转到闪屏页
?
dex加载完应该要finish掉当前Activity
?
按照上面代码分析，今日头条在5.0以下手机首次启动应该是这样：
打开桌面图标
显示默认背景
跳转到加载dex的界面，展示一个loading的加载框几秒钟
跳转到闪屏页
实际上是不是这样呢，用4.4机器试下？
?
?
看起来完全跟猜想的一致，撸几行代码验证应该不难吧？
?
?
点了一根烟之后，开始撸代码，最终实现效果如下
?
?
效果跟今日头条是一致的，不再重复分析代码了，源码上传到github，感兴趣的同学可以参考参考，头条的方案，值得尝试~ github.com/lanshifu/Mu…
再次梳理一下这种方式：
在主进程Application 的 attachBaseContext 方法中判断如果需要使用MultiDex，则创建一个临时文件，然后开一个进程（LoadDexActivity），显示Loading，异步执行MultiDex.install 逻辑，执行完就删除临时文件并finish自己。
主进程Application 的 attachBaseContext 进入while代码块，定时轮循临时文件是否被删除，如果被删除，说明MultiDex已经执行完，则跳出循环，继续正常的应用启动流程。
注意LoadDexActivity 必须要配置在main dex中。
有些同学可能会问，启动还是很久啊，冷启动时间有变化吗？ 冷启动时间是指点击桌面图标到第一个Activity显示这段时间。
MultiDex优化总结
方案1：直接在闪屏页开个子线程去执行MultiDex逻辑，MultiDex不影响冷启动速度，但是难维护。
方案2：今日头条的MultiDex优化方案：
在Application 的attachBaseContext 方法里，启动另一个进程的LoadDexActivity去异步执行MultiDex逻辑，显示Loading。
然后主进程Application进入while循环，不断检测MultiDex操作是否完成
MultiDex执行完之后主进程Application继续走，ContentProvider初始化和Application onCreate方法，也就是执行主进程正常的逻辑。
其实应该还有方案3，因为我发现头条并没有直接使用Google的MultiDex，而是参考谷歌的MultiDex，自己写了一套，耗时应该会少一些，大家有兴趣可以去研究一下。
?
?
?
这段代码是今日头条里面的，Activity对象预先new出来，
对象第一次创建的时候，java虚拟机首先检查类对应的Class 对象是否已经加载。如果没有加载，jvm会根据类名查找.class文件，将其Class对象载入。同一个类第二次new的时候就不需要加载类对象，而是直接实例化，创建时间就缩短了。
头条真是把启动优化做到极致。
很多第三方开源库都说在Application中进行初始化，十几个开源库都放在Application中，肯定对冷启动会有影响，所以可以考虑按需初始化，例如Glide，可以放在自己封装的图片加载类中，调用到再初始化，其它库也是同理，让Application变得更轻。
WebView启动优化文章也比较多，这里只说一下大概优化思路。
WebView第一次创建比较耗时，可以预先创建WebView，提前将其内核初始化。
使用WebView缓存池，用到WebView的地方都从缓存池取，缓存池中没有缓存再创建，注意内存泄漏问题。
本地预置html和css，WebView创建的时候先预加载本地html，之后通过js脚本填充内容部分。
这一部分可以参考： mp.weixin.qq.com/s/KwvWURD5W…
这种方式一般是在主页空闲的时候，将其它页面的数据加载好，保存到内存或数据库，等到打开该页面的时候，判断已经预加载过，直接从内存或数据库读取数据并显示。
线程是程序运行的基本单位，线程的频繁创建是耗性能的，所以大家应该都会用线程池。单个cpu情况下，即使是开多个线程，同时也只有一个线程可以工作，所以线程池的大小要根据cpu个数来确定。
启动优化方式就先介绍到这里，常见的就是这些，其它的可以作为补充。
性能损耗太大，得到的结果不真实。 可以方便追踪关键系统调用的耗时情况，如 Choreographer，但是不支持应用程序代码的耗时分析。
结合 和 ，就是将如下代码插入到每个方法的入口和出口
插桩后的代码如下
插桩工具参考： github.com/AndroidAdva…
mac下systrace路径在
/Users/{xxx}/Library/Android/sdk/platform-tools/systrace/
编译运行app，执行命令
python2 /Users/lanshifu/Library/Android/sdk/platform-tools/systrace/systrace.py gfx view wm am pm ss dalvik app sched -b 90960 -a com.sample.systrace -o test.log.html
?
最后按下Enter停止捕获trace信息，在目录下生成报告test.log.html，直接可以用谷歌浏览器打开查看。
BlockCanary 可以监听主线程耗时的方法，将阈值设置低一点，比如200毫秒，这样的话如果一个方法执行时间超过200毫秒，获取堆栈信息并通知开发者。
BlockCanary 原理在之前那篇卡顿优化的文章里面讲过一些，这里就不再重复。
文章有点长，看到这里，是不是忘记开头讲什么了？总结一下这篇文章主要涉及到哪些内容：
应用启动流程
闪屏页优化
MultiDex 原理分析
ClassLoader 加载一个类的流程分析
热修复原理
MultiDex优化： 介绍了两种方式，一种是直接在闪屏页开个子线程去加载dex，难维护，不推荐；一种是今日头条的方案，在单独一个进程加载dex，加载完主进程再继续。
快速启动Activity的方式：预创建Activity，预加载数据。
启动时间监控的方式：Systrace+插桩、BlockCanary。
面试问到启动优化问题，不要简单一两句话回答，可以说说自己在实际项目中做了哪些优化，比如Multidex优化，把整个流程，原理说清楚。当然，前提是自己要去实践，理解为什么要这样做。
粉丝扣扣裙：
