APP组件化实践(一):通信方案的选择

组件化-题图.png

项目发展到一定阶段,业务线增多,团队庞大,需求变更加速,组件化变成一种“刚需”。
组件化最早在一些大厂被提出,如淘宝、蘑菇街、滴滴等,都有各自的组件化实践,
这些实践满足了各个平台的业务发展需要,同时也让组件化的定义越发模糊,本文从实践角度,梳理一下组件化过程,供在组件化道路上迷茫的开发者参考。
本文讨论以下三个主题:

  1. 通信方案的选择
  2. 组件的划分方式,定义组件包含的内容
  3. 最后给出一个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 方式,形式统一,自然区分了不同组件,成为组件化的首选。

推荐阅读更多精彩内容