iOS中的三種路由方案實(shí)踐

日常開發(fā)中,你可能會遇到這樣的問題,各個(gè)模塊相互引用,相互依賴,直觀表現(xiàn)就是引入了很多頭文件,很混亂,比如登錄、收藏消息模塊間的相互調(diào)用,這樣的代碼顯然不能符合 低耦合、高內(nèi)聚、職責(zé)單一邏輯清晰的代碼設(shè)計(jì)原則。
為此,我們可能需要使用一個(gè) 調(diào)度中心 去管理這些模塊,有了這個(gè)調(diào)度中心,每個(gè)模塊就不需要依賴其它模塊,不用導(dǎo)入其它模塊的頭文件了,只需要調(diào)度中心關(guān)心每個(gè)模塊的調(diào)度,其它模塊只需要關(guān)心怎么調(diào)用和調(diào)用后反饋的結(jié)果,這個(gè)調(diào)度中心就是 路由(Router), 這種設(shè)計(jì)模式也被稱為 中介者模式。

下面我將從以下幾個(gè)方面來介紹一下我學(xué)習(xí)到的關(guān)于路由的知識:

  1. 路由是什么
  2. 路由和組件化的關(guān)系
  3. 業(yè)界常見的三種解決方案
  4. 總結(jié)

路由是什么

路由簡單來說就是一個(gè)中轉(zhuǎn)站,輸入一條數(shù)據(jù),然后按照內(nèi)部的一定規(guī)則,處理這條數(shù)據(jù),最后輸出特定格式的新數(shù)據(jù)。

1.網(wǎng)絡(luò)層

從網(wǎng)絡(luò)的角度來說,路由就是指路由器從一個(gè)接口收到數(shù)據(jù)包,根據(jù)數(shù)據(jù)路由包的目的地址進(jìn)行定向并轉(zhuǎn)發(fā)到另一個(gè)接口的過程。

2.服務(wù)器端

從服務(wù)器角度來說,當(dāng)接收到客戶端發(fā)來的 HTTP 請求時(shí),會根據(jù)請求的URL,來找到相應(yīng)的映射函數(shù),然后執(zhí)行該函數(shù),并將函數(shù)的返回值發(fā)送給客戶端。 在WEB開發(fā)中,路由就是URL函數(shù)的映射,在WEB開發(fā)中,Route 是指根據(jù)URL找到處理這個(gè)URL函數(shù),Router 可以理解為一個(gè)容器,或者說是一種機(jī)制,它管理了一組Route

3.移動端

從移動端的角度來說,就是把URL映射到相應(yīng)的上,iOS中的路由不是僅僅做頁面跳轉(zhuǎn)的,只是用的最多的地方,主要是因?yàn)榭梢越怦铐撁嫣D(zhuǎn)的邏輯,它可以中轉(zhuǎn)的不僅僅是 Controller還可以是其它對象,比如 UIImage ...

路由和組件化的關(guān)系

路由是一個(gè)很好的解耦的方案,它可以為各個(gè)組件之間調(diào)用提供遍歷,沒有路由,組件化也是可以用的。

業(yè)界常見的三種解決方案

1.Url-scheme注冊(MGJRouter)

iOS系統(tǒng)中默認(rèn)是支持 url scheme方式的,例如可以在瀏覽器中輸入: weixin:// 就可以打開微信應(yīng)用。自然在APP內(nèi)部也可以通過這種方法來實(shí)現(xiàn)組件之間的路由設(shè)計(jì)。

這種方式實(shí)現(xiàn)的原理是在APP啟動的時(shí)候,或者是向以下實(shí)例中的每個(gè)模塊自己的load方法里面注冊自己的斷鏈(url),以及對外提供服務(wù)(Block),通過url-scheme標(biāo)記好,然后維護(hù)在url-router里面。 url-router中保存了各個(gè)組件對應(yīng)的url-scheme,只要其它組件調(diào)用了 open url 的方法,url-router就會去根據(jù)url去查找對應(yīng)的服務(wù)并執(zhí)行,詳見demo。

1.1 URL的命名規(guī)范

遵循網(wǎng)上通用的 URIweb service模式的資源通用表示方式) 的格式,例如 appscheme://pathctd://home/scan

1.2 常見案例

