GMTC移动开发者大会纪实（二）组件化只是一句口号吗

1、什么是组件化

到了17年的今天，组件化实在不会是一个新名词。各种关于组件化、模块化的讨论层出不穷，具体实践方案也历经了好几代的演进，到了现在甚至已经有完善的组件化框架类如Small、Atlas等。那么回归初心：什么是组件化？

组件化就是基于可重用的目的，将一个大的软件系统按照分离关注点的形式，拆分成多个独立的组件，以较少耦合、提升长远收益。

直白的说，组件化开发就是将一个大工程进行细化，分为若干个组件，开发过程中由面向大工程开发转向面向组件开发。在Android中的具体实践是一个组件是一个Module，开发过程中在独立Module里进行开发、调试；在回归阶段再集成到主App。

2、组件化的意义

2.1 代码解耦

单工程代码结构的项目一定会遇到代码量持续变大、各模块耦合严重的问题。组件化开发将各个模块独立为组件，单组件的代码量会减少，而且模块之间的交互通信通过统一的接口协议，达到高内聚、低耦合。

2.2 功能复用

对于组件，分为技术组件和业务组件。如果组件很好的被拆分，达到高内聚、低耦合的标准，那么同样的功能势必可以直接复用组件。这点功能复用和在单工程项目里的代码复用有什么区别呢？单工程里的代码复用很大程度上可能做不到高内聚、低耦合（和别的模块耦合或者人为因素），满足不了需要的话很有可能是直接再写一份而不是对其进行更改。

2.3 效率

• 开发效率：单工程的项目结构开发阶段每次修改都会是全量编译，项目变大之后肯定面临着龟速的编译，研发体验极差；而组件化之后单独针对组件进行编译，经过拆分的组件体量变小，编译速度会加快。
• 测试效率：单工程代码结构的项目，在回归测试阶段，不管有没有改动某模块，QA都需要对其进行回归测试（多次提交难以保证代码真的没有别动过），会造成大量的资源浪费。而在组件化之后，针对组件进行开发，没有修改过的组件就可以不对其进行回归测试，节约测试资源。

3、组件化是噱头吗

组件化的思路说来容易但是实践起来也不是温馨的请客吃饭，如果不是从项目初期就做好了组件化的准备，那半路出家的组件化推进一定会极度困难：抽取Lib、组件的剥离、组件的交互规则都会让你烦恼的不要不要的。那么既然推进起来如此困难，组件化只是一个噱头吗？

不，肯定不是。

3.1 组件化是项目变大之后的一个必由之路

需要注意的是：项目架构、开发模式等都不会存在一个最优解，架构、开发模式的选择和项目所处阶段、团队规模、业务场景等息息相关。不是每一个App做大之后都要走插件化的道路，但每一个App做大之后都要走组件化的道路。因为2W行代码的项目一定和发展到20W行代码之后的项目挑战不一样，开发模式与架构不升级的话，一点会遇到瓶颈，造成资源的损耗；而组件化是一个一本万利的事情，只需付出前期的汗水，后期的回报更多。

3.2 深入理解业务、整理代码的机会

项目做大的过程中，势必会伴随着人员的流动，很多模块历经多次的迭代、维护人员的变更，很少有人能说清其中的具体业务以及其中的补偿逻辑。这点我相信每一个研发同学平时都是抱着不到最后一刻不去看所维护的代码的原则，相当于这块业务其实是没有人能接上的，出现Bug之后再变抱怨变看代码，影响工作情绪也影响工作效率。

而组件化相当于提供了一个机会：深入理解业务、整理代码的机会。要想做组件化，势必需要拆分业务，那就需要反过来逼自己去理解业务，整理写的不好的代码。

3.3 协作模式的升级、架构的深层理解

上面提到了：因为2W行代码的项目一定和发展到20W行代码之后的项目挑战不一样，如果因为嫌麻烦而不去实践新的协作模式、架构，那纸上谈兵，只说不练，自己的能力一定不匹配更高复杂度的项目。

3.4 整个团队的正面影响

协作模式、架构的升级可以刺激团队成员不断的探索学习；而对于业务的深入理解、整理则是培养脚踏实地的团队作风。最后的收益，不管是代码结构的整洁、编译速度的提升、回归周期的减短对整个团队都是正向的刺激。

4、如何推进组件化

记得说过了很多次，很多的选择，需要结合多种条件：自身产品形态、需求、团队规模、组成等来具体分析，解决方案只有最合适的，没有最通用且最优。

• 如果项目具有动态化的需求，可以使用Small、Atlas框架，组价化和插件化的完美结合；
• 如果是一般性的组件化需求可以参考以下思路。

4.1 抽取独立Lib Module

各业务组件需要使用到各自基础功能，因此首先需要一个独立的技术组件，为业务组件提最基本的支撑，这是组件化的基础。

备注：很多App属于壮大之后来做组件化，那么抽取Lib的过程一定是万般痛苦。建议解决方案是重新封装一个技术Lib，新起的业务使用新的技术Lib，老的业务，逐渐替换。

4.2 路由的实现

各独立组件要独立编译、运行，但也免不了和别的业务组件有交互：跳转和组件间通信。那么一个路由协议是必要的，否则跳转都是强引用，是做不到独立编译的。而组件之间的通信方式可以独立选择：使用路由或者接口。

4.3 业务剥离

这块就是组件的划分了，如何划分组件，肯定的需要结合自身业务。我们可以想一下一个电商类的App业务组件可以分为哪些：登录、列表、商品详情、搜索、支付、购物车等。组件化的开始阶段组件可以粒度较粗，一步步细化。

4.4 问题解决

这部分就是趟坑了：比如DisPatcher的实现方式、组件间通信的实现方式、资源冲突、重复依赖等问题。