通过上述对比分析，Android使用iframe唤起，ios采用window.location.href唤起更合适一点。
进入页面直接唤起和事件驱动唤起的区别
这两种唤起场景在Android中有明显的区别，无论是iframe的方式唤起还是location.href,以小米1s的chrome为例:
| <a id="goApp" href="javascript:void(0);">点我打开APP</a> |
绑定事件 人工驱动唤起：
| //成功唤起 window.onload = function () { $('#goApp').on("click", function () { window.lib.callapp("nativeUrl");//iframe //window.location.href = nativeUrl; }); }; |
进入页面直接唤起：
| //唤起失败 window.onload = function () { window.lib.callapp("nativeUrl");//iframe //window.location.href = nativeUrl; }; |
绑定事件，js唤起
| //唤起失败 window.onload = function () { $('#goApp').on("click", function () { window.lib.callapp("nativeUrl");//iframe //window.location.href = nativeUrl; }); $('#goApp).trigger('click'); }; |
原本我以为$('#goApp).trigger('click');的方式和人工点击是一样的，而实际表现是，js触发事件的表现和页面直接跳转一样无效。
从参考的博文中看到 Android平台和各个app厂商差异很大，比如Chrome从25及以后就不再支持通过js触发（非用户点击），设置iframe src地址等来触发scheme跳转。所以js触发和直接用户点击区别还是很大的，跟音频播放的限制异曲同工吧。
最后
经过上述的测试和分析，基本敲定ios用window.location.href的方式唤起比较合适，Android用iframe唤起比较合适。我们在使用iframe唤起时，一般对唤起失败的处理是直接下载，但是这里就有一个问题，就是浏览器无法检测到唤起是否成功，即，如果我唤起成功后返回浏览器，浏览器还是会弹出下载信息，这个体验很差。当然我们也需要处理一些成功或失败的回调函数，说不定我们的场景只需要唤起而并不需要失败后的下载呢。
关于使用location.href唤起iphone手机上的原生app，跳转中间页的处理方式可能也比当前页直接处理更好一点。
以上就是本文的全部内容，希望对大家的学习有所帮助，也希望大家多多支持易采站长站。
