具体实施方式

为了使本申请的目的、技术方案及优点更加清楚明白，以下结合附图及实施例，对本申请进行进一步详细说明。应当理解，此处描述的具体实施例仅仅用以解释本申请，并不用于限定本申请。

本申请提供的音频卡顿检测方法，可以应用于如图1所示的应用环境中。其中，终端101与终端102之间通过网络进行通信以传输音频。在终端102的待检测应用程序的运行过程中，获取调用音频解码函数的时间信息，其中，调用音频解码函数即应用程序在接收端对音频进行解码时调用的函数；根据相邻两次调用音频解码函数的时间信息，得到单帧音频处理时间，根据待检测应用程序中单帧音频处理时间即可确定在待检测应用程序中音频解码之后的音频是否发生卡顿。其中，终端101、终端102可以但不限于是各种个人计算机、笔记本电脑、智能手机、平板电脑和便携式可穿戴设备。

在另一些实施例中，上述音频卡顿检测方法还可以应用在终端101、终端102和服务器的应用场景中。其中，终端101与终端102之间通过网络进行通信以传输音频，终端102作为被测试终端与服务器之间通过网络进行通信。在本实施例中，在终端102的待检测应用程序的运行过程中，获取调用音频解码函数的时间信息，其中，调用音频解码函数即应用程序在接收端对音频进行解码时调用的函数；根据相邻两次调用音频解码函数的时间信息，得到单帧音频处理时间，根据待检测应用程序中单帧音频处理时间即可确定在待检测应用程序中音频解码之后的音频是否发生卡顿。其中，终端102从服务器处获取待检测应用程序对应的音频解码函数。服务器可以用独立的服务器或者是多个服务器组成的服务器集群来实现。在一些实施例中，服务器可以是区块链中的一个节点。

本申请提供一种音频卡顿检测方法，对应用程序的音频是否发生卡顿进行检测，涉及语音技术。语音技术(Speech Technology)的关键技术有自动语音识别技术(ASR)和语音合成技术(TTS)以及声纹识别技术。让计算机能听、能看、能说、能感觉，是未来人机交互的发展方向，其中语音成为未来最被看好的人机交互方式之一。

在一个实施例中，如图2所示，提供了一种音频卡顿检测方法，以该方法应用于图1中的终端102为例进行说明，包括步骤S210至步骤S230。

步骤S210，在待检测应用程序的运行过程中，获取调用音频解码函数的时间信息。

其中，待检测应用程序为需要进行音频卡顿检测的应用程序。音频解码函数用于待检测应用程序中对音频进行解码。音频的传输过程包括：在发送端对原始音频进行编码，发送端将编码后的音频发送至接收端，接收端对接收到的音频进行解码，然后播放解码后的音频。其中，接收端对音频进行解码即需要调用音频解码函数。在一个具体实施例中，待检测应用程序为游戏类应用程序。

不同的应用程序对于音频进行解码采用的音频解码函数可能不相同；进一步地，在一个实施例中，应用程序采用的音频解码函数与应用程序支持的音频格式相关，而应用程序支持的音频格式与开发应用程序时使用的开发工具相关，在一个实施例中，开发应用程序时使用的开发工具为引擎。例如在一个具体实施例中，基于unity3d引擎开发的游戏类应用程序，对应的音频格式为Opus，Opus对应的音频解码函数为opus_decode()。其中，unity是一种实时3D互动内容创作和运营平台，可用于游戏开发；Opus是一个有损声音编码的格式，由Xiph.Org基金会开发，之后由IETF(The Internet Engineering Task Force，国际互联网工程任务组)进行标准化，目标是希望用单一格式包含声音和语音，取代Speex(一种音频压缩格式)和Vorbis(一种音频压缩格式)，且适用于网络上低延迟的即时声音传输，标准格式定义于RFC 6716文件。在其它实施例中，音频解码函数也可以是其它音频解码函数。

在本实施例中，在待检测应用程序的运行过程中，接收到音频需进行解码时，则会调用音频解码函数对音频进行解码；对待检测应用程序进行监控，当检测到待检测应用程序调用音频解码函数时，获取调用音频解码函数的时间信息。

其中，获取调用音频解码函数的时间信息可以通过任意一种方式实现。在一个实施例中，通过提前在音频解码函数对应位置注入时间记录函数，当调用音频解码函数时，将会执行时间记录函数记录调用音频解码函数时的时间。进一步地，提前在音频解码函数对应位置注入时间记录函数可以通过钩子函数(Hook)实现。其中，通过钩子函数音频解码函数对应位置注入时间记录函数的具体过程将在后实施例详细描述，在此不在赘述。

步骤S220，根据相邻两次调用音频解码函数的时间信息，确定音频解码函数对应的单帧音频处理时间。

