插件化

1、插件化的来由

65536/64k

从技术上说，业务逻辑的复杂，导致代码集聚地膨胀，当方法数超过65536后就无法创建新的方法。

从功能上来数，功能模块的解耦，以及维护团队的分离，其实是大势所趋，每个团队都会维护app中不同的业务模块，如果每个模块升级都需要对整个app进行升级，效率会很低。

h5、hybird虽然可以解决，但在性能上比不了native的app，Facebook推出了runntime native框架，国内比较流行插件化。插件化能使我们的体验更好，因为使用的都是native的。

2、插件化要解决的问题

①动态加载apk：会有一个速度程序，会动态地从指定的sd卡中动态地进行加载apk

②资源加载：都是通过assetmanage这个类来加载的。不同插件对资源是如何管理的？是公用同一套资源还是使用独立资源？有很多种方法。有的方案会设定一套资源，并采用资源分段解决冲突。另外还建议独立资源，国内最近比较成熟的插件方案，比如adl（AndroidDynamic Loader）、DroidPlugin对fram work层进行了操作

③代码加载：不是把类加载进来就能操作，因为不能管理生命周期

3、类加载器

主要是通过反射获得方法和对象来进行操作的

DexClasLoader:可以加载apk中的字节码

PathClassLoader:只能加载文件目录中的apk

4、原理

①通过ProxyActivity来进行操作，利用反射得到类与其相关的方法进行操作。

setProxy方法实际上是调用了onCreate方法

②在基类中进行相应的操作

如果有setProxy方法，则走setProxy热更新方法，否则执行onCreate方法

③程序的入口MainActivity

没有xml文件，因为该文件读取不到了。

当执行点击事件后会通过startActivityByProxy来开启activity

④基类中就是根据proxy来进行判断，如果有的话则跳转到相应的apk，如果没有的话则开启默认的apk

5、资源加载：

apk没有打包的话，是不能加载资源的。从一个apk调用另一个apk，最大的问题是如何访问资源。

①这里主要是通过AssetManager来进行资源加载的，由于这是一个隐藏的api，所以通过反射的方式来加载资源

②代码的方式

通过反射获取与生命周期有关的方法，然后将这些生命周期和代理的生命周期进行同步

这样就可以作用到onActivityResult这个方法中，并在onResume、onPasue中通过反射关联相应的方法

6、代码加载

首先要绑定到activity相关联的生命周期，然后通过生命周期的反射方法来进行相关的回调

类加载器、生命周期、反射是插件化永远离不开的