Android模块化之MicroModule(微信Pins工程)

一、Android模块化之MicroModule(微信Pins工程)

1、相信你看过微信关于模块化的分享《微信Android模块化架构重构实践》，也注意到里面提到的pins工程结构。

2、作者是这样描述的------“pins工程能在module之内再次构建完整的多子工程结构，通过project.properties来指定编译依赖关系。通过依赖关系在编译时找到所有的资源和源码路径。”

3、仔细推敲这句话的意思，应该能知道它实现的基本原理------通过设置sourceSets指定多个java、res等路径.

4、

5、

6、但是，有一个问题需要要知道的是，一个module只能指定一个AndroidManifest文件，pins工程中包含了多个AndroidManifest，它是怎么做到的？

7、研究过 com.android.tools.build:gradle，会留意到它使用到一个子库 com.android.tools.build:manifest-merger，官方通过这个库来合并多个AndroidManifest文件，或许pins工程也是用了这方式。

8、接下来，再它的基础上，我做的一些改动，取了另一个名字叫 MicroModule，先来看一下工程结构：

9、与pins工程的结构大致不变，增加了 androidTest和 test，以及将 project.properties替换为 build.gradle。

10、基本原理是不变的，与微信pins工程一样配置 sourceSets。AndroidManifest合并用了 com.android.tools.build:manifest-merger。

11、在根项目的build.gradle中添加插件依赖：

12、在模块的build.gradle中引用插件并配置 MicroModule：

13、为了使用上的更加方便，专门写了Android Studio的插件，能快速的创建一个MicroMoudle.

14、

15、

16、 MicroModule已经上传至Github，欢迎star交流。

17、

二、Android模块化设计方案之使用代理模式解耦

Android模块化设计方案系列文章：

1、 Android模块化设计方案模型图

2、 Android模块化设计方案之接口API化

3、 Android模块化设计方案之使用代理模式解耦

本篇是Android模块化设计方案的第三篇，也是对第一篇中ThridLibs Proxy模块进行说明。

很多人觉得对那些优秀的第三方依赖库再次封装是一件多余的事情，因为这些库可能出自大神/大厂，或有非常高的star并且使用起来十分稳定，可以在项目中直接拿来使用。当然每个开发者都有自己的态度，我也只是根据以往的经验，表达一下自己的看法。

作为从了解四大组件就不愁找不到工作的互联网大时代中一路走来的Android老鸟，经历了网路请求框架从HttpConnection到Volley再到OkHttp，也经历了图片加载框架从UniversalImageLoader到Picasso再到Gilde，技术的迭代随时都会发生。让项目架构具有良好的扩展性是在设计之初就需要考虑的东西。

那么接下来我用一个简单的demo来演示一下如何使用代理模式对第三方框架进行解耦。

现在我们有一个名为 thirdlib的模块，为我们提供图片加载功能。

第一步：我们创建了一个新的模块 thridlibproxy，并且该模块依赖于 thirdlib，我们在该模块中创建包私有的接口ImageLoaderInterface，这个接口中把thirdlib模块中提供的功能抽象为接口：

第二步：创建包私有的接口的实现类ImageLoaderOneImpl，类中图片加载的业务逻辑是通过调用 thirdlib中的ImageLoader类实现的：

第三步：我们提供一个供外部调用的ImageLoaderOneImpl接口代理类ImageLoaderProxy：

最后我们就可以通过ImageLoaderProxy中提供的loadImage方法进行图片的加载了。

看到这里有些盆友就会问了，在第二步的时候，我们就完成了 thirdlib的封装工作，为什么还要有第三步？还有我写一个单例类直接对 thirdlib进行封装不就行了，为什么还要抽象出接口？

原因很简单，为的就是尽可能的满足软件设计七大原则中的第一个：开闭原则。

一个好的软件设计，需要对拓展开放，对修改关闭。我们在设计之初就要想到，在更换图片加载框架之后如何最大程度上满足开闭原则。

如果直接对 thirdlib进行封装，是面向类的开发而不是面向接口。如果此时更换图片加载类库，那必然会对封装出来的类进行大量的修改，把原来的实现替换为新的实现。

使用代理模式的好处就是，我新创建一个被代理的类ImageLoaderTwoImpl：

然后只需要对第三步中的被代理类进行替换就行了。

在想要达到相同效果的时候，最大程度的满足了开闭原则。

我们业务层模块也和第三方库实现了完全的解耦，我不需要知道 thridlibproxy是如何帮我完成图片加载工作的，但是只要调用它提供的方法就完事儿的，这也符合软件设计七大原则中的：最少知道原则。

关于为何以及怎么通过代理调用第三方依赖库，到这里就介绍完毕了，赶快动手试试吧~

我只想说：原则是死的，人是活的😹

如果觉得有收获的话，欢迎点赞评论以及关注~

三、Android 模块化路由框架:TheRouter

1、TheRouter是一套面向 Android模块化开发的解决方案，核心功能包括：Navigator、ServiceProvider、FlowTaskExecutor和 ActionManager。其设计旨在解耦模块间的依赖，提升大型应用开发效率，同时提供额外功能以解决模块化过程中的常见问题。

2、为了实现页面跳转和跨模块调用，TheRouter在编译期通过注解生成 RouteMap类，存储当前模块的所有路由信息。这些信息随后被集中管理，应用启动时无需反射即可加载。路由表以正则匹配的 Map结构存储，支持多路径对应同一页面。页面跳转时，通过 path获取落地页信息，调用 startActivity()方法完成跳转。

3、页面跳转时，用户可声明路由项，每个页面支持多个路由项，实现一对多的能力。TheRouter提供了声明路由项的注解和发起页面跳转的方式，支持多种参数类型，包括 String、基本数据类型、Bundle、Serializable和 Parcelable对象。同时，支持额外的 Intent参数，如 Flag、Uri、ClipData和 identifier。

4、路由表生成遵循覆盖规则，优先级高者覆盖低者，支持动态添加，生成为 JSON文件。TheRouter提供远程下发路由表的功能，支持不同版本的配置。动态路由表允许通过远程方式更新，以解决线上页面崩溃问题。

5、在跨模块依赖方面，TheRouter推荐采用面向服务架构(SOA)的设计。ServiceProvider负责服务的提供和调用，服务使用方无需关注提供方，只需声明所需服务接口。服务提供方通过@ServiceProvider注解标记，实现服务的声明。

6、TheRouter的单模块自动初始化能力通过 FlowTaskExecutor实现。开发者可以在模块中声明初始化方法，标记为@FlowTask注解，系统会在应用启动时自动调用。这种方法解决了循环依赖问题，并支持构建有向无环图，检测并显示循环依赖，便于排查。

7、动态化能力通过 ActionManager实现，用于预埋系统回调，如弹窗、上传日志、清理缓存等操作。Action支持关联多个拦截器，可以设置优先级，终止低优先级执行。客户端动态响应场景下，用户操作触发预埋的 Action逻辑；服务端打通时，通过智能推断和长连接指令实现动态操作。

8、TheRouter通过提供一键切换源码与 AAR的 Gradle脚本，允许开发者灵活选择编译方式，提升开发效率。迁移工具支持一键从 ARouter迁移至 TheRouter，并且正在开发支持其他路由框架的迁移工具。

9、TheRouter并非单一的路由库，而是全面的 Android模块化解决方案，致力于解决模块化开发中的问题，并支持平滑迁移。GitHub上提供了学习文档和迁移工具，欢迎社区贡献和提出需求。