今天我們來說一個(gè)2016年 iOS 圈子里被說爛的的話題, App 的模塊化.
當(dāng)然, 根據(jù)我的風(fēng)格, 咱們來通過一個(gè)框架來進(jìn)行說明.
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 的結(jié)構(gòu)
BeeHive的核心思想是模塊分別處理自己的邏輯和業(yè)務(wù), 然后通過暴露出來 模塊的 service 來讓模塊間相互調(diào)用, 從而達(dá)到模塊解耦和的作用, 下面我們來看下官方的結(jié)構(gòu)圖
從圖中我們可以很清晰的看到 BeeHive 的結(jié)構(gòu)
BHCore 作為一個(gè)中心樞紐, 可以提供模塊/服務(wù)的注冊(cè), 同時(shí)它還有一個(gè)很重要的作用就是把 appdelegate 里的方法向下傳遞, 從而做到讓每一個(gè)模塊能夠做到單獨(dú)維護(hù)自身的生命周期, 這一點(diǎn)我覺得是很好的方法.
Context 作為一個(gè)上下文也是讓我覺得非常不錯(cuò)的一個(gè)設(shè)計(jì), 這里面提供了當(dāng)前的運(yùn)行環(huán)境, App 的配置 以及 一些靜態(tài)服務(wù)/靜態(tài)模塊的加載路徑, 這樣的做法能夠讓每一個(gè)模塊都能根據(jù)下傳的上下文在同一種狀態(tài)或者環(huán)境中去進(jìn)行初始化
模塊和服務(wù)都是由每一個(gè)小組單獨(dú)處理, 但是值得注意的是他們需要在一個(gè)統(tǒng)一的地方去維護(hù)自己模塊獨(dú)有的 service 協(xié)議.
更加細(xì)節(jié)的配置或者 event 請(qǐng)自行官網(wǎng)查看,或者閱讀源代碼.
思考
BeeHive 雖然是阿里開源的一款開源框架, 但是在我看來他還是一個(gè)不這么好用的框架, 所謂不這么好用的原因是它太簡(jiǎn)單了, 去除了多余的東西, 就保留了最原始的 模塊和服務(wù), 我們可以說這是他的優(yōu)點(diǎn),但是這也是它的缺點(diǎn),就想 GO 語言一樣, 愛他的人為他著迷, 恨他的人每天都在抱怨, 這個(gè)因人而定.
而, 我個(gè)人是喜歡復(fù)雜一點(diǎn)點(diǎn)的.
模塊化就是為了解耦和, 在目前主流的兩大派系就是 Router/Target-action
首先兩大派系的共同點(diǎn)都是需要維護(hù)一種共同的協(xié)議, router 維護(hù)的是 url 規(guī)則和跳轉(zhuǎn)協(xié)議, target-action 維護(hù)的是 service 的 interface, 這個(gè)大家半斤八兩, 有人覺得 url 來的更方便, 有人覺得 action 來的更清晰.
url 的優(yōu)點(diǎn)在于很擅長(zhǎng)處理頁面跳轉(zhuǎn)的場(chǎng)景, 直接通過 url 就能跳轉(zhuǎn)到相應(yīng)的頁面 但是缺點(diǎn)也是很明確的, 一個(gè)是不能很優(yōu)雅的傳遞對(duì)象, 只能在 url 傳遞一些類似 id, type 之類的參數(shù), 如果一定要傳遞對(duì)象, 要不就有一個(gè)中心管理器持有對(duì)象, 然后在 url 傳遞指針地址, 或者對(duì)應(yīng)的 key, 第二種方式就是把對(duì)象序列化再反序列化,但是這種我認(rèn)為不好,有要處理序列化又對(duì)性能有所損耗.第二個(gè)不足之處就是對(duì)于邏輯的處理有不足之處,我們?nèi)绻o不同的邏輯處理也添加相應(yīng)的 url scheme 與之對(duì)應(yīng),不免會(huì)造成不清晰的感覺.
target-action 的最大優(yōu)點(diǎn)在于清晰, serivce 中調(diào)用的方法清晰的描述了要做的事情, 又能很方便的傳遞參數(shù).這一點(diǎn)是 url 怎么也無法媲美的. 第二個(gè)優(yōu)點(diǎn)在于安全, 不會(huì)因?yàn)橥饨缌私饬薬pp 內(nèi) url 跳轉(zhuǎn)的規(guī)律從而通過模仿 url 來做一些不好的事情. 但是缺點(diǎn)就是我之前說的麻煩, 寫起來麻煩, 用起來麻煩, 頁面跳轉(zhuǎn)更是各種糾結(jié).
在我看來既然兩種方式既然都有可取之處, 咱們就都拿過來使用, 使用 url 來處理跳轉(zhuǎn)情景, 用 target-action 來處理邏輯相關(guān)的東西.
這樣的壞處很明顯, 需要維護(hù)兩份協(xié)議, service 和 url scheme
但是優(yōu)點(diǎn)也是有的
- 處理頁面跳轉(zhuǎn)時(shí)候很方便
- APP 和 web 可以很好的結(jié)合在一起, 相互調(diào)用很方便
- 能夠把一些敏感邏輯封裝到 service 中, 保證不能被隨便調(diào)用
我的疑惑: 如果使用 url 進(jìn)行跳轉(zhuǎn), 那么我們?cè)谕荒K中是否也要使用這種方式呢? 各路大神各種討論, 我是在模塊內(nèi)也要使用 router 跳轉(zhuǎn)那類人
