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。

而在唤醒失败时，则所有请求的status均为2。

不难判断出，百度云盘是通过web端和用户端直接通讯来判断出能否唤醒成功，但他们是如何进行通讯的呢？这个问题我们先按下不表，但这种方式又让我联想到了EN和QQ邮箱的快速登录功能，当我们启动了 QQ用户端，再去访问 QQ 邮箱登录页，页面会提醒我们已经登录了的 QQ，点击就可登录。

响应内容

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取得的，那么问题来了，这个服务是谁提供的呢？

真相大白！由上面的信息我们可以判断出是QQ的用户端开启了一个HTTP Server，当浏览器打开页面时，会向这个Server发起请求来判断客户能否已经登录并返回对应的客户信息。

最终方案

前提：要唤醒的本地应用是自家开发的。
通过百度云盘和快速登录的案例，我们可以得到唤醒本地应用的最终方案：

1. 通过自己设置协议唤醒本地应用；
2. 在本地应用启动时开启一个HTTP Server用于通知web端应用已启动；
3. 通过自己设置协议唤醒本地应用后，在规定的一段时间内向本地应用开启的HTTP Server进行轮询，若在这段时间内能够得到正确的响应状态，则证实应用已被唤醒，反之则认为唤醒失败。

问题看似被处理了，但我们其实还需要处理web端与本地应用的HTTP Server的跨域问题：
方案一：通过后端代理商，这是百度云盘使用的方式；
方案二：通过jsonp，这是qq邮箱快速登录使用的方式；
方案一成本较高，需要加多一层代理商层，并且需要想办法生成一个唯一标识来标记当前浏览器；方案二没有唯一标识的问题，但需要提前对端口号进行商定，并且有可能出现端口号被占用的情况。最终基于成本和端口被占用的概率考虑，我选择了方案二，尽管不算完美，但也算是能够满足大多数客户的需求了。