iOS開發——App架構之抽象協議
從架構設計層面，一個端，尤其是一個成熟的端，應該有自己的規范，大到頁面跳轉、服務請求，小到某個具體的業務功能比如生成訂單、取消訂單、查看訂單等。一方面，制定統一的協議后，不僅可以約束各業務線開發同學的開發行為，統一代碼的風格，還可以增強團隊同學的合作以及凝聚力，另一方面，統一開發行為后，對于增加新的功能、修復bug、查詢問題等都有很好的幫助，極大提高開發效率。
App 架構組最重要的一個職能就是統一 App 架構，讓業務開發同學在一套統一的架構中盡情塑造端的產品，以提高業務開發效率和保證業務使用穩定性為己任。本著這一原則，這一年來也在不斷探索各種跟 App 架構相關技能。協議是我發現最能體現 App 架構意義的一個關鍵技術，用好以及推廣好協議，能使業務開發效率倍增。
一般來說，App 中的協議類型可以任意發散，只要可以復用的地方，你都可以用協議一言以蔽之。當然，我們都是有追求的人，應該創造一些更通用、更抽象、更值得讓大家復用的協議，舉個栗子，iOS SDK 中 url scheme 就是這樣一個典型。
iOS URL Scheme
URL Schemes是蘋果給出的用來跳轉到系統應用或者跳轉到別人的應用的一種機制，同時還可以在應用之間傳遞數據，用于實現一些特定的功能。你可以完全按照理解一個網頁的 URL 的方式來理解一個 iOS 應用的 URL。
比如微信的 url scheme
- weixin://
微信朋友圈 url scheme 格式
- weixin://dl/moments
看著是不是很方便?
在其他app中，你可以像這樣就可以跳轉到微信 App 應用(如果已安裝的話)
- NSURL *url = [NSURL URLWithString:@"weixin://"];
- [[UIApplication sharedApplication] openURL:url options:@{} completionHandler:^(BOOL success) {
- }];
每個應用都可以創建一個或者一些自己的 url scheme，只需要配置 info.plist 文件即可，然后通過 App 管理中心 [UIApplication sharedApplication] 即可進行 App 之間的通信。
同樣，我們將這樣的思路可以應用到其他抽象模塊中來。在每一個抽象模塊中，我們用一個協議來指定它的使用規則以及支持的功能，開放給調用方使用時，只要其遵循協議規則，使用抽象模塊提供的 api 接口，即可進行模塊的調用或者使用其提供的服務。
由此，我們得出這樣一個結論：采用協議方式抽象一個模塊，需要兩個重要組件：協議+協議管理中心。
通用協議
- scheme://service/actor?params=\{\"xxx\":xxx\}&origin=xxx
在 App 架構中，頁面導航框架是非常重要的一個組件，直接決定當前 App 的頁面組織形式以及風格，好的頁面導航框架也能讓業務方開發擁有***的新頁面搭建以及頁面間跳轉體驗。從協議角度出發，我們可以這樣約定一個頁面跳轉協議：
頁面跳轉協議
- page://action?params=\{\}&origin=xxx
- // 跳轉 native 頁面
- page://goto?params={"page_name":"xxxx","data":{"xxx":"xxx",...},"navi_type":0|1,"anime_type":-1|0|1|2|3|4,"success_callback":"xxxxxx","failure_callback":"xxxxx"}&origin=xxx
- // 跳轉 h5 頁面
- page://act_web?params={"page_name":"xxxx","data":{"xxx":"xxx",...},"navi_type":0|1,"anime_type":-1|0|1|2|3|4,"success_callback":"xxxxxx","failure_callback":"xxxxx"}&origin=xxx
Manager 需要提供的 api 包括：
- // 跳轉 native 頁面
- // 跳轉 h5 頁面
服務請求協議
- // @TODO 可繼續拆分
- service://modulename/servicename?params={}&origin=xxx
Bridge 橋接協議
- // bridge 為特定 scheme，bridgename 為bridge js庫支持的api
- bridge://bridgename?module=xxx&method=xxx&args=\{\}&origin=xxx
