音乐先解码为 PCM 采样，再经过走带与机架处理，最后交给 Android 音频输出。系统与耳机还可能排队、重采样或编码；某一段缓存的大小不等于从手指动作到听见声音的总延迟。

一帧 PCM 包含同一时刻各声道的采样；处理块是一批音频帧。帧数换算成时间需要采样率，不能把界面帧率或一个处理块直接当作听觉延迟。

建议使用有线耳机。开发者对拨轮和摇晃操作的实测中，改用有线耳机解决了蓝牙路径下明显的可闻滞后；实际响应仍取决于手机、系统与输出设备。

前台输出以设备最小缓冲要求为下限，并结合约 30 ms 的请求量，减少输出队列积压，让走带操作更快反映到后续声音。

播放最多保留四个预读窗口，并用上限为 16 MiB、按需占用的解码复用缓存减少重复解码，同时约束内存使用。预读和复用不代表把整首曲目或这么多数据排队送到耳机。

预读窗口、解码结果缓存和设备输出缓冲承担不同职责。讨论延迟时，需要区分这些位置，不能把内存容量直接换算成实际输出延迟。

效果链在音频块边界更新，约 20 ms 的新旧链过渡帮助衔接声音。过渡可能短时增加处理负载，但不能仅凭这个机制认定它是噼啪的根因。Android 只接收一块音频的一部分时，后续继续提交已处理的剩余数据，不重复执行效果处理。

旁通会改变听到的结果，但实例仍计算以维持状态。要减少处理负载，应移除暂时不需要的实例。

出现噼啪时，先检查效果链输出峰值、降低过高的效果器增益，排查幅度削波；再移除暂时不需要的效果器，比较处理负载。音频供给赶不上播放会欠载，过高峰值则可能削波。过载灯反映峰值，不能用来确认欠载；这些步骤帮助缩小范围，不等于确诊。

进入后台后，以正常 1 倍速批量提交 PCM 音频，并保留机架处理。空机架请求约 200 ms 缓冲，有效果器时请求约 600 ms，实际受已分配容量限制。

较大的后台缓冲为系统调度抖动留出余量；如果持续处理不过来，仍可能欠载。回到前台后恢复较小的缓冲设置，但已经排队的声音仍需按顺序输出。

拨轮绘制只保留最新状态，至多一个待绘任务，减少旧状态积压。画面更新与音频输出是不同路径；蓝牙造成的可闻滞后不能直接解释画面掉帧。

应用切到后台、熄屏或关闭相应功能时，停止对应姿态传感器读取并释放监听。动态反光改变光影，不改变声音；摇晃模拟对声音的影响由独立开关控制。

目前公开的是开发者对有线与蓝牙输出的定性观察，尚未公布带完整条件、可复现的端到端延迟、处理负载或耗电测量数值。

比较这些指标时，需要记录手机型号、系统版本、输出设备和连接方式、采样率、效果链以及同一测试片段。请求量和缓存目标不能代替实测；十个机架位置表示组合容量，不保证任意组合都流畅，也不承诺固定延迟或节电幅度。