多媒体录制方法、装置、终端及存储介质与流程

本申请实施例涉及终端技术领域，特别涉及一种多媒体录制方法、装置、终端及存储介质。

背景技术：

随着移动终端技术的不断发展，移动终端中应用程序的种类也越来越多。比如，移动终端中同时安装有游戏类应用程序、社交类应用程序、视频播放类应用程序、音频播放类应用程序、即时通信类应用程序和购物类应用程序。

在诸如即时通信类应用程序和社交类应用程序一类的应用程序中，通常会提供多媒体录制功能。比如，通过使用即时通信类应用程序的多媒体录制功能，用户可以与其他用户进行实时视频聊天，或者，将录制的视频分享给其他用户。

技术实现要素：

本申请实施例提供了一种多媒体录制方法、装置、终端及存储介质，可以解决多媒体录制时，若系统资源所提供的性能不足，将影响多媒体录制质量的问题。所述技术方案如下：

一方面，提供了一种多媒体录制方法，所述方法应用于终端，所述终端运行有操作系统和具有多媒体录制功能的目标应用程序，所述方法包括：

所述目标应用程序通过软件开发工具包(softwaredevelopmentkit，sdk)提供的应用程序编程接口(applicationprogramminginterface，api)，向所述操作系统发送多媒体录制参数，所述多媒体录制参数包括音频录制参数和视频录制参数中的至少一种；

所述操作系统接收所述目标应用程序发送的所述多媒体录制参数；

所述操作系统根据所述多媒体录制参数确定资源配置策略，所述资源配置策略为所述目标应用程序录制多媒体时配置系统资源的策略；

所述操作系统根据所述资源配置策略配置所述系统资源。

另一方面，提供了一种多媒体录制装置，所述装置应用于终端，所述终端运行有操作系统和具有多媒体录制功能的目标应用程序，所述装置包括：

目标应用程序模块，用于通过sdk提供的api，向操作系统模块发送多媒体录制参数，所述多媒体录制参数包括音频录制参数和视频录制参数中的至少一种；

所述操作系统模块，用于接收所述目标应用程序模块发送的所述多媒体录制参数；

所述操作系统模块，用于根据所述多媒体录制参数确定资源配置策略，所述资源配置策略为所述目标应用程序录制多媒体时配置系统资源的策略；

所述操作系统模块，用于根据所述资源配置策略配置所述系统资源。

另一方面，提供了一种终端，所述终端包括处理器、与所述处理器相连的存储器，以及存储在所述存储器上的程序指令，所述处理器执行所述程序指令时实现如上述方面所述的多媒体录制方法。

另一方面，提供了一种计算机可读存储介质，其上存储有程序指令，所述程序指令被处理器执行时实现如上述方面所述的多媒体录制方法。

本申请实施例提供的技术方案带来的有益效果至少包括：

目标应用程序通过sdk提供的api接口，向操作系统发送多媒体录制时采用的多媒体录制参数，以便操作系统基于多媒体录制参数制定相应的资源配置策略，进而根据该资源配置策略为目标应用程序配置相应的系统资源，保证目标应用程序在配置后的系统资源下达到较好的多媒体录制效果；本申请实施例中的操作系统可以根据多媒体录制相关的参数，针对性地为应用程序分配相应系统资源，使得系统资源提供的性能能够满足多媒体的录制需求，从而避免因系统资源所提供的性能不足而影响多媒体录制质量的问题，有助于提高多媒体的录入质量。

附图说明

图1是本申请一个示例性实施例提供的终端的结构示意图；

图2是终端中应用程序与操作系统通信过程的实施示意图；

图3是本申请一个示例性实施例提供的终端的结构示意图；

图4和图5是图3所示终端中应用程序与操作系统通信过程的实施示意图；

图6是本申请另一个示例性实施例提供的终端的结构示意图；

图7示出了本申请一个示例性实施例示出的多媒体录制方法的流程图；

图8示出了本申请另一个示例性实施例示出的多媒体录制方法的流程图；

图9示出了本申请另一个示例性实施例示出的多媒体录制方法的流程图；

图10示出了本申请另一个示例性实施例示出的多媒体录制方法的流程图；

图11示出了本申请一个实施例提供的多媒体录制装置的结构框图。

具体实施方式

为使本申请的目的、技术方案和优点更加清楚，下面将结合附图对本申请实施方式作进一步地详细描述。

下面的描述涉及附图时，除非另有表示，不同附图中的相同数字表示相同或相似的要素。以下示例性实施例中所描述的实施方式并不代表与本申请相一致的所有实施方式。相反，它们仅是与如所附权利要求书中所详述的、本申请的一些方面相一致的装置和方法的例子。

