真机调试和开发者工具都没有问题，预览以及发体验版，进入小程序后除了tabbar页面都是空白，提示报错 [图片] 开发者工具版本[图片]

各位开发者： 微信内网页在不经过用户允许的情况下自动播放音频，会导致用户没有预期、用户体验差等问题。此外，音频自动播放可能会在用户不知情的情况下给用户带来较大的流量消耗。基于此，微信公众平台将对微信内网页自动播放音频能力进行如下调整： 自2020年04月28日起，用户打开微信内网页时将无法自动播放音频。必须在得到用户手动允许（比如触摸屏幕，单击按钮等）的情况下，才能播放音频，开发者可以提前进行适配调试。 具体的适配调试方法如下： 1、下载安装包：http://dldir1.qq.com/weixin/android/wechat_0x27000C70_1620_autoplay.apk 2、扫描二维码安装浏览器内核 [图片] 3、打开网页，点击右上方菜单，第二行最后一项禁止自动播放（注：再点一次可以变回允许自动播放） [图片] 4、退出页面，重新进入即可体验禁止自动播放的效果。 附测试用例：https://docs.qq.com/sheet/DWlduYWxhVEFkRkVa?tab=BB08J2&c=B12A0F0 微信团队 2020年03月30日

概要介绍及比较 汇总比较 技术1-java-applet 忽略权限限制 底层原理 Applet 是一种 Java 程序。它一般运行在支持 Java 的 Web 浏览器内。因为它有完整的 Java API支持,所以Applet 是一个全功能的 Java 应用程序。 Applet 程序是一个经过编译的 Java 程序，它既可以在 Appletviewer 下运行，也可以在支持 Java 的 Web 浏览器中运行。 Applet 程序可以完成图形显示、声音演奏、接受用户输入、处理输入内容等工作。 Applet 程序中必须有一个是 Applet 类的子类。<applet> 标签的属性指定了要运行的 Applet 类。width 和 height 用来指定 Applet 运行面板的初始大小。Applet 必须使用 </applet> 标签来关闭。[代码]<applet code="HelloWorldApplet.class" width="320" height="120">If your browser was Java-enabled, a "Hello, World"message would appear here.</applet>[代码] 技术2 PWA 主谷歌PWA 底层原理 P)rogressive (W)eb (A)pps在不影响主要功能的情况下，使用一些高级的CSS和JavaScript特性来提高性能或者开发效率的开发方式，PWA的P和这个想法有些类似——我可以按照常规标准来开发一个WebApp，PWA主推的能力：离线，推送，桌面访问这三个能力。在说PWA之前必须先简要PWA的核心——ServcieWorker， PWA的所提及到的所有功能都是围绕着ServcieWorker来展开，那什么是ServcieWorker：详细的解释请参照MDN或者Google Developer上面给出解释，这里先给一个大致的总结，ServiceWorker是一个单独的后台线程，不依赖于某一个WebView，它是一个Proxy，用于监听以及管理服务的请求以及返回。 ServiceWorker是运行在单独线程，在浏览器进程退出之后，ServiceWorker线程也会关闭。再次打开浏览器之后，可以通过Wake Up机制唤醒ServiceWorker线程。PWA网页和浏览器生命周期一致，浏览器进程杀掉网页也销毁了。ServiceWorker进程在网页关闭后，如果内存足够，也不会被销毁。| 技术3 app内小程序 以微信为主 底层原理 iOS 上，小程序逻辑层的 javascript 代码运行在 JavaScriptCore 中，视图层是由 WKWebView 来渲染的，环境有 iOS 12、iOS 13 等；在 Android 上，小程序逻辑层的 javascript 代码运行在 V8 中，视图层是由自研 XWeb 引擎基于 Mobile Chrome 内核来渲染的；在 开发工具上，小程序逻辑层的 javascript 代码是运行在 NW.js 中，视图层是由 Chromium Webview 来渲染的。先调用js，再回掉潜入式编程的C++。js是丢给v8支持，里面内置了两个引擎一个负责渲染一个执行js。开发者不支持使用标准的Dom API开发网页，最后的渲染工作由微信端的JS库进行操作。而微信小程序采用Virtual Dom，可以减少重绘和重排的次数，提高了页面的性能。 如果Dom API暴露给用户，虽然界面的交互和操作上更丰富，但开发者对于Dom操作的随意性反而会降低页面的性能。 部分原生能力的API使用 技术4 浏览器内小程序 以百度智能小程序为主 底层原理 待更新 区别与联系 正如上文所述，两者主要都是基于Web技术，都是为了用户体验的优化，只不过实现原理不太相同： 小程序类似传统的Hybrid架构，对渲染性能要求较高的组件,通过Native 组件来实现，以弥补传统Web页面性能上的不足。另外传统Web无法访问的本地能力，需要通过JSSDK来实现。而PWA是Web能力的增强，通过提供更多的接口和规范可以让Web应用更接近Native应用。 一、java-applet ###是什么 applet（应用小程序）applet 是一种通常由 Java 编程语言编写的程序，它是内容的组成部分，并由用户代理执行。 核心 WebAssembly，java api 参考链接 https://www.cnblogs.com/zhazhanitian/p/11211773.html https://blog.csdn.net/baidu_browser/article/details/64440238 https://www.runoob.com/java/java-applet-basics.html https://wenku.baidu.com/view/d208dbdece84b9d528ea81c758f5f61fb73628f4.html https://www.cnblogs.com/zhazhanitian/p/11211773.html 二、PWA 是什么 progressive web app： 渐进式网页应用。这是谷歌推出的 技术栈 WEB前端 核心 通过ServiceWorker 访问 cache ,所以需要注册 ServiceWorker 工作者 参考链接 https://www.cnblogs.com/fundebug/p/pwa-tutorial.html https://juejin.im/post/5a9e8ad5f265da23a40456d4| 欢迎关注我的博客：https://www.cnblogs.com/microsoft-zyl/p/13365909.html 三、微信小程序 是什么 小程序是一种全新的连接用户与服务的方式，它可以在微信内被便捷地获取和传播，同时具有出色的使用体验。 技术栈 web前端，小程序前端 参考链接 https://developers.weixin.qq.com/miniprogram/dev/framework/quickstart/ 四、抖音小程序 是什么 以字节小程序为载体，开发者可利用小程序提供的丰富基础能力完成服务搭建，在字节跳动各个 App 精准匹配用户需求，为全球 15 亿用户提供优质服务的同时，也让自身业务完成流量与转化升级。 头条小程序是一种开放能力。 技术栈 web前端，字节跳动小程序 参考链接 https://microapp.bytedance.com/docs/zh-CN/mini-app/introduction/plug-in/privacy-policy-process-guidelines 五、支付宝小程序 是什么 支付宝小程序是一种全新的开放模式，它运行在支付宝客户端，是手机应用嵌入支付宝客户端的一种方法。支付宝小程序开放给开发者更多的 JSAPI 和 OpenAPI，也可以提供给用户多样化的便捷服务。支付宝小程序可以被便捷地获取和传播，从而为终端用户提供更优的用户体验。 技术栈 小程序开发全流程知识地图 参考链接 https://opendocs.alipay.com/mini/00o5w6#相关文档 六、百度小程序 是什么 智能小程序基本开发思路类似于前端开发，调用了大量端能力，性能体验优于普通 Web 。上层架构基于 JS 开发，可以更好的辅助开发者进行开发。智能小程序为开发者提供了 MVVM 的开发方式。JS 状态的变更可以引起视图的变化，视图的变更也可以反馈到逻辑层的状态中，开发者开发更方便。 参考链接 https://smartprogram.baidu.com/docs/develop/fuctionlist/list/

