某次嘉宾直播重保项目中，直播中出现了声音卡顿、爆音问题，经过排查得出一个结论：嘉宾直播时手机处于充电状态，手机出现发热导致降频，发热降频导致系统采集线程调度出现问题，属于系统行为，影响到系统采集的输入输出，最终出现声音异常问题。
该结论乍一听似乎没什么说服力，很容易让人不认同这个结论，并且有一些质疑问题，比如：
很多同学都知道 iOS 发热降频这个事情，但是可能不太清楚如何量化影响、如何系统化或者说量化去分析。
本文将基于这个典型案例，做一个系统性的分析，分享 iOS 发热降频的基本概念与处理经验，希望能够解决大家对 iOS 发热降频的一些疑惑，帮助大家在下次遇到类似问题时，能够知道如何分析问题、如何发现证据、如何解决问题。
AURemoteIO:IOThread 是系统创建专门用于采集和播放或者说是输入、输出的线程，有两个特点：
概述
由于 Mach 具有处理器集的抽象，所以从某个角度说，Mach 比 Linux 和 Windows 更擅长管理多核处理器。
上下文切换
暂停某个线程的执行，并且将其寄存器状态记录在某个预定义的内存位置中。当一个线程被抢占时，CPU 寄存器中会记住另一个线程保存的线程状态，从而恢复那个线程的执行。
一个线程在 CPU 上可以执行任意长的时间。CPU 寄存器中填满了线程的状态，这个执行过程一直在延续，直到发生下面某种情况：
优先级
每一个线程都被分配了优先级，优先级直接影响线程被调度的频率。每一个操作系统都提供了一个这种优先级的范围：Windows 有 32 个优先级，Linux 有 140 个优先级，Mach 有 128 个优先级。
内核线程的最低优先级为 80，比用户态线程的优先级要高。可以保证内核以及用户维护管理的线程能够抢占用户态的线程。
苹果系统在进入低电量模式时都会回收一部分系统资源，降低处理器主频来保证系统的稳定性，也就是我们俗称的降频。
在需要更极端的性能管理的情况下，用户可能会发现以下影响：