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 连接实现页面的跳转

具体细节的实现参考连接：www.cocoachina.com/ios/2015090…

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 判断是否安装
segmentfault.com/a/119000000…

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 具有哪些能力

那么惟一标识须要知足哪些条件呢

1. 选择当作惟一标识的内容，必须能让app获取的到
2. 选择当作惟一标识的内容，必须也能让h5获取的到
3. 选择当作惟一标识的内容，还必须有能力区分出不一样的设备，若是选的惟一标识好几个设备取出来的都同样，那么就乱套了

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

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

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

1. 设备屏幕尺寸（iOS设备如此的统一，一共就那么几个屏幕尺寸，重复的还不一堆一堆的）
2. 设备操做系统（iOS系统碎片化如此的低，大部分几乎都升到较高级的系统版本，重复的依然一堆一堆）
3. 设备IP（IP这玩意会变啊，离开WIFI进入3G，常常变，而且IP这玩意在同一WIFI下也重复的一堆一堆的啊）
4. 访问时间（时间这玩意更没谱了，大家的用户量越大，某一个肯定的时间段内，发生第一次安装，重复的就越多）

上面的数据最大的特色就是，有必定的描述设备体征的信息，可是若是只靠这一个描述信息，那结果就是重复的太多太多，根本无法肯定一个惟一性。
可是，若是咱们把这么些描述信息作成一个合集，同一时间内知足全部的条件，那么这个设备重复的几率一下就缩减了太多太多。

好比：

设备以前访问过度享的连接，服务区手机到了上面的基本信息，设备经过引导安装了app,安装完毕第一次打开的时候，app 也上报这些基本信息，服务器找到一样的屏幕尺寸，一样的操做系统版本，一样的IP地址，访问时间相差不超过8min（暂定）的设备，在如此多得限定条件下，咱们近乎能够认定为，是具备惟一性的设备，是同一我的
能够看到这里面众多的信息一块儿去过滤，比较强的过滤条件就是IP，但由于IP存在频繁变化，因此追加了时间条件，IP也可能由于WIFI路由器的缘由致使，IP也存在重复和误伤，这时候，又辅助了简单的设备信息进行二次过滤。
这样咱们就找到了一个并不完美的惟一标识

方案的弊端

由于他是不完美的惟一标识，因此就存在着

1. 有时间段限制 如上：8 分钟以内h5浏览引导，完成app下载，启动操做的
2. 误伤，存在同一个IP出口，同一时间段，一样的设备特征的状况下，有2个2我的以上的人作一样的事情

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

原理就是：
SFSafariViewController 能够和 safari 共享沙盒，能够共享cookie，cookie 的sessionid 能够惟一标识

可是你也能够看到一样有很是大的弊端
只能在safari下打开的才生效，在微信，QQ 这种不生效

这就形成了很是的局限性，目前国内大部分分享都是经过微信的

参考资料
segmentfault.com/a/119000000…
www.cocoachina.com/ios/2016010…