如何在微信中打开app

方法一：微下载链接

微下载能力不仅能够帮助开发者在微信等场景进行一键下载安装，目前已支持直接拉起应用的指定内容页，帮助开发者缩短内容触达路径，提升产品活跃和用户体验

实际的情况如下。

Android系统。
- 如果手机安装了应用宝，会先拉起应用宝，应用宝再拉起App；
- 如果没有安装应用宝，会进入应用宝的App下载页。
iOS系统。
- 进入应用宝的App应用下载页，并提示用户用浏览器打开，用户选择用浏览器打开后，如果已经安装App，会拉起App。

由此可见：该方法的缺陷是比较依赖应用宝。但是好在可以将下载与拉起App两个功能结合在一起，不需要开发者，再做这块逻辑，并且能很好的支持两端情况。

方法二：微信开放标签
这个是微信新开放的功能。刚开放不久。
参考链接 https://www.jianshu.com/p/98c914c82d59

在部分场景下，用户在微信内访问网页时需要跳转到 APP 使用完整服务，为此我们提供了“微信开放标签”以满足微信内网页跳转到 APP 的需求。微信内网页跳转 APP 功能已向全体开发者开放，当用户访问已认证服务号的 JS 接口安全域名时，可以通过“微信开放标签”打开符合条件的 APP 。

微信版本要求为：7.0.12及以上。系统版本要求为：iOS 10.3及以上、Android 5.0及以上。需要关联公众号和微信开放平台。

方法三：iOS使用Universal Links
iOS端可以使用通用链接，配置过程推荐使用由openinstall免费提供的一键拉起功能，减少不必要的操作
参考文档：iOS集成指南 - openinstall
（关于openSDK1.8.6的更新说明 | 微信开放文档）；

`uniapp使用`Universal Links前提条件

https://ask.dcloud.net.cn/article/36393  //很有必要

原文：http://www.yyyweb.com/4981.html

Schema VS Universal Link

实现参考

https://www.jianshu.com/p/860d13ace6fd
https://community.apicloud.com/bbs/thread-144727-1-1.html
https://community.apicloud.com/bbs/thread-144727-1-1.html

Deeplink相关的技术，在wap中唤起app其实应用最最广泛的并不是Universal Link，而是直接Schema跳转

location.href = 'schema://xxxx'

并且一般各大APP都会给自己做一套路由体系，这样其实可以直接在schema头后面对接路由体系，做到一行schema定位打开任意App内功能界面（我就不详细扯路由的事了）

