关于Android模块化你须要知道的

最近公司一个项目使用了模块化设计，本人参与其中的一个小模块开发，可是总体的设计并非我架构设计的，开发半年有余，在此记录下来个人想法。

模块化场景

为何须要模块化？

当一个App用户量增多，业务量增加之后，就会有不少开发工程师参与同一个项目，人员增长了，原先小团队的开发方式已经不合适了。

原先的一份代码，如今须要多我的来维护，每一个人的代码质量也不相同，在进行代码Review的时候，也是比较困难的，同时也容易会产生代码冲突的问题。

同时随着业务的增多，代码变的愈来愈复杂，每一个模块之间的代码耦合变得愈来愈严重，解耦问题急需解决，同时编译时间也会愈来愈长。

人员增多，每一个业务的组件各自实现一套，致使同一个App的UI风格不同，技术实现也不同，团队技术没法获得沉淀。

架构演变

在刚刚开始的时候，项目架构使用的是MVP模式，这也是最近几年很流行的一个架构方式，下面是项目的原始设计。

随着业务的增多，咱们添加了Domain的概念，Domain从Data中获取数据，Data可能会是Net，File，Cache各类IO等，而后项目架构变成了这样。

再而后随着人员增多，各类基础组件也变的愈来愈多，业务也很复杂，业务与业务之间还有很强的耦合，就变成了这样的。

使用模块化技术之后，架构变成了这样。

技术要点

这里简单介绍下Android项目实现模块化须要使用的技术以及技术难点。

Library module

在开始开始进行模块化以前，须要把各个业务单独抽取成Android Library Module,这个是Android Studio自带一个功能，能够把依赖较少的，做为基本组件的抽取成一个单独模块。

如图所示，我把各个模块单独分为一个独立的项目。

在主项目中使用gradle添加代码依赖。

Library module开发问题

在把代码抽取到各个单独的Library Module中，会遇到各类问题。最多见的就是R文件问题，Android开发中，各个资源文件都是放在res目录中，在编译过程当中，会生成R.java文件。R文件中包含有各个资源文件对应的id，这个id是静态常量，可是在Library Module中，这个id不是静态常量，那么在开发时候就要避开这样的问题。

举个常见的例子，同一个方法处理多个view的点击事件，有时候会使用switch(view.getId())这样的方式，而后用case R.id.btnLogin这样进行判断，这时候就会出现问题，由于id不是常常常量，那么这种方式就用不了。

一样开发时候，用的最多的一个第三方库就是ButterKnife，ButterKnife也是不能够用的，在使用ButterKnife的时候，须要用到注解配置一个id来找到对应view，或者绑定对应的各类事件处理，可是注解中的各个字段的赋值也是须要静态常量，那么就不可以使用ButterKnife了。

解决方案有下面几种：

1.从新一个Gradle插件，生成一个R2.java文件，这个文件中各个id都是静态常量，这样就能够正常使用了。

2.使用Android系统提供的最原始的方式，直接用findViewById以及setOnClickListener方式。

3.设置项目支持Databinding，而后使用Binding中的对象，可是会增长很多方法数，同时Databinding也会有编译问题和学习成本，可是这些也是小问题，我的觉的问题不大。

上面是主流的解决方法，我的推荐的使用优先级为 3 > 2 > 1。

当把个模块分开之后，每一个人就能够单独分组对应的模块就好了，不过会有资源冲突问题，我的建议是对各个模块的资源名字添加前缀，好比user模块中的登陆界面布局为activity_login.xml，那么能够写成这样us_activity_login.xml。这样就能够避免资源冲突问题。同时Gradle也提供的一个字段resourcePrefix，确保各个资源名字正确，具体用法能够参考官方文档。

依赖管理

当完成了Library module后，代码基本上已经很清晰了，跟咱们上面的最终架构已经很类似了，有了最基本的骨架，可是仍是没有完成，由于仍是多我的操做同一个git仓库，各个开发小伙伴仍是须要对同一个仓库进行各类fork和pr。

随着对代码的分割，可是主项目app的依赖变多了，若是修改了lib中的代码，那么编译时间是很恐怖的，大概统计了一下，原先在同一个模块的时候，编译时间大概须要2-3min，可是分开之后大概须要5-6min，这个是绝对没法忍受的。

