Android Tech网页跳转appiOS开发

唤醒APP的那些事

2016-09-11  本文已影响20075人  zyl04401

移动互联时代，很多互联网服务都会同时具备网站以及移动客户端，很多人认为APP的能帮助建立更稳固的用户关系，于是经常会接到各种从浏览器、webview、短信、甚至是在其他APP中唤醒APP的运营需求。

运营推广场景

APP服务化理念

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

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

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

如何唤醒APP

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

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情况一样。

这是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下载页，这对于国内的特殊网络环境，还是挺有用的。

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

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

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

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

优点：

缺点：

iOS9开启Universal Links

首先，你必须有一个域名，且这个域名的网站需要支持https，然后拥有网站的上传到.well-known目录的权限（这个权限是为了上传一个Apple指定的文件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是否合法有效。

- (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，并跳转至指定页面了。

在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一致：

先决条件：
  1. 注册一个域名
[{
  "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安装的时候检查这个文件。

<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>

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，都需要

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

上一篇下一篇

猜你喜欢

热点阅读