路由是實現模組間解耦的一個有效工具。如果要進行元件化開發，路由是必不可少的一部分。目前iOS上絕大部分的路由工具都是基於URL匹配的，優缺點都很明顯。這篇文章裡將會給出一個更加原生和安全的設計，這個設計的特點是：
- 路由時用protocol尋找模組
- 可以對模組進行固定的依賴注入和執行時依賴注入
- 支援不同模組間進行介面適配和轉發，因此無需和某個固定的protocol關聯
- 充分解耦的同時，增加型別安全
- 支援移除已執行的路由
- 封裝UIKit介面跳轉方法，可以一鍵跳轉和移除
- 支援storyboard，支援其他任意模組
- 可以檢測介面跳轉時的大部分錯誤
如果你想要一個能夠充分解耦、型別安全、有依賴注入功能的路由器，那這個就是目前所能找到的最佳方案。
這個路由工具是為了實踐VIPER模式而設計的，目的是為VIPER提供依賴注入功能，不過它也可以用於MVC、MVP、MVVM，沒有任何限制。
工具和Demo地址：ZIKRouter。
目錄
- Router的作用
- 路由缺失時的情況
- 尋找模組
- 宣告依賴和介面
- Builder和依賴注入
- 現有的Router
- URL Router
- 優點
- 極高的動態性
- 統一多端路由規則
- 適配URL scheme
- 缺點
- 不適合通用模組
- 安全性差
- 維護困難
- 優點
- Protocol Router
- 優點
- 安全性好，維護簡單
- 適用於所有模組
- 優雅地宣告依賴
- 缺點
- 動態性有限
- 需要額外適配URL Scheme
- Protocol是否會導致耦合？
- 業務設計的互相關聯
Required Interface和Provided Interface
- 優點
- Target-Action
- 優點
- 缺點
- UIStoryboardSegue
- 總結
- URL Router
- ZIKRouter的特性
- 離散式管理
- 自由定義路由引數
- 移除已執行的路由
- 通過protocol獲取對應模組
- Protocol作為匹配標識
- 多對一匹配
- 依賴注入和依賴宣告
- 固定依賴和執行時依賴
- 直接在標頭檔案中宣告
- 使用泛型指明特定router
- 型別安全
- 傳入正確的protocol
- 泛型的協變和逆變
- 用Adapter相容介面
- 為
Provided模組新增Required Interface - 用中介者轉發介面
- 為
- 封裝UIKit跳轉和移除方法
- 封裝iOS的路由方法
- 識別
adaptative型別的路由 - 支援自定義路由
- 關於extension裡的跳轉方法
- 支援storyboard
- AOP
- 路由錯誤檢查
- 支援任意模組
- 效能
- 專案地址和Demo
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介面
[ZIKLoginViewRouter
performFromSource:self //介面跳轉時的源介面
configuring:^(ZIKViewRouteConfiguration *config) {
//跳轉型別，支援push、presentModally、presentAsPopover、performSegue、show、showDetail、addChild、addSubview、custom、getDestination
config.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:self
configuring:^(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:self
configuring:^(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 *,ZIKViewRouteConfiguration<ZIKLoginConfigProtocol> *>
performFromSource:self
configuring:^(ZIKViewRouteConfiguration<ZIKLoginConfigProtocol> *config) {
config.routeType = ZIKViewRouteTypePerformSegue;
config.configureSegue(^(ZIKViewRouteSegueConfiguration *segueConfig) {
segueConfig.identifier = @"showLoginViewController";
);
}];
複製程式碼ZIKViewRouter<UIViewController *, ZIKViewRouteConfiguration<ZIKLoginConfigProtocol> *>就是一個指定了泛型的類，尖括號中指定了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 *,ZIKViewRouteConfiguration<ZIKLoginConfigProtocol> *> *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, ZIKCompatibleAlertConfigProtocol>!
@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, ZIKCompatibleAlertConfigProtocol>的屬性後，外部就可以直接注入一個對應的router。可以用這種設計模式來轉移、集中獲取router的職責。
Router可以在定義的時候限制自己的泛型：
Objective-C:
@interface ZIKCompatibleAlertViewRouter : ZIKViewRouter<UIViewController *, ZIKViewRouteConfiguration<ZIKCompatibleAlertConfigProtocol> *>
@end
複製程式碼Swift:
class ZIKCompatibleAlertViewRouter: ZIKViewRouter<UIViewController, ZIKViewRouteConfiguration & ZIKCompatibleAlertConfigProtocol> {
}
複製程式碼這樣在傳遞的時候，就可以讓編譯器檢查router是否正確。
呼叫安全和型別安全
上面的演示已經展示了型別安全的處理，由protocol和泛型共同完成了這個型別安全的設計。不過有一些問題還需要特別注意。
編譯檢查
使用ZIKViewRouterToModule和ZIKViewRouterToView時，會對傳入的protocol進行編譯檢查。保證傳入的protocol是可路由的protocol，不能隨意濫用。具體用到的方式有些複雜，而且在Objective-C和Swift上使用了兩種方式來實現編譯檢查，具體實現可以看原始碼。
泛型的協變和逆變
Swift的自定義泛型不支援協變，所以使用起來有點奇怪。
let alertRouterClass: ZIKViewRouter<UIViewController, ZIKViewRouteConfiguration>.Type
//編譯錯誤
//ZIKCompatibleAlertViewRouter.Type is ZIKViewRouter<UIViewController, ZIKViewRouteConfiguration & ZIKCompatibleAlertConfigProtocol>.Type
alertRouterClass = ZIKCompatibleAlertViewRouter.self
複製程式碼Swift的自定義泛型不支援子型別轉為父型別，因此把ZIKViewRouter<UIViewController, ZIKViewRouteConfiguration & ZIKCompatibleAlertConfigProtocol>.Type賦值給ZIKViewRouter<UIViewController, ZIKViewRouteConfiguration>.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 = [ZIKViewRouterToView(LoginViewInput) makeDestination];
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];
複製程式碼對應的列舉值：
ZIKViewRouteTypePushZIKViewRouteTypePresentModallyZIKViewRouteTypePresentAsPopoverZIKViewRouteTypePerformSegueZIKViewRouteTypeShowZIKViewRouteTypeShowDetailZIKViewRouteTypeAddAsChildViewControllerZIKViewRouteTypeAddAsSubviewZIKViewRouteTypeCustomZIKViewRouteTypeGetDestination
移除路由時，也不必再判斷不同情況分別呼叫-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在代理方法中被取消，導致路由未執行
- 重複執行路由
基本上包含了介面跳轉時會發生的大部分錯誤事件。
支援任意模組
ZIKRouter包含ZIKViewRouter和ZIKServiceRouter。ZIKViewRouter專門用於介面跳轉，ZIKServiceRouter則可以新增任意類進行例項獲取。
你可以用ZIKServiceRouter管理需要的類，並且ZIKServiceRouter增添了和ZIKViewRouter相同的動態性和泛型支援。
效能
為了錯誤檢查、支援storyboard和註冊，ZIKViewRouter和ZIKServiceRouter會在app啟動時遍歷所有類，進行hook和註冊的工作。註冊時只是把view class、protocol和router class的地址加入字典，不會對記憶體有影響。
在release模式下，iPhone6s機型上，測試了5000個UIViewController以及5000個對應的router，遍歷所有類並且hook的耗時大約為15ms，註冊router的耗時大約為50ms。基本上不會遇到效能問題。
如果你不需要支援storyboard，可以去掉view class和router class配對的註冊，去掉以後就無法自動為storyboard裡的view controller建立router。至於protocol和router的註冊，目前似乎是無法避免的。
專案地址和Demo
簡單來說，ZIKRouter就是一個用於模組間路由，基於介面進行模組發現和依賴注入的Router。它以原生的語法執行路由，在OC和Swift中都能使用。
專案地址在：ZIKRouter。裡面包含了一個demo，用於演示iOS中大部分的介面路由場景，建議在橫屏iPad上執行。
最後記得點個star~
Demo截圖，控制檯的輸出就是介面路由時的AOP回撥：
