APP插件化模块解耦

一、使用插件化对app模块拆分的背景

上次写了一篇SDK热更新的设计与实践，和本文插件化技术点是一样的，不过热更新SDK是独立产品，并没有通用性，部分同学看完后建议我写篇通用性的文章讲讲插件化技术在APP业务模块解耦的实践。

一个app随着业务代码量剧增，都无可避免的会遇到新的问题。

常见的问题主要有：

• 一、在兼容android低版本（anroid4.4以下）时出现方法数爆棚，这个此处不做过多解释。

• 二、在遇到上述问题后采用android官方提供的mutildex方案时，各业务模块依赖复杂，堪称依赖地狱，早期架构设计并没有考虑到这种复杂的承载量后期新业务太多没有时间重构导致解耦设计太差，代码shit一样不堪入目更不堪维护

• 三、基于第二条的解决方案是基于module的常规组件化，依赖和解耦做到了，模块也独立了，业务上做到了解耦，但重复依赖的本质问题依赖没有解决。

• 四、基于常规组件化后，大部分复杂依赖关系的解析工作依然是交给了buildTools，势必还是卡卡卡（此处虽有办法优化一部分，但成本较高，得不偿失），使用组件化后依然难以避免宿主编译时间的魔咒，项目代码量过大，项目编译时间从1分钟编程2-5分钟，即使开启了install run速度依然没有显著提升

PS:小道消息，听说新版的install run和android studio2.3推出后编译速度会得到显著改善（依我经验看，自as1.5之后越来越卡的尿性，并不太看好）

基于以上原因，插件化能完美的解决上述所有问题，达到最终效果是

• 一、无需关心方法数，无缝兼容android低级版本

• 二、无需关心模块的内部实现，只需要了解如何输入如何输出（路由跳转）

• 三、无需关心重复依赖，和常规开发基本无异

• 四、绝杀技！！！产品经理最爱：修BUG，动态发布版本

二、插件化、组件化、宿主、插件分别是啥

1、插件化技术中有什么术语？搞清楚宿主和插件的关系，

宿主：需要编译打包发布的

插件：需要内置或者动态下载，动态安装的

2、模块解耦有什么术语

• 插件化：插件化是一种技术术语，android系统的设计就是完全的C/S架构，应用层是完全的插件化设计的，比如launcher是宿主，所有安装的app都是插件，系统自带的app就是内置插件，用户安装的app就是运行时安装的插件。

• 常规组件化：组件化在android技术发展过程中还属于新词，主要是业内大佬因为android官方的支持愈发给力而对黑科技的插件化的嗤之以鼻产生的新的解耦思路，其实和插件化是不冲突的，这里我把这个组件化叫做常规组件化，就是不使用任何黑科技手段达到的解耦的一种思路，本文后期说的组件化都是指常规手段的组件化。

• 基于插件化的组件化：就是在常规组件化后对模块组件进行插件化

原文链接：http://www.apkbus.com/blog-719059-63329.html