一个 Android MVVM 组件化架构框架

模块

• app:

app壳 工程，是依赖所有组件的壳，该模块不应该包含任何代码，它只作为一个空壳存在，由于项目中使用了EventBusAPT技术，需要索引到各业务组件的对应的APT生成类，所以在 app壳 内有这一部分的代码。

• buildGradleScript:

脚本模块，该模块下存放的都是各个组件及封装的一些 Gradle 脚本文件。初衷是将所有的脚本统一管理，事实上我在组件内查找脚本的习惯还是没有改掉。

• buildSrc:

这是一个特殊的文件夹，负责项目的构建，里面存放着一些项目构建时用到的东西，比如项目配置，依赖。这里面还是存放 Gradle 插件的地方，一些自定义的 Gradle 的插件都需要放在此处。

• lib_base:

项目的基础公共模块，存放着各种基类封装、对远程库的依赖、以及工具类、三方库封装， Android开源项目《ali1024.coding.net/public/P7/Android/git》 该组件是和项目业务无关的，和项目业务相关的公共部分需要放在 lib_common 中。

• lib_common:

项目的业务公共模块，这里面存放着项目里各个业务组件的公共部分，还有一些项目特定需要的一些文件等，该组件是和项目业务有关系的。

• lib_net:

网络模块，网络模块的配置、封装等，专门设立了一个组件来负责网路模块部分。

组件化相关

组件初始化

为了更好的代码隔离与解耦，在特定组件内使用的SDK及三方库，应该只在该组件内依赖，不应该让该组件的特定SDK及三方库的API暴露给其他不需要用的组件。有一个问题就出现了，SDK及三方库常常需要手动去初始化，而且一般都需要在项目一启动（即 Application 中）初始化，但是一个项目肯定只能有一个自定义的 Application，该项目中的自定义 Application 在 lib_base 模块中，并且也是在 lib_base 模块中的清单文件中声明的，那其他组件该如何初始化呢？带着这个问题我们一起来深入研究下。

常见的组件初始化解决方案：

在我的了解范围内，目前有两种最为常见的解决方案：

• 面向接口编程 + 反射扫描实现类：

该方案是基于接口编程，自定义 Application 去实现一个自定义的接口（interface），这个接口中定一些和 Application 生命周期相对应的抽象方法及其他自定义的抽象方法，每个组件去编写一个实现类，该实现类就类似于一个假的自定义 Application，然后在真正的自定义 Application 中去通过反射去动态查找当前运行时环境中所有该接口的实现类，并且去进行实例化，然后将这些实现类收集到一个集合中，在 Application