一、布景

为了节省开发成本，有时也为了能够和小程序开发同步，移动端的一些事务常常交给网页端的同学去做，原生则负责为网页端同学供给一个安稳，牢靠的WebView环境，必要时，还要给网页端同学供给一些接口，用于调用原生能力。

相信咱们关于这种混合开发的场景都非常常见。

现如今，跟着实时音视频通信的流行，WebRTC技能也会常常被用到。有时咱们期望直接在H5页面中运用WebRTC（运用自布置的stun/turn服务），往往会遇到哪些挑战？

  1. 体系WebView内核在不同的机器上体现不一致，常常带来适配噩梦，甚至无法支撑
  2. 权限问题坑较多

二、抹平设备差异

TBS内核计划

即便不是为了处理WebRTC环境问题，咱们也应该考虑为H5同学去尽量抹平WebView内核带来的差异。假如咱们有WebView sdk团队，能够运用自研的WebView内核。但除了大厂以外，很难有这方面的资源。

所以现在咱们只能借助一些免费的第三方sdk，如腾讯TBS（以前叫X5内核）

TBS免费版内核是根据chromium m89版本的，且在多年前的623xx版本就完成了对WebRTC的支撑，这有助于咱们隔离不同设备的体系WebView内核差异。

可是，我要说可是了，免费版还是有免费版的问题。

无法安稳下发的动态布置

我要给网页端同学完整的WebRTC环境

TBS的内核是动态布置的，内核文件由腾讯的服务器下发。既然是动态下发的，那就有千千万万种可能会下发失利。假如下发失利，TBS会降级到体系内核。尽管体系内核也是能够持续用的，但就无法到达抹平设备差异的目的了。

最常见的内核下载错误是-134等，官方文档给出的解释是“命中流控”。依照咱们监控的线上数据，一般时段失利率在3%左右，并且到了周末会激增，由于周五周六（18:00-21:00）属于服务器保护期，不支撑下载。

尽管动态布置的安稳性不可控，但TBS官方也并不供给免费的静态布置的计划。

还记得大明湖畔的 bugly OTA 功用吗？

上一年bugly就有过关停了免费OTA事务的先例，而今年TBS也开端推商业版了。尽管TBS现已免费了多年，但还是不排除什么时候TBS也会关停免费版，毕竟腾讯的产品，不氪金你能变强吗？

以下依然根据TBS计划来完结完成

尽管以上有这么多的危险预警，由于没有找到更为牢靠的平替计划，所以以下完成依然抛砖引玉的根据TBS计划。

假如咱们有更好的计划也能够在谈论区说下哦~

三、权限控制

权限动态请求

众所周知，Android 6.0后推出了权限的动态请求。WebRTC作为一种需求用到相机和麦克风的技能，天然逃不过权限请求。

关于体系WebView内核，来自H5的权限请求一般在WebChromeClient中回调。

webview.setWebChromeClient(new WebChromeClient(){
    // Need to accept permissions to use the camera 
    @Override public void onPermissionRequest(final PermissionRequest request) { 
        request.grant(request.getResources()); }
    }
);

但TBS阻拦了原始的WebChromeClient中onPermissionRequest回调，而是通过IX5WebChromeClientExtension的onPermissionRequest来重新封装了来自H5的权限请求回调

webview.setWebChromeClientExtension(new IX5WebChromeClientExtension() {
    // ....... 省略其他方法完成 
    @Override public boolean onPermissionRequest(String s, long l, MediaAccessPermissionsCallback mediaAccessPermissionsCallback) { 
        long allowed = 0; 
        allowed = allowed | MediaAccessPermissionsCallback.ALLOW_AUDIO_CAPTURE; 
        boolean retain = true; 
        mediaAccessPermissionsCallback.invoke(s, allowed, retain); 
        return true; 
    } 
});

其中，关于MediaAccessPermissionsCallback.invoke()

/**
* @params origin 请求权限的网页地址
* @params resouorces 请求的权限类型，位操作辨认
* @params retain 是否缓存成果，缓存后，同一个origin请求同一权限都回来此成果而不会再次回调
*/
public void invoke(String origin, long allow, boolean retain);

扩展完成

当然，出于安全合规考虑，回调中还能够做一些扩展完成：

  • 对origin进行鉴权，关于不在白名单的网址，一概直接拒绝权限
  • 动态请求权限时，弹窗奉告用户请求权限的具体用途，防止合规危险

权限静态请求

处理完动态请求的权限后，发现在一些设备上，H5端与音频相关的初始化依然会失利，最终发现是以下权限需求静态添加到AndroidManifest

<uses-permission android:name="android.permission.MODIFY_AUDIO_SETTINGS" />

三、WebRTC功用测验

完结了装备，就需求测验下以上办法是否奏效，以下供给了两个快速验证的线上工具：

ZEGO webrtc测验

地址： zegodev.gitee.io/zego-expres…

测验方法很简单，点击“开端测验”即可，测验完后，页面会奉告每一项的测验成果。

我要给网页端同学完整的WebRTC环境

Janus WebRTC Server VideoCall

地址：janus.conf.meetecho.com/videocallte…

可通过这个demo验证网页端的WebRTC视频通话

我要给网页端同学完整的WebRTC环境

总结

本文介绍了根据TBS为网页端同学供给一个完整的WebRTC支撑的实践计划，并在实践事务中落地。诚然TBS为这个计划供给了支撑，也成为了这个计划中最大的危险，但苦于没有好的平替计划，又期望能为用户供给更牢靠的服务，最终咱们选择了静静充钱氪金[doge]。

假如本文对你有协助，记得点个赞哦~