前端的路由
网络中路由概念是指路由器从一个接口上接收到数据包，根据数据包的目的地址进行定向转发到另一个接口的过程。直白一点就是，路由是一种数据的收集和分发过程。在前端开发中，路由的作用主要是保证视图和 URL 的信息同步，用户可以通过手动输入或者与页面进行交互来改变 URL，然后程序向服务端发送请求获取资源，接着重新绘制 UI。iOS 移动端可以借用前端的思路，遵循约定的路由协议，通过某种手段映射到具体的视图组件/控制器/功能等资源。
URI
统一资源标识符（Uniform Resource Identifier）是一种用于标识互联网资源的字符串，此种标识允许用于对网络中的资源通过特定的协议进行交互操作。URI 最常见的形式就是统一资源定位符 URL。
URL
这是一段URL，每一段都代表类对应的含义，我们可以理解 URL 为一段携带了获取到某资源的所有必须的信息的特定组合字符串。
iOS 系统里面支持的 URL Scheme 方式打开应用。我们可以通过 TARGETS -> Info -> URL Types 添加应用的 Scheme，该 Scheme 可以理解为 App 的一个身份标识，用它可以打开我们的应用（在三方分享时经常需要我们去平台生成自己的 Scheme，三方平台用此字段跳转本体App）。
URL Types 添加
这样，我们运行App之后，通过 Safai 就可以跳转到我们的App。输入 myroute:// 跳转。
移动端的路由作用
移动端的路由概念有着很多的用处，重要的一点就是让页面和组件之间的解耦，形成一种低耦合，高类聚的特性。
- 消息推送/3D-Touch
我们在处理上述两个功能的跳转时候，通常会使用到路由协议，通过解析 -application:openURL:options: 中的 url得到具体的页面跳转。
- 自家App之间跳转如何携带数据
通过约定的路由协议，我们可以通过 -openURL: 的方式，将数据信息携带到其他应用中，在开发过程中，类似的功能有：三方分享、三方支付等等，虽然通过三方的平台框架，但是本质上都是一致的。
- App功能组件和App页面的解耦
未采用路由的情况下，我们从页面A跳转到页面B时，我们通常将在A中引入B，在跳转的事件中创建B类的实例进行跳转，这样做是没有任何错误，只是这样的写法让A对B产生了依赖，并且此处跳转的逻辑被写死，一旦B出现错误，如果线上的App未集成热修复的功能，那么后端无法通过紧急降级处理，将A引导到其他的地方。
- 统一三方的处理逻辑
web 前端、iOS 和 Android 采用相同的路由协议，我们可以统一控制三方的展现形式。
- 引流向
在应用推广的过程中，我们可以将路由数据嵌入到web页面中，如链接或者二维码，通过路由中的 scheme 字段，我们将用户引流到应用中去。
App间的跳转
我们先通过App之前的跳转来初步认识一下路由。
1. URL Scheme
iOS 系统是支持 URL Scheme 的，在上一小节，我们有过演示，你也可以通过 info.plist 文件中的 URL types 字段管理你的 URL Scheme 信息。即使你没有用过 URL Scheme，那么你一定使用过一些系统的服务，例如拨打电话，使用系统邮箱等功能。他们的协议头就像下面这样：
mailto://
tel://110
如果你未使用过，那么最直观的，你在手机的系统浏览器 Safar 中输入上面的命令，系统就会提示你是否拨打电话或者编写邮件。tel:// 和 mailto:// 就是系统电话和邮件应用的路由协议头。
一些热门的应用同样定义了自己的路由协议头，例如QQ、微信、微博等：
mqq://
weixin://
sinaweibo://
1.1 接收处理
通过 -openURL: 过来的的消息，我们可以通过 AppDelegate 中的回调代理进行接收处理：
- application:handleOpenURL: // iOS 9.0 -
- application:openURL:options:options:// iOS 9.0 +
2 Universal Links
使用 URL Scheme 有两个弊端，第一个就是混乱，由于 URL Scheme 是自定义字段，任何App都可以使用 weixin:// 这就可能导致系统跳转错误，这种情况在公司开发一系列的应用时经常发生。第二个就是如果用户未安装与 URL Scheme 对应的应用时，系统则无法正常跳转，这时通常需要我们程序员手动判断是否可以打开此 URL：-canOpenURL:，然后引导用户去安装对应的应用。
在 iOS 9.0 之后，苹果新增了一项功能 Universal Links，直译就是通用链接，这个功能让我们可以通过普通的 HTTP 链接就能启动我们的 App。
使用 Universal Links 跳转应用的好处就是：
-
如果安装了App，无论是在系统浏览器 Safari 里，还是在其他使用了
webView控件的页面中，都可以打开App。 -
如果没有安装App，就会打开对应的网页，这个网页可以是宣传官网，又或者是下载安装地址。
我们在系统的备忘录演示设置过 Universal Links 的例子。
Universal Links 实例
当你在备忘录中点击设置了 Universal Links 的链接，系统就会跳转到对应的App，当然这里没有演示过程，为了演示，我们进行了长按操作，我们可以看到这里多了一项 在“某应用”中打开 的选项，点击它同样会打开对应的应用。
网页中查看
即使用户没有跳转对应的app，在网页的顶部同样会出现提示（此时手机中需要有安装App）。
2.1 如何使用
了解了 Universal Links 的能力之后，我们快点来体验一下吧！使用 Universal Links功能需要三件事要做：
- App 需要开启 Associated Domains 服务，并设置 Domains。
- 一个支持 HTTPS 的服务地址。
- 一份跟应用相关的配置文件。
首先是开启相关的功能服务 Associated Domains：
Xcode 11+ ：PROJECT -> TARGETS -> Signing & Capabilityes -> + Capability -> Associated Domains
Xcode 11- ：PROJECT -> TARGETS -> Capabilities -> Associated Domains
注意，需要 applinks 开头:
Associated Domains
开启服务后，app 相应的配置描述文件同样需要开启服务。
接着就是支持 HTTPS 的域名地址，这个地址是为了让苹果访问第三点的App信息的配置文件的。
配置文件中的内容是 JSON 格式的文件，文件名必须为apple-app-site-association，没有 .json 的后缀 ，并将其放在上述域名的根目录下，或者.well-known目录下，苹果会自动去下载更新这个文件。
关于文件的创建，你可以在 Xcode 中创建空白文件，编辑好内容后，将其拿出，文件内容可以像下面这样：
{
"applinks": {
"apps": [],
"details": [
{
"appID": "9JA89QQLNQ.com.apple.wwdc",
"paths": [ "/wwdc/news/", "/videos/wwdc/2015/*"]
},
{
"appID": "ABCD1234.com.apple.wwdc",
"paths": [ "*" ]
}
]
}
}
注：
appID：组成方式是 teamId.yourapp’s bundle identifier。如上面的 9JA89QQLNQ就是teamId。登陆开发者中心，在Account -> Membership里面可以找到Team ID。
paths：设定你的app支持的路径列表，只有这些指定的路径的链接，才能被app所处理。星号的写法代表了可识 别域名下所有链接，即可以任意打开应用。
更多的详细信息可以查看 官方文档 。
2.2 接收处理
和 URL Scheme 不同，Universal Links 的唤醒回调则是下面的方法：
-(BOOL)application:(UIApplication *)application continueUserActivity:(NSUserActivity *)userActivity restorationHandler:(void (^)(NSArray<id<UIUserActivityRestoring>> * _Nullable))restorationHandler {
NSLog(@"userActivity : %@",userActivity.webpageURL.description);
return YES;
}
App内部的跳转
上一小节我们简单介绍了一下 App 之间的两种跳转方式，在唤醒 App 的回调中，我们可以拿到路由信息，再由路由信息映射到具体的资源，这里就涉及到接下来要介绍的路由概念。
前面曾说到，路由涉及到数据信息的解析处理和资源分发。在接收到的路由包含了我们所需要的功能信息，接下来就涉及到如何解析和资源分发的部分。
App 内部的跳转通常有几种功能需求：跳转页面，调用功能组件，其他功能。
常见的就是页面的跳转，从页面A跳转到页面B时，我们一般都会在A中引入B，在跳转的地方生成B的实例并进行跳转，又或者采用MVVM的设计模式，但是缺点就是import引入的头文件相对分散，不方便管理，另外采用硬编码的跳转方式时，一旦出现问题，我们无法降级处理，将错误引导至其他页面。
路由框架
路由的框架主要涉及路由协议的解析和分发方式，我们来看下 Github 上 star 相对多的框架，我们分别来看下。
JLRoutes 是一种基于 URL Scheme 的路由框架，它全局会保存一个Map，key 是路由协议 url，value 则是对 url 解析后 block 回调，你可以在该回调中处理具体的业务。
实例：
例如我们的路由协议定义如下：
scheme://描述/打开方式/保留字段/功能标识？参数1=值1&参数2=值2
||
myroute://market/1/route/cjpm?stockcode=600212.ss
首先配置路由 url 和 对应的回调处理：
/// 默认下都会进入这里，这里填写路由匹配规则
[JLRoutes.globalRoutes addRoute:@"/market/:operate/route/:code" handler:^BOOL(NSDictionary<NSString *,id> * _Nonnull parameters) {
NSLog(@"%@", parameters);
// 接下来的业务逻辑
return YES; // 返回YES，表示处理截止，后面的路由规则不再启用
}];
然后在需要路由的地方传入相应的路由 url ：
// 某地方获取到的url
NSURL* url = [NSURL URLWithString:@"myroute://market/1/route/cjpm?stockcode=600212.ss"];
// 处理路由
[JLRoutes routeURL:url];
控制台输出：
{
JLRoutePattern = "/market/:operate/route/:code";
JLRouteScheme = myroute;
JLRouteURL = "myroute://market/1/route/cjpm?stockcode=600212.ss";
code = cjpm;
operate = 1;
stockcode = "600212.ss";
}
JLRoutePattern 是匹配的正则，JLRouteScheme是 Scheme，JLRouteURL是处理的路由 url， JLRoutePattern 中的:operate 和 :code 表示需要匹配取出的信息字段，而后面的参数默认都会被取出放到回调字典中。
JLRoutes 还支持可选类型的匹配规则、优先级、自定义多种scheme等等，帮助你处理多种复杂多变的路由设置。
但是 JLRoutes 有两个缺点，第一个就是 JLRoutes 保存的 url 和 block 会常驻内存，这一点是不必要的，如果项目中存在大量的路由，则会造成大量的内存浪费；第二个就是 Map 是以数组形式来保存的（可能是因为引入了优先级的关系导致采用了数组形式），在查找 url 和 block 时，效率不够高。
该库是由蘑菇街的技术团队开源的项目，特点是使用简单方便，JLRoutes 的问题是查找 url 是遍历查找而不是匹配，效率不高，MGJRouter 则采基于匹配查找，在大量的的路由下，效率会提高，但是功能相对单一，同样没有解决内存占用的问题。
MGJRouter 的使用和 JLRoutes 类似：
// 注册路由匹配
[MGJRouter registerURLPattern:@"myroute://market/:operate/route/:code" toHandler:^(NSDictionary *routerParameters) {
NSLog(@"%@", routerParameters);
}];
// 某地方获取到的url
NSURL* url = [NSURL URLWithString:@"myroute://market/1/route/cjpm?stockcode=600212.ss"];
// 处理路由
[MGJRouter openURL:url.absoluteString];
MGJRouter 还提供了额外参数的配置（UserInfo）、处理回调（需要手动取出使用）以及自动生成路由的功能。
NSString* generateURL = [MGJRouter generateURLWithPattern:@"myroute://market/1/route/:code?stockcode=:stockcode" parameters:@[@"cjpm",@"600212.ss",]];
总结
本文简单介绍了 iOS 中路由的概念，以及一些场景的应用，如拨打电话，发邮件等等，并演示如何通过 URL Scheme 和 Universal Links 两种方式实现 App 之间的跳转。在应用内部的路由跳转，我们可以利用自定义的路由协议来实现。然后紧接着介绍了基于 URL Scheme 的两种路由框架 JLRoutes 和 MGJRouter，两种框架发挥的作用都是将路由信息进行解析，通过 block 的形式触发解析结果回调。JLRoutes 功能相对丰富，但是效率不如 MGJRouter，但是抛开业务谈架构是没有意义的，两种框架各有优缺点，没有那种路由方案是最好的，结合自身的项目的需求特点，找到最适合的方案才是正确的。
引入路由的其中一个理由就是为了避免硬编码的问题，但是在解析完路由之后，通常做的依然是硬编码的操作，如果此时结合面向接口编程 + 依赖注入 能够进一步避免硬编码的问题。
网友评论