原文鏈接: http://casatwy.com/iOS-Modulization.html?hmsr=toutiao.io&utm_medium=toutiao.io&utm_source=toutiao.io 作者是大神啊

iOS應用架構談 開篇
iOS應用架構談 view層的組織和調用方案
iOS應用架構談 網絡層設計方案
iOS應用架構談 本地持久化方案及動態部署
iOS應用架構談 組件化方案

簡述

前幾天的一個晚上在infoQ的微信群里，來自蘑菇街的Limboy做了一個分享，講了蘑菇街的組件化之路。我不認為這條組件化之路蘑菇街走對了。分享后我私聊了Limboy，Limboy似乎也明白了問題所在，我答應他我會把我的方案寫成文章，于是這篇文章就出來了。

另外，按道理說組件化方案也屬于iOS應用架構談的一部分，但是當初構思架構談時，我沒打算寫組件化方案，因為我忘了還有這回事兒。。。后來寫到view的時候才想起來，所以在view的那篇文章最后補了一點內容。而且覺得這個組件化方案太簡單，包括實現組件化方案的組件也很簡單，代碼算上注釋也才100行，我就偷懶放過了，畢竟寫一篇文章好累的啊。

本文的組件化方案demo在這里https://github.com/casatwy/CTMediator 拉下來后記得pod install 拉下來后記得pod install 拉下來后記得pod install
，這個Demo對業務敏感的邊界情況處理比較簡單，這需要根據不同App的特性和不同產品的需求才能做，所以只是為了說明組件化架構用的。如果要應用在實際場景中的話，可以根據代碼里給出的注釋稍加修改，就能用了。

蘑菇街的原文地址在這里：《蘑菇街 App 的組件化之路》，沒有耐心看完原文的朋友，我在這里簡要介紹一下蘑菇街的組件化是怎么做的：

App啟動時實例化各組件模塊，然后這些組件向ModuleManager注冊Url，有些時候不需要實例化，使用class注冊。
當組件A需要調用組件B時，向ModuleManager傳遞URL，參數跟隨URL以GET方式傳遞，類似openURL。然后由ModuleManager負責調度組件B，最后完成任務。

這里的兩步中，每一步都存在問題。

第一步的問題在于，在組件化的過程中，注冊URL并不是充分必要條件，組件是不需要向組件管理器注冊Url的。而且注冊了Url之后，會造成不必要的內存常駐，如果只是注冊Class，內存常駐量就小一點，如果是注冊實例，內存常駐量就大了。至于蘑菇街注冊的是Class還是實例，Limboy分享時沒有說，文章里我也沒看出來，也有可能是我看漏了。不過這還并不能算是致命錯誤，只能算是小缺陷。

真正的致命錯誤在第二步。在iOS領域里，一定是組件化的中間件為openUrl提供服務，而不是openUrl方式為組件化提供服務。

什么意思呢？

也就是說，一個App的組件化方案一定不是建立在URL上的，openURL的跨App調用是可以建立在組件化方案上的。當然，如果App還沒有組件化，openURL方式也是可以建立的，就是丑陋一點而已。

為什么這么說？

因為組件化方案的實施過程中，需要處理的問題的復雜度，以及拆解、調度業務的過程的復雜度比較大，單純以openURL的方式是無法勝任讓一個App去實施組件化架構的。如果在給App實施組件化方案的過程中是基于openURL的方案的話，有一個致命缺陷：非常規對象無法參與本地組件間調度。關于非常規對象
我會在詳細講解組件化方案時有一個辨析。

實際App場景下，如果本地組件間采用GET方式的URL調用，就會產生兩個問題：

根本無法表達非常規對象

比如你要調用一個圖片編輯模塊，不能傳遞UIImage到對應的模塊上去的話，這是一個很悲催的事情。 當然，這可以通過給方法新開一個參數，然后傳遞過去來解決。比如原來是:

[a openUrl:"http://casa.com/detail?id=123&type=0"];

同時就也要提供這樣的方法：

[a openUrl:"http://casa.com/detail" params:@{ @"id":"123", @"type":"0", @"image":[UIImage imageNamed:@"test"]}]

