Android插件化方案
Android插件化的目的主要有两个，第一个是应对每个dex包65536个方法数的上限问题，第二是实现功能复杂的app的拆解，能够按需下载和加载运行所需的模块。插件化的实现并没有统一的标准或方式，很多公司都有自己的一套插件化方案，而且没有哪个公司的方案被业界普遍认可。本文将按时间轴的方式介绍几家比较有代表性的公司的插件化方案，供大家开阔思路。至于要选取那种方案为我所用，那就只有结合自己的实际需求实践比较得知。
Facebook是进行插件化开发尝试的鼻祖，早期Facebook安装包变大以后出现的两个导致安装失败的问题:
- Number of Java methods in our app more than 65536(64K), can't hold in one dex file.
- Large number of methods was exceeding "LinearAlloc" buffer and causing dexopt to crash
第一个错误是说方法数目超过最大数目64K，这是因为Android每个Dex文件的方法通过两个字节进行索引，两个字节能索引的最大数目就是64K。第二个错误是说单个dex包大小超出了Dexopt所能使用的最大缓存。Dexopt是将.dex文件进行优化，并转化成.odex的工具，所能使用的最大缓存跟手机相关，一般为8M或16M，如果dex包太大就有可能超出Dexopt所能使用的最大缓存，导致出错。
对此Facebook采取了两种方法来解决以上问题，总结如下：
- 将安装包拆分成多个dex文件，运行时通过DexClassLoader动态载入
- 找到Delvik虚拟机的缓存设置代码片段，替换成更大的缓存
后来，Google在Android里引入这种问题一的解决方法，MultiDex方法，并将其标准化（5.0以下版本，buildtools升级到21即可使用支持包)。使用步骤：
首先修改gradle文件，在defaultConfig里面添加multiDexEnabled属性，并修改dependencies：
android {
...
defaultConfig {
...
minSdkVersion 14
targetSdkVersion 21
...
// Enabling multidex support.
multiDexEnabled true
}
...
}
dependencies {
compile 'com.android.support:multidex:1.0.0'
}然后在Application的扩展类中重写attachBaseContext函数：
public class MyApplication extends Application {
//...
@Override
protected void attachBaseContext(Context base) {
super.attachBaseContext(base);
try {
// to resolve: java.lang.NoClassDefFoundError
MultiDex.install(this);
} catch (Exception e) {
e.printStackTrace();
}
}
//...
}该方法大部分情况下可行，但是存在几个问题：
- 理论上该方法只解决了64K的问题，如果拆分后的包超出了LinearAlloc的大小（Dalvik linearAlloc bug），还是会触发问题二导致crash
- 点击图标启动的时候既要对主dex文件进行dex的解压、dexopt、加载操作，又要对辅dex文件进行dex的解压、dexopt、加载操作，容易导致ANR错误，导致首次启动初始化失败
- mulitDex的App有可能在4.0以前的机器上无法启动，因为Dalvik linearAlloc bug
- 哪些class被放在主dex文件，哪些在辅dex文件可以由build tools搞定，但是如果你代码存在反射和native的调用也不保证100%正确
有些技巧可以缓解存在的上述问题：
- 尽量减少无用依赖
- 使用Proguard进行代码瘦身
- 通过gradle里--set-max-idx-number=48000参数减小每个dex最多容纳的方法数，写的小一点可以多产生几个dex文件
美团网
美团网对拆分dex包的过程进行了干预，并针对ANR错误进行了优化，他们要解决的三个问题以及采取的方案如下：
-
如何控制生成多个dex包 : 在gradle中定义一个task，控制生成多个dex包
-
如何控制哪些class放到主dex包，哪些放在辅dex包
- 把Service，Receiver和Provider以及依赖的class都放在主dex包中。Activity则进行区别对待
- 把首页Activity，欢迎页Activity等需要首先展现的Activity及依赖的class放到主dex包中，把二级，三级页面及以来的class放到辅dex包中
-
如何避免动态加载辅dex包导致的ANR错误
- 开启一个线程异步加载辅dex包。这样做潜在的问题是，在辅dex包加载完成前，如果启动了辅dex包里的Activity，会导致
- ClassNotFound的错误。所以在所有Activity启动前要做一个校验，如果试图打开Activity时辅dex包还没有加载完成，则给个
- 正在加载的提示给用户。他们研究发现Activity是通过ActivityThread的Instrumentation来启动的，其中跟Activity相关的方法包括execStartActivity，newActivity方法，所以在这两个方法里加入了校验过程，如果还没加载完就给用户展示个正在加载的提示
微信
微信团队也总结了一套自己的优化方案，他们针对动态加载辅dex包进行了自己的处理，微信主要修改了动态加载辅dex包的方式：
第一次加载辅dex包时需要进行dexopt操作，这个过程比较耗时，但是如果已经加载过一次再加载就会很快了，所以微信的策略是，第一次加载的时候在sharedpreference中写个标记，下次启动如果发现已经有该标记，直接往下走，否则在新开一个透明的Activity，这样这个Activity就是前台进程，主进程就不再是前台进程，也就不会出现ANR错误了。流程如下：
微信动态加载Dex文件流程
携程网
携程网为了实现插件化并行开发，借鉴前辈们的思路开发了一套自己的插件化方案DynamicApk，他们不仅实现了dex包的拆分和动态加载，更重要的是，他们实现了多个插件apk独立并行开发，以便多人协作开发。
面临的问题及解决思路：
- 编译期：资源和代码的编译
- 每个apk指定不同的标志位
- 引用宿主base.jar
- 运行时：资源和代码的加载
- 访问不同的资源根据标志位去不同apk加载
- pathList追加dex路径
实现思路：
- 针对插件子工程做的编译流程改造
- 运行时动态加载改造
实现方式：
- 对aapt工具的修改
- gradle打包脚本的实现
- 运行时加载代码的实现
上面介绍的几家公司的插件化技术可以分为两类：多dex方案和多apk方案。这两种方案异同总结如下：
- 相同点
- 都可以把一个大工程拆分成多个组件（多个.dex文件或多个apk文件）
- 都可以做到使用哪个功能就按需动态加载那个组件
- 不同点
多dex文件方案
- 需要各个小组在一个工程下开发
- 所有代码合起来编译，编译生成一个apk包，该apk包含多个dex文件
- 各个dex文件只包含类文件，不包含资源文件
- 所有类一起编译，编译完了再拆分成不同的dex文件
- 运行时，资源都从主dex文件加载；代码加载靠往pathList上添加dex路径
- 编译时间长 多apk的方案
- 每个组有自己独立的工程
- 每个组各自编译生成自己的apk包
- 各个apk包都既包含资源文件，又包含类文件
- 各个apk包要考虑资源怎么编译（分配不同的标志位），代码怎么编译（引用宿主base.jar)
- 运行时，资源的加载根据不同的标志位去不同apk中加载；代码加载靠往pathList上添加dex路径
- 编译时间短
两种方案如何选择：
- 多dex方案不需要额外的编码规范，但是需要人工控制拆包的过程，成本略低
- 多apk方案可以节约很多编译时间，使用该框架需要遵循一定的编码规范，成本稍高
- 多dex方案成本低，编译时间长，多apk方案成本高，编译时间短
- 实践来检验谁更好
其他技术方案 360的 DroidPlugin开源框架
- 可以在不对插件apk做任何修改的情况下运行没有安装在手机上的apk，因为绕过了用户授权，颇具流氓色彩，被成为安卓黑科技
- 代码很乱，实用性有限
Xposed
- 可以Hook所有app的函数或系统函数
- 实现系统或app层级的特效