10、移动端性能优化：Android/iOS的硬件编码器适配、功耗与发热控制、前后台切换的保活策略
移动端做WebRTC，说白了就是跟资源较劲。CPU就那么点，电池就那么点，散热全靠被动。我刚开始做移动端优化时，以为把桌面端的代码搬过来就行，结果一跑，手机烫得能煎鸡蛋。嗯，从那以后我学乖了——移动端优化，得从硬件编码器开始说起。
10.1 硬件编码器适配：别让CPU扛编码
为什么一定要用硬件编码器？你想想看，软件编码（x264）在桌面端表现不错，但到了手机上，同样的720p编码，软编能吃掉一个完整的大核，功耗直奔2W+。而硬件编码器，功耗通常在200-400mW之间，差距是5到10倍。
我个人习惯，在项目初始化时就做一次编码器能力探测。Android和iOS的API完全不同，得分别处理。
Android端：MediaCodec的坑与填坑
Android的硬件编码器通过MediaCodec API暴露。但有个问题——不同厂商的编码器实现差异很大。我在项目中遇到过，某款骁龙芯片的编码器在1080p下只能跑到20fps，而同一款芯片的另一台手机却正常。后来发现是编码器配置参数的问题。
这里给出一段我常用的编码器探测代码：
// 检测硬件编码器是否支持目标分辨率
private fun checkEncoderSupport(mimeType: String, width: Int, height: Int): Boolean {
val codecList = MediaCodecList(MediaCodecList.REGULAR_CODECS)
for (codecInfo in codecList.codecInfos) {
if (!codecInfo.isEncoder) continue
val capabilities = codecInfo.getCapabilitiesForType(mimeType)
val videoCap = capabilities.videoCapabilities
// 关键：检查分辨率支持范围
if (videoCap.isSizeSupported(width, height)) {
return true
}
}
return false
}适配策略上，我建议做降级处理：
- 首选：目标分辨率硬件编码
- 降级1：降低一档分辨率（如1080p→720p）再试硬件编码
- 降级2：如果硬件编码完全不支持，回退到软件编码（但要做好发热准备）
iOS端：VideoToolbox的配置要点
iOS的硬件编码器通过VideoToolbox框架调用。相比Android，iOS的编码器一致性要好很多，但也有自己的脾气。
我记得有一次，在iOS 14的设备上，编码器输出的关键帧间隔不稳定。排查后发现是kVTCompressionPropertyKey_MaxKeyFrameInterval设置的问题。苹果的文档说这个值是帧数，但实际行为跟帧率有关。我后来改用kVTCompressionPropertyKey_MaxKeyFrameIntervalDuration，按秒设置，问题就解决了。
// iOS端编码器配置示例
let encoderSpec: [String: Any] = [
kVTCompressionPropertyKey_RealTime: kCFBooleanTrue,
kVTCompressionPropertyKey_ProfileLevel: kVTProfileLevel_H264_High_AutoLevel,
kVTCompressionPropertyKey_MaxKeyFrameIntervalDuration: 2, // 2秒一个关键帧
kVTCompressionPropertyKey_ExpectedFrameRate: 30,
kVTCompressionPropertyKey_AverageBitRate: 1_500_000, // 1.5Mbps
kVTCompressionPropertyKey_DataRateLimits: [2_000_000 as CFNumber] // 峰值码率
]RealTime为true很重要。如果不设置，编码器可能会为了质量而牺牲延迟，导致编码一帧耗时几十毫秒，视频就卡了。
10.2 功耗与发热控制：别让手机变暖手宝
功耗控制，核心就一句话：在保证体验的前提下，尽可能降低计算负载。我总结了一套分层控制策略，从粗粒度到细粒度。
分层策略：分辨率、帧率、码率联动调节
不要单独调某个参数。分辨率、帧率、码率三者是联动的。我习惯用一个简单的表格来定义不同档位：
| 档位 | 分辨率 | 帧率 | 码率 | 适用场景 |
|---|---|---|---|---|
| 高性能 | 1080p | 30fps | 2.5Mbps | WiFi、充电状态 |
| 均衡 | 720p | 24fps | 1.5Mbps | 4G网络、中等电量 |
| 省电 | 480p | 15fps | 800Kbps | 弱网、低电量 |
| 极限省电 | 360p | 10fps | 400Kbps | 电量低于20% |
切换策略我建议用阶梯式降级，不要一下子从1080p跳到360p。用户会明显感觉到画质突变。我一般每30秒评估一次系统状态，每次只降一档。
温度监控与主动降级
我曾经在一个户外直播项目里，手机在太阳底下晒了10分钟，温度直接飙到45°C。系统开始降频，编码器丢帧，视频直接卡成PPT。从那以后，我养成了监控电池温度的习惯。
// Android端获取电池温度
fun getBatteryTemperature(context: Context): Float {
val intent = context.registerReceiver(null, IntentFilter(Intent.ACTION_BATTERY_CHANGED))
val temp = intent?.getIntExtra(BatteryManager.EXTRA_TEMPERATURE, 0) ?: 0
return temp / 10.0f // 单位：摄氏度
}
// 温度阈值控制逻辑
when {
temp < 38 -> 保持当前档位
temp in 38..42 -> 降一档（如720p→480p）
temp in 42..45 -> 降两档，同时降低帧率
temp > 45 -> 强制切换到极限省电模式，甚至关闭视频发送
}iOS端的功耗优化细节
iOS的功耗管理相对封闭，但有几个点可以注意：
- 避免频繁创建编码器： VideoToolbox编码器创建开销很大，大约需要200-500ms。我建议在通话开始时创建，通话期间复用，不要频繁重建。
- 合理设置编码器参数： 不要使用
kVTEncodeFrameOptionKey_ForceKeyFrame过于频繁。每次强制关键帧都会导致编码器内部状态重置，增加功耗。 - 利用iOS的
lowPowerMode： 检测到低电量模式时，主动降低编码参数。
10.3 前后台切换的保活策略：别让通话断了
移动端最头疼的问题之一：用户切到后台回个微信，回来发现通话断了。为什么？因为系统把App进程杀了，或者网络连接被回收了。
保活策略，说白了就是跟系统抢时间。我总结了三道防线：
第一道防线：后台任务声明
Android和iOS都提供了后台任务机制，但限制越来越严。
Android端：
- 使用
ForegroundService，并显示一个持久通知。这是最可靠的方式。 - 在
AndroidManifest.xml中声明FOREGROUND_SERVICE权限。 - 注意：Android 12+要求指定前台服务类型，视频通话应使用
camera或microphone类型。
<service
android:name=".WebRTCForegroundService"
android:foregroundServiceType="camera|microphone"
android:exported="false" />iOS端：
- 启用
VoIP后台模式（但iOS 10+后限制很多，主要用于推送唤醒）。 - 更实际的做法：使用
Background TaskAPI，申请额外的时间（约30秒）来完成连接迁移。
第二道防线：连接迁移与快速重连
用户切到后台时，网络可能从WiFi切到4G，或者IP地址发生变化。这时候需要做连接迁移。
我个人习惯的做法：
- 在
onPause（Android）或applicationDidEnterBackground（iOS）时，保存当前的ICE连接状态。 - 切回前台时，立即触发ICE重启（
RestartIce()）。 - 同时启动一个快速重连定时器，如果在3秒内没有收到视频帧，就主动重建PeerConnection。
第三道防线：心跳与保活
有些网络环境（比如移动热点）会在空闲时关闭UDP端口。这时候需要心跳包来维持NAT映射。
我建议的心跳策略：
- 使用WebRTC自带的
STUN心跳（默认每5秒一次）。 - 如果发现长时间没有收到对端数据，主动发送一个空的RTP包（payload type=0，但不要带实际数据）。
- 对于后台场景，可以降低心跳频率到15秒一次，减少功耗。
10.4 知识体系总览
下面这张图总结了移动端性能优化的核心逻辑。你可以看到，从编码器适配到底层保活，每个环节都环环相扣。
移动端优化没有银弹。每个项目都有自己的瓶颈，可能是编码器兼容性，可能是特定机型的发热问题，也可能是运营商网络的NAT超时策略。我的建议是：先跑一轮完整的性能基线测试，找到真正的瓶颈在哪，再针对性地优化。不要一上来就全盘改造，那样反而容易引入新问题。
公众号:蓝海资料掘金营，微信deep3321