网上看到这篇文章，写的很清楚，这里转载记录一下。H5唤起APP指南 | 拾壹小筑

1.前言

        前一段时间在做电流App H5页面，需求中落地页占比较大，落地页承担的职责就是引流。引流有两种形式，同时也是我们对唤端的定义：引导已下载用户打开APP，引导未下载用户下载APP。

        引导已下载用户打开APP，从数据上说用户停留在APP中的时间更多了，是在提高用户粘性；从体验上说，APP体验是要比H5好的。引导未下载用户下载APP，可以增加我们的用户量。

        上面其实分别解释了 什么是唤端 以及 为什么要唤端，也就是 3W法则 中的 What 和 Why，那么接下来我们就要聊一聊 How 了，也就是 如何唤端 。

我们先来看看常见的唤端方式以及他们适用的场景：

2. 唤端媒介

2.1 URL Scheme

来源

        我们的手机上有许多私密信息，联系方式、照片、银行卡信息…我们不希望这些信息可以被手机应用随意获取到，信息泄露的危害甚大。所以，如何保证个人信息在设备所有者知情并允许的情况下被使用，是智能设备的核心安全问题。

        对此，苹果使用了名为 沙盒 的机制：应用只能访问它声明可能访问的资源。但沙盒也阻碍了应用间合理的信息共享，某种程度上限制了应用的能力。

因此，我们急需要一个辅助工具来帮助我们实现应用通信， URL Scheme 就是这个工具。

URL Scheme 是什么

我们来看一下 URL 的组成：