在本申请的描述中，需要理解的是，术语“第一”、“第二”等仅用于描述目的，而不能理解为指示或暗示相对重要性。在本申请的描述中，需要说明的是，除非另有明确的规定和限定，术语“相连”、“连接”应做广义理解，例如，可以是固定连接，也可以是可拆卸连接，或一体地连接；可以是机械连接，也可以是电连接；可以是直接相连，也可以通过中间媒介间接相连。对于本领域的普通技术人员而言，可以具体情况理解上述术语在本申请中的具体含义。此外，在本申请的描述中，除非另有说明，“多个”是指两个或两个以上。“和/或”，描述关联对象的关联关系，表示可以存在三种关系，例如，a和/或b，可以表示：单独存在a，同时存在a和b，单独存在b这三种情况。字符“/”一般表示前后关联对象是一种“或”的关系。

请参考图1，其示出了本申请一个示例性实施例提供的终端100的结构方框图。该终端100可以是智能手机、平板电脑、电子书等能够运行应用程序的电子设备。本申请中的终端100可以包括一个或多个如下部件：处理器110、存储器120和输入输出装置130。

处理器110可以包括一个或者多个处理核心。处理器110利用各种接口和线路连接整个终端100内的各个部分，通过运行或执行存储在存储器120内的指令、程序、代码集或指令集，以及调用存储在存储器120内的数据，执行终端100的各种功能和处理数据。可选地，处理器110可以采用数字信号处理(digitalsignalprocessing，dsp)、现场可编程门阵列(field－programmablegatearray，fpga)、可编程逻辑阵列(programmablelogicarray，pla)中的至少一种硬件形式来实现。处理器110可集成中央处理器(centralprocessingunit，cpu)、图像处理器(graphicsprocessingunit，gpu)和调制解调器等中的一种或几种的组合。其中，cpu主要处理操作系统、用户界面和应用程序等；gpu用于负责显示内容的渲染和绘制；调制解调器用于处理无线通信。可以理解的是，上述调制解调器也可以不集成到处理器110中，单独通过一块通信芯片进行实现。

存储器120可以包括随机存储器(randomaccessmemory，ram)，也可以包括只读存储器(read-onlymemory)。可选地，该存储器120包括非瞬时性计算机可读介质(non-transitorycomputer-readablestoragemedium)。存储器120可用于存储指令、程序、代码、代码集或指令集。存储器120可包括存储程序区和存储数据区，其中，存储程序区可存储用于实现操作系统的指令、用于实现至少一个功能的指令(比如触控功能、声音播放功能、图像播放功能等)、用于实现下述各个方法实施例的指令等，该操作系统可以是安卓(android)系统(包括基于android系统深度开发的系统)、苹果公司开发的ios系统(包括基于ios系统深度开发的系统)或其它系统。存储数据区还可以存储终端100在使用中所创建的数据(比如电话本、音视频数据、聊天记录数据)等。

存储器120可分为操作系统空间和用户空间，操作系统即运行于操作系统空间，原生及第三方应用程序即运行于用户空间。为了保证不同第三方应用程序均能够达到较好的运行效果，操作系统针对不同第三方应用程序为其分配相应的系统资源。然而，同一第三方应用程序中不同应用场景对系统资源的需求也存在差异，比如，在本地资源加载场景下，第三方应用程序对磁盘读取速度的要求较高；在动画渲染场景下，第三方应用程序则对gpu性能的要求较高。而操作系统与第三方应用程序之间相互独立，操作系统往往不能及时感知第三方应用程序当前的应用场景，导致操作系统无法根据第三方应用程序的具体应用场景进行针对性的系统资源适配。

如图2所示，为了使操作系统能够区分第三方应用程序的具体应用场景，需要打通第三方应用程序与操作系统之间的数据通信，使得操作系统能够随时获取第三方应用程序当前的场景信息，进而基于当前场景进行针对性的系统资源适配。

以操作系统为android系统为例，存储器120中存储的程序和数据如图3所示，存储器120中可存储有linux内核层220、系统运行库层240、应用框架层260和应用层280，其中，linux内核层220、系统运行库层240和应用框架层260属于操作系统空间，应用层280属于用户空间。linux内核层220为终端100的各种硬件提供了底层的驱动，如显示驱动、音频驱动、摄像头驱动、蓝牙驱动、wi-fi驱动、电源管理等。系统运行库层240通过一些c/c++库来为android系统提供了主要的特性支持。如sqlite库提供了数据库的支持，opengl/es库提供了3d绘图的支持，webkit库提供了浏览器内核的支持等。在系统运行库层240中还提供有安卓运行时库(androidruntime)，它主要提供了一些核心库，能够允许开发者使用java语言来编写android应用。应用框架层260提供了构建应用程序时可能用到的各种api，开发者也可以通过使用这些api来构建自己的应用程序，比如活动管理、窗口管理、视图管理、通知管理、内容提供者、包管理、通话管理、资源管理、定位管理。应用层280中运行有至少一个应用程序，这些应用程序可以是操作系统自带的原生应用程序，比如联系人程序、短信程序、时钟程序、相机应用等；也可以是第三方开发者所开发的第三方应用程序，比如游戏类应用程序、即时通信程序、相片美化程序、购物程序等。

