直播案例剖析：手机降频对直播声音体验的影响_UTF_8

小鋺豆

背景某次嘉宾直播重保项目中，直播中出现了声音卡顿、爆音问题，经过排查得出一个结论：嘉宾直播时手机处于充电状态，手机出现发热导致降频，发热降频导致系统采集线程调度出现问题，属于系统行为，影响到系统采集的输入输出，最终出现声音异常问题。该结论乍一听似乎没什么说服力，很容易让人不认同这个结论，并且有一些质疑问题，比如：问题一：如果是性能问题，为什么她说话感觉不卡，而是爆音的现象？问题二：通过对音视频采集的埋点等信息能更精确的定位吗？“发热降频导致的系统采集线程调度出问题，属于系统行为”是明确结论还是推断？怎么判定的？问题三：CPU 为什么异常变高？很多同学都知道 iOS 发热降频这个事情，但是可能不太清楚如何量化影响、如何系统化或者说量化去分析。本文将基于这个典型案例，做一个系统性的分析，分享 iOS 发热降频的基本概念与处理经验，希望能够解决大家对 iOS 发热降频的一些疑惑，帮助大家在下次遇到类似问题时，能够知道如何分析问题、如何发现证据、如何解决问题。基本概念AURemoteIO 线程AURemoteIO:IOThread 是系统创建专门用于采集和播放或者说是输入、输出的线程，有两个特点：输入输出是串行的，所以相互之间会受到影响；线程回调时间是稳定的，且要求实时性非常高，如果存在阻塞，会导致输入输出都受到影响，出现声音异常。异常现象会根据阻塞程度不同而不同，轻微阻塞采集数据不连续，严重一些会明显感觉卡顿、爆音，极其严重的情况会直接导致采集线程关掉出无声数据，这一点解释了背景中提到的问题一。iOS 的线程调度概述由于 Mach 具有处理器集的抽象，所以从某个角度说，Mach 比 Linux 和 Windows 更擅长管理多核处理器。上下文切换暂停某个线程的执行，并且将其寄存器状态记录在某个预定义的内存位置中。当一个线程被抢占时，CPU 寄存器中会记住另一个线程保存的线程状态，从而恢复那个线程的执行。一个线程在 CPU 上可以执行任意长的时间。CPU 寄存器中填满了线程的状态，这个执行过程一直在延续，直到发生下面某种情况：线程终止线程自愿放弃外部中断打断了线程的执行，外部中断要求 CPU 保存线程状态并且立即执行中断处理代码优先级每一个线程都被分配了优先级，优先级直接影响线程被调度的频率。每一个操作系统都提供了一个这种优先级的范围：Windows 有 32 个优先级，Linux 有 140 个优先级，Mach 有 128 个优先级。内核线程的最低优先级为 80，比用户态线程的优先级要高。可以保证内核以及用户维护管理的线程能够抢占用户态的线程。iPhone 性能与电池的关系苹果系统在进入低电量模式时都会回收一部分系统资源，降低处理器主频来保证系统的稳定性，也就是我们俗称的降频。在需要更极端的性能管理的情况下，用户可能会发现以下影响：App 启动时间变长滚动时帧速率降低背光灯变暗（可在“控制中心”手动调整）扬声器音量降低幅度高达 -3dB部分 App 的帧速率逐渐降低在最极端的情况下，相机闪光灯会被停用（会显示在相机用户界面上）在后台刷新的 App 在启动时可能需要重新载入iOS11.1 以上系统都有降频策略；系统>=iOS13.1，默认开启降频功能，但用户可以手动选择关闭。iOS 系统常见的降频策略有：如果主动设置了省电模式，系统会主动降频。如果硬件设备老化，如电池老化（设置->电池容量峰值