平常開發(fā)中用戶點(diǎn)擊頭像， 進(jìn)入個(gè)人主頁(yè)，這看似平常的操作， 背后極有可能會(huì)牽扯到多個(gè)模塊。 再如： 視頻模塊的播放頁(yè)， 有與視頻相關(guān)的音樂，點(diǎn)擊這些音樂，需要跳轉(zhuǎn)到音樂模塊的播放頁(yè)， 這樣視頻與音樂模塊之間，不可避免的會(huì)產(chǎn)生依賴或耦合。 這個(gè)問題讓人腦殼疼，相信很多朋友都這樣做過，寫一些代理或通知， 不停的傳遞事件； 有時(shí)干脆直接導(dǎo)入另一個(gè)模塊。

因?yàn)槲以诠惊?dú)立開發(fā)， 顧及少一點(diǎn)，可以拿公司項(xiàng)目做實(shí)踐，在嘗試組件化的過程中， 了解到了路由， 對(duì)于解決上述問題， 有極大的幫助。因此我想總結(jié)并與大家分享一下。

什么是移動(dòng)端路由層：

路由層的概念在服務(wù)端是指url請(qǐng)求的分層解析，將一個(gè)請(qǐng)求分發(fā)到對(duì)應(yīng)的應(yīng)用處理程序。移動(dòng)端的路由層指的是將諸如App內(nèi)頁(yè)面訪問、H5與App訪問的訪問請(qǐng)求和App間的訪問請(qǐng)求，進(jìn)行分發(fā)處理的邏輯層。

移動(dòng)端路由層需要解決的問題：

1.對(duì)外部提供遠(yuǎn)程訪問的功能，實(shí)現(xiàn)跨應(yīng)用調(diào)用響應(yīng)，包括H5應(yīng)用調(diào)用、其他App應(yīng)用調(diào)用、系統(tǒng)訪問調(diào)用等
2.原生頁(yè)面、模塊、組件等定義，統(tǒng)稱為資源(Resource)，在跨應(yīng)用調(diào)用和路由層在不同端實(shí)現(xiàn)的業(yè)務(wù)表現(xiàn)需要一致的前提下，需要對(duì)資源進(jìn)行定義，在路由提供內(nèi)部請(qǐng)求分發(fā)的時(shí)候則可以提供不依賴對(duì)外進(jìn)行資源定義的功能
3.外部調(diào)用如何使用統(tǒng)一標(biāo)示(Uniform)進(jìn)行表示資源
4.如何在移動(dòng)端統(tǒng)一定義訪問請(qǐng)求的過程，從而達(dá)成移動(dòng)端與web端的統(tǒng)一性
5.如何更好的兼容iOS、Android的系統(tǒng)訪問機(jī)制、App鏈接協(xié)議、web端路由機(jī)制與前端開發(fā)規(guī)范等
6.如何兼容各平臺(tái)(Android、iOS)App頁(yè)面導(dǎo)航機(jī)制
7.如何解決安全訪問問題
8.移動(dòng)端在客戶端進(jìn)行動(dòng)態(tài)配置

移動(dòng)端路由所應(yīng)用的場(chǎng)景：

0.H5頁(yè)面與App原生頁(yè)面、模塊與組件的交互
1.App與App之間的相互訪問
2.App內(nèi)部頁(yè)面跳轉(zhuǎn)、模塊調(diào)度與組件加載等
3.推送與通知系統(tǒng)解除硬編碼的邏輯，動(dòng)態(tài)訪問原生資源，更好的支持通過通知和推送完成動(dòng)態(tài)頁(yè)面訪問和邏輯執(zhí)行
4.Extension等動(dòng)態(tài)調(diào)用主App的資源
5.App實(shí)現(xiàn)更復(fù)雜的架構(gòu)MVVM或者是VIPER架構(gòu)，提供解除業(yè)務(wù)相互依賴的能力
6.以組件化為目的的工程改造，隔離各個(gè)業(yè)務(wù)，以制作單獨(dú)的組件

接口預(yù)覽

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

流程

簡(jiǎn)單的講，app應(yīng)用中，路由識(shí)別一個(gè)請(qǐng)求， 將它分派給對(duì)應(yīng)的handler進(jìn)行處理。 這個(gè)流程非常像發(fā)送一個(gè)網(wǎng)絡(luò)請(qǐng)求（拼接參數(shù)=>發(fā)起請(qǐng)求=>回調(diào)）。

