闲聊MultiDex

MultiDex 是什么?

当Android系统安装一个应用的时候,有一步是对Dex进行优化,这个过程有一个专门的工具来处理,叫DexOpt。DexOpt的执行过程是在第一次加载Dex文件的时候执行的。这个过程会生成一个ODEX文件,即Optimised Dex。执行ODex的效率会比直接执行Dex文件的效率要高很多。

但是在早期的Android系统中,DexOpt有一个问题,DexOpt会把每一个类的方法id检索起来,存在一个链表结构里面。但是这个链表的长度是用一个short类型来保存的,导致了方法id的数目不能够超过65536个。当一个项目足够大的时候,显然这个方法数的上限是不够的。尽管在新版本的Android系统中,DexOpt修复了这个问题,但是我们仍然需要对低版本的Android系统做兼容。

在Android 5.0之前,为了解决这个问题,Google官方推出了这个类似于补丁一样的 support-library, MultiDex。而在 Android 5.0及以后,使用了 ART 虚拟机,原生支持从 APK 文件加载多个 dex 文件。

使用方法

以下是在 minSdkVersion < 21 的使用方法。

  1. 配置build.gradle

     android {
     
         compileSdkVersion 21
         buildToolsVersion "21.1.0"
     
         defaultConfig {
             ...
     
             // Enabling multidex support.
             multiDexEnabled true
         }
         ...
     }
    
     dependencies {
       compile 'com.android.support:multidex:1.0.3'
     }
    
  2. 继承 MultiDexApplication

     public class MyApplication extends MultiDexApplication {
       // ...........
     }
    
  3. 如果不想继承 MultiDexApplication ,可以重写 attachBaseContext 方法

     @Override
     protected void attachBaseContext(Context base) {
        super.attachBaseContext(base);
        MultiDex.install(this);
     }
    

反之,如果 minSdkVersion >= 21 ,只需要以下配置即可。

    android {
        defaultConfig {
            ...
            minSdkVersion 21 
            targetSdkVersion 28
            multiDexEnabled true
        }
        ...
    }

MultiDex 原理

  • 类加载机制系列3——MultiDex原理解析
  • Android使用Multidex突破64K方法数限制原理解析

简单地来说,MultiDex 做的事情就是:

  1. 解压得到 dex 并进行 dexOpt ;
  2. 把主dex文件除外的 dex 文件都追加到 PathClassLoader 中 DexPathListde Element[] 数组中

熟悉组件化、热修复的同学肯定对这些已经了如指掌了吧。

MultiDex 的局限性

Dalvik 可执行文件分包支持库具有一些已知的局限性,将其纳入您的应用构建配置之中时,您应该注意这些局限性并进行针对性的测试:

• 启动期间在设备数据分区中安装 DEX 文件的过程相当复杂,如果辅助 DEX 文件较大,可能会导致应用无响应 (ANR) 错误。在此情况下,您应该通过 ProGuard 应用代码压缩以尽量减小 DEX 文件的大小,并移除未使用的那部分代码。

• 由于存在 Dalvik linearAlloc 错误(问题 22586),使用 Dalvik 可执行文件分包的应用可能无法在运行的平台版本早于 Android 4.0(API 级别 14)的设备上启动。如果您的目标 API 级别低于 14,请务必针对这些版本的平台进行测试,因为您的应用可能会在启动时或加载特定类群时出现问题。代码压缩可以减少甚至有可能消除这些潜在问题。

• 由于存在 Dalvik linearAlloc 限制(问题 78035),因此,如果使用 Dalvik 可执行文件分包配置的应用发出非常庞大的内存分配请求,则可能会在运行期间发生崩溃。尽管 Android 4.0(API 级别 14)提高了分配限制,但在 Android 5.0(API 级别 21)之前的 Android 版本上,应用仍有可能遭遇这一限制。

第一个问题的解决方法

Facebook 提出一种加载方案:将 MultiDex.install() 操作放在另外一个经常进行的。

让 Launcher Activity 在另外一个进程启动,但是 Multidex.install 还是在 Main Process 中开启,虽然逻辑上已经不承担 dexopt 的任务。
这个 Launcher Activity 就是用来异步触发 dexopt 的 ,load 完成就启动 Main Activity;如果已经loaded,则直接启动Main Process。
Multidex.install所引发的合并耗时操作,是在前台进程的异步任务中执行的,所以没有 ANR 的风险。

在 Facebook 的这个方案基础上,其实你不知道MultiDex到底有多坑 给出了一个优化后的方案。

闲聊MultiDex_第1张图片
20190709001043.png

另外,还有美团、微信的解决方案,详见 Android Dex分包最全总结:含Facebook解决方案

第二个问题的解决方法

现在开发的应用 minSdkVersion 一般都设置为 Android 4.1 。所以 API 低于 14 的不需要考虑了。

现在应该不存在哪个应用丧心病狂地向下兼容适配到 Android 2.X 了吧?

Reference

  • 配置方法数超过 64K 的应用
  • 类加载机制系列3——MultiDex原理解析
  • Android使用Multidex突破64K方法数限制原理解析
  • 其实你不知道MultiDex到底有多坑
  • Android Dex分包最全总结:含Facebook解决方案

你可能感兴趣的:(闲聊MultiDex)