在一个实施例中，对一帧音频进行解码处理需调用一次音频解码函数，若当前帧对应的音频解码完成，需再次调用音频解码函数对下一帧音频进行音频解码处理；因此，通过相邻两次调用音频解码函数的时间信息即可确定单帧音频解码所对应的时间。在本实施例中，相邻两次调用音频解码函数之间的间隔时间，即表示上一帧音频解码所耗费的时间，记为单帧音频处理时间，具体为上一帧音频的处理时间。

步骤S230，基于单帧音频处理时间对待检测应用程序进行音频卡顿检测，确定待检测应用程序是否发生音频卡顿。

在音频解码正常的情况下，单帧音频处理时间应当是一定的，若单帧音频处理时间较长，可能表示该帧音频解码发生了卡顿。在一个实施例中，基于单帧音频处理时间对待检测应用程序进行音频卡顿检测，确定待检测应用程序是否发生音频卡顿，包括：将单帧音频处理时间与预设时间阈值相比较，以确定待检测应用程序是否发生音频卡顿；其中，预设时间阈值用于表示正常情况下单帧音频的处理时间，预设时间阈值可以根据实际情况进行设置为任意数值。在其它实施例中，基于单帧音频处理时间对待检测应用程序进行音频卡顿检测，确定待检测应用成像是否发生音频卡顿，也可以通过其它方式实现。

进一步地，若需要对待检测应用程序的音频卡顿进行更详细的检测，可以对一段时间内的单帧音频处理时间进行检测；在一个实施例中，基于单帧音频处理时间对待检测应用程序进行音频卡顿检测，确定待检测应用程序是否发生音频卡顿，包括：获取预设时间段内的单帧音频处理时间，根据预设时间段内的单帧音频处理时间，确定待检测应用程序在预设时间段内是否发生卡顿。

可以理解地，单帧音频处理时间大于预设时间阈值仅能表示这一帧音频发生卡顿，根据预设时间段内的单帧音频处理时间进行检测，可以确定待检测应用程序在预设时间段内的音频是否发生卡顿。

进一步地，根据预设时间段内的单帧音频处理时间进行音频卡顿检测还可以在待检测应用程序发生卡顿时确定卡顿相关信息。其中，卡顿相关信息表示发生卡顿时的相关信息；在一个实施例中，卡顿相关信息可以包括卡顿类型、卡顿持续时间、卡顿的音频在预设时间段内的占比等等信息。其中，预设时间段可以根据实际情况进行设置，例如可以设置为30秒、1分钟、2分钟，或者也可以设置为音频总时长，例如音频为一段时长5秒的语音，预设时间段为5秒。

在其中的一个实施例中，卡顿类型包括：毛刺卡顿类型、连续卡顿类型、持续卡顿类型。其中，毛刺卡顿表示单帧音频处理时间出现突增，并超过一定阈值，引起的卡顿问题；如图3(1)所示为一个具体实施例中毛刺卡顿类型的单帧音频处理时间的示意图。连续卡顿表示在一定时间片范围内，连续两帧以上单帧音频处理时间出现激增与回落，并超过一定阈值，引起的卡顿问题；如图3(2)所示为一个具体实施例中连续卡顿类型的单帧音频处理时间的示意图。持续卡顿表示在一定时间片范围内，单帧音频处理时间出现突增，并超过一定阈值，持续多帧不恢复，引起的卡顿问题；如图3(3)所示为一个具体实施例中持续卡顿类型的单帧音频处理时间的示意图。卡顿持续时间表示发生卡顿的音频持续的时间；卡顿的音频在预设时间段内的占比表示发生卡顿的音频在检测的音频总时长中所占的比例。

进一步地，对于待检测应用程序检测是否发生音频卡顿可以通过对应的音频检测卡顿模型实现，在本实施例中，将预设时间段内的单帧音频处理时间输入对应的音频卡顿检测模型，输出待检测应用程序是否发生音频卡顿，以及在确定待检测应用程序发生音频卡顿时，输出卡顿相关信息。

在一个实施例中，基于单帧音频处理时间对待检测应用程序进行音频卡顿检测，确定待检测应用程序是否发生音频卡顿，包括：获取预设时间段内的单帧音频处理时间；通过音频卡顿检测模型对预设时间段内的单帧音频处理时间进行音频卡顿检测，确定预设时间段内待检测应用程序是否发生卡顿，以及卡顿类型。

