【下篇】TWS蓝牙耳机游戏时延标准与游戏应用侧优化建议

上篇已详细解读了TWS蓝牙耳机游戏时延的测试方法，那么如何衡量游戏时延的好与坏？以及游戏时延该如何优化呢？本篇章将重点解读蓝牙耳机游戏时延的评测标准和绿盟各成员给出的一些优化建议。

TWS蓝牙耳机游戏时延体验标准

标注：实验数据来源于绿盟实验室数据，实验设备均采购于市场

《软件绿色联盟游戏体验标准3.0》通过大量的人因拟合实验、大数据分析和实验室精确的测试以及ITU相关标准参考，得出结果：时延小于140ms时，游戏体验无感知，体验舒适；时延大于200ms，有明显的延迟感，难接受；介于140ms到200ms之间时，延迟感不明显，属于可接受范围，评级如下：

蓝牙游戏时延三方应用侧的优化建议

对准绿标3.0 定义的级别，我们对蓝牙耳机游戏时延指标做了一些分解，发现除了硬件设备的因素外，三方游戏APK对音频接口的开发和应用行为也起着重要的作用，主要因素如下：

1.OPENSLES库的使用

1）在创建播放器的流程Engine::CreateAudioPlayer之前，需要设置参数：buffer数量，后文称bufferNum。在播放过程中，通过回调应用的回调函数，将一片音频数据，后文称buffer，写入队列。一片buffer中包含的音频数据含量，我们称为bufferSize。考虑到音频数据在Android音频播放系统中流动的健壮性，在三方应用提供的回调函数中，写入buffer的数据大小bufferSize不宜过大，即 采用小批量数据，多次回调写入的方式 。我们对此建议是优先保证单次buffer数据含量 bufferSize小于1536Bytes ，之后再结合应用具体需要，考虑设置相应的bufferNum。

2）虽然Android建议了接口使用顺序，但是开发者仍有较宽泛的接口使用行为选择。其中比较重要的是当音频播放停止和开始的时候开发者的选择。开发者可以选择在用户打开应用的开始只创建一个播放器，后续的播放行为的开始和停止均由数据的写入停断控制完成，对于此类方式我们统称数据控制，是一种不推荐的方法。同样开发者也可以选择在停止播放的时候就销毁播放器，重新开始播放的时候再重新创建播放器，对于此类方式我们统称为流程控制。

我们对于播放行为有如下建议：

(1)：任何声音从有-无，从无-有的场景（例如游戏的后台前台切换，游戏内部打开外部网页连接后，返回游戏等场景），需采用流程控制。即声音停止播放后销毁播放器，声音再次播放的时候， 重新设置参数并创建播放器（Engine::CreateAudioPlayer）。

(2)：任何播放设备切换的场景，如外放=>耳机，均需要重新设置相对合适的播放参数，并 重新创建播放器（Engine::CreateAudioPlayer）播放。针对播放设备的切换场景，可通过接收设备状态变化相关的广播来监控，如：

“android.intent.action.HEADSET_PLUG”

“android.bluetooth.a2dp.profile.action.ACTIVE_DEVICE_CHANGED”

“android.bluetooth.a2dp.profile.action.CONNECTION_STATE_CHANGED”

2.游戏应用的建议

1）游戏打开时，通常伴随相对短促的打开音效，为保障此音效播放正常，我们建议在游戏打开时尽可能简化操作。例如：我们发现部分游戏需要调用权限管理接口，来向用户申请权限。这是很好的行为，不过在已获取所需权限以后，建议在后续打开不再调用权限管理接口，即不依赖权限管理进行是否已获得权限的判断，而是自行甄别已获得权限， 取消不必要的权限申请操作，以此减少权限管理的Activity动作。

2）不同播放设备的采样率支持情况不同，建议 通过AudioTrack的接口getNativeOutputSampleRate，在获取播放设备采样率之后，选择对应的音源采样率参数进行播放，以保证最佳的播放效果。

三方游戏应用侧如按照以上建议开发考虑，即可保证较小的音频数据消耗和音频数据流的健壮性，达到最优的音频播放效果，从而配合蓝牙耳机时可达到最佳的游戏时延体验。

为此，软件绿色联盟倡导推动软件生态健康发展，打通三方游戏厂商与设备厂商之间的壁垒，从而为用户带来更好的蓝牙游戏体验。

· END ·