上面的第一问题，能够这样解决，把各个子module分别使用单独的一个git仓库，这样每一个人也只须要关注本身须要的git仓库便可，主仓库使用git submodule的方式，分别依赖各个子模块。

可是这样仍是没法解决编译时间过长的问题，咱们把各个模块也单独打包，每次子模块开发完成之后，发布到maven仓库中，而后在主项目中使用版本进行依赖。

举个例子，好比进行某一版本迭代，这个版本叫1.0.0，那么各个模块的版本也叫一样的版本，当版本完成测试发布后，对各个模块打对应版本的tag，而后就很清楚的了解各模块的代码分布。

gradle依赖以下。

可能有人会问，既然各个模块已经分开开发，那么若是进行开发联调，别急，这个问题暂时保留，后面会对这个问题后面再表。

数据通讯

当一个大项目拆成若干小项目时候，调用的姿式发生了少量改变。我这边总结了App各个模块之间的数据通讯几种方式。

• 页面跳转，好比在订单页面下单时候，须要判断用户是否登陆，若是没有则须要跳到登陆界面。

• 主动获取数据，好比在下单时候，用户已经登陆，下单须要传递用户的基本信息。

• 被动得到数据，好比在切换用户的时候，有时候须要更新数据，如订单页面，须要把原先用户的购物车数据给清空。

再来看下App的架构。

第一个问题，原先的方式，直接指定某个页面的ActivityClass，而后经过intent跳转便可，可是在新的架构中，因为shopping模块不直接依赖user，那么则不能使用原始的进行跳转，咱们解决方式使用Router路由跳转。

第二个问题，原先的方式有个专门的业务单利，好比UserManager，直接能够调用便可，一样因为依赖发生了改变，不可以进行调用。解决方案是全部的须要的操做，定义成接口放在Service中。

第三个问题，原先的方式，能够针对事件变化提供回调接口，当我须要监听某个事件时候，设置回调便可。

页面路由跳转

如上分析，原先方式代码以下。

可是使用Router后，调用方式改变了。

具体的原理是什么，很简单的，作一个简单的映射匹配便可，把"app://user"与UserActivity.class配对，具体的就是定义一个Map，key是对应的Router字符，value是Activity的class。在跳转时候从map中获取对应的ActivityClass，而后在使用原始的方式。

可能有人的会问，要向另一个页面传递参数怎么办，没事咱们能够在router后面直接添加参数，若是是一个复杂的对象那么能够把对象序列化成json字符串，而后再从对应的页面经过反序列化的方式，获得对应的对象。

例如：

注： 上面的router中json字符串是须要url编码的，否则会有问题的，这里只是作个示例。

除了使用Router进行跳转外，我想了一下，能够参考Retrofit方式，直接定义跳转Java接口，若是须要传递额外参数，则以函数参数的方式定义。

这个Java接口是没有实现类的，可使用动态代理方式，而后接下来的方式，和使用Router的方式同样。

那么这总两种方式有什么优缺点呢。

Router方式:

• 有点：不须要高难度的技术点，使用方便，直接使用字符串定义跳转，能够好的日后兼容

• 缺点：由于使用的是字符串配置，若是字符输入字符，则很难发现bug，同时也很难知道某个参数对应的含义

仿Retrofit方式:

• 由于是Java接口定义，因此能够很简单找到对应的跳转方法，参数定义也很明确，能够直接写在接口定义处，方便查阅。

• 一样由于是Java接口定义，那么若是须要扩展参数，只能从新定义新方法，这样会出现多个方法重载，若是在原先接口上修改，对应的原先调用方也要作响应的修改，比较麻烦。

上面是两种实现方式，若是有相应同窗要实现模块化，能够根据实际状况作出选择。

Interface和Implement

如上分析，若是须要从某个业务中获取数据，咱们分别须要定义接口以及实现类，然在获取的时候在经过反射来实例化对象。

下面是简单的代码示例

接口定义

实现类

反射生成对象

实际调用

本示例中每次调用都是用反射生成新的对象，实际应用中可能与IoC工具结合使用，好比Dagger2.

EventBus

针对上面的第三个问题，原先设计的使用方式也是能够的，只须要把回调接口定义到对应的service接口中，而后调用方就可使用。

可是我建议可使用另一个方式——EventBus，EventBus也是利用观察者模式，对事件进行监听，是设置回调更优雅方式的实现。

