Android中组件和模块概念辨析

一千个人的眼中就有一千个哈姆雷特。在网上看了大量关于Android 开发模式的博客，有的说是模块儿化开发，有的说是组件化开发，刚开始搞得一头雾水，但是仔细看完后会发现，他们说的核心思想都是一样的，都是说将一个App分成多个module，既可以分而治之又可以统一管理。但我还是想说一下自己眼中的哈姆雷特是什么样子。

一 、概念区别

• 对比

类别	目的	特点	接口	成果	架构定位
组件	重用、解耦	高重用、松耦合	无统一接口	基础库、基础组件	纵向分层
模块	隔离/封装	高内聚、松耦合	统一接口	业务框架、业务模块	横向分块

• 举例说明

1. 组件：Android的原生控件，基本上都没法直接拿来用，太丑了。另外一方面，原生控件在不同的Android版本上可能有不同风格，Holo，Material Design等。而从应用开发者角度来讲，他们需要一个拿来可用的，统一并且可延续的风格。在这种背景下，他们开始自定义系统控件，逐渐形成了自己的风格。比如，微信，支付宝，高德地图等。这样之后，我们就需要将这种风格应用于TextView，Button，ImageView等标准化控件。组件化后，我们开发新功能，只需要直接引用带有自己风格的标准化控件，再稍微调整宽度，高度，字体大小等，就可以应付大多数情况了。

2. 模块：起初，一个人搞定一个应用，并不需要模块化这些事情。但随着业务的发展，应用的迭代，可能出现人员越来越多，业务模块越来越多，越来越复杂的情况。在产品快速迭代过程中，假设某个业务的某个需求，由于外部原因等无法按时开发完成怎么办？或者由于其他原因，导致这部分功能有严重BUG怎么办？下掉这部分功能，又进行全量测试？划不来。硬着头皮修复BUG？万一来不及，错过发布日期怎么办？

• 总结

1. 从代码组织层面上来区分，组件化开发是纵向分层，模块化开发是横向分块，所以模块化并没有要求一定组件化。也就是说你可以只做模块化开发，而不做组件化开发。那这样的结果是什么样的呢？就是说你的代码完全不考虑代码重用，只是把相同业务的代码做内聚整合，不同模块之间还是存在大量的重复代码。这样的成果也算是做到了模块化，只不过我们一般不会这样而已。

2. 和组件、模块近似的一对概念是库和框架。库的概念偏近于代码的堆集，是分层的概念，所以对应组件化。框架是结构化的代码，所以应用于模块化。框架是骨，模块化是肉。 比如，ReactiveCocoa是库，只是提供了响应式编码能力，而基于此的MVVM具体实现成果才叫框架，因为框架本身就有架构思想在里面。

二 、在代码重构中练习

1.组件

将重复的代码合并成为一份，也就是重用。 它的着重点就是重用，那这一步最后的结果就是提炼出一个个组件在不同的业务中都可以使用。
这里我们可以看一下依赖关系，当从具体业务中提炼出来组件，组件本身之间可能也有依赖关系，但一般不多。所以我们总结组件化开发的原则就是高重用，低依赖。当然这只是相对而言。

2.模块

在实际项目中假如没有进行模块化拆分，那么很多时候会出现同一类中会有多种业务逻辑的代码，比如系统启动的时候，我们会在启动方法里直接写多个模块的初始化代码，有实际开发经验的同学一定深有感触。

而模块化开发就是为了解决这一问题，即提高内聚，将同一模块（同一套业务）代码放到一起；降低耦合，将不同模块间的耦合程度弱化。

高内聚是目标，但是现状是有许多地方会用到多个模块，比如启动的时候会调用四个模块，首页会展示三个模块的界面。如果要高内聚，那么必然需要这些模块为不同的场景提供相同的方法，这就是说所有模块要实现同一套多个接口。这样主应用和模块之间的重耦合就变成了主应用和接口耦合，接口和模块耦合这样的松耦合。 但这样的简单模块只是轻模块，统一接口较少。而统一定义的接口越多，模块和统一接口的耦合就越高，对开发人员也就越不利。这时路由就派上了大作用，但路由也只是解决模块间耦合的问题，并不是模块化开发的必然需求，只不过我们一般都会在这个时间考虑这件事，就像我们不会只做模块化开发同时不做组件化开发一样。