1.2.1 JLRoutes git 上 star 最多的一個(gè)開源庫

本質(zhì)可以理解為保存一個(gè)全局的map,keyurl,value是對應(yīng)存放的block數(shù)組,urlblock都會常駐在內(nèi)存中,當(dāng)打開一個(gè)url時(shí),GLRoutes就可以遍歷這個(gè)全局的map,通過url來執(zhí)行對應(yīng)的block。

1.2.2 routable-ios
1.2.3 HHRouter
1.2.4 MGJRouter

蘑菇街的技術(shù)團(tuán)隊(duì)開源的一個(gè)router,特點(diǎn)是使用簡單方便,JLRoutes的問題主要在于查找url的實(shí)現(xiàn)不夠高效,通過遍歷而不是匹配。還有就是功能偏多。HHRouterurl查找是基于匹配,所以會更高效,MGJRouter也是采用的這種方法,但它和viewcontroller綁定地過于緊密,一定程度上降低了靈活性。于是就有了 MGJrouter, 從數(shù)據(jù)結(jié)構(gòu)上看它和 HHRouter是一樣的。

蘑菇街方案不好的地方:

  1. URL注冊對于實(shí)施組件化是完全沒有必要的,拓展性和可維護(hù)性都降低;
  2. 基于 Open-url 的方案的話,有一個(gè)致命缺陷:非常規(guī)對象無法參與本地組件間調(diào)度;但是可以通過傳遞parms來解決,但是這個(gè)區(qū)分了遠(yuǎn)程調(diào)用和本地調(diào)用的接口;
  3. 模塊內(nèi)部是否仍然需要使用URL去完成調(diào)度?是沒有必要的,為啥要復(fù)雜化?
  4. 當(dāng)組件多起來的時(shí)候,需要提供一個(gè)關(guān)乎URL和服務(wù)的對應(yīng)表,并且需要開發(fā)人員對這樣一個(gè)表進(jìn)行維護(hù);
  5. 這種方式需要在APP啟動時(shí),每個(gè)組件需要到路由管理中心注冊自己的URL及服務(wù),因此 內(nèi)存中需要保存這樣一份表,當(dāng)組件多起來以后就會出現(xiàn)一些內(nèi)存的問題
  6. 混淆了本地調(diào)用和遠(yuǎn)程調(diào)用,它們的處理邏輯是不同的,正確的做法應(yīng)該是把遠(yuǎn)程調(diào)用通過一個(gè)中間層轉(zhuǎn)化成本地調(diào)用,如果把兩者混為一談,后期可能會出現(xiàn)無法區(qū)分業(yè)務(wù)的情況。比如對于組件無法響應(yīng)的問題,遠(yuǎn)程調(diào)用可能直接顯示一個(gè)404頁面,但是本地調(diào)用可能需要做其它處理。如果不加以區(qū)分,那么就無法完成這種業(yè)務(wù)要求。 遠(yuǎn)程調(diào)用只能傳遞被序列化JSON的數(shù)據(jù),像UIImage這樣非常規(guī)的對象是不行的,所以如果組件接口要考慮遠(yuǎn)程調(diào)用,這里的參數(shù)與就不能是這類非常規(guī)對象

2.利用Runtime實(shí)現(xiàn)的target-action方式(CTMediator)- 推薦

相較于url-scheme的方式進(jìn)行組件間的路由,runtime的方式借助了OC運(yùn)行時(shí)的特征,實(shí)現(xiàn)了組件間服務(wù)的自動發(fā)現(xiàn),無需注冊即可實(shí)現(xiàn)組件間的調(diào)用,因此,不管從維護(hù)性、可讀性、擴(kuò)展性來說,都是一個(gè)比較完美的方案, 詳見demo。

原理:

傳統(tǒng)的中介者模式,這個(gè)中間件Mediator會依賴其它組件,其它組件也會依賴mediator, 但是能不能讓mediator不在依賴組件,各個(gè)組件之間不再依賴,組件間調(diào)用只依賴中間者mediator?
casa 大神是這樣優(yōu)化的:
利用target-action的方式,創(chuàng)建一個(gè)taget的類,里面定義了一些action方法,這些方法的結(jié)果是返回一個(gè)controller或其它object,再給中間件CTMedator添加一個(gè)分類方法,定義組件外部可調(diào)用的方法接口,內(nèi)部實(shí)現(xiàn)方法 perform:target:action的方法,主要通過runtime中的 NSClassFromString 獲取target類和 NSSelectorFromString 獲取方法名,這樣就可以執(zhí)行先去創(chuàng)建的 target類中的方法得到返回值,再通過分類中的方法傳值出去,完美解決~