操作系统与第三方应用程序之间一种可行的通信方式如图4所示，第三方应用程序中内嵌有用于与操作系统进行通信的软件开发工具包(softwaredevelopmentkit，sdk)。

其中，sdk包含若干经过抽象的应用程序编程接口(applicationprogramminginterface，api)，并由操作系统开发者提供给第三方应用程序开发者，并由第三方应用程序开发者将该sdk内嵌到第三方应用程序中。此类第三方应用程序安装并运行在操作系统后，即可调用sdk提供的api与操作系统进行通信。

如图4所示，系统运行库层240可以额外包括接口通信系统242。该接口通信系统242可以视为操作系统中的一个子系统，或视为操作系统内嵌的一个应用程序。接口通信系统242中设置有sdk接口，第三方应用程序即调用内嵌sdk的api与该sdk接口之间通过粘合(binder)的方式进行数据通信。这样，第三方应用程序的应用场景相关的数据就可以通过sdk传输给操作系统。借助内嵌sdk，操作系统还可以主动向第三方应用程序传输数据，或者，操作系统与第三方应用程序之间可以进行双向数据传输。

在另一种可行的通信方式中，如图5所示，第三方应用程序还可以采用套接字(socket)方式与接口通信系统242的socket接口建立长连接，第三方应用程序的应用场景相关的数据即可以通过该长连接传输给操作系统。

如图4和5所示，接口通信系统242中可设置有不同的策略模块，接收到第三方应用程序发送的数据后，接口通信系统242即采用第三方应用程序对应的策略模块对数据进行分析，得到相应的资源适配优化策略。基于分析得到的资源适配优化策略，接口通信系统242通过控制接口通知linux内核层220进行系统资源适配优化。其中，该控制接口可以采用sysfs的方式与linux内核层220进行通信。

可选的，接口通信系统242中不同的策略模块可以对应不同的第三方应用程序(即针对不同的应用程序设置策略模块)，或者，不同的策略模块对应不同类型的第三方应用程序(即针对不同类型的应用程序设置策略模块)，或者，不同的策略模块对应不同的系统资源(即针对不同系统资源设置策略模块)，或者，不同的策略模块对应不同的应用场景(即针对不同的以应用场景设置策略模块)，本申请实施例并不对策略模块的具体设置方式进行限定。。

其中，接口通信系统242还可以通过binder的方式与应用框架层260进行通信，用于接收应用框架层260发送的前景应用信息，从而基于前景应用信息，仅针对当前前台运行的第三方应用程序进行系统资源优化。

以操作系统为ios系统为例，存储器120中存储的程序和数据如图6所示，ios系统包括：核心操作系统层320(coreoslayer)、核心服务层340(coreserviceslayer)、媒体层360(medialayer)、可触摸层380(cocoatouchlayer)。核心操作系统层320包括了操作系统内核、驱动程序以及底层程序框架，这些底层程序框架提供更接近硬件的功能，以供位于核心服务层340的程序框架所使用。核心服务层340提供给应用程序所需要的系统服务和/或程序框架，比如基础(foundation)框架、账户框架、广告框架、数据存储框架、网络连接框架、地理位置框架、运动框架等等。媒体层360为应用程序提供有关视听方面的接口，如图形图像相关的接口、音频技术相关的接口、视频技术相关的接口、音视频传输技术的无线播放(airplay)接口等。可触摸层380为应用程序开发提供了各种常用的界面相关的框架，可触摸层380负责用户在终端100上的触摸交互操作。比如本地通知服务、远程推送服务、广告框架、游戏工具框架、消息用户界面接口(userinterface，ui)框架、用户界面uikit框架、地图框架等等。

在图6所示出的框架中，与大部分应用程序有关的框架包括但不限于：核心服务层340中的基础框架和可触摸层380中的uikit框架。基础框架提供许多基本的对象类和数据类型，为所有应用程序提供最基本的系统服务，和ui无关。而uikit框架提供的类是基础的ui类库，用于创建基于触摸的用户界面，ios应用程序可以基于uikit框架来提供ui，所以它提供了应用程序的基础架构，用于构建用户界面，绘图、处理和用户交互事件，响应手势等等。

其中，在ios系统中实现第三方应用程序与操作系统数据通信的方式以及原理可参考android系统，本申请在此不再赘述。

输入输出装置130可以包括触摸显示屏，该触摸显示屏用于接收用户使用手指、触摸笔等任何适合的物体在其上或附近的触摸操作，以及显示各个应用程序的用户界面。触摸显示屏通常设置在终端100的前面板。触摸显示屏可被设计成为全面屏、曲面屏或异型屏。触摸显示屏还可被设计成为全面屏与曲面屏的结合，异型屏与曲面屏的结合，本申请实施例对此不加以限定。

