关于小程序和webrtc。如果跟我一样是一个实用主义者，那我就简单从实用主义角度说一下我的结论：小程序搞定了手机，WebRTC拿下了PC。 如果你对技术比较感兴趣，那我们就可以从多个技术的角度去列举两者的区别，下面是一张详细对比的表格： 📷 实现原理： 小程序音视频是将腾讯视频云的 liteavsdk 嵌入到微信内部实现的，然后通过 <live-pusher> 和 <live-player> 两个标签将 SDK 内部的音视频能力开放出来。所以小程序的标签起到了开发者 API 的作用，而内部的 SDK 则是真正用来实现音视频功能。 WebRTC 由谷歌收购 GIPS 得来（这里不得不提一下，我加入腾讯时所在的第一个团队就是 QQ 团队，当时 QQ 的音视频还是购买的 GIPS 公司的产品，不过由于各种不靠谱，后来就转为自研路线了）。所以其技术被完整的保留并且加入到了 Google 的 Chrome 浏览器内核当中。而且最近苹果也已经开始在 Safari 浏览器中支持 WebRTC 的相关能力。 底层协议 小程序音视频的主要协议是目前在直播领域最为常用的 RTMP 推流协议，以及 HTTP-FLV 播放协议，这两种协议都已经有多年的沉淀而且在互联网上的资料也是汗牛充栋。 WebRTC的底层则是使用RTP和RTCP两种数据协议，其中RTP主要用于音视频数据传输，而RTCP则一般用于控制。 移动端碎片化问题 小程序音视频由于是微信统一实现的，而且微信团队每个版本都尽量要求功能对齐，否则宁可不上，所以在碎片化问题上基本不存在。 WebRTC在这里则要尴尬的多，一方面Android系统的碎片化本身让WebRTC的具体表现呈现“百花齐放”的景象，同时，iOS 目前的内嵌WebView（也就是在微信等APP里打开的各种内嵌网页）不支持WebRTC也还是个很麻烦的问题。 扩展性 小程序音视频跟随微信的版本发布，有什么问题一般是当前代码流修正，然后跟随下一个版本发布，所以一般一个功能点（比如给 pusher 加一个美颜的功能）或者一个问题点（比如不支持手势放大）从确立到最终实现（或解决）仅需要一个月的时间，而且微信APP新版本的覆盖速度也确实挺快。 相比之下，WebRTC则不是一个团队或者一家公司的问题了，因为它现在已经走标准路线，所以每一个新特性都是先确定标准，然后再推动浏览器厂商（包括苹果）进行跟随。这里面的故事就多了，时间也就更久了。 桌面浏览器 相信您已经发现，在前面几个问题的分析上，我的观点都倾向小程序音视频。确实，在目前国内的移动领域里，谷歌和苹果都不能一家说了算，真正说了算的还是微信。 但是在桌面浏览器这个部分，Chrome目前在PC浏览器市场上留到地位的存在决定了 WebRTC 的优势就很大了，开发者可以在不安装插件的情况下就可以实现自己想要的功能。 相比之下，由于没有 Chrome 的原生支持，所以如果我们要在 PC 上对接小程序音视频，就需要安装浏览器插件或者通过 wxlite://start 这样的伪协议唤起本地 exe 应用程序（类似在网页上打开 QQ 聊天窗口）。 并非零和博弈 小程序音视频和WebRTC支架并非零和博艺，双方都有自己的优势和不足，所以本着“打不过他们，就加入他们”的思路，腾讯视频云团队在2018年春节回来后，就马不停蹄地开始了小程序音视频和WebRTC互通的相关工作。 目前，需要向各位开发者汇报的是，在最新版本的微信中，小程序音视频已经可以跟WebRTC打通，目前在PC 的Chrome浏览器上就可以跟小程序进行实时音视频互通。 // to-do 当然，如果您想知道这个功能是怎么实现的，可以继续看下去： 充分了解WebRTC 就像结婚一样，既然你决定要选择另一个人作为人生下半辈子的伴侣，那你肯定会先深入地了解一下TA这个人，比如性格，脾气，爱好等各个方面。 同样，我们要想很好的将小程序音视频和WebRTC打通，那也必须要多了解一下WebRTC，这里我就说一下我对 WebRTC 这个“人” 在性格上的一些理解。 首先，她虽然长得不太好看，但很有内涵。 说WebRTC长得不好看，只是我的一种比喻，我的意思是想说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 进行功能上的对齐，我们甚至不需要修改我们在第一版中定义的接口，就可以达成这个目标： 📷 （1）<live-pusher> 的 url 接口不再传递 rtmp:// 协议的推流地址，而是传递 room:// 协议的推流地址。room:// 协议的使用方式可以参考我们的原理版文档 DOC。 （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，更适合初学者使用。

