分享回流调起实战-CSDN博客

分享闭环的意义

看了最近热播电视剧《创业时代》，感受了一波创业的波折、守业的艰辛。对于初创产品需求主要是：1）品牌感知，2）引导下载APP体验，追求更多的是下载量。对于已经基本成型的产品来讲需要，关注更多的是，手机生态中所提供服务使用的连贯性，追求更多的则是DAU/MAU。

从最近AppStore中APP更新频率来看，明显可以感受到现在市场对APP的重视程度。然而当下APP之间竞争激烈，好不容易吸引过来的用户不想轻易被别的APP抢走，但又想夹缝中求生存费劲形式想从别人家的APP中导流来自己APP，在这样的矛盾和糟糕环境中，分享和分享回流一直倍受老板和业界关注。

分享逻辑闭环可以拆解来看一下，如图：

APP_A 一般指的是非社交平台APP，APP_B一般是带有社交属性的APP，可以简单理解为：XXAPP跟微信的关系。现阶段微信一家独大，微信做了连接一切的事情，被公认为是传播最有效的渠道。各家也是想法设法充分利用好这个平台。

上图中两个虚线框，按照需求关系『分享功能』是有较稳定的解决方案(NA有分享SDK或配置，H5可以借助NA进行功能实现)，不在本文讨论范围。『回流功能』则是需要集成大前端（FE\Android\Ios）所有力量进行攻破的课题。

Native现状梳理

调起APP方案梳理

场景	调起原理	外部调用方式	下载	参数携带
Android浏览器	<data android:scheme="myscheme://" />	1. location.href="myscheme://xxx" 2. <iframe src='myscheme://xxx'>	1. location.href="myhost://xxx.apk" 2. location.href="应用市场（下表）"	URL拦截
IOS浏览器	Universal Links （IOS9+） 1. 创建apple-app-site-association 2. Xcode的capabilities配置域名信息 3. AppDelegate.m 中支持	1. 访问配置的域名(a.com) 2. 跨域访问（b.com 跳转 a.com）	location.href="itunes.apple.com/tw/app/id12…"	URL解析：userActivity.activityType.webpageURL
IOS浏览器	Scheme：- (BOOL)application:(UIApplication )app openURL:(NSURL )url	location.href="myscheme://xxx"	同上	URL拦截
微信	白名单机制 1. 白名单内的支持调起 2.其他如果在应用宝发布，可以通过应用宝间接调起	location.href="a.app.qq.com/o/simple.js…"	携带给应用宝，交给他们处理	location.href="a.app.qq.com/o/simple.js…"

Android 各大应用市场Scheme

平台	sheme	正则
小米	mimarket://details?id=xxx&back=true	/\(.Android.(MI\|Mi\|Redmi\|HM NOTE\| 201\d{4} Build).)\|Android.XiaoMi/
sumsung	samsungapps://ProductDetail/xxxx	/\(.Android.(SAMSUNG\|SM-\|GT-).*)/
华为	appmarket://details?id=xxxx	/\(.Android.(HUAWEI\|HONOR\|HW-
oppo	oppomarket://details?packagename=xxxx	/Android.(OPPO\|A31.? Build\|R\d+(Plus)? Build)\|Android.OppoBrowser\|^OPPO/
vivo	vivomarket://details?id=xxxx	/\(.Android.(vivo\|VIVO).*)/

调起流程设计

说明：设计方案是按照两个域名的方案设计。A.COM 和 Universal Link(Ulink) 分别是两个不同域名

调起实战

机缘本次项目调起功能的实现，从源头深入了解并实现了调起功能，实战过程中的几个点总结起来跟大家一起分享。

微信拦截调起咋回事

2018年初，微信干了一件蛋疼的事情，Universal link进行白名单机制。之前限制了scheme开发者不得不转向Ulink方案，但是这样一来完全把微信内调起封死。如果想调起，需要进入其白名单，具体方法不得而知。

白名单Android同学反编译分析出来的，具体怎么做的如有微信同学，欢迎出来批评指正，愿听其详。

微信限制后有三个方案：

右上角三个点，浏览器打开；
跳转应用宝，连接scheme；
IOS直接跳转Appstore打开，但无法携带参数。

域名需要几个

域名是一个可选项。

无域名方案

也就是所谓的scheme方案，安卓&IOS都可以通过scheme方案来实现。

想到一个问题：如果定义自己APP的schema为一个别人APP的sheme（如wx://）它会调起谁？实战发现，会调起后安装的APP。如此使用scheme，想必会产生一系列问题。也许这是IOS使用ulink的考虑出发点。

