1. 从零开始为什么你的小程序需要直播与通话这几年我帮不少团队做过小程序发现一个挺有意思的现象很多产品经理和技术同学一提到“实时音视频”就觉得这是个大工程是只有大厂才能玩的“高端技术”。其实真不是这样。微信小程序从2017年支持live-pusher和live-player这两个原生组件开始就已经把直播和视频通话的门槛降得非常低了。你想想一个在线教育平台老师不能和学生实时互动一个企业内训工具只能看录播一个远程客服系统只能打字发图——这体验是不是差点意思实时音视频就是那个能把产品体验从“能用”提升到“好用”甚至“爱用”的关键拼图。我见过太多案例了。比如一个做技能培训的团队早期只有图文和录播课用户完课率和复购率一直上不去。后来我们花了一周多时间给他们的小程序接入了直播和连麦功能老师可以实时答疑学员之间也能互相看到、交流整个学习氛围和效果一下子就起来了。再比如一些零售品牌用小程序直播做新品发布和带货主播和观众实时问答、抽奖转化率比传统的图文详情页高出好几倍。所以别再把直播和视频通话想成是“秀场”专属了它已经变成了提升用户参与感、构建服务闭环的标配能力。那么具体到开发层面我们到底要做什么呢简单来说就是两件事“推”和“拉”。主播或者通话的一方用live-pusher组件把手机摄像头和麦克风采集到的音视频数据编码后“推”送到云端服务器。观众或者通话的另一方用live-player组件从云端服务器实时“拉”取这些数据解码并播放出来。微信小程序已经帮你封装好了最复杂的采集、编码、解码、渲染这些底层工作你真正要操心的其实就是怎么配置好这两个组件以及如何搭建或选用一个稳定、低延时的云端“中转站”。接下来我就带你一步步把这套流程跑通从环境准备到代码实战再到性能调优把里面容易踩的坑都给你标出来。2. 环境与云服务准备选对“赛道”事半功倍在动手写代码之前咱们得先把“战场”布置好。这个战场主要就是云服务。你可以选择自己搭建一套流媒体服务器比如用开源的 nginx-rtmp-module这对于学习原理或者有特殊定制需求的团队来说是个好选择。但说实话对于绝大多数希望快速上线、稳定运营的产品来说我强烈建议直接使用成熟的云服务比如腾讯云直播、阿里云视频直播等。为什么因为你省去的是服务器运维、全球节点部署、网络优化、防盗链、流量突发应对等一系列极其繁琐且专业的工作。自己搭初期可能觉得省了点钱但后期在稳定性和扩展性上踩的坑会让你付出更多代价。以腾讯云直播为例准备工作其实非常清晰注册与开通首先你得有一个腾讯云账号并实名认证。然后在产品控制台找到“云直播”服务开通它。这个过程基本都是点按钮跟着指引走就行。创建域名与配置直播服务需要用到推流和播放域名。你需要在云直播控制台添加两个域名一个用于推流通常以push.yourdomain.com命名一个用于播放通常以play.yourdomain.com命名。添加后你需要按照指引去你的域名DNS服务商那里给这两个域名配置CNAME记录指向腾讯云给你的地址。这个步骤是为了将流量引导到腾讯云的全球加速网络上。生成推流与播放地址这是核心的一步。推流地址看起来像这样rtmp://push.yourdomain.com/live/streamname?txSecretxxxxtxTimexxxx。播放地址则有多种格式比如RTMP格式rtmp://play.yourdomain.com/live/streamname、FLV格式http://play.yourdomain.com/live/streamname.flv、HLS格式http://play.yourdomain.com/live/streamname.m3u8。这里有个关键点对于低延时要求的直播和实时通话请务必使用FLV或RTMP格式HLS格式的延迟通常在20秒以上只适合对延迟不敏感的点播回看场景。我建议你在云服务商的控制台里把“防盗链”配置也提前设置好。简单来说就是给你的推流和播放地址加上一个有过期时间的签名就像上面地址里的txSecret和txTime参数防止地址被恶意盗用产生天价流量账单。这一步虽然增加了一点生成地址的复杂度但绝对是保障安全的必要操作。准备好这些之后你就拥有了一个稳定、高可用的音视频传输“高速公路”接下来就可以专心在小程序端搞开发了。3. 直播功能实现让一个人说话千万人看见直播是小程序音视频最基础也最常用的场景。咱们的目标是让主播的画面和声音稳定、流畅地呈现在所有观众的小程序里。这里我们分主播端和观众端两步走。3.1 主播端推流配置与优化主播端的核心就是live-pusher组件。你把它想象成一个专业的摄像机加导播台集成在了小程序里。在页面的 WXML 文件中你需要这样放置它!-- 主播端页面 push.wxml -- live-pusher url{{pushUrl}} modeHD autopush enable-camera enable-mic beauty{{beautyLevel}} whiteness{{whitenessLevel}} aspect3:4 min-bitrate400 max-bitrate1000 waiting-imagehttps://your-cdn.com/waiting.png bindstatechangeonPushStateChange bindnetstatusonPushNetStatus binderroronPushError /live-pusher button bindtapstartPush开始推流/button button bindtapstopPush停止推流/button我来解释一下这些关键属性这都是我踩过坑总结出来的经验url这就是上一步你在云服务后台生成的推流地址必须填对。mode推流模式。SD标清、HD高清、FHD超清。对于大多数移动端直播HD模式在画质和流量消耗上是个不错的平衡。如果是秀场或者对画质要求极高的场景可以考虑FHD。beauty和whiteness美颜和美白级别范围一般是0-9。别小看这两个参数对提升主播特别是非专业主播的出境意愿有奇效。我一般建议默认设为3或4提供一个自然的优化效果。aspect画面宽高比。3:4是竖屏直播类似抖音9:16也是竖屏但更瘦长16:9是横屏直播。一定要根据你的产品设计来选择比例不对画面会被拉伸变形。min-bitrate和max-bitrate最小和最大码率单位kbps。这是画质和流畅度的调节阀。码率越高画质越清晰但对网络要求也越高。我设置的400和1000是个保守且通用的起步值。网络好时向1000靠拢保证清晰网络差时降到400保证不卡顿。你可以在后台监听网络状态动态调整。waiting-image推流中断或等待时显示的垫片图片。强烈建议设置一张你们产品的品牌背景图提升体验避免黑屏尴尬。在 JS 文件里你需要控制推流的开始和结束并监听各种事件// 主播端页面 push.js Page({ data: { pushUrl: rtmp://push.yourdomain.com/live/stream001, beautyLevel: 4, whitenessLevel: 3, isPushing: false }, startPush() { const pusherContext wx.createLivePusherContext(pusher); // 假设live-pusher的id是pusher pusherContext.start(); this.setData({ isPushing: true }); }, stopPush() { const pusherContext wx.createLivePusherContext(pusher); pusherContext.stop(); this.setData({ isPushing: false }); }, onPushStateChange(e) { console.log(推流状态变化:, e.detail.code, e.detail.message); // 状态码 1001: 已经连接推流服务器1002: 已经与服务器握手完毕开始推流1003: 打开摄像头成功1004: 打开麦克风成功1005: 推流动态调整分辨率1006: 推流动态调整码率1007: 网络断连且经多次重连抢救无效更多请查阅官方文档 if (e.detail.code 1007) { wx.showToast({ title: 网络断开推流失败, icon: none }); } }, onPushNetStatus(e) { // 这个回调很频繁用于监控网络状况 console.log(推流网络状态:, e.detail.info); // 如果发现视频码率videoBitrate持续远低于min-bitrate或者NET_BUSY可以提示主播检查网络 } })3.2 观众端拉流播放与体验打磨观众端相对简单核心是live-player组件。它的任务就是把云端流稳定、低延迟地播出来。!-- 观众端页面 play.wxml -- live-player src{{playUrl}} modelive autoplay object-fitcontain min-cache1 max-cache3 bindstatechangeonPlayStateChange binderroronPlayError /live-player观众端的参数配置直接决定了观众的观看体验src播放地址。记住优先使用http://.../xxx.flv这种FLV格式的地址。它在延迟、兼容性和性能上综合表现最好。mode播放模式。直播场景必须设为live。object-fit画面填充模式。contain会保持视频比例全部显示可能有黑边fillCrop会填满屏幕但可能裁剪部分画面。根据你的UI设计来选。min-cache和max-cache这是控制延迟的关键单位是秒。它代表了播放器缓冲区的大小。min-cache越小延迟越低但网络稍有波动就容易卡顿max-cache越大抗网络波动能力越强但延迟会增高。对于普通直播我实测下来min-cache1和max-cache3是个不错的平衡点能在1-3秒的延迟下提供比较流畅的体验。如果是电商秒杀、互动答题这种强实时场景可以尝试把min-cache调到0.5但要做好卡顿的心理准备。观众端的JS逻辑主要是监听播放状态处理错误比如提示“主播尚未开播”、“网络连接失败”等。// 观众端页面 play.js Page({ data: { playUrl: http://play.yourdomain.com/live/stream001.flv // 务必用FLV地址 }, onPlayStateChange(e) { const code e.detail.code; // 状态码 2001: 已经连接服务器2002: 已经连接服务器开始拉流2003: 网络接收到首个视频数据包(IDR)2004: 视频播放开始2005: 视频播放进度2006: 视频播放结束2007: 视频播放Loading2008: 解码器启动2009: 视频分辨率变化... 2103: 网络断连经重连抢救成功2104: 网络断连经重连抢救失败 if (code 2004) { console.log(视频开始播放); } else if (code 2104) { wx.showToast({ title: 拉流失败请检查网络, icon: none }); } } })把主播端和观众端的页面分别部署或者集成到你的小程序不同页面中一个基础的直播功能就跑通了。你可以让同事用两个手机分别打开一个推流一个播放亲眼看到画面出来的那一刻还是挺有成就感的。4. 实时视频通话实现让两端像面对面一样交流如果说直播是“一对多”的广播那视频通话就是“一对一”或“多对多”的实时对话。它对延迟的要求苛刻得多理想情况要控制在500毫秒以内。小程序为我们提供了live-pusher和live-player的RTC模式专门用于这种超低延时场景。4.1 RTC模式原理与地址生成RTC模式的本质是让两端直接建立低延迟的音视频通道。在实现上它和直播最大的区别在于需要两条独立的、方向相反的流。用户A不仅要推流给A的播放地址让B看还要拉取B推过来的流。所以你需要为一次通话准备两对推拉流地址。假设用户A和B要进行通话A的推流地址push_url_a(A的画面流上传到这里)A的播放地址play_url_a(B从这个地址拉取A的画面)B的推流地址push_url_b(B的画面流上传到这里)B的播放地址play_url_b(A从这个地址拉取B的画面)在云服务商的控制台你通常只需要生成一个流名StreamName比如room001_userA系统会自动给你对应的推流和播放地址。对于通话你需要生成两个流名例如room001_userA和room001_userB然后分别获取它们的推流和播放地址。关键点来了RTC模式必须使用云服务商提供的“超低延时播放地址”这种地址通常带有特殊的参数如txSecret延迟能压到400ms以下。普通的直播播放地址延迟在2-3秒根本没法用于通话。4.2 双端代码实战我们假设有一个通话房间用户A和B进入房间后都能看到自己和对方的画面。那么在每个用户的页面里都需要一个live-pusher推自己的画面和一个live-player拉对方的画面。!-- 通话页面A和B界面逻辑相同 rtc.wxml -- view classcontainer !-- 本地画面小窗 -- view classlocal-view live-pusher idlocalPusher url{{localPushUrl}} modeRTC autopush enable-camera enable-mic beauty3 aspect3:4 min-bitrate300 max-bitrate800 waiting-image/images/waiting.png bindstatechangeonLocalPushStateChange /live-pusher /view !-- 远程画面大窗 -- view classremote-view live-player idremotePlayer src{{remotePlayUrl}} modeRTC autoplay object-fitfillCrop min-cache0.1 max-cache0.5 bindstatechangeonRemotePlayStateChange /live-player /view button bindtaptoggleCamera切换摄像头/button button bindtaptoggleMic{{isMicOn ? 关闭麦克风 : 开启麦克风}}/button button bindtaphangUp挂断/button /view注意看这里的参数和直播有显著不同mode推流和播放组件都设置为RTC。这是启用低延时模式的关键。min-bitrate/max-bitrate通话场景下为了保证声音优先和流畅性视频码率不宜设置过高。我通常设置为300和800这个范围能在大多数网络下提供可接受的画质同时优先保障音频不中断。min-cache/max-cache为了极致降低延迟这里的缓存时间要设得非常小。我设的0.1和0.5秒意味着播放器只会缓冲0.1到0.5秒的数据延迟极低但对网络稳定性要求也极高。网络一抖就容易卡。JS逻辑主要负责控制组件的生命周期、事件监听和用户交互// 通话页面 rtc.js Page({ data: { localPushUrl: , // 根据当前用户角色A或B赋值例如rtmp://push.yourdomain.com/live/room001_userA remotePlayUrl: , // 根据当前用户角色赋值例如http://play.yourdomain.com/live/room001_userB.flv?txSecretxxxtxTimexxx (必须是超低延时FLV地址) isMicOn: true, localPusherContext: null, remotePlayerContext: null }, onLoad(options) { // 假设通过房间号options.roomId和用户身份options.role从后端接口获取对应的推流和播放地址 this.initStreamUrls(options.roomId, options.role); this.localPusherContext wx.createLivePusherContext(localPusher); this.remotePlayerContext wx.createLivePlayerContext(remotePlayer); }, onReady() { // 页面渲染完成后自动开始推流和播放 this.localPusherContext.start(); // remote-player autoplay属性已设置为true通常会自动播放 }, toggleCamera() { this.localPusherContext.switchCamera(); }, toggleMic() { const newStatus !this.data.isMicOn; this.localPusherContext.enableMic(newStatus); this.setData({ isMicOn: newStatus }); }, hangUp() { this.localPusherContext.stop(); this.remotePlayerContext.stop(); wx.navigateBack(); }, onLocalPushStateChange(e) { // 监听本地推流状态处理错误或网络警告 if (e.detail.code 1101) { // PUSH_WARNING_NET_BUSY wx.showToast({ title: 网络拥堵请检查网络, icon: none }); } }, onRemotePlayStateChange(e) { // 监听远程流播放状态 if (e.detail.code 2104) { // PLAY_ERROR_NET_DISCONNECT wx.showToast({ title: 对方连接断开, icon: none }); } } })在实际项目中localPushUrl和remotePlayUrl的生成和分配通常需要你的业务服务器参与。当用户加入房间时小程序端请求你的服务器服务器根据房间号和用户ID向云服务商API申请生成对应的、带签名的超低延时推流和播放地址再返回给小程序。这样才能保证安全性和灵活性。5. 性能调优与问题排查从“能用”到“好用”功能实现只是第一步要让用户体验好性能调优和问题排查必不可少。下面是我在多个项目中总结出来的常见问题和解决方案。5.1 直播延迟过高怎么办观众反馈画面慢半拍通常是延迟问题。可以从以下几个层面排查播放协议首先确认你用的播放地址是不是http-flv或rtmp格式。绝对不要用.m3u8(HLS) 地址做直播它的延迟是天生的高。播放器缓存检查live-player的min-cache和max-cache参数。如果设得太大比如默认值或更大延迟必然高。根据你的场景调整互动直播可以尝试1和3强互动场景可以尝试0.5和2。云端链路如果你用的是云服务确认是否开启了“低延迟播放”选项。有些云服务商对普通直播流和低延迟流是分开处理的。网络抖动观众自身的网络不稳定会导致播放器不断缓冲 (max-cache生效)从而增加延迟。可以引导观众检查网络或者在播放器收到PLAY_WARNING_RECONNECT警告时在UI上给予提示。5.2 主播端卡顿或画质差问题出在推流上行网络或编码设置上。监听网络状态live-pusher的bindnetstatus事件会频繁返回网络信息。重点关注videoBitrate视频码率和netSpeed网速。如果videoBitrate持续低于你设置的min-bitrate说明网络无法支撑最低画质。动态调整码率当检测到NET_BUSY(1101) 警告时可以主动调低max-bitrate甚至适当调低min-bitrate牺牲画质换取流畅。等网络恢复后再调回来。这是一个进阶优化点。美颜开销beauty和whiteness级别越高手机CPU的计算开销越大。在低端机上过高的美颜等级可能导致编码跟不上引起卡顿。建议提供开关让主播根据手机性能选择。清晰度模式确认mode设置是否过高。在弱网环境下将mode从FHD降到HD甚至SD是立竿见影的改善方法。5.3 视频通话感觉不流畅、声音断续RTC模式的核心是保音频所以当你说“不流畅”时要区分是声音问题还是画面问题。声音断续这通常是网络问题。RTC模式下音频优先级最高。如果网络丢包严重画面可能会冻结或模糊但声音会尽力保持。检查双方的网络信号强度Wi-Fi还是4G/5G尽量使用稳定的网络环境。画面卡顿、模糊码率设置过高回顾一下RTC模式下我推荐的码率是300-800kbps。如果你设成了1500甚至更高在网络波动时视频数据包大量丢失或发送不出去就会导致画面卡住然后跳帧或者编码器被迫输出极低质量的画面。把max-bitrate降到800以下试试。缓存设置过小为了超低延迟我们把min-cache/max-cache设得很小。这就像走钢丝网络稍一抖动缓冲区就空了画面就会卡。如果对延迟可以容忍到1秒左右可以适当增大缓存到0.5和1.5流畅度会显著提升。使用超低延时地址再次强调RTC通话必须使用云服务商提供的、带特殊参数的超低延时播放链接普通直播链接的延迟无法满足要求。5.4 其他常见坑点真机调试音视频功能在微信开发者工具的模拟器上是无法正常预览的必须使用真机扫码调试。这是第一铁律。用户授权首次使用摄像头和麦克风微信会弹出授权框。如果用户拒绝后续无法使用。需要在代码中处理授权失败的情况引导用户去设置页打开权限。后台运行小程序切到后台时默认会停止推流和播放以节省资源。如果需要在后台持续播放音频如直播课需要在app.json中配置requiredBackgroundModes: [audio]并在页面中管理好组件的生命周期。多实例问题一个小程序页面内同时只能存在一个live-pusher组件。但在视频通话场景一个页面内是一个live-pusher本地和多个live-player远程这是允许的。