作为scheme技术的升级替代方案，Universal Links在国内应用程度并不高，官网和民间现有中英文资料基本都是介绍实现步奏的。本文志在从宏观角度补充Universal Links的运用机制，会简单介绍其中关键点，详细记录了在官网和民间资料中缺失的线下调试部分，并就应用程度不高的现象提出自己的解读
什么是Universal Links
Universal Links 是一种深度链接 (又名 Deep Link，What is deep linking?)，并且可以无缝链接到app或网页，主要应用场景有 内容分享 和 广告投放。它有如下特点：
- 如果安装了app，会直接打开app，并定位到内容页
- 如果没有安装app，使用浏览器打开该链接
除了Universal Links，iOS中的scheme也可以实现deep link。据笔者观察，国内app的唤端（唤起app）基本都是scheme实现的（2022.6 scheme: 淘宝、拼多多、京东，Universal Links: 抖音），详见彩蛋。
效果示例：京东会在百度上投放商品广告，用户使用百度app搜索关键词的时候，就可以看到京东的商品，点开后可以直接跳转到京东app，并且app会自动打开刚才浏览的商品，用户可以一键购买。假如用户没有安装京东，这时候点击百度搜索结果中京东商品，会在百度app内直接打开京东的h5页面，用户仍然可以继续浏览商品，体验丝滑，毫无卡点。
Universal Links原理
本着技术人的认真严谨，我们先看一下打开Universal Links会发生什么：
- 宿主app发起唤端请求（调用 open(_:options:completionHandler:) 方法）
- iOS系统检查域名的AASA文件(apple-app-site-association)，从AASA文件中找到URL需要唤起的app
- iOS系统检查需要唤起的app的entitlements文件，确认app可以处理该域名。这一步的作用是确认网页的合法性，防止未知网页对app的攻击
- iOS系统唤起app，并调用app的-[UIApplicationDelegate application:continueUserActivity:restorationHandler:]方法，app在这个方法里处理URL，定位到URL描述的内容
所以要实现Universal Links，我们需要：
- 跟后端｜前端同学配合，发布有效的AASA文件
- 配置app的 Associated Domains
- app内对URL进行处理
具体实现步骤有很多资料可以参考：
详细全面的英文资料：Universal links in iOS
简单易懂的中文资料：iOS Universal Links教程
AASA文件
AASA（apple-app-site-association）文件是一个位于 /.well-known 文件夹下面的json文件 （eg: https://your_domain/.well-known/apple-app-site-association），里面描述了目标app的信息。AASA文件和entitlements为网站和app提供了互相认证的机制。example：
{
"applinks": {
"apps": [],
"details": [
{
"appID": "YourAppID.com.your.bundleId",
"paths": [
"", //使用空字符串匹配裸域名
"*", //使用*匹配所有path
"/product", //文本匹配
"/product/*", //使用*匹配任意个数的任意字符
"/product/201?/page" //使用?号匹配单个字符
]
}
]
},
"webcredentials": {
"apps": ["YourAppID.com.your.bundleId"]
}
}
复制代码AASA文件通常是后端同学帮忙发布的，发布时注意以下几点：
- 文件不能加后缀名
- content-type需要设置成json
- 不能有重定向
AASA文件的格式和命名会直接影响到iOS系统能否正常拉取、识别里面的内容。现有一些工具可以校验AASA文件有效性：
Associated Domains配置
暂无注意事项，按照网上资料配置就好
线下调试
在修改AASA文件后，我们通常不能直接发布线上，需要在先测试一下
iOS14以前
iOS14之前，xcode launch app时，iOS系统会主动请求https://your_domain/apple-app-site-association 拉取AASA数据，所以我们只需要用charles或者LightProxy等抓包软件 mock 这个url就好了。
iOS14及之后
iOS14之后，苹果采用CDN缓存设计，设备不再直接请求域名下的apple-app-site-association文件：
Starting with macOS 11 and iOS 14, apps no longer send requests for apple-app-site-association files directly to your web server. Instead, they send these requests to an Apple-managed content delivery network (CDN) dedicated to associated domains.
这时候需要用到develop模式，苹果官网对develop模式的介绍：
While you’re developing your app, if your web server is unreachable from the public internet, you can use the alternate mode feature to bypass the CDN and connect directly to your private domain.
You enable an alternate mode by adding a query string to your associated domain’s entitlement as follows: :?mode=
上面就是官网关于develop模式的全部描述，网上资料更是寥寥。经过艰难的探索，笔者总结出了develop模式的操作步骤：
第一步：修改Associated Domains
路径：Xcode工程 -> Signing & Capabilities -> Associated Domains 给需要线下调试的域名增加mode=develop后缀
第二步：打开手机中的Associated Domains Development选项
路径：设置 -> 开发者 -> Associated Domains Development
第三步：Mock数据
做完了前面两步，就和iOS14之前一样了：当用Xcode运行app启动时，设备就会绕过CDN，直接请求域名下面的.well-known/apple-app-site-association文件，可以通过抓包看到这个请求。这样就可以用LightProxy或者charles mock数据。
彩蛋
使用scheme唤端最大的问题是，没安装app的时候唤端没效果。所以国内的主流解决方案是直接 分享/投放 普通h5链接，用户点击h5链接，h5一边加载正常内容，一边自动尝试使用scheme跳转，跳转没效果也没关系，因为h5已经把内容加载出来了，可以正常使用。
那为什么国内的app们，都采用了落后繁琐的scheme技术呢，难道是他们的技术不够勤快吗？笔者认为不是，笔者认为是没有利益点驱动他们更新换代，
唤端对用户来说，是一种工具，目的是要在app间共享信息（编辑文档、浏览商品），但是对于平台来说，唤端过来的用户是流量，而流量是互联网平台变现的命脉。平台一方面希望其他平台的用户顺滑的迁移到自己的app，另一方面则在努力圈住自己的用户，不让用户去其他平台。我们上面说的百度和京东互动的例子，用的其实还是scheme。百度惜流，即使卖了广告，让用户去了京东，还是希望用户能够再回到百度，所以在京东页面左上角提供“回到百度”的功能。也无法责怪百度，强如微信，也是如此。抖音分享出来的链接是Universal Links，但是在微信里，却只能在微信自带的浏览器中打开。
各个平台像一座座孤岛，把用户圈起来，Universal Links有什么用，你生成了，需要别人支持打开才行。如果那天微信支持Universal Links直接打开app，我相信一夜之间各大平台都会争相更新唤端方案。
参考链接：
- 苹果官网（新）：developer.apple.com/documentati…
- 苹果官网（老）：developer.apple.com/library/arc…