怎么在iOS中實現(xiàn)路由Router？很多新手對此不是很清楚，為了幫助大家解決這個難題，下面小編將為大家詳細講解，有這方面需求的人可以來學習下，希望你能有所收獲。
創(chuàng)新互聯(lián)建站專注于呼瑪企業(yè)網(wǎng)站建設,成都響應式網(wǎng)站建設公司,商城系統(tǒng)網(wǎng)站開發(fā)。呼瑪網(wǎng)站建設公司,為呼瑪?shù)鹊貐^(qū)提供建站服務。全流程按需定制制作，專業(yè)設計，全程項目跟蹤，創(chuàng)新互聯(lián)建站專業(yè)和態(tài)度為您提供的服務
什么是移動端路由層：
路由層的概念在服務端是指url請求的分層解析，將一個請求分發(fā)到對應的應用處理程序。移動端的路由層指的是將諸如App內(nèi)頁面訪問、H5與App訪問的訪問請求和App間的訪問請求，進行分發(fā)處理的邏輯層。
移動端路由層需要解決的問題：
1.對外部提供遠程訪問的功能，實現(xiàn)跨應用調(diào)用響應，包括H5應用調(diào)用、其他App應用調(diào)用、系統(tǒng)訪問調(diào)用等
2.原生頁面、模塊、組件等定義，統(tǒng)稱為資源(Resource)，在跨應用調(diào)用和路由層在不同端實現(xiàn)的業(yè)務表現(xiàn)需要一致的前提下，需要對資源進行定義，在路由提供內(nèi)部請求分發(fā)的時候則可以提供不依賴對外進行資源定義的功能
3.外部調(diào)用如何使用統(tǒng)一標示(Uniform)進行表示資源
4.如何在移動端統(tǒng)一定義訪問請求的過程，從而達成移動端與web端的統(tǒng)一性
5.如何更好的兼容iOS、Android的系統(tǒng)訪問機制、App鏈接協(xié)議、web端路由機制與前端開發(fā)規(guī)范等
6.如何兼容各平臺(Android、iOS)App頁面導航機制
7.如何解決安全訪問問題
8.移動端在客戶端進行動態(tài)配置
移動端路由所應用的場景：
0.H5頁面與App原生頁面、模塊與組件的交互
1.App與App之間的相互訪問
2.App內(nèi)部頁面跳轉(zhuǎn)、模塊調(diào)度與組件加載等
3.推送與通知系統(tǒng)解除硬編碼的邏輯，動態(tài)訪問原生資源，更好的支持通過通知和推送完成動態(tài)頁面訪問和邏輯執(zhí)行
4.Extension等動態(tài)調(diào)用主App的資源
5.App實現(xiàn)更復雜的架構MVVM或者是VIPER架構，提供解除業(yè)務相互依賴的能力
6.以組件化為目的的工程改造，隔離各個業(yè)務，以制作單獨的組件
接口預覽
Router
NS_ASSUME_NONNULL_BEGIN @interface SJRouter : NSObject + (instancetype)shared; - (void)handleRequest:(SJRouteRequest *)request completionHandler:(SJCompletionHandler)completionHandler; @end NS_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; @end NS_ASSUME_NONNULL_END
RouteHandlerProtocol
NS_ASSUME_NONNULL_BEGIN typedef id SJParameters; @protocol SJRouteHandler + (NSString *)routePath; + (void)handleRequestWithParameters:(nullable SJParameters)parameters topViewController:(UIViewController *)topViewController completionHandler:(nullable SJCompletionHandler)completionHandler; @end NS_ASSUME_NONNULL_END
流程
簡單的講，app應用中，路由識別一個請求， 將它分派給對應的handler進行處理。 這個流程非常像發(fā)送一個網(wǎng)絡請求（拼接參數(shù)=>發(fā)起請求=>回調(diào)）。
同樣的，當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，傳遞必要參數(shù)：
@implementation SJRouter
- (void)handleRequest:(SJRouteRequest *)request completionHandler:(SJCompletionHandler)completionHandler {
NSParameterAssert(request); if ( !request ) return;
Class 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至此， 我們再回過頭看剛開始舉的那個例子：
視頻模塊的播放頁， 有與視頻相關的音樂，點擊這些音樂，需要跳轉(zhuǎn)到音樂模塊的播放頁。
此時，可以讓視頻模塊依賴Router， 進行跳轉(zhuǎn)請求。這看起來都是依賴，實則兩者差別很大了。
路由不止能處理跳轉(zhuǎn)音樂模塊的請求， 依賴也從多個變成只依賴Router即可。。。
在刪除某個依賴模塊時， 需要刪除依賴的代碼， 很煩的， 對吧。
吧啦吧啦吧啦吧啦吧啦。。。
所以點擊跳轉(zhuǎn)音樂模塊，可以替換成如下操作, 發(fā)起請求：
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
從開始到現(xiàn)在，可以看出Handler就是最終執(zhí)行請求的那個家伙。 相信大家都有疑問， 如何成為一個Handler？
很簡單，它是自動的(參見Router)， 只要某個類遵守了SJRouteHandlerProtocol， 它便成為了一個Handler。再來看一遍協(xié)議吧。
NS_ASSUME_NONNULL_BEGIN typedef id SJParameters; @protocol SJRouteHandler + (NSString *)routePath; + (void)handleRequestWithParameters:(nullable SJParameters)parameters topViewController:(UIViewController *)topViewController completionHandler:(nullable SJCompletionHandler)completionHandler; @end NS_ASSUME_NONNULL_END
routePath： 即路徑， 表示handler能夠處理的路徑。當發(fā)起請求時， Router會通過路徑獲取到對應的handler， 交給其進行處理。
handleRequestWithParameters。。。： handler進行的處理。
Router
在整個請求過程中，Router做的事情實質(zhì)上就是在眾多Handler中尋找命中注定的那一個。如何尋找呢？為什么遵守了SJRouteHandlerProtocol便自動成為了Handler呢？
這自然要歸功于Runtime的強大力量，我們先看如何實現(xiàn)吧。
@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)thisCls routePath]] = thisCls;
break;
}
}
if ( classes ) free(classes);
return self;
}
@end objc_getClassList： 很明顯了， 獲取App所有類。
class_conformsToProtocol： 該類是否遵守某個協(xié)議。
看完上述內(nèi)容是否對您有幫助呢？如果還想對相關知識有進一步的了解或閱讀更多相關文章，請關注創(chuàng)新互聯(lián)行業(yè)資訊頻道，感謝您對創(chuàng)新互聯(lián)的支持。
