相信很多人再开发过程会遇到方法数超过65535的问题，通过学习我们通过一个简单的例子利用Android的插件化开发去解决这个问题。所谓插件化就是由宿主APP去加载以及运行插件APP。
下面是一些插件化的优势：
1.模块解耦
2.解除单个dex函数不能超过65535的限制
3.动态升级
4.高效开发(编译速度更快)
下面是插件化开发的缺点：
1.插件化开发的APP不能在Google Play上线，也就是没有海外市场。
2.技术有难度，目前一些成熟的框架都是闭源的
下面开始通过一个简单的demo 实现Android插件化开发（类似支付宝中在未安装滴滴软件的情况下能够跳转到滴滴的页面）
我们通过简单的图片设置到页面验证跳转是否成功
1、首先我们创建一个宿主工程->MainActivity
用一个点击事件做插件的Activity的跳转。
2、创建一个插件工程module->MainActivity(一定要是module不是Android library)
3、创建一个插件遵循的标准工程library（DidiInterface 和 BasePlugActivity）
例如 滴滴想要在支付宝上集成，那么就必须遵循这个标准做事
创建一个 BasePlugActivity类 实现接口
紧接着插件的MainActivity去继承这个BasePlugActivity。
看似以上代码并没有什么问题，我们平常写的最简单的代码不就是这样的吗？
其实坑马上就来了。我们知道 setContenView以及 findViewById都是调用系统提供的上下文的，（包括BasePlugActivity中的类似onCreate都是调用系统的 super.Oncreate(saveInstanceState)）然而插件apk我们是没有安装的，所以凡是调用系统上下文的方法都是不靠谱的，我们必须都要重写他们。然后注入一个新的context.
好了，插件类也创建完了那么我们到底要怎么在宿主中去跳转到这个没有安装的插件Activity呢？既然要跳转那么第一步我们要做的可能是先去配置文件中注册这个类。那么在宿主项目中并没有这个Activity那么我们要怎么实现以上的需求呢？
其实，除了Hook我们还可以用插桩的方式，通过一个代理类专门做类的跳转。
我们在宿主项目中创建一个ProxyActivity，我们知道加载一个页面除了要加载它的ClassLoader 还要重写它的getResources。
所以首先我们创建一个管理单例类 ProxyManager专门去做这些东西
解释下：DexclassLoader
在Java环境中,有个概念叫做”类装载器(Class Loader)”,其作用是动态加载Class文件.标准的Java SDK中有一个ClassLoader类,借助他可以装载想要的Class文件,每个ClassLoader对象在初始化的时候必须指定Class文件的路径.
但我们在使用java的时候,基本上没有使用过ClassLoader,仅仅使用import就可以加载类文件了,简单的讲,import中所引用的类文件有两个特点:
1:必须存在于本地,当程序运行需要该类的时候,内部类装载器会自动装载该类,这对程序员来说是透明的,即程序员感知不到该过程
2:编译时必须在现场,否则编译过程会因找不到引用文件而不能正常编译.
但在有些情况下,所需要的类却不能满足以上两个条件.比如当该类是从远程下载并在本地执行的时候,典型的例子就是通过浏览器中的AppletLet执行的java程序,这些要执行的程序是在服务器端.另一种情况是,要引用的Class文件不方便在编译的时候直接参与,而只能在运行时动态调用.例如,在Android Framework中,所包含的Class文件是一些通用的类文件,但对于一些设备商而言,他们需要扩充Framework,扩充的具体工作包括两点:
1:需要增加一些额外的类文件,这些类文件提供厂商自定义的功能,这些文件一般以独立的jar包存在
2:需要修改Framework中的已有的类文件,比如WindowManagerService类,在该类中添加使用自定义jar包中的代码.使用自定义jar常用的方法是使用import关键字包含自定义的类,但为了保持和原生Framework的兼容性,对原声Framework最少化修改,可以使类装载器动态装载自定义jar包.
这就是使用ClassLoader的原因.
在一般情况下,应用程序不需要创建一个全新的ClassLoader对象,而是使用当前环境已经存在的ClassLoader.因为java的Runtime环境在初始化时,其内部会创建一个ClassLoader对象用于加载Runtime所需的各种java类.
每个ClassLoader必须有一个父ClasLoader,在装载Class文件的时候,子ClassLoader会先请求其父ClassLoader加载该Class文件,只有当其父ClassLoader找不到该Class的时候,子ClassLoader才会急促装载该类,这是一种安全机制.
对于Android的应用程序,本质上虽然也是用Java开发,并且使用标准的Java编译器编译出Class文件,但最终的APK文件中包含的确实dex类型的文件.dex文件是将所需的所有Class文件重新打包,打包的规则不是简单的压缩,而是完全对Class文件内部的各种函数表,变量表等进行优化,并产生一个新的文件,这就是dex文件.由于dex文件是一种经过优化的Class文件,因此要加载这样特殊的Class文件就需要特殊的类装载器,这就是DexClassLoader.Android SDK中提供了DexClassLoader类就是处于这个目的.
转至 DexClassLoader的使用 - hongbochen1223的专栏 - CSDN博客
创建DexClassLoader 需要四个参数，分别代表的意义：
1:dexPath,指目标类所在的APK或jar文件的路径.类装载器将从该路径中寻找指定的目标类,该类必须是APK或jar的全路径.如果要包含多个路径,路径之间必须使用特定的分割符分隔,特定的分割符可以使用System.getProperty(“path.separtor”)获得.
2:dexOutputDir,由于dex文件被包含在APK或者Jar文件中,因此在装载目标类之前需要先从APK或Jar文件中解压出dex文件,该参数就是制定解压出的dex 文件存放的路径.在Android系统中,一个应用程序一般对应一个Linux用户id,应用程序仅对属于自己的数据目录路径有写的权限,因此,该参数可以使用该程序的数据路径.
3:libPath,指目标类中所使用的C/C++库存放的路径
4:最后一个参数是指该装载器的父装载器,一般为当前执行类的装载器
这里我们可以把libPath置为null。
创建Resouces时我们需要AssetManager。
通过源码我们可以查看到addAssetPath这个方法和AssetManager的构造方法注释上面都有{@hide},这个表示我们不能在应用层直接调用,如果我们还是要调用的话就需要用到反射:
写完工具类，现在我们转到宿主的MainActivity中，我们需要跳转到特定的activity中，将ActivityName传递给proxyActivity。那么我们要怎么得到这个类名呢？
我们在ProxyManager中通过context得到packmanager从而获取
最后我们将插件apk导出来，然后放入宿主项目中的assert文件夹底下，写入我们手机sd卡下，这一步模拟的是插件apk的下载
好了，结束了以上的步骤我们就可以运行下看看到底跳是否成功？
然后点击了宿主页面后确实一片空白！不过索性没有出现页面崩溃和无法跳转的现象，这说明我们的做法是没有问题。那么问题到底出来哪里呢？
我再来看下这个代理类。似乎没什么问题？ 实际上我们界面显示以及显示后能够交互是走了生命周期的onStart()以及onResume的方法，换句话说这个代理类实际上就是一个空壳 显示不了界面。
那么我们就得去执行它的生命周期方法，至少要执行 onCreate()、onStart()以及onResume。我们同样的可以通过反射的方式得到这个Activity以及它的构造方法。
我们可以看到object被强转成了一开始的 interface,实际上这里的生命周期都可以通过反射的方式去执行，但是一开始我们就制定了interface的规则，所以这个时候这个规则就派上了用场
我们重新运行下代码看下情况。
以上就是插件化的一个小例子，其实它的用到的无外乎是反射，DexClassLoader等机制。
动态换肤：https://blog.csdn.net/MAGIC_JSS/article/details/52403778?utm_source=blogxgwz5