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