思维导图

直接上图，下面详细讲解网页.png

步骤解析

加载网页后的第一步就是环境判断，根据业务需求我分了以下四类

这里没有专门去考虑平板等特殊设备

先讲一下通俗方案。

其实网页唤醒app有很多解决方案，具体可以看我之前的文章，在这里我分别使用的是ios端的universal link以及Android端的url scheme。

上面是方案，那么下面就是具体实现：

这套方案是苹果自己推出的，其实现效果为已安装的应用直接唤醒app，未安装的应该打开我们配置的网站。

那么我们要做的就是通过是否打开我们的网址来判断用户是否唤醒成功，也就是说用户是否安装我们的app。

相应的，我们只需要在唤醒网址页面预埋js函数，如果用户访问那么代表用户未安装，这时候我们通过js直接打开app store应用详情页

url scheme并不是Android独有的方案，只不过我们在安卓中使用了此方案。

与ios差不多，如果用户安装了app，那么网页会唤醒app，不过在首次唤醒的时候会有个弹框提示你是否允许唤醒。

那么未安装app，这套方案就会无效，所以我们的处理方法就是通过判断调用这个方法后的多少毫秒内，网页是否被切换到后台为依据，来判断是否唤醒成功。

如果调用后页面没有被切换到后台，我们就当唤醒失败用户没有安装app，此时主动访问下载地址，唤醒下载即可。

当然了，能看出来这套方案并不是完美的。

说完浏览器通用方案，接下来说一下微信浏览器的方案。

其实在此类业务场景中，大部分流量都是通过微信分享来导流的，微信的使用场景相比于浏览器频率要高很多。

那么前面也提到了，微信的开放标签并不是必须的，只不过是微信给我们提供的一种方案，如果不使用微信的方案，在微信浏览器中，上述ios的universal link是可以继续使用的。

但是Android的方案则行不通了，因为微信因为安全的考虑禁止了很多操作，比如下载，所以我们的方案也是通用的跳转到一个专门的引导页，引导用户在浏览器打开页面，然后走之前的操作即可。

与上述方案js直接触发事件不同，微信提供的方案wx-open-launch-app需要用户主动点击来交互，所以在页面编写上面需要进行特殊处理，具体的方案可以看我之前的文章。

微信这套方案，跟所有的微信api一样，都需要在安全域名下面才能成功，所以在微信浏览器里面使用的时候，需要先判断环境，如果微信jdk调用失败，需要走上面所说的方案。

到了原生内嵌这一步，所有交互都与上面不同了，上述的交互都是为了唤醒app引流，而这里的主要功能是为了实现web与native通信交互。

这里的话就是web与native分别注入约定的事件到jsbridge，然后相互调用。

需要注意的是因为app存在迭代新旧版本兼容的问题，所以web这边需要在每次执行的时候判断app版本是否支持相应api，并且根据情况进行特殊判断。

这里面有非常多细节，比如native里面的未登录状态需要唤醒登录页、比如同一个按钮如何处理才能最好的兼容所有环境。

整体来说这是一套非常复杂的东西，在我的项目中所做的就是封装，无限封装套娃，一层一层的组件叠加，根据各种变量控制相应标签的渲染与否，最大化减少渲染节点，最大化精简组件并且复用。