应用程序的录音方法、终端设备及介质与流程

本发明属于信息处理技术领域，尤其涉及一种应用程序的录音方法、终端设备及计算机可读存储介质。

背景技术：

开源的代码库，免费的开发软件、社区以及第三方开源共享，使得安卓系统在当前的应用开发市场中占据了越来越重要的地位。安卓系统中通常运行有用于执行录音操作的应用程序。录音功能的实现涉及安卓系统所提供的多个架构层级，包括java层、native层以及linux内核底层等。其中，audiorecord是安卓系统提供的用于实现录音的功能类，是java层应用程序在native层的实例；native层的audio硬件抽象层则负责操控linux内核底层的麦克风硬件。当java层的某一应用程序需要启动录音时，对应该应用程序的服务端录音线程将会通过audio硬件抽象层，从麦克风中获得并保存录音数据。此后，该应用程序才能够从native层中读取这些录音数据，以完成录音操作。

在安卓系统中，经常会出现多个应用程序同时运行的情况。然而，由于麦克风硬件在同一时刻只能被一个服务端录音线程占用，因此，若同时运行的多个应用程序都需要启动录音功能，则将会因多个服务端录音线程的冲突而产生应用程序错误的情况，从而降低了应用程序的稳定性以及可靠性。

技术实现要素：

有鉴于此，本发明实施例提供了一种应用程序的录音方法、终端设备及计算机可读存储介质，以解决现有技术中，当同时运行的多个应用程序都需要启动录音功能时，容易产生应用程序错误，由此降低了应用程序的稳定性以及可靠性的问题。

本发明实施例的第一方面提供了一种应用程序的录音方法，包括：

分别创建对应于各个应用程序的客户端实例；

若检测到两个以上的所述客户端实例所关联的录音事件被触发，则在预先生成的服务端录音线程中，分别创建与各个所述客户端实例所对应的音轨区域；

获取预置的音频拾取器所采集得到的录音数据，并将所述录音数据分别存储至各个所述音轨区域；

对每一所述应用程序所对应的所述客户端实例，在与该客户端实例对应的所述音轨区域中，基于所述服务端录音线程执行录音数据的读取操作，以完成关联该应用程序的录音事件。

本发明实施例的第二方面提供了一种应用程序的录音装置，包括：

第一创建单元，用于分别创建对应于各个应用程序的客户端实例；

第二创建单元，用于若检测到两个以上的所述客户端实例所关联的录音事件被触发，则在预先生成的服务端录音线程中，分别创建与各个所述客户端实例所对应的音轨区域；

获取单元，用于获取预置的音频拾取器所采集得到的录音数据，并将所述录音数据分别存储至各个所述音轨区域；

读取单元，用于对每一所述应用程序所对应的所述客户端实例，在与该客户端实例对应的所述音轨区域中，基于所述服务端录音线程执行录音数据的读取操作，以完成关联该应用程序的录音事件。

本发明实施例的第三方面提供了一种终端设备，包括存储器以及处理器，所述存储器存储有可在所述处理器上运行的计算机程序，所述处理器执行所述计算机程序时实现如第一方面所述的应用程序的录音方法的步骤。

本发明实施例的第四方面提供了一种计算机可读存储介质，所述计算机可读存储介质存储有计算机程序，所述计算机程序被处理器执行时实现如第一方面所述的应用程序的录音方法的步骤。

本发明实施例中，当检测到两个以上的客户端实例所关联的录音事件被触发时，表示多个应用程序同时启动了录音功能，通过在预先生成的一个服务端录音线程中，分别创建与各个客户端实例所对应的音轨区域，并将采集得到的录音数据分别存储至各个音轨区域，使得各个应用程序在请求加载录音数据时，均能够从自身对应的一个音轨区域中读取所需的录音数据，从而实现多个应用程序的同步录音，保证了每个应用程序在获得录音数据后，能够利用这些录音数据来完成各项不同的应用功能，故提高了应用程序的交互能力；避免了产生应用程序错误的情况，由此也提高了应用程序的稳定性以及可靠性。

附图说明

为了更清楚地说明本发明实施例中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动性的前提下，还可以根据这些附图获得其他的附图。

图1是本发明实施例提供的应用程序的录音方法的实现流程图；

图2是本发明实施例提供的关于应用程序录音过程的数据流图；

图3是本发明实施例提供的应用程序的录音方法s102的具体实现流程图；

