iOS Deep Linkin 和 Deferred Deep Linking-白红宇

1. 什么是deep linkin 和 deferred Deep Linking

a. deep linkin:在移动开发领域，deep linking 则是指 mobile app 在 handle 特定 URI 的时候可以直接跳转到对应的内容页或触发特定逻辑，而不仅仅是启动 app

b. deferred Deep Linking: deferred deep linking 是指用户打开一个 web page 的时候并没有安装对应的 app，希望用户在安装 app 以后可以 deep link 到对应内容

2. 如何实现deep linkin

1）URL Scheme 的方式，在iOS9 以前很长一段时间都是采用这种方式，通常URL schema 格式如:schema://new/list?key1=value1&key2=value2 这种方式，然后都有自己一套解析schema的路由router,路由也是组件化的重要组成部分，网上有很多相关资料，就不详细介绍了。

这种方式需要在appdelegate 中实现，然后里面根据做schema 解析，根据URL

- (BOOL)application:(UIApplication *)application openURL:(NSURL *)url sourceApplication:(NSString *)sourceApplication annotation:(id)annotation { }

2）Universal Links 的方式，苹果在iOS9 后引入这种方式，带来了几大好处

Custom URL scheme 因为是自定义的协议，所以在没有安装 app 的情况下是无法直接打开的，而 universal links 本身是一个 HTTP/HTTPS 链接，所以有更好的兼容性

Universal links 支持从其他 app 的 MKWebView 或 UIWebView 中跳转到目标 app

Universal links 本身可以被搜索引擎索引。

微信不再能封禁跳转了，终于可以实现平滑跳转

尤其是最后一条，实现Universal links 跳转，已经成为各大公司运营推广，带回APP流程的一个重要手段

那如何才能实现Universal links呢，首先满足实现Universal links 需要以下几个必要条件：

xcode 7 以上，需要做一些配置信息

iOS 9 以上的系统

注册通过的ssl 协议（https）

分享的地址域名和需要条状的Universal links域名不能相同，需要跨域

具体的实现不详细描述，是一个需要前端和客户端一起配合的一个项目

前端的工作主要有以下几个点

满足ssl 协议的域名

上传苹果验证通过的apple-app-site-association文件到域名根目录下

写出兼容性很强的js,判断ios9 以上和以下分别怎么处理，微信平台和非微信平台，判断已经安装和未安装等情况

客户端需要做的工作

Xcode中开启Associated Domains服务

要在苹果开发者网站中开启App的Associated Domains功能

appdelegate 中实现Universal links 的代理

解析Universal links 链接实现页面的跳转

具体细节的实现参考链接：

h5 如何做各种情况兼容（暂时未考虑android 情况）

首先有以下几种情况

已经安装

A. 微信内

1. iOS 9 以上    universal link打开    universal link关闭 ：不存在关闭这一行为，只是苹果给的一个记录最后一次的打开方式，但是这个是在safari 浏览器生效2. iOS 9 以下    方案一：schema 技术，由于微信屏蔽，加浮层引导 右上角safari 打开    方案二：跳应用宝，应用宝可以转跳复制代码

B. 微信外:

1. iOS 9 以下： schema 方式打开     2. iOS 9 以上：universal link ，schema 均可，universal link 更好复制代码

未安装

未安装跳转下载页面

如何判断是否安装呢，尤其是在微信平台，目前比较通用的做法是先正常链接universal link 或者schema 地址，然后采用一个timeout做一个延时跳转到下载中间页面地址

代码大概如下：

