分享回流调起实战

分享闭环的意义

看了最近热播电视剧《创业时代》，感觉了一波创业的波折、守业的艰辛。对于初创产品需求主要是：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等信息记录，打开下载页的时候，准确提示用户是下载仍是打开。后面有机会的话常识去作一下。

总结

本人最近参与作了一个创新型APP，关于调起这块进行了全方位的了解。

关于技术选择：初期选择：IOS单域名、Android Scheme调起，服务端302分发下载链接，在分享出来的落地页上突出品牌宣传，完成调起功能。后期产品作大了，引入中间页通用方案，提供更加通用解决方案。

关于用户体验：这个社会为了利益，无奈让开发者夹缝中生存找解决方案。这无异于早些年JS的 升级过程，须要颠覆性产品不断涌现，好比腾讯、百度提出的小程序生态。这是一个须要时间的过程...持续关注。

参考文档

• 【Android】Scheme详解
• iOS9 Universal Links
• Universal Link 前端部署采坑记

欢迎留言沟通交流。若有须要转载或者引用，辛苦标注一下，互相帮助。