图4是本发明实施例提供的应用程序的录音方法s1021的具体实现流程图；

图5是本发明实施例提供的应用程序的录音方法s103的具体实现流程图；

图6是本发明实施例提供的应用程序的录音装置的结构框图；

图7是本发明实施例提供的终端设备的示意图。

具体实施方式

以下描述中，为了说明而不是为了限定，提出了诸如特定系统结构、技术之类的具体细节，以便透彻理解本发明实施例。然而，本领域的技术人员应当清楚，在没有这些具体细节的其它实施例中也可以实现本发明。在其它情况中，省略对众所周知的系统、装置、电路以及方法的详细说明，以免不必要的细节妨碍本发明的描述。

为了说明本发明所述的技术方案，下面通过具体实施例来进行说明。

图1示出了本发明实施例提供的应用程序的录音方法的实现流程，该方法流程包括步骤s101至s104。各步骤的具体实现原理如下：

s101：分别创建对应于各个应用程序的客户端实例。

本发明实施例中，录音功能的实现涉及安卓系统所提供的多个架构层级，包括java层、native层以及linux内核底层等。其中，audiorecord是安卓系统提供的用于实现录音的功能类，是java层应用程序在native层的客户端实例；native层的audio硬件抽象层则负责操控linux内核底层的麦克风硬件。

在本发明的各个实施例中，以两个应用程序为例，阐述两个应用程序在同时触发录音事件时，安卓系统内部所产生的录音数据的数据流向关系。值得注意的是，除了上述两个应用程序同时触发录音事件的场景之外，本发明实施例所提供的应用程序的录音方法还适用于一个或多个应用程序同时触发录音事件的场景之下，在此不作限定。

具体地，图2示出了本发明实施例提供的关于应用程序录音过程的数据流图，如图2所示的数据流图用于描述两个应用程序在同时触发录音事件时，安卓系统内部所产生的录音数据的数据流向关系。在图2中，运行于java层的应用程序包括应用程序1以及应用程序2，则在native层中，分别创建对应于各个应用程序的客户端实例audiorecord。示例性地，与应用程序1对应的客户端实例为客户端1；与应用程序2对应的客户端实例为客户端2。

audioflinger与audiopolicyservice是音频在native层的服务，audioflinger管理着多个服务端录音线程，用于处理录音数据；audiopolicyservice主要用于控制服务端录音线程的开启、暂停和释放；native层的audio硬件抽象层则负责操控linux内核底层的音频拾取器。具体地，本发明实施例中的音频拾取器包括图2所示的麦克风。

s102：若检测到两个以上的所述客户端实例所关联的录音事件被触发，则在预先生成的服务端录音线程中，分别创建与各个所述客户端实例所对应的音轨区域。

本发明实施例中，若在两个应用程序中均同时或先后接收到用户发出的录音启动指令，则确定两个客户端实例所关联的录音事件被触发，此时，在预先生成的服务端录音线程中，分别创建与每一个客户端实例对应的一个音轨区域track。其中，服务端录音线程存在于audioflinger服务，且每一个服务端录音线程所允许创建的音轨区域track的数量最大值为32。

优选地，作为本发明的一个实施例，图3示出了本发明实施例提供的应用程序的录音方法s102的具体实现流程，详述如下：

s1021：若检测到两个以上的所述客户端实例所关联的录音事件被触发，则判断是否存在预先生成的服务端录音线程。

当检测到客户端实例1所关联的录音事件被触发时，在audioflinger服务中，创建一个用于处理录音数据的服务端录音线程。在该客户端实例1的录音事件执行过程中，若检测到其余任一客户端实例所关联的录音事件也被触发，如客户端实例2所关联的录音事件被触发，则客户端实例2的audiorecord通过audiopolicyservice服务，检查audioflinger服务中是否已经存在服务端录音线程。若判断结果为是，则执行步骤s1022；若判断结果为否，则执行步骤s1023。

s1022：若存在预先生成的服务端录音线程，则在所述服务端录音线程中，分别创建与各个所述客户端实例所对应的音轨区域。

s1023：若不存在预先生成的服务端录音线程，则创建一服务端录音线程后，返回执行所述判断是否存在预先生成的服务端录音线程的步骤。

