项目发展到一定阶段，业务线增多，团队庞大，需求变更加速，组件化变成一种“刚需”。
组件化最早在一些大厂被提出，如淘宝、蘑菇街、滴滴等，都有各自的组件化实践，
这些实践满足了各个平台的业务发展需要，同时也让组件化的定义越发模糊，本文从实践角度，梳理一下组件化过程，供在组件化道路上迷茫的开发者参考。
本文讨论以下三个主题：
- 通信方案的选择
- 组件的划分方式，定义组件包含的内容
- 最后给出一个Demo，演示组件的集成和消息传递。
本文主要从iOS技术角度出发，兼顾跨平台实践，其它平台可以对应参考，其思想是贯通的。
通信方案的选择
由于组件对通信库有直接的依赖关系，通信方案决定着组件封装形式，讨论组件化的实践，就需要先确定组件的通信方式，常见的通信方式有下面三种：
通信方式1: 协议
将方法调用抽象为协议，调用者依赖抽象协议，从而避免与实际被调用者紧耦合，是面向对象的传统方法。
协议的缺点是：维护时需要同时维护Protocol、接口类两部分，影响开发效率。
通信方式2: Target-Action
Target-Action方式，说白了，就是利用了OC的分类特性，在中间件中“声明”了每个组件各自的方法，优点是参数传递和返回值直观，可以强控制参数类型，以至于在很多组件方案中都是优先选择。
强方法会造成一些问题，举例来说，设想在手机淘宝中，搜索“保温杯”后显示一个商品列表，其中的商品可能来自天猫也有可能来自C铺，点击后分别打开天猫详情页和C铺详情页，这两个商品页面差别较大，业务流程也有差异，应该分为两个组件，这就需要根据跳转的商品，区分不同平台，并调用不同分类方法，这部分代码无论由调用者还是中间件来处理，都导致硬编码，有悖组件化的初衷。
通信方式3: Route
在 RESTful 系统中，URL 都已经不陌生，Route 方式是这种思路在APP内的自然选择，Route 方式在传值上有限制，不过在一个已经适配了 RESTful 的项目中，遇到的不便实际很少，毕竟如果一个项目已经能 Web 化，必要的模型都已经 json 化，能通过 URL 传输。
在前面“保温杯”的例子中，来自天猫的详情页URL可以是：
/tmall/detail/:itemid
来自C铺的详情页URL可以是：
/taobao/detail/:itemid
直接在 URL 上就区分了两个组件，中间件可以直接跳转，不需要额外的编码。
小结
通信方案是组件化的基础，基于 URL 的 Route 方式，形式统一，自然区分了不同组件，成为组件化的首选。