对于低端机在录制时候发热，除了降低分辨率和码率，请问还有其他优化方案吗？

手机发热的根本原因是：CPU/GPU 使用负载过高。所以要优化低端机发热问题，基本思路是从降低 CPU/GPU 的使用负载出发。

在手机录制的场景下，可能涉及到这些功能模块：

• 相机采集，必选。
• 图像处理，可选。比如：人脸识别、美颜、磨皮、美白、图像降噪、特效等。
• 音频处理，可选。比如：音频降噪、美声、变声、混响、声音增强等。
• 编码，必选。
• 封装，必选。
• 存储 I/O，场景相关：录制视频用于本地存储，必选。
• 网络 I/O，场景相关：录制视频用于直播推流或文件上传，必选。

在上述模块中，容易成为发热重点的 CPU/GPU 计算密集型模块一般是：图像处理、编码。

在低端机上，要优化发热：

1）简单的做法：去掉『可选』，优化『必选』。

• 关闭图像处理、音频处理模块。机型太差的时候，优先满足核心的录制需求。
• 编码尽量适配硬编。软编主要靠 CPU 运算，性能消耗大，而硬编主要使用专用硬件来编码，会显著降低 CPU 负担。但是主要注意的是，如果是 Android 平台，由于机型过多，会出现一些硬编兼容性很差的机器，这时候为了支持编码可用，最好增加硬编黑名单来控制。
• 降低相机采集的分辨率、码率、帧率。相机采集的分辨率、码率、帧率，都决定了编码阶段的数据处理量，可以适当降低。

2）进阶的做法：数据处理链路降低计算消耗。

• 采集到图像处理进行图像下采样。有时候我们采集时需要较高的分辨率，但是在算法处理时则不需要，这时候采集完直接下采样交给后续的图像处理链路，可以降低数据量，优化性能。
• 图像处理链路对齐分辨率，防止多次采样消耗性能。图像处理链路也不光是下采样就完了，因为整个图像处理链路可能涉及不同的节点（比如人脸识别模块、降噪模块、美颜模块），如果这几个节点对应的算法输入分辨率不一致，那就需要一路上做多次图像上采样或下采样，这样就带来了额外的性能开销。如果在数据链路设计之初，各个模块就能对齐分辨率，就节省了反复上下采样的消耗。
• 图像处理链路对齐颜色空间，防止颜色空间转换消耗性能。同样的，不同的节点的算法模型如果使用不同的颜色空间，一路下来就会涉及颜色格式的转换，这样也会带来更多的性能开销。
• 减少 CPU 和 GPU 之间的数据拷贝。可以使用系统能力来实现 GPU 和 CPU 的内存共享来实现相关的优化。
• 做图像的裁剪、缩放、旋转、尺寸变化时要注意优化性能。可以使用 libyuv 来做常规的图像处理，一些 libyuv 版本甚至做过汇编级别的优化来提升图像处理的性能。
• 对计算密集型模块做汇编指令级优化。视频或音频算法处理涉及的端侧智能推理引擎、音视频编解码涉及的编码器都是计算密集型模块，对这些模块可以针对性地做汇编指令级优化，提升性能。

3）精细的做法：全机型跑分，动态适配功能模块。

• 对各种机型下发 CPU/GPU 性能跑分的 Benchmark 任务，并上报跑分数据到服务端，基于跑分衡量在某一款机型上可以开启哪些功能模块，并实现动态开关配置。这个方案是个大工程，这里就先不展开了。

此外，开发 iOS 应用时，可以使用 Xcode 的 Energy Impact、Instrument 的 Energy Log 等工具来分析和定位性能消耗的大户，进行针对性的优化。

---

在 iOS 上，如何使用系统能力来减少 GPU 和 CPU 之间的数据拷贝呢？

在 iOS 上，使用设置了 kCVPixelBufferIOSurfacePropertiesKey 属性的 CVPixelBufferRef 是可以支持 GPU 和 CPU 共享内存的。从相机采集出来的、从 VideoToolbox 解码出来的 CVPixelBufferRef 都具有这个属性，所以通常来讲使用系统的 API 时，你并不太需要操心这个问题。

如果你要自己创建一个图像来进行渲染，还希望能读出其数据做其他处理，并且希望支持 GPU 和 CPU 共享内存，可以参考下面的文章：

About Texture Cache