文章大纲

一、项目模块化初步介绍
二、项目模块化的两种模式与比较
三、大型项目模块化的演进
四、项目模块化总结
五、参考文章

 

一、项目模块化初步介绍

1. 前言

在Android开发中，随着项目的不断扩展，项目会变得越来越庞大，而随之带来的便是项目维护成本与开发成本的增加！每次调试时，不得不运行整个项目；每当有新成员加入团队时，需要更多的时间去了解庞大的项目。。。而为了解决这些问题，团队通常会将项目模块化，以此来降低项目的复杂度和耦合度，让团队可以并行开发与测试，让团队成员更加专注于自己所负责的功能模块开发。。。
对于一些大厂如BAT或者美团等这些大型互联网公司，都会自己造轮子，实现项目模块化。而对于中小型公司，限于成本因素，一般都是选用这些大厂造的优秀的轮子来进行项目模块化。

2. 模块化需要做什么

首先，在开始项目模块化之前，我们必须要明确模块化需要做些什么？这就等于写书之前必须得有个总纲，否则越写到后面，越是混乱。以下是我认为在模块化时需要注意的几个问题：
（1）如何拆分项目
（2）模块之间的通信
（3）模块内的代码隔离
（4）模块在调试与发布模式之间的切换

3. 如何拆分项目

 

如上图所示，我将项目大概划分为五层：
宿主层
不做具体的项目功能实现，只负责集成业务模块，组装成一个完整的APP
业务模块层
将项目的每个大功能模块拆分成的一个一个单独的module
基础业务组件层
此层最大的作用是为了复用，例如首页模块与新盘模块中都有楼盘搜索这个功能，且UI显示相似，这时在两个模块中都实现楼盘搜索就显得繁琐了，像这种与业务有关联且需要多处使用的情况，我们完全可以将其抽离出来作为基础业务组件
功能组件层
项目中常用的功能库，如图片加载、网络请求等
底层SDK
从公司项目中长期积累出来的底层类库
以上是大多数项目模块化时的拆分方式，每个人也可以根据项目的实际情况进行调整。

4. 模块之间的通信

4.1 常用的通信方式
当项目被拆分成多个模块后，模块之间的良好的通信是我们必须考虑的问题。ARouter本身也提供一套通信机制，但是一般很难满足我们所有的需求，所以我们会容易想到的常用的几种通信方式：EvenBus、协议通信、广播或者是将通信的部分下沉到公共组件库。对于这几种方式，在一些大厂的技术文章中都有提到一些他们的看法，下面我简单总结一下：
EventBus： 我们非常熟悉的事件总线型的通信框架，非常灵活，采用注解方式实现，但是难以追溯事件，微信、饿了么认为这是个极大的缺点，不是很推荐，但是美团觉得只要自身控制的好就行（自己设计了一套基于LiveData的简易事件总线通信框架）。
协议通信： 通信双发必须得都知晓协议，且协议需要放在一个公共部分保存。虽然解耦能力强，但是协议一旦变化，通讯双方的同步会变的复杂，不方便。
广播： 安卓的四大组件之一，常见的通信方式，但是相对EventBus来说，过重。
下沉到公共组件库： 这是在模块化中常见的做法，不断的将各种方法、数据模型等公共部分下成到公共组件库，这样一来，公共组件库会变的越来越庞大，越来越中心化，违背了项目模块化的初衷。最后，越来越难以维护，不得不在重新拆分公共组件库。

4.2 如何对外暴露接口
解决了通信手段的问题，我们就得考虑另一个问题，为其他模块提供的接口+数据结构我们应该放在哪里？下沉到公共模块吗？或者另外新建一个module用来维护这些接口+数据结构？但是这样一来，成本就有些大了，也不方便。

在微信的模块化文章中提出了一个解决方法，将你要暴露的接口+数据结构甚至其他想要暴露的文件都.api化，即将你要暴露的文件的后缀名改为api，然后通过特定的方法将api后缀的文件拷贝出来，在module外部重新组成一个新的module（也可称为SDK），而想要使用的模块只需要调用这个SDK即可。当然，拷贝文件和组件SDK是完全自动化的，并非手工，这样才能节省成本。

由于微信的模块化文章中没有涉及到.api化的具体实现，所以根据这种思路，我使用了其他方法来实现要达到的效果。具体思路如下：

创建一个名为_exports的文件夹，需要对外暴露的文件都放在里面

 

将_exports文件夹打包成jar

/** * 创建 jar 包 */ task makeExportJar(type: Jar) { baseName = "hpauth-exports" version = "1.0.0" extension = "jar" // java文件编译后的所在位置 from('build/intermediates/classes/debug/') // kotlin文件编译后的所在位置 from('build/tmp/kotlin-classes/debug/') include('com/homeprint/module/auth/_exports/**') // jar包导出路径 destinationDir = file('build/_exports') } 

将jar发布到本地maven仓库（发布到本地仅仅针对个人开发的时候；团队开发时，大家使用各自的电脑，无法访问到你本地的maven仓库，所以这时需要在局域网中建立一个maven仓库，详情请查看《Android：超详细的本地搭建maven私服以及使用Nexus3.x搭建maven私服的讲解》）

artifacts {
    archives makeExportJar
}

uploadArchives {
    repositories {
        mavenDeployer {
            // 本地的maven仓库路径 repository(url: uri("../repo")) pom.project { groupId 'com.homeprint.module' artifactId 'auth-exports' version '1.0.0' } } } } 

在需要的模块调用jar

compileOnly 'com.homeprint.module:auth-exports:1.0.0@jar' 

注： 此处必须使用compileOnly来调用，compileOnly是provided的替代方法，provided将被google废弃。此处使用compileOnly代表，jar包只在编译时有效，不参与打包。如果使用api或者implementation，因为我们只是将文件拷贝出来成为一个单独的SDK，并未修改包名和文件名，当将多个模块集成为一个app时，会抛出异常，提示jar包中的文件已存在。

5. 组件的生命周期管理

在组件化开发时，每个组件都应该有自己独立的生命周期，这个生命周期类似于组件自己的Application，在这个生命周期中，组件可以做一些类库的初始化等工作，否则如果每个组件都将这些工作集中到壳工程的Applicaiton中实现的话，会显得壳工程的Application太过中心化，并且一旦需要修改，会很麻烦，且容易产生冲突。

基于上述原因，我们可以自己搭建一个简易的组件生命周期管理器，主要分为两步：

构建组件的生命周期模型，构建的模型持有整个app的Application引用，同时提供三个基础方