企业官网建设流程全解析

1. 先搞清楚一条声音在Unity里走过的链路

很多项目做到最后一周才开始补音效，结果就是一堆AudioSource挂在预制体上，PlayOneShot到处乱飞，手机上一开枪就掉帧，切场景时还有“啪”的一声爆音。这类问题的根子几乎都不在音效文件本身，而在于没搞清楚一条声音在 Unity3D 游戏开发里到底经过哪几道关卡。搞清楚这条链路之后，音量管理、性能优化、3D 定位这些问题会一下子变得有迹可循，而不是靠试。

我在这里把这条链路拆成三段：声源（AudioSource）产生信号 → 监听器（AudioListener）决定听到什么 → 混音器（AudioMixer）决定最终输出成什么样。绝大多数“声音听不见”“只有一边耳朵响”“切场景就没了”的怪毛病，都能对应到这三段里的某一段。下面按这个顺序讲，并且每一步都给出实际会踩到的点。

适合读这篇的人：正在做 Unity 项目、音效是临时拼凑上去、或者准备把音效系统重做一遍的开发者。代码示例用 C#，不依赖任何第三方插件。

1.1 AudioSource、AudioListener与Mixer的三段式结构

AudioSource是“喇叭”，它持有一个AudioClip，按自己的音量、音调、空间参数把声音送到音频线程。AudioListener是“耳朵”，场景里通常只有一只（默认在主摄像机身上），它决定哪些 3D 声音能被听到、听到的方向和距离关系。AudioMixer处在最后一段，所有输出到某个AudioMixerGroup的声源，都会汇入这个组，再经过组的音量、效果器和快照处理，最后到硬件。

这里第一个高频坑：AudioListener 必须唯一。相机切换、多相机分屏、UI 相机和主相机都挂着 Listener，Unity 会在 Console 里刷一条警告，实际表现是 3D 声音定位混乱，或者声音忽大忽小。我的做法是在启动脚本里主动扫描一遍，把多余的 Listener 关掉：

using UnityEngine; public class ListenerGuard : MonoBehaviour { private void Awake() { var listeners = FindObjectsOfType<AudioListener>(); for (int i = 1; i < listeners.Length; i++) { listeners[i].enabled = false; Debug.LogWarning($"多余的 AudioListener 已关闭：{listeners[i].name}"); } } }

第二个坑更隐蔽：UI 音效用了 3D 声源。按钮点击音如果 Spatial Blend 是 1，而 Listener 离它“很远”，玩家就听不到或听到极小的声音。规则很简单：UI、BGM、全局提示音一律 2D（Spatial Blend = 0），只有场景内发声的物体才用 3D。这条定死以后，能省掉大量“这个音效怎么没声”的排查时间。

第三个点关于生命周期：AudioSource.PlayClipAtPoint会临时创建一个 GameObject 播完再销毁。写起来爽，但它每次调用都产生 GC 分配，战斗特效密集的场景里频繁调用，会在 profiler 里看到明显的 GC Alloc 尖峰。这类一次性音效我全部交给对象池，第 4 节会给出完整实现。

1.2 3D声音的三个旋钮：Spatial Blend、距离衰减与多普勒

3D 声音的听感好不好，八成取决于三个参数的搭配，而不是音频文件质量。

Spatial Blend决定 2D 与 3D 的混合比例。实际项目里我很少用 0 和 1 这两个极端，环境氛围声常用 0.6~0.8，让它有方位感但不至于走出范围就完全消失；武器、脚步这类必须精确听声辨位的用 1。

距离衰减由Min Distance、Max Distance和Rolloff Mode三者共同决定。三种模式的差别很大，选错了会出现“远处声音反而变大”这种荒谬情况：

音量的实际计算公式是：attenuation = 1 / (1 + k * (distance - minDistance))，其中 k 由曲线在 Min 和 Max 之间的斜率决定。这就解释了一个常见现象：Min Distance 设成 0.1 时，玩家靠近到 1 米音量就掉了一大截。我的经验值是：脚步类 Min 1~2、Max 15~20；环境类 Min 3~5、Max 40；远处爆炸类 Min 10、Max 120。

多普勒（Doppler Level）默认是 1，对赛车、飞行、抛射物这类高速移动物体很有用。但它依赖物体在音频帧之间的位置差，如果物体用Transform.position硬设（比如瞬移、跟随相机的物体），会算出巨大的速度导致音调被扯得离谱。瞬移物体和挂在自己身上的音效，多普勒必须设 0，我在这上面吃过一次亏，一个传送技能的音效听起来像磁带快进。