进一步地，在一个实施例中，音频卡顿检测模型可以根据卡顿类型进行设置，例如音频卡顿检测模型包括：毛刺音频卡顿检测模型、连续音频卡顿检测模型和持续音频卡顿检测模型。在一个具体实施例中，在获取预设时间段内的单帧音频处理时间之后，先将预设时间段内的单帧音频处理时间输入毛刺音频卡顿检测模型，确定预设时间段内音频是否出现毛刺卡顿，然后再将预设时间段内的单帧音频处理时间输入连续音频卡顿检测模型或持续音频卡顿检测模型，确定预设时间段内音频是否出现连续卡顿或持续卡顿。在另一个实施例中，也可以将预设时间段内的单帧音频处理时间分别同时输入毛刺音频卡顿检测模型、连续音频卡顿检测模型和持续音频卡顿检测模型，确定音频是否出现毛刺卡顿、连续卡顿或者持续卡顿。

其中，在一个实施例中，对于音频卡顿检测模型中需设置对应的阈值，以判断是否出现卡顿。进一步地，在一个实施例中，对于音频卡顿检测模型的阈值设置包括以下步骤：设置音频卡顿检测模型的多个候选阈值，获取样本音频，以各候选阈值分别作为音频卡顿检测模型的阈值对样本音频进行检测，得到样本检测结果，确定样本音频以候选阈值进行评判是否发生音频卡顿；同时，将样本音频发送至多个用户试听，获取各用户的试听结果，具体为用户试听认为样本音频是否发生卡顿；结合试听结果和样本检测结果对各候选阈值的判断结果确定准确性，得到各候选阈值对应的准确率和漏报率；根据准确率和漏报率候选阈值选择最优候选阈值作为音频卡顿检测模型对应的阈值。

在一个实施例中，样本音频包括三个以上。在一个具体实施例中，准确率和漏报率的计算方式为：准确率＝Y/X；漏报率＝Y/Z。其中，X代表：仅样本检测结果为卡顿的样本音频数量；Y代表：样本检测结果为卡顿、且试听结果为卡顿(即人能感知到的卡顿)的样本音频数量；Z代表：仅试听结果为卡顿的样本音频数量。

进一步地，在一个实施例中，根据准确率和漏报率候选阈值选择最优候选阈值作为音频卡顿检测模型对应的阈值，包括：选择准确率超出预设准确率阈值，且漏报率低于预设漏报率阈值的候选阈值，作为音频卡顿检查模型的阈值。更进一步地，预设准确率阈值、预设漏报率阈值可以根据实际情况进行设定，例如预设准确率阈值设置为90％或者95％等，漏报率设置为5％或者10％等等。若满足预设准确率阈值、预设漏报率阈值的候选阈值包括多个，则以准确率越高、漏报率越低为更优。

在一个实施例中，不同的音频卡顿检测模型对应设置的阈值可以相同，也可以不相同。在一个具体实施例中，对于不同音频卡顿检测模型分别设置不同的候选阈值，并通过上述阈值的确定方法为不同的音频卡顿检测模型确定对应的阈值。在一个具体实施例中，通过上述阈值的确定方法确定的阈值包括：毛刺音频卡顿检测模型的阈值为340ms(毫秒)，连续音频卡顿检测模型的阈值为650ms，持续音频卡顿检测模型的阈值为70ms。

本实施例中，通过音频卡顿检测模型对待检测应用程序进行音频卡顿检测，不仅可以输出音频是否卡顿，还可以输出音频卡顿的相关信息，便于相关人员对待检测应用程序的音频卡顿更进一步的了解。进一步地，本实施例中还为音频卡顿检测模型设置不同的候选阈值，并利用样本音频对候选阈值进行检测，为音频卡顿检测模型确定最优的阈值，确定阈值的过程中结合了用户对于样本音频的试听感受，从而使确定的音频卡顿检测模型的阈值更加符合人耳感知，即音频卡顿检测模型对于音频卡顿的检测更加符合人耳的感知，判断更加准确。

上述音频卡顿检测方法，在待检测应用程序的运行过程中，获取调用音频解码函数的时间信息，其中，调用音频解码函数即应用程序在接收端对音频进行解码时调用的函数；进一步地，根据相邻两次调用音频解码函数的时间信息，得到单帧音频处理时间，根据待检测应用程序中单帧音频处理时间即可确定在待检测应用程序中音频解码之后的音频是否发生卡顿。上述方法，仅在待检测应用程序的运行过程中检测音频解码函数的调用时间信息，即只需在音频的接收端进行操作即可完成对待检测应用程序的音频卡顿检测，简化了音频卡顿的检测过程的操作流程。

在一个实施例中，如图4所示，在待检测应用程序的运行过程中，获取调用音频解码函数的时间信息之前，包括：步骤S410，通过钩子函数在待检测应用程序中音频解码函数的对应位置注入时间记录函数。

其中，钩子函数(hook)：一种计算机技术，在没有源码的情况下，通过汇编的跳转指令实现修改目标函数的执行流程；是Windows消息处理机制的一部分，通过设置“钩子”，应用程序可以在系统级对所有消息、事件进行过滤，访问在正常情况下无法访问的消息。

