27、测试与调试：模拟器测试、真机调试、网络模拟
做WebRTC移动端开发，最头疼的是什么？
我个人的答案是：“本地跑得好好的，一上真机就崩”。
这几乎是每个RTC开发者的必经之路。模拟器里音视频流顺畅得像丝绸，结果到了真机上，画面卡成PPT，音频断断续续。为什么会这样？说白了，模拟器和真机是两个世界。
这一章，我就带你把这几个环节彻底捋清楚。从模拟器测试的局限性，到真机调试的硬核操作，再到网络模拟的骚操作，咱们一步到位。
核心观点：WebRTC移动端开发，测试环境必须“三管齐下”——模拟器做功能验证，真机做性能压测，网络模拟做极限场景演练。缺一个，上线必翻车。
模拟器测试：能做什么，不能做什么
先说说模拟器。很多新手觉得模拟器方便，跑得快，还能随意切换设备型号。嗯，确实方便，但你要清楚它的边界。
模拟器能做的：
- UI布局验证——不同屏幕尺寸、分辨率下的界面适配
- 信令流程测试——加入房间、离开房间、媒体协商等逻辑
- 基本API调用——getUserMedia、RTCPeerConnection的创建与销毁
- 日志与调试——断点、打印、性能Profile
模拟器不能做的：
- 真实的摄像头/麦克风采集——模拟器用的是虚拟设备，编码参数和真机完全不同
- 硬件编解码——大部分模拟器不支持硬件加速，全走软编软解
- 网络状态模拟——模拟器的网络栈和真机有差异，WiFi/4G/5G切换场景无法复现
- 功耗与发热——这个不用我说了吧，模拟器插着电源跑，根本看不出电池消耗
我的习惯：每次写完一个新功能，先在模拟器上跑一遍基本流程。确认UI没崩、信令没报错，再上真机。模拟器帮我过滤掉80%的低级bug。
真机调试：避坑指南
真机调试才是WebRTC开发的“主战场”。我见过太多人，模拟器上跑得飞起，一上真机就各种诡异问题。
iOS真机调试要点：
- 必须使用真机设备，iOS模拟器不支持摄像头采集
- 需要在Xcode中配置Capabilities，开启Audio、Video权限
- 注意App Transport Security设置，WebRTC的信令服务器如果是HTTP，需要在Info.plist中例外
- 真机调试时建议开启“GPU Frame Capture”，可以直观看到视频帧的渲染流程
Android真机调试要点：
- Android模拟器从API 26开始支持摄像头，但效果很差，建议直接上真机
- 注意Android 10+的隐私权限变更，后台麦克风访问受限
- 不同厂商的硬件编解码实现差异巨大——华为、小米、三星，同一个H.264码流，解码延迟能差出50ms
- 建议在AndroidManifest中显式声明
CAMERA和RECORD_AUDIO权限
我曾经踩过的坑：有一次在小米手机上测试，视频一直黑屏。查了半天，发现是WebRTC默认开启了硬件编码，而小米那颗芯片的H.264编码器有个bug——分辨率不是16的倍数就直接输出空帧。最后加了分辨率对齐逻辑才解决。嗯，这种问题模拟器永远测不出来。
网络模拟：让bug无处遁形
WebRTC最怕什么？网络抖动。
你在办公室WiFi下测得好好的，用户在地铁上、电梯里、高速公路上用，体验能一样吗？
所以，网络模拟是测试环节的“照妖镜”。
常用的网络模拟工具：
| 工具 | 平台 | 功能 | 我的评价 |
|---|---|---|---|
| Network Link Conditioner | macOS/iOS | 限制带宽、延迟、丢包率 | 苹果官方工具，简单好用，但功能有限 |
| Clumsy | Windows | 实时网络干扰，支持丢包、延迟、重排 | 轻量级，适合快速验证 |
| tc (Traffic Control) | Linux | 内核级网络模拟，功能强大 | 我最常用的，配合脚本可以自动化测试 |
| Augmented Traffic Control (ATC) | 跨平台 | Facebook开源，支持WiFi/4G模拟 | 适合团队搭建统一测试环境 |
网络模拟的核心参数：
- 带宽限制：模拟300kbps、500kbps、1Mbps等场景，看视频是否降级
- 延迟：50ms、100ms、200ms，观察通话的实时性
- 丢包率：1%、5%、10%，WebRTC的FEC和NACK机制是否生效
- 抖动：模拟网络波动，看JitterBuffer能否平滑处理
我建议的测试组合：先跑一个“理想网络”（WiFi，0丢包，10ms延迟），再跑一个“恶劣网络”（4G，5%丢包，100ms延迟）。如果两个场景下通话都能维持，那基本就稳了。
知识体系：测试与调试全景图
下面这张图，是我自己梳理的WebRTC移动端测试体系。你照着这个框架去搭测试环境，基本不会漏掉关键环节。
实战：搭建一个完整的测试流程
光说不练假把式。我分享一下自己常用的测试脚本，你拿去就能用。
iOS端网络模拟脚本（配合Network Link Conditioner）：
// 模拟4G网络环境
// 带宽：下行10Mbps，上行5Mbps
// 延迟：50ms
// 丢包：2%
// 通过Xcode的Devices and Simulators窗口
// 或者使用命令行：
xcrun simctl io booted --network-condition
// 然后手动配置参数Android端网络模拟脚本（配合tc命令）：
# 模拟3G网络
# 带宽：1Mbps
# 延迟：100ms
# 丢包：3%
# 添加规则
tc qdisc add dev wlan0 root netem \
delay 100ms 20ms distribution normal \
loss 3% \
rate 1mbit
# 清除规则
tc qdisc del dev wlan0 root一个小技巧：把网络模拟脚本和自动化测试脚本结合起来。每次CI构建完成后，自动跑一遍“恶劣网络”场景下的通话测试。如果视频帧率低于15fps或者音频卡顿超过5次，直接标记为构建失败。这样能提前拦截大量性能问题。
调试工具推荐
最后，分享几个我常用的调试工具，都是实战中验证过的。
- Chrome DevTools（Remote Debugging）：Android端WebRTC调试首选，可以实时查看Stats报告，包括丢包率、往返时间、编解码器状态
- Safari Web Inspector：iOS端调试利器，支持WebRTC的inspect，可以看到ICE连接状态和媒体流信息
- Wireshark：抓包分析SRTP/SCTP流量，排查加密传输问题
- WebRTC Internals（chrome://webrtc-internals）：浏览器内置工具，能看到所有PeerConnection的详细日志
注意：真机调试时，一定要关闭Xcode或Android Studio的“自动休眠”设置。我有一回调试到一半，手机锁屏了，WebRTC的音频采集直接断掉，排查了半天才发现是锁屏导致的权限回收。嗯，这种低级错误犯一次就够了。
测试与调试这件事，说白了就是“把问题暴露在实验室，而不是留给用户”。模拟器帮你快速验证逻辑，真机帮你暴露硬件差异，网络模拟帮你压出极限场景下的隐患。三者缺一不可。
你想想看，如果用户在地铁上打开你的App，视频通话卡成PPT，他还会用第二次吗？
所以，别偷懒。把测试环境搭扎实了，上线才能睡得安稳。