另外还有Spread（扩散角）和Reverb Zone Mix。Spread 在 0 时是点声源，适合精确的脚步声；设到 60~90 度会让声音“包围”过来，适合大面积的环境声。Reverb Zone 则是配合场景内的混响区域使用，进入洞穴时自动切换混响参数，这个功能配合 Mixer 的 Snapshot 用起来很顺手，第 3 节细讲。

2. 音频文件进项目之前，先把导入设置定下来

音效性能问题里，有一半是导入设置埋的雷。音频文件拖进工程后，Inspector 里那几项默认值对 PC 勉强够用，对移动端基本是灾难。我见过一个项目把 200 多个 wav 全部用默认设置打进包里，结果包体多了 40MB，运行时内存里躺着 200 多份解压后的 PCM 数据。

这一节按“内存在哪里花掉、CPU 在哪里花掉”的思路来讲，每个选项都说明为什么这么选。先给一个基准换算，方便你算账：44.1kHz、16bit、单声道，每秒占 88.2KB；立体声翻倍到 176.4KB。也就是说一段 30 秒的立体声 BGM 解压后是 5.3MB。这个数字乘以你项目里同时加载的音效数量，就是内存账单。

2.1 Load Type三种模式的内存与CPU账

Load Type是这个面板上影响最大的一项，三个选项的代价完全不同：

对短音效，Decompress On Load 是唯一正确的选择。一次解压的代价换来的是零解码开销，脚步、打击这类一秒可能触发十几次的声音，用 Compressed In Memory 会让音频线程持续解码，移动端直接掉帧。代价是内存，所以短音效必须配合第 2.2 节的压缩格式与采样率下调一起用。

对 1~2 分钟以内的 BGM，Compressed In Memory比较均衡。对超过 2 分钟的长音乐（尤其是循环播放的环境铺底），用Streaming，但注意两点：一是流式播放对磁盘 IO 敏感，低端机上可能出现开头几百毫秒的延迟；二是流式加载的 clip 不要在切场景瞬间被销毁，否则会听到明显的断音。实践做法是把 BGM 挂在常驻单例上，切场景时淡出而不是直接 Stop。

还有一个容易忽略的勾选项：Preload Audio Data。勾上会在场景加载时预加载，好处是第一声不延迟，坏处是拖慢加载速度、增加常驻内存。我的原则是：高频短音效勾上，长音乐和大文件取消勾选。至于Load In Background，只对上面那个流式的长文件有意义。

2.2 压缩格式与强制单声道：3D音效最容易被忽略的一条

格式选择看两个维度：时长和是否循环。

PCM是无损，体积最大，只有在内存极其充裕且对音质有苛刻要求时才用，实际项目里几乎不用。ADPCM体积约是 PCM 的 3.5 分之一，解码开销极低，特别适合短促的打击音、UI 音。Vorbis压缩率高，音质可调，是音乐和长音效的首选，但它的解码开销比 ADPCM 高，且循环点不精确（编码器会在头尾填充数据），做无缝循环的 BGM 时容易听到接缝。MP3现在基本不推荐，主要是循环和延迟上的问题。

采样率下调是最省事的一招。人耳对脚步声、风声这类音效的高频细节并不敏感，把 Override Sample Rate 从 44100 降到 22050，文件体积和内存直接砍一半，听感几乎没差别。UI 点击音甚至可以降到 11025。有这个习惯的项目，音频内存能省出三分之一。

然后是那条几乎所有人第一遍都会踩的：3D 音效必须 Force To Mono。立体声文件用于 3D 声源时，Unity 无法正确做方位计算，表现是“声音永远从正前方来”或者方位感很怪异。判别方法很直接——只要这个音效的 Spatial Blend 大于 0，就在导入面板勾上Force To Mono。BGM 和 UI 音效保持立体声没问题。

最后一个细节是音量归一化。不同来源的音效素材响度差别很大，导入后如果整体音量差 10dB 以上，调代码时会很痛苦。我的做法是在导入前统一做一次响度对齐（把峰值归到 -3dB 左右），运行时只做微调。这件事在素材进项目时花一个小时，后面能省掉几十次“这个音效怎么这么小”的调试。

3. AudioMixer不是可选项，是音量管理的骨架