如果不像上面這么做，復雜參數和非常規參數就無法傳遞。如果這么做了，那么事實上這就是拆分遠程調用和本地調用的入口了，這就變成了我文章中提倡的做法，也是蘑菇街方案沒有做到的地方。

另外，在本地調用中使用URL的方式其實是不必要的，如果業務工程師在本地間調度時需要給出URL，那么就不可避免要提供params，在調用時要提供哪些params是業務工程師很容易懵逼的地方。。。在文章下半部分給出的demo代碼樣例已經說明了業務工程師在本地間調用時，是不需要知道URL的，而且demo代碼樣例也闡釋了如何解決業務工程師遇到傳params容易懵逼的問題。

URL注冊對于實施組件化方案是完全不必要的，且通過URL注冊的方式形成的組件化方案，拓展性和可維護性都會被打折

注冊URL的目的其實是一個服務發現的過程，在iOS領域中，服務發現的方式是不需要通過主動注冊的，使用runtime就可以了。另外，注冊部分的代碼的維護是一個相對麻煩的事情，每一次支持新調用時，都要去維護一次注冊列表。如果有調用被棄用了，是經常會忘記刪項目的。runtime由于不存在注冊過程，那就也不會產生維護的操作，維護成本就降低了。
由于通過runtime做到了服務的自動發現，拓展調用接口的任務就僅在于各自的模塊，任何一次新接口添加，新業務添加，都不必去主工程做操作，十分透明。

小總結

蘑菇街采用了openURL的方式來進行App的組件化是一個錯誤的做法，使用注冊的方式發現服務是一個不必要的做法。而且這方案還有其它問題，隨著下文對組件化方案介紹的展開，相信各位自然心里有數。

正確的組件化方案

先來看一下方案的架構圖

這幅圖是組件化方案的一個簡化版架構描述，主要是基于Mediator模式和Target-Action模式，中間采用了runtime來完成調用。這套組件化方案將遠程應用調用和本地應用調用做了拆分，而且是由本地應用調用為遠程應用調用提供服務，與蘑菇街方案正好相反。

調用方式

先說本地應用調用，本地組件A在某處調用

[[CTMediator sharedInstance] performTarget:targetName action:actionName params:@{...}]

向CTMediator發起跨組件調用，CTMediator根據獲得的target和action信息，通過objective-C的runtime轉化生成target實例以及對應的action選擇子，然后最終調用到目標業務提供的邏輯，完成需求。

在遠程應用調用中，遠程應用通過openURL的方式，由iOS系統根據info.plist里的scheme配置找到可以響應URL的應用（在當前我們討論的上下文中，這就是你自己的應用），應用通過AppDelegate接收到URL之后，調用CTMediator的openUrl:方法將接收到的URL信息傳入。

當然，CTMediator也可以用openUrl:options:的方式順便把隨之而來的option也接收，這取決于你本地業務執行邏輯時的充要條件是否包含option數據。傳入URL之后，CTMediator通過解析URL，將請求路由到對應的target和action，隨后的過程就變成了上面說過的本地應用調用的過程了，最終完成響應。

針對請求的路由操作很少會采用本地文件記錄路由表的方式，服務端經常處理這種業務，在服務端領域基本上都是通過正則表達式來做路由解析。App中做路由解析可以做得簡單點，制定URL規范就也能完成，最簡單的方式就是scheme://target/action
這種，簡單做個字符串處理就能把target和action信息從URL中提取出來了。

組件僅通過Action暴露可調用接口

所有組件都通過組件自帶的Target-Action來響應，也就是說，模塊與模塊之間的接口被固化在了Target-Action這一層，避免了實施組件化的改造過程中，對Business的侵入，同時也提高了組件化接口的可維護性。

Paste_Image.png

大家可以看到，虛線圈起來的地方就是用于跨組件調用的target和action，這種方式避免了由BusinessA直接提供組件間調用會增加的復雜度，而且任何組件如果想要對外提供調用服務，直接掛上target和action就可以了，業務本身在大多數場景下去進行組件化改造時，是基本不用動的。

復雜參數和非常規參數，以及組件化相關設計思路