时间记录函数用于记录当前时刻对应的时间信息，在本实施例中，通过钩子函数将时间记录函数注入到待检测应用程序中的音频解码函数的对应位置，使得待检测应用程序在调用音频解码函数时，执行时间记录函数，得到当前时刻的时间信息。进一步地，在一个实施例中，通过钩子函数在待检测应用程序中音频解码函数的对应位置注入时间记录函数，包括：通过钩子函数，在音频解码函数的头部注入时间记录函数。

在一个具体实施例中，时间记录函数为time_record()。如图5(1)所示为一个具体实施例中，在待检测应用程序的音频解码函数的头部注入时间记录函数前后的示意图。如图5(2)所示为一个具体实施例中，注入时间函数之后执行音频解码函数时的跳转示意图。

请继续参照图4，在本实施例中，在待检测应用程序的运行过程中，获取调用音频解码函数的时间信息，包括步骤S211：在待检测应用程序的运行过程中，当音频解码函数被调用时，基于时间记录函数得到当前时间信息，得到调用音频解码函数的时间信息。

在上述步骤中，已经通过钩子函数将时间记录函数注入到待检测应用程序的音频解码函数对应位置，在待检测应用程序的运行过程中，一旦调用音频解码函数，就会执行时间记录函数，从而得到当前时刻的时间信息，该时间信息表示调用音频解码函数的时间。

在本实施例中，预先通过钩子函数在待检测应用程序中注入时间记录函数，当待检测应用程序运行时，可在调用音频解码函数时通过时间记录函数得到当前时刻的时间信息，即调用音频解码函数的时间，通过钩子函数无需获得待检测应用程序的源代码，可实现获取待检测应用程序的运行过程中对于音频解码函数的调用信息，实现简单，方便快捷。

在一个实施例中，如图6所示，在通过钩子函数在待检测应用程序中音频解码函数的对应位置注入时间记录函数之前，还包括步骤S610至步骤S620。

步骤S610，获取待检测应用程序的应用程序标识。

其中，应用程序标识是应用程序的唯一标识，可以用于区分应用程序。在一个具体实施例中，待检测应用程序的应用程序标识为待检测应用程序的apk包名(Androidapplication package，Android应用程序包)。在其他实施例中，应用程序标识也可以自定义设置。

在一个实施例中，待检测应用程序的应用程序标识可以是由用户输入。当用户希望对某个应用程序进行音频卡顿检查时，可以发起音频卡顿检测请求，通过音频卡顿检测请求将待检测应用程序的应用程序标识输入到终端。在一个实施例中，获取待检测应用程序的应用程序标识，包括：接收音频卡顿检测请求；根据音频卡顿检测请求获取待检测应用程序的应用程序标识。

在一个实施例中，对待检测应用程序的音频卡顿检测请求可以是在音频卡顿检测工具中发起，例如卡顿计工具；在本实施例中，即将上述音频卡顿检测方法可以集成为卡顿计工具。卡顿计工具是一种在终端中对应用程序进行卡顿检测识别、定位分析的性能检测工具。在一个具体实施例中，用户在终端中打开卡顿计工具，并在卡顿计检测工具中通过点击开始卡顿检测，选择待检测的应用程序，即向终端发起音频卡顿检测请求。终端接收到音频卡顿检测请求时，对其进行解析得到其中的待检测应用程序的应用程序标识。

步骤S620，根据应用程序标识，获取待检测应用程序中的音频解码函数名称。

由于不同的应用程序在进行音频解码时可能采用的音频解码函数不相同，因此在本实施例中，利用获取到的待检测应用程序的应用程序标识获取对应的音频解码函数名称。

在一个实施例中，在获取到待检测应用程序的应用程序标识之后，基于待检测应用程序的应用程序标识向服务器发送函数获取请求，然后接收服务器基于函数获取请求中携带的应用程序标识返回对应的音频解码函数名称。其中，函数获取请求中携带应用程序标识，函数获取请求用于向请求服务器查找并反馈待检测应用程序对应的音频解码函数。

在一个实施例中，在服务器中存储了大量应用程序标识与使用的音频解码函数的映射关系；终端将应用程序标识发送至服务器，服务器在接收到应用程序标识之后，根据应用程序标识查找与其对应的音频解码函数名称，并将音频解码函数名称反馈至终端。在一个具体实施例中，假设服务器中存储了以下映射关系：应用程序1-音频解码函数opus_decode()，应用程序2-音频解码函数opus_decode()，…；终端将应用程序标识发送至服务器，服务器接收到终端发送的应用程序1的应用程序标识1之后，通过该应用程序标识1在映射关系中查找对应的音频解码函数为opus_decode()，将该音频解码函数opus_decode()的名称反馈至终端。同理，终端发送的应用程序2的应用程序标识2时，服务器根据该应用程序标识2查找对应的音频解码函数名称并反馈至终端。

