按照AudioFocus的机制，在使用AudioStream之前，需要申请AudioFocus，在获得AudioFocus之后才可以使用相应的AudioStream；如果有别的程序竞争你正在使用的AudioStream，你的程序需要在收到通知之后做停止播放或者降低声音的处理。值得指出的是，这种机制是需要合作完成的，需要所有使用Audio资源的程序都按照这种机制来做，而如果有程序在它失去AudioFocus的时候仍然在使用Audio，AudioFocus拿它也没办法。而这一点对于开放系统的Android来说很致命的：用户可能安装没遵守这种机制的程序，或者版本太老还没引入这种机制的程序，这最终会导致很差的用户体验。

对于手机方案公司来说，要做的能做的事情就是教育和培训团队成员以保证自己内建的程序遵守机制没问题，这包括了Android原生的程序、自己开发的程序，以及适配第三方的程序。

一、AudioFocus的申请与释放

下面看与AudioFocus的相关的类：

获取/放弃AudioFocus的方法都在android.media.AudioManager中，获取AudioFocus用requestAudioFocus()；用完之后，放弃AudioFocus，用abandonAudioFocus()。

其中，参数：

返回值，可能是：

二、AudioFocus被抢占与重新获得

由上节中知道，申请/释放AudioFocus时传入了AudioManager.OnAudioFocusChangeListener这个参数，其onAudioFocusChange()方法是Audio Focus被抢占与再次获得通知的地方。所以，每个要使用AudioFocus的程序都要小心实现这个函数，保证AudioFocus实现的一致性。

onAudioFocusChange()方法的focusChange参数指示了该AudioFocus的竞争者对AudioFocus的拥有情况，取值如下：

下面是onAudioFocusChange()方法处理的代码片段：

三、典型的应用AudioFocus的场景

下面的时序图描述了AudioFocus被抢占与再次获取的典型场景：

Audio Focus被抢占与再次获取的时序图

注意：为了描述简单，此图中除了两个竞争Audio Focus的App之外，只用AudioManager表征了Android的AudioFocus机制中内部参与的对象，实际AudioManager只是外部的表象，内部参与的对象很多，回调函数也并非简单的直接由AudioManager调用，其中还包含了复杂的IPC机制。

图中：

小结

Audio Focus机制要参与各方充分理解并统一遵照施行，有没有遵照者或者实现有误的程序存在就可能打破这一机制，带来糟糕的用户体验。在保证Built-in程序没问题的前提下，如果进入AndroidMarket之前的程序都严格执行了AudioFocus相关的测试，应该也没问题。

问题点以及进一步的探讨