本发明实施例中，如果audioflinger服务中不存在已经生成的服务端录音线程，则创建一个服务端录音线程1，并返回重新判断当前时刻是否已存在一服务端录音线程的步骤；若存在已经生成的服务端录音线程1，则使用上述已经存在的服务端录音线程1作为与客户端实例2对应的服务端录音线程，并在服务端录音线程1中，创建一个新的音轨区域。例如，图2中，若服务录音线程中已预先存在音轨区域track1，则再新建一个音轨区域track2。可见，此时服务端录音线程1中存在两个音轨区域，且音轨区域track1与客户端实例1对应，音轨区域track2与客户端实例2对应，以保证不同的音轨区域分别与不同的应用程序关联。

优选地，作为本发明的一个实施例，图4示出了本发明实施例提供的应用程序的录音方法s1021的具体实现流程。如图4所示，上述s1021还包括：

s10211：若检测到两个以上的所述客户端实例所关联的录音事件被触发，则确定各个所述客户端实例所请求加载的录音数据的数据格式。

本发明实施例中，在检测到两个以上的客户端实例所关联的录音事件被触发时，确定各个客户端实例所请求加载的录音数据的数据格式。具体地，根据用户在每一应用程序中所发出的格式选取指令，或者，根据应用程序所预设的代码逻辑，确定该应用程序在录音过程中所请求加载的录音数据的数据格式，则该数据格式即为与其对应的客户端实例所请求加载的录音数据的数据格式。

上述录音数据的数据格式包括但不限于录音数据的采样率、采样位数以及通道数等。

s10212：若存在所述请求加载的录音数据的数据格式相同的任意两个所述客户端实例，则确定出其中录音事件触发时间在后的所述客户端实例，并停止关于该客户端实例的所述录音事件。

在触发录音事件的任意两个应用程序中，若检测到上述两个应用程序所对应请求的数据格式相同，则表示二者存在录音冲突，两个应用程序无法同时启动录音。因此，确定出录音事件触发时间在后的应用程序，停止与该应用程序相关的录音操作。

优选地，向停止录音事件的应用程序发出错误提示信息，以使用户基于该错误提示信息，确定当前时刻存在录音冲突事件。

s103：获取预置的音频拾取器所采集得到的录音数据，并将所述录音数据分别存储至各个所述音轨区域。

本发明实施例中，通过控制native层的audio硬件抽象层执行运作，可操控linux内核底层的麦克风硬件进行音频信号的收集，以获取得到对应的录音数据。将采集得到的录音数据存储至当前处于启动状态的服务端录音线程1的音轨区域1中。若同时检测到其余音轨区域存在，则将从麦克风采集到的录音数据存储至上述其余音轨区域。

优选地，作为本发明的一个实施例，图5示出了本发明实施例提供的应用程序的录音方法s103的具体实现流程，详述如下：

s1031：确定所述客户端实例所请求加载的录音数据的数据格式。

s1032：获取预置的音频拾取器所采集得到的录音数据，并识别所述录音数据的脉冲编码调制pcm格式。

模拟音频信号经模数转换所直接形成的二进制序列为脉冲编码调制(pulsecodemodulation，pcm)数据。本发明实施例中，通过控制native层的audio硬件抽象层执行运作，可操控linux内核底层的麦克风硬件进行模拟音频信号的收集，以获取得到对应的录音数据，则当前时刻的录音数据为pcm格式数据。对上述获取得到的录音数据进行读取，以确定录音数据的pcm格式。其中，录音数据的pcm格式包括录音数据的采样率、采样位数以及通道数等。

s1033：若所述pcm格式与所述数据格式不匹配，则将所述录音数据的pcm格式转换为所述数据格式，并将转换后的所述录音数据存储至与该客户端实例对应的所述音轨区域。

本发明实施例中，对于每一个触发录音事件的应用程序，判断当前录音数据的pcm格式与客户端实例所请求加载的录音数据的数据格式是否相同。若判断结果为否，则通过预设的各类转换工具，如convert工具等，把pcm格式数据转换成上述客户端实例所请求加载的录音数据的数据格式后，再将转换后的录音数据存储至与该客户端实例对应的音轨区域。

示例性地，在图2中，当应用程序1启动录音后，由于服务端录音线程1一直处于工作状态，故当应用程序2再启动录音时，服务端录音线程1会将从麦克风获得的pcm数据保存在track2中；但如果从麦克风获得的录音数据的pcm格式与应用程序2所需求的数据格式不一致，则服务端录音线程1会将pcm数据的数据格式转换为应用程序2所需要的数据格式后，再将其保存至track2。