除此之外，本领域技术人员可以理解，上述附图所示出的终端100的结构并不构成对终端100的限定，终端可以包括比图示更多或更少的部件，或者组合某些部件，或者不同的部件布置。比如，终端100中还包括射频电路、输入单元、传感器、音频电路、无线保真(wirelessfidelity，wifi)模块、电源、蓝牙模块等部件，在此不再赘述。

相关技术中，具有多媒体录制功能的应用程序在进行多媒体录制时，若系统资源提供的性能不足，将影响多媒体的录制质量。比如，当进行视频录制时，系统资源提供的性能不足将导致视频分辨率降低、视频丢帧、甚至视频数据丢失等问题；当进行音频录制时，系统资源提供的性能不足将导致音节丢失、音频中断等问题。

为了解决上述问题，本申请实施例提供的多媒体录制方法中，应用程序在进行多媒体录制时，通过调用sdk中的api，向操作系统发送多媒体录制参数，以便操作系统根据多媒体录制参数为应用程序配置相应的系统资源，为多媒体录制提供足够的性能。

本申请各个实施例提供的多媒体录制方法，可以应用于多媒体录制场景(比如视频录制场景、音频录制场景)或者多媒体通信场景(比如视频通话场景、音频通话长场景)。示意性的，该方法可以用于即时通信应用程序中的视频通话场景，或者，可以用于短视频应用程序中的短视频录制场景。下面采用示意性的实施例进行说明。

请参考图7，其示出了本申请一个示例性实施例示出的多媒体录制方法的流程图。本实施例以该方法应用于终端100，且终端100运行有操作系统和具有多媒体录制功能的目标应用程序来举例说明。该方法包括：

步骤701，目标应用程序通过sdk提供的api，向操作系统发送多媒体录制参数，多媒体录制参数包括音频录制参数和视频录制参数中的至少一种。

其中，该sdk可以是内嵌在目标应用程序中由操作系统开发商提供的sdk，也可以是位于操作系统的系统运行库层的.so文件的动态库(dynamiclinklibrary，dll)中的sdk。为了方便说明，下述实施例以sdk为内嵌在目标应用程序中的sdk为例进行说明。

可选的，目标应用程序通过调用sdk提供的api，目标应用程序即与操作系统之间建立binder连接，从而通过该binder连接与操作系统进行数据通信。其中，该binder连接可以是单向连接，也可以是双向连接。

可选的，多媒体录制参数用于指示多媒体的录制质量，其中包含与音频质量相关的音频录制参数，和/或，与视频质量相关的视频录制参数。

可选的，音频录制参数包括音频格式、音频压缩算法、音频采样率中的至少一种；视频录制参数包括视频格式、视频帧率、视频码率、视频分辨率中的至少一种。

针对发送多媒体录制参数的时机，在一种可能的实施方式中，目标应用程序每隔预定时间间隔向操作系统发送获取到的多媒体录制参数，比如，该预定时间间隔为5s或10s；在另一种可能的实施方式中，当接收到多媒体录制指令时(比如在即时通信应用中接收到视频发起指令时)，目标应用程序即调用sdk提供的api，向操作系统发送资源配置请求，该资源配置请求中即包含多媒体录制参数。

可选的，当接收到多媒体录制指令时，目标应用程序获取录制类型，该录制类型包括音频录制、视频录制和音视频录制中的至少一种；目标应用程序根据所述录制类型获取多媒体录制参数。

步骤702，操作系统接收目标应用程序发送的多媒体录制参数。

如图4所示，操作系统通过接口通信系统242的sdk接口，接收目标应用程序发送的多媒体录制参数。

为了避免非法应用程序通过调用sdk提供的api与操作系统进行通信，造成系统安全隐患以及系统资源滥用，可选的，操作系统接收到多媒体录制参数后，获取目标应用程序的应用标识。

可选的，操作系统接收目标应用程序发送的多媒体录制参数的同时，接收目标应用程序发送的应用标识，该应用标识用于唯一标识应用程序。

操作系统中存储有预设应用标识列表，该预设应用标识列表中包含支持进行资源配置的应用程序的应用标识。可选的，该列表由操作系统开发商设置，且加密存储在终端内。

若目标应用程序的应用标识属于预设应用标识列表，操作系统则执行步骤703，若目标应用程序的应用标识不属于预设应用标识列表，操作系统则不响应多媒体录制参数。

可选的，当目标应用程序的应用标识不属于预设应用标识列表时，操作系统断开与目标应用程序之间的连接。

步骤703，操作系统根据多媒体录制参数确定资源配置策略，资源配置策略为目标应用程序录制多媒体时配置系统资源的策略。

