iOS 路由的概念

2019-10-31 本文已影响0人小白进城

前端的路由

网络中路由概念是指路由器从一个接口上接收到数据包，根据数据包的目的地址进行定向转发到另一个接口的过程。直白一点就是，路由是一种数据的收集和分发过程。在前端开发中，路由的作用主要是保证视图和 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

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 时，效率不够高。

MGJRouter

该库是由蘑菇街的技术团队开源的项目，特点是使用简单方便，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，但是抛开业务谈架构是没有意义的，两种框架各有优缺点，没有那种路由方案是最好的，结合自身的项目的需求特点，找到最适合的方案才是正确的。

引入路由的其中一个理由就是为了避免硬编码的问题，但是在解析完路由之后，通常做的依然是硬编码的操作，如果此时结合面向接口编程 + 依赖注入能够进一步避免硬编码的问题。