优势：不须要定义不少个回调接口，只须要定义事件Class，而后经过Claas的惟一性来进行事件匹配。

缺点：须要定义不少额外的类来表示事件，同时也须要关注EventBus的生命周期，在不须要使用事件时候，须要注销事件绑定，否则容易发生内存泄漏。

映射匹配

上面的介绍的各个模块之间通讯，都运涉及到映射匹配问题，在此我总结了一下，主要涉及到一下三种方式。

Map register

Map register是这样的，全局定义一个Map，各个模块在初始化的时候，分别在初始化的时候注册映射关系。

下面是简单的代码示例，好比咱们定义一个模块生命周期，用于初始化各个模块。

User模块初始化

在Application中完成初始化

APT

使用注解的方式配置映射信息，而后生成一个相似Database同样的文件，而后Database文件中包含一个Map字段，Map中记录各个映射信息。

首先须要定义个Annotation。

如：

须要实现一个 Annotation Process Tool，来解析本身定义的Annotation。

代码略，此代码有点复杂，暂时不贴了。

编译产生的文件，大概以下所示。

而后利用反射找到Implement_$$_Database这个类，而后从方法中找到配对。

而后在须要配置的地方添加注解便可。

调用姿式。

注意点：

有时候，在生成最终的配置文件的时候，文件的名字是固定的，好比上面的Implement_$$Database,最终的路径是这样的cn.mycommons.implements.database.Implement$$_Database.java，而后经过编译到apk中或则是aar中。

可是有个问题，若是各个子模块都使用了这样的插件，那么每一个子模块的就会有这个Implement_$$_Database.class，那么就会编译出错。

由于aar中包含的时候class文件，不是java文件，不能在使用APT作处理了。下面有2中解决方案。

1. 子工程的插件生成的文件包含必定的规则，好比包含模块名字，如User_Implement_$$_Database.java，同时修改编译过程，把java文件也打包到aar中，主工程的插件在编译时候，提取aar中的文件，而后合并子工程的全部的代码，这个思路是可行的，不过技术实现起来比较麻烦。

2. 同一的方式相似，也是生成有必定规则的的文件，或者在特意package下生成class，这些class再经过接下来的所讲的Gradle Transform方式，生成一个新的Database.class文件。

Gradle Transform

这是Android Gradle编译提供的一个接口，能够供开发自定义一些功能，而咱们就能够根据这个功能生成映射匹配，这种方式和APT相似，APT是运行在代码编译时期，并且Transform是直接扫描class，而后再生成新的class，class中包含Map映射信息。修改class文件，使用的是javassist一个第三方库。

下面简单讲述代码实现，后面有机会单独写一篇文章讲解。

首先定义一个注解，这个注解用于标注一个实现类的接口。

一个测试用的接口以及实现类。

定义一个静态方法，用于获取某个接口的实现类。

若是不使用任何黑科技，直接使用Java技术，那么在定义时候须要主动的往CONFIG这个map中添加配置，可是这里咱们利用transform，直接动态的添加。

定义一个ImplementsPlugin gradle插件。

自定义的Transform实现。

代码省略。。地址为https://github.com/LiushuiXiaoxia/AndroidModular/tree/master/ImplementsTransformPlugin

映射匹配总结

优势:

• Map:简单明了，很容易入手，不会对编译时间产生任何影响，不会随着Gradle版本的升级而受影响，代码混淆时候不会有影响，无需配置混淆文件。

• APT：使用简单，使用注解配置，代码优雅，原理是用代码生成的方式生成新的文件。

• Transform：使用简单，使用注解配置，代码优雅，原理是用代码生成的方式生成新的文件，不过生成的文件的时期和APT不一样，会编译时间产生少量影响。

缺点:

• Map：在须要新添加映射的时候，须要手动添加，否则不会生效，代码不优雅。

• APT：在编译时期生成文件，会编译时间产生少量影响，同时在不一样的Gradle的版本中可能会产生错误或者兼容问题。须要配置混淆设置，否则会丢失文件。技术实现复杂，较难维护。

• Transform：在编译时期生成文件，会编译时间产生少量影响，同时在不一样的Gradle的版本中可能会产生错误或者兼容问题。须要配置混淆设置，否则会丢失文件。技术实现复杂，较难维护。

从技术复杂性以及维护性来看，Map > APT = Transform