操作系统能够分配的系统资源包括硬件资源和软件资源，而不同应用场景下，目标应用程序对不同系统资源的需求程度不同，因此，为了实现针对不同的应用场景，为应用程序动态配置系统资源，操作系统根据目标应用程序发送的多媒体录制，制定相应的资源配置策略。

本申请实施例中，资源配置策略用于指示硬件资源的配置方式。可选的，该硬件资源包括中央处理器(centralprocessingunit，cpu)资源、内存资源、嵌入式的多媒体存储卡(embeddedmultimediacard，emmc)资源、通用闪存存储卡(universalflashstorage，ufs)资源、音频信号处理器(audiosignalprocessor，asp)资源和图像信号处理器(imagesignalprocessor，isp)资源中的至少一种。

可选的，该资源配置策略中包括硬件资源的工作频率、核心数、带宽以及工作电压等参数。

在一种可能的实施方式中，操作系统根据多媒体录制参数确定多媒体录制负载，从而根据多媒体录制负载确定相应的资源配置策略。

可选的，该资源配置策略中至少包括：待配置系统资源的资源类型以及资源配置参数。

步骤704，操作系统根据资源配置策略配置系统资源。

进一步的，根据制定出的资源配置策略，操作系统与内核层进行通信，从而指示内核层对相应的系统资源进行配置。

示意性的，如图4所示，操作系统中接口通信系统242即通过控制接口与linux内核层220进行通信，最终完成系统资源优化配置。

可选的，对于能够通过直接通讯的方式进行控制的系统资源(比如cpu资源)，操作系统直接调用此类系统资源对应的抽象接口完成资源配置；而对于操作系统无法直接访问控制的系统资源，操作系统采用代理的方式，通过代理与此类系统资源对应的子系统进行间接通讯，从而完成系统资源配置。

可选的，当目标应用程序结束生命周期时(应用程序的进程结束)，或者，目标应用程序停止多媒体录制时，操作系统断开与目标应用程序之间的连接，并清理数据通道，以便后续与其他应用程序建立连接。

综上所述，本申请实施例中，目标应用程序通过sdk提供的api接口，向操作系统发送多媒体录制时采用的多媒体录制参数，以便操作系统基于多媒体录制参数制定相应的资源配置策略，进而根据该资源配置策略为目标应用程序配置相应的系统资源，保证目标应用程序在配置后的系统资源下达到较好的多媒体录制效果；本申请实施例中的操作系统可以根据多媒体录制相关的参数，针对性地为应用程序分配相应系统资源，使得系统资源提供的性能能够满足多媒体的录制需求，从而避免因系统资源所提供的性能不足而影响多媒体录制质量的问题，有助于提高多媒体的录入质量。

在一种可能的实施方式中，操作系统根据接收到的多媒体录制参数，确定按照该多媒体录制参数进行录制时的多媒体录制负载，从而根据该多媒体录制负载确定资源配置策略。下面采用示意性的实施例进行说明。

请参考图8，其示出了本申请另一个示例性实施例示出的多媒体录制方法的流程图。本实施例以该方法应用于终端100中来举例说明。该方法包括：

步骤801，目标应用程序通过sdk提供的api，向操作系统发送多媒体录制参数，多媒体录制参数包括音频录制参数和视频录制参数中的至少一种。

步骤802，操作系统接收目标应用程序发送的多媒体录制参数。

上述步骤801至802的实施方式可以参考步骤701至702，本实施例在此不再赘述。

步骤803，操作系统根据多媒体录制参数计算多媒体录制负载，多媒体录制负载指根据多媒体录制参数录制多媒体时的系统负载。

根据接收到的多媒体录制参数，操作系统通过预设负载计算公式计算多媒体录制负载，从而基于该多媒体录制负载指定资源配置策略。

在一种可能的实施方式中，多媒体录制负载用于指示录制多媒体时，单位时间内的多媒体数据处理量，其中，单位时间内的多媒体数据处理量越大，多媒体录制负载越大。

针对不同的多媒体录制类型，且计算多媒体录制负载的方式也不同，在一种可能的实施方式中，当进行视频录制时，操作系统接收到的多媒体录制参数为视频录制参数，该视频录制参数中至少包含视频格式、视频帧率和视频码率，操作系统根据视频录制参数计算多媒体录制负载时可以包括如下步骤。

一、操作系统获取视频格式对应的视频压缩比。

由于通过摄像头采集到的视频图像需要经过压缩(视频编码过程)后发送，而视频压缩方式与数据处理量相关，因此，操作系统根据视频录制的视频格式确定视频压缩比。

在一种可能的实施方式中，操作系统预先存储有不同视频格式与视频压缩比之间的对应关系，当获取到视频录制参数时，操作系统即基于该对应关系查找相应的视频压缩比。