在另一个实施例中，服务器中存储了大量应用程序对应的开发工具与使用的音频解码函数的映射关系；在本实施例中，终端将应用程序标识发送至服务器，服务器接收到应用程序标识之后，根据应用程序确定对应的开发工具，基于开发工具查找对应的音频解码函数，并将解码函数反馈至终端。在一个具体实施例中，服务器中存储了以下映射关系：开发工具unity3d-音频解码函数opus_decode()，开发工具A-音频解码函数x，开发工具B-音频解码函数y，…；终端将应用程序1的应用程序标识1发送至服务器，服务器分析确定应用程序1对应的开发工具为unity3d，通过查找映射关系表获取到开发工具unity3d对应的音频解码函数为opus_decode()，将解码函数opus_decode()的名称反馈至终端。同理，终端发送的应用程序2的应用程序标识2时，服务器根据应用程序标识2确定对应的开发工具，进而查找对应的音频解码函数名称并反馈至终端。

在另一个实施例中，在获取到待检测应用程序的应用程序标识之后，也可以由终端自身根据待检测应用程序的应用程序标识查找对应的音频解码函数，或者由终端自身根据待检测应用程序的应用程序标识确定对应的开发工具，进而根据开发工具查找对应的音频解码函数。可以理解地，在其他实施例中，终端在获取到待检测应用程序的应用程序标识之后，也可以通过其他方式获取音频解码函数。

进一步地，请继续参照图6，在本实施例中，通过钩子函数在待检测应用程序中音频解码函数的对应位置注入时间记录函数，包括步骤S411：基于音频解码函数名称，在待检测应用程序中查找音频解码函数的对应位置，通过钩子函数在音频解码函数的对应位置注入时间记录函数。

本实施例中，在通过钩子函数在音频解码函数对应位置注入时间记录函数时，是根据获取到的音频解码函数名称在待检测应用程序中查找对应位置实现注入时间记录函数的。

进一步地，在一个实施例中，接收音频卡顿检测请求之后，还包括：响应于音频卡顿检测请求，拉起待检测应用程序，使待检测应用程序进入运行状态。

当接收到音频卡顿检测请求时，除了根据音频卡顿检测请求获取到待检测应用程序的应用程序标识以外，还基于音频卡顿检测请求拉起待检测应用程序，时待检测应用程序进入运行状态，即可开始进行音频卡顿检测。

在一个具体实施例中，在实际进行音频卡顿检测时，具体为通过卡顿计工具拉起待检测应用程序，使待检测应用程序进入运行状态，从而进入到待检测应用程序的场景中，即可对待检测应用程序是否发生音频卡顿进行检测。

在另一个具体实施例中，响应于音频卡顿检测请求，在虚拟机中拉起待检测应用程序，使待检测应用程序进入运行状态。其中，虚拟机(Virtual Machine)指通过软件模拟的具有完整硬件系统功能的、运行在一个完全隔离环境中的完整计算机系统。本实施例中，在虚拟机中实现上述音频卡顿检测方法，可实现在非root的终端中对release版本(发布版本)的测试包完成音频卡顿检测，对测试人员提供了极大的便利。其中，Root，也称为根用户，是Unix(如Solaris、AIX、BSD)和类UNIX系统(如Linux、QNX等)，及Android和iOS移动设备系统中的唯一的超级用户，因其可对根目录执行读写和执行操作而得名。其相当于Windows系统中的SYSTEM(XP及以下)/TrustedInstaller(Vista及以上)用户。Root终端具有系统中的最高权限，如启动或停止一个进程，删除或增加用户，增加或者禁用硬件，添加文件或删除所有文件等等。

在一个实施例中，在基于单帧音频处理时间对待检测应用程序进行音频卡顿检测，确定待检测应用程序是否发生音频卡顿、卡顿类型等音频卡顿检测结果之后，将音频卡顿检测结果发送至服务器进行存储，并且可将音频卡顿检测结果在服务器的前端进行显示。如图7所示为在服务器前端展示卡顿检测结果的示意图。

在一个实施例中，上述音频卡顿检测方法可应用在如图8所示物理架构示意图中。上述音频卡顿检测方法涉及的硬件环境包括：ARM架构处理器(卡顿计客户端)、X86架构处理器(卡顿计服务器、DB(Data Base，数据库)服务器、WEB(World Wide Web,全球广域网)平台)；上述音频卡顿检测方法涉及的软件环境可以包括：android/ios平台(卡顿计客户端工具)、windows xp及以上操作系统(卡顿计服务器、DB服务器、WEB平台)。上述卡顿计工具可以是终端设备中的APK客户端、WEB服务器、DB数据库构成。上述仅是示例，本实施例中对此不作任何限定。其中，APK(Android application package，Android应用程序包)，是Android操作系统使用的一种应用程序包文件格式，用于分发和安装移动应用及中间件。

