本申请涉及android系统技术，特别涉及一种android系统中的音频播放方法。

背景技术：

在android系统中，现有的使用audiotrack进行音频播放时，audiotrack应用与android系统平台的交互过程如图1所示，在图1中，minbuffer是android平台api返回值，告知应用当前需要配置给android平台的最小缓存数；trackbuffer为应用最终设置给平台的缓存数，需要保证trackbuffer>＝minbuffer；write为应用向平台缓存中写数据，内部维护的已写数量总和；play是android平台api返回值，告知当前的播放进度；x是android平台内部的缓存，应用无法感知，对不同终端该值不同，需要缓存量大于x时才真正开始播放。

基于上述交互过程实现的音频播放流程具体包括：

1)应用在播放配置阶段创建audiotrack时，为audiotrack设置buffer大小为trackbuffer，为了能够正常播放，通常trackbuffer≥minbuffer；

2)在启动播放阶段，应用向trackbuffer中持续写入数据，当trackbuffer被填满后audiotrack开始播放；

3)在稳态播放过程中，当存在一帧待播放的音频数据时，应用记录已经送给平台的音频数write，同时不断通过api获取平台的播放进度play，判断如下：

a)若write–play≥trackbuffer，则认为平台的缓存已满，不作处理；

b)若write–play

4)判断若还存在待播放的音频数据，则继续执行步骤3，否则等待有新数据时再执行步骤3。

上述音频播放方式存在如下两个问题：

1、对于某些终端，当应用已经给audiotrack的buffer填充满trackbuffer数据后，android平台api返回的播放进度play并不改变，导致音频不能正常播放；其原因可能是android平台底层的audioflinger还未真正启动播放，还需要trackbuffer中的数据达到一定的缓存量x后才开始播放。为了trackbuffer被填满后，能够真正的启动播放，通常将该buffer值设定的很大，让其大于audioflinger层真正启动播放需要的缓存量x。但是x的实际值对应用并不可见，只能针对不同终端去猜测x的大小。且如果为了保证能够正常播放而配置更大的trackbuffer量，则填充trackbuffer的时间会随之增长，势必会导致流媒体播放的用户面时延增大；

2、使用android平台进行音频播放过程中如果连接蓝牙播放设备，可能导致音频无法继续播放。具体地，使用蓝牙设备进行音频播放时，audiotrack需要的缓存量较大，通常大于使用android设备自身喇叭播放时需要的trackbuffer值。因此，当连接上蓝牙设备后，原先设给android平台的缓存量不能满足蓝牙设备的播放。连接蓝牙设备进行音频播放所需的缓存量大小对应用不可见，且不同蓝牙设备的缓存需求量不同。如果为了保证能够正常播放而配置更大的trackbuffer量，则填充trackbuffer的时间会随之增长，势必会导致流媒体播放的用户面时延增大。

技术实现要素：

本申请提供一种android系统中的音频播放方法，能够减小音频播放的时延。

为实现上述目的，本申请采用如下技术方案：

一种android系统中的音频播放方法，包括：

在播放配置阶段，将android平台的trackbuffer设为minbuffer；其中，minbuffer为android平台当前需要的最小缓存数；

应用识别android平台的播放状态；

当所述播放状态为未播放时，继续向缓存写入音频数据；当所述播放状态为播放时，播放缓存中的音频数据。

较佳地，所述应用识别android平台的播放状态包括：

当所述应用从播放配置阶段刚进入启动播放阶段的初始场景下，所述播放状态为未播放；和/或，

在预设的第一时间段内播放进度值没有更新，则确定所述播放状态为未播放；和/或，

连续n次向trackbuffer写入数据的间隔时间大于预设的第二时间段，则确定所述播放状态为未播放；和/或，

连续m次接收android平台反馈的播放进度值不同，则确定所述播放状态为播放；其中，所述n和m为预设的正整数。

较佳地，该方法进一步包括：当所述播放状态为播放时，如果连续x次出现写入数据耗时超过预设的第三时间段，将缓存中剩余未播放数据量重设为trackbuffer；其中，x为预设的正整数。

由上述技术方案可见，在播放配置阶段，将android平台的trackbuffer设为minbuffer；应用识别android平台的播放状态；当所述播放状态为未播放时，若缓存中剩余的未播放数据大于或等于预先配置的trackbuffer，仍继续向缓存写入音频数据，以驱动android平台进入播放状态；当所述播放状态为播放时，按照图1方式播放缓存中的音频数据。通过上述方式，不需要在配置阶段将trackbuffer设置的过大，仍然能够保证音频的正常播放，从而减小了音频播放启动的时延。

附图说明

图1为现有的audiotrack应用与android系统平台的交互过程示意图；

图2为本申请实施例中音频播放方法的具体流程示意图。