這里我們需要針對術語做一個理解上的統一：
復雜參數
是指由普通類型
的數據組成的多層級參數。在本文中，我們定義只要是能夠被json解析的類型就都是普通類型
，包括NSNumber， NSString， NSArray， NSDictionary，以及相關衍生類型，比如來自系統的NSMutableArray或者你自己定義的都算。
總結一下就是：在本文討論的場景中，復雜參數的定義是由普通類型組成的具有復雜結構的參數。普通類型的定義就是指能夠被json解析的類型。
非常規參數
是指由普通類型
以外的類型組成的參數，例如UIImage等這些不能夠被json解析的類型。然后這些類型組成的參數在文中就被定義為非常規參數
。
總結一下就是：非常規參數
是包含非常規類型的參數。非常規類型
的定義就是不能被json解析的類型都叫非常規類型。

邊界情況：

假設多層級參數中有存在任何一個內容是非常規參數，本文中這種參數就也被認為是非常規參數。

如果某個類型當前不能夠被json解析，但通過某種轉化方式能夠轉化成json，那么這種類型在場景上下文中，我們也稱為普通類型。

舉個例子就是通過json描述的自定義view。如果這個view能夠通過某個組件被轉化成json，那么即使這個view本身并不是普通類型，在具有轉化器的上下文場景中，我們依舊認為它是普通類型。

如果上下文場景中沒有轉化器，這個view就是非常規類型了。

假設轉化出的json不能夠被還原成view，比如組件A有轉化器，組件B中沒有轉化器，因此在組件間調用過程中json在B組件里不能被還原成view。在這種調用方向中，只要調用者能將非常規類型轉化成json的，我們就依然認為這個view是普通類型。如果調用者是組件A，轉化器在組件B中，A傳遞view參數時是沒辦法轉化成json的，那么這個view就被認為是非常規類型，哪怕它在組件B中能夠被轉化成json。

然后我來解釋一下為什么應該由本地組件間調用來支持遠程應用調用：

在遠程App調用時，遠程App是不可能通過URL來提供非常規參數的，最多只能以json string的方式經過URLEncode之后再通過GET來提供復雜參數，然后再在本地組件中解析json，最終完成調用。在組件間調用時，通過performTarget:action:params:
是能夠提供非常規參數的，于是我們可以知道，遠程App調用
時的上下文環境以及功能是本地組件間調用
時上下文環境以及功能的子集
。

因此這個邏輯注定了必須由本地組件間調用來為遠程App調用來提供服務，只有符合這個邏輯的設計思路才是正確的組件化方案的設計思路，其他跟這個不一致的思路一定就是錯的。因為邏輯上子集為父集提供服務說不通，所以強行這么做的話，用一個成語來總結就叫做倒行逆施。

另外，遠程App調用和本地組件間調用必須要拆分開，遠程App調用只能走CTMediator
提供的專用遠程的方法，本地組件間調用只能走CTMediator
提供的專用本地的方法，兩者不能通過同一個接口來調用。
這里有兩個原因：

遠程App調用處理入參的過程比本地多了一個URL解析的過程，這是遠程App調用特有的過程。這一點我前面說過，這里我就不細說了。

架構師沒有充要條件條件可以認為遠程App調用對于無響應請求的處理方式和本地組件間調用無響應請求的處理方式在未來產品的演進過程中是一致的

在遠程App調用中，用戶通過url進入app，當app無法為這個url提供服務時，常見的辦法是展示一個所謂的404界面，告訴用戶"當前沒有相對應的內容，不過你可以在app里別的地方再逛逛"。這個場景多見于用戶使用的App版本不一致。比如有一個URL只有1.1版本的app能完整響應，1.0版本的app雖然能被喚起，但是無法完成整個響應過程，那么1.0的app就要展示一個404了。

在組件間調用中，如果遇到了無法響應的請求，就要分兩種場景考慮了。

場景1

如果這種無法響應的請求發生場景是在開發過程中，比如兩個組件同時在開發，組件A調用組件B時，組件B還處于舊版本沒有發布新版本，因此響應不了，那么這時候的處理方式可以相對隨意，只要能體現B模塊是舊版本就行了，最后在RC階段統測時是一定能夠發現的，只要App沒發版，怎么處理都來得及。