通过微信自带的浏览器访问h5的webrtc页面，接收流正常，推送流刚开始正常，不到一分钟时间开始，推送的流数据中没有音频数据，视频数据正常。

概述 本文介绍了微信小程序视音视频和WebRTC的技术特征、差异等，并针对两者的技术差异分享和总结了微信小程序视音视频和WebRTC互通的实现思路以及技术方案。 关于作者 rexchang（常青）：腾讯视频云终端技术总监，2008 年毕业加入腾讯，一直从事客户端研发相关工作，先后参与过 PC QQ、手机QQ、QQ物联 等产品项目，目前在腾讯视频云团队负责音视频终端解决方案的优化和落地工作。 分别介绍一下小程序音视频和WebRTC 小程序音视频是什么？ 2017年腾讯视频云团队跟微信团队联合，将视频云 SDK 跟微信小程序整合在一起，并通过 <live-pusher> 和 <live-player> 两个标签的形式开放内部的功能。通过这两个标签，开发者可以实现在线直播、低延时监控、双人视频通话以及多人视频会议等功能 [图片] WebRTC又是什么？ WebRTC（Web Real-Time Communication），是一个支持网页浏览器进行实时语音对话或视频对话的技术，是谷歌收购 GIPS 公司而获得的一项技术，在 Chrome 浏览器上无需安装插件，通过 javascript 就可以编写实时音视频通话程序。 小程序音视频和WebRTC的区别在哪里？ 如果您跟我一样是一个实用主义者，那我就简单从实用主义角度说一下我的结论：小程序搞定了手机，WebRTC拿下了PC。 如果你对技术原理比较感兴趣，那我们就可以从多个技术的角度去列举两者的区别，下面是一张详细对比的表格： [图片] （区别一）：内部原理 小程序音视频是将腾讯视频云的 liteavsdk 嵌入到微信内部实现的，然后通过 <live-pusher> 和 <live-player> 两个标签将 SDK 内部的音视频能力开放出来。所以小程序的标签起到了开发者 API 的作用，而内部的 SDK 则是真正用来实现音视频功能。 WebRTC 由谷歌收购 GIPS 得来（这里不得不提一下，我加入腾讯时所在的第一个团队就是 QQ 团队，当时 QQ 的音视频还是购买的 GIPS 公司的产品，不过由于技术支持不能满足需求，后来我们就转为自研路线了）。所以其技术被完整的保留并且加入到了 Google 的 Chrome 浏览器内核当中。而且最近苹果也已经开始在 Safari 浏览器中支持 WebRTC 的相关能力。 （区别二）：传输协议 小程序音视频在直播场景使用了 RTMP 推流协议以及 FLV 播放协议，这两种协议都已经有多年的沉淀而且在互联网上的资料也是汗牛充栋。 小程序音视频在视频通话场景则使用了经过 UDP 改造的 RTMP 协议，相比于普通 RTMP 有更强的抗弱网能力和更低的卡顿率。 小程序音视频内核 LiteAVSDK 的抗弱网演示 WebRTC的底层则是使用RTP和RTCP两种数据协议，其中RTP主要用于音视频数据传输，而 RTCP 则用于传输控制。 （区别三）：移动端碎片化问题 小程序音视频由于是微信统一实现的，而且微信团队每个版本都尽量要求功能对齐，否则宁可不上，所以在碎片化问题上基本不存在。 相比之下，WebRTC在这里则要尴尬的多，一方面Android系统的碎片化本身让WebRTC的具体表现呈现“百花齐放”的景象，同时，iOS 目前的内嵌WebView（也就是在微信等APP里打开的各种内嵌网页）不支持WebRTC也还是个很麻烦的问题。 （区别四）：未来扩展性 小程序音视频跟随微信的版本发布，有什么问题一般是当前代码流修正，然后跟随下一个版本发布，所以一般一个功能点（比如给 pusher 加一个美颜的功能）或者一个问题点（比如不支持手势放大）从确立到最终实现（或解决）仅需要一个月的时间，而且微信APP新版本的覆盖速度也确实挺快。 相比之下，WebRTC则不是一个团队或者一家公司的问题了，因为它现在已经走标准路线，所以每一个新特性都是先确定标准，然后再推动浏览器厂商（包括苹果）进行跟随。 （区别五）： 桌面浏览器 在前面几个问题的分析上，我的观点都倾向于小程序音视频。确实，在目前国内的移动领域里，谷歌和苹果都不能一家说了算，真正说了算的还是微信。 但是在桌面浏览器这个部分，Chrome目前在PC浏览器市场上留到地位的存在决定了 WebRTC 的优势就很大了，开发者可以在不安装插件的情况下就可以实现自己想要的功能。 所以，实现同 Chrome 浏览器的音视频互通，成为了小程序音视频的一个必不可少的能力特性。 互联互通 小程序音视频和WebRTC支架并非零和博弈，双方都有自己的优势和不足，实现两者的互通就能实现 1 + 1 > 2 的效果。 PC 端 用户可以使用 Chrome 浏览器直接使用音视频能力，免去安装桌面应用程序的痛苦。 移动端 用户可以使用微信小程序直接使用音视频能力，减少安装App的等待时间。 两者结合，可以将原本局限于小应用场景下的音视频能力扩展到各行各业中。 当然，要实现互联互通，并不是特别容易，首先，我们需要对 WebRTC 协议本身有一个全面的了解： 剖析WebRTC 就像结婚一样，既然你决定要选择另一个人作为人生下半辈子的伴侣，那你肯定会先深入地了解一下TA这个人，比如性格，脾气，爱好等各个方面。 同样，我们要想很好的将小程序音视频和WebRTC打通，那也必须要多了解一下WebRTC，对其知根知底，方能和平相处。 WebRTC 的设计思路是open的 WebRTC 的接口设计一开始就尽可能把内部细节更多的暴露出来，而不是简单封装一套傻瓜式的接口。这种方案的好处是二次开发的灵活度比较高，比如您可以发现 WebRTC 的 API 可以灵活到操作很多连接细节。 但任何事情都有另一面，WebRTC的学习成本并不低，虽然Google做了很多浅显易懂的PPT来教你怎么 Getting Start，但真要完整的学进去，还是需要静下心来，慢慢啃下去。 WebRTC 有多种后台接入方案 说WebRTC喜欢迁就比人，也是一种比喻，WebRTC所支持的后台架构非常多（比如 Mixer， Mesh，Router），而且谷歌认为这些后台实现方案并不需要给出什么限制和标准，因此也就没有提供统一的后台解决方案。 这种开放式的设计思路非常好，但副作用就是实现成本高。在真刀真枪的项目落地时，没有踩坑经验的开发者就很容易被这种技术门槛挡在门外。尤其是想要将 WebRTC 真正应用到企业级解决方案中，面对录制和存档的刚性需求，就需要花费大量时间进行定制开发。 互通方案 了解到 WebRTC 的这些特点后，我们的互通方案也就比较清晰了： 首先，小程序音视频的特点是接口简单，快速上手，这是小程序的优势；而这一点恰恰是WebRTC的劣势，所以我们没有必要在小程序端为WebRTC暴露十几组接口函数，而是继续采用小程序音视频的<live-pusher> 和 <live-player> 标签来解决问题。 其次，WebRTC 的后台没有官方实现，那就意味着这里有很大的发挥空间，腾讯视频云就可以实现一套WebRTC后台并将其同小程序音视频所使用RTMP后台进行打通。简单来说，腾讯视频云要在小程序音视频和WebRTC之间充当红娘（更确切的说，应该是翻译员）的角色。 但是看过《新闻联播》里国家领导人之间谈话镜头的人都知道，这种翻译是会影响交流速度的。小程序音视频和WebRTC之间互通，中间引入一个翻译员，是不是通讯延时也就增加了？ 其实不会，因为小程序音视频和WebRTC的视频编码标准在常规应用场景中是一致的，都是H.264标准，只是音频格式不同而已。这就意味着，翻译员要做的事情很少，两边基本都能听懂对方在说什么，所以延时不会增加多少。 协议握手 下图所展示的就是腾讯视频云在小程序音视频和WebRTC互通问题上所采取的方案： [图片] （1）首先，微信端的小程序通过腾讯视频云SDK将音视频流推送到腾讯云 RTMP 服务器。 （2）其次，腾讯云 RTMP 服务器的会对音视频数据进行初步的转化处理，然后透传给腾讯视频云的实时音视频后台集群。 （3）再次，实时音视频后台会再次将数据交给一个叫做 WebRTC-Proxy 的模块，就在这里， WebRTC-Proxy 要将来自小程序音视频的音视频数据翻译成 WebRTC 理解的“语言”。 （4）最后，在PC上的Chrome浏览器，就可以通过浏览器内置的WebRTC模块跟 WebRTC-Proxy 通讯，进而看到小程序端的视频影像。 （5）上面的四个过程倒过来，就可以实现双向视频通话；而将腾讯视频云作为星型结构的中心节点，多个端（不管是小程序还是Chrome浏览器）都接入进来，那就可以形成多人音视频解决方案。 打通房间逻辑 仅仅完成了音视频数据在小程序和WebRTC之间的握手还远远不够，因为在一次成功的音视频通话背后，不仅仅是把一端的音视频数据传递到另一端这么简单，还有状态的同步和成员间的状态协同。 比如多人视频通话中，涉及到呼叫和接通的流程，其中一方如果挂断了，其他人要收到挂断的通知。同时，如果有新的参与者加入，那么其他人也要收到相应的通知。WebRTC 中有很多组件，比如 RTCPeerConnection 就负责处理网络连接中各种密密麻麻的逻辑细节。但是 WebRTC 的接口中引入的新名词非常多，对于初学者来说还是有一定的门槛，为了简化这里的逻辑，我们引入一个叫做“房间”的概念。 所谓房间（Room），就是把同时参与视频通话的各方圈在一起的一个东西。比如双人通话中，通话中的两个人 A 和 B 就可以认为在一个房间中。再比如在多人通话中，通话中的五个人（A B C D E）也可以认为是在一个房间里。 有了房间的概念，那我们就可以对刚才说的状态协同用两个简单的动作描述一下：如果有一个人加入了视频通话，那么就可以理解为他/她已经进房（EnterRoom）了；如果有一个退出了视频通话，那么就可以理解为他/她已经离开房间（LeaveRoom）了。而房间的门板上始终写着：“目前在房间里有哪几个人”。 有了房间的概念，我们就可以将小程序的两个简单的<live-pusher> 和 <live-player>标签，同 WebRTC 那一套复杂的 API 进行功能上的对齐，我们甚至不需要修改我们在第一版中定义的接口，就可以达成这个目标： <live-pusher> 标签：代表房间中的“我”。 <live-player> 标签：代表房间中的“其他人”。 内部逻辑细节 [图片] （1）<live-pusher> 的 url 接口不再传递 rtmp:// 协议的推流地址，而是传递 room:// 协议的推流地址。 （2）<live-pusher> 标签在 start 成功之后，就相当于成功进入一个 room，之后，您可以通过 onPushEvent (PUSH_EVT_ROOM_USERLIST = 1020) 事件，收到房间里还有那些人的信息。在视频通话期间，房间内各个成员的进进出出，也都会通过这个事件通知给您的小程序代码。 （3）ROOM_USERLIST 里每一项都是一个二元组（如果是 1v1 的视频通话，ROOM_USERLIST 里只会有一个人）: userid 和 playurl。 userid 代表是哪个用户， playurl 则是这个用户远程画面的播放地址。您要做的只是使用 <live-player> 标签播放这些远程画面的图像和声音而已。 （4）在 WebRTC 这一端，您可以参考我们的 webrtc API，这套 API 相对于 WebRTC 原生的 API，更适合初学者使用。 呃… 您可能会说：“你这也叫简单呀，我感觉还是要写几十行代码，能不能真的做到像一个标签一样简单呢？” 好吧，其实上面四步是我们第一个版本的接入流程，就在我们昨晚这套方案之后，小程序团队刚好推出了自定义组件的机制，于是，我们有了更好的接入方案。 能不能更简单? 如果您希望一天内就打通 webrtc 和 小程序音视频 的互通，那么我推荐您不要从零开始，因为那会耗费您太多时间去踩坑和 bugfix，推荐您直接使用我们封装好的 <webrtc-room> ，这套方案既可以帮助您完成快速接入，又能满足一定的定制需求。 另外，不要忘记在微信=>发现=>小程序=>腾讯云视频云，体验一下腾讯云官方 Demo 中的 WebRTC 互通效果哦。 [图片] <webrtc-room> 功能说明 <webrtc-room> 标签是基于 <live-pusher> 和 <live-player> 实现的用于 WebRTC 互通的自定义组件。用于实现跟 Chrome 和 App SDK 之间的视频通话功能。 版本要求 微信 6.6.6 版本开始支持。 Demo体验 (1) Chrome: 用谷歌浏览器打开 体验页面。 (2) 微信端：发现=>小程序=>搜索“腾讯视频云”，点击 视频通话 页卡，输入相同的房间号。 对接资料 源码地址 源码说明 小程序端源码 Github Chrome端源码 Github 属性定义 属性 类型 默认值 说明 template String ‘float’ 必要，标识组件使用的界面模版。 demo中内置 bigsmall，float，grid三种布局 sdkAppID String   必要，开通实时音视频服务创建应用后分配的 sdkAppID userID String   必要，用户 ID userSig String   必要，身份签名，相当于登录密码的作用 roomID Number   必要，房间号 beauty Number 0 可选， 美颜指数，取值 0 - 9，数值越大效果越明显 whiteness String 0 可选， 美白指数，取值 0 - 9，数值越大效果越明显 muted Boolean false 可选，true 静音 false 不静音 debug Boolean false 可选，true 打印推流 debug 信息 fales 不打印推流 debug 信息 bindRoomEvent Function   必要，监听 <webrtc-room> 组件返回的事件 enableIM Boolean false   可选，是否启用IM bindIMEvent Function   当IM开启时必要，监听 IM 返回的事件 aspect String 9:16 可选， 宽高比3:4, 9:16 minBitrate String 200 可选，最小码率，该数值决定了画面最差的清晰度表现 maxBitrate String 400 可选，最大码率，该数值决定了画面最好的清晰度表现 autoplay Boolean false 可选，进入房间后是否自动显示远程画面 enableCamera Boolean true 可选，开启\关闭摄像头 pureAudioPushMode Number   可选，纯音频推流模式 recordId Number   可选，自动录制时业务自定义id enableCamera Boolean true 是否开启摄像头 smallViewLeft String ‘1vw’ 小窗口距离大画面左边的距离，只在template设置为bigsmall有效 smallViewTop String ‘1vw’ 小窗口距离大画面顶部的距离，只在template设置为bigsmall有效 smallViewWidth String ‘30vw’ 小窗口宽度，只在template设置为bigsmall有效 smallViewHeight String ‘40vw’ 小窗口高度，只在template设置为bigsmall有效 waitingImg String   当微信切到后台时的垫片图片 loadingImg String   画面loading图片 操作接口 <webrtc-room> 组件包含如下操作接口，您需要先通过 selectComponent 获取 <webrtc-room> 标签的引用，之后就可以进行相应的操作了。 函数名 说明 start() 启动 pause() 暂停 resume() 恢复 stop() 停止 switchCamera() 切换摄像头 sendC2CTextMsg(receiveUser, msg, succ, fail) 发送C2C文本消息 sendC2CCustomMsg(receiveUser, msgObj, succ, fail) 发送C2C自定义消息 sendGroupTextMsg(msg, succ, fail) 发送群组文本消息 sendGroupCustomMsg(msgObj, succ, fail) 发送群组自定义消息 [代码]var webrtcroom = this.selectComponent("#webrtcroomid") webrtcroom.pause(); [代码] 事件通知 <webrtc-room> 标签通过 onRoomEvent 返回内部事件，通过 onIMEvent返回 IM 消息事件，事件参数格式如下: [代码]"detail": { "tag": "事件tag标识，具有唯一性", "code": "事件代码", "detail": "对应事件的详细参数" } [代码] 如何快速接入? 上面说了很多细节的技术原理和内部细节，如果您想要快速尝试一下，建议您阅读下面三篇文章就可以了。 一分钟跑通demo 我们准备了一个简单上手的小程序音视频Demo，输入房间号即可开始通话，这篇文章主要介绍如何把Demo快速地 run 起来。 一分钟集成组件 这篇文章主要介绍如何快速地将 <webrtc-room> 组件集成到您的小程序工程项目中。 快速调通基本功能 这篇文档就主要介绍如何二次开发了，它介绍了<webrtc-room> 中主要 API 的使用。 总结 本篇文章主要介绍了小程序音视频和Chrome浏览中重要的WebRTC技术的互通方案，希望能对您的项目开发有所帮助，期待您的反馈。

