iOS VIPER架構(三)

路由是實現模塊間解耦的一個有效工具。如果要進行組件化開發，路由是必不可少的一部分。目前iOS上絕大部分的路由工具都是基于URL匹配的，優缺點都很明顯。這篇文章里將會給出一個更加原生和安全的設計，這個設計的特點是：

路由時用protocol尋找模塊
可以對模塊進行固定的依賴注入和運行時依賴注入
支持不同模塊間進行接口適配和轉發，因此無需和某個固定的protocol關聯
充分解耦的同時，增加類型安全
支持移除已執行的路由
封裝UIKit界面跳轉方法，可以一鍵跳轉和移除
支持storyboard，支持其他任意模塊
可以檢測界面跳轉時的大部分錯誤

如果你想要一個能夠充分解耦、類型安全、有依賴注入功能的路由器，那這個就是目前所能找到的最佳方案。

這個路由工具是為了實踐VIPER模式而設計的，目的是為VIPER提供依賴注入功能，不過它也可以用于MVC、MVP、MVVM，沒有任何限制。

工具和Demo地址：ZIKRouter。

Router的作用

首先，我們需要梳理清楚，為什么我們需要Router，Router能帶來什么好處，解決什么問題？我們需要一個什么樣的Router？

路由缺失時的情況

沒有路由時，界面跳轉的代碼就很容易產生模塊間耦合。

iOS中執行界面跳轉時，用的是UIViewController上提供的跳轉方法：

[sourceViewController.navigationController pushViewController:destinationViewController animated:YES];

[sourceViewController presentViewController:destinationViewController animated:YES completion:nil];

如果是直接導入destinationViewController的頭文件進行引用，就會導致和destinationViewController模塊產生耦合。類似的，一個模塊引用另一個模塊時也會產生這樣的耦合。因此我們需要一個方式來獲取destinationViewController，但又不能對其產生直接引用。

這時候就需要路由提供的"尋找模塊"的功能。以某種動態的方式獲取目的模塊。

那么路由是怎么解決模塊耦合的呢？在上一篇VIPER講解里，路由有這幾個主要職責：

尋找指定模塊，執行具體的路由操作
聲明模塊的依賴
聲明模塊的對外接口
對模塊內各部分進行依賴注入

通過這幾個功能，就能實現模塊間的完全解耦。

尋找模塊

路由最重要的功能就是給出一種尋找某個指定模塊的方案。這個方案是松耦合的，獲取到的模塊在另一端可以隨時被另一個相同功能的模塊替換，從而實現兩個模塊之間的解耦。

尋找模塊的實現方式其實只有有限的幾種：

用一個字符串identifier來標識某個對應的界面（URL Router、UIStoryboardSegue）
利用Objective-C的runtime特性，直接調用目的模塊的方法（CTMediator）
用一個protocol來和某個界面進行匹配（蘑菇街的第二種路由和阿里的BeeHive），這樣就可以更安全的對目的模塊進行傳參

這幾種方案的優劣將在之后逐一細說。

聲明依賴和接口

一個模塊A有時候需要使用其他模塊的功能，例如最通用的log功能，不同的app有不同的log模塊，如果模塊A對通用性要求很高，log方法就不能在模塊A里寫死，而是應該通過外部調用。這時這個模塊A就依賴于一個log模塊了。App在使用模塊A的時候，需要知道它的依賴，從而在使用模塊A之前，對其注入依賴。

當通過cocoapods這樣的包管理工具來配置不同模塊間的依賴時，一般模塊之間是強耦合的，模塊是一一對應的，當需要替換一個模塊時會很麻煩，容易牽一發而動全身。如果是一個單一功能模塊，的確需要依賴其他特定的各種庫時，那這樣做沒有問題。但是如果是一個業務模塊中引用了另一個業務模塊，就應該盡量避免互相耦合。因為不同的業務模塊一般是由不同的人負責，應該避免出現一個業務模塊的簡單修改（例如調整了方法或者屬性的名字）導致引用了它的業務模塊也必須修改的情況。

這時候，業務模塊就需要在代碼里聲明自己需要依賴的模塊，讓app在使用時提供這些模塊，從而充分解耦。

示例代碼：

@protocol ZIKLoginServiceInput <NSObject>
- (void)loginWithAccount:(NSString *)account password:(NSString *)password success:(void(^_Nullable)(void))successHandler error:(void(^_Nullable)(void))errorHandler; @end

@interface ZIKNoteListViewController ()
//筆記界面需要登錄后才能查看，因此在頭文件中聲明，讓外部在使用的時候設置此屬性
@property (nonatomic, strong) id<ZIKLoginServiceInput> loginService; @end

這個聲明依賴的工作其實是模塊的Builder的職責。一個界面模塊大部分情況下都不止有一個UIViewController，也有其他一些Manager或者Service，而這些角色都是有各自的依賴的，都統一由模塊的Builder聲明，再在Builder內部設置依賴。不過在上一篇文章的VIPER講解里，我們把Builder的職責也放到了Router里，讓每個模塊單獨提供一個自己的Router。因此在這里，Router是一個離散的設計，而不是一個單例Router掌管所有的路由。這樣的好處就是每個模塊可以充分定制和控制自己的路由過程。

可以聲明依賴，也就可以同時聲明模塊的對外接口。這兩者很相似，所以不再重復說明。

Builder和依賴注入

執行路由的同時用Builder進行模塊構建，構建的時候就對模塊內各個角色進行依賴注入。當你調用某個模塊的時候，需要的不是某個簡單的具體類，而是一個構建完畢的模塊中的某個具體類。在使用這個模塊前，模塊需要做一些初始化的操作，比如VIPER里設置各個角色之間的依賴關系，就是一個初始化操作。因此使用路由去獲取某個模塊中的類，必定需要通過模塊的Builder進行。很多路由工具都缺失了這部分功能。

