1、前言
组件化就是基于可重用的目的，将一个大的软件系统按照分离关注点的形式，拆分成多个独立的组件，以较少耦合、提升长远收益。
在之前我的一篇文章中，提到过关于组件化的一些概念，可以参考《GMTC移动开发者大会纪实（二）组件化只是一句口号吗》。接下来的几篇文章，主要会写下我们团队实施组件化的一些经历。
2、组件化原因
对于组件化，简单的说就是项目逐步变大过程中的必由之路。
在准备做组件化之前，随着逐步迭代现有项目结构暴露了一些问题：
- 代码整体结构混乱、缺少层次；
- 耦合严重，代码边界不清晰；
- 龟速编译，开发体验极差；
- 无法很好的支持A/BTest；
正是因为这些问题，我们才逐渐规划了组件化。当然同时需要强调的是项目架构、开发模式等都不会一直存在最优解，架构、开发模式的选择和项目所处阶段、团队规模、业务场景等息息相关，毕竟在业务刚起步打量的阶段和精细化运营阶段团队的重心是不一样的。
3、正确认识组件化
现如今网上已经有很多组件化思路、实践等文章了，但是有必要提一下的是对组件化首先需要正确认识：
- 何时实施组件化以及组件化的具体方案等都需要结合项目所处阶段、团队规模等来决断；
- 组件化不是炫技术，不是故弄玄虚；网上有文章讲普通的组件化实现竟然有“难点在于解决跨进程通信”，坦白的说这种就属于自己强行给自己提升B格了（忽悠到小白那真是MMP了）；
- 传统意义上的组件化和插件化是两条路：组件化发生在开发阶段、插件化发生在运行阶段；
- 纵然二者可以结合，但是独立组件对绝大多数App难有使用场景；
- 组件如果在运行阶段不是在自己独立的进程，那必然是拉B格无疑；
- 说好的组件化却又去扯动态化也是拉B格无疑；
4、组件化思路
首先对于组件分为两类：技术组件和业务组件；而组件化具体的思路也一定要和自己的使用场景相结合：
- 对于技术组件，合理封装，注意不要放在一起，避免技术组件库巨大无比；
- 对业务组件，可选择自己依赖的技术组件够业务组件单独运行即可；
- 对于独立组件，这种场景相对较少，一般见于一个模块需要运行于多个APP里（在自己单独的进程）；
对于我们的组件化，我们首先需要的是模块之间的解耦，形式就是各个Module自己能跑起来，因而我们的思路更偏向于前两种。
5、组件化实施过程
实施过程描述起来相对简单，但是实践过程其中酸爽只有经历才会明白这是一段血泪史。具体过程在下篇讲，此处只简述；
- 对于技术组件需要合理封装，减少之后可能存在的替换成本；
- 同时注意，将技术组件分为常用和非常用，可以选择自己需要的技术组件，避免一个统一的技术组件库过大；
- 将业务代码根据模块进行剥离，剥离成一个个的小模块；
- 单独的业务模块加上必要的技术组件，支撑在开发阶段的独立运行；
6、组件化实施难点
- 技术组件的整理、抽离；
- 一定要有的DisPatcher：提供隐式的跳转和模块间方法调用能力；
- 组件的划分；
- 调试及集成方式；
