缘起

随着app变得复杂，“组件化”、“模块化” 这两个概念就会经常被提到。 面试中或者其他交流活动中也经常被提及。 但是“组件”、“模块”这两个概念并没有明确的定义，明确的边界。而且又有一些相似、交叉的地方。每个人理解有所不同。有人认为 组件化和模块化 是相同的事情。也有人认为 组件化是模块化思想的进一步演进。

这种认知冲突可能影响沟通交流，甚至项目推进。 本文我想聊聊我对组件化、模块化的理解，如有谬误还请各路大神不吝赐教。

从定义思考

定义

以下定义引自其他文章

组件

组件（Component）是对数据和方法的简单封装 -- 互动百科 非常简单的定义，关键字就是封装，延伸含义就是复用。良好的封装就可以达到完美的复用，因此提到组件往往会联想到 - 乐高（积木）

image

组件的出现就是期望能够通过搭积木的方式，完成一个 App 的构建

模块

模块（Module），又称构件，是能够单独命名并独立地完成一定功能的程序语句的集合（即程序代码和数据结构的集合体） -- 互动百科 稍微复杂一些的定义，关键字是集合，延伸含义就是功能模块体。功能运行自成一体。

总结

从定义中可以看出，“组件” 更注重于代码的“复用”。 “模块” 更注重与一块业务能力的完整性。通常情况下我们谈及组件的时候，心中所想的是一个framwork，一个pod或者一个aar（android）。 它有有明确的api和依赖，能够完成一个确定的功能，app可以在需要的时候调用相关的api。 而当我们谈及模块的时候，心中所想更多的是一块独立的业务功能， 它可能包含展示用户的页面，自身的逻辑，以及和服务端通讯的能力。

从定义的角度来看。 组件、模块其实是从不同的角度来划分一个app。 组件更多的是从自下而上的视角，按照技术实现的思维划分实现代码，并将这些代码组装成一个app。 模块更多的是从自上而下的视角，按照业务划分实现代码。

image

从做的事情思考

当我们进行“组件化”、“模块化”的时候，又会做些什么？从我个人角度来看，大致如下：

组件化

当我们谈到组件化的时候，更关注， 依赖关系、分层。一个典型的划分可能如下图所示。

image

上层组件应该严格的只依赖下层组件。 组件间通过直接依赖，调用对应的api的方式交互。

在这个思想下，相对来说，一些高度抽象出来的基础组件比较容易实现。例如： 图片缓存、UI组件、动画类库、工具类库等等。

但是具体组成的业务组件的划分就比较难，依赖关系也较难梳理，尤其是业务之间有互相交互的情况。 常见的解法是通过url route来跳转页面、传递信息。或者更进一步，采用类似 CTMediator 的方案。

模块化

模块化更关注，模块间通讯，生命周期，运行环境。 模块均遵守相同的规范，以相同的机制通讯，业务功能具体如何实现则可以由各业务方灵活决策。如下图所示：

image

阿里有一个这种类型的开源framework BeeHive

在这种思想下，业务之间通过app container 链接通讯。app通过在app container上配置模块来实现。各个模块实现相对独立，可以根据业务需求采用不同的策略。 比较有利于多个团队并行开发，但是对于性能，重复代码等需要额外机制处理。例如model A使用了sdwebimage，而model B 使用了kinfisher。

更进一步 MicroKernel 有一个更加通用的抽象。 但是实际上对于不同的app，不用提供太多复杂的能力，够用就好。

结论

“组件化”、“模块化” 目的都是针对复杂app，降低其复杂性，提升开发效率和质量。只是划分的角度略有不同。具体例子：一个输出日志pod 到底是一个组件呢？ 还是一个模块呢？可以回答，它即是一个组件，也可以是一个模块，只是划分方式不同😄。 当它被直接依赖使用的时候，我更倾向于叫它组件。 当它在一个模块化机制时，我更倾向于叫它模块。