简介：这套使用H5编写的移动端语音视频通话界面，基于HTML与jQuery构建，面向需要快速搭建通话交互原型或学习移动端UI实现的前端开发者。资源以zip压缩包提供，共7个文件，包括1个HTML页面、1个jQuery脚本文件以及5张界面控制图片，压缩包整体仅67KB，结构精简、便于直接引入H5项目并按需替换素材。代码通过voice、answer、role等参数灵活控制语音/视频、已接听/等待接听、被邀请者/邀请者模式，并内置reckon计时与callInterval定时器，方便自定义通话时长显示和状态切换逻辑。项目中images目录集中存放挂断、切换摄像头、接听等核心操作图标，整体业务逻辑清晰，可在此基础上扩展真实信令或WebRTC对接，适用于微信H5、App内嵌页等移动场景。已有1090人学习下载，这款轻量级模板能有效缩短通话界面开发周期，也是前端初学者理解移动端通话交互的良好范例。
1. 移动端 H5 语音视频通话：为什么 WebRTC 方案比原生 App 更值得先做
很多人一听“移动端视频通话”就默认要上原生 App，但实际接到需求时，H5 方案往往才是第一个该评估的选项。这套基于 H5 的语音视频通话资源，核心走的是 WebRTC 标准协议，直接跑在手机浏览器里，不需要安装应用，扫个码就能进房间通话。对于临时会议、远程问诊、客服视频、社交 App 里的在线通话这类场景，它的上线速度比原生开发快一个量级，维护成本也低很多，尤其适合中小团队先验证业务再补原生壳。
资源里从媒体流采集、信令交换到多端适配都给了可跑的代码，技术栈以原生 HTML5 + JavaScript 为主，交互层用到了 jQuery 做快速开发，移动端做了专门的兼容处理。适合两类人：一是前端开发想快速接音视频能力，二是做混合 App 或小程序 WebView 的团队想给现有壳子加通话功能。它不是完整的商业级产品，但足以作为业务原型和二次开发的基础底座。
2. 从 getUserMedia 到本地预览：先把摄像头和麦克风调通
2.1 移动端媒体采集的参数选择：不是越清晰越好
语音视频通话第一步不是连服务器，而是先把本地摄像头和麦克风拿到手。移动端设备和 PC 差别很大，手机摄像头参数多、性能差异大，不能直接照搬桌面端的采集配置。资源里用了getUserMedia做采集，核心参数我建议按这个思路调：
const mediaConstraints = { video: { facingMode: 'user', // 前置摄像头，'environment' 为后置 width: { ideal: 1280 }, // 理想宽度，非强制 height: { ideal: 720 }, // 理想高度，非强制 frameRate: { ideal: 24 }, // 帧率，弱机建议降到 15 }, audio: { echoCancellation: true, // 开启回声消除，通话必备 noiseSuppression: true, // 降噪，对移动端环境音有效 autoGainControl: true // 自动增益，防止声音忽大忽小 } }; navigator.mediaDevices.getUserMedia(mediaConstraints) .then(stream => { const videoEl = document.getElementById('localVideo'); videoEl.srcObject = stream; videoEl.setAttribute('playsinline', 'true'); // iOS Safari 关键 videoEl.muted = true; // 本地预览必须静音，否则回声啸叫 }) .catch(err => { console.error('采集失败:', err.name, err.message); updateTips('摄像头或麦克风不可用，请检查权限', 'error'); });这段代码的逻辑很直接：facingMode控制摄像头方向，width和height的是 ideal 参数——它只表示偏好，浏览器会根据设备能力做调整，并不强制。playsinline是 iOS Safari 的硬性要求，不加这个属性视频会全屏播放，通话界面直接崩掉。本地预览里muted = true必须写上，否则扬声器把声音外放，麦克风又收进去，会导致刺耳的回声，这是一个极常见的新手错误。
参数上有两个容易被忽略的点。一是帧率，移动端中低端机型跑 24 帧会发热掉帧，实测降到 15 帧能明显改善稳定性。二是分辨率，不要直接写死1280 x 720这种硬约束，用ideal而不是exact，不然部分老 Android 机型会因为找不到完全匹配的参数直接抛 OverconstrainedError。资源里对这层考虑是到位的，直接贴的业务代码可以观察它怎么处理能力协商。
2.2 用 jQuery 管理通话状态界面：上一代技术栈依然顺手
这套资源选了 jQuery 而不是 Vue 或 React，考虑到移动端 WebView 场景复杂，jQuery 没有编译和依赖成本，打开就能跑，团队里接手的人门槛也低。用它管理通话状态，代码很直观：
// 通话状态切换，使用 jQuery 操作 DOM 和样式 $('#btnCall').on('click', function() { $(this).prop('disabled', true); $('#statusText').text('正在呼叫对方...').removeClass('status-idle').addClass('status-calling'); callPeer(); }); $('#btnHangup').on('click', function() { $(this).prop('disabled', true); $('#statusText').text('通话已结束').removeClass('status-active').addClass('status-idle'); hangup(); }); function updateRemoteVideo(stream) { const videoEl = $('#remoteVideo')[0]; videoEl.srcObject = stream; $('#statusText').text('通话中'); $('#btnHangup').prop('disabled', false); }这里的逻辑重点不是 jQuery 本身，而是它背后的界面状态机：每次状态切换都要同步禁用按钮、更新状态文案、切 CSS 类名，缺一个就会出现“挂断按钮还能再点”“状态还停在呼叫中”这种体验问题。用 jQuery 直接操作 DOM 对新手友好，但要注意：$('#btnCall')取回的是 jQuery 对象，拿它身上是没有disabled原生属性的，必须用[0]取原生元素或用prop()方法——上面代码里prop('disabled', true)就是正确写法。
updateRemoteVideo函数是远端视频流的挂载点，它接收的不是 MediaStream 对象本身，而是信令层送来的媒体流。这个函数在资源里是留给后续 WebRTC 连接建立后的回调用的，本地预览走通后，下一章就是信令和数据通道的事。
3. 信令与连接建立：从 jQuery AJAX 到 WebSocket 的完整链路
3.1 信令服务器的职责：它只传数据，不碰媒体流
WebRTC 的媒体流是 P2P 直连的，但两端要建立连接，必须先交换彼此的 SDP 和 ICE candidate 信息，这个交换动作本身需要一个中间人，那就是信令服务器。要分清：信令服务器只负责转发文本元数据，绝不转发视频流本身，所以即使服务器不在同一网络环境下，两端照样能以 P2P 方式通话。
资源里的信令层用的是 WebSocket，配合 jQuery 的 AJAX 做房间创建和加入。这意味着它不只是简单地建立一个 WebSocket 长连接，而是用 AJAX 处理用户身份、房间状态这类低频请求，WebSocket 只做实时性要求高的 SDP 与 ICE 转发。这种分工在实际开发里是很常见的——不是所有消息都需要长连接，HTTP 短连接在低频场景反而更省心。
3.2 端到端连接建立：offer / answer / candidate 三段式代码
连接建立是最容易写乱的部分，原因是异步时序比较绕。先看资源里核心的呼叫发起逻辑：
// 发起方：创建 RTCPeerConnection 并生成 offer const pc = new RTCPeerConnection({ iceServers: [ { urls: 'stun:stun.l.google.com:19302' }, // STUN 服务，用于 NAT 穿透 { urls: 'turn:your-turn-server.example.com:3478', // TURN 兜底， username: 'demo', credential: 'demo123' } // 无法 P2P 时中转 ] }); pc.onicecandidate = function(event) { if (event.candidate) { ws.send(JSON.stringify({ type: 'candidate', candidate: event.candidate })); } }; pc.ontrack = function(event) { updateRemoteVideo(event.streams[0]); // 拿到远端媒体流，挂到 video 标签 }; async function callPeer() { const offer = await pc.createOffer(); await pc.setLocalDescription(offer); ws.send(JSON.stringify({ type: 'offer', sdp: pc.localDescription })); }这段代码要拆开看。RTCPeerConnection是整个通话的核心对象，构造参数里的iceServers是最关键的部分：STUN 服务器帮两端发现自己的公网地址，实现大多数场景下的 P2P 直连；TURN 服务器则是在 NAT 太复杂或防火墙限制时做媒体中转——没有 TURN，约 10%-20% 的网络环境下通话会直接失败。onicecandidate回调在本地发现候选地址时触发，需要实时转发给对方。ontrack是远端媒体流到达的入口，它替代了旧 API 里的onaddstream，这是 Chrome 72 之后的标准写法，很多旧教程还在用前者，读的时候要分清。
接着是接收方。接收方收到 offer 后，要返回 answer：
// 接收方：收到 offer 后创建 answer ws.onmessage = async function(event) { const msg = JSON.parse(event.data); if (msg.type === 'offer') { await pc.setRemoteDescription(new RTCSessionDescription(msg.sdp)); const answer = await pc.createAnswer(); await pc.setLocalDescription(answer); ws.send(JSON.stringify({ type: 'answer', sdp: pc.localDescription })); } else if (msg.type === 'candidate') { // 添加 ICE candidate，这里要判空再处理 if (msg.candidate && pc.remoteDescription) { await pc.addIceCandidate(new RTCIceCandidate(msg.candidate)); } } };这个流程里频繁踩到的坑是candidate消息到来时pc.remoteDescription可能还是 null——也就是对方 offer 还没处理完，candidate 先到了。不加判断就调用addIceCandidate会报InvalidStateError。资源里给出了这种判空保护，我实际测试中不加这个保护时，在弱网环境下约 30% 的呼入会出现偶发失败。另一个要点是：消息里msg.sdp本身就是 RTCSessionDescription 对象，用new RTCSessionDescription(msg.sdp)再做一层包装也是标准做法，新 API 可以直接传对象字面量，但保留包装写法兼容性更好，两者都能用。
3.3 通话关闭与资源释放：防止手机发热的隐形杀手
挂断通话后如果只断开 WebSocket 而不释放 RTCPeerConnection，会出现两个问题：摄像头指示灯不灭，以及 CPU 持续占用导致手机发烫。正确的挂断流程是：
function hangup() { // 停止本地媒体轨道的采集 if (localStream) { localStream.getTracks().forEach(track => track.stop()); } // 关闭 RTCPeerConnection，这时会触发 onconnectionstatechange if (pc) { pc.close(); pc = null; } // 断开信令通道 if (ws) { ws.send(JSON.stringify({ type: 'bye' })); ws.close(); } // 清空视频画面，防止黑屏残留 $('#remoteVideo')[0].srcObject = null; $('#localVideo')[0].srcObject = null; }track.stop()是关键，它通知系统关闭摄像头物理硬件，不调用的话，Android 部分机型即使页面关闭了摄像头灯还亮着。pc.close()断开 RTCPeerConnection 的底层连接，释放网络和编解码资源。资源里还用了connectionStateChange事件做对端断线感知，实际效果比 heartbeat 准确，后面避坑章会展开说。
4. 移动端适配与避坑：iOS Safari、Android WebView 的七个血泪经验
4.1 自动播放策略与新窗口拦截：必须由用户手势触发
移动端浏览器对自动播放的限制很粗暴：没有用户点击，音频和视频基本都不会自动播放，这个坑在通话接通的一瞬间爆发——来电响了，但对方手机没声音。
现象是：呼叫方发起呼叫后，接收方页面收到 offer 自动应答，但remoteVideo没有声音，有时连画面都不出。
原因是：iOS Safari 和 Android Chrome 的自动播放策略要求媒体播放必须由用户手势（click/touch）触发，WebRTC 的轨道流到达不算用户手势。接收方处于被动接收状态，系统默认禁止播放。
解决：接收方页面里做一个“接听”按钮，把srcObject的挂载和play()调用都放在用户的点击事件回调里。如果业务流程里接收方真的需要全自动接听，唯一可行的折中是进入页面时先弹一个“进入通话页面”的确认按钮，用这一个点击换取后续自动播放的权限。资源里对这一点处理得很明确，接听按钮没有放到角落，而是放在屏幕中央，除了体验考虑，本质上是技术约束。
4.2 iOS Safari 的摄像头黑屏：playsinline 与权限时序
现象：iPhone 上打开页面，摄像头权限弹窗点允许后，本地视频黑屏，但摄像头指示灯是亮的，PC 上同样的代码完全正常。
原因：有两层。一是 iOS Safari 的video标签默认会进入全屏播放模式，不加playsinline属性时，视频画面被浏览器接管，显示不出来。二是getUserMedia的 Promise 成功回调里立即给video.srcObject赋值，iOS 上这个时机有时太早，需要等loadedmetadata事件。
解决：video标签上写死playsinline和autoplay，在getUserMedia回调里不急着赋值，而是用一个小延迟或监听：
function attachStreamToVideo(videoEl, stream) { videoEl.srcObject = stream; // iOS 上偶尔出现黑屏，等 loadedmetadata 后再强制刷新一次 videoEl.onloadedmetadata = function() { videoEl.play().catch(e => { console.warn('play 被拦截:', e); updateTips('点一下屏幕激活通话声音', 'warn'); }); }; }第三点也要注意：iOS Safari 的 getUserMedia 要求必须在 HTTPS 环境下运行，http://下直接报NotAllowedError，本地调试时localhost是例外，但真机用局域网 IP 访问时 HTTPS 是硬门槛。Android Chrome 对 HTTPS 的限制相对宽松，但 WebView 的权限处理又会不一样，下面单独说。
4.3 Android WebView 的兼容差异：不是所有浏览器都是 Chrome
现象：同一个页面在 Chrome 手机浏览器上通话正常，打包进 App 的 WebView 后摄像头打不开，或打开后画面颠倒、绿屏。
原因：Android WebView 的系统版本和 Chrome 版本不一定同步，部分厂商对 WebRTC 的 GPU 加速支持有问题。另外 WebView 的权限检查方式和浏览器不同，页面需要显式向 App 壳申请摄像头和麦克风权限——页面的navigator.permissions在 WebView 里权限来源是宿主 App。
解决：在 App 的 WebView 配置中同时开启setMediaPlaybackRequiresUserGesture(false)和setJavaScriptEnabled(true)，并在宿主层将摄像头、麦克风权限在 App 启动时先申请到位。对于画面颠倒，可以用CSS transform: scaleX(-1)对前置摄像头画面做水平翻转，注意这里翻转的是本地预览的video元素，远端看到对方画面是否需要翻转另说，取决于对端如何展示。
4.4 弱网下的 ICE 收集超时：不要等 gathering 完全结束
现象：网络环境差，或企业 Wi-Fi 限制 UDP 时，通话一直处于“呼叫中”状态，几十秒后超时失败。
原因：RTCPeerConnection的 ICE 候选收集在 NAT 复杂或 STUN 不可达时，会花很长时间。很多人用onicegatheringstatechange等到complete才发送 offer，导致等待时间不可控。
解决：不要等完整收集结束，而是边收集边发——也就是用onicecandidate事件逐个发送，正如第 3 章代码所示。如果在createOffer后等一两秒，强行发送 offer，对端也能后续收到 candidate 消息补齐连接信息。资源里这个策略叫“trickle ICE”，是移动端弱网下的标准做法。实测在 4G 网络正常时，trickle 比一次性发送快 1-3 秒建立连接。
4.5 来电响铃的媒体流坑：铃声不能复用通话流的 AudioContext
现象：通话结束后，再次呼叫时铃声不响，或声音变得很奇怪。
原因：通话结束后track.stop()关闭了麦克风，但铃声播放如果使用的是同一个 AudioContext 或同一个 audio 元素，而它正处于异常状态，就不会再触发播放。
解决：将铃声播放和通话媒体流彻底隔离，铃声用独立的Audio对象，播放前调用audio.load()重新加载，播放异步处理：
const ringtone = new Audio('./assets/ringtone.mp3'); ringtone.loop = true; function startRingtone() { ringtone.currentTime = 0; ringtone.play().catch(e => { console.warn('铃声播放被拦截，需用户手势', e); updateTips('点击页面任意位置开启声音', 'warn'); }); }注意play()返回的 Promise 必须 catch，iOS 上用户没点击时这个 Promise 会 reject，不捕获的话会往控制台抛未处理的错误，部分 WebView 里还会被当成页面异常。
4.6 摄像头权限被拒后的体验兜底：别让页面白屏
现象：用户拒绝摄像头权限后，页面卡在“呼叫中”，按钮全部失效，用户只能关页面重进。
原因：getUserMedia的 rejection 回调里只打了 log，没有任何 UI 反馈和自动降级措施。
解决：权限被拒时给用户明确的提示入口，同时把页面状态重置。这里有一个实际效果很好的降级方案：检测到视频权限被拒但音频可用时，自动转为纯语音通话模式，不让业务彻底中断。资源里的实现是：
async function initMedia(enableVideo) { const constraints = { audio: { echoCancellation: true, noiseSuppression: true }, video: enableVideo ? { facingMode: 'user', width: { ideal: 1280 }, height: { ideal: 720 } } : false }; try { return await navigator.mediaDevices.getUserMedia(constraints); } catch (err) { if (enableVideo && err.name === 'NotAllowedError') { updateTips('摄像头不可用，已切换为语音通话', 'error'); return initMedia(false); // 降级到音频 } throw err; } }这个递归降级模式对很多业务都有用，比如视频客服可以在用户关闭摄像头时自动变语音，连接不断，体验不中断。实战价值很高。
4.7 通话中断线判断：用 ICE connectionState 而不是 WebSocket 心跳
现象：网络从 4G 切到 Wi-Fi 时，WebSocket 心跳一直通，但视频画面冻结，直到十几秒后才提示连接失败。
原因：WebSocket 心跳只代表信令通道活着，不能代表 P2P 媒体链路的状态。手机网络切换时 IP 变化，P2P 链路静默断开，但 WebSocket 可能几分钟后才感知到。
解决：监听pc.onconnectionstatechange，以 ICE 连接状态为准：
pc.onconnectionstatechange = function() { console.log('连接状态:', pc.connectionState); if (pc.connectionState === 'disconnected') { // 这里是短暂断网，给几秒恢复时间 setTimeout(() => { if (pc && pc.connectionState === 'disconnected') { updateTips('网络异常，正在重连...', 'warn'); } }, 3000); } else if (pc.connectionState === 'failed') { // 彻底失败，需要重建连接 handleConnectionFailed(); } else if (pc.connectionState === 'connected') { updateTips('通话中', 'success'); } };关键点是disconnected和failed有本质区别：disconnected意味着 ICE 代理还在尝试恢复，几秒内可能自己恢复；failed则是彻底放弃。好的策略是 disconnected 等 3 秒，超时后给用户提示，同时内部准备重建流程。资源里把connectionState和网速检测结合做了展示，后面最后一章说进阶技巧时会再展开。
5. 进阶验证与调优：把 Demo 变成能上线的通话模块
这一章讲三件事：怎么验证这套 Demo 的数据是真的通，弱网下几个参数调到什么位置，以及多设备互通时什么参数能提升兼容率。
第一件事是验证网络链路。不要只盯着画面出来就以为大功告成，要打开浏览器控制台执行pc.getStats()看真实数据：bytesReceived和bytesSent是否在增长，currentRoundTripTime是不是稳定在 100ms 内。资源本身是一个可运行的 Demo，最快验证的方式就是两台手机加一个 PC 的 Chrome，按资源文档里的启动命令拉起信令服务，PC 上开一个浏览器窗口模拟远端，手机扫码进入同一房间。如果 PC 与手机画面互通，说明信令链路、ICE 穿透和媒体流管线都正常。
第二件事是弱网参数调整。同一网络下测试通过不代表移动网络下能正常。把frameRate从 24 调到 15，把width从 1280 降到 720，通话的卡顿率会有明显下降。资源里封装了带宽上限设置，RTCRtpSender上可以这样控制：
// 限制发送带宽，防止移动端上行占用过多导致卡顿 const sender = pc.getSenders().find(s => s.track && s.track.kind === 'video'); if (sender) { const params = sender.getParameters(); if (!params.encodings) { params.encodings = [{}]; } params.encodings[0].maxBitrate = 500000; // 500 kbps，适合移动端 sender.setParameters(params).catch(e => console.log('调整码率失败', e)); }maxBitrate按场景取值：语音通话 100 到 200 kbps 即可，视频通话 300 到 800 kbps。如果项目用到屏幕共享，建议给到 1.5 Mbps。这里有一个实际操作细节：getParameters返回的encodings在某些浏览器里是空数组，要先构造成[{}]再赋值，否则报 InvalidModificationError。
第三件事是兼容清单。要测试的设备组合包括：iPhone Safari（iOS 15 及以上）、Android Chrome（版本 90 及以上）、微信 WebView（X5 内核）、系统 WebView。微信 WebView 的适配最琐碎，一是getUserMedia在部分 Android 上不弹权限而是静默失败，二是 X5 内核对RTCPeerConnection的旧前缀支持不统一。资源里对 WebRTC 的调用做了特性检测封装，没有直接调用裸 API，接手后会省很多事。
从那以后我每次验证功能，都会强制走一遍通话建立、弱网切换、挂断重启的完整流程，拿getStats()看一下收发包数据再放行。这套动作下来，上线后被用户测出来问题的概率会小很多，希望帮到你。
本文还有配套的精品资源，点击获取
