关于 Android中的插件化开发，dex分包，热修复（Tinker）的思考（一）

插件化开发

优点：
一. 来可以将自己的应用分拆，某些功能可以在插件中实现，用到时再进行下载，而且不用安装. 如果有新功能的添加，不需要更新应用，只要预留插件管理，我们就可以通过添加插件的方式，动态更新自己的应用,该功能需要改进或扩展，更新插件即可，无需频繁安装或卸载(容易造成用户反感).

二. 对应同系应用，正常的引流方式只能引导用户进行新应用的下载和安装,如果使用插件化开发，则无需安装应用，关闭插件功能也十分方便，省去应用安装和卸载的过程,可以实现无缝引流.
三.避开65536个方法限制，模块化开发便于维护。

基本实现原理：
1.使用dexClassLoader加载未安装的APK。
2.代理模式之通过代理的Activity执行APK中的Activity，加载对应生命周期。
3.资源管理，通过反射调用AssetManager中的addAssetPath()方法获取插件中的Resource.

插件化开发简单的说就是DexClassLoader在程序A里面动态装载程序B中的类,并且来调用B程序中的方法.
插件化开发库：
https://github.com/Qihoo360/DroidPlugin/blob/master/readme_cn.md
https://github.com/houkx/android-pluginmgr
https://github.com/singwhatiwanna/dynamic-load-apk

dex分包

当一个app的功能越来越复杂，代码量越来越多，也许有一天便会突然遇到下列现象：

1. 生成的apk在2.3以前的机器无法安装，提示INSTALL_FAILED_DEXOPT

2. 方法数量过多，编译时出错，提示：

java.lang.IllegalArgumentException: method ID not in [0, 0xffff]: 65536

出现这种问题的原因是：

1. Android2.3及以前版本用来执行dexopt(用于优化dex文件)的内存只分配了5M

2. 一个dex文件最多只支持65536个方法。

3. 针对上述问题，也出现了诸多解决方案，使用的最多的是插件化，即将一些独立的功能做成一个单独的apk，当打开的时候使用DexClassLoader动态加载，然后使用反射机制来调用插件中的类和方法。这固然是一种解决问题的方案：但这种方案存在着以下两个问题：

   插件化只适合一些比较独立的模块；
   必须通过反射机制去调用插件的类和方法，因此，必须搭配一套插件框架来配合使用；

由于上述问题的存在，通过不断研究，便有了dex分包的解决方案。简单来说，其原理是
将编译好的class文件拆分打包成多个dex，绕过dex方法数量的限制以及安装时的检查，在运行时再动态用DexCla