今天我们来说一个2016年 iOS 圈子里被说烂的的话题, App 的模块化.
当然, 根据我的风格, 咱们来通过一个框架来进行说明.
BeeHive, 一款阿里巴巴开源的模块化框架
BeeHive is a modular program of implementation in iOS , it absorbed the Spring Framework API service >concept to avoid to directly coupling between modules.
BeeHive 的结构
BeeHive的核心思想是模块分别处理自己的逻辑和业务, 然后通过暴露出来 模块的 service 来让模块间相互调用, 从而达到模块解耦和的作用, 下面我们来看下官方的结构图
从图中我们可以很清晰的看到 BeeHive 的结构
BHCore 作为一个中心枢纽, 可以提供模块/服务的注册, 同时它还有一个很重要的作用就是把 appdelegate 里的方法向下传递, 从而做到让每一个模块能够做到单独维护自身的生命周期, 这一点我觉得是很好的方法.
Context 作为一个上下文也是让我觉得非常不错的一个设计, 这里面提供了当前的运行环境, App 的配置 以及 一些静态服务/静态模块的加载路径, 这样的做法能够让每一个模块都能根据下传的上下文在同一种状态或者环境中去进行初始化
模块和服务都是由每一个小组单独处理, 但是值得注意的是他们需要在一个统一的地方去维护自己模块独有的 service 协议.
更加细节的配置或者 event 请自行官网查看,或者阅读源代码.
思考
BeeHive 虽然是阿里开源的一款开源框架, 但是在我看来他还是一个不这么好用的框架, 所谓不这么好用的原因是它太简单了, 去除了多余的东西, 就保留了最原始的 模块和服务, 我们可以说这是他的优点,但是这也是它的缺点,就想 GO 语言一样, 爱他的人为他着迷, 恨他的人每天都在抱怨, 这个因人而定.
而, 我个人是喜欢复杂一点点的.
模块化就是为了解耦和, 在目前主流的两大派系就是 Router/Target-action
首先两大派系的共同点都是需要维护一种共同的协议, router 维护的是 url 规则和跳转协议, target-action 维护的是 service 的 interface, 这个大家半斤八两, 有人觉得 url 来的更方便, 有人觉得 action 来的更清晰.
url 的优点在于很擅长处理页面跳转的场景, 直接通过 url 就能跳转到相应的页面 但是缺点也是很明确的, 一个是不能很优雅的传递对象, 只能在 url 传递一些类似 id, type 之类的参数, 如果一定要传递对象, 要不就有一个中心管理器持有对象, 然后在 url 传递指针地址, 或者对应的 key, 第二种方式就是把对象序列化再反序列化,但是这种我认为不好,有要处理序列化又对性能有所损耗.第二个不足之处就是对于逻辑的处理有不足之处,我们如果给不同的逻辑处理也添加相应的 url scheme 与之对应,不免会造成不清晰的感觉.
target-action 的最大优点在于清晰, serivce 中调用的方法清晰的描述了要做的事情, 又能很方便的传递参数.这一点是 url 怎么也无法媲美的. 第二个优点在于安全, 不会因为外界了解了app 内 url 跳转的规律从而通过模仿 url 来做一些不好的事情. 但是缺点就是我之前说的麻烦, 写起来麻烦, 用起来麻烦, 页面跳转更是各种纠结.
在我看来既然两种方式既然都有可取之处, 咱们就都拿过来使用, 使用 url 来处理跳转情景, 用 target-action 来处理逻辑相关的东西.
这样的坏处很明显, 需要维护两份协议, service 和 url scheme
但是优点也是有的
- 处理页面跳转时候很方便
- APP 和 web 可以很好的结合在一起, 相互调用很方便
- 能够把一些敏感逻辑封装到 service 中, 保证不能被随便调用
我的疑惑: 如果使用 url 进行跳转, 那么我们在同一模块中是否也要使用这种方式呢? 各路大神各种讨论, 我是在模块内也要使用 router 跳转那类人