其中，视频格式包括avi、mov、asf、wmv、navi、3gp、mkv、flv、rmvb中的至少一种，本申请并不对视频录制所采用的视频格式进行限定。

当然，若视频录制参数中包含视频压缩比，操作系统即直接获取该视频压缩比，而无需根据视频格式查询，本实施例对此不做限定。

比如，终端根据视频格式flv，获取到对应的视频压缩比为5:1。

二、操作系统根据视频压缩比、视频帧率和视频码率，计算单位时间内的视频数据处理量。

进一步的，根据视频压缩比、视频帧率和视频码率，操作系统计算得到单位时间内的视频数据处理量，该视频数据处理量即为按照视频录制参数进行录制时，终端每秒需要处理的视频数据量。其中，视频压缩比、视频帧率和视频码率均与视频数据处理量呈正相关关系。

可选的，该视频数据处理量＝视频压缩比×视频帧率×视频码率。

比如，当视频压缩比为5:1，视频帧率为20帧/s，视频码率为200kbps时，单位时间内的视频数据处理量即为5×20×200＝20000。

需要说明的是，若视频录制参数中不包含视频码率，而包括视频分辨率，操作系统可以根据视频分辨率和视频帧率计算得到视频码率，本实施例在此不再赘述。

三、操作系统根据视频数据处理量确定多媒体录制负载。

根据计算得到的单位时间内的视频数据处理量，操作系统确定多媒体录制负载，其中，多媒体录制负载与单位时间的视频数据处理量呈正相关关系。

在一种可能的实施方式中，操作系统中存储有视频数据处理量与多媒体录制负载之间的对应关系，后续操作系统即基于该对应关系确定多媒体负载。

在另一种可能的实施方式中，操作系统根据负载计算公式，将视频数据处理量映射到多媒体录制负载区间中，得到视频数据处理量对应的多媒体录制负载。比如，负载计算公式可以表示为：多媒体录制负载＝视频数据处理量/1000，多媒体录制负载区间为[0,100]。本申请实施例并不对基于视频数据处理量确定多媒体录制负载的具体方式进行限定。

比如，操作系统视频数据处理量20000，确定出媒体录制负载为20。

在另一种可能的实施方式中，当进行音频录制时，操作系统接收到的多媒体录制参数为音频录制参数，该音频录制参数中至少包含音频格式和音频采样率，操作系统根据音频录制参数计算多媒体录制负载时可以包括如下步骤。

一、操作系统获取音频格式对应的音频压缩比。

由于通过麦克风采集到的音频数据需要经过压缩(音频编码过程)后发送，而音频压缩方式与数据处理量相关，因此，操作系统根据音频录制的音频格式确定音频压缩比。

在一种可能的实施方式中，操作系统预先存储有不同音频格式与音频压缩比之间的对应关系，当获取到视频录制参数时，操作系统即基于该对应关系查找相应的音频压缩比。

其中，音频格式包括mp3、aac、m4a/mp4、wma、ape、mpc、ogg、wave、cd、flac、rm、tta、aiff、au中的至少一种，本申请并不对音频录制所采用的音频格式进行限定。

当然，若音频录制参数中包含音频压缩比，操作系统即直接获取该音频压缩比，而无需根据音频格式查询，本实施例对此不做限定。

比如，终端根据音频格式aac，获取到对应的音频压缩比为18:1。

二、操作系统根据音频压缩比和音频采样率，计算单位时间内的音频数据处理量。

进一步的，根据音频压缩比和音频采样率，操作系统计算得到单位时间内的音频数据处理量，该音频数据处理量即为按照音频录制参数进行录制时，终端每秒需要处理的音频数据量。其中，音频压缩比和音频采样率均与音频数据处理量呈正相关关系。

可选的，该音频数据处理量＝音频压缩比×音频采样率。

比如，当音频压缩比为18:1，音频采样率22.05khz时，单位时间内的音频数据处理量即为18×22.05＝396.9。

三、操作系统根据音频数据处理量确定多媒体录制负载。

根据计算得到的单位时间内的音频数据处理量，操作系统确定多媒体录制负载，其中，多媒体录制负载与单位时间的音频数据处理量呈正相关关系。

在一种可能的实施方式中，操作系统中存储有音频数据处理量与多媒体录制负载之间的对应关系，后续操作系统即基于该对应关系确定多媒体负载。

在另一种可能的实施方式中，操作系统根据负载计算公式，将音频数据处理量映射到多媒体录制负载区间中，得到音频数据处理量对应的多媒体录制负载。比如，负载计算公式可以表示为：多媒体录制负载＝音频数据处理量/20，多媒体录制负载区间为[0,100]。本申请实施例并不对基于视频数据处理量确定多媒体录制负载的具体方式进行限定。

比如，操作系统视频数据处理量396.9，确定出媒体录制负载为19.85。