你可以把依賴注入簡單地看成對目的模塊傳參。在進行界面跳轉和使用某個模塊時，經常需要設置目的模塊的一些參數，例如設置delegate回調。這時候就必須調用一些目的模塊的方法，或者傳遞一些對象。由于每個模塊需要的參數都不一樣，目前大部分Router都是使用字典包裹參數進行傳遞。但其實還有更好、更安全的方案，下面將會進行詳解。

你也可以把Router、Builder和Dependency Injector分開，不過如果Router是一個離散型的設計，那么都交給各自的Router去做也很合理，同時能夠減少代碼量，也能夠提供細粒度的AOP。

現有的Router

梳理完了路由的職責，現在來比較一下現有的各種Router方案。關于各個方案的具體實現細節我就不再展開看，可以參考這篇詳解的文章：iOS 組件化 —— 路由設計思路分析。

URL Router

目前絕大多數的Router都是用一串URL來表示需要打開的某個界面，代碼上看來大概是這樣：

//注冊某個URL，和路由處理進行匹配保存
[URLRouter registerURL:@"settings" handler:^(NSDictionary *userInfo) {UIViewController *sourceViewController = userInfo[@"sourceViewController"]; //獲取其他參數 id param = userInfo[@"param"]; //獲取需要的界面 UIViewController *settingViewController = [[SettingViewController alloc] init]; [sourceViewController.navigationController pushViewController: settingViewController animated:YES]; }];

//調用路由
[URLRouter openURL:@"myapp://noteList/settings?debug=true" userInfo:params completion:^(NSDictionary *info) {}];

傳遞一串URL就能打開noteList界面的settings界面，用字典包裹需要傳遞的參數，有時候還會把UIKit的push、present等方法進行簡單封裝，提供給調用者。

這種方式的優點和缺點都很突出。

優點

極高的動態性

這是動態性最高的方案，甚至可以在運行時隨時修改路由規則，指向不同的界面。也可以很輕松地支持多級頁面的跳轉。

如果你的app是電商類app，需要經常做活動，app內的跳轉規則經常變動，那么就很適合使用URL的方案。

統一多端路由規則

URL的方案是最容易跨平臺實現的，iOS、Andorid、web、PC都按照URL來進行路由時，也就可以統一管理多端的路由規則，降低多端各自維護和修改的成本，讓不懂技術的運營人員也可以簡單快速地修改路由。

和上一條一樣，這也是一個和業務強相關的優點。如果你有統一多端的業務需求，使用URL也很合適。

適配URL scheme

iOS中的URL scheme可以跨進程通信，從app外打開app內的某個指定頁面。當app內的頁面都能使用URL打開時，也就直接兼容了URL scheme，無需再做額外的工作。

缺點

不適合通用模塊

URL Router的設計只適合UI模塊，不適合其他功能性模塊的組件。功能性模塊的調用并不需要如此強的動態特性，除非是有模塊熱更新的需求，否則一個模塊的調用在一個版本里應該總是穩定不變的，即便要進行模塊間解耦，也不應該用這種方式。

安全性差

字符串匹配的方式無法進行編譯時檢查，當頁面配置出錯時，只能在運行時才能發現。如果某個開發人員不小心在字符串里加了一個空格，編譯時也無法發現。你可以用宏定義來減少這種出錯的幾率。

維護困難

沒有高效地聲明接口的方式，只能從文檔里查找，編寫時必須仔細對照字符串及其參數類型。

傳參通過字典來進行，參數類型無法保證，而且也無法準確地知道所調用的接口需要哪些參數。當目的模塊進行了接口升級，修改了參數類型和數量，那所有用到的地方都要一一修改，并且沒有編譯器的幫助，你無法知道是否遺漏了某些地方。這將會給維護和重構帶來極大的成本。

針對這個問題，蘑菇街的選擇是用另一個Router，用protocol來獲取目的模塊，再進行調用，增加安全性。

Protocol Router

這個方案也很容易理解。把之前的字符串匹配改成了protocol匹配，就能獲取到一個實現了某個protocol的對象。

開源方案里只看到了BeeHive實現了這樣的方式：

id<ZIKLoginServiceInput> loginService = [[BeeHive shareInstance] createService:@protocol(ZIKLoginServiceInput)];

優點

安全性好，維護簡單

再對這個對象調用protocol中的方法，就十分安全了。在重構和修改時，有了編譯器的類型檢查，效率更高。

適用于所有模塊

Protocol更加符合OC和Swift原生的設計思想，任何模塊都可以使用，而不局限于UI模塊。

優雅地聲明依賴

模塊A需要用到登錄模塊，但是它要怎么才能聲明這種依賴關系呢？如果使用Protocol Router，那就只需要在頭文件里定義一個屬性：

@property (nonatomic, string) id<ZIKLoginServiceInput> *loginService;

如果這個依賴是必需依賴，而不是一個可選依賴，那就添加到初始化參數里：

@interface ModuleA ()
- (instancetype)initWithLoginService:(id<ZIKLoginServiceInput>)loginService;
@end

問題是，如果這樣的依賴很多，那么初始化方法就會變得很長。因此更好的做法是由Builder進行固定的依賴注入，再提供給外部。目前BeeHive并沒有提供依賴注入的功能。

缺點

動態性有限

你可以維護一份protocol和模塊的對照表，使用動態的protocol來嘗試動態地更改路由規則，也可以在Protocol Router之上封裝一層URL Router專門用于動態性的需求。

需要額外適配URL Scheme

使用了Protocol Router就需要再額外處理URL Scheme了。不過這樣也是正常的，解析URL Scheme本來就應該放到另一個單獨的模塊里。

Protocol是否會導致耦合？

很多談到這種方案的文章都會指出，和URL Router相比，Protocol Router會導致調用者引用目的模塊的protocol，因此會產生"耦合"。我認為這是對"解耦"的錯誤理解。

要想避免耦合，首先要弄清楚，我們需要什么程度的解耦。我的定義是：模塊A調用了模塊B，模塊B的接口或者實現在做出簡單的修改時，或者模塊B被替換為相同功能的模塊C時，模塊A不需要進行任何修改。這時候就可以認為模塊A和模塊B是解耦的。

業務設計的互相關聯

有些時候，表達出兩個模塊之間的關聯是有意義的。

當一個界面A需要展示一個登錄界面時，它可能需要向登錄界面傳遞一個"提示語"參數，用于在登錄界面顯示一串提示。這時候，界面A在調用登錄界面時，是要求登錄界面能夠顯示這個自定義提示語的，在業務設計中就存在兩個模塊間的強關聯性。這時候，URL Router和Protocol Router沒有任何區別，包括下面將要提到的Target-Action路由方式，都存在耦合，但是Protocol Router通過簡單地改善，是可以把這部分耦合去除的。

URL Router：

[URLRouter openURL:@"login" userInfo:@{@"message":@"請登錄查看筆記詳情"}];

Protocol Router:

@protocol LoginViewInput <NSObject>
@property (nonatomic, copy) NSString *message; @end //獲取登錄界面進行設置 UIViewController<LoginViewInput> *loginViewController = [ProtocolRouter destinationForProtocol:@protocol(LoginViewInput)]; loginViewController.message = @"請登錄查看筆記詳情";

由于字典傳參的原因，URL Router只不過是把這種接口上的關聯隱藏到了字典key里，它在參數字典里使用@"message"時，就是在隱式地使用LoginViewInput的接口。

這種業務設計上導致的模塊之間互相關聯是不可避免的，也是不需要去隱藏的。隱藏了反而會引來麻煩。如果登錄界面的屬性名字變了，從NSString *message改成了NSString *notifyString，那么URL Router在register的時候也必須修改傳參時的代碼。如果register是由登錄界面自己執行和處理的，而不是由App Context來處理的，那么此時參數key是固定為@"notifyString"的，那就會要求所有調用者的傳參key也修改為notifyString，這種修改如果缺少編譯器的幫助會很危險，目前是用宏來減少這種修改導致的工作量。而Protocol Router在修改時就能充分利用編譯器進行檢查，能夠保證100%安全。

因此，URL Router并不能做到解耦，只是隱藏了接口關聯而已。一旦遇到了需要修改或者重構的情況，麻煩就出現了，在替換宏的時候，你還必須仔細檢查有沒有哪里有直接使用字符串的key。只是簡單地修改名字還是可控的，如果是需要增加參數呢？這時候就根本無法檢查哪里遺漏了參數傳遞了。這就是字典傳參的壞處。

關于這部分的討論，也可以參考Peak大佬的文章：iOS組件化方案。

Protocol Router在這種情況下也需要作出修改，但是它能幫助你安全高效地進行重構。而且只要稍加改進，也可以完全無需修改。解決方法就是把Protocol分離為Required Interface和Provided Interface。

`Required Interface`?和?`Provided Interface`

模塊的接口其實是有Required Interface和Provided Interface的區別的。Required Interface就是調用者需要用到的接口，Provided Interface就是實際的被調用者提供的接口。

在UML的組件圖中，就很明確地表現出了這兩者的概念。下圖中的半圓就是Required Interface，框外的圓圈就是Provided Interface：

組件圖

那么如何實施Required Interface和Provided Interface？上一篇文章里已經討論過，應該由App Context在一個adapter里進行接口適配，從而使得調用者可以繼續在內部使用Required Interface，adapter負責把Required Interface和修改后的Provided Interface進行適配。

示例代碼：

@protocol ModuleARequiredLoginViewInput <NSObject>
@property (nonatomic, copy) NSString *message; @end //Module A中的調用代碼 UIViewController<ModuleARequiredLoginViewInput> *loginViewController = [ZIKViewRouterToView(LoginViewInput) makeDestination]; loginViewController.message = @"請登錄查看筆記詳情";

//Login Module Provided Interface
@protocol ProvidedLoginViewInput <NSObject> @property (nonatomic, copy) NSString *notifyString; @end

//App Context 中的 Adapter，用Objective-C的category或者Swift的extension進行接口適配
@interface LoginViewController (ModuleAAdapte) <ModuleARequiredLoginViewInput> @property (nonatomic, copy) NSString *message; @end @implementation LoginViewController (ModuleAAdapte) - (void)setMessage:(NSString *)message { self.notifyString = message; } - (NSString *)message { return self.notifyString; } @end

用category、extension、NSProxy等技術兼容新舊接口，工作全部由模塊的使用和裝配者App Context完成。如果LoginViewController已經有了自己的message屬性，這時候就說明新的登錄模塊是不可兼容的，必須有某一方做出修改。當然，接口適配能做的事情是有限的，例如一個接口從同步變成了異步，那么這時候兩個模塊也是不能兼容的。

因此，如果模塊需要進行解耦，那么它的接口在設計的時候就應該十分仔細，盡量不要在參數中引入太多其他的模塊依賴。

只有存在Required Interface和Provided Interface概念的設計，才能做到徹底的解耦。目前的路由方案都缺失了這一部分。

Target-Action

CTMediator的方案，把對模塊的調用封裝到Target-Action中，利用了Objective-C的runtime特性，省略了Target-Action的注冊和綁定工作，直接通過CTMediator中介者調用目的模塊的方法。

@implementation CTMediator (CTMediatorModuleAActions)
- (UIViewController *)CTMediator_viewControllerForDetail { UIViewController *viewController = [self performTarget:kCTMediatorTargetA action:kCTMediatorActionNativFetchDetailViewController params:@{@"key":@"value"} shouldCacheTarget:NO ]; if ([viewController isKindOfClass:[UIViewController class]]) { // view controller 交付出去之后，可以由外界選擇是push還是present return viewController; } else { // 這里處理異常場景，具體如何處理取決于產品 return [[UIViewController alloc] init]; } } @end

-performTarget:action:params:shouldCacheTarget:方法通過NSClassFromString，獲取目的模塊提供的Target類，再調用Target提供的Action，實現了方法調用：

@implementation CTMediator
- (id)performTarget:(NSString *)targetName action:(NSString *)actionName params:(NSDictionary *)params shouldCacheTarget:(BOOL)shouldCacheTarget { NSString *targetClassString = [NSString stringWithFormat:@"Target_%@", targetName]; NSString *actionString = [NSString stringWithFormat:@"Action_%@:", actionName]; Class targetClass; NSObject *target = self.cachedTarget[targetClassString]; if (target == nil) { targetClass = NSClassFromString(targetClassString); target = [[targetClass alloc] init]; } SEL action = NSSelectorFromString(actionString); if (target == nil) { // 這里是處理無響應請求的地方之一，這個demo做得比較簡單，如果沒有可以響應的target，就直接return了。實際開發過程中是可以事先給一個固定的target專門用于在這個時候頂上，然后處理這種請求的 return nil; } if (shouldCacheTarget) { self.cachedTarget[targetClassString] = target; } if ([target respondsToSelector:action]) { return [self safePerformAction:action target:target params:params]; } else { // 有可能target是Swift對象 actionString = [NSString stringWithFormat:@"Action_%@WithParams:", actionName]; action = NSSelectorFromString(actionString); if ([target respondsToSelector:action]) { return [self safePerformAction:action target:target params:params]; } else { // 這里是處理無響應請求的地方，如果無響應，則嘗試調用對應target的notFound方法統一處理 SEL action = NSSelectorFromString(@"notFound:"); if ([target respondsToSelector:action]) { return [self safePerformAction:action target:target params:params]; } else { // 這里也是處理無響應請求的地方，在notFound都沒有的時候，這個demo是直接return了。實際開發過程中，可以用前面提到的固定的target頂上的。 [self.cachedTarget removeObjectForKey:targetClassString]; return nil; } } } } @end

優點

實現簡潔，整個實現的代碼量很少
省略了路由注冊的步驟，可以減少一部分內存消耗和時間消耗，但是也略微降低了調用時的性能
使用場景不局限于界面模塊，所有模塊都可以通過中介者調用

缺點

在調用action時使用字典傳參，無法保證類型安全，維護困難
直接使用runtime互相調用，難以明確地區分Required Interface和Provided Interface，因此其實無法實現完全解耦。和URL Router一樣，在目的模塊變化時，調用模塊也必須做出修改
過于依賴runtime特性，和Swift的類型安全設計是不兼容的，也無法跨平臺多端實現

UIStoryboardSegue

蘋果的storyboard其實也有一套路由API，只不過它的局限性很大。在這里簡單介紹一下：

@implementation SourceViewController- (void)showLoginViewController {//調用在storyboard中定義好的segue identifier [self performSegueWithIdentifier:@"presentLoginViewController" sender:nil]; } //perform segue時的回調 - (BOOL)shouldPerformSegueWithIdentifier:(NSString *)identifier sender:(nullable id)sender { return YES; } //配置目的界面 - (void)prepareForSegue:(UIStoryboardSegue *)segue sender:(id)sender { //用[segue destinationViewController]獲取目的界面，再對目的界面進行傳參 } @end

UIStoryboardSegue是和storyboard一起使用的，storyboard中定義好了一些界面跳轉的參數，比如轉場方式（push、present等），在執行路由前，執行路由的UIViewController會收到回調，讓調用者配置目的界面的參數。

在storyboard中連接segue，其實是跳轉到一個已經配置好界面的view controller，也就是和View相關的參數，都已經做好了依賴注入。但是自定義的依賴，卻還是需要在代碼中注入，所以又給了我們一個-prepareForSegue:sender:回調。

我不建議使用segue，因為它會導致強耦合。但是我們可以借鑒UIStoryboardSegue的sourceViewController、destinationViewController、封裝跳轉邏輯到segue子類、對頁面執行依賴注入等設計。

總結

總結了幾個路由工具之后，我的結論是：路由的選擇還是以業務需求為先。當對動態性要求極高、或者需要多平臺統一路由，則選擇URL Router，其他情況下，我更傾向于使用Protocol Router。和Peak大大的結論一致。

Protocol Router目前并沒有一個成熟的開源方案。因此我造了個輪子，增加了上面提到的一些需求。

ZIKRouter的特性

離散式管理

每個模塊都對應一個或者多個router子類，在子類中管理各自的路由過程，包括對象的生成、模塊的初始化、路由狀態管理、AOP等。路由時，需要使用對應的router子類，而不是一個單例router掌管所有的路由。如果想要避免引用子類帶來的耦合，可以用protocol動態獲取router子類，或者用父類+泛型在調用者中代替子類。

采用離散式的設計的原因是想讓各個模塊對路由擁有充分的控制權。

一個router子類的簡單實現如下：

@interface ZIKLoginViewRouter : ZIKViewRouter
@end @implementation ZIKLoginViewRouter //app啟動時，注冊對應的模塊和Router //不使用+load和+initialize方法，因為在Swift中已經不適用 + (void)registerRoutableDestination { [self registerView:[ZIKLoginViewController class]]; [self registerViewProtocol:ZIKRoutableProtocol(ZIKLoginViewProtocol)]; } //執行路由時，返回對應的viewController或者UIView - (id)destinationWithConfiguration:(ZIKViewRouteConfiguration *)configuration { UIStoryboard *sb = [UIStoryboard storyboardWithName:@"Main" bundle:nil]; ZIKLoginViewController *destination = [sb instantiateViewControllerWithIdentifier:@"ZIKLoginViewController"]; return destination; } //檢查來自storyboard的界面是否需要讓外界進行 + (BOOL)destinationPrepared:(UIViewController<ZIKLoginViewProtocol> *)destination { if (destination.loginService != nil) { return YES; } return NO; } //初始化工作 - (void)prepareDestination:(UIViewController<ZIKLoginViewProtocol> *)destination configuration:(__kindof ZIKViewRouteConfiguration *)configuration { if (destination.loginService == nil) { //ZIKLoginService也可以用ZIKServiceRouter動態獲取 destination.loginService = [ZIKLoginService new]; } } //路由時的AOP回調 + (void)router:(nullable ZIKViewRouter *)router willPerformRouteOnDestination:(id)destination fromSource:(id)source { } + (void)router:(nullable ZIKViewRouter *)router didPerformRouteOnDestination:(id)destination fromSource:(id)source { } + (void)router:(nullable ZIKViewRouter *)router willRemoveRouteOnDestination:(id)destination fromSource:(id)source { } + (void)router:(nullable ZIKViewRouter *)router didRemoveRouteOnDestination:(id)destination fromSource:(id)source { } @end

你甚至可以在不同情況下返回不同的destination，而調用者對此完全不知情。例如一個alertViewRouter為了兼容UIAlertView和UIAlertController，可以在router內部，iOS8以上使用UIAlertController，iOS8以下則使用UIAlertView。

一切路由的控制都在router類內部，不需要模塊做出任何額外的修改。

自由定義路由參數

路由的配置信息都存儲在configuration里，在調用者執行路由的時候傳入。基本的跳轉方法如下：

 //跳轉到Login界面[ZIKLoginViewRouterperformFromSource:self //界面跳轉時的源界面configuring:^(ZIKViewRouteConfiguration *config) {//跳轉類型，支持push、presentModally、presentAsPopover、performSegue、show、showDetail、addChild、addSubview、custom、getDestinationconfig.routeType = ZIKViewRouteTypePush; config.animated = NO; config.prepareDestination = ^(id<ZIKLoginViewProtocol> destination) { //跳轉前配置界面 }; config.routeCompletion = ^(id<NoteEditorProtocol> destination) { //跳轉成功并結束處理 }; config.performerErrorHandler = ^(ZIKRouteAction routeAction, NSError * error) { //跳轉失敗處理，有失敗的詳細信息 }; }];

Configuration只能在初始化block里配置，出了block以后就無法修改。你也可以用一個configuration子類添加更多自定義信息。

如果不需要復雜的配置，也可以只用最簡單的跳轉：

[ZIKLoginViewRouter performFromSource:self routeType:ZIKViewRouteTypePush];

移除已執行的路由

你可以先初始化一個router，再交給其他角色執行路由：

//初始化router
self.loginRouter = [[ZIKLoginViewRouter alloc] initWithConfiguring:^(ZIKViewRouteConfiguration * _Nonnull config) {config.source = self; config.routeType = ZIKViewRouteTypePush; }]; //執行路由 if ([self.loginRouter canPerform] == NO) { NSLog(@"此時無法執行路由:%@",self.loginRouter); return; } [self.loginRouter performRouteWithSuccessHandler:^{ NSLog(@"performer: push success"); } performerErrorHandler:^(ZIKRouteAction routeAction, NSError * _Nonnull error) { NSLog(@"performer: push failed: %@",error); }];

當你需要消除已經展示的界面，或者銷毀一個模塊時，可以調用移除路由方法一鍵移除：

if ([self.loginRouter canRemove] == NO) {NSLog(@"此時無法移除路由:%@", self.loginRouter); return; } [self.loginRouter removeRouteWithSuccessHandler:^{ NSLog(@"performer: pop success"); } performerErrorHandler:^(ZIKRouteAction routeAction, NSError * _Nonnull error) { NSLog(@"performer: pop failed,error:%@",error); }];

從而無需再區分調用pop、dismiss、removeFromParentViewController、removeFromSuperview等方法。

通過protocol獲取對應模塊

Protocol作為匹配標識

我們不想讓外部引用ZIKLoginViewRouter頭文件導致耦合，調用者只需要獲取一個符合了ZIKLoginViewProtocol的view controller，因此只需要根據ZIKLoginViewProtocol獲取到對應的router子類，然后在子類上調用父類ZIKViewRouter提供的路由方法即可，這樣就可以做到隱藏子類。

使用ZIKViewRouterToView和ZIKViewRouterToModule宏，即可通過protocol獲取到對應的router子類，并且子類返回的destination必定符合ZIKLoginViewProtocol：

[ZIKViewRouterToView(ZIKLoginViewProtocol)performFromSource:selfconfiguring:^(ZIKViewRouteConfiguration *config) {config.routeType = ZIKViewRouteTypePush;config.prepareDestination = ^(id<ZIKLoginViewProtocol> destination) {//跳轉前配置界面 }; config.routeCompletion = ^(id<ZIKLoginViewProtocol> destination) { //跳轉成功并結束處理 }; }];

這時候ZIKLoginViewProtocol就相當于LoginView模塊的唯一identifier，不能再用到其他view controller上。你可以用多個protocol注冊同一個router，用于區分requiredProtocol和providedProtocol。

多對一匹配

有時候，一些第三方的模塊或者系統模塊并沒有提供自己的router，你可以為其封裝一個router，此時可以有多個不同的router管理同一個UIViewController或者UIView類。這些router可能提供了不同的功能，比如同樣是alertRouter，routerA可能是用于封裝UIAlertController，routerB可能是用于兼容UIAlertView和UIAlertController，這時候要如何區分并獲取兩個不同的router？

像這種提供了獨特功能的router，需要你使用configuration的子類，然后讓子類conform對應功能的protocol。于是就可以根據configuration的protocol來獲取對應的router：

[ZIKViewRouterToModule(ZIKCompatibleAlertConfigProtocol)performFromSource:selfconfiguring:^(ZIKViewRouteConfiguration<ZIKCompatibleAlertConfigProtocol> * _Nonnull config) {config.routeType = ZIKViewRouteTypeCustom;config.title = @"Compatible Alert";config.message = @"Test custom route for alert with UIAlertView and UIAlertController"; [config addCancelButtonTitle:@"Cancel" handler:^{ NSLog(@"Tap cancel alert"); }]; [config addOtherButtonTitle:@"Hello" handler:^{ NSLog(@"Tap hello button"); }]; config.routeCompletion = ^(id _Nonnull destination) { NSLog(@"show custom alert complete"); }; }];

如果模塊自己提供了router，并且這個router用于依賴注入，不能被其他router替代，可以聲明本router為本模塊的唯一指定router，當有多個router嘗試管理此模塊時，啟動時就會產生斷言錯誤。

依賴注入和依賴聲明

固定依賴和運行時依賴

模塊的依賴分為固定依賴和運行時參數依賴。

固定依賴就類似于VIPER各角色之間的依賴關系，是一個模塊中固定不變的依賴。這種依賴只需要在router內部的-prepareDestination:configuration:固定配置即可。

運行時依賴就是外部傳入的參數，由configuration負責傳遞，然后同樣是在-prepareDestination:configuration:中，獲取configuration并配置destination。你可以用一個configuration子類和router配對，這樣就能添加更多自定義信息。

如果依賴參數很簡單，也可以讓router直接對destination進行配置，聲明router的destination遵守ZIKLoginViewProtocol，讓調用者在prepareDestination里設置destination。但是如果依賴涉及到了model對象的傳遞，并且由于需要隔離View和Model，destination不能接觸到這些model對象，這時候還是需要讓configuration傳遞依賴，在router內部再把model傳給負責管理model的角色。

因此，configuration和destination的protocol就負責依賴聲明和暴露接口。調用者只需要傳入protocol里要求的參數或者調用一些初始化方法即可，至于router內部怎么使用和配置這些依賴，調用者就不用關心了。

直接在頭文件中聲明

聲明一個protocol是一個router的config protocol或者view protocol時，只需要讓這個protocol繼承自ZIKViewConfigRoutable或者ZIKViewRoutable即可。這樣，所有的依賴聲明都可以在頭文件里明確表示，不必再從文檔中查找。

使用泛型指明特定router

一個模塊可以直接在內部用ZIKViewRouterToModule和ZIKViewRouterToView動態獲取router，也可以在頭文件里添加一個router屬性，讓builder注入。

那么一個模塊怎么向builder聲明自己需要某個特定功能的router呢？答案是父類+泛型。

ZIKRouter支持用泛型指定參數類型。在OC中可以這樣使用：

//注意這個示例代碼只是用于演示泛型的意思，實際運行時必須要用一個ZIKViewRouter子類才可以
[ZIKViewRouter<UIViewController> *>performFromSource:selfconfiguring:^(ZIKViewRouteConfiguration<ZIKLoginConfigProtocol> *config) {config.routeType = ZIKViewRouteTypePerformSegue;config.configureSegue(^(ZIKViewRouteSegueConfiguration *segueConfig) { segueConfig.identifier = @"showLoginViewController"; ); }];

ZIKViewRouter<UIViewController> *>就是一個指定了泛型的類，尖括號中指定了router的destination和configuration類型。這一串說明相當于是在聲明：這是一個destination為UIViewController類型，用ZIKViewRouteConfiguration<ZIKLoginConfigProtocol> *作為執行路由時的configuration的router類。你可以對configuration再添加protocol，表明這個configuration必須遵守指定的protocol。

這時你就可以用父類+泛型來聲明一個router類，這個router類的configuration符合特定的config protocol。而且在寫的時候Xcode會給你自動補全。這是一種很好的隱藏子類的方式，而且符合原生的語法。

但是由于OC中的類都是Class類型，因此只能這樣聲明一個實例屬性：

@property (nonatomic, strong) ZIKViewRouter<UIViewController> *> *loginViewRouter;

Builder只能注入一個router實例，而不是一個router class。因此在OC里一般不這么使用。

但是在Swift這種類型安全語言中這種模式就能更好地發揮作用了，你可以直接注入一個符合某個泛型的router：

//在Builder中注入alertRouter
swiftSampleViewController.alertRouter = Router.to(RoutableViewModule<ZIKCompatibleAlertConfigProtocol>())

class SwiftSampleViewController: UIViewController {    //在Builder里注入alertRouterClass后，就可以直接用這個routerClass執行路由var alertRouter: ViewRouter<Any>! @IBAction func testInjectedRouter(_ sender: Any) { self.alertRouter.perform( from: self, configuring: { (config, prepareDestination, prepareModule) in prepareModule({ moduleConfig in //moduleConfig在類型推斷時就是ZIKCompatibleAlertConfigProtocol，無需在判斷后再強制轉換 moduleConfig.title = "Compatible Alert" moduleConfig.message = "Test custom route for alert with UIAlertView and UIAlertController" moduleConfig.addCancelButtonTitle("Cancel", handler: { print("Tap cancel alert") }) moduleConfig.addOtherButtonTitle("Hello", handler: { print("Tap Hello alert") }) }) } } }

聲明了ViewRouter<Any>的屬性后，外部就可以直接注入一個對應的router。可以用這種設計模式來轉移、集中獲取router的職責。

Router可以在定義的時候限制自己的泛型：

Objective-C:

@interface ZIKCompatibleAlertViewRouter : ZIKViewRouter<UIViewController> *> @end

Swift:

class ZIKCompatibleAlertViewRouter: ZIKViewRouter<UIViewController> { }

這樣在傳遞的時候，就可以讓編譯器檢查router是否正確。

調用安全和類型安全

上面的演示已經展示了類型安全的處理，由protocol和泛型共同完成了這個類型安全的設計。不過有一些問題還需要特別注意。

編譯檢查

使用ZIKViewRouterToModule和ZIKViewRouterToView時，會對傳入的protocol進行編譯檢查。保證傳入的protocol是可路由的protocol，不能隨意濫用。具體用到的方式有些復雜，而且在Objective-C和Swift上使用了兩種方式來實現編譯檢查，具體實現可以看源代碼。

泛型的協變和逆變

Swift的自定義泛型不支持協變，所以使用起來有點奇怪。

let alertRouterClass: ZIKViewRouter<UIViewController>.Type//編譯錯誤//ZIKCompatibleAlertViewRouter.Type is ZIKViewRouter<UIViewController>.TypealertRouterClass = ZIKCompatibleAlertViewRouter.self

Swift的自定義泛型不支持子類型轉為父類型，因此把ZIKViewRouter<UIViewController>.Type賦值給ZIKViewRouter<UIViewController>.Type類型時就會出現編譯錯誤。奇怪的是反過來逆變反而沒有編譯錯誤。而Swift原生的集合類型是支持協變的。從2015年開始就有人提議Swift對自定義泛型加入協變，到現在也沒支持。在Objective-C里自定義泛型是可以正常協變的。

因此在swift里，使用了另一個類來包裹真正的router，而這個類是可以隨意指定泛型的。

用Adapter兼容接口

可以用不同的protocol獲取到相同的router。也就是requiredProtocol和providedProtocol只要有聲明，都可以獲取到同一個router。

首先檢查requiredProtocol和providedProtocol，確定兩個接口提供的功能是一致的。否則無法兼容。

為`Provided`模塊添加`Required Interface`

requiredProtocol是外部的要求目的模塊額外兼容的，由App Context在ZIKViewAdapter的子類里進行接口兼容。

@protocol ModuleARequiredLoginViewInput <ZIKViewRoutable>
@property (nonatomic, copy) NSString *message; @end //Module A中的調用代碼 UIViewController<ModuleARequiredLoginViewInput> *loginViewController = [ProtocolRouter destinationForProtocol:@protocol(LoginViewInput)]; loginViewController.message = @"請登錄查看筆記詳情";

//Login Module Provided Interface
@protocol ProvidedLoginViewInput <NSObject> @property (nonatomic, copy) NSString *notifyString; @end

//ZIKEditorAdapter.h，ZIKViewAdapter子類
@interface ZIKEditorAdapter : ZIKViewRouteAdapter @end

//ZIKEditorAdapter.m
//用Objective-C的category、Swift的extension進行接口適配
@interface LoginViewController (ModuleAAdapte) <ModuleARequiredLoginViewInput> @property (nonatomic, copy) NSString *message; @end @implementation LoginViewController (ModuleAAdapte) - (void)setMessage:(NSString *)message { self.notifyString = message; } - (NSString *)message { return self.notifyString; } @end @implementation ZIKEditorAdapter + (void)registerRoutableDestination { //注冊NoteListRequiredNoteEditorProtocol和ZIKEditorViewRouter匹配 [ZIKEditorViewRouter registerViewProtocol:ZIKRoutableProtocol(NoteListRequiredNoteEditorProtocol)]; } @end

用中介者轉發接口

如果遇到protocol里的一些delegate需要兼容：

@protocol ModuleARequiredLoginViewDelegate <NSObject>
- (void)didFinishLogin; @end @protocol ModuleARequiredLoginViewInput <ZIKViewRoutable> @property (nonatomic, copy) NSString *message; @property (nonatomic, weak) id<ModuleARequiredLoginViewDelegate> delegate; @end

@protocol LoginViewDelegate <NSObject>
- (void)didLogin; @end @protocol ProvidedLoginViewInput <NSObject> @property (nonatomic, copy) NSString *notifyString; @property (nonatomic, weak) id<LoginViewDelegate> delegate; @end

這種情況在OC里可以hook-setDelegate:方法，用NSProxy來進行消息轉發，把LoginViewDelegate的消息轉發為對應的ModuleARequiredLoginViewDelegate中的消息。

不過Swift里就不適合這么干了，相同方法有不同參數類型時，可以用一個新的router代替真正的router，在新的router里插入一個中介者，負責轉發接口：

@implementation ZIKEditorMediatorViewRouter
+ (void)registerRoutableDestination {//注冊NoteListRequiredNoteEditorProtocol，和新的ZIKEditorMediatorViewRouter配對，而不是目的模塊中的ZIKEditorViewRouter //新的ZIKEditorMediatorViewRouter負責調用ZIKEditorViewRouter，插入一個中介者 [self registerView:/* mediator的類*/]; [self registerViewProtocol:ZIKRoutableProtocol(NoteListRequiredNoteEditorProtocol)]; } - (id)destinationWithConfiguration:(ZIKViewRouteConfiguration *)configuration { //用ZIKEditorViewRouter獲取真正的destination id<ProvidedLoginViewInput> realDestination = [ZIKEditorViewRouter makeDestination]; //獲取一個負責轉發ProvidedLoginViewInput和ModuleARequiredLoginViewInput的mediator id<ModuleARequiredLoginViewInput> mediator = MediatorForDestination(realDestination); return mediator; } @end

一般來說，并不需要立即把所有的protocol都分離為requiredProtocol和providedProtocol。調用模塊和目的模塊可以暫時共用protocol，或者只是簡單地改個名字，在第一次需要替換模塊的時候再對protocol進行分離。

封裝UIKit跳轉和移除方法

封裝iOS的路由方法

ZIKViewRouter把UIKit中路由相關的方法：

-pushViewController:animated:
-presentViewController:animated:completion:
UIPopoverController的-presentPopoverFromRect:inView:permittedArrowDirections:animated:
UIPopoverPresentationController的配置
-performSegueWithIdentifier:sender:
-showViewController:sender:
-showDetailViewController:sender:
-addChildViewController:
-addSubview:

全都統一封裝，可以用枚舉一鍵切換：

[ZIKViewRouterToView(ZIKLoginViewProtocol)performFromSource:self routeType::ZIKViewRouteTypePush];

對應的枚舉值：

ZIKViewRouteTypePush
ZIKViewRouteTypePresentModally
ZIKViewRouteTypePresentAsPopover
ZIKViewRouteTypePerformSegue
ZIKViewRouteTypeShow
ZIKViewRouteTypeShowDetail
ZIKViewRouteTypeAddAsChildViewController
ZIKViewRouteTypeAddAsSubview
ZIKViewRouteTypeCustom
ZIKViewRouteTypeGetDestination

移除路由時，也不必再判斷不同情況分別調用-popViewControllerAnimated:、-dismissViewControllerAnimated:completion:、-dismissPopoverAnimated:、-removeFromParentViewController、-removeFromSuperview等方法。

ZIKViewRouter會在內部自動調用對應的方法。

識別`adaptative`類型的路由

-performSegueWithIdentifier:sender:、-showViewController:sender:、-showDetailViewController:sender:這些adaptative的路由方法，系統會根據不同的情況適配UINavigationController和UISplitViewController，選擇調用push、present或者其他方式。直接調用時無法明確知道最終調用的是哪個方法，也就無法移除界面。

ZIKViewRouter可以識別這些路由方法在調用后真正執行的路由操作，所以你現在也可以在使用這些方法后移除界面。

支持自定義路由

ZIKViewRouter也支持在子類中提供自定義的路由和移除路由方法。只要寫好對應的協議即可。

關于extension里的跳轉方法

App extension里還有一些特有的跳轉方法，比如Watch擴展里WKInterfaceController的-pushControllerWithName:context:和-popController，Share擴展里SLComposeServiceViewController的-pushConfigurationViewController:和-popConfigurationViewController。

看了一下extension的種類有十幾個，懶得一個個去適配了。而且extension里的界面不會特別復雜，不是特別需要路由工具。如果你需要適配extension，可以自己增加，也可以用ZIKViewRouteTypeCustom來適配。

支持storyboard

ZIKViewRouter支持storyboard，這也是和其他Router相比更強的地方。畢竟storyboard有時候也是很好用的，當使用了storyboard的項目中途使用router的時候，總不能為了適配router，把所有使用storyboard的界面都重構吧？

適配storyboard的原理是hook了所有UIViewController的-prepareForSegue:sender:方法，檢查destinationViewController是否遵守ZIKRoutableView協議，如果遵守，就說明是一個由router管理的界面，獲取注冊的對應router類，生成router實例，對其進行依賴注入。如果destination需要傳入動態參數，就會調用sourceViewController的-prepareDestinationFromExternal:configuration:方法，讓sourceViewController傳參。如果有多個router類注冊了同一個view controller，則取隨機的一個router。

你不需要對現有的模塊做任何修改，就可以直接兼容。而且原來view controller中的-prepareForSegue:sender:也能照常使用。

AOP

ZIKViewRouter會在一個界面執行路由和移除路由的時候，對所有注冊了此界面的router回調4個方法：

+ (void)router:(nullable ZIKViewRouter *)router willPerformRouteOnDestination:(id)destination fromSource:(id)source { } + (void)router:(nullable ZIKViewRouter *)router didPerformRouteOnDestination:(id)destination fromSource:(id)source { } + (void)router:(nullable ZIKViewRouter *)router willRemoveRouteOnDestination:(id)destination fromSource:(id)source { } + (void)router:(nullable ZIKViewRouter *)router didRemoveRouteOnDestination:(id)destination fromSource:(id)source { }

你可以在這些方法中檢查界面是否配置正確。也可以用于AOP記錄。

例如，你可以為UIViewController這個所有view controller的父類注冊一個router，這樣就可以監控所有的UIViewController子類的路由事件。

路由錯誤檢查

ZIKRouter會在啟動時進行所有router的注冊，這樣就能檢測出router是否有沖突、protocol是否和router正確匹配，保證所有router都能正確工作。當檢測到錯誤時，斷言將會失敗。

ZIKViewRouter在執行界面路由時，會檢測并報告路由時的錯誤。例如：

使用了錯誤的protocol執行路由
執行路由時configuration配置錯誤
不支持的路由方式（router可以限制界面只能使用push、present等有限的跳轉方式）
在其他界面的跳轉過程中，執行了另一個界面的跳轉（unbalanced transition錯誤，會導致-viewWillAppear:、-viewDidAppear:、-viewWillDisAppear:、-viewDidDisappear:等事件的順序發生錯亂）
Source view controller此時的狀態無法執行當前路由
路由時container view controller配置錯誤
segue在代理方法中被取消，導致路由未執行
重復執行路由

基本上包含了界面跳轉時會發生的大部分錯誤事件。