場景2

如果這種無法響應的請求發生場景是在已發布的App中，有可能展示個404就結束了，那這就跟遠程App調用時的404處理場景一樣。但也有可能需要為此做一些額外的事情，有可能因為做了額外的事情，就不展示404了，展示別的頁面了，這一切取決于產品經理。

那么這種場景是如何發生的呢？

我舉一個例子：當用戶在1.0版本時收藏了一個東西，然后用戶升級App到1.1版本。1.0版本的收藏項目在本地持久層存入的數據有可能是會跟1.1版本收藏時存入的數據是不一致的。此時用戶在1.1版本的app中對1.0版本收藏的東西做了一些操作，觸發了本地組件間調用，這個本地間調用又與收藏項目本身的數據相關，那么這時這個調用就是有可能變成無響應調用，此時的處理方式就不見得跟以前一樣展示個404頁面就結束了，因為用戶已經看到了收藏了的東西，結果你還告訴他找不到，用戶立刻懵逼。。。這時候的處理方式就會用很多種，至于產品經理會選擇哪種，你作為架構師是沒有辦法預測的。如果產品經理提的需求落實到架構上，對調用入口產生要求然而你的架構又沒有拆分調用入口，對于你的選擇就只有兩個：要么打回產品需求，要么加個班去拆分調用入口。

當然，架構師可以選擇打回產品經理的需求，最終挑選一個自己的架構能夠承載的需求。但是，如果這種是因為你早期設計架構時挖的坑而打回的產品需求，你不覺得丟臉么？

鑒于遠程app調用和本地組件間調用下的無響應請求處理方式不同，以及未來不可知的產品演進，拆分遠程app調用入口和本地組件間調用入口是功在當代利在千秋的事情。

組件化方案中的去model設計

組件間調用時，是需要針對參數做去model化的。如果組件間調用不對參數做去model化的設計，就會導致業務形式上被組件化了，實質上依然沒有被獨立
。

假設模塊A和模塊B之間采用model化的方案去調用，那么調用方法時傳遞的參數就會是一個對象。

如果對象不是一個面向接口的通用對象，那么mediator的參數處理就會非常復雜，因為要區分不同的對象類型。如果mediator不處理參數，直接將對象以范型的方式轉交給模塊B，那么模塊B必然要包含對象類型的聲明。假設對象聲明放在模塊A，那么B和A之間的組件化只是個形式主義。如果對象類型聲明放在mediator，那么對于B而言，就不得不依賴mediator。但是，大家可以從上面的架構圖中看到，對于響應請求的模塊而言，依賴mediator并不是必要條件，因此這種依賴是完全不需要的，這種依賴的存在對于架構整體而言，是一種污染。

如果參數是一個面向接口的對象，那么mediator對于這種參數的處理其實就沒必要了，更多的是直接轉給響應方的模塊。而且接口的定義就不可能放在發起方的模塊中了，只能放在mediator中。響應方如果要完成響應，就也必須要依賴mediator，然而前面我已經說過，響應方對于mediator的依賴是不必要的，因此參數其實也并不適合以面向接口的對象的方式去傳遞。

因此，使用對象化的參數無論是否面向接口，帶來的結果就是業務模塊形式上是被組件化了，但實質上依然沒有被獨立。

在這種跨模塊場景中，參數最好還是以去model化的方式去傳遞，在iOS的開發中，就是以字典的方式去傳遞。這樣就能夠做到只有調用方依賴mediator，而響應方不需要依賴mediator。然而在去model化的實踐中，由于這種方式自由度太大，我們至少需要保證調用方生成的參數能夠被響應方理解，然而在組件化場景中，限制去model化方案的自由度的手段，相比于網絡層和持久層更加容易得多。

因為組件化天然具備了限制手段：參數不對就無法調用！無法調用時直接debug就能很快找到原因。所以接下來要解決的去model化方案的另一個問題就是：如何提高開發效率。

在去model的組件化方案中，影響效率的點有兩個：調用方如何知道接收方需要哪些key的參數？調用方如何知道有哪些target可以被調用？其實后面的那個問題不管是不是去model的方案，都會遇到。為什么放在一起說，因為我接下來要說的解決方案可以把這兩個問題一起解決。