$('a').click(function() {    location.href = '自定义 URL scheme 或者 universal link 地址';    setTimeout(function() {        location.href = '下载中间页面页';    }, 250);    setTimeout(function() {        location.reload();    }, 1000);}复制代码

具体h5 实现细节参考或者搜索引擎搜索 h5 判断是否安装

3. 如何实现 deferred Deep Linking

一开始也解释了什么是deferred deep linking ：是指用户打开一个 web page 的时候并没有安装对应的 app，希望用户在安装 app 以后可以 deep link 到对应内容。

实现思路大家都可能都猜的到：

就是h5 需要上报设备的一些信息到服务端，用户下载后，第一次启动也上设备信息，去服务端匹配是否应该跳转和跳转地址

这里有三个需要解决的问题：

判断是否已经安装了 app，如果已经安装了直接 deep link 到 app，否则跳转 App Store。

用户匹配（user matching），如何把一个 install 对应到某一次 web page view 或者某一次 click。

Deep linking

第一个问题其实上面也讲到一些，就是判断用户是否已经安装了app

window.location = 'schema url 或者 universal link 地址';  setTimeout(function() {      window.location = '下载中间页面或者APPStore 地址'}, 250);复制代码

在 iOS 9.2 以前，Safari 里是否用 app 打开 scheme URL 会有一个弹框所以如果用户同意用 app 打开链接以后就不会跳转 App Store，反之，用户选择取消或者并没有安装 app 的时候，会跳转 App Store。iOS 9.2 Apple 不再弹 block JS，所以无论如何都会跳转 App Store。加上微信scheme URL 不生效，因此现在会推荐使用 universal links 来实现这样的逻辑

第二个问题就实现这儿的核心，如何标识一个用户，其实很多广告追踪也有这样的场景

方案流程

用户在wap网页上产生了行为，产生了用户个人数据

wap网页收集了一种能够唯一标识设备的信息，并且发送给了服务器

app安装完毕后第一次运行，也去通过app尝试收集唯一标识设备的信息，并且发给服务器

服务器经过对比，发现app的唯一标识与wap网页发上来的唯一标识能够匹配

服务器判断，是同一个人操作，于是下发用户个人数据
纵观整个流程发现，一切的核心，一切的关键，就是那个唯一标示

不难看出唯一标识是这里面的重点，那么问题来了，如何选取唯一标识，需要考虑，h5 具备哪些能力

那么唯一标识需要满足哪些条件呢

选择当做唯一标识的内容，必须能让app获取的到

选择当做唯一标识的内容，必须也能让h5获取的到

选择当做唯一标识的内容，还必须有能力区分出不同的设备，如果选的唯一标识好几个设备取出来的都一样，那么就乱套了

那么我们看看遵循这几个条件，我们能选择啥？

常用的UDID,MAC,IDFA地址啥的这玩意app是能取到了，但是h5拿不到啊

那么我们反过来推，h5 能取到什么

设备屏幕尺寸（iOS设备如此的统一，一共就那么几个屏幕尺寸，重复的还不一堆一堆的）

设备操作系统（iOS系统碎片化如此的低，大部分几乎都升到较高级的系统版本，重复的依然一堆一堆）

设备IP（IP这玩意会变啊，离开WIFI进入3G，经常变，并且IP这玩意在同一WIFI下也重复的一堆一堆的啊）

访问时间（时间这玩意更没谱了，你们的用户量越大，某一个确定的时间段内，发生第一次安装，重复的就越多）

上面的数据最大的特点就是，有一定的描述设备体征的信息，但是如果只靠这一个描述信息，那结果就是重复的太多太多，根本没法确定一个唯一性。

但是，如果我们把这么些描述信息做成一个合集，同一时间内满足所有的条件，那么这个设备重复的概率一下就缩减了太多太多。

比如：

设备之前访问过分享的链接，服务区手机到了上面的基本信息，设备通过引导安装了app,安装完毕第一次打开的时候，app 也上报这些基本信息，服务器找到同样的屏幕尺寸，同样的操作系统版本，同样的IP地址，访问时间相差不超过8min（暂定）的设备，在如此多得限定条件下，我们近乎可以认定为，是具有唯一性的设备，是同一个人

可以看到这里面众多的信息一起去过滤，比较强的过滤条件就是IP，但因为IP存在频繁变化，所以追加了时间条件，IP也可能因为WIFI路由器的原因导致，IP也存在重复和误伤，这时候，又辅助了简单的设备信息进行二次过滤。

这样我们就找到了一个并不完美的唯一标识

方案的弊端

因为他是不完美的唯一标识，所以就存在着

有时间段限制如上：8 分钟之内h5浏览引导，完成app下载，启动操作的

误伤，存在同一个IP出口，同一时间段，同样的设备特征的情况下，有2个2个人以上的人做同样的事情

但是在iOS9 以上，还有一种精准的解决方案就是iOS9 的SFSafariViewController

原理就是：

SFSafariViewController 可以和 safari 共享沙盒，可以共享cookie，cookie 的sessionid 可以唯一标识

但是你也可以看到同样有非常大的弊端

只能在safari下打开的才生效，在微信，QQ 这种不生效

这就造成了非常的局限性，目前国内大部分分享都是通过微信的

参考资料