从使用复杂性以及代码优雅性来看，Transform > APT > Map

开发调试技巧

Debug

上面介绍了不少关于模块化的概念以及技术难题，当模块化完成之后，再进行完成开发时候仍是会遇到很多问题。不如原先代码在一块儿的时候很方便的进行代码调试。可是进行模块化之后，直接使用的是aar依赖，不能直接修改代码，可使用下面技巧，能够直接进行代码调试。

在根目录下面建立一个module目录以及module.gradle文件，这个目录和文件是git ignore的，而后把对应的模块代码clone到里面，根目录的setting.gradlew apply module.gradle文件，以下所示，若是须要源码调试，则在module中添加对应的模块。而后在app的依赖中去掉aar依赖，同时添加项目依赖便可。当不须要源码调试好，再修改成到原先代码便可。

module.gradle

好比调试shopping模块

固然还有个更具技术挑战性方案，使用gradle插件的形式，若是发现root项目中包含的模块化的源码，则不适用aar依赖，直接使用源码依赖，固然这个想法是不错的，不过具备技术挑战性，同时有可能随着Gradle版本的升级，编写的gradle插件也要作相对于的兼容风险，这是只是简单提示一下。

容器设计

上面讲到的若是要调试代码时候，须要完整的运行的整个项目，随着项目的增大，编译时间可能变得很长。

咱们能够作一个简单的，相似与主app模块同样，好比我是负责user模块的开发者，那么我只要调试我这个模块就好了，若是须要其余的模块，我能够简单的作一个mock，不是把其余的模块直接依赖过来，这样能够作到调试做用。等到再须要完整项目调试时候，咱们在使用上面介绍的方式，这样能够节省很多开发时间。

还有一种实现调试的方式，好比上面的user模块，目录下面的build.gradle文件是这样的

咱们能够在gradle.properties中设置编译变参数isLibModule，当须要完整调试好，设置为isLibModule=false，这样我这个子模块就是一个apply plugin: 'com.android.application'这样的模块，是能够单独运行的一个项目

可能有时候仍是须要单独的运行环境，android编译方式有2中，一种是debug，一种是release。当打包成aar的时候，使用的是release方式，咱们能够把须要调试的代码所有放到debug中，这样打包的时候就不会把调试的文件发布到aar中。不过这种实现方式，须要对Android项目的目录有较高的认识，才能够熟练使用。

CI

上面介绍的各个模块须要单独到独立的git仓库，同时打包到单独的maven仓库，当开发完成后，这时候就须要进行打包，但这个是一个简单和重复的事情，因此咱们须要一个工具来完成这些事情，咱们能够利用CI系统来搞定这件事情，这里我推荐Jenkins，主流厂商使用jenkins做为CI服务器这个方案。

具体的步骤就是，须要对每一个模块的git仓库作web hook，咱们公司使用的是git lab，能够对git的各类操做作hook，好比push，merge，tag等。

当代码发送了变化了，咱们能够发送事件到CI服务器，CI服务器再对各个事件作处理，好比user模块develop分支有代码变化，这个变化多是merge，也有多是push。咱们能够把主项目代码和user项目的代码单独clone下拉，而后编译一下，确认是否有编译问题，若是有编译经过，那么在使用相关gradle命令发布到maven仓库中。

无论每次编译结果怎样，是成功仍是失败，咱们都应该把结果回馈给开发者，常见的方式是邮件，不过这个信息邮件方式可能很频繁，咱们建议使用slack。

总结

模块化架构主要思路就是分而治之，把依赖整理清楚，减小代码冗余和耦合，在把代码抽取到各自的模块后，了解各个模块的通讯方式，以及可能发生的问题，规避问题或者解决问题。最后为了开发和调试方便，开发一些周边工具，帮助开发更好的完成任务。

做者：流水不腐小夏

地址：http://www.jianshu.com/p/910911172243

更多文章

2017上半年技术文章集合—184篇文章分类汇总

NDK项目实战—高仿360手机助手之卸载监听

破解Android版微信跳一跳,一招教你挑战高分

高级UI特效仿直播点赞效果—一个优美炫酷的点赞动画

一个实现录音和播放的小案例

相信本身，没有作不到的，只有想不到的

若是你以为此文对您有所帮助，欢迎入群 QQ交流群 ：644196190 微信公众号：终端研发部