接着上一篇音频策略的分析，接下来看下音频焦点
音频焦点机制是Android系统提供的一种约定：
1 播放声音前申请音频焦点，播放结束的时候释放音频焦点，
2 获得焦点才能开始播放，失去音频焦点应该暂停播放或者降低音量
一 看下申请音频焦点的粗略流程：
app端 调用AudioManager.requestAudioFocus ->bind->AudioService->MediaFocusControl.requestAudioFocus->
--->当前焦点是否是电话
--->是否使用外部音频策略处理
--->是否是多音频焦点管理
--->是否延迟获取焦点
->通知是否成功
以上就是整个调用流程
那些细节需要注意呢
1 这个流程是个同步调用机制，成功失败直接返回
2 延时焦点申请，会直接申请到电话对应的焦点栈下面，下次直接给它，后来的会冲掉之前的（能够申请延时焦点的只有当电话的时候才需要）
3 会有各种条件判断能否申请成功（比如，当前是否是电话，栈是否大于100等等）
4 当前app意外崩溃，会导致系统泄漏吗？ 不会，会有linktodeath机制，自动释放焦点和内存
二 如何定制自己的音频焦点交互模型
比如 我语音和导航交互的时候是不是可以兼容（同时获得焦点）
上面的焦点流程已经贴出，里面会通过FocusInteraction来给出交互逻辑，里面通过直接修改 FocusInteraction里面的二维数组即可：
private static final int\[\]\[\] INTERACTION_MATRIX
可以看下 焦点在NAVIGATION时候的焦点交互逻辑
INTERACTION_CONCURRENT：兼容
INTERACTION_EXCLUSIVE：申请者获得焦点，之前的放弃焦点
// Focus holder: NAVIGATION
{
INTERACTION_CONCURRENT, // MUSIC
INTERACTION_CONCURRENT, // NAVIGATION
INTERACTION_EXCLUSIVE, // VOICE_COMMAND
INTERACTION_CONCURRENT, // CALL_RING
INTERACTION_CONCURRENT, // CALL
INTERACTION_CONCURRENT, // ALARM
INTERACTION_CONCURRENT, // NOTIFICATION
INTERACTION_CONCURRENT, // SYSTEM_SOUND
INTERACTION_EXCLUSIVE, // EMERGENCY
INTERACTION_CONCURRENT, // SAFETY
INTERACTION_CONCURRENT, // VEHICLE_STATUS
INTERACTION_CONCURRENT, // ANNOUNCEMENT
}
至此，framwork层audio经常改动的两大区域基本分析完毕，接下来要开始音频移植了