最近这几天把项目中组件化的代码给去掉了，将项目逻辑代码重新合并到了一个 module中，去年6月份在项目中加入积木这个组件化方案还是费了一番功夫，好记性不如烂笔杆，所以就记录一下收获的知识。
当时考虑在项目中加入组件化的方案，完全是趁着这个技术的余热实践一把，也想给以后的开发打个基础，但是随着开发的进行，慢慢发现组件化并没有带来什么优势，反而有些地方还不够方便。
组件化的优势有两点：
一是方便并行开发：每个人或者团队负责各自的模块，理想状态下每个模块只有一个入口
二是在代码量级达到一定程度后在开发中可以减少编译时间，例如编译项目需要10分钟，可以把项目分成独立的模块，这样在开发调试过程中就大大减少了编译时间，提高了效率。
目前看来我们的项目在开发中并没有达到这样的要求，项目整体规模不大，每个人又有交叉开发的代码，代码编译时间也是1分半钟左右，而加入组件化之后代码阅读不够流畅，上手需要成本，反而额外增加了开发负担。
当初在选择使用哪种组件化方案的时候，也看过网上的比较，最终选择积木这个方案是因为这种方法是基于gradle插件来实现的，gradle本身是as的构建工具，功能强大，能够在基于一套代码的基础上打包出不同样式的代码，相互之间的切换也十分方便，积木本身也是利用了gradle的这个特点。最终组件化选择了积木，而路由选择了阿里的Arouter。
积木组件的原理是基于gradle插件开发实现的。因为as项目可以包含多个module，每个module都有一个build.gradle和gradle.properties文件，gradle构建的时候是读取每个module的配置文件，最终形成一个整体的配置文件（当初调试过这个插件，记不太清了，应该是这个流程），这就给编译哪个module不编译哪个module提供了可能，也切合组件的名称：积木，就像堆积木一样，需要哪个module就插入哪个，不需要就拔掉。
Arouter的原理是基于动态编译技术和gradle插件开发实现的，activity是这样，fragment的源码没看，可能还不一样。是在activity类中用注解做标记，定义一个注解名字，然后在编译时期扫描每个java类，找到做注解标记的activity，然后使用javapoet类库，生成一个路由表类，里面是个map，存放着activity注解的名字和对应的activity的class名字。在路由跳转的时候读取module下面的路由表类，找到activity的class名字就可以了，具体实现更复杂些。
最后放上jimu组件作者自己的文章Android彻底组件化方案实践 - 简书，里面写的非常详细，实在搞不懂的可以先熟悉熟悉gradle的使用。