进一步地，在一个实施例中，待检测应用程序的场景包括两个以上检测模式，其中一个检测模式为战斗场景检测模式。在本实施例中，在拉起待检测应用程序，使待检测应用程序的运行过程之后，接收检测模式选择指令，当检测模式选择指令为战斗场景检测模式选择指令时，进入获取调用音频解码函数的时间信息的步骤。在一个实施例中，待检测应用程序的场景还包括非战斗场景检测模式；战斗场景检测模式包括对待检测应用程序的音频卡顿进行检测；非战斗场景检测模式包括对待检测应用程序的画面卡顿等进行检测，可以检测待检测应用程序的非战斗场景的画面是否发生卡顿。其中，针对非战斗场景检测模式的检测可通过任意一种方式实现。

相关技术中对于音频卡顿的检测大多是针对非游戏类应用程序的音频卡顿检测方案，这类应用场景的音频卡顿检测方案通常是需要先在本地测试发起端存放原始的被测音频，在发起端播放被测音频后，在接收端输出经过云端传输的接收端音频，再将原始音频和接收端的音频通过特征值的对比得到音频的卡顿情况。然而这种卡顿检测方案在游戏类应用程序中并不适用，因为游戏类应用程序的语音功能的输入内容通常是不固定的，而不是固定的播放测试某段被测音频。为此，本申请提供一种音频卡顿检测方法，可以应用于游戏类应用程序中间对游戏语音是否发生卡顿进行检测。

本申请提供一种应用场景，该应用场景应用上述的音频卡顿检测方法。在本实施例中，以待检测应用程序为游戏类应用程序为例；具体地，该音频卡顿检测方法在该应用场景的应用如下：

上述音频卡顿检测方法的输入：游戏客户端程序；处理：自动获取游戏中语音交流时的音频解码函数，对语音场景进行语音卡顿检测；输出：游戏音频卡顿的提示，平台展示音频卡顿信息汇总及单个卡顿的详情信息。

具体流程如下：通过卡顿计启动游戏会获取当前游戏APK包名，再把游戏在virtual app中进行初始化，然后服务器会根据不同的游戏APK包名下发对应的音频解码函数(如opus_decode())，工具APK端根据服务器下发的音频解码函数进行hook，获取音频解码帧耗时数据(即上述单帧音频处理时间)，然后会将语音解码帧耗时数据实时发送给音频卡顿识别模型进行识别处理，一旦遇到语音卡顿。会在工具端进行语音卡顿的提示，然后再将语音卡顿数据上报到服务器端进行信息汇总。

应用在实际场景中，结合人员的处理过程，上述方法的步骤如下：

相关人员在被测试终端打开卡顿计工具，在卡顿计工具中选择需要进行音频卡顿检测的待检测应用程序，如图9(1)所示为一个具体实施例中卡顿计工具的界面示意图，在该界面中的测试列表新增待检测应用程序，进入如图9(2)所示的界面示意图，在该界面中选择待检测应用程序6，新增待检测应用程序之后的卡顿计工具界面如图9(3)所示；在如图9(3)所示的界面中选择启动待检测应用程序，即向终端发送音频卡顿检测请求；终端接收到音频检测请求之后，基于音频检测请求在卡顿计工具中拉起待检测应用程序，进入到待检测应用程序的场景中。

如图9(4)所示的界面示意图，相关人员选择场景检测模式，其中，上述音频卡顿检测方法可以应用于游戏的战斗场景检测。同时，基于音频检测请求中携带的待检测应用程序(应用程序6)的应用程序标识6向服务器发送函数获取请求，从服务器获取待检测应用程序(应用程序6)对应的音频解码函数opus_decode()。

在拉起待检测应用程序之后，通过hook函数在待检测应用程序中的opus_decode()对应位置注入时间记录函数time_record()。在一个具体实施例中，为在opus_decode()的头部注入时间记录函数time_record()。在本实施例中，游戏语音音频格式都是Opus，发送端是通过opus_encode()对音频进行编码，接收端通过opus_decode()对音频进行解码。在其它实施例中，若待检测应用程序的音频格式为其它格式，对应的音频解码函数为其它函数。