大部分小项目最初的音量控制就是直接改AudioSource.volume，做设置界面时才发现要遍历场景里所有声源，还得记住哪些是音乐哪些是音效。这套做法撑不过第一个版本。AudioMixer提供了分组、快照、效果器、侧链闪避这一整套能力，用起来并不复杂，但需要一开始就把层级定好。

一句话概括它的价值：AudioMixer 让“音量”从一个分散在每个声源上的属性，变成一个集中的、可插值、可被游戏逻辑驱动的参数。设置界面改一个滑条、过场动画压低音乐、玩家进入水下切换闷音效果，全都靠它。

3.1 Group层级与Exposed参数的组织方式

我一般建这样一棵树：

Master ├── Music │ ├── BGM │ └── Stinger（过场短乐） ├── SFX │ ├── Player │ ├── Enemy │ ├── Ambient │ └── UI └── Voice

分组的粒度以“设置界面会单独暴露给玩家的滑条数量”为准，不要为了整齐分太细。三层已经足够，再细就只是增加维护成本。

关键动作是给 Group 的 Volume 参数右键 Expose 到脚本，然后在 Mixer 面板顶部能看到它被重命名（建议改成MasterVolume、MusicVolume、SFXVolume这种一眼能认的名字）。之后代码里改音量必须走 dB 换算，这是新手最容易搞错的一步：

