如果你是一名 Android 开发者，尤其是做过多媒体、语音助手或者车载开发的工程师，你一定在某个深夜对着 AudioManager 破口大骂过。
小弟不才，我刚骂完。
起因是我正在做一个 AOSP 项目，开发一个非常复杂的 App - Launcher。
这个 App 支持语音的各种操作，目前就在改一个 Bug —— 焦点抢占导致其他 App 的音乐播放有问题。
今天，我们就以一场“抬杠”式的对话，彻底扒下 Android 音频焦点（Audio Focus）那层令人费解的外衣。
出场人物：
- 暴躁老哥（我）： 饱受 Audio Focus 折磨的 Android 开发，今天专程来找茬。
- Android 田文镜： 见多识广的老油条，专注于解答（并忍受）各种刁钻问题。
第一回合：这到底是个什么反人类设计
暴躁老哥： 田文镜！我就问你，Android 的音频焦点申请到底是怎么设计的？我觉得好难用啊！为了放个声音，我还要写一堆错综复杂的状态机，别人抢了还要管，这是什么反人类的设计？
内心OS： 无数个日夜，我都在与第三方扯皮音频焦点的 Bug ，这个 Bug 最糟糕的河西在于——最终谁去改！有些 App 根本不遵循音频焦点的设计原则，根本无法让他暂停播放！
Android 田文镜： （喝了口茶）年轻人，火气不要这么大。你觉得难用，是因为你没有理解它的核心设计理念。
Android 是一个多任务系统，但人类的耳朵在同一时间只能接受单一（或极少数）的主音频流。想象一下：你正在听歌，这时候导航突然大声播报，微信又弹出一个超大声的提示音，后台还有一个带声音的广告——这绝对是一场听觉灾难。
为了解决冲突，Google 设计了 Audio Focus。但它早期的核心思想是一个“君子协议”，而不是底层强制锁：
- 系统是一个大喇叭： 当你申请焦点时，系统会通知之前占用焦点的 App：“老哥，焦点被别人抢了。”
- 如何响应全靠自觉： 至于被抢的 App 是暂停、降低音量，还是假装没听见继续“头铁”播放，系统早年是完全不管的。它把处理复杂冲突的责任推给了开发者。
特别是如果你在做车机系统，这套规则就变成了“独裁统治”。
车机底层的 CarAudioService 接管了焦点，维护了严密的并发矩阵。导航发声时，根本不需要你同意，底层会直接对音乐进行硬件级压音（Ducking）甚至静音（Muting）。这也是为什么车机的焦点管理让人觉得更加受限。
第二回合：有本事你一口气背出所有的焦点类型
暴躁老哥： 行吧，就算它是君子协议。但你别以为我好糊弄，API 文档里那一大堆参数我看都看晕了。你要是能一口气把获取焦点的方式全列出来，我当场......叫你大师！
内心OS： 我真的不相信这世界上有人能一口气背出音频焦点所有的获取方式！
Android 田文镜： （冷笑）这有何难？听好了，Android 申请焦点总共就四大门派，搞懂了它们，你就出师了：
-
AUDIOFOCUS_GAIN（长住霸占型）：
- 特点： 申请长期的、未知时长的焦点。
- 场景： 音乐播放器、长视频 App、播客。当你准备长时间霸占扬声器，并且希望其他背景音乐“彻底死心”并释放资源时用它。
-
AUDIOFOCUS_GAIN_TRANSIENT（短暂借用型）：
- 特点： 申请短暂的焦点，用完马上还。系统允许其他应用的提示音与你混音。
- 场景： 导航播报、语音助手的回答（TTS播报）。比如导航说“前方路口左转”时，让背景音乐暂停一下，播完让音乐继续。
-
AUDIOFOCUS_GAIN_TRANSIENT_MAY_DUCK（短租温柔型）：
- 特点： 申请短暂焦点，而且态度极其温柔。它告诉被抢的人：“你不用暂停，只需要把音量降低（Duck）一点点就行，我插句话”。
- 场景： 微信提示音、导航播报（允许混音时）。比如你听歌时导航说话，音乐声音变小，导航说完音乐声音恢复正常。这种体验比直接暂停更连贯。
-
AUDIOFOCUS_GAIN_TRANSIENT_EXCLUSIVE（短租且绝对霸道型）：
- 特点： 申请短暂焦点，且要求“绝对排他”。占用期间系统会严格屏蔽其他一切提示音和按键音。
- 场景： 语音唤醒/识别（ASR）、警告提示、录音。当你录音时，绝对不允许系统发出“叮”的一声混进录音里导致识别失败或者其他杂音问题。
第三回合：GAIN 和 EXCLUSIVE，傻傻分不清楚
暴躁老哥： 行吧，大师。那我问你个具体的，AUDIOFOCUS_GAIN 和 AUDIOFOCUS_GAIN_TRANSIENT_EXCLUSIVE 这两个参数有什么区别，不都是“我要抢占焦点”吗？
内心OS： 既然都是抢占焦点，能有什么区别？
Android 田文镜： 这两者在使用场景和系统底层处理方式上有着天壤之别！用一句话概括：
GAIN 是“我要长住，请大家让座”，而 EXCLUSIVE 是“我短住，但是要求绝对安静，谁也别出声”。
-
AUDIOFOCUS_GAIN（长期的常规独占）：
- 含义： 你不知道要播多久，通常是很长时间。
- 别人怎么想： 正在放歌的 App 会收到
LOSS（永久失去）。它应该彻底停止播放并释放资源。 - 包容度： 它允许系统的其他提示音混进来。听歌时来微信，你会听到“叮”的一声，音乐不会断。
- 场景： 音乐播放器、长视频、播客。
-
AUDIOFOCUS_GAIN_TRANSIENT_EXCLUSIVE（短暂的排他独占）：
- 含义： 占用时间很短，马上就还。
- 别人怎么想： 放歌的 App 会收到
LOSS_TRANSIENT（短暂失去），乖乖暂停等待。 - 霸道程度（核心区别）： 极其霸道！系统会尽可能保证在你占用期间，没有任何声音干扰你。系统的按键音、通知音统统被静音或阻止。
- 场景： 语音唤醒/识别（ASR）、录像机。你总不希望用户喊“你好语音助手”时，录进去一声微信的“叮”导致识别失败吧？
排他——意味着在这个时间内，别的声音是不允许说话的！
你仔细想想这种设计理念，AUDIOFOCUS_GAIN 这种长期的占用如果还是排他的，是不是特别不合理；但是如果你真的希望排他独占，那么就只能短暂的，不能长时间的！
第四回合：那 TRANSIENT 和 EXCLUSIVE 又有啥区别
暴躁老哥： 等等，那 AUDIOFOCUS_GAIN_TRANSIENT 和 AUDIOFOCUS_GAIN_TRANSIENT_EXCLUSIVE 呢？既然都是带 TRANSIENT，说明都是短时间占用，这俩又有什么区别？
内心OS： 我不信短暂占用还能有区别？
Android 田文镜： 你的盲点又来了！既然都是 TRANSIENT，那对于被抢焦点的音乐 App 来说，完全没有区别，它收到的都是 LOSS_TRANSIENT，都会乖乖暂停。
它们的区别在于系统对“第三方干扰音”的态度。
打个通俗的比方：
-
TRANSIENT（短暂发言）：
你在会议室放着背景音乐，突然站起来说：“音乐停一下，我插两句话。”（音乐暂停）。这时候如果旁边同事的手机来微信了，“叮”的一声你是能听到的。场景： 导航播报、语音助手回答（TTS播报）。
-
TRANSIENT_EXCLUSIVE（机密录音）：
你站起来说：“音乐停一下，现在我要录音了，所有人手机静音，任何人不许咳嗽！”（音乐暂停，且系统强制屏蔽所有杂音）。场景： 麦克风开始收音时。
第五回合：终极刁难 —— 快进快出的 GAIN
暴躁老哥： （摸了摸下巴）我好像懂了点。那我给你出一个绝的：我申请 AUDIOFOCUS_GAIN，但是过个 5 秒钟我就立刻调用 abandonAudioFocus 释放掉！反正都是用一下就还回去，这不就和 AUDIOFOCUS_GAIN_TRANSIENT 一模一样了吗？我还背那么多参数干嘛！
内心OS： 系统怎么知道我是快进快出？
Android 田文镜： （猛拍大腿），嘿，你TND，还真是个天才！
绝对不行，这是极其糟糕的做法！你只站在了你自己的视角，完全没有考虑被你抢走焦点的“受害者”的感受！
区别不在于你实际占用了多久，而在于系统发给别人的“契约”是不一样的。
-
如果你用 TRANSIENT 然后释放： 系统告诉音乐 App
LOSS_TRANSIENT。音乐 App 想：“他马上回来”，于是它仅仅暂停（Pause），原地待命。5秒后你释放，音乐 App 收到GAIN，自动无缝恢复播放，体验丝滑。 -
如果你用 GAIN 然后立刻释放： 系统告诉音乐 App
LOSS。音乐 App 心灰意冷：“主人不需要我了”，于是它不仅暂停，还彻底销毁了播放器实例，甚至清理了通知栏。5秒后你释放，焦点空闲了，但音乐 App 绝对不会自动恢复播放。用户会骂街：“你的破软件把我的后台音乐彻底杀掉了？！”
暴躁老哥： 卧槽？！那我 abandon 之后，那个音乐 App 难道收不到 GAIN 的通知重新活过来吗？
Android 田文镜： 绝大多数情况下，收不到！
因为底层的 AudioManager 维护了一个焦点栈（Audio Focus Stack）。
当音乐 App 收到 LOSS 时，正常的逻辑是它不仅停止播放，还会主动调用 abandonAudioFocus，将自己从焦点栈中彻底移除！。
等你 5 秒后释放焦点时，系统往下看，发现栈已经空了。没有任何人排队，自然也不会发通知。
从设计的逻辑上讲，AUDIOFOCUS_GAIN 表示你的占用时间是无限的，无法预知结果的，就像如果你是播放音乐，你不知道用户何时关闭。此时当其他应用收到 LOSS 通知的时候，自然不会一直等待下去，所以就会做音频相关的清理工作了。
第六回合：一图胜千言
暴躁老哥： 这个焦点栈退栈的逻辑有点绕，大师你能画个图吗？
Android 田文镜： 没问题，两张时序图，让你彻底看透。
场景一：申请 GAIN
场景二：申请 TRANSIENT
醍醐灌顶
暴躁老哥： 不愧是田文镜大师，我真是醍醐灌顶了！原来之前用户的投诉都是因为我用错了参数！
Android 田文镜： 孺子可教也。既然你这么好学，最后，我再给你一套决策宝典，下次碰到音频焦点申请的难题的时候，直接看宝典：
暴躁老哥： 跪谢大师！
Android 田文镜： 顺便提一句，从 Android 12 (API 31) 开始，如果别的 App 不守规矩（比如收到 LOSS 还不暂停），系统底层的 AudioFlinger 会直接把它强制淡出（Fade-out）甚至物理级静音。
所以，这套“君子协议”正在逐渐变成“系统强制的法律”。写好焦点状态机，不仅是为了优雅，更是为了你的 App 在新系统和苛刻的车机环境下能够正常存活！
暴躁老哥： 大师！（感激涕零）