同樣的，當(dāng)Router收到下面的請(qǐng)求時(shí)(請(qǐng)求視頻播放頁(yè))：

- (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  }];}

會(huì)嘗試識(shí)別路由， 找到匹配的handler，傳遞必要參數(shù)：

@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進(jìn)行處理。

@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

至此， 我們?cè)倩剡^頭看剛開始舉的那個(gè)例子：

視頻模塊的播放頁(yè)， 有與視頻相關(guān)的音樂，點(diǎn)擊這些音樂，需要跳轉(zhuǎn)到音樂模塊的播放頁(yè)。

此時(shí)，可以讓視頻模塊依賴Router， 進(jìn)行跳轉(zhuǎn)請(qǐng)求。這看起來都是依賴，實(shí)則兩者差別很大了。

1. 路由不止能處理跳轉(zhuǎn)音樂模塊的請(qǐng)求， 依賴也從多個(gè)變成只依賴Router即可。。。
2. 在刪除某個(gè)依賴模塊時(shí)， 需要?jiǎng)h除依賴的代碼， 很煩的， 對(duì)吧。
3. 吧啦吧啦吧啦吧啦吧啦。。。

所以點(diǎn)擊跳轉(zhuǎn)音樂模塊，可以替換成如下操作, 發(fā)起請(qǐng)求：

  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找到對(duì)應(yīng)的handler， 讓其進(jìn)行處理。

Handler

從開始到現(xiàn)在，可以看出Handler就是最終執(zhí)行請(qǐng)求的那個(gè)家伙。 相信大家都有疑問， 如何成為一個(gè)Handler？

很簡(jiǎn)單，它是自動(dòng)的(參見Router)， 只要某個(gè)類遵守了SJRouteHandlerProtocol， 它便成為了一個(gè)Handler。再來看一遍協(xié)議吧。

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

1. routePath： 即路徑， 表示handler能夠處理的路徑。當(dāng)發(fā)起請(qǐng)求時(shí)， Router會(huì)通過路徑獲取到對(duì)應(yīng)的handler， 交給其進(jìn)行處理。
2. handleRequestWithParameters。。。： handler進(jìn)行的處理。

Router

在整個(gè)請(qǐng)求過程中，Router做的事情實(shí)質(zhì)上就是在眾多Handler中尋找命中注定的那一個(gè)。如何尋找呢？為什么遵守了SJRouteHandlerProtocol便自動(dòng)成為了Handler呢？ 

這自然要?dú)w功于Runtime的強(qiáng)大力量，我們先看如何實(shí)現(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<SJRouteHandler>)thisCls routePath]] = thisCls;      break;    }  }  if ( classes ) free(classes);  return self;}@end

1. objc_getClassList： 很明顯了， 獲取App所有類。
2. class_conformsToProtocol： 該類是否遵守某個(gè)協(xié)議。

得益于Runtime的這兩個(gè)函數(shù)，即可獲取到眾多的Handler。 當(dāng)發(fā)起請(qǐng)求時(shí)， 在眾多Handler中尋找注定的那一個(gè)， 豈不是易如反掌。

Request

App發(fā)起的跳轉(zhuǎn)請(qǐng)求，更多到是內(nèi)部頁(yè)面之間的跳轉(zhuǎn)， 我們最需要關(guān)注的就是它的路徑，所以整個(gè)路由都是圍繞著路徑去跳轉(zhuǎn)的， 而像URL中的scheme和host，體現(xiàn)出來的作用倒是不大。至少在我的項(xiàng)目中跳轉(zhuǎn)第三方App(例如分享)都是使用的友盟這類的SDK去處理的。

因此， Request持有每個(gè)請(qǐng)求的路徑， 以及必要的參數(shù)， 之后再無多余操作。 

好了， 就到這里了。

下面是項(xiàng)目地址， 有興趣到話可以與我一起交流哦。。。

https://github.com/changsanjiang/SJRouter

以上就是本文的全部?jī)?nèi)容，希望對(duì)大家的學(xué)習(xí)有所幫助，也希望大家多多支持VEVB武林網(wǎng)。