- (BOOL)application:(UIApplication *)application openURL:(NSURL *)url sourceApplication:(NSString *)sourceApplication annotation:(id)annotation {if ([[url absoluteString] hasPrefix:@"schema://"]) {[[WKDispatcher sharedInstance] operationObjectFromRouteURL:[url absoluteString]];//路由return YES;}
}

如果单纯为了实现deeplink — 在WAP上打开App，并且传递来数据信息，定位App内的具体逻辑，那么Schema就够了，其实没必要上Universal Link，Schema相当于是很特殊的Url，他是schema://xxx这种样子，如果安装了APP才能支撑跳转这种Schema Url，如果没安装APP就没任何效果，而Universal Link则是把普通url，长http://xxx.xxx.xxx/xxx这样的Normal Url，如果安装了App，就能像Schema一样传递给App，延续App内逻辑，如果没装App，则还会继续在浏览器里跳转这个Normal Url

标题Schema的弊端

Schema无法判断是否安装App
一定会有这样的产品需求的：

如果已经安装App，则打开App
如果没有安装App，则前往下载App
浏览器实际上是没有能力判断手机里是否安装了某个App的，所以聪明的程序员们选择了讨巧的方法

try {var appSchema = 'schema://xxxx';if ($.os.ios) {location.href = openNALocation; //location.href 打开schema}else {$('body').append('<iframe src="' + appSchema + '"></iframe>'); //iFrame 打开 schema}
}catch (e) {}//延迟1000秒
setTimeout(function () {if ($.os.ios) {location.href = `https://itunes.apple.com/us/app/idxxxxxxx?mt=8`;}else {location.href = `https://xxx.xxx.xxx/xxx/xxx.apk`;//直接apk下载link}
}，1000）

首先发起跳转Schema
- 如果没安装App，会打开App失败，没效果
- 如果安装App，会成功打开App
延迟1000ms
- 如果没安装App，Schema打开失败，等1000秒后会自动跳转
- 如果安装App，App会打开，当前网页会被暂停，这延迟代码不会执行
  聪明的人会发现，这样有个风险，如果用户打开APP成功后，又手动切回浏览器，那么延迟1000ms的代码依然会执行，安卓会跳出下载apk包得提示，iOS会又再度跳到Appstore，但这个瑕疵也不是太大的问题，所以这种做法被普遍采用，运用在各种安装就跳转，不安装就下载的用户场景。

安卓这么用挺好，iOS有个讨厌的弹框

如果用户没有安装App，那么他一定会经历2个事情
- schema打开app，但是失败
- 延迟后，跳转下载App
  在第一个环节，安卓上schema打开失败，没有任何反映，也没有任何提示，一切顺利，但是iOS就不同了。

schema会弹个可恶的跳转失败的框

1504334347900
1504334347900
然后再延迟后弹跳转AppStore的框

1504334376521
1504334376521

Schema被很多App禁止，比如微信手百

Schema被广泛使用，从浏览器中唤起打开专门的App，但这并不被很多App认可，比如微信，手机百度，他们本身除了浏览网页以外有其他的使用场景，所以站在微信/手百的角度，并不希望用户为了看一些分享和内容就跳出微信/手百的App，于是这些客户端拦截了Schema，使得所有Schema都无法生效。

于是不得已，广大开发者只好针对，微信/手百，等特殊UA信息，展现出蒙层，引导用户用系统/外部浏览器打开

Universal Link 解决 Schema的弊端

开篇就说了，如果你单纯为了能让wap打开App，Schema就能做到了，Universal Link的意义则是把普通url，也赋予了能打开App的能力，而不必编写专门的Schema Url去唤起App

Schema 的2个弊端确实能通过Universal Link解决

不同于Schema，在没装App的时候，Universal Link他也是一个合法的url链接，浏览器可以正常跳转，因此不会出现在iOS上讨人厌的框

Universal Link目前还没有基于iOS的UI/WKWebView的应用进行拦截，所以目前看还是能突破微信/手百的封锁。（以后，不好说啊~）

Universal Link 开发

类似的话题，随便搜搜Universal Link能搜到一大堆，我这里就略微多啰嗦两句，一般各大教程里会反复说的，我尽量一带而过，多说点我遇到的坑

配置apple-app-association
究竟哪些的url会被识别为Universal Link，全看这个apple-app-association文件
Apple Document UniversalLinks.html

你的域名必须支持Https
域名根目录下放这个文件apple-app-association，不带任何后缀
文件为json保存为文本即可
json按着官网要求填写即可

怎么写json其实没啥可教的，满世界的文章都教你咋写了，我们看个例子，点下面的链接，你的浏览器就会自动把知乎的apple-app-association的json file给down下来

知乎的 apple-app-association 文件

划重点

有心人可能看到，知乎的Universal Link配置的是 oia.zhihu.com 这个域名，并且对这个域名下比如/answers /questions /people 等urlpath进行了识别，也就是说，知乎的universal link，只有当你访问 https://oia.zhihu.com/questions/xxxx，在移动端会触发Universal Link，而知乎正经的Urlhttps//www.zhihu.com/questions/xxx是不会触发Universal Link的，知乎为什么制作，为什么不把他的主域名配置Universal Link，这是由于Universal Link的一个大坑所致

PS.

apple-app-association 你可以看完全了知乎的json file，会发现里面也不止是 universal link
苹果的一些其他功能都和apple-app-association有关，都需要配置这个文件，增加更多json字段信息
比如Hand off 还有一些跨Web&App的分享

测试是否正确

苹果官方提供了一个网站来测试你配置的域名apple-app-association是否正常work

https://search.developer.apple.com/appsearch-validation-tool/

这个网站有点SB，就是你用他测试不通过，其实Universal Link也可能不生效的，比如我把知乎的oia.zhihu.com输入进去，他就没感应到，认为没有。我搜索的时候，发现也有人发现了这个问题，反正可以当个参考

配置iOS App工程

开发者中心证书打开Associated Domains
工程配置Associated Domains
将你apple-app-association所在域名配置进去
给你的工程像Schema的OpenUrl一样，编写App被唤醒后的处理逻辑

#pragma mark Universal Links
- (BOOL)application:(UIApplication *)application continueUserActivity:(NSUserActivity *)userActivity restorationHandler:(void (^)(NSArray * _Nullable))restorationHandler {if ([userActivity.activityType isEqualToString:NSUserActivityTypeBrowsingWeb]) {NSURL *webUrl = userActivity.webpageURL;[self handleUniversalLink:webUrl]; // 转化为App路由}return YES;
}

恩比较千篇一律，我不多说了

Universal Link的基本运作流程

APP第一次启动 or APP更新版本后第一次启动
APP向工程里配置的域名发起Get请求拉取apple-app-association Json File
APP将apple-app-association注册给系统
由任意webview发起跳转的url，如果命中了apple-app-association注册过的通用链接
打开App，触发Universal Link delegate
没命中，webview继续跳转url

在你进行apple-app-association 以及 App工程的配置之后，整个Universal Link的运作流程完全由系统控制了

Universal Link 采坑

整个Universal Link其实真要只是开发完成，完全写不了几行代码，就差不多搞定了，不过还真是踩了几个坑

跨域
前端开发经常面临跨域问题，恩Universal Link也有跨域问题，但不一样的是，Universal Link，必须要求跨域，如果不跨域，就不行，就失效，就不工作。（iOS 9.2之后的改动，苹果就这么规定这么设计的）

这也是上面拿知乎举例子的时候重点强调的一个问题，知乎为什么使用oia.zhihu.com做Universal Link？

假如当前网页的域名是 A
当前网页发起跳转的域名是 B
必须要求 B 和 A 是不同域名，才会触发Universal Link
如果B 和 A 是相同域名，只会继续在当前WebView里面进行跳转，哪怕你的Universal Link一切正常，- - 根本不会打开App

是不是不太好理解，那直接拿知乎举例子

https://www.zhihu.com/question/22914651

知乎的一般网页URL都是www.zhihu.com域名，你在微信朋友圈看到了知乎的问题分享，如果copy url 你就能看到这样的链接

微信里其实是屏蔽Schema的，但是你依然能看到大大的一个按钮App内打开，这确实就是通过Universal Link来实现的，但如果知乎把Universal Link 配在了www.zhihu.com域名，那么即便已经安装了App，Universal Link也是不会生效的。

一般的公司都会有自己的主域名，比如知乎的www.zhihu.com，在各处分享传播的时候，也都是直接分享基于主域名的url，但为了解决苹果强制要求跨域才生效的问题，Universal Link就不能配置在主域名下，于是知乎才会准备一个oia.zhihu.com域名，专为Universal Link使用，不会跟任何主动传播分享的域名撞车，从而在任何活动WAP页面里，都能顺利让Universal Link生效。

简单一句话

只有当前webview的url域名，与跳转目标url域名不一致时，Universal Link 才生效
apple-app-association 覆盖
我们业务机房的集群是大部门下几条业务线共用的，有一整套云服务系统来进行机房集群的管理，有统一的接入层进行分发。虽然是不同的产品线，不同的服务，但是共享分布式的机房进行运作的。

很多Universal Link的教学文章是这么写的

将json命名为apple-app-association 不要乱改名
将file 上传到域名所在的服务器根目录下

于是我就将我们文库的apple-app-association，上传到我准备的wenkuUniversal域名的所在机器的根目录下。（因为机房都是分布式的，所以其实就是upload的全部门下的很多机器上）

同部门另一个产品线阅读后来也开始尝试Universal Link，也要把他们写好的apple-app-association上传到他们的yueduUniversal域名所在的机器的根目录下。

因为都是同样的文件名，又因为整个事业部机器实际上是共用的，因此就发生了覆盖。

解决办法

共用同一个 apple-app-association

因为apple-app-association的具体内容里有App 的Bundle ID在，因此可以简单的把2个json file 进行merge，你的App bundle 生效你的link，我的App bundle生效我的link

但其实并不推荐，毕竟双方都要小心在更新的时候，不能覆盖对方，并且这样做也很不合理，apple-app-association也不止为universal link 一个feature工作，当面临跨app / web share 甚至hand off的时候，共用一个json file 还是有坑

接入层分发不同json file
2个产品线的link域名其实是不一样的，只不过恰巧这两个域名最重打到得机器是同一个或者说有重叠，因此产生了覆盖，完全可以将json文件保存成各自的名字，在接入层对域名进行分发

最终App也是通过Get请求去拉取apple-app-association的，只要Get到，并且ssl安全性上符合要求（强制https）就没问题

隐藏的坑：apple-app-association被覆盖后如何更新

我们线上已经work的Universal Link功能，突然有一天发现坏了，查了一圈最后查到被阅读覆盖了，那就修复呗，修复倒是没问题，问题在于修复后的universal link，用户必须重新安装一次app，才能重新work，这个太坑了啊

所以关键是需要掌握apple-app-association的更新时机，反复重新杀APP重开完全没用，删了APP重装确实有用，但不可能让用户这么去做

https://stackoverflow.com/questions/35187576/does-the-apple-app-site-association-json-file-ever-get-updated-in-app

这里解释了，每次App安装后的第一次Launch，会拉取apple-app-association，除此之外在Appstore每次App的版本更新后的第一次Launch，也会拉取apple-app-association。

也就是说，一旦不小心因为意外apple-app-association，想要挽回又让那部分用户无感，App再发一个版本就好了

Universal Link 会因为用户行为而失效
Universal Link 触发后打开App，这时候App的状态栏右上角会有文字提示来自XXApp，可以点状态栏的文字快速返回原来的AP

如果用户点了返回微信，就会被苹果记住，认为用户并不需要跳出原App打开新App，因此这个App的Universal Link会被关闭，再也无效。

想要开启也不是不行，让用户重新用safari打开，universal link的页面，然后会出现很像苹果smart bar的东西，那个东西点了后就能打开（我是看到的，我没亲自操作过）

Universal Link 业务部署

知乎的apple-app-association可以看到里面有一大堆的WAP的URL，比如/answers /questions /people等，知乎都将它一一映射到App得对应界面里，问题/回答/人详情页。这是因为知乎的WAP站和APP的功能几乎是一致的。因此知乎的Universal Link的使用方式，可以说是很经典的遵循着苹果的原始设计初衷通用链接，将wap url，变成通用url，同样的url，对应着2个跳转，web跳转/app跳转，但是他们是同一个功能。

我们产品线面临的情况不一样，我们的产品线文库，他的WAP和APP功能差异非常大，可以说除了文档阅读页/view，WAP与APP都有这个功能，其他的功能WAP是WAP的，APP是APP的，形态和场景都有明显差异。除了/view这个功能，我们可以按着通用链接的设计，将APP阅读页跳转，与WAP阅读页跳转进行统一。其他时候Universal Link对于我们业务来说就是一个更强大的Schema（突破旧Schema局限的=），他只需要跳转到APP，他没有合法的WAP Url可以让浏览器在没有安装App的情况下继续跳转。

我们的Universal Link 业务部署
我们的Universal Link就像知乎一样，没有选择我们的主域名，而是选了一个完全没在WAP上有任何页面和流量的域名，我们的apple-app-association是这么写的

{"appID": "xxxxxx.xxx.xxx.xxxxx","paths":[ "/view/*","/_iosuniversallink/*"]
},

我们的AppDelegate中具体handleUniversalLink的逻辑是这么写的

- (BOOL)handleUniversalLink:(NSURL *)url {NSURLComponents *components = [NSURLComponents componentsWithURL:url resolvingAgainstBaseURL:YES];NSString *host = components.host;if ([host isEqualToString:@"xxx.xxx.xxx"]) { //host判断，虽然没啥意义if (pathComponents.count >= 3) {//地址匹配+页面跳转NSString *router;if ([pathComponents[1] isEqualToString:@"view"]) {router = @"xxx";//生成打开APP阅读页的专属Router} else if ([pathComponents[1] isEqualToString:@"_iosuniversallink"]) {router = @"xxx";//解析出APP能识别的任意路由，}if (router && router.length > 0) {[[WKDispatcher sharedInstance] operationObjectFromRouteURL:router];//无论是阅读页路由还是任意路由，发起跳转}return YES;}}return NO;
}

可以看出来我只打开了这个域名下https://xxx.xxx.xxx/view/*和https://xxx.xxx.xxx/_iosuniversallink/*2个Universal Link Path.对没错，不像知乎那么多。

/view/* 后面的*直接是阅读页ID，用于快速生成阅读页路由，发起跳转
/_iosuniversallink/* 后面的*其实应该填写的是我们App已经设计好的路由字符串，识别出路由字符串后，发起跳转
其实可以看出来/_iosuniversallink是完全包含/view的，因为APP阅读页天然也是包含在我们的路由规则内的，只要这里有路由策略，扩展力已经足够支持任意APP页面了，因此apple-app-association只配置了2个，但是如果有计划外的特殊case，大不了更新一下，也没多大事。

为了统一WAP&APP，为了通用链接的效果
我刚才提到，我们选择的Universal Link的域名其实是一个没有实际页面的域名，也就是说https://xxx.xxx.xxx/view/*这个url，如果没安装APP因此触发WebView继续跳转原地址，会直接404。处理很简单，重定向一下

router.use('/view', function (req, res, next) {var path = req.path;res.redirect('https://wk.baidu.com/view' + path + '?st=1#1');
});

整个效果就是

跳转https://xxx.xxx.xxx/view/*
- 已安装App
  - 打开App 触发handleUniversalLink
  - 走到/view/分支，拼接阅读页路由
  - 跳转
- 未安装App
  - WebView原地跳转https://xxx.xxx.xxx/view/*
  - 命中服务器的重定向逻辑
  - 重定向到https://wk.baidu.com/view/*
  - 打开我们的WAP阅读页
    这就是为啥明明/_iosuniversallink是完全包含/view能力的，但还是要把/view/单独处理的原因，为的是实现WAP与APP的统一设计，为了通用链接这个初衷

不为了统一WAP&APP 只拿来当强化版Schema使用
同样的道理，https://xxx.xxx.xxx/_iosuniversallink/*这个url，也没有实际的页面，如果不进行重定向，也会直接返回404，因此看一眼重定向的代码

router.use(’/_iosuniversallink’, function (req, res, next) {
var redirecturl = ‘https://wk.baidu.com/topic/naiosappstore’;
res.redirect(redirecturl);
});

解释一下https://wk.baidu.com/topic/naiosappstore就是我们为iOS下载App准备的专门的WAP单页面，这个页面打开后会自动延迟500ms，发起跳转appstore

整个效果就是

跳转https://xxx.xxx.xxx/_iosuniversallink/*
- 已安装App
  - 打开App 触发handleUniversalLink
  - 走到/_iosuniversallink/分支，拼接出任意App内的界面路由
  - 跳转界面
- 未安装App
  - WebView原地跳转https://xxx.xxx.xxx/_iosuniversallink/*
  - 命中服务器的重定向逻辑
  - 重定向到https://wk.baidu.com/topic/naiosappstore
  - naiosappstore页面会延迟跳转AppStore
  - 打开AppStore下载

这个设计看起来就是完美解决了PM得需求

如果已安装App，跳转对应界面
如果没安装App，跳转App下载界面
解决了旧Schema模式下的弊端问题：
Schema无法判断是否安装App，只能采用setTimeout的Trick方式
Schema的Trick方式会有一个丑陋的错误跳转弹框
Schema无法在微信/手百等App内，打开我们自己的App

简单的说，这样设计的初衷就是，我不为了通用链接这一目的来使用Universal Link，来统一WAP&APP的URL跳转，我就为了把Universal Link当做加强版Schema来使用