iOS 版本：14.3、14.4 微信版本：8.0.1 iOS 14.3 为WKWebView 增加WebRTC 支持：https://blog.bitsrc.io/ios-14-3-brings-webrtc-to-wkwebview-closing-gap-on-ios-accessibility-90a83fa6bda2 其它app可以成功调用，但是微信就不行。 调用的Demo：https://webrtc.github.io/samples/src/content/getusermedia/gum/ [图片] [图片] [图片] [图片]

机型：华为p40 鸿蒙2.0.0.138 微信版本：8.0.11 小程序中web-view内核版本：XWEB/3121（微信浏览器此内核同样可复现） 复现步骤： 使用web-view组件打开https://webrtc.github.io/samples/src/content/getusermedia/gum/。测试getUserMedia及video播放。必现。 XWEB/2893内核未出现此问题。 代码片段： https://developers.weixin.qq.com/s/wi5UYcms7vt9

微信端浏览的H5，发现安卓端有部分机型的内置浏览器内核不是X5而是xweb，想知道如下问题： 1、xweb内核会向X5一样，不管微信版本多么低，都会自动升级到最新的xweb内核吗？ 2、xweb内核具体对H5、css3、es5、es6的具体支持情况有没有具体文档？

我有一个自动播放音乐的h5网页, 内嵌在小程序的 webview 中, 目前, 只要是webview 打开的都没有声音, 我查看log 显示已经执行了播放, 但是没有声音, 这个问题是近期出现的,之前一直都有声音, 而且我近期没有修改过代码 目前我尝试了,在微信内置浏览器, 夸克浏览器打开都有自动播放, 唯独 小程序里面内嵌的h5页面没有声音 这是webview打开H5 [图片] 这是H5原本链接: https://vr.he29.com/d/60725f5751ca647.html