在其他可能的实施方式中，当多媒体录制为音视频录制时，操作系统分别根据视频录制参数计算视频录制负载，根据音频录制参数计算音频录制负载，从而根据视频录制负载和音频录制负载确定多媒体录制负载，本实施例在此不再赘述。

步骤804，操作系统根据多媒体录制负载确定资源配置策略。

由于并非所有应用程序进行多媒体录制时都会造成较大负载，因此为了避免系统资源浪费，操作系统首先确定该多媒体录制负载下是否需要进行系统资源配置，并在确定需要进行系统资源配置时，确定资源配置策略；否则操作系统保持当前系统资源配置。

可选的，如图9所示，本步骤可以包括如下步骤：

步骤804a，操作系统确定多媒体录制负载对应的目标系统资源。

在一种可能的实施方式中，操作系统根据多媒体录制负载，在预设对应关系中查找多媒体录制负载对应的目标系统资源，预设对应关系中包含多媒体录制负载和系统资源之间的对应关系。该预设对应关系示意性如表一所示。

表一

操作系统确定出多媒体录制负载后，即基于该对应关系确定对应的目标系统资源。

比如，操作系统根据该多媒体录制负载30，确定出目标资源为cpu资源(cpu核心数量为3，cpu电压为765mv)、内存资源(内存2.7g)、emmc资源(频率166mhz)。

步骤804b，若当前系统资源未达到目标系统资源，操作系统则根据目标系统资源和当前系统资源确定资源配置策略，资源配置策略用于指示将当前系统资源上调至目标系统资源。

进一步的，操作系统获取当前系统资源，并检测当前系统资源是否达到目标系统资源，若已达到，则确定当前系统资源提供的性能能够保证多媒体录制质量，无需重新制定资源配置策略；若未达到，则需要重新制定资源配置策略。

可选的，若当前系统资源超过目标系统资源，操作系统将当前系统资源下调为目标系统资源，从而降低终端的功耗。

在一种可能的实施方式中，操作系统根据目标系统资源和当前系统资源计算两者的系统资源差，从而根据该系统资源差生成资源配置策略。后续操作系统即在当前系统资源基础上，根据系统资源差上调相应系统资源，使得系统资源达到目标系统资源。

在其他可能的实施方式中，操作系统直接根据目标系统资源生成资源配置策略，后续操作系统即根据资源配置策略将当前系统资源上调至目标系统资源。

步骤805，操作系统根据资源配置策略配置系统资源。

本步骤的实施方式可以参考上述步骤704，本实施例在此不再赘述。

本实施例中，操作系统根据多媒体录制参数计算得到多媒体录制负载，并基于该多媒体录制负载确定出资源配置策略，从而实现在多媒体录制负载过大是上调系统资源，确保多媒体录制的录制质量。

另外，本实施例中，操作系统根据多媒体录制参数计算单位时间内多媒体数据处理量，并根据该多媒体数据量确定出多媒体录制负载，提高了确定出的多媒体录制负载的准确性。

在一种可能的实施方式中，该sdk还具有提高(boost)特性，通过该boost特性，操作系统能够提供足够的性能，从而防止因系统资源突变导致的多媒体录制质量下降。在图8的基础上，如图10所示，步骤803之后还包括步骤806，步骤804可以被替换为步骤807。

步骤806，操作系统在多媒体录制负载的基础上增加负载盈余。

通过上述步骤801至803计算得到多媒体录制负载后，操作系统在该多媒体录制负载的基础上增加负载盈余，即提高多媒体录制负载。

在一种可能的实施方式中，该负载盈余为定值，比如，该负载盈余为5。

在另一种可能的实施方式中，该负载盈余与多媒体录制负载之间正负相关关系，即多媒体录制负载越高，该负载盈余越大，从而保证高多媒体录制负载状态下多媒体录制质量的稳定性。比如，该负载盈余为多媒体录制负载的10％。

比如，操作系统根据多媒体录制参数计算得到多媒体录制负载为80，从而确定负载盈余为80×10％＝8，进而计算得到增加负载盈余后的多媒体录制负载为88。

步骤807，操作系统根据增加负载盈余后的多媒体录制负载确定资源配置策略。

在一种可能的实施方式中，操作系统根据增加负载盈余后的多媒体录制负载确定对应的目标系统资源，并根据当前系统资源和目标系统资源确定资源配置策略。其实施方式可以参考上述步骤804，本实施例在此不再赘述。

本实施例中，操作系统通过在多媒体录制负载的基础上增加负载盈余，确保为多媒体录制配置足够的系统资源，避免因系统资源突变导致多媒体录制质量下降的同时，保证多媒体录制的稳定性。

下述为本申请装置实施例，可以用于执行本申请方法实施例。对于本申请装置实施例中未披露的细节，请参照本申请方法实施例。

