平常開發中用戶點擊頭像， 進入個人主頁，這看似平常的操作， 背后極有可能會牽扯到多個模塊。 再如： 視頻模塊的播放頁， 有與視頻相關的音樂，點擊這些音樂，需要跳轉到音樂模塊的播放頁， 這樣視頻與音樂模塊之間，不可避免的會產生依賴或耦合。 這個問題讓人腦殼疼，相信很多朋友都這樣做過，寫一些代理或通知， 不停的傳遞事件； 有時干脆直接導入另一個模塊。
因為我在公司獨立開發， 顧及少一點，可以拿公司項目做實踐，在嘗試組件化的過程中， 了解到了路由， 對于解決上述問題， 有極大的幫助。因此我想總結并與大家分享一下。
什么是移動端路由層：
路由層的概念在服務端是指url請求的分層解析，將一個請求分發到對應的應用處理程序。移動端的路由層指的是將諸如App內頁面訪問、H5與App訪問的訪問請求和App間的訪問請求，進行分發處理的邏輯層。
移動端路由層需要解決的問題：
1.對外部提供遠程訪問的功能，實現跨應用調用響應，包括H5應用調用、其他App應用調用、系統訪問調用等
2.原生頁面、模塊、組件等定義，統稱為資源(Resource)，在跨應用調用和路由層在不同端實現的業務表現需要一致的前提下，需要對資源進行定義，在路由提供內部請求分發的時候則可以提供不依賴對外進行資源定義的功能
3.外部調用如何使用統一標示(Uniform)進行表示資源
4.如何在移動端統一定義訪問請求的過程，從而達成移動端與web端的統一性
5.如何更好的兼容iOS、Android的系統訪問機制、App鏈接協議、web端路由機制與前端開發規范等
6.如何兼容各平臺(Android、iOS)App頁面導航機制
7.如何解決安全訪問問題
8.移動端在客戶端進行動態配置
移動端路由所應用的場景：
0.H5頁面與App原生頁面、模塊與組件的交互
1.App與App之間的相互訪問
2.App內部頁面跳轉、模塊調度與組件加載等
3.推送與通知系統解除硬編碼的邏輯，動態訪問原生資源，更好的支持通過通知和推送完成動態頁面訪問和邏輯執行
4.Extension等動態調用主App的資源
5.App實現更復雜的架構MVVM或者是VIPER架構，提供解除業務相互依賴的能力
6.以組件化為目的的工程改造，隔離各個業務，以制作單獨的組件
接口預覽
Router
NS_ASSUME_NONNULL_BEGIN@interface SJRouter : NSObject+ (instancetype)shared;- (void)handleRequest:(SJRouteRequest *)request completionHandler:(SJCompletionHandler)completionHandler;@endNS_ASSUME_NONNULL_END
RouteRequest
NS_ASSUME_NONNULL_BEGIN@interface SJRouteRequest : NSObject- (instancetype)initWithURL:(NSURL *)URL;- (instancetype)initWithPath:(NSString *)requestPath parameters:(nullable SJParameters)parameters;@property (nonatomic, strong, readonly) NSString *requestPath;@property (nonatomic, strong, readonly, nullable) SJParameters prts;- (instancetype)init NS_UNAVAILABLE;+ (instancetype)new NS_UNAVAILABLE;@endNS_ASSUME_NONNULL_END
RouteHandlerProtocol
NS_ASSUME_NONNULL_BEGINtypedef id SJParameters;@protocol SJRouteHandler+ (NSString *)routePath;+ (void)handleRequestWithParameters:(nullable SJParameters)parameters topViewController:(UIViewController *)topViewController completionHandler:(nullable SJCompletionHandler)completionHandler;@endNS_ASSUME_NONNULL_END
流程
簡單的講，app應用中，路由識別一個請求， 將它分派給對應的handler進行處理。 這個流程非常像發送一個網絡請求（拼接參數=>發起請求=>回調）。
同樣的，當Router收到下面的請求時(請求視頻播放頁)：
- (void)push:(id)sender { SJRouteRequest *request = [[SJRouteRequest alloc] initWithPath:@"video/playbackInfo" parameters:@{@"video_id":@(111)}]; [SJRouter.shared handleRequest:request completionHandler:^(id _Nullable result, NSError * _Nullable error) {#ifdef DEBUG NSLog(@"%d - %s", (int)__LINE__, __func__);#endif }];}會嘗試識別路由， 找到匹配的handler，傳遞必要參數：
@implementation SJRouter- (void)handleRequest:(SJRouteRequest *)request completionHandler:(SJCompletionHandler)completionHandler { NSParameterAssert(request); if ( !request ) return; Class<SJRouteHandler> handler = _handlersM[request.requestPath]; if ( handler ) { [handler handleRequestWithParameters:request.requestPath topViewController:_sj_get_top_view_controller() completionHandler:completionHandler]; } else { printf("/n (-_-) Unhandled request: %s", request.description.UTF8String); }}@end最后handler進行處理。
@implementation TestViewController+ (NSString *)routePath { return @"video/playbackInfo";}+ (void)handleRequestWithParameters:(nullable SJParameters)parameters topViewController:(UIViewController *)topViewController completionHandler:(nullable SJCompletionHandler)completionHandler { TestViewController *vc = [TestViewController new]; vc.completionHandler = completionHandler; [topViewController.navigationController pushViewController:vc animated:YES];}@end至此， 我們再回過頭看剛開始舉的那個例子：
視頻模塊的播放頁， 有與視頻相關的音樂，點擊這些音樂，需要跳轉到音樂模塊的播放頁。
此時，可以讓視頻模塊依賴Router， 進行跳轉請求。這看起來都是依賴，實則兩者差別很大了。
所以點擊跳轉音樂模塊，可以替換成如下操作, 發起請求：
SJRouteRequest *request = [[SJRouteRequest alloc] initWithPath:@"audio/playbackInfo" parameters:@{@"audio_id":@(232)}]; [SJRouter.shared handleRequest:request completionHandler:^(id _Nullable result, NSError * _Nullable error) {#ifdef DEBUG NSLog(@"%d - %s", (int)__LINE__, __func__);#endif }];router找到對應的handler， 讓其進行處理。
Handler
從開始到現在，可以看出Handler就是最終執行請求的那個家伙。 相信大家都有疑問， 如何成為一個Handler？
很簡單，它是自動的(參見Router)， 只要某個類遵守了SJRouteHandlerProtocol， 它便成為了一個Handler。再來看一遍協議吧。
NS_ASSUME_NONNULL_BEGINtypedef id SJParameters;@protocol SJRouteHandler+ (NSString *)routePath;+ (void)handleRequestWithParameters:(nullable SJParameters)parameters topViewController:(UIViewController *)topViewController completionHandler:(nullable SJCompletionHandler)completionHandler;@endNS_ASSUME_NONNULL_END
Router
在整個請求過程中，Router做的事情實質上就是在眾多Handler中尋找命中注定的那一個。如何尋找呢？為什么遵守了SJRouteHandlerProtocol便自動成為了Handler呢？
這自然要歸功于Runtime的強大力量，我們先看如何實現吧。
@implementation SJRouter - (instancetype)init { self = [super init]; if ( !self ) return nil; _handlersM = [NSMutableDictionary new]; int count = objc_getClassList(NULL, 0); Class *classes = (Class *)malloc(sizeof(Class) * count); objc_getClassList(classes, count); Protocol *p_handler = @protocol(SJRouteHandler); for ( int i = 0 ; i < count ; ++ i ) { Class cls = classes[i]; for ( Class thisCls = cls ; nil != thisCls ; thisCls = class_getSuperclass(thisCls) ) { if ( !class_conformsToProtocol(thisCls, p_handler) ) continue; if ( ![(id)thisCls respondsToSelector:@selector(routePath)] ) continue; if ( ![(id)thisCls respondsToSelector:@selector(handleRequestWithParameters:topViewController:completionHandler:)] ) continue; _handlersM[[(id<SJRouteHandler>)thisCls routePath]] = thisCls; break; } } if ( classes ) free(classes); return self;}@end得益于Runtime的這兩個函數，即可獲取到眾多的Handler。 當發起請求時， 在眾多Handler中尋找注定的那一個， 豈不是易如反掌。
Request
App發起的跳轉請求，更多到是內部頁面之間的跳轉， 我們最需要關注的就是它的路徑，所以整個路由都是圍繞著路徑去跳轉的， 而像URL中的scheme和host，體現出來的作用倒是不大。至少在我的項目中跳轉第三方App(例如分享)都是使用的友盟這類的SDK去處理的。
因此， Request持有每個請求的路徑， 以及必要的參數， 之后再無多余操作。
好了， 就到這里了。
下面是項目地址， 有興趣到話可以與我一起交流哦。。。
https://github.com/changsanjiang/SJRouter
以上就是本文的全部內容，希望對大家的學習有所幫助，也希望大家多多支持VEVB武林網。
新聞熱點
疑難解答
