面试官：今日头条启动很快，你以为多是作了哪些优化？

时间  2019-11-05
标签 面试 今日 头条 启动 很快 以为 作了 哪些 优化 栏目 快乐工作 繁體版
原文   原文链接

前言

网上关于启动优化的文章多不胜数，内容千篇一概，大都是列举一些耗时操做，采用异步加载、懒加载等。css

而在面试过程当中，关于启动优化的问题，若是只是很表面地回答耗时操做应该放在子线程，显然太过于普通，没法跟竞争者拉开差距。如何让面试官知道你的“内功深厚”，那确定是要往原理层面去回答。html

本文重点仍是关注原理，冷启动优化这个问题能延伸到不少原理层面的知识点，本文比较有意思的地方是经过反编译今日头条App，研究大厂的启动优化方案。java

讲启动优化以前，先看下应用的启动流程python

1、应用启动流程

应用进程不存在的状况下，从点击桌面应用图标，到应用启动（冷启动），大概会经历如下流程：android

  1. Launcher startActivity
  2. AMS startActivity
  3. Zygote fork 进程
  4. ActivityThread main()
    4.1. ActivityThread attach
    4.2. handleBindApplication
    4.3 attachBaseContext
    4.4. installContentProviders
    4.5. Application onCreate
  5. ActivityThread 进入loop循环
  6. Activity生命周期回调，onCreate、onStart、onResume...

整个启动流程咱们能干预的主要是 4.三、4.5 和6，应用启动优化主要从这三个地方入手。理想情况下，这三个地方若是不作任何耗时操做，那么应用启动速度就是最快的，可是现实很骨感，不少开源库接入第一步通常都是在Application onCreate方法初始化，有的甚至直接内置ContentProvider，直接在ContentProvider中初始化框架，不给你优化的机会。git

2、启动优化

直奔主题，常见的启动优化方式大概有这些：github

  • 闪屏页优化
  • 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 按下编译按钮后发生了什么？

  1. 打包资源文件，生成R.java文件（使用工具AAPT）
  2. 处理AIDL文件，生成java代码（没有AIDL则忽略）
  3. 编译 java 文件，生成对应.class文件（java compiler）
  4. .class 文件转换成dex文件（dex）
  5. 打包成没有签名的apk（使用工具apkbuilder）
  6. 使用签名工具给apk签名（使用工具Jarsigner）
  7. 对签名后的.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", "", true);
            ...
            Log.i("MultiDex", "install done");
        }
    }
复制代码

从入口的判断来看，若是虚拟机自己就支持加载多个dex文件，那就啥都不用作；若是是不支持加载多个dex（5.0如下是不支持的），则走到 doInstallation 方法。

private 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 {
...
                    //获取非主dex文件
                    File dexDir = getDexDir(mainContext, dataDir, secondaryFolderName);
                    MultiDexExtractor extractor = new MultiDexExtractor(sourceApk, dexDir);
                    IOException closeException = null;

                    try {

                        // 1. 这个load方法，第一次没有缓存，会很是耗时
                        List files = extractor.load(mainContext, prefsKeyPrefix, false);

                        try {
                            //2. 安装dex
                            installSecondaryDexes(loader, dexDir, files);
                        } 
                        ...

                }
            }
        }
    }
复制代码

先看注释1，MultiDexExtractor#load

List<? extends File> load(Context context, String prefsKeyPrefix, boolean forceReload) throws IOException {
        if (!this.cacheLock.isValid()) {
            throw new IllegalStateException("MultiDexExtractor was closed");
        } else {
            List files;
            if (!forceReload && !isModified(context, this.sourceApk, this.sourceCrc, prefsKeyPrefix)) {
                try {
                    //读缓存的dex
                    files = this.loadExistingExtractions(context, prefsKeyPrefix);
                } catch (IOException var6) {
                    Log.w("MultiDex", "Failed to reload existing extracted secondary dex files, falling back to fresh extraction", var6);
                    //读取缓存的dex失败，多是损坏了，那就从新去解压apk读取，跟else代码块同样
                    files = this.performExtractions();
                    //保存标志位到sp，下次进来就走if了，不走else
                    putStoredApkInfo(context, prefsKeyPrefix, getTimeStamp(this.sourceApk), this.sourceCrc, files);
                }
            } else {
                //没有缓存，解压apk读取
                files = this.performExtractions();
                //保存dex信息到sp，下次进来就走if了，不走else
                putStoredApkInfo(context, prefsKeyPrefix, getTimeStamp(this.sourceApk), this.sourceCrc, files);
            }

            Log.i("MultiDex", "load found " + files.size() + " secondary dex files");
            return files;
        }
    }
