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

在之前我的一篇文章中，提到过关于组件化的一些概念，可以参考《GMTC移动开发者大会纪实（二）组件化只是一句口号吗》。接下来的几篇文章，主要会写下我们团队实施组件化的一些经历。

对于组件化，简单的说就是项目逐步变大过程中的必由之路。

在准备做组件化之前，随着逐步迭代现有项目结构暴露了一些问题：

正是因为这些问题，我们才逐渐规划了组件化。当然同时需要强调的是项目架构、开发模式等都不会一直存在最优解，架构、开发模式的选择和项目所处阶段、团队规模、业务场景等息息相关，毕竟在业务刚起步打量的阶段和精细化运营阶段团队的重心是不一样的。

现如今网上已经有很多组件化思路、实践等文章了，但是有必要提一下的是对组件化首先需要正确认识：

何时实施组件化以及组件化的具体方案等都需要结合项目所处阶段、团队规模等来决断；
组件化不是炫技术，不是故弄玄虚；网上有文章讲普通的组件化实现竟然有“难点在于解决跨进程通信”，坦白的说这种就属于自己强行给自己提升B格了（忽悠到小白那真是MMP了）；
- 传统意义上的组件化和插件化是两条路：组件化发生在开发阶段、插件化发生在运行阶段；
- 纵然二者可以结合，但是独立组件对绝大多数App难有使用场景；
- 组件如果在运行阶段不是在自己独立的进程，那必然是拉B格无疑；
- 说好的组件化却又去扯动态化也是拉B格无疑；

首先对于组件分为两类：技术组件和业务组件；而组件化具体的思路也一定要和自己的使用场景相结合：

对于我们的组件化，我们首先需要的是模块之间的解耦，形式就是各个Module自己能跑起来，因而我们的思路更偏向于前两种。

实施过程描述起来相对简单，但是实践过程其中酸爽只有经历才会明白这是一段血泪史。具体过程在下篇讲，此处只简述；

本文主要讲组件化的缘由、思路、难点等，有个概念就好；具体的实践过程、难点解决及方案思考在下篇文章，欢迎关注！

欢迎关注微信公众号：定期分享Java、Android干货！