移动端适配：iOS/Android平台差异、功耗优化、后台保活策略
做WebRTC移动端适配，说白了就是跟两个平台「斗智斗勇」。我最早做移动端WebRTC时，以为把桌面端的代码交叉编译一下就能跑，结果被iOS的音频会话和Android的Camera API折腾得够呛。今天咱们就聊聊这些坑，以及我这些年攒下来的经验。
一、iOS与Android的平台差异
这两个平台的差异，远不止一个用Objective-C一个用Java那么简单。咱们从底层说起。
1. 音频采集与渲染
iOS这边，WebRTC用的是自带的AudioUnit。为什么？因为AudioUnit延迟最低，能到10ms以内。Android那边就复杂了——OpenSL ES是主流，但碎片化严重。我遇到过某款国产手机，OpenSL ES初始化直接崩溃，最后只能回退到Java层的AudioRecord。
核心差异点：
- iOS：AudioUnit + AVAudioSession，延迟可控，系统级优化
- Android：OpenSL ES（首选）→ AAudio（API 27+）→ AudioRecord（兜底）
嗯，这里要注意：Android的音频路由策略跟iOS完全不同。iOS插拔耳机时系统会自动切换，Android你得自己监听ACTION_HEADSET_PLUG广播。我曾经因为这个没处理好，用户戴着蓝牙耳机通话，声音却从扬声器出来了——那场面，尴尬得很。
2. 视频采集与编码
iOS的Camera API相对统一，从AVCaptureSession到现在的AVCaptureDevice，变化不大。Android就头疼了——Camera1、Camera2、CameraX，三个API并存。我建议直接用Camera2，虽然代码量大了点，但兼容性最好。
编码器这块，iOS有VideoToolbox硬件编码器，Android有MediaCodec。但有个坑：Android的MediaCodec在不同厂商的芯片上表现差异巨大。高通芯片的H.264编码器延迟低，联发科的就容易丢帧。我做过一个测试，同一段视频在不同手机上编码延迟差了3倍。
我的经验：Android端建议把编码器初始化的超时时间设长一点，至少5秒。有些低端机第一次初始化MediaCodec要花好几秒，超时太短直接失败。
3. 网络接口差异
iOS的Network.framework和Android的ConnectivityManager，获取网络状态的方式完全不同。但WebRTC底层已经封装好了，你只需要关注一件事：网络切换时的处理。
iOS从WiFi切到4G时，系统会断开所有TCP连接，但UDP连接不受影响。Android则相反——有些手机会把UDP连接也断掉。这就导致WebRTC的ICE连接可能突然中断。我建议在应用层监听网络变化，主动触发ICE重启。
二、功耗优化：让手机不那么烫
做移动端WebRTC，功耗是绕不开的坎。用户打着视频电话，手机烫得能煎鸡蛋，这体验谁受得了？
1. 视频编码功耗
硬件编码器比软件编码器省电得多，这是共识。但硬件编码器也有讲究：
- 分辨率动态调整：不要一直用1080p。根据网络状况和CPU温度，动态降到720p甚至480p。我习惯每30秒检查一次CPU温度，超过65°C就降一档分辨率。
- 帧率控制：30fps和15fps的功耗差多少？实测能差30%。如果画面变化不大（比如文档共享），降到15fps完全够用。
- 编码器配置：H.264的baseline profile比main profile省电，但画质差一些。看场景取舍吧。
功耗优化清单：
| 优化项 | 预期效果 | 实现方式 |
|---|---|---|
| 动态分辨率 | 降低编码负载30% | 根据CPU温度/网络带宽调整 |
| 帧率自适应 | 降低功耗20% | 画面静止时降帧 |
| 硬件编码优先 | 比软编码省电50% | 优先使用MediaCodec/VideoToolbox |
| 音频降采样 | 降低音频处理功耗 | 48kHz→16kHz（语音场景） |
2. 音频处理功耗
WebRTC的音频3A算法（AEC、ANS、AGC）很耗电。尤其是回声消除，需要大量的FFT计算。我建议：
- 如果用户使用耳机，可以关闭AEC——耳机天然隔离了回声
- 降噪强度不要拉满，中等强度就够了，再高也听不出区别
- 采样率从48kHz降到16kHz，语音通话完全够用，功耗能降一半
3. 网络模块功耗
WebRTC的ICE连接会定期发送STUN探测包，这个频率可以调。默认是每5秒发一次，如果网络稳定，可以改成15秒。另外，WiFi比4G省电，4G比5G省电——这个优先级要记住。
注意：不要为了省电把STUN间隔设得太长。我曾经设成30秒，结果网络切换后ICE连接恢复特别慢，用户投诉说「通话断了半分钟」。省电和省心，得找个平衡点。
三、后台保活策略：别让App被系统杀掉
移动端WebRTC最头疼的问题之一：App切到后台，通话就断了。iOS和Android的处理方式完全不同。
1. iOS后台保活
iOS提供了两种后台模式：
- VoIP模式：系统会为VoIP App保持网络连接，但iOS 13以后限制很严，必须用PushKit来唤醒
- Audio模式：只要App在播放音频，系统就不会杀掉它。这是最常用的方式
我的做法是：切到后台时，创建一个无声的音频播放器（播放静音文件），告诉系统「我在用音频」。这样系统会保留App的进程。但要注意，iOS会检测你是否真的在播放音频，如果只是占着资源不干活，过几分钟还是会被杀掉。
小技巧：iOS后台时，把视频编码器关掉，只保留音频。视频画面用最后一帧代替。这样既省电，又能维持后台连接。
2. Android后台保活
Android的后台管理比iOS复杂得多。不同厂商的ROM有不同的策略：华为的「智慧引擎」、小米的「神隐模式」、OPPO的「冻结应用」……每个都在想方设法杀后台。
我总结了几种保活策略，按优先级排列：
- 前台服务：创建一个带通知的前台服务，告诉系统「我在做重要的事」。这是最靠谱的方式。
- JobScheduler：用JobScheduler定期唤醒App，保持进程活跃。但Android 8以后限制变严了。
- 厂商白名单：引导用户把App加入厂商的「受保护应用」列表。虽然用户体验差一点，但最有效。
- 双进程守护：创建两个进程互相唤醒。但Android 10以后，这种方式基本失效了。
避坑指南：我曾经在某个项目里用了「双进程守护」，结果被华为手机直接标记为「恶意应用」。从那以后我再也不敢用这种灰色手段了。老老实实引导用户加白名单，虽然麻烦，但安全。
3. 网络切换时的保活
不管是iOS还是Android，网络切换时WebRTC连接都可能中断。我的策略是：
- 监听网络变化广播（iOS的NWPathMonitor，Android的ConnectivityManager）
- 检测到网络变化后，立即触发ICE重启
- 如果ICE重启失败，尝试重新创建PeerConnection
- 整个过程控制在3秒内完成，用户几乎感觉不到
四、知识体系总览
下面这张图是我整理的移动端适配核心逻辑，你看一眼就能明白各个模块之间的关系：
你看，这三个模块其实是相互影响的。平台差异决定了你用什么API，API的选择影响功耗，功耗又跟后台保活策略挂钩。我习惯在设计阶段就把这三件事一起考虑，而不是分开做。
最后说一句：移动端WebRTC没有银弹。每个项目都有自己的场景和约束，我的经验只能给你参考，具体怎么取舍，还得看你的用户群体和产品定位。嗯，今天就聊到这儿，下次咱们聊聊音视频同步的那些坑。
公众号:蓝海资料掘金营，微信deep3321