模块化是什么

官方解释，模块化是指解决一个复杂问题时自顶向下逐层把系统划分成若干模块的过程，有多种属性，分别反映其内部特性。
简单来说，就是把独立的模块分割开来开发，最后用集成的方式组合起来，拼出一个app，就比如我们蜂鸟团队app，把UI控件、网络请求等通用的功能模块以及qc、feedback等业务模块抽出来，把独立的模块抽出来，这样做还有一个好处，其他app也可以使用相同的模块。

模块化好处

1、每个module可以单独调试开发，节省编译时间。
2、降低耦合，划分职责，保证高效迭代。
3、技术和业务维度划分模块，独立开发，独立维护。
3、模块之间可以复用，便于新模块的快速搭建与接入。
4、降低维护难度，降低团队成员熟悉项目的成本。

模块化设计

说完前面那些官方介绍之后，我们就开始对app进行模块化重构吧！
说到开始，那我们应该怎么设计、分割app呢？这里就说一种最常见、最被认同的方案吧，先看下面图：

设计图

从图中可以看出，推荐分为三大部分：基础模块、业务模块、app模块。
基础模块：
所有模块依赖库 ，基础工具类，比如封装的网络请求、图片处理、base文件等，接口库（后面会讲到为什么要抽出一个接口库）等
业务模块：
一些可以独立的出来的业务，比如登录、更新、推送等等。
app模块
所有模块最终聚合的地方，这里把各个模块整合一起，组成一个app。

模块化解耦

设计好了之后，在开发之前，才是这篇文章最重要的部分，如何解耦？
你在实际模块化开发的时候，你会发现，每个独立模块并不是完全分割的，互相之间都会有依赖，各种交叉依赖，导致耦合度很高，在维护的时候造成很大的困扰。
目前有很多解耦的方法，最常见应该就是两种方法：

1. 统一跳转

• 完全解耦跳转
• url route方式
• 动态性+rewrite
• 跳转时参数检查
• 支持基础数据类型和复杂数据类型

1. 面向服务，弱解耦

• 依赖interface，弱解耦
• 没有动态性
• 接口强依赖，编译期检查
• 原生接口方式，学习开发障碍小

目前url解耦的方式，每次跳转或者调用的时候，都需要约定url、参数等，这种方式，在业务较多的项目中维护起来不是特别方便，所以我们决定使用面向服务弱解耦的方式。

在我们目前的项目中，我们模块化的方案是：

• 把项目分割成基础模块（网络、UI控件等）、业务模块、接口模块（我们定义好的接口）。
• 每个模块打包成aar，最后打包成一个app。
  这样做起来，每个模块改动之后，还需要升级模块，然后打包，然后给其他模块使用，这样在开发起来十分麻烦。
  后来公司一位大神做了一套方案，在开发测试的时候，我们可以将module放到本地进行开发测试，上传git的时候，这些本地的module不能传到git上，在本地的module升级打包aar上传到jcenter，最终打包的app就是把打包好的aar组合生成的。
  这个方案，当多个模块之间需要互相调用的时候呢？我们借助dagger控件来解耦（具体使用大家可以看一下官方文档）。
  这套模块化的方案，可以比较好的降低模块之间的耦合，但是使用起来是比较繁琐的，
• 约定好接口，并单独放到我们的接口模块中
• 接口里面的方法，递增的方式添加，尽量不要修改接口方法。
• 牵一发而动全身，接口一旦修改了，依赖于这个接口的module是编译不通过的。

那还有没有更好的方案呢？

答案是有的。无意中看到的一篇文章，这种方案给了我很大的启发。
spiny模块化

spiny框架，本质上就是把我们的接口module改成注册的module，也就是说我们项目中有耦合关系的module，需要将耦合的方法、参数等统一注册到我们的接口module，每次需要调用的时候，从注册module中去找，找到注册信息后去找到相应的实现方法。
这样做的好处就是：
每个module之间耦合消失，只依赖注册module，极大程度降低耦合度

听起来是不是很爽，spiny这种模块化方案的确是一个很好的方案，但是大家看它的使用方法就会发现，非常的繁琐、麻烦，每个需要对外提供方法的module都需要继承一大堆的类，使用方也是需要写一大堆东西，那有没有更好的方法来解决这个方法的繁琐呢？

答案是有的，请看下一篇，