入职ZTC接近两年，因为业务繁重，从入职开始一直在做业务上的需求，项目还是MVC模式开发，由此可见工程的耦合度极高，也是众多反锁的业务互相关联导致最初开发的时候没有很好的设计架构。经过大半年的边重构项目边合并老项目新需求的开发，见证了开发团队一路走来的努力，Android团队也在自己预期的想法中向前迈进。
前言
在公司的发展方向上，由单一的求职平台，到人脉社交，问答社区的扩展，让我察觉到组件化必然是正确的演进方向。在项目gradle升级到3.x后，依赖隔离的新特性更是帮助我对组件化的推进工作。
组件化优点
在现在的大环境下组件化的优点相信大家都比较熟悉。
- 高内聚，低耦合，代码边界清晰，每一个组件都可以拆分出来独立运行
- 功能集中，每一个组件负责属于自己组件的工作，不受其他组件影响也不影响其他组件功能
- 提高开发效率，每个组件可单独调试，保证代码质量
- 减少重复造轮子和维护工作量
- 加快编译速度，最理想的情况是，App工程仅仅是一个空壳，用于加载各个组件
组件化方案
现在GitHub上面流行着各大家公司开源的路由库，他们基本采用组件化的方案是
这个是比较通用组件化的一个方式，当然不同厂有着会根据自己的实际情况进行改造流程，但是基本大同小异，我们五花八门讨论得最多的是不同业务组件的路由通讯协议封装，我们将一个个业务组件细化拆分，不可能最后是互相直接依赖使用导致各种混乱和耦合，我们此时需要的是路由，它帮我们管理各业务组件间有序地通讯，路由重点划一下:事件分发和动态拦截。
我第一期组件化的工作方向是功能模块化与业务组件化相结合。这是因为我们项目是一直遵循着模块化，对功能的整理比较好，我这边不对每一个业务进行拆分组件化，也就是不采用现很热门的路由通讯方式，因为如果我将项目弄成完全组件化，是过度封装了，导致开发成本不协调，然而目前我们首要处理的问题是业务组件复用问题，所以避免我们重复造轮子，我们先将咨询组件、支付组件、定位组件、网络请求组件、推送组件进行分离，同时优化封装图片加载库、普通工具库、Banner工具库、友盟第三方库、图片选择库、JSBridge库、地图库等非业务性的基础库。
总结
组件化的推进工作，从简单的分离代码，里面帮助我们更好地梳理了陈旧代码，及时整理好wiki。到享受面向过程、面向对象、面向接口、面向切面的编程乐趣。
展望
到了最后，这次组件化构架演进，只是一个开始，就如一开始所说的，将来会有一天多款App会进行整合，我个人推荐的是通过插件化的方式加载对应的业务模块，在前段时间官方所推出的动态化框架Android App Bundles更适合未来的发展。另外在未来大前端完全介入商城日常开发，架构还会继续进行调整。以上是我的简单总结和对模块化的一些尝试，不足之处还望大家交流指正。
