iOS App间相互跳转漫谈 part2

写在前面

上一篇已经介绍了iOS系统层面提供的应用之间跳转的技术和实施方案，本篇会带你们更深刻的了解UniveralLinks技术，探究其绑定运做原理，使用时的技巧。

运做原理

对于UniversalLinks的生效和绑定原理，官方文档并未说明，经过亲自尝试整理出了其绑定原理，这有助于对于触发时机把握：

1. App从iOS9开始，安装App成功后，系统会检查App是否对UniversalLinks技术作了支持，若是检查到有作支持，则从App的associated-domains配置里读取绑定域名。

2. 访问该域名下预设的JSON文件apple-app-site-association，读取JSON文件中的app绑定信息，与当前App内的信息作对比。

3. 若是匹配成功，在系统本地内部就作完了双向绑定。

也就是只要App安装完成，就能够即刻触发UniversalLinks打开App啦！不须要像推送那样，须要打开一次。

巧用UniveralLinks判断App是否安装

上一篇文章也提到了，目前全部包括UniversalLinks技术都没法直接对App的安装作判断。

但我要说：非也！UniversalLinks提供的一项特性可让咱们反向推断App是否安装，并且准确率至关高，不像scheme跳转那样，只能作延时。

UniversalLinks在触发时，也就是连接被点击时，系统会与本地已经创建双向绑定的数据进行匹配，匹配到的话，这个网络请求就会在系统层面被拦截，系统就会转而打开绑定的App，并把完整URL传给App的openURL的Delegate方法来处理。反之，若是App没有安装，那么点击连接时系统没法匹配到信息，则就将请求放行，让服务端接收到这个请求来处理。

看到这里已经很明了了吧，用户只要点击了，服务端能够经过是否接收到请求来判断App是否已安装。

固然这里也会不许，但几率比较小，缘由若是用户是长按打开，或者打开App后点击了右上角的系统的返回按钮后，系统会下次触发UniversalLinks的时候就不会拦截请求了，致使接收到请求的设备其实已经App，而咱们没法知道。要想从新让系统拦截，用户须要点击的时候长按link，而且选择经过App打开，以后才又会被拦截。

但已经比scheme跳转设置一个timeout要来的靠谱的多了。

巧用UniveralLinks拉新引旧

UniversalLinks做为一个平滑使用体验的工具类技术来讲，自己不具有拉新客户的功能：好比新用户若是从站外点击UniversalLinks，那么用户没有装App的话，只是会访问m站而已，无它；引导老用户从H5迁移到App的能力也比较弱，一直使用m站的用户，只有在页面顶部看到有一个入口，点击才能打开App。缘由是用户若是直接输入了m站的地址，在站内访问，是不会触发UniversalLinks的，只是会在绑定的H5页面顶部有一个bar提醒用户，点击能够跳转到App的相同功能，能够说是很弱的。

让咱们看看怎么才能让它具有强制拉新引旧能力：

• 首先要具有判断是否安装App的条件来区分新用户仍是老用户，若是未安装则为新，已安装则为旧。方法上面一节已经介绍。
• 接下来服务端开发一个特殊的UniversalLinks，相似于https://app.alibaba.com/babalink，对app作好双向绑定，注意，这里域名与m站的m.alibaba.com域名必须不一样。
• babalink接收两种参数scheme=&url=，前者是应用的scheme跳转，服务端拼接传入打开App后须要打开页面的scheme值，这个值是给已安装App的状况用的；还有url中传入须要跳转的http页面，一般是这个连接本来功能的m站连接。
• 这里举个栗子，例如跳转到产品详情，app的scheme是enalibaba://detail?id=123；而m站的页面是https://m.alibaba.com/product?id=123；那么服务端在搜索结果页每一个结果的连接应该是https://app.alibaba.com/babalink?scheme=enalibaba://detail?id=123&url=https://m.alibaba.com/product?id=123每一个一级参数下的值都须要urlencode，这边为了查看方便就不作了。
• 这样，用户到了m站搜索结果页的时候，每一个搜索结果点击的都是上面这种连接，这种连接的域名与m站自己域名不一样，在App已安装的状况下就会触发系统拦截请求，跳转App，App在打开时经过完整url中的scheme参数，进行页面跳转便可完成引导老用户的操做。
• 再看看新用户，新用户由于没有安装App，因此这个link的请求会被发送到服务端，服务端根据状况控制将其引导到AppStore去安装App，或者直接重定向到url参数的网页。后者不用说仍是延续用户在m站的上的继续浏览，前者打开了AppStore安装了App后，用户打开时首页怎么办？
• 这里这里能够利用归因系统来作到从AppStore打开，还能继续以前的操做，大体原理是服务端接收到link的请求，从请求中将这个请求转化为用户指纹存起来。
• 当用户打开刚安装好的App后，App会在启动的时候将一些可做为指纹的数据当作参数经过某个接口传给服务端，服务端接收App的指纹数据参数后，经过算法匹配以前的用户指纹，匹配上后将用户点击的完整连接返回给客户端，由客户端来说连接解析，利用其scheme值进行跳转，便可完美continue用户的行为。

从其余App直接打开

• 从浏览器打开，只要是当前页面的域名和用户点击按钮的universallinks的域名是不一样的，就会触发。
• 在App中打开会有些麻烦，只有经过[[UIApplication sharedApplication] opentURL:@"https://app.alibaba.com/babalink?scheme=enalibaba://detail?id=123&url=https://m.alibaba.com/product?id=123"]这样打开，才能跳转到目标app，若是把连接塞到webview中则不会触发，请求必定会到服务端。
• 因此，微信里直接经过聊天内容发送连接跳转是作不到的。
• 这里可让连接检测浏览器UA来判断连接是否为从其余App打开，若是是，则重定向到https://app-c.alibaba.com/babalink?scheme=enalibaba://detail?id=123&url=https://m.alibaba.com/product?id=123注意这个连接的域名不是app.alibaba.com，这个h5页面展现一个按钮，跳转连接为https://app.alibaba.com/babalink?scheme=enalibaba://detail?id=123&url=https://m.alibaba.com/product?id=123。为何？由于要跨域，并且点击行为在浏览器中进行是没法阻断的。
• 此时用户点击中间页按钮时，即使在其余App，不论是Facebook仍是微信，均可以触发UniversalLink啦！

总结

总结一下，巧用UniversalLink须要让服务端的这个link具有

1. 继续用户m站行为
2. 跳转AppStore行为
3. 重定向到中间页行为
4. 连接归因存储匹配能力