如果想将腾讯云提供的Demo换成自己的服务器，可以做以下步骤。 1. 搭建 <webrtc-room> 的服务器 1.1 这个服务器能做什么？ 点击demo里的互动课堂 <webrtc-room> 功能，您会看到一个房间列表，这个房间列表是怎么实现的呢？ 在看到视频房间列表以后，如果你要创建一个视频房间，或者进入一个其他人建好的视频房间，就需要为 <webrtc-room> 所对应的几个属性（sdkAppID、userID、userSig、roomID 和 privateMapKey）传递合法的参数值，这几个参数值怎么获取呢？ 1.2 这个服务器要怎么搭建？ 下载 webrtc_server ，这是一份 java 版本的实现，根据 README.md 中的说明就可以了解怎么使用这份源码。 1.3 服务器建好了我怎么用？ 小程序源码中，将 wxlite/config.js 文件中的 webrtcServerUrl 修改成：https://您自己的域名/webrtc/weapp/webrtc_room 小程序实现 WebRTC 能力肯定是为了跟 Chrome 浏览器进行视频通话，浏览器端的源代码可以点击 Chrome(src) 下载到，将 component/WebRTCRoom.js 文件中的serverDomain修改成：https://您自己的域名/webrtc/weapp/webrtc_room 2. 搭建 <live-room> 和 <rtc-room> 的服务器 2.1 这个服务器能做什么？ <live-room> （用于直播连麦）和 <rtc-room> （用于视频通话）都是基于腾讯云 LVB 和 IM 两个基础服务实现的扩展功能，需要一个叫做 RoomService 的后台组件配合才能运行。 2.2 这个服务器要怎么搭建？ 下载 RoomService 的 java 版本源代码，根据 README.md 中的说明就可以了解怎么使用这份源码。 2.3 服务器建好了我怎么用？ 小程序 源码中，将 wxlite/config.js 文件中的 serverUrl和 roomServiceUrl 修改成：https://您自己的域名/roomservice/ 小程序如果使用 <live-room> 和 <rtc-room> 两个标签，在 PC 端就不能用 Chrome 浏览器配对了，需要改用 WebEXE 混合解决方案。将 GitHub(WebEXE) 源码中 liveroom.html、double.html文件中的RoomServerDomain修改成:https://您自己的域名/roomservice/ 3. Wafer 零成本服务器部署方案 （Node.js） 如果您是一位资深的 Web 前端工程师，暂时找不到合适的服务器，但又想快速拥有自己的调试后台，可以使用腾讯云的 Wafer 功能进行零成本的一键部署方案（Wafer 只支持 Node.js 语言的后台代码），您需要你做的只是： step1: 下载小程序源码。 step2: 根据一键部署指引完成部署。 step3: 将 GitHub(WebEXE) 源码中 liveroom.html、double.html文件中的RoomServerDomain修改成:https://您自己的域名/roomservice/

对于小程序的音视频解决方案这块腾讯云自身能提供的方案已经很成熟了，并且场景广泛，创新和实用度都较高，具体目前我了解到包括下面六个方面吧： 1、银行证券开户 随着远程视频开户逐渐被银行、证券等行业广泛应用。应用腾讯云小程序实时音视频通信技术，无需安装App，从微信小程序快速开启实时视频认证，画质清晰、低延时，极大提升客户开户效率。 2、高端客户专属服务 针对高价值VIP客户，提供专属视频服务通道，专属顾问远程服务，1对1实时交流，逼真的音视频画面，极大提升了高端客户的便利性，保障客户隐私，为VIP客户打造实时尊贵体验。 3、远程报警 事故现场，自己身处危机，他人急需帮助。从微信小程序一键报警，迅速连通公安局，通过实时视频通信，警方实时掌控现场情况，同步引导报案人正确应对，控制事态发展，做出最正确的响应和处理。 4、远程应急指挥 突发险情或公共事件时，从微信小程序，一键连接远程应急指挥。实时回传事故现场画面，中央指挥室中同步分析和决策。实时对现场应急响应与部署，控制事态发展，将损失降低到最小。 5、在线游艺 通过微信小程序实现随时随地在线抓娃娃，玩家可远程控制娃娃机，运用腾讯云的直播解决方案，将抓娃娃过程直播出去，观众在观看的同时能够进行实时文字和音视频互动。极大的增强了抓娃娃的趣味性。 6、在线医疗 应用腾讯云为小程序提供的实时音视频能力，突破医疗资源在地域上的限制，为医生和患者建立视频沟通渠道。实现远程多方视频会诊，极大降低了会诊的时间和成本，让每一个人享受到优质的医疗服务。 image.png

问下 node 版本是多少 这个应该是执行 configureProject.js 报错导致拷贝文件缺失 这个拷贝没成功 static 下面缺少压缩包导致的

微信小程序开放平台-开发设置-业务域名注册进行设置

TypeError: e.publishResultCodeManager 上传的流类型错误，请配置下上传pushell

汇款到绑定的商户号，会自动结算到银行卡，提现后退款会从账户中退款，如商户余额不足则失败。

看看是不是小程序违规被封禁了

不能

1、同时关闭摄像头和麦克风，是没有上行流的，小程序是获取不到远端流的 2、黑屏的问题麻烦提供一下黑屏的sdkappid、userid、roomid和时间点我们排查下

应该是sdk升级咯，然后解码失败。请查阅最新的文档console控制台中的升级指引操作

可以啊

不可以

把小程序和商户关联起来，支付的时候用同一个商户就行了。目前同主体商户号应该没有上限，但是如果在一个支付服务商下是最多5个。

从修改平台进入才能修改，如果全网发布审核中的话等返回结果后再修改。

您好，可以在微信小程序开发中使用以下代码获取屏幕的宽度和高度： wx.getSystemInfoSync().windowWidth // 获取屏幕宽度 wx.getSystemInfoSync().windowheight // 获取屏幕高度

清除开发者工具缓存刷新再试！

指定用户录制（已经支持的平台） 支持iOS、Android、Windows、Mac、Electron等终端发起录制控制，暂不支持由 Web 浏览器和微信小程序端发起控制。

非常抱歉，目前小程序和web端都没有来电提示，不支持震动和响铃，后续会进行优化，请您及时关注官网动态。