Android 组件化面试必备，内容太过真实

分解成多module的项目结构，就是组件化开发了吗？

当然不是，多module分层的项目结构，只是组件化开发的一部分。只是组件化开发的基础。

大叔，搜索了很多资料，发现，对于组件化开发，并没有很严格的定义。 当然，我们没有必要，过于纠结 ”组件化开发的定义“；

我们更关注这种开发思想对项目带来的好处以及在团队中如何运用。

)二、组件化的思想&优势

下面是我的理解，如有出入，欢迎提出来一起讨论。

)1、将一个大型项目分解成多个module，拆解的过程就是一个化繁为简的过程。

尤其在大团队，大项目上，组件化的优势会更加凸显。 大项目分解成一个个小型项目，相当于将一个复杂的问题拆解成一个个相对简单的问题。 每个成员，可以专注在自己相关业务的module上。

)2、分层的module结构，同一层的module间存在代码隔离，这种隔离是编译上的隔离。

同层的代码不能相互调用。底层的代码也不能调用上层。 这种编译隔离，带来了，模块间的高度解耦。 让模块的依赖关系清晰。

)3、更高的可重用性

（如果构建正确）组件化设计的系统，比传统的整体设计具有更高的可重用性。 什么是组件？什么是模块？ 组件强调复用，模块强调职责划分。 他们没有非常严格的划分。 达到可复用要求的模块，那么这个模块就是组件。 base层的module必须是可复用的，如果项目设计的好，business层都能被复用，每个module都能成为组件。 可重用性是组件化思想的核心。 如此架构，是否也适合技术中台的架构？

)4、每个组件都具有可替代性（如果构建正确）

如果我们要为某个已经存在的组件，重新开发一个新组件，将变得非常可行。 组件内的重构也将变得非常可行。 新的组件的设计只要保证对外提供的接口，完全符合，旧组件对外提供的接口

)5、组件的热插拔，成为可能（如果构建正确）

我们想象下，在app运行时，business中的组件可以动态加载，也可动态卸载。 那么我们可以轻松实现组件的懒加载：用户用到的组件，那么就加载进来。用完之后便可以卸载。

)6、组件的独立编译、测试，成为可能（如果构建正确）

大的android工程项目，build一次要到5分钟左右，太浪费时间了。 拆成多个组件之后，如果每个组件都能单独build，单独测试，那么将大大提升开发效率。

上面讨论的这些优势，并不是将简单将 单工程 拆分成 分层的多module工程结构 就能获得这些优势。

想要获得这些优势，还任重道远，我们还需要解决很多问题，才能让我们的项目具备上面的说的优势。

)二、组件化后，将面临哪些问题？如何解决？

)1、module之间如何优雅的通信

通过arouter通信。

arouter是阿里开源的一个项目。[github.com/alibaba/aro…](

)

通过arouter跨module跳转activity

@route(path = "/test/activity")//申明路由

public class youractivity extend activity {

...

}

//通过路由启动activity

arouter.getinstance().build("/test/activity").withlong("key1", 666l).navigation();

通过arouter在module间共享对象，实现module间通信。

比如：我们有一个账号模块 business:account ,提供了登录、登出、用户信息查询等业务。 同级的其他模块，如何跟账号模块通信？获取用户的登录状态以及用户相关信息？

public class accountbean {

private string name;

private int age;

//....

public interface iaccountservice extends iprovider {

void login(context context);//登录

void logout(context context);//登出

accountbean getaccountbean();//获取账号信息

对外的数据结构和接口定义。

@route(path = businessroutepath.moduleaccount.account)

public class accountserviceimpl implements iaccountservice {

//.....

bussiness:account模块中的实现。

iaccountservice accountservice = arouter.getinstance().navigation(iaccountservice.class);

accountservice.login(activity);

accountbean bean = accountservice.getaccountbean();

但是问题来了：

同层的其他模块，如何，能拿到arouter的path？

同层的其他模块编译时，如何，共享accountbean类、iaccountservice接口？

这就是模块之间的编译隔离，带来的问题。

我们很自然的想到了framework模块，或者base层的其他模块。

我们只要将这些path定义、accountbean类、iaccountservice接口，下沉到base层,就可以实现编译上的代码共享。

如此一来，就带来了，另一个问题：代码的中心化问题。

?

)2、代码的中心化

简单的path字符串定义，放在framework倒是还好。

如果所有business模块对外提供的接口和数据结构，都定义到framework的话，问题就有点严峻。

将会破坏：组件的 可替代性、可重用性、组件间耦合度

因为framework是基础模块嘛，所有business模块都依赖的模块，如此，不管你的business1模块是否依赖business2模块的对外接口，都会存在这一层依赖。 模块间的代码边界出现一些劣化。缺少了编译上的隔离。许多模块将会变得不够“独立”了。 可替代性、可重用性 越来越弱，想要替换或者复用某个business组件将变得越来越难。 将会导致，我们很难知道，哪些business对哪些business 接口有依赖。

同时，framework模块随着功能迭代，会不断膨胀。

这就是，中心化的问题。

于是我们很自然的想到了一个解决方案：

实现了另一种接口暴露的形式——“.api化”。 将 business模块 对外提供的接口单独抽到 business-api 模块中。其他依赖他的模块只需要依赖他的business-api即可。

</blockquote>

这个方案如何实践下去呢？

[](

)微信的api化方案

微信团队出了一个很巧妙的方案，这个方案对android的组件化开发，产生了非常深远的影响。 后面很多做组件化开发的团队，在解决中心化问题基本都会用到类似的方案。 [mp.weixin.qq.com/s/6q818xa5f…](

以下为，微信官方博客的原文引用：

使用方式和思路都很简单。对于java文件，将工程里想要暴露出去的接口类后缀名从“.java”改成“.api”，就可以了。 而且并不只是java文件，其他文件如果也想暴露，在文件名后增加".api”，也一样可以。

当然，要让工程支持这样的方式，gradle文件肯定会有一点改变。

它的实现原理也相当简单：自动生成一个“sdk”工程，拷贝.api后缀文件到工程中就行了，后面其他工程依赖编译的只是这个生成的工程。简单好用。

api方案有点类似于android的aidl的思路。

)微信api方案的变种

gradle 根据src/api文件来，自动生成{modulename}-api模块。

如果，src/api文件不存在，将不会自动生成 {modulename}-api 模块。

通过api模块来解决代码中心化问题带来的好处：

让各个business的之间的依赖明确

让business对外提供的接口明确。

从而加强了模块的：可替代性。

只要两个business对外提供的api一致，就可以相互替换。

)3、单独编译、测试 business的单个模块

模块变多了，项目变大了，整个项目的编译速度变慢了。

业内有两种常用做法。

方案一：动态配置 build.gradle。

只要让单个的组建能编译成app就能单独测试。

方案二：多壳app

方案来自，在聚美优品。

这里需要注意：假如，demo1是business1的壳app。那么demo1还需要依赖哪些businessxxx呢？

刚好，前面做的api化，能排上用场。

business1依赖的businessxxx-api模块对应的businessxxx模块，demo1也需要依赖。

为甚？因为，business1依赖的businessxxx-api模块，意味着，business1需要依赖 businessxxx提供的功能，比如要跳转到businessxxx的activity？或者，要获取businessxxx的对象。

)4、模块变多了，gradle代码同比增长，gradle 代码复用

)版本号统一管理，依赖的统一管理

方案一：extra properties

在项目跟目录的build.gradle文件中配置extra属性