从零开始Android组件化改造（一） - 总体架构
我的Github：https://github.com/BzCoder
最近准备对Android项目的组件化改造写一个系列心得，同时也对本轮学习的一次记录，会尽量写的细一点，也是对知识的巩固。
尤其要感谢@JessYan大神的ArmsComponet框架。
在本章中不谈具体代码，只谈总体思路。欢迎各位在简书下留言。
前言
去年熟悉了一整个SpringBoot，SpringCloud生态，说实在很多后台开发的思想是值得Android开发借鉴的（AOP，IOC，以及面向接口编程的思想），受益匪浅。
这段时间公司里提出要将原有APP进行组件化改造，以适应之后更加丰富的需求以及代码的解耦，以及多app的模块复用。其实后台模块化开发已经实现了很久，加上后台开发有注册中心的概念，模块管理十分灵活。当然Android开发依旧可以借鉴后台的开发模式。我作为公司的老安卓，自然挑起了这个担子，对APP进行组件化重构。
本次组件化改造的几个目标：
- 分离业务模块，减少不必要的耦合，方便模块的拆卸增减。
- 独立模块单独编译，方便开发人员的开发。
- 通过后台配置一键生成APP（Git + Jekins持续集成）。
- 实现同一个项目多应用差异化打包。
组件化开发相比原来的All in One模式，要考虑多方面的问题，我主要罗列了以下几点：
组件化主要需要解决的问题：
- gradle的管理
- manifest的管理
- 模块之间的分层边界
- 模块间的通讯与调用
- 各个模块网络请求的管理
- 各个模块的生命周期
- 不同模块的屏幕适配
需要学习的第三方框架原理和工具
- okhttp
- rxjava2 + retrofit
- arouter
- dagger2
- evnetbus
- leakcanary
- lifecycle
- autoSize
- butterKnife
- jitpack
在接下来的章节中我们来仔细分析如何解决这些问题。
项目架构
使用的基础架构是基于@JessYan大神的ArmsComponet框架，并在此框架上做出相应的优化与改造。
总体分层
总体分层基本采用@JessYan的分层方式，大体分为三层。外加CommonService层来统一管理模块之间调用。
宿主层
APP壳文件，最后打包层，通过统一配置文件（gradle.properties），决定最后app的包名，定义主界面样式风格，模块的最终引入。
业务层
各个实际业务，业务层根据实际逻辑结构继续分层，我根据现有的项目是分了三层。当然可以根据业务量级继续分层。
- 第一层：被APP层直接调用，较大的模块，功能较为完整的模块。
- 第二层：一般为第一层业务模块跳转的页面。
- 第三层：底层页面，一般为详情页，不会有下一级跳转。
基础层
包含了各种基础服务，除了简单的工具类，通用自定义组件，一般情况都建议以远程调用模式引入，基础层（CommonSDK）不要引入过多的东西，有以下几个原因。
- 加快工程的编译速度 。
- 减少基础层的代码量 。
- 自定义组件专人维护，责任到人，因为总是有一些人觉得自己能优化别人的写的库，同时开源，有利于优化组件。
- 有利于在其他工程中快速复用以及在本地Lib的删减升级。
Service层
定义各个模块接口，以实现模块之间的互相调用，每个模块对外暴露的方法，都必须注册在Service中。我们尽量保持模块对外接的输入参数的最小化。这样某一个模块从V1升级至V2，其他模块保持对外部接口调用不变，我们就可以迅速的对模块进行V1到V2的升级。