当在待检测应用程序中接收到战斗场景检测模式选择指令时，进入音频卡顿检测的流程。对于待检测应用程序的运行过程进行监控，当调用音频解码函数opus_decode()时，基于time_record()记录当前时间作为调用opus_decode()的时间信息，根据相邻两次调用opus_decode()的时间信息，得到单帧音频处理时间。即在接收端通过hook opus_decode()来计算两次音频帧decode的间隔，从而获取每一帧音频解码的耗时，具体过程为：首先对opus_decode()函数进行hook，添加时间记录函数time_record()，在第一次执行opus_decode()函数时，实际上会跳转先执行time_record()函数，记录执行opus_decode()的时间time1；在第二次执行opus_decode()函数时，就会记录opus_decode()的时间time2；这样第一次执行opus_decode()的时间就是：time2-time1，这就是音频每一帧解码的耗时。

获取预设时间内的单帧音频处理时间，输入音频卡顿检测模型，确定待检测应用程序是否发生卡顿，以及卡顿相关信息，如卡顿类型、卡顿持续时长等等信息。其中，音频卡顿检测模型包括毛刺音频卡顿检测模型、连续音频卡顿检测模型和持续音频卡顿检测模型；针对各音频卡顿检测模型，分别设置多组候选阈值，并利用样本音频和用户对样本音频的试听结果，对各组候选阈值确定准确率和漏报率，基于准确率和漏报率选择最合适的候选阈值作为音频卡顿检测模型的阈值，如图10所示为音频卡顿检测模型的阈值确定流程示意图。

进行音频检测之后，记录识别到的音频卡顿，检测完成后，可以在本地查看卡顿检测记录。

通过上述音频卡顿检测方法，可以快速准确地对待检测应用程序音频卡顿进行检测，例如基于unty3d引擎开发的游戏类应用程序，并且上述方法是基于虚拟机的方案，在非root的终端上就可以对发布版本的测试包进行测试，对测试相关人员提供了极大的便利。

应该理解的是，虽然上述实施例中所涉及的各流程图中的各个步骤按照箭头的指示依次显示，但是这些步骤并不是必然按照箭头指示的顺序依次执行。除非本文中有明确的说明，这些步骤的执行并没有严格的顺序限制，这些步骤可以以其它的顺序执行。而且，上述实施例中所涉及的各流程图中的至少一部分步骤可以包括多个步骤或者多个阶段，这些步骤或者阶段并不必然是在同一时刻执行完成，而是可以在不同的时刻执行，这些步骤或者阶段的执行顺序也不必然是依次进行，而是可以与其它步骤或者其它步骤中的步骤或者阶段的至少一部分轮流或者交替地执行。

在一个实施例中，如图11所示，提供了一种音频卡顿检测装置，该装置可以采用软件模块或硬件模块，或者是二者的结合成为计算机设备的一部分，该装置具体包括：时间信息获取模块1110、单帧时间确定模块1120和音频卡顿检测模块1130，其中：

时间信息获取模块1110，用于在待检测应用程序的运行过程中，获取调用音频解码函数的时间信息；音频解码函数用于待检测应用程序中对音频进行解码；

单帧时间确定模块1120，用于根据相邻两次调用音频解码函数的时间信息，确定音频解码函数对应的单帧音频处理时间；

音频卡顿检测模块1130，用于基于单帧音频处理时间对待检测应用程序进行音频卡顿检测，确定待检测应用程序是否发生音频卡顿。

上述音频卡顿检测装置，在待检测应用程序的运行过程中，获取调用音频解码函数的时间信息，其中，调用音频解码函数即应用程序在接收端对音频进行解码时调用的函数；进一步地，根据相邻两次调用音频解码函数的时间信息，得到单帧音频处理时间，根据待检测应用程序中单帧音频处理时间即可确定在待检测应用程序中音频解码之后的音频是否发生卡顿。上述装置，仅在待检测应用程序的运行过程中检测音频解码函数的调用时间信息，即只需在音频的接收端进行操作即可完成对待检测应用程序的音频卡顿检测，简化了音频卡顿的检测过程的操作流程。

在一个实施例中，上述装置还包括：函数注入模块，用于通过钩子函数在待检测应用程序中音频解码函数的对应位置注入时间记录函数；上述时间信息获取模块1110，还用于：在待检测应用程序的运行过程中，当音频解码函数被调用时，基于时间记录函数得到当前时间信息，得到调用音频解码函数的时间信息。

在一个实施例中，上述装置还包括：程序名称获取模块，用于获取待检测应用程序的应用程序标识；函数名称获取模块，用于根据应用程序标识，获取待检测应用程序中的音频解码函数名称；上述函数注入模块，还用于：基于音频解码函数名称，在待检测应用程序中查找音频解码函数的对应位置，通过钩子函数在音频解码函数的对应位置注入时间记录函数。