具体实施方式

为了使本申请的目的、技术手段和优点更加清楚明白，以下结合附图对本申请做进一步详细说明。

如背景技术所述，为了使android的音频正常播放，需要保证初始阶段android平台缓存的数据量能够达到x。通常的方式是将trackbuffer设置的比较大，使得trackbuffer大于x。然而这种方式可能会导致音频播放的延时较大。

本申请中为避免出现音频播放延时过大的问题，提供一种音频播放方法。该方法具体包括：

在播放配置阶段，将android平台的trackbuffer设为minbuffer；接下来在音频播放阶段，应用识别android平台的播放状态；当播放状态为未播放时，若缓存中剩余的未播放数据大于或等于预先配置的trackbuffer，则表明设置的trackbuffer可能小于播放音频的最低缓存量x，这时，本申请中将继续向缓存写入音频数据，使缓存内部的数据量大于x，以触发音频播放；当播放状态为播放时，仍然按照现有的方式控制播放缓存中的音频数据。

在上述处理中，新增了应用对平台播放状态的识别机制，其中，判断平台播放状态的机制具体包括：

1)在以下场景时，判断平台播放状态为“未播放”的场景：

a.初始场景，即应用刚刚从“播放配置”阶段进入“启动播放”阶段；

b.连续预设的第一时间段内播放进度play都不更新，如：每隔100ms判断一次，连续三次查询时，播放进度都没更新则可认为平台没有播放；

c.连续n次向trackbuffer中填充数据的间隔时间过长，例如大于预设的第二时间段。

2)在以下场景时，判断平台播放状态为“播放”的场景：

a.连续m次平台返回的播放进度play不一样。

上述即为应用判断平台播放状态的具体方式。

优化后应用根据平台的播放状态的数据处理机制为：

1)若平台为未播放状态：

a.当write–play

b.当write–play≥trackbuffer时，强行执行写入动作。

2)若平台为播放状态：

a.音频播放相关的处理同原有的播放机制。

b.为了增强方案健壮性，在播放状态下，如果连续x次出现写入数据耗时大于预设的第三时间段，则认为平台缓存已满，强制令write–play＝trackbuffer，即认为audiotrack的可用缓存为0，避免下次继续执行数据写入耗时过长。

下面通过一个具体实施例说明本申请的具体实现。图2为本申请实施例中音频播放方法的具体流程图。该实施例是在专网终端上实现的。如图2所示，该方法包括：

步骤201，在播放配置阶段，将android平台的trackbuffer设为minbuffer，并开始向audiotrack中写入数据。

本实施例中，假定在播放配置阶段，将android平台的trackbuffer设为minbuffer。

步骤202，识别平台播放状态。

步骤203，判断播放状态是否为播放，若否，则执行步骤204，若是，执行步骤205。

本实施例中，假定获取到的minbuffer为640字节，则trackbuffer也设置为640字节。当缓存量达到trackbuffer大小时，音频并不会开始播放，因为平台要求960字节以上才能启动播放。那么在缓存量达到640字节后，判断播放状态为未播放，则执行步骤204。

步骤204，强行向平台写入音频数据。

通过播放进度判决android平台为“未播放”状态，开始强行向audiotrack中写入数据。继续强行写入320字节后，android平台真正开始音频播放，app根据播放进度更新平台为“播放”状态。

步骤205，将平台状态标记为“播放”，按照现有方式播放音频。

在android平台的“播放”状态下，app按照原有播放机制进行音频播放直到播放结束。

步骤206，判断平台是否有空余缓存，若是，则执行步骤207，否则，返回步骤202。

步骤207，判断距离上一次平台写入数据时间是否超过设定的时间段，若是，则执行步骤204，否则，执行步骤208。

如果在“播放”状态下平台长时间没有可播放的数据，app会再次判决平台为“未播放”状态，再次播放数据时将重复业务开始时的流程，再次触发强写机制。

步骤208，向平台写入音频数据。

步骤209，判断多次写入耗时是否过长(例如大于8ms)，若是，则执行步骤210，否则返回步骤202。

当多次写入耗时过长时，认为平台缓存已满，通过步骤210将可用缓存设为0，继续判断平台播放状态。

步骤210，将平台剩余缓存空间设为0。

上述即为本实施例中的音频播放方法的具体实现。

通过上述本申请中的音频播放方法，能够降低在android系统中播放流媒体音频时的耗时，对于用户面时延要求高的场景，该方案能够带来较为显著的时延优化效果；另外，对于某些android终端，在音频播放过程中切换为蓝牙播放后就无声的问题可以得到解决。

以上所述仅为本发明的较佳实施例而已，并不用以限制本发明，凡在本发明的精神和原则之内，所做的任何修改、等同替换、改进等，均应包含在本发明保护的范围之内。