using UnityEngine; using UnityEngine.Audio; public class VolumeControl : MonoBehaviour { [SerializeField] private AudioMixer mixer; // UI 滑条给的是 0~1 的线性值，Mixer 要的是 dB public void SetVolume(string exposedParam, float linear01) { float clamped = Mathf.Clamp(linear01, 0.0001f, 1f); // 避免 log10(0) = -Infinity mixer.SetFloat(exposedParam, Mathf.Log10(clamped) * 20f); } public float GetVolume(string exposedParam) { if (mixer.GetFloat(exposedParam, out float db)) { return Mathf.Pow(10f, db / 20f); } return 0f; } }

为什么必须换算？因为 Mixer 的 Volume 单位是分贝。UI 滑条拉到一半（0.5）时，如果直接把 0.5 塞进去，实际听到的音量大约是线性值的 0.7 倍左右，玩家的直觉是“滑条过半声音反而更大”，体验很怪。用log10换算之后，滑条位置和主观响度才基本对齐。

还有一条硬性提醒：AudioMixer 资源必须在 Assets 里存在并被引用，不能在运行时 new。同时要确认 Mixer 资源被打进了包体（放在 Resources 或 Addressables 里，或通过场景引用），我见过打包后设置界面滑条失效的情况，就是因为 Mixer 引用在构建时被裁掉了。

3.2 Snapshot切换与Duck侧链：做“音乐让路”和“水下闷音”

Snapshot 是 Mixer 里最实用的功能之一。它记录当前所有 Group 的音量、效果器参数，切换时按设定的过渡时间插值过去。典型用法有三种：

过场压低音乐：做一个Ducking快照，把 Music 组压到 -12dB，SFX 保持不变，切换时间设 0.3 秒。播剧情对话时TransitionToSnapshots，结束后切回Normal，比手写插值协程稳得多。

水下/洞穴闷音：新建一个快照，在 Master 或 SFX 组上挂一个 Lowpass 效果器，Cutoff 拉到 800Hz 左右，进入水下触发。同时可以给一个 Reverb 效果器加一点空间感。

暂停菜单：做一个Paused快照，把 SFX 组压下去但保留 UI 音效，避免暂停后按钮音效也被一起压掉——这种做法比用AudioListener.pause粗暴地全停要细致得多。

Duck 侧链（Sidechain）是另一个高频需求。做法是在 Voice 组上加一个Send效果器，目标选Ducking；再给 Music 组加一个Receive效果器，Receive 的 Duck Volume 设 -8dB、Threshold 设 -30dB 左右。效果是：只要有语音或重要音效在播，音乐自动往下让；播完自动恢复。

// 用代码短暂压低音乐，适用于播报、Boss 出场等 public void DuckMusic(float duration = 1.5f) { StartCoroutine(DuckRoutine(duration)); } private System.Collections.IEnumerator DuckRoutine(float duration) { mixer.SetFloat("MusicVolume", -12f); yield return new WaitForSecondsRealtime(duration); mixer.SetFloat("MusicVolume", Mathf.Log10(0.7f) * 20f); // 恢复到约 0.7 }

注意这里用WaitForSecondsRealtime。如果游戏里Time.timeScale被改成 0（比如暂停或子弹时间），用普通的WaitForSeconds会让这段压低永远不恢复，音乐一直是闷的。这个坑很典型，而且很难在编辑器里复现，因为通常是有时间缩放的场景才会暴露。

4. 用对象池接管播放请求，别让PlayOneShot满天飞

先说结论：正式项目里，除了极少数确定只播一次的声音，其余全部走统一的播放入口。原因不是“架构好看”，而是三个具体的痛点：无法统一限流、无法统一做随机化、无法在设置里关掉某一类音效。

Unity 默认的Max Real Voices是 32（在 Project Settings 的 Audio 里可调）。这意味着同时超过 32 个声源时，超出的会被“虚拟化”——听起来就是某些音效莫名其妙不响了。战斗密集时，如果每个子弹、每次命中都各占一个AudioSource，32 个额度会在半秒内被吃干净，玩家的脚步声反而没了。这不是 bug，是资源竞争。

4.1 一个可用的轻量AudioManager骨架

思路是：预先创建固定数量的AudioSource池子，每次播放请求从池里找一个空闲的，找不到就丢弃（或按优先级抢占最低优先级的那一个）。丢弃比抢占更安全，因为抢占会导致正在播的重要音效被切断，听感上很突兀。

using System.Collections.Generic; using UnityEngine; using UnityEngine.Audio; public class AudioManager : MonoBehaviour { public static AudioManager Instance { get; private set; } [System.Serializable] public class SfxDef { public string key; public AudioClip[] clips; // 同一语义的多个素材，随机选 [Range(0f, 1f)] public float volume = 1f; [Range(0f, 0.3f)] public float pitchJitter = 0.06f; public float cooldown = 0.05f; // 同一 key 的最小触发间隔 } [SerializeField] private SfxDef[] defs; [SerializeField] private AudioMixerGroup sfxGroup; [SerializeField] private int poolSize = 24; private readonly Dictionary<string, SfxDef> _map = new Dictionary<string, SfxDef>(); private readonly Dictionary<string, float> _lastPlay = new Dictionary<string, float>(); private AudioSource[] _pool; private int _cursor; private void Awake() { if (Instance != null && Instance != this) { Destroy(gameObject); return; } Instance = this; DontDestroyOnLoad(gameObject); _pool = new AudioSource[poolSize]; for (int i = 0; i < poolSize; i++) { var go = new GameObject($"Sfx_{i}"); go.transform.SetParent(transform); var src = go.AddComponent<AudioSource>(); src.playOnAwake = false; src.spatialBlend = 1f; src.rolloffMode = AudioRolloffMode.Logarithmic; src.minDistance = 1.5f; src.maxDistance = 25f; src.dopplerLevel = 0f; src.outputAudioMixerGroup = sfxGroup; _pool[i] = src; } foreach (var d in defs) _map[d.key] = d; } public void Play(string key, Vector3 worldPos, float volumeScale = 1f) { if (!_map.TryGetValue(key, out var def) || def.clips == null || def.clips.Length == 0) return; float now = Time.unscaledTime; if (_lastPlay.TryGetValue(key, out float last) && now - last < def.cooldown) return; _lastPlay[key] = now; AudioSource src = GetFreeSource(); if (src == null) return; // 池满，直接丢弃 src.transform.position = worldPos; src.clip = def.clips[Random.Range(0, def.clips.Length)]; src.volume = def.volume * volumeScale; src.pitch = 1f + Random.Range(-def.pitchJitter, def.pitchJitter); src.Play(); } private AudioSource GetFreeSource() { for (int i = 0; i < _pool.Length; i++) { int idx = (_cursor + i) % _pool.Length; if (!_pool[idx].isPlaying) { _cursor = (idx + 1) % _pool.Length; return _pool[idx]; } } return null; } }

池子大小怎么定？经验公式是：常驻并发音效数量 × 1.5，向上取整。动作类项目 16~24 个够用；策略类、休闲类 8~12 个足够。设太大只是浪费内存，每个空AudioSource本身的开销很小，但被占用时音频线程的混合成本会上去。

还有一个细节：池子里的AudioSource挂在AudioManager下面，而AudioManager是DontDestroyOnLoad的。这意味着切场景时这些声源不会跟着被销毁，正在播的声音会继续播——这正好是我们要的效果（切场景的余音不会突兀切断），但也要求你在切场景时主动调用一次淡出，第 5 节会讲。

播放时的pitch随机化是我最推荐的一个小改动。同一个脚步 clip 连播三四次，玩家会明显听出“机关枪感”；加上 ±6% 的音调抖动后，几乎听不出来是同一份素材。代价是pitch修改会影响播放速度，所以对节奏类音效（比如需要严格对齐节拍的声音）不能抖。

提示：如果某个声音必须精确控制起始时间（音乐、节拍音），不要走池子，用独立AudioSource配合PlayScheduled。

4.2 随机音调、音效轮换与冷却：消除“机关枪感”

上节的代码里有三个抗重复的手段，值得单独说一下为什么这么配。

素材轮换是最有效的。同一语义准备 3~5 个变体（脚步声准备 4 个、命中音准备 3 个），随机挑选。这要求美术/音频侧在交付时就按组打包，命名规范统一前缀，比如sfx_footstep_01~04。这件事在素材交付阶段沟通一次，后面全是收益。

音调抖动的比例要克制。±5% 到 ±10% 比较自然，超过 15% 就会变成“变声器”效果。注意随机范围要上下对称，否则长期平均值会偏移，听感上整体音调被拉高或压低。

冷却时间解决的是“同一帧多个触发源”的问题。比如一次范围伤害命中 10 个敌人，如果每个都播一次命中音，声音会叠加成一片噪音，音量还会因为相位叠加而突变。给这种 key 设 0.05~0.1 秒冷却，实际听感反而更结实。反过来，如果是需要体现“连击数”的音效，冷却就不该用，而应该按连击等级切换不同的 clip。

表格对照一下这三者的配置建议：

最后再补一个“优先级”的概念。上面代码里池子满了就丢弃，但更好的做法是给每个 key 一个优先级，池满时与正在播的最低优先级比较，只有更高才抢占。不过说实话，只要池子大小设得合理、冷却配得当，抢占逻辑在中小项目里几乎不会触发，反而增加了调试复杂度。我现在的做法是先用最简单的丢弃策略，等真的观测到重要音效丢失，再补优先级。

5. 实测踩过的坑：切场景爆音、移动端功耗与节奏对齐

前面四节是“该怎么搭”，这一节是“搭完之后会遇到什么”。这几个问题都有共同点：在编辑器里跑得好好的，打包到真机上或者在特定流程里才暴露，排查起来很费时间。我把现象、原因和修法都列出来，方便直接对照。

5.1 切场景、暂停与销毁阶段的残留与爆音

爆音（pop）的成因基本是波形被硬切。一段声音在振幅非零的位置被Stop()，扬声器会收到一个突变，听感上就是“啪”。解法是淡出：在停止前用 0.05~0.1 秒把音量插值到 0，再 Stop。AudioSource没有内置淡出，得自己写协程，或者用 Mixer 的 Snapshot 过渡（更平滑，推荐）。

private System.Collections.IEnumerator FadeOutAndStop(AudioSource src, float duration = 0.08f) { float start = src.volume; float t = 0f; while (t < duration) { t += Time.unscaledDeltaTime; src.volume = Mathf.Lerp(start, 0f, t / duration); yield return null; } src.Stop(); src.volume = start; // 复原，供池子复用 }

切场景后声音残留：如果AudioManager是常驻的，切场景时正在播的环境声会一直播下去，直到播完。表现是新场景里还听得到旧场景的风声。修法是在场景加载前主动调用一次“淡出所有非音乐声源”。

暂停时声音没停：AudioListener.pause = true会暂停所有声音，但它有两个副作用——一是它影响全局，连 UI 音效也一起停了，暂停菜单的按钮音效就没了；二是恢复时要记得置回 false。更可控的做法是用 Mixer 快照，把 SFX 和 Music 组压到 -80dB，UI 组保持不变。

销毁时爆音：直接Destroy(gameObject)一个正在播放的声源，会立即切断波形。场景切换、对象回收时很容易出现。稳妥的做法是给需要在销毁时淡出的对象挂一个小组件，在OnDisable里先淡出再销毁，或者干脆让音效由常驻的 AudioManager 播，与对象生命周期解耦——这也是我一直推荐走统一入口的原因之一。

5.2 移动端与后台切换的真实损耗

移动端的音频问题集中在三点：功耗、内存、后台行为。

功耗这块，最耗电的不是解码，而是同时活跃的声源数量和每帧的音频线程混合。所以在移动端，池子大小应该比 PC 小（我把 24 降到 12 是常见配置），同时用AudioSource.ignoreListenerPause这类细节控制好哪些声音在暂停时继续。

内存上，前面说的采样率下调、Force To Mono、短音效用 ADPCM，这三招在移动端的收益非常明显。一个实测数据是：50 个 1 秒的立体声 44.1kHz 音效，全部改单声道 + 22050Hz + ADPCM 后，内存占用从约 8.8MB 降到约 0.6MB，差距一个数量级。

后台切换必须处理。切到后台时游戏通常会暂停，但如果音频还在播，用户会听到游戏声音从后台传出来，体验很差。标准做法是：

private void OnApplicationFocus(bool hasFocus) { if (!Application.isMobilePlatform) return; AudioListener.pause = !hasFocus; } private void OnApplicationPause(bool paused) { AudioListener.pause = paused; }

要注意的是，AudioListener.pause只是暂停，不释放音频资源；恢复时如果发现某些短音效在暂停期间被触发过，可能会出现“一恢复就同时放出一堆”的情况。解决办法是把播放入口在暂停期间直接返回（在AudioManager.Play开头加一个if (IsPaused) return;），从源头掐断。

另外还有一个低端机上常见的现象：首次播放某个音效有 100~300ms 的延迟。原因是 clip 采用的是 Compressed In Memory 且没勾 Preload，第一次解码时要从内存读压缩数据。把高频音效设为 Decompress On Load + Preload 就能解决，代价是内存，这个权衡自己按项目情况定。

5.3 节奏类玩法必须用DSP时间而不是deltaTime

如果项目里有任何需要“卡拍”的玩法——音乐节奏、QTE 跟着节拍、Boss 技能的节奏提示——那就不能用Time.deltaTime累加来算节拍。原因是主线程时间受帧率波动影响，而音频是在独立的音频线程上按固定采样率走的，两者不同步。帧率掉到 30 时，按 deltaTime 算出来的“节拍点”会明显漂移，玩家会觉得判定不准。

正确的做法是用AudioSettings.dspTime，它是音频系统的时钟，单位是秒，精度高且与音频线程同步：

using UnityEngine; public class BeatTimer : MonoBehaviour { private double _nextBeatDsp; private double _beatInterval; public void StartClock(float bpm) { _beatInterval = 60.0 / bpm; _nextBeatDsp = AudioSettings.dspTime + 0.1; // 留一点预热时间 } private void Update() { if (AudioSettings.dspTime + 0.05 >= _nextBeatDsp) { OnBeat(); _nextBeatDsp += _beatInterval; } } private void OnBeat() { // 触发节拍逻辑：判定、提示、特效 } }

这里有个小技巧：判断条件用dspTime + 0.05 >= 下一拍，也就是提前 50ms 触发。因为音频输出本身有延迟（下一段会讲），提前一点触发视觉表现，玩家看到和听到的才是一致的。

延迟的根源在音频缓冲。Project Settings 的 Audio 里有个DSP Buffer Size，四档对应不同的缓冲区大小，采样率 44100 下的换算关系大致是：

实际输出延迟还要加上双缓冲和系统层的开销，通常是最低延迟的两倍左右。所以追求精准判定的项目，设成 Good Latency 之后，还要在游戏内提供一个“延迟校准”让玩家自己调偏移量，这几乎是所有节奏游戏的标配功能。

如果要用音乐作为节拍基准，那就更该用PlayScheduled把第一拍精确对齐到某个 dsp 时刻：

double startTime = AudioSettings.dspTime + 1.0; // 1 秒后开始 musicSource.PlayScheduled(startTime);

用Play()直接起播的话，实际发声时刻取决于调用时主线程的帧位置，误差可能达到一帧（16~33ms）。而PlayScheduled是把时刻交给音频线程调度，误差在一个采样级别。

最后分享一个我在调音效时养成的习惯：每加一个音效，都先在真机上听一遍，而不是只在编辑器里听。编辑器的音频路径和真机不一样，采样率、缓冲、系统音效处理都可能有差异，很多“编辑器里好好的、手机上很刺耳”的问题，只有在真机上第一耳朵就能发现。项目周期里我会专门留出两个下午做这个动作——把所有音效按触发场景在真机上过一遍，记下刺耳的、听不清的、重复感强的，一次性调整参数。这比后期零散地改要高效得多，而且能避免很多上线后才被玩家指出来的听感问题。