开发工具上在web-view页面内点击鼠标右键有个调试的选项 需要在真机上调试需要自行引入vconsole：https://github.com/Tencent/vConsole/blob/dev/README_CN.md

video标签中的src地址，不是视频的直接访问地址，会做一个重定向到视频访问地址；在ios，或老版本微信的x5内核中，都没有问题；新版本微信中出现有图像没有声音的情况，这个是xweb的问题吗？如何解决呢？ 把src换成视频直接访问地址的方式是可以解决的；是想问除了这种方式，有什么其他设置方式或这xweb之后升级会解决这些问题吗

在微信浏览器里开发H5时，发现Video标签的表现和X5完全不一样了~~ 看UA时，发现没有X5的Tbs标识，反而是 Mozilla/5.0 (Linux; Android 9; MI 6 Build/PKQ1.190118.001; wv) AppleWebKit/537.36 (KHTML, like Gecko) Version/4.0 Chrome/78.0.3904.62 XWEB/2353 MMWEBSDK/200401 Mobile Safari/537.36 MMWEBID/9925 MicroMessenger/7.0.14.1660(0x27000E37) Process/toolsmp NetType/WIFI Language/zh_CN ABI/arm64 WeChat/arm64 里面“XWEB/2353” 的字样和小程序文档里说明的XWeb引擎名称一致。 然后，遇到了BUG，在XWeb引擎里面，Video标签在用户手势下play了之后，在其他任意时间(经测试，延迟四五秒之后)再去play，会报错“play() can only be initiated by a user gesture.” 逻辑上说，已经在用户click手势下play过的video，应该可以任意播放了才对。 X5上是对的，但XWeb上就有这样的问题。 最后，XWeb这个引擎的BUG有单独提问对接的地方吗？

新从应用商店下载的微信，安装完成后webrtc通话的mediastream视频正常，但是没有声音了 https://webrtc.github.io/samples/src/content/peerconnection/audio/ 用这个链接可以测试，在其他浏览器可以看到audio的时间在走，但是xweb里面不动 另外，手机用数据线连接电脑也不能用chrome调试了，是xweb不支持调试了吗？