3.protcol-class注冊

通過協(xié)議綁定,核心思想和代理傳值是一樣的,遵循協(xié)議,實(shí)現(xiàn)協(xié)議中的方法,詳見demo。

主要思路
1、創(chuàng)建一個(gè)頭文件 CommonProtocol.h ,里面存放各個(gè)模塊提供的協(xié)議。在各個(gè)模塊依賴這個(gè)頭文件,實(shí)現(xiàn)協(xié)議的方法。
2、創(chuàng)建一個(gè)中間類 ProtocolMediator, 提供模塊的注冊和獲取模塊的功能(其實(shí)就是將類和協(xié)議名進(jìn)行綁定,放在一個(gè)字典里,key是協(xié)議名字符串,value是類)。
3、在各個(gè)模塊中實(shí)現(xiàn)協(xié)議,核心代碼如下:

Class cls = [[ProtocolMediator sharedInstance] classForProtocol:@protocol(B_VC_Protocol)];   
UIViewController<B_VC_Protocol> *B_VC = [[cls alloc] init];
[B_VC action_B:@"param1" para2:222 para3:333 para4:444];
[self presentViewController:B_VC animated:YES completion:nil];

參考文章

1、?常全?的講解了各大路由方案
2
3

總結(jié)

通過這次對路由方案的研究,認(rèn)識到了自己對系統(tǒng)架構(gòu)方面的認(rèn)識還是太少,以前并沒有認(rèn)真考慮怎么去設(shè)計(jì)一個(gè)好代碼,我們需要的事寫一些優(yōu)質(zhì)代碼,牢記 低耦合、高內(nèi)聚、職責(zé)單一邏輯清晰,不能甘心做碼農(nóng),只知道堆代碼?。?!

本文Demo地址:點(diǎn)我 CXRouterDemo

?著作權(quán)歸作者所有,轉(zhuǎn)載或內(nèi)容合作請聯(lián)系作者
【社區(qū)內(nèi)容提示】社區(qū)部分內(nèi)容疑似由AI輔助生成,瀏覽時(shí)請結(jié)合常識與多方信息審慎甄別。
平臺聲明:文章內(nèi)容(如有圖片或視頻亦包括在內(nèi))由作者上傳并發(fā)布,文章內(nèi)容僅代表作者本人觀點(diǎn),簡書系信息發(fā)布平臺,僅提供信息存儲服務(wù)。

相關(guān)閱讀更多精彩內(nèi)容

  • 前言: 本文轉(zhuǎn)自前同事casa的博文,這篇文章是基于runtime實(shí)現(xiàn)的iOS組件化方案,其實(shí)iOS組件化方案基本...
    monkey01閱讀 1,729評論 1 2
  • 隨著移動互聯(lián)網(wǎng)的不斷發(fā)展,用戶的需求越來越多,對App的用戶體驗(yàn)也變的越來越高。為了更好的應(yīng)對各種需求,開發(fā)人員從...
    xukunluren閱讀 5,239評論 6 20
  • Bang 博客 iOS 組件化方案探索 看了 Limboy(文章1文章2) 和 Casa (文章) 對 iOS 組...
    其實(shí)也沒有閱讀 675評論 0 0
  • 傳統(tǒng)項(xiàng)目結(jié)構(gòu) 缺點(diǎn) 一般當(dāng)項(xiàng)目越來越大的時(shí)候,無可避免的會遇到如下的痛點(diǎn): 代碼沖突多,編譯慢。 每一次拉下代碼開...
    spades_K閱讀 1,172評論 0 1
  • 本文參加#致我們單純的小美好#活動,本人承諾,文章內(nèi)容為原創(chuàng),且未在其他平臺發(fā)表過。 ...
    等一個(gè)筱晴天閱讀 273評論 0 5

友情鏈接更多精彩內(nèi)容