解決方案就是使用category

mediator這個repo維護了若干個針對mediator的category，每一個對應一個target，每個category里的方法對應了這個target下所有可能的調用場景，這樣調用者在包含mediator的時候，自動獲得了所有可用的target-action，無論是調用還是參數傳遞，都非常方便。接下來我要解釋一下為什么是category而不是其他：

category本身就是一種組合模式，根據不同的分類提供不同的方法，此時每一個組件就是一個分類，因此把每個組件可以支持的調用用category封裝是很合理的。

在category的方法中可以做到參數的驗證，在架構中對于保證參數安全是很有必要的。當參數不對時，category就提供了補救的入口。

category可以很輕松地做請求轉發，如果不采用category，請求轉發邏輯就非常難做了。

category統一了所有的組件間調用入口，因此無論是在調試還是源碼閱讀上，都為工程師提供了極大的方便。

由于category統一了所有的調用入口，使得在跨模塊調用時，對于param的hardcode在整個App中的作用域僅存在于category中，在這種場景下的hardcode就已經變成和調用宏或者調用聲明沒有任何區別了，因此是可以接受的。

這里是業務方使用category調用時的場景，大家可以看到非常方便，不用去記URL也不用糾結到底應該傳哪些參數。

if (indexPath.row == 0) { 
    UIViewController *viewController = [[CTMediator sharedInstance] CTMediator_viewControllerForDetail]; 
    // 獲得view controller之后，在這種場景下，到底push還是present，其實是要由使用者決定的，mediator只要給出view controller的實例就好了 
    [self presentViewController:viewController animated:YES completion:nil]; 
} 
if (indexPath.row == 1) { 
    UIViewController *viewController = [[CTMediator sharedInstance] CTMediator_viewControllerForDetail];
    [self.navigationController pushViewController:viewController animated:YES]; 
} if (indexPath.row == 2) { 
    // 這種場景下，很明顯是需要被present的，所以不必返回實例，mediator直接present了
    [[CTMediator sharedInstance] CTMediator_presentImage:[UIImage imageNamed:@"image"]];
 } 
if (indexPath.row == 3) { 
    // 這種場景下，參數有問題，因此需要在流程中做好處理 
    [[CTMediator sharedInstance] CTMediator_presentImage:nil]; 
} 
if (indexPath.row == 4) { 
    [[CTMediator sharedInstance] CTMediator_showAlertWithMessage:@"casa" cancelAction:nil confirmAction:^(NSDictionary *info) {
    // 做你想做的事
    NSLog(@"%@", info); 
    }]; 
}

本文對應的demo展示了如何使用category來實現去model的組件調用。上面的代碼片段也是摘自這個demo。

基于其他考慮還要再做的一些額外措施

基于安全考慮

我們需要防止黑客通過URL的方式調用本屬于native的組件，比如支付寶的個人財產頁面。如果在調用層級上沒有區分好，沒有做好安全措施，黑客就有通過safari查看任何人的個人財產的可能。

安全措施其實有很多，大部分取決于App本身以及產品的要求。在架構層面要做的最基礎的一點就是區分調用是來自于遠程App還是本地組件，我在demo中的安全措施是采用給action添加native
前綴去做的，凡是帶有native前綴的就都只允許本地組件調用，如果在url階段發現調用了前綴為native的方法，那就可以采取響應措施了。這也是將遠程app調用入口和本地組件調用入口區分開來的重要原因之一。
當然，為了確保安全的做法有很多，但只要拆出遠程調用和本地調用，各種做法就都有施展的空間了。

基于動態調度考慮

動態調度的意思就是，今天我可能這個跳轉是要展示A頁面，但是明天可能同樣的跳轉就要去展示B頁面了。這個跳轉有可能是來自于本地組件間跳轉也有可能是來自于遠程app。

做這個事情的切點在本文架構中，有很多個：

以url parse為切點
以實例化target時為切點
以category調度方法為切點
以target下的action為切點

