360的Replugin框架研究案例
由于官方Replugin是没有适配AndroidX项目的，所以此Demo对Replugin2.3.3的Release版本进行了AndroidX的改造，具体改造点参考：Replugin适配AndroidX
Demo结构：
- host：宿主project，用来加载插件、调试插件；
- library：用来生成test.jar的module，生成的test.jar作为宿主和插件的中间桥梁，实现宿主和插件的通信；
- plugindemo1：插件project，用来生成给宿主使用的插件apk；
- plugindemo2：插件project，用来生成给宿主使用的插件apk；
- replugin-host-gradle：host插件库
- replugin-host-library：host依赖库
- replugin-plugin-gradle：plugin插件库
- replugin-plugin-library：plugin依赖库
- RepluginHostLocalRepo：replugin-host-gradle编译后生成的本地host插件库，host就依赖该本地库进行编译的；
- RepluginPluginLocalRepo：replugin-plugin-gradle编译后生成的本地plugin插件库，plugindemo1就依赖该本地插件库进行编译的。
参考资料：
- 官方项目：RePlugin
- 参考项目：RePlugin-AndroidX
前面的原理分析已经讲述了 replugin-host-gradle、replugin-host-library、replugin-plugin-gradle、replugin-plugin-library的一些原理，下面会结合本demo去实践一下Replugin的具体使用方式。
- host
host 是本项目的宿主project，集成了Replugin的 replugin-host-gradle插件库、replugin-host-library依赖库，是用来调试各个插件的功能。
将plugindemo1和plugindemo2打包生成的apk作为插件放置在host的assets文件夹中，作为host的插件进行使用。
- library
library 是用来生成 test.jar 的库，本身和其他几个库没有任何依赖关系，只是提供 test.jar 给host和plugindemo1作为中间桥梁。
- plugindemo1
编译生成的APK作为host的插件进行使用，集成了Replugin的replugin-plugin-gradle插件库、replugin-plugin-library依赖库。
complieOnly 依赖了 test.jar，为了骗过编译期，从而让宿主可以使用 test.jar 里面的接口去调用 plugindemo1 里面的实现类，从而实现宿主和插件的交互工作。
- plugindemo2
编译生成的APK作为host的插件进行使用，集成了Replugin的replugin-plugin-gradle插件库、replugin-plugin-library依赖库。
complieOnly 依赖了 supportV4 库，为了骗过编译期，从而加载宿主的 Fragment.class ，这样就保证了宿主和插件的 Fragment.class 是同一个，从而让宿主可以加载插件的Fragment。
从上面原理分析可以看到，Replugin加载插件和宿主的使用的ClassLoader，是不同的ClassLoader，这就导致了使用的是相同的拓展库，并不能在宿主和插件中进行类型转换，会报 ClassCastException。除非插件使用compileOnly进行依赖，欺骗了编译期，从而会从宿主中去寻找该类。所以宿主初始化的一些对象或者属性，如果插件需要使用的话，还需要在插件再初始化一份，也就是将插件也作为一个可以独立运行的APP去打包。
将插件作为一个独立APP进行打包还是有个问题，就是臃肿，因为作为独立apk打包，依赖的库就比较多了，这样打包出来的插件甚至会和宿主差不多大小，所以需要尽可能的去减小插件的依赖，缩小插件的体积。
上面我们说了，插件使用 compileOnly 可以骗过编译期，从而去加载宿主的类。我们想让宿主加载插件的Fragment，则必须保证宿主和插件的Fragment.class是同一个对象，则需要插件使用 compileOnly fragment.jar 包去骗过编译期。这时候又存在一个严重的问题，使用 compileOnly fragment.jar之后，会导致 replugin-plugin-gradle 无法将继承 FragmentActivity 的子类的继承关系修改为继承 PluginFragmentActivity。因为 FragmentActivity.class 和 Fragment.class 是在同一个包里面，使用 compileOnly 编译的时候， 在插件APK里 FragmentActivity.class 就不存在了，所以 replugin-plugin-gradle 没有办法修改继承关系。这就导致了在插件里凡是继承了 FragmentActivity 的子类，都没有办法使用 startActivity() 等一些 PluginFragmentActivity hook住的方法。
解决办法：让插件的所有要继承FragmentActivity的都继承 PluginFragmentActivity，这样就符合了Replugin所需要修改的默认继承关系，但是耦合性太高。
我们在插件中，使用 startActivity() 是没问题的，因为 replugin-plugin-gradle 修改了继承关系，这样保证我们可以和宿主一样去启动Activity。但是有一些特殊的Activity启动方式，我在插件里做了实验，是无法正常启动Activity的（宿主中可以）。比如广点通广告SDK启动他们的广告页面，是使用下面这种方式启动的：
String className = "com.clark.learn.replugin.plugindemo1.TestClassNameActivity";
Class<?> aClass = Class.forName(className);
Intent intent = new Intent();
intent.setClassName(TestPendingIntentActivity.this, className);
PendingIntent activity = PendingIntent.getActivity(TestPendingIntentActivity.this, 0, intent, 134217728);
activity.send();
这种启动方式在插件里去启动插件自身的Activity是行不通的，估计是由于该启动方式越过了Replugin所Hook住的逻辑，默认去开启宿主的Activity了，从而异常崩溃了，暂时没有解决办法。
如果我们使用的插件里集成里宿主没有的第三方库，这就需要小心一点，因为第三方库的逻辑有可能和Replugin不太兼容，建议这类第三方库都交给宿主去集成，插件compileOnly去使用。
还有 ARouter 库的问题，插件的路由表和宿主的路由表没有办法进行通信的问题，都需要解决。