一、IoT与边缘计算：WebRTC在物联网设备中的实战
说实话，我第一次把WebRTC跑在树莓派上的时候，差点被坑哭。那会儿我还在做智能家居项目，想着用摄像头实时推流到手机端，结果画面卡得跟幻灯片似的。后来我才明白——IoT设备不是PC，资源有限、网络不稳定，你得换个思路来玩。
今天咱们就聊聊，怎么把WebRTC塞进IoT设备里，尤其是摄像头和无人机这类场景。我还会分享一些边缘计算和弱网优化的实战经验。
1.1 摄像头设备：轻量级推流方案
IoT摄像头通常跑Linux或RTOS，算力有限。你不能指望它像PC一样编码1080p视频。我个人习惯的做法是：
- 分辨率降到640x480或更低——320x240在弱网下更稳
- 帧率控制在15fps以内——10fps对监控场景完全够用
- 使用硬件编码器——比如树莓派的GPU编码，别用CPU软编
核心思路：IoT设备只做采集和轻量编码，把复杂的转码、合流交给边缘节点。
举个例子，我在一个智能门铃项目里，摄像头采集到H.264裸流后，直接通过WebRTC的RTCRtpSender发送。代码大概长这样：
// 摄像头端（IoT设备）
const pc = new RTCPeerConnection(config);
const stream = await navigator.mediaDevices.getUserMedia({
video: { width: 640, height: 480, frameRate: 10 }
});
stream.getTracks().forEach(track => pc.addTrack(track, stream));
// 只发不收，节省带宽
pc.createOffer().then(offer => pc.setLocalDescription(offer));嗯，这里要注意：IoT设备通常不需要接收远端流，所以只创建offer，不处理answer里的媒体。这样可以省掉一半的带宽和CPU开销。
1.2 无人机场景：低延迟是第一优先级
无人机和摄像头不太一样。摄像头可以接受1-2秒延迟，但无人机不行——你想想看，飞手看到画面延迟2秒，那飞机早撞树上了。
我在做无人机图传项目时，踩过一个坑：默认的WebRTC配置延迟太高。后来我调整了以下参数：
| 参数 | 默认值 | 无人机推荐值 | 说明 |
|---|---|---|---|
| iceTransportPolicy | all | relay | 强制走TURN，避免NAT穿透延迟 |
| maxBitrate | 自动 | 2-4 Mbps | 根据图传距离动态调整 |
| degradationPreference | balanced | maintain-framerate | 优先保帧率，降分辨率 |
| googCpuOveruseDetection | true | false | 关闭CPU过载检测，避免降质 |
我的经验：无人机场景建议用VP8编码，虽然压缩率不如H.264，但解码速度快、丢包恢复好。我曾经在飞控日志里看到，VP8在5%丢包率下还能保持25fps，H.264直接崩到8fps。
二、边缘计算与WebRTC结合
边缘计算说白了就是——把计算能力从云端搬到离设备近的地方。为什么这对WebRTC重要？因为IoT设备本身太弱了，你不可能让一个单片机去处理视频合流、转码、录制这些事。
2.1 边缘节点的角色
我习惯把边缘节点当作WebRTC的SFU（Selective Forwarding Unit）来用。架构大概是这样的：
IoT摄像头 → 边缘节点(SFU) → 手机/PC客户端
↓
本地存储/分析边缘节点负责：
- 接收多个IoT设备的视频流
- 做合流、转码（比如把H.264转成VP8）
- 分发给多个客户端
- 本地录制和AI分析
我曾经在一个智慧工地项目里，用NVIDIA Jetson Nano做边缘节点。它同时接了8个摄像头，每个640x480@10fps，然后通过WebRTC转发给监控中心。效果还不错，延迟控制在300ms以内。
2.2 边缘计算的优势
你想想看，如果所有摄像头都直接连到云端的WebRTC服务器，那带宽和延迟都扛不住。边缘节点离设备近，延迟低，还能做本地处理。具体来说：
- 延迟降低：边缘到设备通常<10ms，云端可能要50-100ms
- 带宽节省：边缘节点可以做转码，把高码率流压缩后再上传
- 离线可用：边缘节点本地存储，断网也不丢数据
注意：边缘节点不是万能的。它本身也是有限资源，别把所有计算都压上去。我见过有人把AI模型推理也跑在边缘节点上，结果CPU飙到90%，视频转发直接卡死。建议把AI分析单独部署，或者用GPU加速。
三、低功耗与弱网优化
IoT设备很多是电池供电的，比如无人机、无线摄像头。你不能让WebRTC一直全速跑，那电池撑不过半小时。弱网优化就更不用说了——WiFi信号差、4G不稳定，这些都是家常便饭。
3.1 低功耗策略
我总结了几条实用的低功耗优化方法：
- 动态帧率：画面静止时降到1-2fps，有运动时升到15fps
- 休眠模式：没有客户端观看时，关闭编码器和WiFi模块
- 降低分辨率：根据电量动态调整，电量低于20%时降到320x240
- 使用UDP而非TCP：UDP开销小，CPU占用低
举个例子，我在一个电池供电的户外摄像头项目里，用RTCPeerConnection的iceConnectionState事件来判断是否有客户端连接。没有连接时，直接关闭编码器：
pc.oniceconnectionstatechange = () => {
if (pc.iceConnectionState === 'disconnected') {
// 关闭编码器，进入休眠
encoder.stop();
wifi.sleep();
} else if (pc.iceConnectionState === 'connected') {
// 唤醒编码器
wifi.wake();
encoder.start();
}
};嗯，这里要注意：disconnected状态可能有延迟，建议加一个超时判断，比如连续5秒无连接再休眠。
3.2 弱网优化技巧
弱网优化是WebRTC的强项，但默认配置不一定适合IoT场景。我分享几个实战中验证过的技巧：
- 启用FEC（前向纠错）：丢包率>5%时，FEC能明显改善画质
- 使用NACK（丢包重传）：但注意控制重传次数，避免拥塞
- 动态码率调整：根据RTT和丢包率，自动降低码率
- Simulcast（分层编码）：发送多个分辨率，客户端按需选择
避坑指南：我曾经在弱网环境下同时开启FEC和NACK，结果网络更卡了。后来发现FEC和NACK会互相竞争带宽。建议二选一：丢包率<10%用NACK，>10%用FEC。
动态码率调整的代码示例：
// 根据网络状况动态调整码率
const sender = pc.getSenders()[0];
const params = sender.getParameters();
setInterval(() => {
const stats = await pc.getStats();
stats.forEach(report => {
if (report.type === 'candidate-pair' && report.state === 'succeeded') {
const rtt = report.currentRoundTripTime;
const loss = report.packetsLost / report.packetsSent;
if (loss > 0.1 || rtt > 500) {
// 网络差，降低码率
params.encodings[0].maxBitrate = 500000; // 500kbps
} else {
// 网络好，恢复码率
params.encodings[0].maxBitrate = 2000000; // 2Mbps
}
sender.setParameters(params);
}
});
}, 2000); // 每2秒检查一次四、知识体系总览
说了这么多，我画了一张图帮你梳理本章的核心逻辑。从IoT设备到边缘节点，再到客户端，每个环节都有对应的优化策略。
这张图展示了从IoT设备到客户端的完整链路。每一层都有对应的优化策略，低功耗、弱网优化、边缘计算三者缺一不可。我个人建议先从IoT设备端的优化入手，因为那是瓶颈最明显的地方。
最后说一句：WebRTC在IoT场景下潜力很大，但别指望开箱即用。你需要根据设备算力、网络环境、功耗要求做大量调优。我做了四五个IoT项目后才摸索出这些套路，希望你能少走弯路。