前言
网上关于启动优化的文章多不胜数,内容千篇一律,大都是列举一些耗时操作,采用异步加载、懒加载等。
而在面试过程中,关于启动优化的问题,如果只是很表面地回答耗时操作应该放在子线程,显然太过于普通,无法跟竞争者拉开差距。如何让面试官知道你的“内功深厚”,那肯定是要往原理层面去回答。
本文重点还是关注原理,冷启动优化这个问题能延伸到很多原理层面的知识点,本文比较有意思的地方是通过反编译今日头条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优化
- 线程优化
- 系统调用优化
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 原理
下面看下MultiDex
的install 方法做了什么事
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",