为了不必要的冲突scheme命名还是要多考虑一层的。

单域名方案（A.com）

直接打开页面无法跳转对应的Ulink（因为iOS 9.2之后规定，Ulink必须跨域访问才能生效）。但实践证明当单域的时候，分享到微信，再次选择用浏览器打开，如果已经安装APP，会自动调起。这是比较完美的用户体验。

从别的页面跳转到当前单域名下，理论上因为IOS9+的Universal Link使得调起的用户体验更加流畅，所以理论上有一个域名，IOS配置没问题就可以调起。实战过程中遇到两个蛋疼的问题：

有些用户会长按复制URL在浏览器直接打开无法调起，无法调起；
如果恰好安装了APP，合作方页面（B.com）跳转到页面（A.com）不会看到页面直接调起，合作方一般对这种行为非常反感，因为直接跳离了他们APP。

多域名方案（A1.com & A2.com）

为了解决单域名的两个痛点，降级体验。A2.com作为Ulink的配置，先进入A1.com的页面，多一步点击操作，然后跳转A2.com页面进行后面逻辑操作。

调起是怎么请求的

iframe or location

H5调起NA的第一种模式是scheme。

不论iframe还是location，其实本质都是要发出一个scheme请求，APP可以监听到提前约定好的协议，进而启动APP。如果没安装APP，也期望不会对用户体验造成伤害。

iframe的特点是页面不会跳转，当前访问页面无感知（具体实现如下），不过遗憾的是IOS9之后就不支持了。

let last;
 
let invoke = function(scheme) {
    last = +Date.now();
    let $node = document.createElement('iframe');
    $node.style.display = 'none';
    $node.src = scheme ;
    let body = document.body || document.getElementsByTagName('body')[0];
    body.appendChild($node);
    setTimeout(function() {
        body.removeChild($node);
        $node = null;
    }, 10);
};
 
 
invoke(scheme);
setTimeout(function() {
  // 防爆点
  if (Date.now() - last < 1600) {
    location.href = unifiedDownloadURL;
  }
}, 1500);

复制代码

location的特点是history可能会发生变化，同时些特殊APP的webview发现未知协议还会跳转到一个错误页面，不过IOS如果scheme的话只能这么搞了。

所以我的结论：Android iframe & IOS src

前端跳转 or 服务端跳转

H5调起NA的另一种模式是Universal Link。

在启动服务端方案之前，设计了一版纯前端的方案。A2.com配置Ulink ，A1.com-A2.com的过程中如图，1）需要一个中间页承载，2）需要手动出发跳转下载或者定时促发，这不是用户期望看到的。

为了减少用户感知，将A2.com对应的中间页跟下载页URL打包，访问A1.com后，点击跳转A2服务端提供接口，直接302跳转对应下载ULR（当然也可以Nginx配置转发，但为了可维护性，建议写到业务中）

中间页的意义

通过上述服务端跳转来讲，也许中间页是没有存在意义的。要么调起，要么跳转下载，完全不需一个中间页。仔细想一下还是有两个弊端的：

调用复杂。抽离调起方法，但如果但业务多地方，or多业务多产品线引用的时候，就显得有点冗余。这时候如果有一个中间页，调用方只需要跳转过来即可
缺少品牌宣传。如业务初期，无外部落地页，比如一个海报加一个二维码想调起，这个时候如果没安装APP的时候，也没有品牌宣传直接引导到APPstore或者直接下载，略显强硬。这就要根据业务具体情况来看中间页存在的意义。

调起的极致化体验

二次分享

在微信中有如图的几种分享状态，第一个是APP分享后的，后面两个是对分享的再次分享的不同状态。这需要进行一些微信的配置，才能达到2图的效果。后面有机会可详细分享。

监听来源，引导回流

最近发现一些APP，从A应用跳转到B应用，B应用里会提示返回A应用的提示。跳转原理是一致的都是监听别人调起然后，调起别人，理论上都是scheme的具体应用。

判断APP是否安装

有些应用为了考虑更多的兼容性，选用上面提到的中间页方案。这个时候是立即打开？还是立即下载？如果知道应用在手机里安装的状态，对于用户体验来讲应该是较为重大的提升。可惜系统没有提供这样的接口，H5跟NA都无法准确获取。不过可以开动脑筋，利用服务端，通过对APP打开情况对设备号、登录状态、设备标识、IP等信息记录，打开下载页的时候，准确提示用户是下载还是打开。后面有机会的话常识去做一下。