原文地址:https://www.jianshu.com/p/d0fe74f4e9c4
相关阅读:深圳一普通中学老师工资单曝光,秒杀程序员,网友:敢问是哪个学校毕业的?
前言
网上关于启动优化的文章多不胜数,内容千篇一律,大都是列举一些耗时操作,采用异步加载、懒加载等。
而在面试过程中,关于启动优化的问题,如果只是很表面地回答耗时操作应该放在子线程,显然太过于普通,无法跟竞争者拉开差距。如何让面试官知道你的“内功深厚”,那肯定是要往原理层面去回答。
本文重点还是关注原理,冷启动优化这个问题能延伸到很多原理层面的知识点,本文比较有意思的地方是通过反编译今日头条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 onCreateActivityThread 进入loop循环
整个启动流程我们能干预的主要是 4.3、4.5 和6,应用启动优化主要从这三个地方入手。理想状况下,这三个地方如果不做任何耗时操作,那么应用启动速度就是最快的,但是现实很骨感,很多开源库接入第一步一般都是在Application onCreate方法初始化,有的甚至直接内置ContentProvider,直接在ContentProvider中初始化框架,不给你优化的机会。
二、启动优化
直奔主题,常见的启动优化方式大概有这些:
闪屏页优化
MultipDex优化(本文重点)
第三方库懒加载
WebView优化
线程优化
系统调用优化
2.1 闪屏页优化
消除启动时的白屏/黑屏,市面上大部分App都采用了这种方法,非常简单,是一个障眼法,不会缩短实际冷启动时间,简单贴下实现方式吧。
1<application
2 android:name=".MainApplication"
3 ...
4 android:theme="@style/AppThemeWelcome>
5
styles.xml 增加一个主题叫AppThemeWelcome
1<style name="AppThemeWelcome" parent="Theme.AppCompat.NoActionBar">
2 ...
3 <item name="android:windowBackground">@drawable/logo</item> <!-- 默认背景-->
4</style>
闪屏页设置这个主题,或者全局给Application设置,搜索公众号互联网架构师回复“2T”,送你一份惊喜礼包。
1 <activity android:name=".ui.activity.DemoSplashActivity"
2 android:configChanges="orientation|screenSize|keyboardHidden"
3 android:theme="@style/AppThemeWelcome"
4 android:screenOrientation="portrait">
5 <intent-filter>
6 <action android:name="android.intent.action.MAIN" />
7
8 <category android:name="android.intent.category.LAUNCHER" />
9 </intent-filter>
10 </activity>
这样的话启动Activity之后背景会一直在,所以在Activity的onCreate方法中切换成正常主题
1protected void onCreate(@Nullable Bundle savedInstanceState) {
2 setTheme(R.style.AppTheme); //切换正常主题
3 super.onCreate(savedInstanceState);
这样打开桌面图标会马上显示logo,不会出现黑/白屏,直到Activity启动完成,替换主题,logo消失,但是总的启动时间并没有改变。
2.2 MultiDex 优化(本文重点)
说MultiDex
之前,先梳理下apk编译流程
2.2.1 apk编译流程
在第4步,将class文件转换成dex文件,默认只会生成一个dex文件,单个dex文件中的方法数不能超过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)
耗时如下:
1MultiDex.install 耗时:1320
平均耗时1秒以上,目前大部分应用应该还是会兼容5.0以下手机,那么MultiDex优化是冷启动优化的大头。
为什么MultiDex
会这么耗时?老规矩,分析一下MultiDex原理~
2.2.3 MultiDex 原理
下面看下MultiDex
的install 方法做了什么事
1public static void install(Context context) {
2 Log.i("MultiDex", "Installing application");
3 if (IS_VM_MULTIDEX_CAPABLE) { //5.0 以上VM基本支持多dex,啥事都不用干
4 Log.i("MultiDex", "VM has multidex support, MultiDex support library is disabled.");
5 } else if (VERSION.SDK_INT < 4) { //
6 throw new RuntimeException("MultiDex installation failed. SDK " + VERSION.SDK_INT + " is unsupported. Min SDK version is " + 4 + ".");
7 } else {
8 ...
9 doInstallation(context, new File(applicationInfo.sourceDir), new File(applicationInfo.dataDir), "secondary-dexes", "", true);
10 ...
11 Log.i("MultiDex", "install done");
12 }
13 }
从入口的判断来看,如果虚拟机本身就支持加载多个dex文件,那就啥都不用做;如果是不支持加载多个dex(5.0以下是不支持的),则走到 doInstallation
方法。
1private static void doInstallation(Context mainContext, File sourceApk, File dataDir, String secondaryFolderName, String prefsKeyPrefix, boolean reinstallOnPatchRecoverableException) throws IOException, IllegalArgumentException, IllegalAccessException, NoSuchFieldException, InvocationTargetException, NoSuchMethodException, SecurityException, ClassNotFoundException, InstantiationException {
2...
3 //获取非主dex文件
4 File dexDir = getDexDir(mainContext, dataDir, secondaryFolderName);
5 MultiDexExtractor extractor = new MultiDexExtractor(sourceApk, dexDir);
6 IOException closeException = null;
7
8 try {
9
10 // 1\. 这个load方法,第一次没有缓存,会非常耗时
11 List files = extractor.load(mainContext, prefsKeyPrefix, false);
12
13 try {
14 //2\. 安装dex
15 installSecondaryDexes(loader, dexDir, files);
16 }
17 ...
18
19 }
20 }
21 }
22 }
先看注释1,MultiDexExtractor#load
1 List<? extends File> load(Context context, String prefsKeyPrefix, boolean forceReload) throws IOException {
2 if (!this.cacheLock.isValid()) {
3 throw new IllegalStateException("MultiDexExtractor was closed");
4 } else {
5 List files;
6 if (!forceReload && !isModified(context, this.sourceApk, this.sourceCrc, prefsKeyPrefix)) {
7 try {
8 //读缓存的dex
9 files = this.loadExistingExtractions(context, prefsKeyPrefix);
10 } catch (IOException var6) {
11 Log.w("MultiDex", "Failed to reload existing extracted secondary dex files, falling back to fresh extraction", var6);
12 //读取缓存的dex失败,可能是损坏了,那就重新去解压apk读取,跟else代码块一样
13 files = this.performExtractions();
14 //保存标志位到sp,下次进来就走if了,不走else
15 putStoredApkInfo(context, prefsKeyPrefix, getTimeStamp(this.sourceApk), this.sourceCrc, files);
16 }
17 } else {
18 //没有缓存,解压apk读取
19 files = this.performExtractions();
20 //保存dex信息到sp,下次进来就走if了,不走else
21 putStoredApkInfo(context, prefsKeyPrefix, getTimeStamp(this.sourceApk), this.sourceCrc, files);
22 }
23
24 Log.i("MultiDex", "load found " + files.size() + " secondary dex files");
25 return files;
26 }
27 }
查找dex文件,有两个逻辑,有缓存就调用loadExistingExtractions
方法,没有缓存或者缓存读取失败就调用performExtractions
方法,然后再缓存起来。使用到缓存,那么performExtractions
方法想必应该是很耗时的,分析一下代码:
1private List<MultiDexExtractor.ExtractedDex> performExtractions() throws IOException {
2 //先确定命名格式
3 String extractedFilePrefix = this.sourceApk.getName() + ".classes";
4 this.clearDexDir();
5 List<MultiDexExtractor.ExtractedDex> files = new ArrayList();
6 ZipFile apk = new ZipFile(this.sourceApk); // apk转为zip格式
7
8 try {
9 int secondaryNumber = 2;
10 //apk已经是改为zip格式了,解压遍历zip文件,里面是dex文件,
11 //名字有规律,如classes1.dex,class2.dex
12 for(ZipEntry dexFile = apk.getEntry("classes" + secondaryNumber + ".dex"); dexFile != null; dexFile = apk.getEntry("classes" + secondaryNumber + ".dex")) {
13 //文件名:xxx.classes1.zip
14 String fileName = extractedFilePrefix + secondaryNumber + ".zip";
15 //创建这个classes1.zip文件
16 MultiDexExtractor.ExtractedDex extractedFile = new MultiDexExtractor.ExtractedDex(this.dexDir, fileName);
17 //classes1.zip文件添加到list
18 files.add(extractedFile);
19 Log.i("MultiDex", "Extraction is needed for file " + extractedFile);
20 int numAttempts = 0;
21 boolean isExtractionSuccessful = false;
22
23 while(numAttempts < 3 && !isExtractionSuccessful) {
24 ++numAttempts;
25 //这个方法是将classes1.dex文件写到压缩文件classes1.zip里去,最多重试三次
26 extract(apk, dexFile, extractedFile, extractedFilePrefix);
27
28 ...
29 }
30 //返回dex的压缩文件列表
31 return files;
32 }
这里的逻辑就是解压apk,遍历出里面的dex文件,例如class1.dex,class2.dex,然后又压缩成class1.zip,class2.zip…,然后返回zip文件列表。
思考为什么这里要压缩呢?后面涉及到ClassLoader加载类原理的时候会分析ClassLoader支持的文件格式。搜索公众号互联网架构师回复“2T”,送你一份惊喜礼包。
第一次加载才会执行解压和压缩过程,第二次进来读取sp中保存的dex信息,直接返回file list,所以第一次启动的时候比较耗时。
dex文件列表找到了,回到上面MultiDex#doInstallation
方法的注释2,找到的dex文件列表,然后调用installSecondaryDexes
方法进行安装,怎么安装呢?方法点进去看SDK 19 以上的实现
1private static final class V19 {
2 private V19() {
3 }
4
5 static void install(ClassLoader loader, List<? extends File> additionalClassPathEntries, File optimizedDirectory) throws IllegalArgumentException, IllegalAccessException, NoSuchFieldException, InvocationTargetException, NoSuchMethodException, IOException {
6 Field pathListField = MultiDex.findField(loader, "pathList");//1 反射ClassLoader 的 pathList 字段
7 Object dexPathList = pathListField.get(loader);
8 ArrayList<IOException> suppressedExceptions = new ArrayList();
9 // 2 扩展数组
10 MultiDex.expandFieldArray(dexPathList, "dexElements", makeDexElements(dexPathList, new ArrayList(additionalClassPathEntries), optimizedDirectory, suppressedExceptions));
11 ...
12 }
13
14 private static Object[] makeDexElements(Object dexPathList, ArrayList<File> files, File optimizedDirectory, ArrayList<IOException> suppressedExceptions) throws IllegalAccessException, InvocationTargetException, NoSuchMethodException {
15 Method makeDexElements = MultiDex.findMethod(dexPathList, "makeDexElements", ArrayList.class, File.class, ArrayList.class);
16 return (Object[])((Object[])makeDexElements.invoke(dexPathList, files, optimizedDirectory, suppressedExceptions));
17 }
18 }
反射ClassLoader 的 pathList 字段
找到pathList 字段对应的类的
makeDexElements
方法通过
MultiDex.expandFieldArray
这个方法扩展dexElements
数组,怎么扩展?看下代码:
1 private static void expandFieldArray(Object instance, String fieldName, Object[] extraElements) throws NoSuchFieldException, IllegalArgumentException, IllegalAccessException {
2 Field jlrField = findField(instance, fieldName);
3 Object[] original = (Object[])((Object[])jlrField.get(instance)); //取出原来的dexElements 数组
4 Object[] combined = (Object[])((Object[])Array.newInstance(original.getClass().getComponentType(), original.length + extraElements.length)); //新的数组
5 System.arraycopy(original, 0, combined, 0, original.length); //原来数组内容拷贝到新的数组
6 System.arraycopy(extraElements, 0, combined, original.length, extraElements.length); //dex2、dex3...拷贝到新的数组
7 jlrField.set(instance, combined); //将dexElements 重新赋值为新的数组
8 }
就是创建一个新的数组,把原来数组内容(主dex)和要增加的内容(dex2、dex3…)拷贝进去,反射替换原来的dexElements
为新的数组,如下图
![image e434a037b832999344184decbe97524a.png](https://i-blog.csdnimg.cn/blog_migrate/d04a520287386f2bea3de2df9d5a7f46.png)
看起来有点眼熟,Tinker热修复的原理也是通过反射将修复后的dex添加到这个dex数组去,不同的是热修复是添加到数组最前面,而MultiDex是添加到数组后面。这样讲可能还不是很好理解?来看看ClassLoader怎么加载一个类的就明白了~
2.2.4 ClassLoader 加载类原理
不管是 PathClassLoader
还是DexClassLoader
,都继承自BaseDexClassLoader
,加载类的代码在 BaseDexClassLoader
中
4.4 源码
/dalvik/src/main/java/dalvik/system/BaseDexClassLoader.java
![image 97bc646f9802ee6379da9af4c81c385d.png](https://i-blog.csdnimg.cn/blog_migrate/225586c184c0ec1b3dacf14ecce80f30.png)
构造方法通过传入dex路径,创建了
DexPathList
。ClassLoader的findClass方法最终是调用DexPathList 的findClass方法
接着看DexPathList
源码
/dalvik/src/main/java/dalvik/system/DexPathList.java
![image 2b999aeb355621dbb506056fc660fdca.png](https://i-blog.csdnimg.cn/blog_migrate/e3df3ff9ae408a0bc1e4ed53056ace6a.png)
DexPathList
里面定义了一个dexElements
数组,findClass
方法中用到,看下
![image d4226edc732ffefd1233d158a5458626.png](https://i-blog.csdnimg.cn/blog_migrate/6c0fe6b040d94912d883216bf7cd3bb2.png)
findClass方法逻辑很简单,就是遍历dexElements 数组,拿到里面的DexFile对象,通过DexFile的loadClassBinaryName方法加载一个类。
![image aba3ed5165fb10d433d938ea530af842.png](https://i-blog.csdnimg.cn/blog_migrate/c2d0b9fbf0811cf33217ac9b7d1bdbf8.png)
最终创建Class是通过native方法,就不追下去了,大家有兴趣可以看下native层是怎么创建Class对象的。DexFile.cpp
那么问题来了,5.0以下这个dexElements 里面只有主dex(可以认为是一个bug),没有dex2、dex3…,MultiDex是怎么把dex2添加进去呢?
答案就是反射DexPathList
的dexElements
字段,然后把我们的dex2添加进去,当然,dexElements里面放的是Element对象,我们只有dex2的路径,必须转换成Element格式才行,所以反射DexPathList里面的makeDexElements 方法,将dex文件转换成Element对象即可。
![image fda3b1ed2b7821fdd3475636718ce7c5.png](https://i-blog.csdnimg.cn/blog_migrate/954d84636e7eb5b32d319666873673d2.png)
dex2、dex3…通过makeDexElements
方法转换成要新增的Element数组,最后一步就是反射DexPathList的dexElements字段,将原来的Element数组和新增的Element数组合并,然后反射赋值给dexElements变量,最后DexPathList的dexElements变量就包含我们新加的dex在里面了。搜索公众号互联网架构师回复“2T”,送你一份惊喜礼包。
makeDexElements
方法会判断file类型,上面讲dex提取的时候解压apk得到dex,然后又将dex压缩成zip,压缩成zip,就会走到第二个判断里去。仔细想想,其实dex不压缩成zip,走第一个判断也没啥问题吧,那谷歌的MultiDex为什么要将dex压缩成zip呢?在Android开发高手课中看到张绍文也提到这一点
![image a6f51485df6c90635e46102037a1667b.png](https://i-blog.csdnimg.cn/blog_migrate/871bfd7d9c9bab744f67bb4bdd291faa.png)
然后我在反编译头条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原理图如下:
![]()
image
2.2.6 MultiDex 优化(两种方案)
知道了MultiDex原理之后,可以理解install过程为什么耗时,因为涉及到解压apk取出dex、压缩dex、将dex文件通过反射转换成DexFile对象、反射替换数组。
那么MultiDex到底应该怎么优化呢,放子线程可行吗?
方案1:子线程install(不推荐)
这个方法大家很容易就能想到,在闪屏页开一个子线程去执行MultiDex.install
,然后加载完才跳转到主页。需要注意的是闪屏页的Activity,包括闪屏页中引用到的其它类必须在主dex中,不然在MultiDex.install
之前加载这些不在主dex中的类会报错Class Not Found。这个可以通过gradle配置,如下:
1 defaultConfig {
2 //分包,指定某个类在main dex
3 multiDexEnabled true
4 multiDexKeepProguard file('multiDexKeep.pro') // 打包到main dex的这些类的混淆规制,没特殊需求就给个空文件
5 multiDexKeepFile file('maindexlist.txt') // 指定哪些类要放到main dex
6 }
7
maindexlist.txt 文件指定哪些类要打包到主dex中,内容格式如下
1com/lanshifu/launchtest/SplashActivity.class
在已有项目中用这种方式,一顿操作猛如虎之后,编译运行在4.4的机器上,启动闪屏页,加载完准备进入主页直接崩掉了。
![image ec5d8f404df587586fec260dd76b90d1.png](https://i-blog.csdnimg.cn/blog_migrate/b8cc704f81f4971f6b24046409b5189e.png)
报错NoClassDefFoundError
,一般都是该类没有在主dex中,要在maindexlist.txt 将配置指定在主dex。
第三方库中的ContentProvider必须指定在主dex中,否则也会找不到,为什么?文章开头说过应用的启动流程,ContentProvider 初始化时机如下图:
![image 70aa5db8f8d49cd03c04321ad9f16d5b.png](https://i-blog.csdnimg.cn/blog_migrate/8f431e712247559714275f6f10442a71.png)
ContentProvider初始化太早了,如果不在主dex中,还没启动闪屏页就已经crash了。
所以这种方案的缺点很明显:
MultiDex加载逻辑放在闪屏页的话,闪屏页中引用到的类都要配置在主dex。
ContentProvider必须在主dex,一些第三方库自带ContentProvider,维护比较麻烦,要一个一个配置。
这时候就思考一下,有没有其它更好的方案呢?大厂是怎么做的?今日头条肯定要对MultiDex进行优化吧,反编译瞧瞧?
![image ea4bf370712d982574decd43fb18f3a2.png](https://i-blog.csdnimg.cn/blog_migrate/2192751d96fe955853e724bd6a34f715.png)
点了一根烟之后,开始偷代码…
MultiDex优化方案2:今日头条方案
今日头条没有加固,反编译后很容易通过关键字搜索找到MultidexApplication
这个类,
![image 0d6e8b66bbe2c9c93d115bb340bb36cf.png](https://i-blog.csdnimg.cn/blog_migrate/63e8d102dd787de1fa4cc8889159b736.png)
看注释1的d.a(this);
这个方法,代码虽然混淆了,但是方法内部的代码还是可以看出是干嘛的,继续跟这个方法,为了不影响阅读,我对混淆做了一些处理,改成正常的方法名。
![image 66d6df0f61743df04f63de354f34bfd4.png](https://i-blog.csdnimg.cn/blog_migrate/24f448238c919690f1e4f6914211e2aa.png)
每个方法开头都有PatchProxy.isSupport
这个if判断,这个是美团Robust热修复生成的代码,今日头条没有自己的热修复框架,没有用Tinker,而是用美团的,想了解关于Robust细节可以参考文末链接。Robust直接跳过,看else代码块即可。
继续看loadMultiDex
方法
![image 5dbf165f280cec31196a5311a08a5c36.png](https://i-blog.csdnimg.cn/blog_migrate/c1f40a441292c17dc1010b7a537dde41.png)
逻辑如下:
创建临时文件代码
![image 1c4f41d9db82ba1a518fdc7cbe3200f2.png](https://i-blog.csdnimg.cn/blog_migrate/7c1d51a78bed2c243844c13434a2f95a.png)
while循环代码
![image 632d35d413356885b86044732b1c5746.png](https://i-blog.csdnimg.cn/blog_migrate/947ffef5482f14a3bb86b797569e7bd1.png)
LoadDexActivity 只有一个加载框,加载完再跳转到闪屏页
![image 3e0ee5c5ea5a645c14e35c4eb0f03d55.png](https://i-blog.csdnimg.cn/blog_migrate/c1ef4349edf03f9d29ebb04a39ca14b2.png)
dex加载完应该要finish掉当前Activity
![image c9115fd4d1f20d2b702df75bca999378.png](https://i-blog.csdnimg.cn/blog_migrate/5722896207901c0e113ccf35206b94c0.png)
按照上面代码分析,今日头条在5.0以下手机首次启动应该是这样:
![image 9f36d4e7353d10f805b6b68cae405ebb.png](https://i-blog.csdnimg.cn/blog_migrate/2e0e023db4b49e977e60049943560359.png)
看起来完全跟猜想的一致,撸几行代码验证应该不难吧?
![image 6bd206f81eafcb453f24be1ca3979610.png](https://i-blog.csdnimg.cn/blog_migrate/fe35da839392612d8a86c8d186a9f6d9.png)
点了一根烟之后,开始撸代码,最终实现效果如下
[图片上传失败…(image-9629d7-1571154814316)]
效果跟今日头条是一致的,不再重复分析代码了,源码上传到github,感兴趣的同学可以参考参考,头条的方案,值得尝试~
https://github.com/lanshifu/MultiDexTest/
再次梳理一下这种方式:
在主进程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,自己写了一套,耗时应该会少一些,大家有兴趣可以去研究一下。
2.3 预创建Activity
![image 5c7314fa3af440faf855db186b2b2e7f.png](https://i-blog.csdnimg.cn/blog_migrate/449bf19251adf641aa2a503d74de5e76.png)
这段代码是今日头条里面的,Activity对象预先new出来,
对象第一次创建的时候,java虚拟机首先检查类对应的Class
对象是否已经加载。如果没有加载,jvm会根据类名查找.class文件,将其Class对象载入。同一个类第二次new的时候就不需要加载类对象,而是直接实例化,创建时间就缩短了。
头条真是把启动优化做到极致。
2.4 第三方库懒加载
很多第三方开源库都说在Application中进行初始化,十几个开源库都放在Application中,肯定对冷启动会有影响,所以可以考虑按需初始化,例如Glide,可以放在自己封装的图片加载类中,调用到再初始化,其它库也是同理,让Application变得更轻。
2.5 WebView启动优化。
WebView启动优化文章也比较多,这里只说一下大概优化思路。
WebView第一次创建比较耗时,可以预先创建WebView,提前将其内核初始化。
使用WebView缓存池,用到WebView的地方都从缓存池取,缓存池中没有缓存再创建,注意内存泄漏问题。
本地预置html和css,WebView创建的时候先预加载本地html,之后通过js脚本填充内容部分。
这一部分可以参考:
https://mp.weixin.qq.com/s/KwvWURD5WKgLKCetwsH0EQ,
2.6 数据预加载
这种方式一般是在主页空闲的时候,将其它页面的数据加载好,保存到内存或数据库,等到打开该页面的时候,判断已经预加载过,直接从内存或数据库读取数据并显示。
2.7 线程优化
线程是程序运行的基本单位,线程的频繁创建是耗性能的,所以大家应该都会用线程池。单个cpu情况下,即使是开多个线程,同时也只有一个线程可以工作,所以线程池的大小要根据cpu个数来确定。搜索公众号互联网架构师回复“2T”,送你一份惊喜礼包。
启动优化方式就先介绍到这里,常见的就是这些,其它的可以作为补充。
三、启动耗时分析方法
TraceView
性能损耗太大,得到的结果不真实。Systrace
可以方便追踪关键系统调用的耗时情况,如 Choreographer,但是不支持应用程序代码的耗时分析。
3.1 Systrace + 函数插桩
结合Systrace
和 函数插桩
,就是将如下代码插入到每个方法的入口和出口
1class Trace{
2 public static void i(String tag){
3 android.os.Trace.beginSection(tag);
4 }
5
6 public static void o(){
7 android.os.Trace.endSection();
8 }
9
10}
插桩后的代码如下
1void test(){
2 Trace.i("test");
3 System.out.println("doSomething");
4 Trace.o();
5}
插桩工具参考:
https://github.com/AndroidAdvanceWithGeektime/Chapter07
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
![image 0d3bdc49eb14191c9075b597195f6041.png](https://i-blog.csdnimg.cn/blog_migrate/4a040d4452694845f17c588799bcbcc8.png)
最后按下Enter停止捕获trace信息,在目录下生成报告test.log.html,直接可以用谷歌浏览器打开查看。
3.2 BlockCanary 也可以检测
BlockCanary 可以监听主线程耗时的方法,将阈值设置低一点,比如200毫秒,这样的话如果一个方法执行时间超过200毫秒,获取堆栈信息并通知开发者。
BlockCanary 原理在之前那篇卡顿优化的文章里面讲过一些,这里就不再重复。
总结
文章有点长,看到这里,是不是忘记开头讲什么了?总结一下这篇文章主要涉及到哪些内容:
面试问到启动优化问题,不要简单一两句话回答,可以说说自己在实际项目中做了哪些优化,比如Multidex优化,把整个流程,原理说清楚。当然,前提是自己要去实践,理解为什么要这样做。