Android面试指南：说说你对组件化/模块化的理解

到现在组件化真的不是什么新鲜东西了，大公司都用的滚瓜烂熟，龙飞凤舞了，也就是现在部分中型项目和小项目在组件化的路上努力。所以同志们，组件化没玩过的，不熟悉的赶紧搞起来，说一点，你不会组件化，发布影子工程那么对你来说就是个噩梦。从本质上来讲任何技术进步都是在现实需求的逼迫下抓耳挠腮，耗尽无数头发才想出来的。哈哈，这里说个笑话罢了。所以呢组件化这个东西出来这么久了，页发展了这么久了，用的人越来越多，那肯定是对我们显示开发大有裨益的，下伙伴们不会，不熟悉抓紧啦，要不面试问你你怎么回答呢！

下面来正式说说组件化

组件化这个东西其实并不复杂，他就是种思路，本质上是一种 app 架构思路，说穿了很简单的，难在组件化改造的时候，真正写起代码会出现不少棘手的问题，当然这些坑基本前人都趟完了，这里我主要是记录下，要是你看到熟悉的部分，请不要骂我啊，毕竟都是前辈们的东西啊。

这里补充一下，组件化是一种 app 架构，他的发展也是沿着正常的技术发展脉络来的，也是为了以追求高复用，高可维护性的目的的代码封装，区别是组件化是对整个 app 的再次封装。

废话了这么多，那么什么是组件化呢，各位看官想不要着急，在详细说组件化之前，我们要搞懂2个概念，就是上面说的组件和模块。

首先组件和模块都不是官方规定的，都是这些技术发展下来大家约定俗成的概念，其实很简单，一说就明白

• 模块：android 中的模块就是业务模块，单指业务，是按照业务对 app 进行拆分，比如说订单我们搞成一个模块，个人中心我们搞成一个模块，视频，音频这些都搞成模块，在app中的体现就是 一个个module，module 的中文意思也是模块，这不准这就是 google 对我们的暗示呢。模块化的目的是为了搭积木，随便拿几个模块module 出来就可以谁谁便便的上线一个 app，你还别说现在影子 app 的需求很旺盛，你去看看大公司的项目那个不是一堆影子工程，头条还搞出一个头条视频的马甲呢，这其实就是把视频 module 拿出来，加上一个启动页。这样的例子是比比皆是的，要不说不会组件化影子工程对你就是噩梦呢，哈哈，到时候维护那是想也别想了，代码你要搞多少份啊。
• 组件：这个一样简单啊，说穿了就是我们平时干的事，对功能的封装，这就是组件，一个功能就是一个组件，IO，数据库，网络等等这些功能都是组件，这么说你就明白了吧。既然这样那为毛线我们还要搞出来这个一个组件的概念，当然了任何事都是有其意义的，因为组件对功能代码的封装有个很高了明确的要求：一处封装，处处使用。要我们把维护性，复用性，扩展性，性能做到极致，因为这样才能真正做到一处封装，处处使用。当然组件的范围现在也是覆盖的很广的，app 中的一切都是组件，基本上我们分为：基础功能组件，通用UI组件，基础业务组件。

以上我谈了下我自己对于模块化，组件化的理解，是目前开发中对于模块和组件的理解。在模块化和组件化的发展中概念也是有些调整变化的，大家只要看现在是什么样子就好了，深入学习的话有兴趣可以看看组件化，模块化的发展历程。

我认为 Android 模块化探索与实践 对于模块化，组件化概念的解释是最优秀的。

组件化和模块化在现在看是一回事了，如果把一个项目看成是袋中的组合的话，那么模块就是体积最大的哪些袋子，组件就是体积小的袋子，大的袋子是最直接可被外接观测和接触的袋子，大的袋子也是用小的袋子组成的，一个不太恰当的比喻吧，模块和组件就是这样的关系，是我们对业务和功能拆分，封装的理解。

好了正式开始介绍了组件化啦

组件化在工程表现上就是我们把 app 按照其业务的不同，划分为不同的 module模块，把各种功能封装成一个个 library，module 之间是严格禁止横向依赖的，要不怎么单独使用呢，我不能为了用一个 module，把相关的module 都带上吧，要是这么 module 还有依赖的module 呢，这样谈复用性就是扯淡了。

主 app 就是我们常说的壳工程依赖这些 module，library 由需求的 module 依赖，但是要考虑library 版本的问题，随着业务和功能的扩展，library 的数量也是巨大的，微信在组件化拆分时据说拆分出80多个 module，可见 library 也是少不了的。

module 和 library 多数时候我们是提供arr 和 jar 来给壳工程引用的，arr 和 jar 在编译时是不会再编译的，只会检查版本，保留一个最新的版本，既提高了 app 的编译速度，也提供一种资源冲突解决方式。

下面我放一些图来描述一下组件化，大伙仔细看看，图比文字可生动多了