web端唤醒本地应用并检测是否唤醒成功
web端如何唤醒本地应用——URL Protocol
web端可以通过自定义URL Protocol来调用本地的应用程序。我们只需要通过一个链接如：<a href="tencent://">打开QQ</a>或者直接在浏览器中输tencent://（tencent://为QQ的自定义URL Protocol）就能够使得浏览器去寻找注册表并打开对应的本地应用程序。
关于上面提到的注册表和为什么通过自定义URL Protocol就可以调用本地的应用程序的介绍在网上已经有很多相关的博客了，我会将一些我觉得比较详细和清晰的文章贴出来，就不详细介绍其中的原理了。
通过自定义URL协议在Web网页中启动本地应用程序
前端网页如何打开一个PC本地应用
但是，上面说到的这些都不是今天的重点，今天的重点是我们如何得知我们有没有成功唤醒本地应用。
检测是否唤醒成功
protocolcheck.js
如果你曾经再网上搜索过这个问题，那么你得到的最终解决方案大概率是他——protocolcheck.js
protocolcheck.js根据各种浏览器在通过自定义协议调用本地应用的不同反应，整理了各个浏览器对应的hacks，并通过检测用户所使用的浏览器来调用对应的hacks来检测浏览器是否有成功唤醒应用：
- Firefox：尝试在隐藏的iframe中打开处理程序，如果自定义协议不可用，则捕获异常。
- Chrome：使用window的onBlur事件检测焦点是否从浏览器中失焦。当焦点失焦时，便假定自定义协议启动了外部应用程序。
- Win 8 / Win 10中的IE和Edge：最干净的解决方案。Windows 8和Windows 10中的IE和Edge提供了一个API用于检查自定义协议处理程序的存在。
- 其他IE：各种不同的实现。值得注意的是，即使是相同的IE版本，其行为也可能不同。这意味着这些IE的hacks是最不可靠的。
虽然protocolcheck. js已经将刚刚浏览器对应的检测方法封装起来，但这些方法毕竟大多数都是hacks，并且已经有三四年没有进行更新了，随着浏览器的更新肯定会逐渐暴露出许多问题（亲测最新版的chrome和Firefox都已失效）。
显然这不是一个很好的解决方案，正当我想和产品经理去探讨这个需求的可行性时，我想到了百度网盘似乎也有类似的功能，那么百度网盘是怎么实现的呢？
百度网盘与快速登陆
通过百度网盘web端的唤醒功能一段时间的研究，我发现在唤醒过程中他会不断发送同一个请求，在唤醒成功后便不在发送，查看该请求的响应我们可以看到该请求返回了errno，request_id，status三个字段，其中，在唤醒成功时，除了唤醒成功前的最后一个请求的status为1之外，其他请求的status均为2。
image.png
image.png
而在唤醒失败时，则所有请求的status均为2。
image.png
不难判断出，百度云盘是通过web端和客户端直接通讯来判断出是否唤醒成功，但他们是如何进行通讯的呢？这个问题我们先按下不表，但这种方式又让我联想到了EN和QQ邮箱的快速登录功能，当我们启动了 QQ客户端，再去访问 QQ 邮箱登录页，页面会提示我们已经登录了的 QQ，点击即可登录。
image.png
响应内容
var var_sso_uin_list = [{ uin: 767957692, face_index: 597, gender: 1, nickname: '杜鑫', client_type: 65793, uin_flag: 8389120, account: 767957692 }];
ptui_getuins_CB(var_sso_uin_list);
这个请求返回了登录信息，并且是通过向127.0.0.1:4301获得的，那么问题来了，这个服务是谁提供的呢？
image.png
真相大白！由上面的信息我们可以判断出是QQ的客户端开启了一个HTTP Server，当浏览器打开页面时，会向这个Server发起请求来判断用户是否已经登录并返回对应的用户信息。
最终方案
前提：要唤醒的本地应用是自家开发的。
通过百度云盘和快速登录的案例，我们可以得到唤醒本地应用的最终方案：
- 通过自定义协议唤醒本地应用；
- 在本地应用启动时开启一个HTTP Server用于通知web端应用已启动；
- 通过自定义协议唤醒本地应用后，在规定的一段时间内向本地应用开启的HTTP Server进行轮询，若在这段时间内能够得到正确的响应状态，则证明应用已被唤醒，反之则认为唤醒失败。
问题看似被解决了，但我们其实还需要解决web端与本地应用的HTTP Server的跨域问题：
方案一：通过后台代理，这是百度云盘使用的方式；
方案二：通过jsonp，这是qq邮箱快速登录使用的方式；
方案一成本较高，需要加多一层代理层，并且需要想办法生成一个唯一标识来标记当前浏览器；方案二没有唯一标识的问题，但需要提前对端口号进行约定，并且有可能出现端口号被占用的情况。最终基于成本和端口被占用的概率考虑，我选择了方案二，虽然不算完美，但也算是能够满足大多数用户的需求了。
