背景

某次嘉宾直播重保项目中，直播中出现了声音卡顿、爆音问题，经过排查得出一个结论：嘉宾直播时手机处于充电状态，手机出现发热导致降频，发热降频导致系统采集线程调度出现问题，属于系统行为，影响到系统采集的输入输出，最终出现声音异常问题。

团队通过业务埋点发现，对应时刻（20:36），嘉宾的电池状态显示在充电(state=2)，但不是低电量模式，CPU 占比 131%。

经验分析

从嘉宾侧反馈的信息中，可以抽出几个关键信息：

1. 开播时没有出现问题，从 20:36 开始，说明：直播持续了一段时间后才出现；

2. 强杀 App 重开也不行，说明：出现异常后，无法恢复，都说重启大法好，其实就是为了排除或者说是恢复命中的异常条件导致的问题，结果这次不好用了；

3. 存在充电和发热情况，且 CPU 占比达 131%。

从前两个点可以分析出，大概率原因不在代码里。第三点采集到的 CPU 数据异常高，过往经验正常的值应该在 50 - 60 左右。由此推测是命中降频了。

IOS11.1 以上系统都有降频策略；系统>=iOS13.1，默认开启降频功能，但用户可以手动选择关闭。iOS 系统常见的降频策略有：

1. 如果主动设置了省电模式，系统会主动降频。

2. 如果硬件设备老化，如电池老化（设置->电池容量峰值<80%），也会出现降频。

3. CPU 占用上升较快时，会加快降频。

如何避免 iOS 发热降频导致直播声音卡顿、爆音问题

重保增加约束

1. 项目重保时，约束用户手机至少保持 80% 以上的电量，最好是充满。如果无法保证电量充足的条件，则需要指导用户手动设定低电流时禁止开启低电量模式（节能模式），建议用户不要一边直播一边充电。

2. 部分重保场景，推荐主播用水冷，降低手机发热出现几率；

3. 采用性能更好的 iphone 机型，这里的性能更好并不完全等价于更高端，而是跟系统版本和特定机型都有关系，比如 14.5.1 版本系统就被吐槽降频严重，以及过往经验显示 iPhone X 发热后降频非常严重。

优化降低能耗

在正常情况下，我们可以进一步优化能耗，从而降低发热的可能性，或让发热来的更慢一些。这里提几点：

1. 为需要保证实时性的任务提供更高优先级的线程。

2. 有效地使用网络至关重要，尽可能通过减少调度事务以及使用高效的 API 来消除开销成本。网络传输是直播场景的能耗大头。

3. 对繁重开销大的线程任务进行分析，尝试优化线程执行任务的复杂度。例如避免不必要的数据拷贝，降低算法逻辑的时间控件复杂度（算法实时性简化），或者利用SIMD指令集进行并行化处理；以上这些手段的最终目的就是降低 CPU 在单个函数/线程上的执行周期。

总结

遇到这类案例，通常情况下解释难度较大，给出直播声音卡顿、爆音是由于 iOS 发热降频造成的这类结论，天然会给人一种甩锅的感觉。所以，我们更应该充分分析、拿出证据，在分析的过程中自身可以获得很多，也解决了实际问题。

本文来源：心尚传媒（https://www.xscm.cn）