请参考图11，其示出了本申请一个实施例提供的多媒体录制装置的结构示意图。该多媒体录制装置可以通过专用硬件电路，或者，软硬件的结合实现成为图1中的终端的全部或一部分，该多媒体录制装置包括：目标应用程序模块1110和操作系统模块1120。

目标应用程序模块1110，用于通过sdk提供的api，向操作系统模块1120发送多媒体录制参数，所述多媒体录制参数包括音频录制参数和视频录制参数中的至少一种；

所述操作系统模块1120，用于接收所述目标应用程序模块1110发送的所述多媒体录制参数；

所述操作系统模块1120，用于根据所述多媒体录制参数确定资源配置策略，所述资源配置策略为所述目标应用程序录制多媒体时配置系统资源的策略；

所述操作系统模块1120，用于根据所述资源配置策略配置所述系统资源。

可选的，所述操作系统模块1120，用于：

根据所述多媒体录制参数计算多媒体录制负载，所述多媒体录制负载指根据所述多媒体录制参数录制多媒体时的系统负载；

根据所述多媒体录制负载确定所述资源配置策略。

可选的，所述多媒体录制参数为所述视频录制参数，所述视频录制参数包含视频格式、视频帧率和视频码率；

所述操作系统模块1120，用于：

获取所述视频格式对应的视频压缩比；

根据所述视频压缩比、所述视频帧率和所述视频码率，计算单位时间内的视频数据处理量；

根据所述视频数据处理量确定所述多媒体录制负载。

可选的，所述多媒体录制参数为所述音频录制参数，所述音频录制参数包含音频格式和音频采样率；

所述操作系统模块1120，用于：

获取所述音频格式对应的音频压缩比；

根据所述音频压缩比和所述音频采样率，计算单位时间内的音频数据处理量；

根据所述音频数据处理量确定所述多媒体录制负载。

可选的，所述操作系统模块1120，用于：

确定所述多媒体录制负载对应的目标系统资源；

若当前系统资源未达到所述目标系统资源，则根据所述目标系统资源和所述当前系统资源确定所述资源配置策略，所述资源配置策略用于指示将所述当前系统资源上调至所述目标系统资源。

可选的，操作系统模块1120，用于：

所述操作系统根据所述多媒体录制负载，在预设对应关系中查找所述多媒体录制负载对应的所述目标系统资源，所述预设对应关系中包含所述多媒体录制负载和所述系统资源之间的对应关系。

可选的，操作系统模块1120，还用于

在所述多媒体录制负载的基础上增加负载盈余；

根据增加负载盈余后的所述多媒体录制负载确定所述资源配置策略。

可选的，所述系统资源包括cpu资源、内存资源、emmc资源、ufs卡资源、asp资源和isp资源中的至少一种。

综上所述，本申请实施例中，目标应用程序通过sdk提供的api接口，向操作系统发送多媒体录制时采用的多媒体录制参数，以便操作系统基于多媒体录制参数制定相应的资源配置策略，进而根据该资源配置策略为目标应用程序配置相应的系统资源，保证目标应用程序在配置后的系统资源下达到较好的多媒体录制效果；本申请实施例中的操作系统可以根据多媒体录制相关的参数，针对性地为应用程序分配相应系统资源，使得系统资源提供的性能能够满足多媒体的录制需求，从而避免因系统资源所提供的性能不足而影响多媒体录制质量的问题，有助于提高多媒体的录入质量。

相关细节可结合参考图7至图10所示的方法实施例。其中，操作系统模块1110还用于实现上述方法实施例中其他任意隐含或公开的由操作系统所执行的步骤相关的功能；目标应用程序模块1120还用于实现上述方法实施例中其他任意隐含或公开的由目标应用程序所执行的步骤相关的功能。

需要说明的是，上述实施例提供的装置，在实现其功能时，仅以上述各功能模块的划分进行举例说明，实际应用中，可以根据需要而将上述功能分配由不同的功能模块完成，即将设备的内部结构划分成不同的功能模块，以完成以上描述的全部或者部分功能。另外，上述实施例提供的装置与方法实施例属于同一构思，其具体实现过程详见方法实施例，这里不再赘述。

本申请还提供一种计算机可读介质，其上存储有程序指令，程序指令被处理器执行时实现上述各个方法实施例提供的多媒体录制方法。

本申请还提供了一种包含指令的计算机程序产品，当其在计算机上运行时，使得计算机执行上述各个实施例所述的多媒体录制方法。

上述本申请实施例序号仅仅为了描述，不代表实施例的优劣。

本领域普通技术人员可以理解实现上述实施例方法中全部或部分步骤可以通过硬件来完成，也可以通过程序来指令相关的硬件完成，所述的程序可以存储于一种计算机可读存储介质中，上述提到的存储介质可以是只读存储器，磁盘或光盘等。以上所述仅为本申请的较佳实施例，并不用以限制本申请，凡在本申请的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本申请的保护范围之内。