HarmonyOS 鸿蒙Next中音频焦点管理如何影响多任务操作

我们的音频焦点是和音频流绑定的，需要应用在播放音频时，正确设置自己的streamUsage，然后在音频流start的时候，框架层帮应用去申请焦点，并通知其他正在使用音频焦点的应用。框架层是指OH系统的框架。即音频焦点不需要应用主动申请，系统会在应用start音频流的时候自动申请。

同一应用的多音频同时播放 理论上应该设置共享焦点模式 您可以访问参考链接： 【 https://developer.huawei.com/consumer/cn/doc/harmonyos-guides-V5/audio-playback-concurrency-V5 】

对于音频焦点的多种模式可以参考此链接： 【 https://gitee.com/openharmony/docs/blob/805c6b626ed5fbca1e532de8c00c2cf2d0b1af0b/zh-cn/application-dev/media/audio-playback-concurrency.md 】
共享焦点模式（SHARE_MODE）：由同一应用创建的多个音频流，共享一个音频焦点。这些音频流之间的并发规则由应用自主决定，音频打断策略不会介入。当其他应用创建的音频流与该应用的音频流并发播放时，才会触发音频打断策略的管控。
独立焦点模式（INDEPENDENT_MODE）：应用创建的每一个音频流均会独立拥有一个音频焦点，当多个音频流并发播放时，会触发音频打断策略的管控。

音频打断策略（包括两种焦点模式）决定了应该对各个音频流采取何种操作，如暂停播放、继续播放、降低音量播放、恢复音量播放等。而针对这些操作的执行过程，根据执行者的不同，可以分为两种打断类型（InterruptForceType）：
强制打断类型（INTERRUPT_FORCE）：由系统进行操作，强制打断音频播放。
共享打断类型（INTERRUPT_SHARE）：由应用进行操作，可以选择打断或忽略。
对于音频打断策略的执行，系统默认采用强制打断类型（INTERRUPT_FORCE），应用无法更改。但对于一些策略（如继续播放等），系统无法强制执行，所以这两种打断类型均可能出现。应用可根据音频打断事件（InterruptEvent）的成员变量forceType的值，获取该事件采用的打断类型。
在应用播放音频的过程中，系统自动为音频流执行申请焦点、持有焦点、释放焦点等动作，当发生音频打断事件时，系统强制对音频流执行暂停、停止、降低音量、恢复音量等操作，并向应用发送音频打断事件（InterruptEvent）回调。由于系统会强制改变音频流状态，为了维持应用和系统的状态一致性，保证良好的用户体验，推荐应用监听音频打断事件，并在收到音频打断事件（InterruptEvent）时做出相应处理。
对于一些系统无法强制执行的操作（例如音频流继续播放的场景），会向应用发送包含了共享打断类型的音频打断事件，由应用自行执行相应操作，此时应用可以选择执行或忽略，系统不会干涉。
具体实现 可以参考 【 https://gitee.com/openharmony/docs/blob/805c6b626ed5fbca1e532de8c00c2cf2d0b1af0b/zh-cn/application-dev/media/audio-playback-concurrency.md 】