[scheme:][//authority][path][?query][#fragment]

我们拿 https://www.baidu.com 来举例，scheme 自然就是 https 了。

        就像给服务器资源分配一个 URL，以便我们去访问它一样，我们同样也可以给手机APP分配一个特殊格式的 URL，用来访问这个APP或者这个APP中的某个功能(来实现通信)。APP得有一个标识，好让我们可以定位到它，它就是 URL 的 Scheme 部分。

常用APP的 URL Scheme

APP微信支付宝淘宝微博QQ知乎短信
URL Schemeweixin://alipay://taobao://sinaweibo://mqq://zhihu://sms://

URL Scheme 语法

上面表格中都是最简单的用于打开 APP 的 URL Scheme，下面才是我们常用的 URL Scheme 格式：

     行为(应用的某个功能)    
            |
scheme://[path][?query]
   |               |
应用标识       功能需要的参数

Intent

       安卓的原生谷歌浏览器自从 chrome25 版本开始对于唤端功能做了一些变化，URL Scheme 无法再启动Android应用。 例如，通过 iframe 指向 weixin://，即使用户安装了微信也无法打开。所以，APP需要实现谷歌官方提供的 intent: 语法，或者实现让用户通过自定义手势来打开APP，当然这就是题外话了。

Intent 语法

intent:
   HOST/URI-path // Optional host 
   #Intent; 
      package=[string]; 
      action=[string]; 
      category=[string]; 
      component=[string]; 
      scheme=[string]; 
   end;

      如果用户未安装 APP，则会跳转到系统默认商店。当然，如果你想要指定一个唤起失败的跳转地址，添加下面的字符串在 end; 前就可以了:

S.browser_fallback_url=[encoded_full_url]

示例

下面是打开 Zxing 二维码扫描 APP 的 intent。

intent:
   //scan/
   #Intent; 
      package=com.google.zxing.client.android; 
      scheme=zxing; 
   end;

打开这个 APP ，可以通过如下的方式：

<a href="intent://scan/#Intent;scheme=zxing;package=com.google.zxing.client.android;S.browser_fallback_url=http%3A%2F%2Fzxing.org;end"> Take a QR code </a>

Universal Link 是什么

Universal Link 是苹果在 WWDC2015 上为 iOS9 引入的新功能，通过传统的 HTTP 链接即可打开 APP。如果用户未安装 APP，则会跳转到该链接所对应的页面。

为什么要使用 Universal Link

传统的 Scheme 链接有以下几个痛点：

  • 在 ios 上会有确认弹窗提示用户是否打开，对于用户来说唤端，多出了一步操作。若用户未安装 APP ，也会有一个提示窗，告知我们 “打不开该网页，因为网址无效”
  • 传统 Scheme 跳转无法得知唤端是否成功，Universal Link 唤端失败可以直接打开此链接对应的页面
  • Scheme 在微信、微博、QQ浏览器、手百中都已经被禁止使用，使用 Universal Link 可以避开它们的屏蔽（ 截止到 18年8月21日，微信和QQ浏览器已经禁止了 Universal Link，其他主流APP未发现有禁止 ）

如何让 APP 支持 Universal Link

有大量的文章会详细的告诉我们如何配置，你也可以去看官方文档，我这里简单的写一个12345。

  1. 拥有一个支持 https 的域名
  2. 在 开发者中心 ，Identifiers 下 AppIDs 找到自己的 App ID，编辑打开 Associated Domains 服务。
  3. 打开工程配置中的 Associated Domains ，在其中的 Domains 中填入你想支持的域名，必须以 applinks: 为前缀
  4. 配置 apple-app-site-association 文件，文件名必须为 apple-app-site-association ，不带任何后缀
  5. 上传该文件到你的 HTTPS 服务器的 根目录 或者 .well-known 目录下

Universal Link 配置中的坑

这里放一下我们在配置过程中遇到的坑，当然首先你在配置过程中必须得严格按照上面的要求去做，尤其是加粗的地方。

  1. 域名问题

    Universal Link 支持的域名最多只能支持到二级域名，如果你用到了三级域名，Universal Link 唤端是不会生效的。

  2. 跨域问题

    IOS 9.2 以后，必须要触发跨域才能支持 Universal Link 唤端。

    IOS 那边有这样一个判断，如果你要打开的 Universal Link 和 当前页面是同一域名，ios 尊重用户最可能的意图，直接打开链接所对应的页面。如果不在同一域名下，则在你的 APP 中打开链接，也就是执行具体的唤端操作。

  3. Universal Link 是空页面

    Universal Link 本质上是个空页面，如果未安装 APP，Universal Link 被当做普通的页面链接，自然会跳到 404 页面，所以我们需要将它绑定到我们的中转页或者下载页。

3. 如何调用三种唤端媒介

通过前面的介绍，我们可以发现，无论是 URL Scheme 还是 Intent 或者 Universal Link ，他们都算是 URL ，只是 URL Scheme 和 Intent 算是特殊的 URL。所以我们可以拿使用 URL 的方法来使用它们。

3.1 iframe

<iframe src="sinaweibo://qrcode">

在只有 URL Scheme 的日子里，iframe 是使用最多的了。因为在未安装 app 的情况下，不会去跳转错误页面。但是 iframe 在各个系统以及各个应用中的兼容问题还是挺多的，不能全部使用 URL Scheme。

3.2 a 标签

<a href="intent://scan/#Intent;scheme=zxing;package=com.google.zxing.client.android;end"">扫一扫</a>

前面我们提到 Intent 协议，官方给出的用例使用的就是使用的 a 标签，所以我们跟着一起用就可以了。

使用过程中，对于动态生成的 a 标签，使用 dispatch 来模拟触发点击事件，发现很多种 event 传递过去都无效；使用 click() 来模拟触发，部分场景下存在这样的情况，第一次点击过后，回到原先页面，再次点击，点击位置和页面所识别位置有不小的偏移，所以 Intent 协议从 a 标签换成了 window.location。

3.3 window.location

window.location.href = 'sinaweibo://qrcode';

URL Scheme 在 ios 9+ 上诸如 safari、UC、QQ浏览器中， iframe 均无法成功唤起 APP，只能通过 window.location 才能成功唤端。

当然，如果我们的 app 支持 Universal Link，ios 9+ 就用不到 URL Scheme 了。而 Universal Link 在使用过程中，我发现在 qq 中，无论是 iframe 导航 还是 a 标签打开 又或者 window.location 都无法成功唤端，一开始我以为是 qq 和微信一样禁止了 Universal Link 唤端的功能，其实不然，百般试验下，通过 top.location 唤端成功了。

几步走

  1. 判断浏览器，动态加载对应浏览器的下载逻辑
  2. 通过 universal link、URL Scheme、a 标签、iframe 几种方式找出最适合这个浏览器的唤起方式。
  3. 如果下载了 App，就会走打开逻辑，如果没有下载则走下载逻辑。
  4. 如果已知不能唤起的浏览器引导其它浏览器打开

流程：

各个唤起方法对比

没有哪种方式是完美的，每种唤起方式都有它的优势跟劣势，只有将所有的唤起方法在不同浏览器上尝试过才能择优使用。

4. 判断唤端是否成功

如果唤端失败（APP 未安装），我们总是要做一些处理的，可以是跳转下载页，可以是 ios 下跳转 App Store… 但是Js 并不能提供给我们获取 APP 唤起状态的能力，Android Intent 以及 Universal Link 倒是不用担心，它们俩的自身机制允许它们唤端失败后直接导航至相应的页面，但是 URL Scheme 并不具备这样的能力，所以我们只能通过一些很 hack 的方式来实现 APP 唤起检测功能。

const initialTime = new Date();
let counter = 0;
let waitTime = 0;
const checkOpen = setInterval(() => {
   count++;
   waitTime = new Date() - initialTime;
   if (waitTime > 2500) {
      clearInterval(checkOpen);
      cb();
   }
   if (counter < 100) return;
   const hide = document.hidden || document.webkitHidden;
   if (!hide) {
      cb(); // 唤端失败的回调函数
   }
}, 20);


每 20ms 执行一次，执行 100次 在页面中实际耗费与 2000 ms 不会相差多少。APP 如果被唤起的话，页面就会进入后台运行，setInterval 在 ios 中不会停止运行，在 android 中停止运行。

我们的判断条件比预期时间多设置了 500ms，所以如果安卓中 setInterval 内的函数执行 100 次以内所费时间超过 2500ms，则说明 APP 唤起成功，反之则代表失败。

我们通过 document.hidden 和 document.webkitHidden 属性来判断 APP 在 ios 中是否被正常唤起，2000ms 内，页面转入后台运行，document.hidden 会返回 true，代表唤端成功，反之则代表失败。

5. 没有完美的方案

透过上面的几个点，我们可以发现，无论是 唤端媒介 、 调用唤端媒介 还是 判断唤端结果 都没有一个十全十美的方法，我们在代码层上能做的只是在确保最常用的场景（比如 微信、微博、UC 等）唤端无误的情况下，最大化的兼容剩余的场景。

好的，我们接下来扯一些代码以外的，让我们的 APP 能够在更多的平台唤起。

  • 微信、微博、手百、QQ浏览器等。（但是2022年，国家要求这些app开启第三方链接支持）

    这些应用能阻止唤端是因为它们直接屏蔽掉了 URL Scheme 。接下来可能就有看官疑惑了，微信中是可以打开大众点评的呀，微博里面可以打开优酷呀，那是如何实现的呢？

    它们都各自维护着一个白名单，如果你的域名在白名单内，那这个域名下所有的页面发起的 URL Scheme 就都会被允许。就像微信，如果你是腾讯的“家属”，你就可以加入白名单了，微信的白名单一般只包含着“家属”，除此外很难申请到白名单资质。但是微博之类的都是可以联系他们的渠道童鞋进行申请的，只是条件各不相同，比如微博的就是在你的 APP 中添加打开微博的入口，三个月内唤起超过 100w 次，就可以加入白名单了。

  • 腾讯应用宝直接打开 APP 的某个功能

    刚刚我们说到，如果你不是微信的家属，那你是很难进入白名单的，所以在安卓中我们一般都是直接打开腾讯应用宝，ios 中 直接打开 App Store。点击腾讯应用宝中的“打开”按钮，可以直接唤起我们的 APP，但是无法打开 APP 中的某个功能（就是无法打开指定页面）。

    腾讯应用宝对外开放了一个叫做 APP Link 的申请，只要你申请了 APP Link，就可以通过在打开应用宝的时候在应用宝地址后面添加上 &android_schema={your_scheme} ，来打开指定的页面了。

6. 开箱即用的callapp-lib

信息量很大！各种问题得自己趟坑验证！内心很崩溃！

不用愁，已经为你准备好了药方，只需照方抓药即可😏 —— npm 包 callapp-lib

它能在大部分的环境中成功唤端，而且炒鸡简单啊，拿过去就可以用啊，还支持很多扩展功能啊，快来瞅瞅它的 文档 啊~~~

7. 风险示例

关于Intent-based URI的风险我觉得《Android Intent Scheme URLs攻击》和《Intent Scheme URL attack》这两篇文章写的非常好，基本把该说的都都说了，我就不多说了，大家看这两篇文章吧。

参考文章

  1. 浏览器中唤起 native app，否则跳转到应用商城下载
  2. h5唤起app
  3. URL Schemes 使用详解
  4. Android Intents with Chrome
  5. 常用URL Scheme
  6. Universal Link 前端部署采坑记
  7. Support Universal Links
  8. Universal Link是个骗子

APP唤起那点破事 | 明日之事 事事难求

####################################################################

另外一篇文章

1. 运营推广场景

1、微信、QQ等 -> 唤醒APP 

用户通过某APP分享了一条链接至微信或QQ，用户B点开该链接后，会引导用户B打开该APP或者下载该APP。

2、浏览器 -> 唤醒APP

 用户A通过浏览器打开了某APP的M站或者官网，如果检测到A来自手机端，则会引导用户打开该APP或者下载该APP。

3、短信、邮件、二维码等 -> 唤醒APP 

用户A打开了某APP的推广短信，邮件或者扫描二维码等，会引导用户打开该APP或者下载该APP。

4、其他APP -> 唤醒APP 

用户A通过第三方APP分享了（任何可以分享信息的品台或工具：IM或者短信等）一条链接至用户B，用户B点开该链接后，链接会引导用户B打开指定APP或者下载指定APP。

2. APP服务化理念

      所谓APP的服务化就是利用唤醒功能将APP的特定页面做为一个单独的服务或者内容，通过一定的渠道和载体传播出去，并且能够像传统的网页链接那样被一键唤醒。

更多关于APP服务化理念，推荐大家看看这篇文章。

那么移动平台提供了哪些唤醒APP的方法呢？

3. 如何唤醒APP

目前常见的唤醒APP方式有几种：

3.1 URL Scheme

       URL Scheme是iOS，Android平台都支持，只需要原生APP开发时注册scheme， 那么用户点击到此类链接时，会自动唤醒APP，借助于URL Router机制，则还可以跳转至指定页面。比如：

<!-- 唤醒APP并跳转至指定的path页面 -->
<a href="<scheme>://<path>?<params>=<value>">打开APP</a>

<!-- JS设置iframe src跳转至指定的path页面 -->
//创建一个隐藏的iframe
var ifr = document.createElement('iframe');
ifr.src = '<scheme>://<path>?<params>=<value>';
ifr.style.display = 'none';
document.body.appendChild(ifr);
//记录唤醒时间
var openTime = +new Date();
window.setTimeout(function(){
    document.body.removeChild(ifr);
    //如果setTimeout 回调超过2500ms，则弹出下载
    if( (+new Date()) - openTime > 2500 ){
        window.location = '指定的下载页面';
    }
},2000)

这种方式是当期使用最广泛，也是最简单的，但是需要手机，APP支持URL Scheme。 

优点： 开发成本低，绝大多数都支持，web-native协议制定也简单。 

缺点： 错误处理情况因平台不同，难以统一处理，部分APP会直接跳错误页（比如Android Chrome/41，iOS中老版的Lofter）；也有的停留在原页面，但弹出提示“无法打开网页”（比如iOS7）；iOS8以及最新的Android Chrome/43 目前都是直接停留在当前页，不会跳出错误提示。 

支持情况： iOS在实际使用中，腾讯系的微信，QQ明确禁止使用，iOS9以后Safari不再支持通过js，iframe等来触发scheme跳转，并且还加入了确认机制，使得通过js超时机制来自动唤醒APP的方式基本不可用；Android平台则各个app厂商差异很大，比如Chrome从25及以后就同Safari情况一样。

3.2 Android intent

这是Android平台独有的，使用方式如下：

intent:
HOST/URI-path // Optional host 
#Intent; 
  package=[string]; 
  action=[string]; 
  category=[string]; 
  component=[string]; 
  scheme=[string]; 
end;

       这里的HOST/URI-path, 与普通http URL 的host/path书写方式相同， package是Android APP的包名，其它参数如action、category、component不是很理解, 有兴趣可以去了解官方文档。代码如下：

<!-- 唤醒APP并跳转至指定的path页面 -->
<a href="intent://<role>/<path>#Intent;scheme=<scheme>;package=com. domain;end">打开APP</a>
  •  如果手机能匹配到相应的APP，则会直接打开；
  • 如没有安装，则会跳到手机默认的应用商店，比如Google原生系统Nexus 5，将会直接跳到Google Play，对于国内各厂商定制过的系统，则跳转到各自的默认应用商店，或者弹出商店供选择。

    intent比scheme相对完善的一点是，提供一个打开失败去向URL的选项，可以通过指定参数S.browser_fallback_url来指定去向URL。比如打开APP动作，如果打开失败，则跳转到APP下载页，这对于国内的特殊网络环境，还是挺有用的。

  • Safari内置APP广告条

      在页面Head中增加如下meta， 添加智能App广告条，可以自动判断是否已安装应用，只能用于Safari，在第三方应用中就不行了。

<meta"apple-itunes-app"content"app-id=myAppStoreID, affiliate-data=myAffiliateData, app-argument=myURL"

  • Android Chrome内置APP安装提示

       这个是Mobile Chrome 43 beta新加入的特性，在用户浏览某一个网站多次后，如果Chrome发现该站点有原生APP，则会提示用户下载原生APP，此项特性开发者无法干预，完全是Google的推荐行为。

3.3 Universal Links

       在2015年的WWDC大会上，Apple推出了iOS 9的一个功能：Universal Links通用链接。如果你的App支持Universal Links，那就可以访问HTTP/HTTPS链接直接唤起APP进入具体页面，不需要其他额外判断；如果未安装App，访问此通用链接时，可以一个自定义网页。

优点：

1、唯一性：不像自定义的scheme，因为它使用标准的HTTP/HTTPS链接到你的web站点，所以它不会被其它的APP所声明。另外，URL scheme 因为是自定义的协议，所以在没有安装APP的情况下是无法直接打开的，而Universal Links本身是一个HTTP/HTTPS链接，所以有更好的兼容性；

2、安全：当用户的手机上安装了你的APP，那么iOS将去你的网站上去下载你上传上去的说明文件(这个说明文件声明了APP可以打开哪些类型的http链接)。因为只有你自己才能上传文件到你网站的根目录，所以你的网站和你的APP之间的关联是安全的；

3、可变：当用户手机上没有安装你的APP的时候，Universal Links也能够工作。如果你愿意，在没有安装APP的时候，用户点击链接，会在safari中展示你网站的内容；

4、简单：一个URL链接，可以同时作用于网站和APP，可以定义统一的web-native协议；

5、私有：其它APP可以在不需要知道是否安装了的情况下和你的APP相互通信；

缺点：

        只支持iOS9及以上系统；当使用Universal Link打开APP之后，状态栏右上角会出现链接地址，点击它会取消Universal Link，需引导用户重新使用Safari再次打开该链接，弹出Safari内置APP广告条，再点击打开重新开启Universal Link。

4. iOS9开启Universal Links

        首先，你必须有一个域名，且这个域名的网站需要支持https，然后拥有网站的上传到.well-known目录的权限（这个权限是为了上传一个Apple指定的文件apple-app-site-association），有了这个先决条件才能够继续下面的步骤：

1、创建一个json格式的命名为apple-app-site-association文件，注意这个文件必须没有后缀名，文件名必须为apple-app-site-association!!! 

{
    "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 paths = APP支持的路径列表，只有这些指定的路径的链接，才能被APP所处理，大小写敏感。举个例子，如果你的网站是www.domain.com，你的path写的是"/support/*"，那么当用户点击www.domain.com/support/<path>?<params>=<value>，就可以唤醒APP了，相反www.domain.com/other就不会。此外Apple为了方便开发者，提供了一个网址来验证我们编写的这个apple-app-site-association是否合法有效。

2、激活Xcode工程中的Associated Domains能力，在其中的Domains中填入你想支持的域名（这里不是随便填的,是可以支持你需要的Universal Links的域名）, 必须以applinks:为前缀，例如：applinks:www.domain.comApple将会在合适的时候，从这个域名请求apple-app-site-association文件。注意：当你打开Associated Domains后，Xcode会在你的工程中添加.entitlements文件，并且登录开发者中心，可以看到Associated Domains处于Enable状态。

3、在AppDelegate里实现如下代理方法：

- (BOOL)application:(UIApplication *)application continueUserActivity:(NSUserActivity *)userActivity restorationHandler:(void (^)(NSArray *))restorationHandler {
    // NSUserActivityTypeBrowsingWeb 由Universal Links唤醒的APP
    if ([userActivity.activityType isEqualToString:NSUserActivityTypeBrowsingWeb]) {
        NSURL *webpageURL = userActivity.webpageURL;
        NSString *host = webpageURL.host;
        if ([host isEqualToString:@"yohunl.com"]) {
            //进行我们需要的处理
        } else {
            [[UIApplication sharedApplication]openURL:webpageURL];
        }
    }
    return YES;
}

至此APP已经开启Universal Links，可以通过链接唤醒APP，并跳转至指定页面了。

5. Android App Links

      在2015年的Google I/O大会上，Android M宣布了一个新特性：App Links让用户在点击一个普通web链接的时候可以打开指定APP的指定页面，前提是这个APP已经安装并且经过了验证，否则会显示一个打开确认选项的弹出框。在推动deep linking上Google和Apple可谓英雄所见略同，优缺点也大致相同，只支持Android M以上系统。

Android M开启Universal Links

开启Android App Links的方式也大致同iOS一致：

先决条件：

  • 注册一个域名

  • 域名的SSL通道

  • 具有上传JSON文件到域名的能力

  • Android Studio 1.3 Preview 及以上

  • Gradle 版本 — com.android.tools.build:gradle:1.3.0-beta3 及以上

  • 设置 compileSdkVersion 为 android-MNC 及以上

  • buildToolsVersion — 23.0.0 rc2 及以上

创建一个json格式的web-app关联文件，如assetlinks.json，上传到web端

[{
  "relation": ["delegate_permission/common.handle_all_urls"],
  "target": {
    "namespace": "android_app",
    "package_name": "example.com.puppies.app",
    "sha256_cert_fingerprints":
    ["14:6D:E9:83:C5:73:06:50:D8:EE:B9:95:2F:34:FC:64:16:A0:83:42:E6:1D:BE:A8:8A:04:96:B2:3F:CF:44:E5"]
  }
  },
  {
  "relation": ["delegate_permission/common.handle_all_urls"],
  "target": {
    "namespace": "android_app",
    "package_name": "example.com.monkeys.app",
    "sha256_cert_fingerprints":
    ["14:6D:E9:83:C5:73:06:50:D8:EE:B9:95:2F:34:FC:64:16:A0:83:42:E6:1D:BE:A8:8A:04:96:B2:3F:CF:44:E5"]
  }
}]

       其中 package_name: manifest中声明的包名。 

sha256_cert_fingerprints: 可以使用如下命令生成APP的sha256指纹签名

// keystore中持有app release keys的app路径。

// 这个路径依赖于项目设置，因此不同的app是不同的。

keytool -list -v -keystore my-release-key.keystore

      上传这个文件到服务器的.well-known/assetlinks.json，为了避免今后每个app链接请求都访问网络，安卓只会在app安装的时候检查这个文件。

1、创建一个处理App Links的activity，这个activity的目的是为了实现一种这样的机制：负责捕获与解析深度链接，同时转发用户到正确的视图。同时配置激活App Links能力，如下所示：

<activity
  android:name="com.your.app.activity.ParseDeepLinkActivity"
  android:alwaysRetainTaskState="true"
  android:launchMode="singleTask"
  android:noHistory="true"
  android:theme="@android:style/Theme.Translucent.NoTitleBar">
  
  // 此处激活 App Links
  <intent-filter android:autoVerify="true">
    // 注意yourdomain.com 与 www.yourdomain.com 被看成两个不同的域名，因此你需要为每个域名添加一对http和https
    <data android:scheme="http" android:host="yourdomain.com" />
    <data android:scheme="https" android:host="yourdomain.com" />
    <action android:name="android.intent.action.VIEW" />
    <category android:name="android.intent.category.DEFAULT" />
    <category android:name="android.intent.category.BROWSABLE" />
  </intent-filter>
</activity>

2、实现App Linksactivity的处理逻辑

public class ParseDeepLinkActivity extends Activity {
  public static final String PRODUCTS_DEEP_LINK = "/products";
  public static final String XMAS_DEEP_LINK = "/campaigns/xmas";
  
  @Override
  public void onCreate(Bundle savedInstanceState) {
    super.onCreate(savedInstanceState);
    setContentView(R.layout.main);
 
    // Extrapolates the deeplink data
    Intent intent = getIntent();
    Uri deeplink = intent.getData();
 
    // Parse the deeplink and take the adequate action 
    if (deeplink != null) {
      parseDeepLink(deeplink);
    }
  }
  
  private void parseDeepLink(Uri deeplink) {
    // The path of the deep link, e.g. '/products/123?coupon=save90'
    String path = deeplink.getPath();
 
    if (path.startsWith(PRODUCTS_DEEP_LINK)) {
      // Handles a product deep link
      Intent intent = new Intent(this, ProductActivity.class);
      intent.putExtra("id", deeplink.getLastPathSegment()); // 123
      intent.putExtra("coupon", deeplink.getQueryParameter("coupon")); // save90
      startActivity(intent);
    } else if (XMAS_DEEP_LINK.equals(path)) {
      // Handles a special xmas deep link
      startActivity(new Intent(this, XmasCampaign.class));
    }  else {
      // Fall back to the main activity
      startActivity(new Intent(context, MainActivity.class));
    }
  }
}

至此APP已经开启App Links，可以通过链接唤醒APP，并跳转至指定页面了。

后记

总结以上各种方案，唤醒能力似乎都不是很完美，从长远技术趋势来看都是Deep Links，都需要

  • 一个支持HTTPS的web站

但面对移动互联网浪潮中海量APP的唤醒能力需求，一定会有创业公司来做这件事，比如国外的HoKoLinks，国内的魔窗，是自己造轮子，还是用轮子，各有利弊。

参考：

唤醒 App 的那些事 - 开发者头条

# 前端 # p2p # 网络协议
Logo
华为开发者空间

华为开发者空间，是为全球开发者打造的专属开发空间，汇聚了华为优质开发资源及工具，致力于让每一位开发者拥有一台云主机，基于华为根生态开发、创新。

更多推荐

cover

华为云数据仓库专业级开发者认证重磅发布

avatar 华为开发者空间
cover

KubeEdge 新版本5大特性解读：更完备的节点设备能力，全新的Dashboard体验

avatar 华为开发者空间
cover

一文带你搞懂GaussDB数据库性能调优

avatar 华为开发者空间