简介VChat是一款基于Java开发的P2P视频通话Android应用面向移动端开发者与即时通讯学习者可作为理解P2P通话流程、用户列表与呼叫接听逻辑的入门项目。资源提供完整Android Studio工程和预编译APK可方便地在真机或模拟器上体验双端呼叫流程适合作为课程设计或毕业设计的参考原型。压缩包共69个文件涵盖Java源码、XML界面布局、Gradle构建配置、PNG图标素材、SO与JAR依赖库、MP3提示音等大小19.22MB工程结构清晰便于按模块查看客户端逻辑与资源组织。目前已有264人学习适合希望快速掌握Android端P2P音视频通话实现思路的开发者。通过分析项目源码及自带说明读者可了解P2P连接建立、用户在线状态管理以及来电接听等关键环节的具体写法再结合自身需求进行二次开发。 搜P2P这个词结果经常是五花八门。有人问5090显卡能不能P2P通讯有人在折腾某个播放器的P2P连接选项还有人直接把P2P和文件下载器画等号。但在视频通话这个场景里P2P的含义其实非常纯粹两个客户端之间直接建立媒体通道视频和音频数据不经服务器中转点对点直连。VChat就是围绕这个思路做的一个P2P视频通话应用——信令由一台轻量服务器负责交换媒体流走端到端直连既保留集中式架构的易管理性又拿到了直连的低延迟和低成本。这篇文章会把VChat从架构选型到信令实现、从NAT穿透到媒体协商的完整链路摊开来讲适合正在做WebRTC相关项目、被STUN/TURN和ICE搞得一头雾水、或者单纯想理解“P2P视频通话到底是怎么建立起来的”的开发者。我不打算只贴代码更想把每一步选择背后的理由说清楚因为我自己在这个项目里踩过的坑几乎全是因为“只知道怎么配不知道为什么要这样配”。1. 为什么是P2P而不是一台大服务器——VChat的架构选型逻辑1.1 中心化架构的账算不过来很多人做视频通话的第一反应是客户端把视频流推给服务器服务器再转发给对方也就是SFU或MCU方案。这个架构成熟、可控、排障方便但等你算完带宽账单大概率会重新考虑。以一路720p视频通话为例码率按1.5Mbps算。如果是服务器中转上行要收1.5Mbps下行还要再发1.5Mbps一路通话吃掉3Mbps带宽。假设同时在线100路通话就是300Mbps。云厂商的带宽费用大家都清楚按流量计费的话这成本几乎和服务器规格本身一样高。而P2P架构下媒体流直接在两个客户端之间传输服务器只交换几KB的SDP和ICE候选信息带宽成本趋近于零。这是VChat选择P2P最直接的理由。延迟是第二个理由。视频通话的交互延迟最好控制在400ms以内服务器每多一跳就会增加5到20ms的转发延迟。如果用户和服务器距离远或者服务器负载高这个数字还会膨胀。P2P直连在物理路径最短的情况下延迟是最优的。虽然实际网络中P2P不一定总比中转快但至少给了你一个“路径最短”的可能性。1.2 信令与媒体分离VChat的两条数据通道刚开始接触P2P视频通话最容易搞混的一点是既然说P2P为什么还需要服务器答案是媒体走P2P但“建立P2P连接所需的信息”必须有人帮忙交换。打个比方你要和另一个人视频但你们互相不知道对方的IP地址、用什么编解码器、期望接收什么格式的视频。这些信息就是“信令”。在VChat里信令服务器只做一件事把A端的SDP和ICE候选转发给B端再把B端的回应转回去。一旦双方拿到了彼此的地址和媒体参数媒体流就直接在两端之间流动服务器从此退出数据链路。所以VChat本质上有两条通道一条是短暂的、低带宽的信令通道走WebSocket另一条是持久的、高带宽的媒体通道走WebRTC的SRTP/DTLS。理解这个分离后面所有的代码和配置都不会跑偏。1.3 “5090可以P2P通讯吗”背后的概念澄清写代码之前我想先花点篇幅澄清一个概念问题因为我在查资料时发现很多人对P2P的理解差异极大。有人问5090能不能P2P通讯这个P2P指的是NVIDIA GPUDirect P2P也就是显卡之间通过PCIe直接交换数据绕过CPU和内存跟视频通话里的P2P完全是两码事。有人提到某些播放器软件的P2P连接那通常指的是应用层协议里的端到端通道也不一定基于WebRTC。还有一些产品把P2P连接当卖点本质上就是“不经过厂商服务器转发设备之间直接拉流”。这些说法共享同一个底层思想两端直接通信不经过中间节点。但具体到技术实现各自面对的挑战截然不同。VChat要解决的是WebRTC语境下的媒体直连问题核心是NAT穿透和媒体协商。搞清楚这一点再看后面的STUN/TURN就不会被各种概念绕晕。2. 信令服务只牵线不送信——房间管理与SDP转发2.1 信令到底在传什么信令服务传的消息种类很少核心就三类加入/离开房间的控制消息让双方知道“有人进来了”或者“有人走了”。SDP Offer/Answer媒体协商的核心载体包含音视频编解码器、传输地址、加密指纹等信息。ICE候选每个候选代表一个“可用的网络路径”通过信令通道互相交换。我第一次写VChat时犯过一个错误试图把信令做得“很完整”结果传了一堆自定义JSON。后来发现WebRTC标准流程只需要上面三类消息凡是往信令里塞业务数据的行为最后都会变成调试噩梦。信令通道保持简单和媒体通道彻底解耦这是VChat能快速跑通的关键。2.2 基于Socket.IO的信令服务实现VChat的信令服务用Node.js Socket.IO实现核心代码很短const io require(socket.io)(server, { cors: { origin: * } }); io.on(connection, (socket) { // 加入房间同一个房间内的客户端才能互相发现 socket.on(join-room, (roomId, userId) { socket.join(roomId); socket.to(roomId).emit(user-joined, userId); }); // 转发SDP offer socket.on(offer, (data) { socket.to(data.roomId).emit(offer, { from: socket.id, sdp: data.sdp }); }); // 转发SDP answer socket.on(answer, (data) { socket.to(data.roomId).emit(answer, { from: socket.id, sdp: data.sdp }); }); // 转发ICE候选 socket.on(ice-candidate, (data) { socket.to(data.roomId).emit(ice-candidate, { from: socket.id, candidate: data.candidate }); }); socket.on(disconnect, () { // 通知房间内其他用户 }); });这段代码看起来简单但已经覆盖了双人视频通话的所有信令需求。roomId用来隔离会话userId用来标识身份offer/answer/ice-candidate三个事件就是标准信令流程的全部。2.3 为什么选Socket.IO而不是裸WebSocket有人会问WebSocket原生就能发消息为什么非要用Socket.IO说下我的实测感受。第一是自动重连。视频通话场景下用户可能随时切网络Wi-Fi断了切4GWebSocket连接就会断。原生WebSocket你需要自己实现重连逻辑Socket.IO内置了指数退避重连省掉不少事。第二是房间广播。Socket.IO的socket.join(roomId)和socket.to(roomId).emit()天然支持房间概念而原生WebSocket需要自己维护连接列表。第三是事件语义。socket.on(offer)这种写法比原生WebSocket的message事件加JSON解析清晰得多。当然如果做大规模生产系统换用更底层的ws库、接入消息队列做横向扩展这些我都支持。但对一个要快速验证P2P视频通话的项目来说Socket.IO的开发效率优势太明显了。另外提醒一句信令服务如果部署在公网一定要加WSS加密否则SDP和ICE候选在网络上裸奔等于把通话的元信息暴露给中间人。3. NAT穿透没有玄学STUN、TURN、ICE的实战落地3.1 大多数用户都在NAT后面三种候选地址真实网络环境里绝大多数设备并不拥有公网IP而是躲在路由器NAT后面。A设备想直接连B设备首先要回答一个问题我怎么找到你这就是ICEInteractive Connectivity Establishment协议的工作。ICE会收集三种候选地址候选类型来源通俗理解host 候选本机网卡地址你家的门牌号但只有内部网络可见srflx 候选STUN服务器反射地址路由器NAT后的公网映射地址相当于你告诉别人“我在小区门口等你”relay 候选TURN服务器中继地址绕路方案把所有数据交给中转站转发WebRTC内部会为每种候选计算优先级公式大致是2^24 × (65535 - 类型优先级)总之host优先、srflx次之、relay兜底。两个端各自把候选列表通过信令通道交换给对方然后互相做连通性检查选出一条可用路径。我在VChat里最常见的情况是两个用户在同一局域网或者不同的对称NAT之后最后实际使用的路径可能完全不同。ICE的价值就在于它不会只试一条路而是把所有可能性都试一遍选最优的那条。3.2 STUN只能解决一半问题STUN的作用是帮客户端发现自己经过NAT映射后的公网地址和端口。客户端向STUN服务器发一个请求STUN服务器看到请求的来源IP:端口把这个地址返回给客户端这个地址就是srflx候选。但STUN有一个致命盲区它只适用于锥形NAT。如果你的NAT是对称NAT——每次向同一目的地址发包映射出的公网端口都不同——那STUN返回的地址就只能用于和STUN服务器的通信无法用于和另一个客户端通信。实际上很多移动网络就是对称NAT所以只搭STUN服务器远远不够。VChat在开发初期只配了STUN结果在办公室Wi-Fi下一切正常换到4G网络就完全打不通。排查到最后发现不是代码问题而是STUN在这个网络场景下根本解决不了穿透。这个教训让我理解了为什么TURN不是可选项而是必选项。3.3 TURN兜底与coturn部署TURN的本质是当P2P直连实在打不通时所有媒体数据经过TURN服务器中转。它牺牲了P2P的带宽优势但保证了“一定可以连通”。VChat里我用了coturn作为TURN服务器部署命令非常简单# 安装coturn之后最简启动方式 turnserver -a -u vchat:yourpassword -r your.realm -p 3478 \ --no-tls --no-dtls --fingerprint --verbose生产环境建议加TLS证书走5349端口。需要注意TURN的带宽成本和中心化架构是一样的所以它应该只作为兜底策略。实际运营时可以通过观察ICE选路结果统计relay候选的使用比例。如果这个比例高于20%说明大部分用户的网络环境存在对称NAT这时候就需要考虑部署多个地区的TURN节点甚至干脆切回SFU中转架构。ICE的候选配对和连通性检查逻辑WebRTC底层已经实现了不需要自己写。但理解它对排查问题很有帮助如果双方的候选列表里只有host候选说明STUN没生效如果srflx候选存在但连接失败可能是NAT类型不兼容如果最终走了relay说明直连没打通。看到日志里使用的候选类型基本就能定位网络层的症结。4. 从offer到音画上屏RTCPeerConnection完整流程4.1 getUserMedia采集与约束设置媒体采集是视频通话的起点也是很多人忽略细节的地方。VChat里采集的代码是const stream await navigator.mediaDevices.getUserMedia({ video: { width: { ideal: 1280 }, height: { ideal: 720 }, frameRate: { ideal: 30, max: 30 } }, audio: { echoCancellation: true, noiseSuppression: true, autoGainControl: true } });width和height用ideal而不是exact是因为手机前置摄像头不一定支持1280x720用ideal可以让浏览器自动选择最接近的分辨率。如果写死exact在低端设备上会直接抛OverconstrainedError。音频的三个约束建议都开echoCancellation回音消除解决“对方听到自己说话”的问题noiseSuppression降噪过滤环境噪音autoGainControl自动增益补偿距离远近的响度差异。这三个都是WebRTC音频引擎内置的处理白拿的功能不用白不用。4.2 从offer到answer再到ICE候选的完整时序VChat里建立连接的流程我建议严格按照下面的顺序走// 主叫端 const pc new RTCPeerConnection({ iceServers: [ { urls: stun:stun.l.google.com:19302 }, { urls: turn:your.turn.server, username: vchat, credential: password } ] }); // 添加本地媒体轨 stream.getTracks().forEach(track pc.addTrack(track, stream)); // 处理远端媒体轨 pc.ontrack (event) { remoteVideo.srcObject event.streams[0]; }; // 收集并发送ICE候选 pc.onicecandidate (event) { if (event.candidate) { socket.emit(ice-candidate, { roomId, candidate: event.candidate }); } }; // 创建offer并发送 const offer await pc.createOffer(); await pc.setLocalDescription(offer); socket.emit(offer, { roomId, sdp: offer });被叫端收到offer后做镜像操作把对方的SDP设置到自己的连接上创建answer返回同样发送自己的ICE候选。这里有个关键细节SDP交换和ICE候选交换是并行的不是串行的。我见过很多新手代码等offer/answer交换完才开始发ICE候选这会导致连接建立时间白白增加。正确的做法是在setLocalDescription之后立刻开始收集候选ICE候选通过onicecandidate回调不断产生随收随发也就是trickle ICE。VChat里实测trickle ICE能让连接建立时间从2到3秒降到1秒以内。4.3 候选配对与连通性检查的机制ICE候选交换完成之后两个端会各自维护一张候选对列表然后对每一对做连通性检查。这个检查的原理是A端往B端的候选地址发一个STUN Binding请求如果B端能收到并回复这对候选就是可用的。连通性检查通过后媒体才开始流动。整个过程对开发者是黑盒但理解它有助于解释一个现象为什么P2P视频通话不是“信令一握手画面立刻出来”。中间至少经历了候选收集、候选交换、连通性检查、DTLS握手、SRTP密钥协商等多个步骤任何一个环节卡住最直接的表现就是“对方看到我但我看不到对方”或者“两个人都看不到对方但状态却是connected”。调试这类问题时Chrome的chrome://webrtc-internals是我最常用的工具。它能看到完整的SDP、ICECandidatePair变化、RTP包的收发统计。绝大多数连接问题在这个页面里都能找到线索。5. 实测中的坑弱网、移动端与长时间通话5.1 弱网下的码率自适应P2P视频通话最怕的是网络抖动。两端直连的路径上只要有一个丢包画面就会卡顿、花屏、音画不同步。WebRTC自带拥塞控制会根据丢包率和RTT动态调整编码码率。但实测下来默认策略偏保守经常一丢包就把码率砍到很低画面糊成一团。VChat里我做了进一步的码率控制逻辑const sender pc.getSenders().find(s s.track s.track.kind video); const parameters sender.getParameters(); if (!parameters.encodings) { parameters.encodings [{}]; } parameters.encodings[0].maxBitrate currentBitrate; await sender.setParameters(parameters);监听stats事件里的丢包率动态调整maxBitrate。网络好时放开到2Mbps网络差时降到300kbps。这样做的效果是弱网下视频清晰度下降但至少保持流畅不会彻底卡死。音频优先级的处理也一样可以同步降低视频码率给音频腾出带宽。5.2 掉线重连与ICE重启P2P连接建立之后网络路径可能会变。最常见的情况是用户从Wi-Fi切到4G原来的IP地址失效连接直接断开。VChat里处理这个问题的核心是ICE重启pc.onconnectionstatechange () { if (pc.connectionState failed || pc.connectionState disconnected) { pc.restartIce(); } };restartIce()会生成新的ICE候选并重新协商不需要重建RTCPeerConnection对象。实测在大多数情况下ICE重启能在几百毫秒内恢复连接。如果重启一次还失败我会再加上一层兜底重新创建一个新的RTCPeerConnection重新走一遍offer/answer流程。这个二次握手几乎能覆盖所有断线场景。还有一个容易被忽略的问题信令通道和媒体通道的生命周期不一致。媒体连接断开后信令WebSocket可能还活着。这时需要做双向的握手确认比如定时向对方发ping确认媒体依然在流动否则就要触发重连逻辑。VChat早期就遇到过“两边都显示已连接但实际画面冻结了”的假活状态最后就是靠媒体层的活跃检测解决的。5.3 移动端兼容与回声处理移动端的坑比桌面端多不少。首当其冲是编解码器。VP8在Chrome上表现优秀但在部分安卓浏览器上兼容性一般Safari对VP8的支持也时常出问题。VChat最终的方案是优先使用H.264因为移动端芯片普遍有硬件编码器发热低、编码快兼容性也最好。回声问题也很典型。桌面端用耳机或者独立麦克风回声处理相对简单。但在手机上扬声器和麦克风距离近WebRTC内置的AEC回声消除有时不够用。实践中需要留意的是如果同一时间有多个音频流在播放比如通话音频和系统通知音同时出回声消除效果会大打折扣。VChat里的对策是通话期间主动降低系统音量或者提示用户使用免提时保持手机固定距离从声学路径上减少回声。长时间通话的内存问题同样不能轻视。每路媒体流都有对应的Track、Receiver和渲染对象跑一个小时后内存占用如果持续上涨大概率是某个旧流没有清理。VChat在断线重连后必须显式调用pc.getSenders().forEach(s s.track s.track.stop())关闭旧的媒体轨否则每重连一次就会泄露一路流的缓冲。6. VChat之外P2P架构的更多可能性做完VChat之后我最大的感受是WebRTC的P2P能力不应该只局限在视频通话。DataChannel可以把任意二进制数据在两个端之间直传这就打开了另一个世界。例如远程协助场景除了视频画面还需要传鼠标控制指令和剪贴板内容这些走DataChannel再合适不过。再比如多人白板协作涂鸦数据的实时同步走P2P只把缺席用户的节点用TURN兜底整体成本和稳定性都比纯服务器中转好。还有局域网场景两台设备支持直连时根本不需要任何服务器介入浏览器打开页面就能传文件、开视频这种“零成本建联”的能力非常适合临时会议、户外直播、设备调试等场景。我甚至试过把VChat的信令服务器改成静态配置——如果双方都已经知道彼此的候选地址和SDP参数信令服务完全可以省略。当然这需要非标准的媒体参数交换方式不适合通用场景但至少验证了一点P2P的上限远不止于“视频通话”这一个功能。最后分享一个我做VChat时反复体会到的经验不要把P2P理解成“不需要服务器”而是理解成“服务器应回归信令的本职”。媒体流路径越短延迟越低带宽成本越小用户的通话体验越好。找准这个边界P2P视频通话就能在成本和体验之间找到一个非常舒服的平衡点。本文还有配套的精品资源点击获取