經(jīng)過上面的分析，可以發(fā)現(xiàn)，路由的設(shè)計(jì)思路是從URLRoute ->Protocol-class ->Target-Action一步步的深入的過程。這也是逐漸深入本質(zhì)的過程。
[
](https://github.com/halfrost/Halfrost-Field/blob/master/contents/iOSRouter/iOS%20%E7%BB%84%E4%BB%B6%E5%8C%96%20%E2%80%94%E2%80%94%20%E8%B7%AF%E7%94%B1%E8%AE%BE%E8%AE%A1%E6%80%9D%E8%B7%AF%E5%88%86%E6%9E%90.md#1-urlroute注冊(cè)方案的優(yōu)缺點(diǎn))1. URLRoute注冊(cè)方案的優(yōu)缺點(diǎn)
首先URLRoute也許是借鑒前端Router和系統(tǒng)App內(nèi)跳轉(zhuǎn)的方式想出來的方法。它通過URL來請(qǐng)求資源。不管是H5，RN，Weex，iOS界面或者組件請(qǐng)求資源的方式就都統(tǒng)一了。URL里面也會(huì)帶上參數(shù)，這樣調(diào)用什么界面或者組件都可以。所以這種方式是最容易，也是最先可以想到的。
URLRoute的優(yōu)點(diǎn)很多，最大的優(yōu)點(diǎn)就是服務(wù)器可以動(dòng)態(tài)的控制頁(yè)面跳轉(zhuǎn)，可以統(tǒng)一處理頁(yè)面出問題之后的錯(cuò)誤處理，可以統(tǒng)一三端，iOS，Android，H5 / RN / Weex 的請(qǐng)求方式。
但是這種方式也需要看不同公司的需求。如果公司里面已經(jīng)完成了服務(wù)器端動(dòng)態(tài)下發(fā)的腳手架工具，前端也完成了Native端如果出現(xiàn)錯(cuò)誤了，可以隨時(shí)替換相同業(yè)務(wù)界面的需求，那么這個(gè)時(shí)候可能選擇URLRoute的幾率會(huì)更大。
但是如果公司里面H5沒有做相關(guān)出現(xiàn)問題后能替換的界面，H5開發(fā)人員覺得這是給他們?cè)鎏碡?fù)擔(dān)。如果公司也沒有完成服務(wù)器動(dòng)態(tài)下發(fā)路由規(guī)則的那套系統(tǒng)，那么公司可能就不會(huì)采用URLRoute的方式。因?yàn)閁RLRoute帶來的少量動(dòng)態(tài)性，公司是可以用JSPatch來做到。線上出現(xiàn)bug了，可以立即用JSPatch修掉，而不采用URLRoute去做。
所以選擇URLRoute這種方案，也要看公司的發(fā)展情況和人員分配，技術(shù)選型方面。
URLRoute方案也是存在一些缺點(diǎn)的，首先URL的map規(guī)則是需要注冊(cè)的，它們會(huì)在load方法里面寫。寫在load方法里面是會(huì)影響App啟動(dòng)速度的。
其次是大量的硬編碼。URL鏈接里面關(guān)于組件和頁(yè)面的名字都是硬編碼，參數(shù)也都是硬編碼。而且每個(gè)URL參數(shù)字段都必須要一個(gè)文檔進(jìn)行維護(hù)，這個(gè)對(duì)于業(yè)務(wù)開發(fā)人員也是一個(gè)負(fù)擔(dān)。而且URL短連接散落在整個(gè)App四處，維護(hù)起來實(shí)在有點(diǎn)麻煩，雖然蘑菇街想到了用宏統(tǒng)一管理這些鏈接，但是還是解決不了硬編碼的問題。
真正一個(gè)好的路由是在無形當(dāng)中服務(wù)整個(gè)App的，是一個(gè)無感知的過程，從這一點(diǎn)來說，略有點(diǎn)缺失。
最后一個(gè)缺點(diǎn)是，對(duì)于傳遞NSObject的參數(shù)，URL是不夠友好的，它最多是傳遞一個(gè)字典。
[
](https://github.com/halfrost/Halfrost-Field/blob/master/contents/iOSRouter/iOS%20%E7%BB%84%E4%BB%B6%E5%8C%96%20%E2%80%94%E2%80%94%20%E8%B7%AF%E7%94%B1%E8%AE%BE%E8%AE%A1%E6%80%9D%E8%B7%AF%E5%88%86%E6%9E%90.md#2-protocol-class注冊(cè)方案的優(yōu)缺點(diǎn))2. Protocol-Class注冊(cè)方案的優(yōu)缺點(diǎn)
Protocol-Class方案的優(yōu)點(diǎn)，這個(gè)方案沒有硬編碼。
Protocol-Class方案也是存在一些缺點(diǎn)的，每個(gè)Protocol都要向ModuleManager進(jìn)行注冊(cè)。
這種方案ModuleEntry是同時(shí)需要依賴ModuleManager和組件里面的頁(yè)面或者組件兩者的。當(dāng)然ModuleEntry也是會(huì)依賴ModuleEntryProtocol的，但是這個(gè)依賴是可以去掉的，比如用Runtime的方法NSProtocolFromString，加上硬編碼是可以去掉對(duì)Protocol的依賴的。但是考慮到硬編碼的方式對(duì)出現(xiàn)bug，后期維護(hù)都是不友好的，所以對(duì)Protocol的依賴還是不要去除。
最后一個(gè)缺點(diǎn)是組件方法的調(diào)用是分散在各處的，沒有統(tǒng)一的入口，也就沒法做組件不存在時(shí)或者出現(xiàn)錯(cuò)誤時(shí)的統(tǒng)一處理。
[
](https://github.com/halfrost/Halfrost-Field/blob/master/contents/iOSRouter/iOS%20%E7%BB%84%E4%BB%B6%E5%8C%96%20%E2%80%94%E2%80%94%20%E8%B7%AF%E7%94%B1%E8%AE%BE%E8%AE%A1%E6%80%9D%E8%B7%AF%E5%88%86%E6%9E%90.md#3-target-action方案的優(yōu)缺點(diǎn))3. Target-Action方案的優(yōu)缺點(diǎn)
Target-Action方案的優(yōu)點(diǎn)，充分的利用Runtime的特性，無需注冊(cè)這一步。Target-Action方案只有存在組件依賴Mediator這一層依賴關(guān)系。在Mediator中維護(hù)針對(duì)Mediator的Category，每個(gè)category對(duì)應(yīng)一個(gè)Target，Categroy中的方法對(duì)應(yīng)Action場(chǎng)景。Target-Action方案也統(tǒng)一了所有組件間調(diào)用入口。
Target-Action方案也能有一定的安全保證，它對(duì)url中進(jìn)行Native前綴進(jìn)行驗(yàn)證。
Target-Action方案的缺點(diǎn)，Target_Action在Category中將常規(guī)參數(shù)打包成字典，在Target處再把字典拆包成常規(guī)參數(shù)，這就造成了一部分的硬編碼。
[
](https://github.com/halfrost/Halfrost-Field/blob/master/contents/iOSRouter/iOS%20%E7%BB%84%E4%BB%B6%E5%8C%96%20%E2%80%94%E2%80%94%20%E8%B7%AF%E7%94%B1%E8%AE%BE%E8%AE%A1%E6%80%9D%E8%B7%AF%E5%88%86%E6%9E%90.md#4-組件如何拆分)4. 組件如何拆分？
這個(gè)問題其實(shí)應(yīng)該是在打算實(shí)施組件化之前就應(yīng)該考慮的問題。為何還要放在這里說呢？因?yàn)榻M件的拆分每個(gè)公司都有屬于自己的拆分方案，按照業(yè)務(wù)線拆？按照最細(xì)小的業(yè)務(wù)功能模塊拆？還是按照一個(gè)完成的功能進(jìn)行拆分？這個(gè)就牽扯到了拆分粗細(xì)度的問題了。組件拆分的粗細(xì)度就會(huì)直接關(guān)系到未來路由需要解耦的程度。
假設(shè)，把登錄的所有流程封裝成一個(gè)組件，由于登錄里面會(huì)涉及到多個(gè)頁(yè)面，那么這些頁(yè)面都會(huì)打包在一個(gè)組件里面。那么其他模塊需要調(diào)用登錄狀態(tài)的時(shí)候，這時(shí)候就需要用到登錄組件暴露在外面可以獲取登錄狀態(tài)的接口。那么這個(gè)時(shí)候就可以考慮把這些接口寫到Protocol里面，暴露給外面使用?；蛘哂肨arget-Action的方法。這種把一個(gè)功能全部都劃分成登錄組件的話，劃分粒度就稍微粗一點(diǎn)。
如果僅僅把登錄狀態(tài)的細(xì)小功能劃分成一個(gè)元組件，那么外面想獲取登錄狀態(tài)就直接調(diào)用這個(gè)組件就好。這種劃分的粒度就非常細(xì)了。這樣就會(huì)導(dǎo)致組件個(gè)數(shù)巨多。
所以在進(jìn)行拆分組件的時(shí)候，也許當(dāng)時(shí)業(yè)務(wù)并不復(fù)雜的時(shí)候，拆分成組件，相互耦合也不大。但是隨著業(yè)務(wù)不管變化，之前劃分的組件間耦合性越來越大，于是就會(huì)考慮繼續(xù)把之前的組件再進(jìn)行拆分。也許有些業(yè)務(wù)砍掉了，之前一些小的組件也許還會(huì)被組合到一起?？傊?，在業(yè)務(wù)沒有完全固定下來之前，組件的劃分可能一直進(jìn)行時(shí)。