如果以url parse為切點
的話，那么這個動態調度就只能夠對遠程App跳轉產生影響，失去了動態調度本地跳轉的能力，因此是不適合的。

如果以實例化target時為切點
的話，就需要在代碼中針對所有target都做一次審查，看是否要被調度，這是沒必要的。假設10個調用請求中，只有1個要被動態調度，那么就必須要審查10次，只有那1次審查通過了，才走動態調度，這是一種相對比較粗暴的方法。

如果以category調度方法為切點
的話，那動態調度就只能影響到本地件組件的跳轉，因為category是只有本地才用的，所以也不適合。

以target下的action為切點
是最適合的，因為動態調度在一般場景下都是有范圍的，大多數是活動頁需要動態調度，今天這個活動明天那個活動，或者今天活動正在進行明天活動就結束了，所以產生動態調度的需求。我們在可能產生動態調度的action中審查當前action是否需要被動態調度，在常規調度中就沒必要審查了，例如個人主頁的跳轉，商品詳情的跳轉等，這樣效率就能比較高。

大家會發現，如果要做類似這種效率更高的動態調度，target-action層被抽象出來就是必不可少的，然而蘑菇街并沒有抽象出target-action層，這也是其中的一個問題。

當然，如果你的產品要求所有頁面都是存在動態調度需求的，那就還是以實例化target時為切點
去調度了，這樣能做到審查每一次調度請求，從而實現動態調度。

說完了調度切點，接下來要說的就是如何完成審查流程。完整的審查流程有幾種，我每個都列舉一下：

App啟動時下載調度列表，或者定期下載調度列表。然后審查時檢查當前action是否存在要被動態調度跳轉的action，如果存在，則跳轉到另一個action
每一次到達新的action時，以action為參數調用API獲知是否需要被跳轉，如果需要被跳轉，則API告知要跳轉的action，然后再跳轉到API指定的action

這兩種做法其實都可以，如果產品對即時性的要求比較高，那么采用第二種方案，如果產品對即時性要求不那么高，第一種方案就可以了。由于本文的方案是沒有URL注冊列表的，因此服務器只要給出原始target-action和對應跳轉的target-action就可以了，整個流程不是只有注冊URL列表才能達成的，而且這種方案比注冊URL列表要更易于維護一些。

另外，說采用url rewrite的手段來進行動態調度，也不是不可以。但是這里我需要辨析的是，URL的必要性僅僅體現在遠程App調度中，是沒必要蔓延到本地組件間調用的。這樣，當我們做遠程App的URL路由時（目前的demo沒有提供URL路由功能，但是提供了URL路由操作的接入點，可以根據業務需求插入這個功能），要關心的事情就能少很多，可以比較干凈。在這種場景下，單純以URL rewrite的方式其實就與上文提到的以url parse為切點
沒有區別了。

相比之下，蘑菇街的組件化方案有以下缺陷

蘑菇街沒有拆分遠程調用和本地間調用

不拆分遠程調用和本地間調用，就使得后續很多手段難以實施，這個我在前文中都已經有論述了。另外再補充一下，這里的拆分不是針對來源做拆分。比如通過URL來區分是遠程App調用還是本地調用，這只是區分了調用者的來源。

這里說的區分是指：遠程調用走遠程調用路徑，也就是openUrl>urlParse->perform->target-action。
本地組件間調用就走本地組件間調用路徑：perform->target-action。
這兩個是一定要作區分的，蘑菇街方案并沒有對此做好區分。

蘑菇街以遠程調用的方式為本地間調用提供服務

這是本末倒置的做法，倒行逆施導致的是未來架構難以為業務發展提供支撐。因為前面已經論述過，在iOS場景下，遠程調用的實現是本地調用實現的子集，只有大的為小提供服務，也就是本地調用為遠程調用提供服務，如果反過來就是倒行逆施了。

蘑菇街的本地間調用無法傳遞非常規參數，復雜參數的傳遞方式非常丑陋

注意這里復雜參數
和非常規參數
的辨析。

由于采用遠程調用的方式執行本地調用，在前面已經論述過兩者功能集的關系，因此這種做法無法滿足傳遞非常規參數的需求。而且如果基于這種方式不變的話，復雜參數的傳遞也只能依靠經過urlencode的json string進行，這種方式非常丑陋，而且也不便于調試。

