解读

面试官真正想考察的是：在内存、带宽、帧率三重受限的国产手机环境（Android 4.414、iOS 1117）里，你是如何把“边下边播”做成不卡首帧、不爆内存、可断点续传、可版本回退的完整方案。只答“Unity 自带 AudioClip.loadType = Streaming”只能拿 60 分，必须给出工程级落地细节与数据佐证。

知识点

1. FMOD 底层机制：Streamed Clip 在 FMOD 里对应 FMOD_CREATESTREAM，Unity 只是封装；每次解码只读 “2 × 解码缓冲” 大小，默认 0.2 s，可改。
2. Android 文件系统：MediaExtractor 支持 offset + length 的 HTTP Range 请求，但国内 CDN 必须带 Accept-Ranges: bytes，否则整包回退。
3. iOS AVAudioEngine：支持 AVAssetResourceLoaderDelegate 做自定义协议，可把 Unity 的 StreamingAssets 重定向到本地沙盒，实现无等待首帧。
4. 内存峰值公式：峰值 = 同时流通道数 × 采样率 × 位深 × 通道数 × 缓冲秒数；44.1 kHz/16 bit/立体声/0.4 s 单路 ≈ 70 KB，10 路并发 ≈ 700 KB，仍在低端机安全线（< 1/8 总内存）。
5. 热更新兼容：Addressables 1.20+ 的 AudioClipProvider 支持把 Streamed Clip 打进 Catalog，Hash+CRC 校验失败自动重拉，解决国内弱网 302 劫持。
6. 性能黑榜：
   • 在 主线程 调用 AudioClip.length 会触发同步解码，卡顿 30 ms+；
   • 在 Shader 里 用 _Time.y 驱动音频可视化，会把 GPU 时钟拉到 500 MHz，烫手 45 ℃。

答案

“Streamed Clip 在移动端的加载策略我分四层落地。

1. 首帧策略：把首包 64 KB 打进 APK 的 StreamingAssets，启动时异步拷贝到沙盒并记录 offset；Unity 端用自定义 AudioClipProvider 把 url 重定向到本地，首帧延迟 < 100 ms。
2. 网络策略：CDN 开启 HTTP Range 与 gzip，音频文件用 VBR 96 kbps，单首 3 MB 歌曲实际下行 1.8 MB；弱网 2G 下把缓冲阈值从 0.4 s 提到 1.2 s，卡顿率从 8 % 降到 1 %。
3. 内存策略：根据机型分级——
   • 1 GB 内存以下，最大并发 4 路，缓冲 0.2 s；
   • 2 GB 以上，最大并发 10 路，缓冲 0.4 s；
     超过上限时走 LRU + 引用计数，主动调用 AudioClip.UnloadAudioData()，内存峰值始终 < 150 MB。
4. 版本回退策略：Addressables 的 Catalog 里给每个 Streamed Clip 打 CRC32 + 文件大小，下载完先写 .tmp，校验通过再 rename；失败 3 次后自动回退到内置低码率版本，保证游戏不断音。
   上线数据：在 OPPO A5（骁龙 450，3 GB 内存）连续播 50 首，CPU 占用 < 6 %，内存峰值 138 MB，零崩溃。”

拓展思考

如果项目升级为 “互动播客” 场景，需要实时多人语音 + 背景乐流化，可以把 FMOD 的 “async read” 回调接自研 UDP 通道，20 ms 一帧；同时把背景乐切成 48 kHz/24 bit 单声道，用 Opus 32 kbps 编码，单路 CPU 解码 0.3 %，整机 10 路并发仍低于 5 %。此时要把 Unity 的 AudioSettings.speakerMode 强制设为 Mono 并关闭系统重采样，避免 Android 层双倍混音导致 30 ms 延迟。