什么是插件化框架
插件化框架可以在主程序不重新安装的情况下，针对单个业务模块进行加载达到模块更新的目的，整个加载更新过程，对用户来说也是无感知的。
正式因为这样，新需求比起传统更新方式覆盖率和覆盖速度都会更高和更快，对于大型开发团队，各个业务模块开发小组组也不需要再等所有组的需求开发完统一发布版本，发版本可以单独针对小组内单个功能发布了，有了这些优点才使得这1年来插件化框架如此流行的重要原因。
目前网上流行的主流的插件化技术核心主要分两类：
一类是360公司开源的DroidPlugin，特点在宿主程序上打造一个纯粹的环境，可以让一个个普通apk（插件）不安装就可以正常使用，并且插件之前资源和代码都是相互独立互相不干扰也不能访问，为了达到这样的目的，框架hook了大量的系统api。
另一类是从dynamic-load-apk 开始，通过反射少量api，达到插件代码和资源与宿主合并，达到相互调用的结果，目前大部分都是框架从底层代码合并和资源合并用的手法都差不多，只是各个框架在这基础上对插件化的理解不一样，为各自的项目做了不少的业务封装。
常用的类加载方法是：
常见的资源加载方式是：
目前看来怎么加载代码，怎么加载资源、怎么动态声明和启动android组件。网上大部分开源的开源框架都很好的解决了这些怎么实现的问题，很完美的做到了从0到1。但是对于一个有几十个开发人员千万级别的大型的app来说，单解决了这些问题还是不够的。插件框架的稳定性、从原有代码到插件化的迁移成本、后期维护成本等等方面都需要考虑到。
所以兼容性、迁移成本、后期维护成本是我们在插件化选型时最基本的考虑因素。
首先兼容性、后期维护成本，大家都了解到由于android系统的碎片化，android官方提供的api也存在着不少的兼容性问题，况且针对创新能力如此强大的国内手机厂商，国产手机也额外的多了不少兼容性问题。
具体例子：常用到的资源加载方式，放在vivo的部分手机就不能使用原因是其ROM把系统的Resources封装成为了VivoResources直接导致了反射失败插件资源无法加载，同样的Nubia的部分手机也是。所以基于这样在做插件化的时候hook系统的api就应该尽量的少，因为hook的api不确定性太多了，而且在这部分的开发过程肯定不会有任何文档提供参考的，遇到问题就干撸代码吧。
处理兼容性的工作量越大其实后期的维护成本就越高，至少如果android一个新版本出来了首先要看的是之前hook的官方api有没有被改掉。如果有问题还要再针对新的版本寻求新的实现，这部分工作量是非常大的。这也是我们不选择DroidPlugin的重要原因，从网上的能找到的所有资料并没有看到DroidPlugin的兼容性能达到多少能适配多少台手机。但是预判一下DroidPlugin hook了大量的api比起其他框架hook两个，这部分后续维护成本也是足够喝一壶的。
迁移成本，其实很多大型的项目实现插件化，在这个调整的过程中对代码结构，调用逻辑等等的修改肯定是有的。怎么保证这个改动是最少的，也是我们的考虑之一毕竟有改动就会产生bug,比较幸运的是，我们从打包脚本上下手在保证传统的项目结构和逻辑调用不改变的情况下实现模块插件化。让插件化先跑起来，在实现之后再让各个业务小组针对插件化的建议慢慢的完善和封装插件和宿主之间的协议和约定。
插件化迁移过程：
首先，看看我们酷狗原有的基础项目结构：
项目底层是一个公用library 提供大部分的公共的基础模块，酷狗作为application作为主程序，其他听看唱其他业务模块也作为一个个library,各个业务组关联公共模块和酷狗主程序，在各自的业务模块下开发、调试。当发版本的时候就统一在打包平台上让酷狗关联所有业务模块 然后统一打包，这是最常见的项目组成架构业务模块有项目级别的代码分离而且业务项目依赖公共基础库。
项目优化目标
优化后，业务组之前的开发方式完全不变，项目结构对比优化前完整保留，打包之后每个业务模块是一个个插件可以单独加载运行，每个插件都是只包含插件自己的资源和代码（不包含公共库），插件可以正常访问宿主的资源和代码，只要宿主保留了插件所需的资源和代码，无论宿主怎么改变都可以启动插件。
在这个过程中主要需要解决的问题有：
打包插件只保留插件本身的代码，打包后插件不改变任何调用逻辑能顺利调用回宿主逻辑。
决插件和宿主资源冲突问题，插件只保留本身资源，插件能访问到宿主资源。
重新编译之后怎么保证旧的宿主能支持新的插件。
首先怎么把原来跟底层项目依赖的业务模块 单独打成一个插件包 只保留业务模块的代码
我们拿听模块做个例子先编译宿主程序也就是酷狗项目和底层基础库，一直编译完javac这时候主项目资源R.java和映射表都可以得到，然后把编译出来的class打包成common.jar把common项目资源复制到一个空壳项目commonres。
接着修改听项目的属性把它从一个library变成一个application，关联让它不直接关联基础库，而是让它关联 commonn.jar 和 commonres，其中common.jar做提供编译。
按照这样编译下去，听项目编译出来的apk就只包含自己的代码了。
接下来解决资源问题,正常的资源查找方式
应用层获取资源 是用资源id直接去获取，Resources先根据我们的id去资源映射表去查找这个资源的名称是，拿到资源名称不对应文件的资源只需要执行从资源ID到资源名称的转换即可，而对应有文件的资源还需要根据资源名称来打开对应的文件。经过反射 resources 里面包含了多个映射表的目录，查找的时候会按照顺序先查宿主再查各个插件的映射表。
资源冲突问题因为上面项目结构调整之后，插件和宿主都是application编译时候就会出资源id相同，插件做资源id查找的时候就会有可能查找到宿主的资源，所以只要修改了resources.arsc和代码层用到的R.java的id就可以解决冲突了常见的修改方式是修改插件的id的pp段。
程序编译到这里，修改关联后的插件项目还保留了一份commonres资源，跟宿主的程序上的是一摸一样的，能不能修改资源id来解决呢，答案是肯定的,因为插件和宿主查找资源的逻辑是一样的，只要插件代码调用中相同的资源id即R.java里面的id,修改为宿主资源id，资源查找的时候就会顺利的到宿主的resources.arsc去查找资源了。
最后，删除插件resources.arsc多余的资源id和插件多余的资源文件。这样下来 最终得出的插件包 就是只含有插件代码和插件资源的 而且还能随意访问宿主资源和代码。
最后我们看看整体的编译流程。
与微信资源混淆工具的兼容性问题
插件化工具主要在编译时修改ID和去除其他多余资源，资源混淆工具主要是把名称和路径改短不修改ID，所以并不冲突。
只要保证读写操作都是严格按照 resources.arsc 的格式去写就可以了。
接下来最后一个问题,重新编译之后怎么保证旧的宿主能支持新的插件,简单说就是多程序怎么一起 做代码混淆,怎么保持宿主的资源ID。
多项目一起混淆：
我们选择的是统一做混淆，为什么不能先混淆整体混淆一个项目然后再混淆第二个项目的时候保持用上个项目的mapping 继续混淆,一直这样编译下去？
主要因为插件和宿主公共库之间并没有固定接口，单独混淆原来直接关联调用的方法就会被混淆移除掉。
我们还记得插件模块和common基础模块本来就是直接关联、直接调用的，后面我们改变项目结构让插件独立出来了，但是这部分调用还是存在的。
一旦单独混淆他们之间关联的代码就会被移除掉，宿主公共库的final静态变量混淆后也会消失，插件也没法调用得到。
其实正常来说，宿主和插件之间的调用本来就是需要先有固定的接口做好解耦 规范好所有的调用，宿主提供一套完整的api给插件使用，然后混淆的时候 keep好各自边界 。 这样对于后续插件版本更新和管理才是最正确的。
为什么这个问题到现在才聊呢，因为让各个业务模块组为了插件化然后去封装接口，等他们解耦封装好才来做的话时间太长了，所以我们先用这种方式让他们不需要做任何封装和解耦就能用，后续再要求他们慢慢的规范好这部分的接口。
怎么keep资源问题
我们知道资源id的生成是按照资源名称随机生成的，一旦添加或者修改了某个资源名称所有的资源id都有可能改变。 如果不能固定资源id 每次编译都id都变的话插件也无法下发给用户使用。
解决方案是在编译的时候根据宿主R.java的生成ids.xml和public.xml下次编译把ids.xml和public.xml放到宿主的/res/value目录下编译可保持id不变，这样即使下次宿主的其他资源改变了，只要插件用到的所有资源没有改变，新打出来的插件 一样是可以给旧的宿主使用的。
到这里一个完成的插件包已经出来了，剩下的就是 按照基本的加载方式，把这个插件加载进去就顺利完成了。
最后在宿主实现插件管理功能，这部分纯粹就是基本的业务逻辑了。
下载校验插件差异包。 （我们生成新的插件包上次到服务器，服务器就会与原始插件做差异对比，然后生成文件级别的差异文件，下发给用户）
合并差异包对比插件版本号。
加载前黑名单和白名单检验。（某些插件版本必须强制加载，某些强制不能加载）
启动时加载插件资源映射表。（保证一启动就可以查询到所以资源，而且这个反射效率很高，不耗时，也不耗内存速度也很快）。
插件代码选择合适时机懒加载。 （因为加载dex的时候，需要耗时，5.0以下做opt,5.0以上做oat,而且时间还不短，所以需要挑合适的时机做懒加载。）
最后，本文主要是我们在插件化过程中遇到一些问题的解决方案，其实每个解决方案都会有各自的取舍，也无谁优谁劣，如有更好的方案欢迎下面留言交流。