蘑菇街必須要在app啟動時注冊URL響應者

這個條件在組件化方案中是不必要條件，demo也已經證實了這一點。這個不必要的操作會導致不必要的維護成本，如果單純從只要完成業務就好
的角度出發，這倒不是什么大問題。這就看架構師對自己是不是要求嚴格了。

新增組件化的調用路徑時，蘑菇街的操作相對復雜

在本文給出的組件化方案中，響應者唯一要做的事情就是提供Target和Action，并不需要再做其它的事情。蘑菇街除此之外還要再做很多額外不必要措施，才能保證調用成功。

蘑菇街沒有針對target層做封裝

這種做法使得所有的跨組件調用請求直接hit到業務模塊，業務模塊必然因此變得臃腫難以維護，屬于侵入式架構。應該將原本屬于調用相應的部分拿出來放在target-action中，才能盡可能保證不將無關代碼侵入到原有業務組件中，才能保證業務組件未來的遷移和修改不受組件調用的影響，以及降低為項目的組件化實施而帶來的時間成本。

總結

本文提供的組件化方案是采用Mediator模式和蘋果體系下的Target-Action模式設計的。

然而這款方案有一個很小的缺陷在于對param的key的hardcode，這是為了達到最大限度的解耦和靈活度而做的權衡。在我的網絡層架構和持久層架構中，都沒有hardcode的場景，這也從另一個側面說明了組件化架構的特殊性。

權衡時，考慮到這部分hardcode的影響域僅僅存在于mediator的category中
。在這種情況下，hardcode對于調用者的調用是完全透明的。對于響應者而言，處理方式等價于對API返回的參數的處理方式，且響應者的處理方式也被限制在了Action中
。

因此這部分的hardcode的存在雖然確實有點不干凈，但是相比于這些不干凈而帶來的其他好處而言，在權衡時是可以接受的，如果不采用hardcode，那勢必就會導致請求響應方也需要依賴mediator
，然而這在邏輯上是不必要
的。另外，在我的各個項目的實際使用過程中，這部分hardcode是沒有影響的。

另外要談的是，之所以會在組件化方案中出現harcode，而網絡層和持久層的去model化都沒有發生hardcode情況，是因為組件化調用的所有接受者和調用者都在同一片上下文里。網絡層有一方在服務端，持久層有一方在數據庫。再加上設計時針對hardcode部分的改進手段其實已經超出了語言本身的限制。也就是說，harcode受限于語言本身。objective-C也好，swift也好，它們的接口設計哲學是存在缺陷的。如果我們假設在golang的背景下，是完全可以用golang的接口體系去做一個最優美的架構方案出來的。不過這已經不屬于本文的討論范圍了，有興趣的同學可以去了解一下相關知識。架構設計有時就是這么無奈。

組件化方案在App業務穩定，且規模（業務規模和開發團隊規模）增長初期去實施非常重要，它助于將復雜App分而治之，也有助于多人大型團隊的協同開發。但組件化方案
不適合在業務不穩定的情況下過早實施，至少要等產品已經經過MVP階段時才適合實施組件化。因為業務不穩定意味著鏈路不穩定，在不穩定的鏈路上實施組件化會導致將來主業務產生變化時，全局性模塊調度和重構會變得相對復雜。
當決定要實施組件化方案時，對于組件化方案的架構設計優劣直接影響到架構體系能否長遠地支持未來業務的發展，對App的組件化不只是僅僅的拆代碼和跨業務調頁面
，還要考慮復雜和非常規業務參數參與的調度，非頁面的跨組件功能調度，組件調度安全保障，組件間解耦，新舊業務的調用接口修改等問題。

蘑菇街的組件化方案只實現了跨業務頁面調用的需求，本質上只實現了我在view層架構的文章中跨業務頁面調用的內容，這還沒有到成為組件化方案
的程度，且蘑菇街的組件化方案距離真正的App組件化的要求還是差了一段距離的，且存在設計邏輯缺陷，希望蘑菇街能夠加緊重構，打造真正的組件化方案。