复制代码

查找dex文件，有两个逻辑，有缓存就调用loadExistingExtractions方法，没有缓存或者缓存读取失败就调用performExtractions方法，而后再缓存起来。使用到缓存，那么performExtractions 方法想必应该是很耗时的，分析一下代码：

private List<MultiDexExtractor.ExtractedDex> performExtractions() throws IOException {
        //先肯定命名格式
        String extractedFilePrefix = this.sourceApk.getName() + ".classes";
        this.clearDexDir();
        List<MultiDexExtractor.ExtractedDex> files = new ArrayList();
        ZipFile apk = new ZipFile(this.sourceApk); // apk转为zip格式

        try {
            int secondaryNumber = 2;
            //apk已是改成zip格式了，解压遍历zip文件，里面是dex文件，
            //名字有规律，如classes1.dex,class2.dex
            for(ZipEntry dexFile = apk.getEntry("classes" + secondaryNumber + ".dex"); dexFile != null; dexFile = apk.getEntry("classes" + secondaryNumber + ".dex")) {
                //文件名：xxx.classes1.zip
                String fileName = extractedFilePrefix + secondaryNumber + ".zip";
                //建立这个classes1.zip文件
                MultiDexExtractor.ExtractedDex extractedFile = new MultiDexExtractor.ExtractedDex(this.dexDir, fileName);
                //classes1.zip文件添加到list
                files.add(extractedFile);
                Log.i("MultiDex", "Extraction is needed for file " + extractedFile);
                int numAttempts = 0;
                boolean isExtractionSuccessful = false;

                while(numAttempts < 3 && !isExtractionSuccessful) {
                    ++numAttempts;
                    //这个方法是将classes1.dex文件写到压缩文件classes1.zip里去，最多重试三次
                    extract(apk, dexFile, extractedFile, extractedFilePrefix);

                 ...
                }
        //返回dex的压缩文件列表
        return files;
    }
复制代码

这里的逻辑就是解压apk，遍历出里面的dex文件，例如class1.dex，class2.dex，而后又压缩成class1.zip，class2.zip...，而后返回zip文件列表。

思考为何这里要压缩呢？ 后面涉及到ClassLoader加载类原理的时候会分析ClassLoader支持的文件格式。

第一次加载才会执行解压和压缩过程，第二次进来读取sp中保存的dex信息，直接返回file list，因此第一次启动的时候比较耗时。

dex文件列表找到了，回到上面MultiDex#doInstallation方法的注释2，找到的dex文件列表，而后调用installSecondaryDexes方法进行安装，怎么安装呢？方法点进去看SDK 19 以上的实现

private static final class V19 {
        private V19() {
        }

        static void install(ClassLoader loader, List<? extends File> additionalClassPathEntries, File optimizedDirectory) throws IllegalArgumentException, IllegalAccessException, NoSuchFieldException, InvocationTargetException, NoSuchMethodException, IOException {
            Field pathListField = MultiDex.findField(loader, "pathList");//1 反射ClassLoader 的 pathList 字段
            Object dexPathList = pathListField.get(loader);
            ArrayList<IOException> suppressedExceptions = new ArrayList();
            // 2 扩展数组
            MultiDex.expandFieldArray(dexPathList, "dexElements", makeDexElements(dexPathList, new ArrayList(additionalClassPathEntries), optimizedDirectory, suppressedExceptions));
           ...
        }

        private static Object[] makeDexElements(Object dexPathList, ArrayList<File> files, File optimizedDirectory, ArrayList<IOException> suppressedExceptions) throws IllegalAccessException, InvocationTargetException, NoSuchMethodException {
            Method makeDexElements = MultiDex.findMethod(dexPathList, "makeDexElements", ArrayList.class, File.class, ArrayList.class);
            return (Object[])((Object[])makeDexElements.invoke(dexPathList, files, optimizedDirectory, suppressedExceptions));
        }
    }
复制代码
  1. 反射ClassLoader 的 pathList 字段
  2. 找到pathList 字段对应的类的makeDexElements 方法
  3. 经过MultiDex.expandFieldArray 这个方法扩展 dexElements 数组，怎么扩展？看下代码：
private static void expandFieldArray(Object instance, String fieldName, Object[] extraElements) throws NoSuchFieldException, IllegalArgumentException, IllegalAccessException {
        Field jlrField = findField(instance, fieldName);
        Object[] original = (Object[])((Object[])jlrField.get(instance)); //取出原来的dexElements 数组
        Object[] combined = (Object[])((Object[])Array.newInstance(original.getClass().getComponentType(), original.length + extraElements.length)); //新的数组
        System.arraycopy(original, 0, combined, 0, original.length); //原来数组内容拷贝到新的数组
        System.arraycopy(extraElements, 0, combined, original.length, extraElements.length); //dex二、dex3...拷贝到新的数组
        jlrField.set(instance, combined); //将dexElements 从新赋值为新的数组
    }
复制代码

就是建立一个新的数组，把原来数组内容（主dex）和要增长的内容（dex二、dex3...）拷贝进去，反射替换原来的dexElements为新的数组，以下图

image

看起来有点眼熟，Tinker热修复的原理也是经过反射将修复后的dex添加到这个dex数组去，不一样的是热修复是添加到数组最前面，而MultiDex是添加到数组后面。这样讲可能还不是很好理解？来看看ClassLoader怎么加载一个类的就明白了~

2.2.4 ClassLoader 加载类原理

无论是 PathClassLoader仍是DexClassLoader，都继承自BaseDexClassLoader，加载类的代码在 BaseDexClassLoader中

4.4 源码

/dalvik/src/main/java/dalvik/system/BaseDexClassLoader.java

4.4 BaseDexClassLoader

  1. 构造方法经过传入dex路径，建立了DexPathList。
  2. ClassLoader的findClass方法最终是调用DexPathList 的findClass方法

接着看DexPathList源码 /dalvik/src/main/java/dalvik/system/DexPathList.java

DexPathList-dexElements

DexPathList里面定义了一个dexElements 数组，findClass方法中用到，看下

DexPathList#findClass

findClass方法逻辑很简单，就是遍历dexElements 数组，拿到里面的DexFile对象，经过DexFile的loadClassBinaryName方法加载一个类。

DexFile#loadClassBinaryName

最终建立Class是经过native方法，就不追下去了，你们有兴趣能够看下native层是怎么建立Class对象的。DexFile.cpp

那么问题来了，5.0如下这个dexElements 里面只有主dex（能够认为是一个bug），没有dex二、dex3...，MultiDex是怎么把dex2添加进去呢? 答案就是反射DexPathList的dexElements字段，而后把咱们的dex2添加进去，固然，dexElements里面放的是Element对象，咱们只有dex2的路径，必须转换成Element格式才行，因此反射DexPathList里面的makeDexElements 方法，将dex文件转换成Element对象便可。

image

dex二、dex3...经过makeDexElements方法转换成要新增的Element数组，最后一步就是反射DexPathList的dexElements字段，将原来的Element数组和新增的Element数组合并，而后反射赋值给dexElements变量，最后DexPathList的dexElements变量就包含咱们新加的dex在里面了。

makeDexElements方法会判断file类型，上面讲dex提取的时候解压apk获得dex，而后又将dex压缩成zip，压缩成zip，就会走到第二个判断里去。仔细想一想，其实dex不压缩成zip，走第一个判断也没啥问题吧，那谷歌的MultiDex为何要将dex压缩成zip呢？在Android开发高手课中看到张绍文也提到这一点

image

而后我在反编译头条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原理图以下：

MultiDex原理

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配置，以下：

defaultConfig {
        //分包，指定某个类在main dex
        multiDexEnabled true
        multiDexKeepProguard file('multiDexKeep.pro') // 打包到main dex的这些类的混淆规制，没特殊需求就给个空文件
        multiDexKeepFile file('maindexlist.txt') // 指定哪些类要放到main dex
    }
复制代码

maindexlist.txt 文件指定哪些类要打包到主dex中，内容格式以下

com/lanshifu/launchtest/SplashActivity.class
复制代码

在已有项目中用这种方式，一顿操做猛如虎以后，编译运行在4.4的机器上，启动闪屏页，加载完准备进入主页直接崩掉了。

image

报错NoClassDefFoundError，通常都是该类没有在主dex中，要在maindexlist.txt 将配置指定在主dex。 **第三方库中的ContentProvider必须指定在主dex中，不然也会找不到，为何？**文章开头说过应用的启动流程，ContentProvider 初始化时机以下图：

image

ContentProvider初始化太早了，若是不在主dex中，还没启动闪屏页就已经crash了。

因此这种方案的缺点很明显：

  1. MultiDex加载逻辑放在闪屏页的话，闪屏页中引用到的类都要配置在主dex。
  2. ContentProvider必须在主dex，一些第三方库自带ContentProvider，维护比较麻烦，要一个一个配置。

这时候就思考一下，有没有其它更好的方案呢？大厂是怎么作的？今日头条确定要对MultiDex进行优化吧，反编译瞧瞧？

image

点了一根烟以后，开始偷代码...

MultiDex优化方案2：今日头条方案

今日头条没有加固，反编译后很容易经过关键字搜索找到MultidexApplication这个类，

image

看注释1的d.a(this);这个方法，代码虽然混淆了，可是方法内部的代码仍是能够看出是干吗的，继续跟这个方法，为了避免影响阅读，我对混淆作了一些处理，改为正常的方法名。

image
每一个方法开头都有 PatchProxy.isSupport这个if判断，这个是美团Robust热修复生成的代码，今日头条没有本身的热修复框架，没有用Tinker，而是用美团的，想了解关于Robust细节能够参考文末连接。Robust直接跳过，看else代码块便可。

继续看loadMultiDex方法

image

逻辑以下：
1. 建立临时文件，做为判断MultiDex是否加载完的条件
2. 启动LoadDexActivity去加载MultiDex（LoadDexActivity在单独进程），加载完会删除临时文件
3. 开启while循环，直到临时文件不存在才跳出循环，进入Application的onCreate

建立临时文件代码

image

while循环代码

image

LoadDexActivity 只有一个加载框，加载完再跳转到闪屏页

image

dex加载完应该要finish掉当前Activity

image

按照上面代码分析，今日头条在5.0如下手机首次启动应该是这样：

  1. 打开桌面图标
  2. 显示默认背景
  3. 跳转到加载dex的界面，展现一个loading的加载框几秒钟
  4. 跳转到闪屏页

其实是不是这样呢，用4.4机器试下？

今日头条启动

看起来彻底跟猜测的一致，撸几行代码验证应该不难吧？

image

点了一根烟以后，开始撸代码，最终实现效果以下

仿头条启动.gif

效果跟今日头条是一致的，再也不重复分析代码了，源码上传到github，感兴趣的同窗能够参考参考，头条的方案，值得尝试~ github.com/lanshifu/Mu…

再次梳理一下这种方式：

  1. 在主进程Application 的 attachBaseContext 方法中判断若是须要使用MultiDex，则建立一个临时文件，而后开一个进程（LoadDexActivity），显示Loading，异步执行MultiDex.install 逻辑，执行完就删除临时文件并finish本身。
  2. 主进程Application 的 attachBaseContext 进入while代码块，定时轮循临时文件是否被删除，若是被删除，说明MultiDex已经执行完，则跳出循环，继续正常的应用启动流程。
  3. 注意LoadDexActivity 必需要配置在main dex中。

有些同窗可能会问，启动仍是好久啊，冷启动时间有变化吗？ 冷启动时间是指点击桌面图标到第一个Activity显示这段时间。

MultiDex优化总结

方案1：直接在闪屏页开个子线程去执行MultiDex逻辑，MultiDex不影响冷启动速度，可是难维护。

方案2：今日头条的MultiDex优化方案：

  1. 在Application 的attachBaseContext 方法里，启动另外一个进程的LoadDexActivity去异步执行MultiDex逻辑，显示Loading。
  2. 而后主进程Application进入while循环，不断检测MultiDex操做是否完成
  3. MultiDex执行完以后主进程Application继续走，ContentProvider初始化和Application onCreate方法，也就是执行主进程正常的逻辑。

其实应该还有方案3，由于我发现头条并无直接使用Google的MultiDex，而是参考谷歌的MultiDex，本身写了一套，耗时应该会少一些，你们有兴趣能够去研究一下。

2.3 预建立Activity

image

这段代码是今日头条里面的，Activity对象预先new出来，

对象第一次建立的时候，java虚拟机首先检查类对应的Class 对象是否已经加载。若是没有加载，jvm会根据类名查找.class文件，将其Class对象载入。同一个类第二次new的时候就不须要加载类对象，而是直接实例化，建立时间就缩短了。

头条真是把启动优化作到极致。

2.4 第三方库懒加载

不少第三方开源库都说在Application中进行初始化，十几个开源库都放在Application中，确定对冷启动会有影响，因此能够考虑按需初始化，例如Glide，能够放在本身封装的图片加载类中，调用到再初始化，其它库也是同理，让Application变得更轻。

2.5 WebView启动优化。

WebView启动优化文章也比较多，这里只说一下大概优化思路。

  1. WebView第一次建立比较耗时，能够预先建立WebView，提早将其内核初始化。
  2. 使用WebView缓存池，用到WebView的地方都从缓存池取，缓存池中没有缓存再建立，注意内存泄漏问题。
  3. 本地预置html和css，WebView建立的时候先预加载本地html，以后经过js脚本填充内容部分。

这一部分能够参考： mp.weixin.qq.com/s/KwvWURD5W…

2.6 数据预加载

这种方式通常是在主页空闲的时候，将其它页面的数据加载好，保存到内存或数据库，等到打开该页面的时候，判断已经预加载过，直接从内存或数据库读取数据并显示。

2.7 线程优化

线程是程序运行的基本单位，线程的频繁建立是耗性能的，因此你们应该都会用线程池。单个cpu状况下，即便是开多个线程，同时也只有一个线程能够工做，因此线程池的大小要根据cpu个数来肯定。

启动优化方式就先介绍到这里，常见的就是这些，其它的能够做为补充。

3、启动耗时分析方法

TraceView性能损耗太大，获得的结果不真实。 Systrace 能够方便追踪关键系统调用的耗时状况，如 Choreographer，可是不支持应用程序代码的耗时分析。

3.1 Systrace + 函数插桩

结合Systrace 和 函数插桩，就是将以下代码插入到每一个方法的入口和出口

class Trace{
    public static void i(String tag){
        android.os.Trace.beginSection(tag);
    }

    public static void o(){
        android.os.Trace.endSection();
    }

}
复制代码

插桩后的代码以下

void test(){
    Trace.i("test");
    System.out.println("doSomething");
    Trace.o();
}
复制代码

插桩工具参考： 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

image

最后按下Enter中止捕获trace信息，在目录下生成报告test.log.html，直接能够用谷歌浏览器打开查看。

3.2 BlockCanary 也能够检测

BlockCanary 能够监听主线程耗时的方法，将阈值设置低一点，好比200毫秒，这样的话若是一个方法执行时间超过200毫秒，获取堆栈信息并通知开发者。

BlockCanary 原理在以前那篇卡顿优化的文章里面讲过一些，这里就再也不重复。

总结

文章有点长，看到这里，是否是忘记开头讲什么了？总结一下这篇文章主要涉及到哪些内容：

  1. 应用启动流程
  2. 闪屏页优化
  3. MultiDex 原理分析
  4. ClassLoader 加载一个类的流程分析
  5. 热修复原理
  6. MultiDex优化： 介绍了两种方式，一种是直接在闪屏页开个子线程去加载dex，难维护，不推荐；一种是今日头条的方案，在单独一个进程加载dex，加载完主进程再继续。
  7. 快速启动Activity的方式：预建立Activity，预加载数据。
  8. 启动时间监控的方式：Systrace+插桩、BlockCanary。

面试问到启动优化问题，不要简单一两句话回答，能够说说本身在实际项目中作了哪些优化，好比Multidex优化，把整个流程，原理说清楚。固然，前提是本身要去实践，理解为何要这样作。

就这样，有问题请留言，更多文章，敬请期待。

相关连接：
[Android开发高手课07 | 启动优化（上）]
Multidex（二）之Dex预加载优化
Android热更新方案Robust
本文源码:https://github.com/lanshifu/MultiDexTest/

相关文章
相关标签/搜索
每日一句
    每一个你不满意的现在，都有一个你没有努力的曾经。
本站公众号
   欢迎关注本站公众号,获取更多信息
联系我们 最近搜索 最新文章 沪ICP备13005482号-10 MyBatis教程 SQL 教程 MySQL教程 Java 教程 Thymeleaf 教程 Hibernate教程 Spring教程 Redis教程