iOS VIPER架構實踐(三)：面向介面的路由設計

路由是實現模組間解耦的一個有效工具。如果要進行元件化開發，路由是必不可少的一部分。目前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
  • 總結
• 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];
複製程式碼

對應的列舉值：

• 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在代理方法中被取消，導致路由未執行
• 重複執行路由

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

支援任意模組

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回撥：

參考

• iOS元件化方案
• iOS 元件化 —— 路由設計思路分析
• component-diagrams
• BeeHive
• CTMediator