iOS App基于WebRTC与ARKKit实现视频通信时设备发热及CPU占用过高的优化方案咨询

我之前在做WebRTC结合ARKKit的实时视频流项目时，也碰到过完全一样的问题——初期运行流畅，但长时间使用后CPU占用率飙升，设备发烫严重。结合我踩过的坑和实际优化经验，给你整理几个切实有效的调整方向：

1. 替换视图截图，直接复用ARKKit的GPU处理帧 #

原来的视图截图（比如drawHierarchy(in:afterScreenUpdates:)或UIGraphicsImageRenderer）是CPU密集型操作，尤其是ARKKit本身已经在GPU完成了实时渲染，再通过截图转CGImage的方式获取帧，相当于把GPU的数据再拉回CPU处理，完全是额外的性能损耗。

优化方案：

• 在ARSessionDelegate的session(_:didUpdate:)回调中，直接获取ARFrame的capturedImage（这是一个已经处理好的CVPixelBuffer），跳过截图转CGImage的步骤，直接传给RTCVideoCapturer的capturer(_:didCapture:)方法。
• 示例代码片段：

func session(_ session: ARSession, didUpdate frame: ARFrame) {
    // 直接复用ARKKit输出的像素缓冲区，无需截图
    let pixelBuffer = frame.capturedImage
    // 按需调整格式后传给WebRTC
    capturer.capturer(capturer, didCapture: pixelBuffer)
}

2. 优化像素缓冲区处理，避免CPU拷贝 #

如果必须对帧做格式转换或处理，尽量让GPU来承担，减少CPU的参与：

• 用Metal或CoreImage处理像素格式转换，比如把ARKKit的YUV格式转成WebRTC支持的格式，这些框架会自动利用GPU加速。
• 使用CVPixelBufferPool复用缓冲区，避免频繁创建和释放CVPixelBuffer——内存分配和释放的开销在高频帧场景下会累积成显著的CPU占用。
• 确保传给WebRTC的CVPixelBuffer是内存对齐的，并且格式是WebRTC原生支持的（比如kCVPixelFormatType_420YpCbCr8BiPlanarFullRange），这样WebRTC无需再做额外的格式转换。

3. 动态控制捕获帧率，匹配编码能力 #

ARKKit默认输出60fps的帧，但WebRTC的编码能力受网络和硬件限制，过高的帧率会让CPU持续满负荷处理编码工作：

• 通过ARConfiguration的preferredFrameRateRange设置帧率范围，比如限制在24-30fps，能直接减少50%的帧处理量。
• 监听设备热状态（NSProcessInfoThermalState）或WebRTC的统计数据（比如 outgoing RTP帧率），动态调整帧率：当设备进入热警告状态，或网络带宽不足时，自动降到24fps甚至更低；恢复后再回升。
• 示例代码片段：

let config = ARWorldTrackingConfiguration()
// 设置帧率范围为24-30fps
config.preferredFrameRateRange = .init(minimum: 24, maximum: 30)

4. 强制启用WebRTC硬件编码 #

WebRTC在iOS上默认支持硬件编码，但有时候配置不当会 fallback到软件编码，这会导致CPU占用暴增：

• 初始化RTCPeerConnection时，使用RTCDefaultVideoEncoderFactory，它会优先选择硬件编码器（比如H.264硬件编码）。
• 检查RTCVideoEncoderSettings，确保preferredCodec设置为硬件支持的编码格式，避免软件编码。

5. 监控热状态，主动降级性能 #

设备发热后会触发系统的CPU降频，反而会让处理效率更低，所以要提前介入：

• 注册NSProcessInfoThermalStateDidChangeNotification通知，当设备进入NSProcessInfoThermalStateWarning或更高热状态时，立即执行降级操作：
  • 降低视频分辨率（比如从1080p降到720p）
  • 进一步降低帧率
  • 关闭ARKKit的非必要特性（比如环境纹理追踪、多人协作功能）
• 当热状态恢复正常后，再逐步恢复原有性能。

6. 清理冗余的CPU操作 #

检查你的帧处理回调逻辑，移除不必要的耗时操作：

• 不要在didCapture回调里做同步锁、高频日志打印、复杂计算等工作，把这些操作移到后台串行队列执行。
• 确保RTCVideoCapturer的回调在合适的队列运行，避免阻塞主线程或编码线程。

内容的提问来源于stack exchange，提问作者omkar_k