在一个实施例中，上述装置的程序名称获取模块，包括：请求接收单元，用于接收音频卡顿检测请求；解析单元，用于根据音频卡顿检测请求获取待检测应用程序的应用程序标识。

在一个实施例中，上述装置还包括：程序拉起模块，用于响应于音频卡顿检测请求，拉起待检测应用程序，使待检测应用程序进入运行状态。

在一个实施例中，上述装置的函数名称获取模块，包括：发送单元，用于基于应用程序标识，向服务器发送函数获取请求；接收单元，用于接收服务器基于函数获取请求反馈的音频解码函数名称。

在一个实施例中，上述装置的音频卡顿检测模块1130，包括：时间获取单元，用于获取预设时间段内的单帧音频处理时间；卡顿检测单元，用于通过音频卡顿检测模型对预设时间段内的单帧音频处理时间进行音频卡顿检测，确定预设时间段内待检测应用程序是否发生卡顿，以及卡顿类型。

关于音频卡顿检测装置的具体实施例可以参见上文中对于音频卡顿检测方法的实施例，在此不再赘述。上述音频卡顿检测装置中的各个模块可全部或部分通过软件、硬件及其组合来实现。上述各模块可以硬件形式内嵌于或独立于计算机设备中的处理器中，也可以以软件形式存储于计算机设备中的存储器中，以便于处理器调用执行以上各个模块对应的操作。

在一个实施例中，提供了一种计算机设备，该计算机设备可以是终端，其内部结构图可以如图12所示。该计算机设备包括通过系统总线连接的处理器、存储器、通信接口、显示屏和输入装置。其中，该计算机设备的处理器用于提供计算和控制能力。该计算机设备的存储器包括非易失性存储介质、内存储器。该非易失性存储介质存储有操作系统和计算机程序。该内存储器为非易失性存储介质中的操作系统和计算机程序的运行提供环境。该计算机设备的通信接口用于与外部的终端进行有线或无线方式的通信，无线方式可通过WIFI、运营商网络、NFC(近场通信)或其他技术实现。该计算机程序被处理器执行时以实现一种音频卡顿检测方法。该计算机设备的显示屏可以是液晶显示屏或者电子墨水显示屏，该计算机设备的输入装置可以是显示屏上覆盖的触摸层，也可以是计算机设备外壳上设置的按键、轨迹球或触控板，还可以是外接的键盘、触控板或鼠标等。

本领域技术人员可以理解，图12中示出的结构，仅仅是与本申请方案相关的部分结构的框图，并不构成对本申请方案所应用于其上的计算机设备的限定，具体的计算机设备可以包括比图中所示更多或更少的部件，或者组合某些部件，或者具有不同的部件布置。

在一个实施例中，还提供了一种计算机设备，包括存储器和处理器，存储器中存储有计算机程序，该处理器执行计算机程序时实现上述各方法实施例中的步骤。

在一个实施例中，提供了一种计算机可读存储介质，存储有计算机程序，该计算机程序被处理器执行时实现上述各方法实施例中的步骤。

在一个实施例中，提供了一种计算机程序产品或计算机程序，该计算机程序产品或计算机程序包括计算机指令，该计算机指令存储在计算机可读存储介质中。计算机设备的处理器从计算机可读存储介质读取该计算机指令，处理器执行该计算机指令，使得该计算机设备执行上述各方法实施例中的步骤。

本领域普通技术人员可以理解实现上述实施例方法中的全部或部分流程，是可以通过计算机程序来指令相关的硬件来完成，的计算机程序可存储于一非易失性计算机可读取存储介质中，该计算机程序在执行时，可包括如上述各方法的实施例的流程。其中，本申请所提供的各实施例中所使用的对存储器、存储、数据库或其它介质的任何引用，均可包括非易失性和易失性存储器中的至少一种。非易失性存储器可包括只读存储器(Read-OnlyMemory，ROM)、磁带、软盘、闪存或光存储器等。易失性存储器可包括随机存取存储器(Random Access Memory，RAM)或外部高速缓冲存储器。作为说明而非局限，RAM可以是多种形式，比如静态随机存取存储器(Static Random Access Memory，SRAM)或动态随机存取存储器(Dynamic Random Access Memory，DRAM)等。

以上实施例的各技术特征可以进行任意的组合，为使描述简洁，未对上述实施例中的各个技术特征所有可能的组合都进行描述，然而，只要这些技术特征的组合不存在矛盾，都应当认为是本说明书记载的范围。

以上实施例仅表达了本申请的几种实施方式，其描述较为具体和详细，但并不能因此而理解为对发明专利范围的限制。应当指出的是，对于本领域的普通技术人员来说，在不脱离本申请构思的前提下，还可以做出若干变形和改进，这些都属于本申请的保护范围。因此，本申请专利的保护范围应以所附权利要求为准。