为什么要进行组件化
组件化可以增加代码复用，减少代码耦合，减少新人接入成本，提高开发效率
组件化架构如何设计
遵循六大设计原则
- 单一职责原则
- 开闭原则
- 里氏替换原则
- 迪米特法则
- 接口隔离原则
- 依赖倒置原则 之前网上盛传的添加标志位动态切换 apply plugin: 'com.android.application'和apply plugin:'com.android.library'的方式个人认为不符合开闭原则，且切换时的build耗时和AndroidManifest.xml文件维护两份，R和R2的包路径等问题，给开发本身添加了很多维护成本。 Hello组件化方案采用的是多工程+多model的组件化方式，简单易维护，而且也能很好的做到代码权限隔离，调试的时候只需要切换对应的进程就可以直接进行调试，不需要运行整个项目，大大减少编译时间。且在调试和业务变更的时候，严格遵循开闭原则。对修改关闭，对扩展开放。同时模块职责单一，基于IOC进行模块之间通信。
组件化需要解决的问题
1. 组件独立编译
直接上结构图，项目有两个独立的业务组件model1和model2。代表我们平常的业务model。额外建一个independent的java library，删除掉多余文件，新建两个android library分别为runmodel1和runmodel2.并且给这两个model声明单独的applicationId，runmodel1包含model1。则在开发调试时候可以直接运行runmodel1。且independent中的所有代码不会打包到apk中，可以放心进行各种调试。
2. Application的初始化和实例访问问题
Application利用的是框架中的AppSpec和ModuleSpec两个注解。同时设置支持优先级，支持按照顺序初始化。 原理是根据APT注解利用ASM字节码进行函数插桩。将所有被ModuleSpec标记的 application按照优先级统一放到moduleApplications。然后在app的application的生命周期方法调用的时候插入moduleApplications这个list中对应的要执行的方法的字节码。从而达到各个子model解耦初始化。 相比其他用反射在application初始化时候创建子application的方式，该方案将耗时从启动时提前到编译时，大大提升了启动效率 创建统一application基类，放到common组件中，在基类中对INSTANCE进行application赋值，解决组件中application实例访问问题
3. 组件通信问题
核心思想是IOC。新建router模块，在该模块中声明对应的接口，在具体的业务model1中去实现该类并完成对应功能，并用ServiceProvider注解对实现类进行标记。 借助ServiceProvider注解。编译时候将所有被该注解标记的实现类统一放到一个全局的集合中。则在模块之间使用的时候，则完全是接口的调用，不需要关心具体的实现逻辑。 这种依赖抽象，隐蔽细节的设计严格遵守依赖倒置原则 代码示例 public static AppService sAppService = AppJoint.service(AppService.class);
4. 跨模块跳转
Hello中activity和fragment之间的跳转并没有采用arouter的shceme-url这种方案，因为shceme-url也是基于intent去实现跳转，而且多了一层序列化和反序列化，且这种硬编码写法容易出错和不方便维护，缺少类型检查，activity名字更改或者参数变更等则牵一发而动全身。 本项目中不同模块直接跳转直接采用接口声明方式，简单高效。个人感觉适合自己项目的才是最好的，但是arouter中优秀的代码设计和针对组件化问题的各种解决方案是非常值得学习和研究的。
5. 组件关系依赖
一图胜千里。直接上图
项目地址 Hello
参考感谢： Android 组件化最佳实践