本发明实施例中，在多个应用程序同时录音时，通过检测麦克风所采集到的录音数据的pcm格式，并在pcm格式与应用程序所请求加载的录音数据的数据格式不同的情况下，自动执行录音数据的格式转换处理，保证了仅有格式匹配的录音数据才会被存储至相应的音轨区域track中，从而提高了录音数据的自动化处理效率以及有助于提高系统的交互能力。

s104：对每一所述应用程序所对应的所述客户端实例，在与该客户端实例对应的所述音轨区域中，基于所述服务端录音线程执行录音数据的读取操作，以完成关联该应用程序的录音事件。

示例性地，上述图2中，对于应用程序1所对应的客户端实例1，通过服务端录音线程1，从音轨区域track1中读取其所需的pcm数据；对于应用程序2所对应的客户端实例2，通过服务端录音线程1，从音轨区域track2中读取其所需的pcm数据。

优选地，作为本发明的另一个实施例，在上述s104之后，若接收到关于任一应用程序的录音停止指令，则销毁其客户端实例所对应的音轨区域。

例如，当在应用程序1(应用程序2)中接收到用户发出的录音停止指令时，或者，当检测到应用程序1(应用程序2)因录音时长满足预设条件而触发的录音结束事件时，其相应的track1(track2)则会停止工作并被执行销毁。

本发明实施例中，当检测到两个以上的客户端实例所关联的录音事件被触发时，表示多个应用程序同时启动了录音功能，通过在预先生成的一个服务端录音线程中，分别创建与各个客户端实例所对应的音轨区域，并将采集得到的录音数据分别存储至各个音轨区域，使得各个应用程序在请求加载录音数据时，均能够从自身对应的一个音轨区域中读取所需的录音数据，从而实现多个应用程序的同步录音，保证了每个应用程序在获得录音数据后，能够利用这些录音数据来完成各项不同的应用功能，故提高了应用程序的交互能力；避免了产生应用程序错误的情况，由此也提高了应用程序的稳定性以及可靠性。

本发明实施例中，由于客户端实例audiorecord、audiopolicyservice服务以及audio硬件抽象层均集中在安卓系统的native层，整个录音过程的服务端录音线程以及音轨区域的创建均不涉及安卓的java层，因此，不需要修改应用程序的任何接口和代码，就可以实现多个应用程序同时录音的功能，故在保证了对java层的兼容性的同时，还提高了安卓系统的高可用性。

应理解，上述实施例中各步骤的序号的大小并不意味着执行顺序的先后，各过程的执行顺序应以其功能和内在逻辑确定，而不应对本发明实施例的实施过程构成任何限定。

对应于本发明实施例所提供的应用程序的录音方法，图6示出了本发明实施例提供的应用程序的录音装置的结构框图。为了便于说明，仅示出了与本实施例相关的部分。

参照图6，该装置包括：

第一创建单元61，用于分别创建对应于各个应用程序的客户端实例。

第二创建单元62，用于若检测到两个以上的所述客户端实例所关联的录音事件被触发，则在预先生成的服务端录音线程中，分别创建与各个所述客户端实例所对应的音轨区域。

获取单元63，用于获取预置的音频拾取器所采集得到的录音数据，并将所述录音数据分别存储至各个所述音轨区域。

读取单元64，用于对每一所述应用程序所对应的所述客户端实例，在与该客户端实例对应的所述音轨区域中，基于所述服务端录音线程执行录音数据的读取操作，以完成关联该应用程序的录音事件。

可选地，所述获取单元63包括：

确定子单元，用于确定所述客户端实例所请求加载的录音数据的数据格式。

获取子单元，用于获取预置的音频拾取器所采集得到的录音数据，并识别所述录音数据的脉冲编码调制pcm格式。

转换子单元，用于若所述pcm格式与所述数据格式不匹配，则将所述录音数据的pcm格式转换为所述数据格式，并将转换后的所述录音数据存储至与该客户端实例对应的所述音轨区域。

可选地，所述第二创建单元62包括：

判断子单元，用于若检测到两个以上的所述客户端实例所关联的录音事件被触发，则判断是否存在预先生成的服务端录音线程。

第一创建子单元，用于若存在预先生成的服务端录音线程，则在所述服务端录音线程中，分别创建与各个所述客户端实例所对应的音轨区域。

第二创建子单元，用于若不存在预先生成的服务端录音线程，则创建一服务端录音线程后，返回执行所述判断是否存在预先生成的服务端录音线程的步骤。

可选地，所述判断子单元具体用于：

若检测到两个以上的所述客户端实例所关联的录音事件被触发，则确定各个所述客户端实例所请求加载的录音数据的数据格式；

若存在所述请求加载的录音数据的数据格式相同的任意两个所述客户端实例，则确定出其中录音事件触发时间在后的所述客户端实例，并停止关于该客户端实例的所述录音事件。

可选地，所述读取单元64包括：

对每一所述应用程序所对应的所述客户端实例，在与该客户端实例对应的所述音轨区域中，基于所述服务端录音线程执行录音数据的读取操作；

若接收到关于该应用程序的录音停止指令，则销毁所述客户端实例所对应的所述音轨区域。

本发明实施例中，当检测到两个以上的客户端实例所关联的录音事件被触发时，表示多个应用程序同时启动了录音功能，通过在预先生成的一个服务端录音线程中，分别创建与各个客户端实例所对应的音轨区域，并将采集得到的录音数据分别存储至各个音轨区域，使得各个应用程序在请求加载录音数据时，均能够从自身对应的一个音轨区域中读取所需的录音数据，从而实现多个应用程序的同步录音，保证了每个应用程序在获得录音数据后，能够利用这些录音数据来完成各项不同的应用功能，故提高了应用程序的交互能力；避免了产生应用程序错误的情况，由此也提高了应用程序的稳定性以及可靠性。

图7是本发明一实施例提供的终端设备的示意图。如图7所示，该实施例的终端设备7包括：处理器70、存储器71以及存储在所述存储器71中并可在所述处理器70上运行的计算机程序72，例如应用程序的录音程序。所述处理器70执行所述计算机程序72时实现上述各个应用程序的录音方法实施例中的步骤，例如图1所示的步骤101至104。或者，所述处理器70执行所述计算机程序72时实现上述各装置实施例中各模块/单元的功能，例如图6所示单元61至64的功能。

示例性的，所述计算机程序72可以被分割成一个或多个模块/单元，所述一个或者多个模块/单元被存储在所述存储器71中，并由所述处理器70执行，以完成本发明。所述一个或多个模块/单元可以是能够完成特定功能的一系列计算机程序指令段，该指令段用于描述所述计算机程序72在所述终端设备7中的执行过程。

所述终端设备7可以是桌上型计算机、笔记本、掌上电脑及云端服务器等计算设备。所述终端设备可包括，但不仅限于，处理器70、存储器71。本领域技术人员可以理解，图7仅仅是终端设备7的示例，并不构成对终端设备7的限定，可以包括比图示更多或更少的部件，或者组合某些部件，或者不同的部件，例如所述终端设备还可以包括输入输出设备、网络接入设备、总线等。

所称处理器70可以是中央处理单元(centralprocessingunit，cpu)，还可以是其他通用处理器、数字信号处理器(digitalsignalprocessor，dsp)、专用集成电路(applicationspecificintegratedcircuit，asic)、现成可编程门阵列(field-programmablegatearray，fpga)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件等。通用处理器可以是微处理器或者该处理器也可以是任何常规的处理器等。

所述存储器71可以是所述终端设备7的内部存储单元，例如终端设备7的硬盘或内存。所述存储器71也可以是所述终端设备7的外部存储设备，例如所述终端设备7上配备的插接式硬盘，智能存储卡(smartmediacard,smc)，安全数字(securedigital,sd)卡，闪存卡(flashcard)等。进一步地，所述存储器71还可以既包括所述终端设备7的内部存储单元也包括外部存储设备。所述存储器71用于存储所述计算机程序以及所述终端设备所需的其他程序和数据。所述存储器71还可以用于暂时地存储已经输出或者将要输出的数据。

另外，在本申请各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现，也可以采用软件功能单元的形式实现。

所述集成的单元如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本申请的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的全部或部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本申请各个实施例所述方法的全部或部分步骤。而前述的存储介质包括：u盘、移动硬盘、只读存储器(read-onlymemory，rom)、随机存取存储器(randomaccessmemory，ram)、磁碟或者光盘等各种可以存储程序代码的介质。

以上所述，以上实施例仅用以说明本申请的技术方案，而非对其限制；尽管参照前述实施例对本申请进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本申请各实施例技术方案的精神和范围。