CN110764724B - 一种显示设备控制方法、装置、设备及存储介质 - Google Patents

Abstract

本申请公开了一种显示设备控制方法、装置、设备及存储介质，包括：处理芯片获取对车载系统的多个显示设备中每个显示设备上触发的多媒体数据处理请求，多媒体数据处理请求用于请求播放或录制多媒体数据；为每个显示设备分别独立的处理对应的多媒体处理请求，得到对应的是否播放或录制该多媒体数据的处理策略，从而可以根据该处理策略对显示设备进行相应的控制。可见，单个处理芯片能够对多个显示设备上的应用的多媒体数据处理请求，分别独立的进行处理，从而可以利用一个处理芯片实现对多个显示设备播放或录制多媒体数据进行控制，所需配备的处理芯片数量得以减少，从而可以有效降低硬件成本。

Description

一种显示设备控制方法、装置、设备及存储介质

技术领域

本申请涉及设备控制技术领域，特别是涉及一种显示设备控制方法、装置、设备及存储介质。

背景技术

随着车载智能座舱系统的日益发展，为了满足人们对汽车的个性化和差异化需求，在车辆上配置车载多屏互联系统逐渐成为主流需求。其中，车载多屏互联系统，是指在车辆上配置多个屏幕，各个屏幕之间可以通过车载局域网实现互联互动。其中，每个屏幕会配备有专门的处理芯片，如系统级芯片(system on chip，SoC)等，用于支持该屏幕的音频播放。比如，可以在车辆中控台处安装主控屏、在车辆前座靠枕背面安装头枕屏等，其中，主控屏可以用于语音播放当前行驶路线的导航信息，头枕屏可以用于播放电影、音乐等。

虽然，在车辆上配置车载多屏互联系统可以满足用户的差异化需求，但是车载多屏互联系统中的各个屏幕均需要配备专门的处理芯片，会使得实现该车载多屏互联系统的硬件成本较高。

发明内容

本申请实施例提供了一种显示设备控制方法、装置、设备及存储介质，以降低车载多屏互联系统的硬件成本。

第一方面，本申请实施例提供了一种显示设备控制方法，包括：

获取对车载系统的多个显示设备中每个显示设备上触发的多媒体数据处理请求，所述多媒体数据处理请求用于请求播放或录制多媒体数据；

为所述每个显示设备分别独立的处理对应的多媒体数据处理请求，得到对应的是否播放或录制所述多媒体数据的处理策略；

根据所述处理策略对所述显示设备进行相应的控制。

在一些可能的实施方式中，所述多媒体数据处理请求中携带有对应应用的信息以及对应显示设备的标识；所述每个显示设备具有分别对应的存储区域，所述每个显示设备分别对应的存储区域相独立，且所述每个显示设备的标识与存储区域之间存在映射关系；

所述为所述每个显示设备分别独立的处理对应的多媒体数据处理请求包括：

根据所述多媒体数据处理请求中对应显示设备的标识以及所述映射关系确定对应的存储区域；

将所述多媒体数据处理请求中对应应用的信息存储在所述对应的存储区域中；

根据各个独立的存储区域中的应用的信息对对应的多媒体数据处理请求进行处理。

在一些可能的实施方式中，所述存储区域为链表，所述方法还包括：

为所述每个显示设备分别创建对应的链表；

所述每个显示设备的标识与对应存储区域的映射关系具体为所述每个显示设备的标识与对应链表的标识的映射关系；

根据所述多媒体数据处理请求中对应显示设备的标识以及所述映射关系确定对应的存储区域包括：

根据所述多媒体数据处理请求中对应显示设备的标识以及所述映射关系确定目标链表的标识；

将所述多媒体数据处理请求中对应应用的信息存储在所述对应的存储区域中包括：

将所述多媒体数据处理请求中对应应用的信息存储在所述目标链表的标识对应的目标链表中。

在一些可能的实施方式中，所述多个显示设备中包括有第一显示设备，所述第一显示设备上的应用包括第一应用和第二应用；

为所述每个显示设备分别独立的处理对应的多媒体数据处理请求，得到对应的是否播放或录制所述多媒体数据的处理策略，包括：

在所述第一显示设备播放或录制第一应用对应的多媒体数据时，获取第二应用对应的多媒体数据处理请求；

响应于所述第二应用对应的多媒体数据处理请求，根据所述第一应用所属的应用类型和第二应用所属的应用类型确定是否播放或录制所述第一应用对应的多媒体数据的处理策略和所述第二应用对应的多媒体数据的处理策略。

在一些可能的实施方式中，所述处理策略包括以下其中一种或多种：

同时播放所述第一应用对应的多媒体数据和所述第二应用对应的多媒体数据；

继续播放所述第一应用对应的多媒体数据以及不播放所述第二应用对应的多媒体数据；

暂停播放所述第一应用对应的多媒体数据以及播放所述第二应用对应的多媒体数据；

继续录制所述第一应用对应的多媒体数据以及暂停录制所述第二应用对应的多媒体数据；和

暂停录制所述第一应用对应的多媒体数据以及录制所述第二应用对应的多媒体数据。

在一些可能的实施方式中，所述每个显示设备都具有各自对应的多媒体通道；

若所述处理策略为播放或录制所述多媒体数据，则所述根据所述处理策略对所述显示设备进行相应的控制包括：

根据所述每个显示设备与多媒体通道之间的对应关系，控制所述显示设备通过对应的多媒体通道播放或录制所述多媒体数据。

第二方面，本申请实施例还提供了一种显示设备控制装置，所述装置包括：

获取模块，用于获取对车载系统的多个显示设备中每个显示设备上触发的多媒体数据处理请求，所述多媒体数据处理请求用于请求播放或录制多媒体数据；

处理模块，用于为所述每个显示设备分别独立的处理对应的多媒体数据处理请求，得到对应的是否播放或录制所述多媒体数据的处理策略；

控制模块，用于根据所述处理策略对所述显示设备进行相应的控制。

在一些可能的实施方式中，所述多媒体数据处理请求中携带有对应应用的信息以及对应显示设备的标识；所述每个显示设备具有分别对应的存储区域，所述每个显示设备分别对应的存储区域相独立，且所述每个显示设备的标识与存储区域之间存在映射关系；

所述处理模块，包括：

第一确定单元，用于根据所述多媒体数据处理请求中对应显示设备的标识以及所述映射关系确定对应的存储区域；

存储单元，用于将所述多媒体数据处理请求中对应应用的信息存储在所述对应的存储区域中；

处理单元，用于根据各个独立的存储区域中的应用的信息对对应的多媒体数据处理请求进行处理。

在一些可能的实施方式中，所述存储区域为链表，所述装置还包括：

创建模块，用于为所述每个显示设备分别创建对应的链表；所述每个显示设备的标识与对应存储区域的映射关系具体为所述每个显示设备的标识与对应链表的标识的映射关系；

所述第一确定单元，具体用于根据所述多媒体数据处理请求中对应显示设备的标识以及所述映射关系确定目标链表的标识；

所述存储单元，具体用于将所述多媒体数据处理请求中对应应用的信息存储在所述目标链表的标识对应的目标链表中。

在一些可能的实施方式中，所述多个显示设备中包括有第一显示设备，所述第一显示设备上的应用包括第一应用和第二应用；

所述处理模块，包括：

获取单元，用于在所述第一显示设备播放或录制第一应用对应的多媒体数据时，获取第二应用对应的多媒体数据处理请求；

第二确定单元，用于响应于所述第二应用对应的多媒体数据处理请求，根据所述第一应用所属的应用类型和第二应用所属的应用类型确定是否播放或录制所述第一应用对应的多媒体数据的处理策略和所述第二应用对应的多媒体数据的处理策略。

在一些可能的实施方式中，所述处理策略包括以下其中一种或多种：

同时播放所述第一应用对应的多媒体数据和所述第二应用对应的多媒体数据；

继续播放所述第一应用对应的多媒体数据以及不播放所述第二应用对应的多媒体数据；

暂停播放所述第一应用对应的多媒体数据以及播放所述第二应用对应的多媒体数据；

继续录制所述第一应用对应的多媒体数据以及暂停录制所述第二应用对应的多媒体数据；和

暂停录制所述第一应用对应的多媒体数据以及录制所述第二应用对应的多媒体数据。

在一些可能的实施方式中，所述每个显示设备都具有各自对应的多媒体通道；

若所述处理策略为播放或录制所述多媒体数据，则所述控制模块，具体用于根据所述每个显示设备与多媒体通道之间的对应关系，控制所述显示设备通过对应的多媒体通道播放或录制所述多媒体数据。

第三方面，本申请实施例还提供了一种显示设备控制设备，所述设备包括处理器以及存储器：

所述存储器用于存储程序代码，并将所述程序代码传输给所述处理器；

所述处理器用于根据所述程序代码中的指令执行上述第一方面中任一种实施方式所述的方法。

第四方面，本申请实施例还提供了一种存储介质，所述存储介质用于存储程序代码，所述程序代码用于执行上述第一方面中任一种实施方式所述的方法。

在本申请实施例的上述实现方式中，处理芯片可以获取对车载系统的多个显示设备中每个显示设备上触发的多媒体数据处理请求，该多媒体数据处理请求用于请求播放或录制多媒体数据；然后，处理芯片可以为每个显示设备分别独立的处理对应的多媒体处理请求，得到对应的是否播放或录制该多媒体数据的处理策略，从而处理芯片可以根据该处理策略对显示设备进行相应的控制。可见，单个处理芯片能够对多个显示设备上的应用的多媒体数据处理请求，分别独立的进行处理，从而可以利用一个处理芯片实现对多个显示设备播放或录制多媒体数据进行控制，这相对于为每个显示设备均配备专门的处理芯片的方案而言，所需配备的处理芯片数量得以减少，从而可以有效降低硬件成本。

附图说明

为了更清楚地说明本申请实施例中的技术方案，下面将对实施例描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本申请中记载的一些实施例，对于本领域普通技术人员来讲，还可以根据这些附图获得其他的附图。

图1为本申请实施例中一示例性应用场景示意图；

图2为本申请实施例中一种显示设备控制方法的流程示意图；

图3为本申请实施例中又一种显示设备控制方法的流程示意图；

图4为音频播放焦点链表以及音频录制焦点链表示意图；

图5为一示例性抢占音频播放资源的二维表；

图6为另一示例性抢占音频播放资源二维表；

图7为一示例性为音频录制优先级二维表；

图8为本申请实施例中一种显示设备控制装置的结构示意图；

图9为本申请实施例中一种显示设备控制设备的硬件结构示意图。

具体实施方式

在车载多屏互联系统中，由于每个屏幕都需要为其配备专门的处理芯片，以支持和响应该屏幕的音频播放以及其它处理等，这使得在实现车载多屏互联系统时需要配备多个处理芯片，硬件成本较高。

基于此，本申请实施例提供了一种可以应用于处理芯片上的显示设备控制方法，以实现利用一个处理芯片来控制多个显示设备播放或录制多媒体数据(包括音频数据等)，从而降低硬件成本。具体的，处理芯片可以获取对车载系统的多个显示设备中每个显示设备上触发的多媒体数据处理请求，该多媒体数据处理请求用于请求播放或录制多媒体数据；然后，处理芯片可以为每个显示设备分别独立的处理对应的多媒体处理请求，得到对应的是否播放或录制该多媒体数据的处理策略，从而处理芯片可以根据该处理策略对显示设备进行相应的控制。可见，单个处理芯片能够对多个显示设备上的应用的多媒体数据处理请求，分别独立的进行处理，从而可以利用一个处理芯片实现对多个显示设备播放或录制多媒体数据进行控制，这相对于为每个显示设备均配备专门的处理芯片的方案而言，所需配备的处理芯片数量得以减少，从而可以有效降低硬件成本。

作为一种示例，本申请实施例可以应用于如图1所示的示例性应用场景。在该场景中，车辆100上可以在中控台处安装有屏幕101，在车辆前座靠枕背面安装有屏幕102，并且，屏幕101以及屏幕102的音频播放过程均是由SoC103进行控制。在用户打开屏幕101以及屏幕102上音频播放软件并触发音频数据的播放时，SoC103能够获取到对屏幕101上音频播放软件触发的第一音频播放请求以及对屏幕102上应用触发的第二音频播放请求，其中，第一音频播放请求用于请求播放第一音频，第二音频播放请求用于请求播放第二音频；然后，SoC103可以为屏幕101以及屏幕102分别独立的处理第一音频播放请求以及第二音频播放请求，得到对应的是否播放第一音频的第一处理策略以及是否播放第二音频的第二处理策略，从而SoC103可以根据第一处理策略控制屏幕101播放第一音频或者禁止播放第一音频，根据第二处理策略控制屏幕102播放第二音频或者禁止播放第二音频，从而可以实现仅利用单个SoC103即可控制屏幕101以及屏幕102这两个屏幕的音频播放控制。

可以理解的是，上述场景仅是本申请实施例提供的一个场景示例，本申请实施例并不限于此场景。比如，在其它可能的应用场景中，车载多屏互联系统还可以包括安装于车内后视镜处的屏幕，并且，SoC103可以对该屏幕的音频播放进行相应的控制；又比如，其它可能的应用场景中，用户在屏幕101以及屏幕102上所打开的应用为录音软件，由SoC103控制屏幕101以及屏幕102的录音过程等。总之，本申请实施例可以应用于任何可适用的应用场景中，而不局限于上述场景示例。

为使本申请的上述目的、特征和优点能够更加明显易懂，下面将结合附图对本申请实施例中的各种非限定性实施方式进行示例性说明。显然，所描述的实施例是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其它实施例，都属于本申请保护的范围。

参阅图2，图2示出了本申请实施例中一种显示设备控制方法的流程示意图，该方法具体可以包括：

S201：获取对车载系统的多个显示设备中每个显示设备上触发的多媒体数据处理请求，其中，该多媒体数据处理请求用于请求播放或录制多媒体数据。

本实施例中，可以为车载系统的多个显示设备仅配备一个处理芯片，并利用该单个处理芯片来支持多个显示设备播放或录制多媒体数据，以实现硬件成本的降低。其中，显示设备播放的多媒体数据，具体可以是显示设备所播放的视频、音频、图像以及文档等数据，而显示设备所录制的多媒体数据，具体可以是音频数据或者视频数据等。

基于此，当用户(可以是一个用户，也可以是多个不同的用户)在多个显示设备上触发该显示设备上的应用播放或者录制多媒体数据时，该显示设备上的应用可以基于用户的触发操作，生成相应的多媒体数据处理请求。当然，在其它可能的实施方式中，也可以是配备于显示设备的控制器等生成相应的多媒体数据处理请求等。这样，处理芯片可以获取到来自多个显示设备的多媒体数据处理请求。可以理解，当用户在显示设备上触发应用进行多媒体数据的播放时，该显示设备上所生成的多媒体数据处理请求，可以用于向处理芯片请求播放多媒体数据；类似的，当用户在显示设备上触发应用录制多媒体数据时，该显示设备上所生成的多媒体数据处理请求，可以用于向处理芯片请求录制多媒体数据。

S202：为每个显示设备分别独立的处理对应的多媒体数据处理请求，得到对应的是否播放或者录制多媒体数据的处理策略。

需要说明的是，单个处理芯片在接收到来自多个显示设备上的应用发送的多媒体数据处理请求时，处理芯片会为每个显示设备分别独立的处理相应的多媒体数据处理请求，即处理芯片在为第一显示设备处理第一显示设备上的应用发送的多媒体数据处理请求的过程，并不影响处理芯片在为第二显示设备处理第二显示设备上的应用发送的多媒体数据处理请求的过程。

在一种示例性的具体实施方式中，处理芯片所获取到的多媒体数据处理请求中，可以携带有发送该多媒体数据处理请求的应用的相关信息以及该应用所在显示设备的标识。这样，处理芯片在获取到该多媒体数据处理请求后，可以从该多媒体数据处理请求中解析出显示设备的标识，从而可以确定发送该多媒体数据处理请求的应用位于哪个显示设备，或者说确定该多媒体数据处理请求来源于哪个显示设备；然后，处理芯片可以根据预先存储的每个显示设备的标识与对应存储区域的映射关系，确定该多媒体数据处理请求中所携带的显示设备的标识所对应的存储区域，其中，处理芯片上可以包括每个显示设备对应的存储区域，并且各个显示设备分别对应的存储区域相对独立；接着，处理芯片可以将从多媒体数据处理请求中解析出来的应用的相关信息存储在所确定出的存储区域中(也即为存储在该显示设备的标识所对应的存储区域中)，这样，处理芯片可以根据各个独立的存储区域中的应用的相关信息对相应的多媒体数据处理请求进行处理。

举例来说，处理芯片上可以预先创建针对于多个显示设备的存储容器，该存储容器中可以包含每个显示设备所对应的链表(也即为上述每个显示设备对应的存储区域)。处理芯片在接收到显示设备上的应用发送的音频播放请求后，可以从该音频播放请求中解析出该显示设备的标识，从而根据预先存储的每个显示设备的标识与链表标识的对应关系，确定从以你怕你播放请求中所解析出的显示设备的标识确定出目标链表的标识，进而可以根据该目标链表的标识可以确定出存储容器中该显示设备所对应的目标链表；并且，处理芯片还可以从音频播放请求中解析出该应用的相关信息(如音频播放焦点以及该应用的标识或者类型标识等)，并将该应用的相关信息存储于目标链表中。这样，处理芯片可以根据该目标链表中存储的应用相关信息对该音频播放请求进行处理，确定是否通过显示设备播放相应的音频。其中，不同显示设备对应于存储容器中不同的链表。

当然，实际应用中，每个显示设备所对应的存储容器中所包含的除了是链表以外，也可以是数组等其它数据存储方式，在此并不限定。

在进一步的实施方式中，处理芯片在处理多媒体数据处理请求的过程中，若该显示设备上存在至少两个需要播放或者录制多媒体数据的应用，则可以根据这两个应用所属的应用类型来响应该多媒体数据处理请求。具体实现时，以处理芯片处理多个显示设备中的第一显示设备上的应用发送的多媒体数据处理请求为例，假设该第一显示设备上包括第一应用以及第二应用，并且，在第一显示设备当前正在播放或者录制第一应用对应的多媒体数据时，处理芯片获取到该第一显示设备上第二应用发送的多媒体数据处理请求。则，处理芯片响应于该第二应用对应的多媒体数据处理请求，可以确定第一应用以及第二应用所属的应用类型，并根据第一应用所属的应用类型以及第二应用所属的应用类型，得到是否播放或录制该第一应用对应的多媒体数据的处理策略以及是否播放或录制第二应用对应的多媒体数据的处理策略。

例如，处理芯片在获取到音乐播放软件(第一应用)所属的应用类型以及语音通信软件(第二应用)所属的应用类型后，可以确定该语音通信软件的应用类型的优先级高于音乐播放软件所属的应用类型的优先级，则针对于该语音通信软件的处理策略即为播放语音通信软件对应的音频数据，而针对于该音乐播放软件的处理策略即为停止播放音乐播放软件对应的音频数据，从而处理芯片可以对显示设备上各个应用之间的音频播放顺序进行有序管理。

上述举例中，是针对于第一应用以及第二应用的处理策略进行一种示例性说明，即播放其中一个应用的音频并停止播放另一个应用对应的音频。而在其它示例中，针对于第一应用以及第二应用的处理策略还可以是以下几种策略：

1、同时播放第一应用对应的多媒体数据以及第二应用对应的多媒体数据。

2、继续播放第一应用对应的多媒体数据以及不播放第二应用对应的多媒体数据。

3、暂停播放第一应用对应的多媒体数据以及播放第二应用对应的多媒体数据。

4、继续录制第一应用对应的多媒体数据以及暂停录制第二应用对应的多媒体数据。

5、暂停录制第一应用对应的多媒体数据以及录制第二应用对应的多媒体数据。

需要说明的是，上述示例中，针对于第一应用对应的多媒体数据的处理可以与针对于第二应用对应的多媒体数据的处理相同，而在另一些可能的实施方式中，针对于第一应用对应的多媒体数据的处理也可以与针对于第二应用对应的多媒体数据的处理不同。即，在第一应用当前播放多媒体数据时，第二应用也可以向处理芯片请求播放第二应用对应的多媒体数据，即第一应用与第二应用对应的多媒体数据的处理过程相同；同时，第一应用当前在播放多媒体数据时，第二应用也可以向处理芯片请求录制第二应用对应的多媒体数据，或者第一应用当前在录制多媒体数据时，第二应用也可以向处理芯片请求播放第二应用对应的多媒体数据。

相应的，当针对于第一应用对应的多媒体数据的处理与针对于第二应用对应的多媒体数据的处理不同时，针对于第一应用以及第二应用的处理策略还可以是以下几种策略：

1、继续播放第一应用对应的多媒体数据以及录制第二应用对应的多媒体数据。比如，在一些应用场景中，第一应用对应的多媒体数据是播放至用户的耳机中，从而不会影响该显示设备对第二应用对应的多媒体数据的录制。

2、继续播放第一应用对应的多媒体数据以及不录制第二应用对应的多媒体数据。

3、暂停播放第一应用对应的多媒体数据以及继续录制第二应用对应的多媒体数据。

4、继续录制第一应用对应的多媒体数据以及播放第二对应的多媒体数据。

5、继续录制第一应用对应的多媒体数据以及不播放第二对应的多媒体数据。

6、暂停录制第一应用对应的多媒体数据以及播放第二应用对应的多媒体数据。

实际应用中，针对于每个显示设备上的应用，处理芯片可以基于上述处理策略来处理该显示设备上应用发送的多媒体数据处理请求，即每个显示设备所对应的处理策略相同。而在另一些实施方式中，不同显示设备所对应的处理策略可以存在差异，比如，对于第一显示设备上的两个应用，可以支持播放其中一个应用对应的多媒体数据的同时，还可以播放另一个应用对应的多媒体数据，而对于第二显示设备上的两个应用，可以不支持两个应用各自对应的多媒体数据的同时播放，即当其中一个应用对应的多媒体数据播放时，另一应用对应的多媒体数据可以暂停播放或者终止播放。

进一步的，当第一显示设备上的第一应用与第二应用均为播放多媒体数据的应用，或者均为录制多媒体数据的应用时，该用于播放多媒体数据的应用(包括第一应用以及第二应用)至少可以包括音乐、电话、导航以及语音这四种应用类型中的一种，而用于录制多媒体数据的应用(包括第一应用以及第二应用)至少可以包括普通录音、语音唤醒录音和电话录音。其中，语音唤醒录音，具体可以是指通过语音输入的方式唤醒应用或者系统。

S203：根据该处理策略对显示设备进行相应的控制。

处理芯片在处理获取到的多媒体数据处理请求后，可以得到对应的是否播放或者录制多媒体数据的处理策略，从而处理芯片可以基于该处理策略对显示设备进行相应的控制。具体的，当处理策略表征为播放多媒体数据时，处理芯片可以向发送该多媒体数据处理请求的应用所在显示设备传输多媒体数据，以便该显示设备播放接收到的多媒体数据；当处理策略表征为播放多媒体数据时，处理芯片可以向该显示设备发送针对于多媒体数据的录制指令，以便该显示设备可以开始录制多媒体数据。当然，当处理策略表针为不播放多媒体数据或者不录制多媒体数据时，处理芯片可以通知该显示设备或者该显示设备的相应应用拒绝播放或者录制多媒体数据。

实际应用中，每个显示设备可以具有其对应的多媒体通道，不同显示设备所对应的多媒体通道可以不同，因此，处理芯片若确定处理策略为显示设备需要播放或者录制多媒体数据时，可以根据每个显示设备与多媒体通道之间的对应关系，从多个显示设备对应的多媒体通道中确定出该需要播放或者录制多媒体数据的显示设备所对应的多媒体通道，然后，处理芯片可以控制该显示设备通过相应的多媒体通道播放或者录制多媒体数据。

本实施例中，旨在利用一个处理芯片来控制多个显示设备播放或录制多媒体数据(包括音频数据等)，从而降低硬件成本。具体的，处理芯片可以获取对车载系统的多个显示设备中每个显示设备上触发的多媒体数据处理请求，该多媒体数据处理请求用于请求播放或录制多媒体数据；然后，处理芯片可以为每个显示设备分别独立的处理对应的多媒体处理请求，得到对应的是否播放或录制该多媒体数据的处理策略，从而处理芯片可以根据该处理策略对显示设备进行相应的控制。可见，单个处理芯片能够对多个显示设备上的应用的多媒体数据处理请求，分别独立的进行处理，从而可以利用一个处理芯片实现对多个显示设备播放或录制多媒体数据进行控制，这相对于为每个显示设备均配备专门的处理芯片的方案而言，所需配备的处理芯片数量得以减少，从而可以有效降低硬件成本。

为了便于理解本申请实施例的技术方案，下面将结合具体应用场景对本申请实施例的技术方案进行详细介绍。参阅图3，图3示出了本申请实施例中又一种显示设备控制方法的流程示意图。在该场景实施例中，车辆上可以配置有车载多屏互联系统，并且，该车载多屏互联系统可以包括安装在中控台处的主控屏、安装在车辆前座靠枕背面的头枕屏以及单个SoC，该SoC可以对主控屏以及头枕屏的音频播放或录音进行控制。具体的，该方法可以应用于SoC，具体可以包括：

S301：SoC在自身的存储区域创建音频播放焦点容器以及音频录制焦点容器，其中，该音频播放焦点容器包括主控屏对应的音频播放焦点链表以及头枕屏对应的音频播放焦点链表，该音频录制焦点容器包括主控屏对应的音频录制焦点链表以及头枕屏对应的音频录制焦点链表。

本实施例中，可以预先为主控屏以及头枕屏分别创建对应的音频播放焦点链表以及音频录制焦点链表，如图4所示。其中，该音频播放焦点链表可以存储音频播放焦点，音频录制焦点可以存储音频录制焦点，并且，主控屏与头枕屏所对应的音频播放焦点链表之间相互独立，同时，主控屏与头枕屏所对应的音频录制焦点链表之间也相互独立。实际应用中，各个屏幕对应的音频播放焦点链表以及音频录制焦点链表可以对应于该屏幕的标识(如，屏幕的产品序列号、类型标识等)。

通常情况下，对于具有音频播放焦点的应用，可以播放音频，而不具有音频播放焦点的应用，可以暂停或者禁止播放音频；类似的，对于具有音频录制焦点的应用，可以录制音频，而不具有音频录制焦点的应用，不具有录制音频的权限。以主控屏为例，当主控屏上的应用成功申请到音频播放焦点或者音频录制焦点后，可以在该主控屏所对应的音频播放焦点链表中添加相应的音频播放焦点或者在音频录制焦点链表中添加相应的音频录制焦点，以便后续查询。

S302：SoC获取主控屏上导航应用发送的音频播放请求以及头枕屏上电话录制应用发送的音频录制请求，该音频播放请求用于向SoC请求播放导航音频，音频录制请求用于向SoC请求录制电话音频。

S303：针对于主控屏，SoC通过解析音频播放请求，可以根据导航应用所属的应用类型以及该主控屏上当前播放音频的应用所属的应用类型确定是否播放导航音频的处理策略；针对于头枕屏，SoC通过音频录制请求，可以根据电话录制应用所属的应用类型以及该头枕屏上当前录制音频的应用所属的应用类型确定是否录制电话音频。

本实施例中，SoC可以根据获取到的音频播放请求确定导航应用所在屏幕为主控屏，并检测该主控屏上当前是否存在其它应用正在播放音频，若存在，则SoC可以确定出导航应用所属的应用类型以及当前播放音频的应用所属的应用类型，并根据预先建立的音频播放优先级二维表，确定是否播放导航音频以及确定是否继续播放当前正在播放的音频。

作为一种示例，该音频播放优先级二维表可以包括抢占音频播放资源的二维表以及音频混音二维表。具体的，图5示出了一示例性抢占音频播放资源的二维表，播放音频的应用所属的应用类型可以包括“音乐”、“电话”、“导航”以及“语音”四种。其中，如图5中所示的“可抢占焦点并可打断当前应用”，是指申请播放音频的应用可以播放音频而当前正在播放音频的应用暂停播放音频，“不可抢占并不可打断当前应用”，是指申请播放音频的应用不可以播放音频而当前正在播放音频的应用可以继续播放音频。图6示出了一示例性音频混音二维表，图6中所示的“可与当前播放音频应用混音”，是指申请播放音频的应用可以与当前正在播放音频的应用同时播放音频，“不可与当前播放音频应用混音”，是指申请播放音频的应用不能与当前正在播放音频的应用同时播放音频。

SoC在确定出导航应用所属的应用类型以及当前播放音频的应用所属的应用类型后，可以通过查找音频播放优先级二维表确定是否播放导航音频以及确定是否继续播放当前正在播放的音频。具体的，根据图5所示的抢占音频播放资源二维表可以确定当前不允许主控屏播放导航音频，而当前正在播放音频的应用可以继续播放音频；而根据图6所示的音频混音二维表可以确定，若当前正在播放音频的应用所属的应用类型为音乐时，则可以确定导航应用可以与当前正在播放音频的应用同时播放音频，而若当前正在播放音频的应用所属的应用类型为电话、导航或者语音时，则可以确定该导航应用不能与当前正在播放音频的应用同时播放音频。在进一步可能的实施方式中，主控屏上应用在向SoC发送音频播放请求时，可以在该音频播放请求中携带抢占音频播放资源的标识或者音频混音的标识，从而SoC可以根据该音频播放请求中所携带的抢占音频播放资源的标识或者音频混音的标识，选择相应的抢占音频播放资源二维表或者音频混音二维表确定是否允许该申请播放音频的应用是否能够播放音频。

实际应用中，可以将图5所示的抢占音频播放资源二维表以及图6所示的音频混音二维表，转换成相应的配置文件，SoC基于该配置文件生成对应的二维数组模型。作为一种示例，可以利用二维数组A[M][M]＝{{1，1，0，1}，{0，0，0，0}，{1，1，0，1}，{0，1，0，1}}来表示图5所示的抢占音频播放资源二维表，二维数组中的M表征播放音频的应用所属的应用类型总数(在本示例中M的值为4)。其中，图5中所示的“可抢占焦点并可打断当前应用”可以用数字“1”表示，“不可抢占焦点并不可打断当前应用”可以利用数字“0”表示。而该二维数组中不同的列可以代表当前应用所属的不同应用类型，具体的，第一列表征当前应用所属的应用类型为音乐、第二列表征当前应用所属的应用类型为电话等；该二维数组中不同的行可以代表申请播放音频的应用所属的不同应用类型，具体的，第一行表征申请播放音频的应用所属的应用类型为音乐、第二行表征申请播放音频的应用所属的应用类型为电话等。而对于音频混音二维表，可以利用二维数组B[M][M]＝{{1，1，0，1}，{0，0，0，0}，{1，1，0，1}，{0，1，0，1}}来表示图6所示的抢占音频播放资源二维表，同样，二维数组中的M表征录制音频的应用所属的应用类型总数(在本示例中M的值为4)。其中，图6中所示的“可与当前播放音频应用混音”可以用数字“1”表示，“不可与当前播放音频应用混音”可以利用数字“0”表示。而该二维数组中不同的列可以代表当前应用所属的不同应用类型，具体的，第一列表征当前应用所属的应用类型为音乐、第二列表征当前应用所属的应用类型为电话等；该二维数组中不同的行可以代表申请播放音频的应用所属的不同应用类型，具体的，第一行表征申请播放音频的应用所属的应用类型为音乐、第二行表征申请播放音频的应用所属的应用类型为电话等。

类似的，SoC可以根据获取到的音频录制请求确定电话录制应用所在屏幕为头枕屏，并检测该头枕屏上当前是否存在其它应用正在录制音频，若存在，则SoC可以确定出电话录制应用所属的应用类型以及当前录制音频的应用所属的应用类型，并根据预先建立的音频录制优先级二维表，确定是否录制电话音频以及确定是否继续录制当前正在录制的音频。

作为一种示例，该音频录制优先级二维表具体可以是图7所示的示例性音频录制优先级二维表，录制音频的应用所属的应用类型可以包括“普通录音”、“语音唤醒录音”以及“电话录音”三种。其中，如图7中所示的“可抢占焦点并可打断当前应用”，是指申请录制音频的应用可以录制音频而当前正在录制音频的应用暂停录制音频，“不可抢占并不可打断当前应用”，是指申请录制音频的应用不可以录制音频而当前正在录制音频的应用可以继续录制音频。

SoC在确定出电话录制应用所属的应用类型以及当前录制音频的应用所属的应用类型后，可以通过查找音频录制优先级二维表确定是否录制电话音频以及确定是否继续录制当前正在录制的音频。具体的，根据图7所示的音频录制优先级二维表可以确定，若当前正在录制音频的应用所属的应用类型为普通录音或者语音唤醒录音时，则定电话录制应用可以录制电话音频而暂停当前正在录制音频的应用进行音频录制，而若当前正在录制音频的应用所属的应用类型为电话录音时，则确定该电话录制应用不能与当前正在录制音频的应用同时录制音频。

实际应用中，可以将图7所示的音频录制优先级二维表，转换成相应的配置文件，SoC基于该配置文件生成对应的二维数组模型。作为一种示例，可以利用二维数组C[N][N]＝{{1，1，1}，{1，1，1}，{0，0，0}}来表示图7所示的音频录制优先级二维表，二维数组中的N表征录制音频的应用所属的应用类型总数(在本示例中N的值为3)。其中，图7中所示的“可抢占焦点并可打断当前应用”可以用数字“1”表示，“不可抢占焦点并不可打断当前应用”可以利用数字“0”表示。而该二维数组中不同的列可以代表当前应用所属的不同应用类型，具体的，第一列表征当前应用所属的应用类型为普通录音，第二列表征当前应用所属的应用类型为语音唤醒录音等；该二维数组中不同的行可以代表申请录制音频的应用所属的不同应用类型，具体的，第一行表征申请录制音频的应用所属的应用类型为普通录音、第二行表征申请录制音频的应用所属的应用类型为语音唤醒录音等。

需要说明的是，主控屏与头枕屏可以对应于相同的音频播放优先级二维表以及音频录制优先级二维表，也可以根据自身的实际需求进行特殊化定制，即主控屏与头枕屏可以对应于不同的音频播放优先级二维表以及音频录制优先级二维表，比如，在主控屏上导航应用可以抢占音乐播放应用的音频播放焦点，而在头枕屏上导航应用不可以抢占音乐播放应用的音频播放焦点等。

S304：SoC根据是否播放导航音频的处理策略，更新主控屏对应的音频播放焦点链表，根据是否录制电话音频的处理策略，更新头枕屏对应的音频录制焦点链表。

本实施例中，SoC可以预先建立并存储主控屏的标识与音频播放焦点链表之间的映射关系。这样，SoC在基于音频播放请求确定出导航应用位于主控屏后，可以根据该主控屏的标识与音频播放焦点链表之间的对应关系，确定出主控屏对应的音频播放焦点链表，并根据是否播放导航音频的处理策略，对音频播放焦点链表进行更新。即，可以为允许播放音频的应用添加或者保留音频播放焦点，而为暂停播放或者不允许播放音频的应用删除已添加的音频播放焦点或者不添加音频播放焦点。例如，若该处理策略表征播放导航音频而当前正在播放音频的应用暂停播放音频，则可以向主控屏对应的音频播放焦点链表中添加音频播放焦点，进一步的，还可以在添加音频播放焦点的同时，添加导航应用的标识，并且，删除主控屏对应的音频播放焦点链表中之前已为当前正在播放音频的应用所添加的音频播放焦点。

类似的，SoC可以预先建立并存储头枕屏的标识与音频录制焦点链表之间的映射关系。这样，SoC在基于音频录制请求确定出电话录制应用位于头枕屏后，可以根据该头枕屏的标识与音频录制焦点链表之间的对应关系，确定出头枕屏对应的音频录制焦点链表，并根据是否录制电话音频的处理策略，对音频录制焦点链表进行更新。即，可以为允许录制音频的应用添加或者保留音频录制焦点，而为暂停录制或者不允许录制音频的应用删除已添加的音频录制焦点或者不添加音频录制焦点。例如，若该处理策略表征录制电话音频而当前正在录制音频的应用暂停录制音频，则可以向头枕屏对应的音频录制焦点链表中添加音频录制焦点，进一步的，还可以在添加音频录制焦点的同时，添加电话录制应用的标识，并且，删除头枕屏对应的音频录制焦点链表中之前已为当前正在录制音频的应用所添加的音频录制焦点。

S305：SoC在确定播放导航音频时，根据主控屏与多媒体通道之间的对应关系，控制主控屏通过主控屏对应的多媒体通道播放导航音频，并且，SoC在确定录制电话音频时，根据头枕屏与多媒体通道之间的对应关系，控制头枕屏通过头枕屏对应的多媒体通道录制电话音频。

本实施例中，主控屏与头枕屏均具有各自对应的多媒体通道，并可以利用各自对应的多媒体通道进行音频的播放或录制。

在一种播放导航音频的示例性具体实施方式中，针对于主控屏，SoC在确定主控屏需要播放导航音频时，可以根据预先建立的主控屏与多媒体通道之间的对应关系，确定主控屏所对应的多媒体通道。实际应用中，主控屏所对应的多媒体通道可以是多个通道，因此，SoC可以确定出主控屏所对应的多媒体通道列表。然后，SoC可以从多媒体通道列表中选择与导航应用所匹配的唯一通道来播放导航音频。

在一种录制电话音频的示例性具体实施方式中，针对于头枕屏，SoC在确定头枕屏需要录制电话音频时，可以根据预先建立的头枕屏与多媒体通道之间的对应关系，确定出头枕屏所对应的多媒体通道。实际应用中，SoC可以确定出头枕屏所对应的多媒体通道列表，然后，SoC可以从多媒体通道列表中选择与电话录制应用所匹配的唯一通道来录制电话音频。

可见，本实施例中单个SoC能够对主控屏上应用发送的音频播放请求以及头枕屏上应用发送的音频录制请求，分别独立的进行处理，从而可以利用一个SoC实现对两个屏幕播放或录制音频数据进行控制，这相对于为每个屏幕均配备专门的SoC的方案而言，所需配备的SoC数量得以减少，从而可以有效降低硬件成本。

此外，本申请实施例还提供了一种显示设备控制装置，参阅图8，图8示出了本申请实施例中一种现实设备控制装置的结构示意图，该装置800包括：

获取模块801，用于获取对车载系统的多个显示设备中每个显示设备上触发的多媒体数据处理请求，所述多媒体数据处理请求用于请求播放或录制多媒体数据；

处理模块802，用于为所述每个显示设备分别独立的处理对应的多媒体数据处理请求，得到对应的是否播放或录制所述多媒体数据的处理策略；

控制模块803，用于根据所述处理策略对所述显示设备进行相应的控制。

在一些可能的实施方式中，所述多媒体数据处理请求中携带有对应应用的信息以及对应显示设备的标识；所述每个显示设备具有分别对应的存储区域，所述每个显示设备分别对应的存储区域相独立，且所述每个显示设备的标识与存储区域之间存在映射关系；

所述处理模块802，包括：

第一确定单元，用于根据所述多媒体数据处理请求中对应显示设备的标识以及所述映射关系确定对应的存储区域；

存储单元，用于将所述多媒体数据处理请求中对应应用的信息存储在所述对应的存储区域中；

处理单元，用于根据各个独立的存储区域中的应用的信息对对应的多媒体数据处理请求进行处理。

在一些可能的实施方式中，所述存储区域为链表，所述装置800还包括：

创建模块，用于为所述每个显示设备分别创建对应的链表；所述每个显示设备的标识与对应存储区域的映射关系具体为所述每个显示设备的标识与对应链表的标识的映射关系；

所述第一确定单元，具体用于根据所述多媒体数据处理请求中对应显示设备的标识以及所述映射关系确定目标链表的标识；

所述存储单元，具体用于将所述多媒体数据处理请求中对应应用的信息存储在所述目标链表的标识对应的目标链表中。

在一些可能的实施方式中，所述多个显示设备中包括有第一显示设备，所述第一显示设备上的应用包括第一应用和第二应用；

所述处理模块802，包括：

获取单元，用于在所述第一显示设备播放或录制第一应用对应的多媒体数据时，获取第二应用对应的多媒体数据处理请求；

第二确定单元，用于响应于所述第二应用对应的多媒体数据处理请求，根据所述第一应用所属的应用类型和第二应用所属的应用类型确定是否播放或录制所述第一应用对应的多媒体数据的处理策略和所述第二应用对应的多媒体数据的处理策略。

在一些可能的实施方式中，所述处理策略包括以下其中一种或多种：

同时播放所述第一应用对应的多媒体数据和所述第二应用对应的多媒体数据；

继续播放所述第一应用对应的多媒体数据以及不播放所述第二应用对应的多媒体数据；

暂停播放所述第一应用对应的多媒体数据以及播放所述第二应用对应的多媒体数据；

继续录制所述第一应用对应的多媒体数据以及暂停录制所述第二应用对应的多媒体数据；和

暂停录制所述第一应用对应的多媒体数据以及录制所述第二应用对应的多媒体数据。

在一些可能的实施方式中，所述每个显示设备都具有各自对应的多媒体通道；

若所述处理策略为播放或录制所述多媒体数据，则所述控制模块803，具体用于根据所述每个显示设备与多媒体通道之间的对应关系，控制所述显示设备通过对应的多媒体通道播放或录制所述多媒体数据。

值得注意的是，本实施例所述的显示设备控制装置，对应于上述方法实施例中所述的显示设备控制方法，本实施例中的各模块、单元的具体实施方式，可参见前述方法实施例中的相关之处描述即可，在此不做赘述。

本实施例中，由于单个处理芯片能够对多个显示设备上的应用的多媒体数据处理请求，分别独立的进行处理，从而可以利用一个处理芯片实现对多个显示设备播放或录制多媒体数据进行控制，这相对于为每个显示设备均配备专门的处理芯片的方案而言，所需配备的处理芯片数量得以减少，从而可以有效降低硬件成本。

另外，本申请实施例还提供了一种显示设备控制设备。参阅图9，于9示出了本申请实施例中一种显示设备控制设备的硬件结构示意图，该设备900包括处理器901以及存储器902：

所述存储器902用于存储程序代码，并将所述程序代码传输给所述处理器901；

所述处理器901用于根据所述程序代码中的指令执行上述方法实施例中所述的显示设备控制方法。

第四方面，本申请实施例还提供了一种存储介质，所述存储介质用于存储程序代码，所述程序代码用于执行上述方法实施例中所述的显示设备控制方法。

本申请实施例中提到的“第一应用”、“第一显示设备”、“第一确定单元”等名称中的“第一”只是用来做名字标识，并不代表顺序上的第一。该规则同样适用于“第二”等。

通过以上的实施方式的描述可知，本领域的技术人员可以清楚地了解到上述实施例方法中的全部或部分步骤可借助软件加通用硬件平台的方式来实现。基于这样的理解，本申请的技术方案可以以软件产品的形式体现出来，该计算机软件产品可以存储在存储介质中，如只读存储器(英文：read-only memory，ROM)/RAM、磁碟、光盘等，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者诸如路由器等网络通信设备)执行本申请各个实施例或者实施例的某些部分所述的方法。

本说明书中的各个实施例均采用递进的方式描述，各个实施例之间相同相似的部分互相参见即可，每个实施例重点说明的都是与其他实施例的不同之处。尤其，对于装置实施例而言，由于其基本相似于方法实施例，所以描述得比较简单，相关之处参见方法实施例的部分说明即可。以上所描述的装置实施例仅仅是示意性的，其中作为分离部件说明的模块可以是或者也可以不是物理上分开的，作为模块显示的部件可以是或者也可以不是物理模块，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部模块来实现本实施例方案的目的。本领域普通技术人员在不付出创造性劳动的情况下，即可以理解并实施。

以上所述仅是本申请示例性的实施方式，并非用于限定本申请的保护范围。

Claims (9)

1.一种显示设备控制方法，其特征在于，包括：

获取对车载系统的多个显示设备中每个显示设备上触发的多媒体数据处理请求，所述多媒体数据处理请求用于请求播放或录制多媒体数据；

为所述每个显示设备分别独立的处理对应的多媒体数据处理请求，得到对应的是否播放或录制所述多媒体数据的处理策略；

根据所述处理策略对所述显示设备进行相应的控制；

其中，所述多媒体数据处理请求中携带有对应应用的信息以及对应显示设备的标识；所述每个显示设备具有分别对应的存储区域，所述每个显示设备分别对应的存储区域相独立，且所述每个显示设备的标识与存储区域之间存在映射关系；所述每个显示设备分别对应的存储区域用于存储所述每个显示设备上触发的多媒体数据处理请求中的应用的相关信息；

所述多个显示设备中包括有第一显示设备，所述第一显示设备上的应用包括第一应用和第二应用；

为所述每个显示设备分别独立的处理对应的多媒体数据处理请求，得到对应的是否播放或录制所述多媒体数据的处理策略，包括：

在所述第一显示设备播放或录制第一应用对应的多媒体数据时，获取第二应用对应的多媒体数据处理请求；

响应于所述第二应用对应的多媒体数据处理请求，根据所述第一应用所属的应用类型和第二应用所属的应用类型确定是否播放或录制所述第一应用对应的多媒体数据的处理策略和所述第二应用对应的多媒体数据的处理策略。

2.根据权利要求1所述的方法，其特征在于，所述为所述每个显示设备分别独立的处理对应的多媒体数据处理请求包括：

根据所述多媒体数据处理请求中对应显示设备的标识以及所述映射关系确定对应的存储区域；

将所述多媒体数据处理请求中对应应用的信息存储在所述对应的存储区域中；

根据各个独立的存储区域中的应用的信息对对应的多媒体数据处理请求进行处理。

3.根据权利要求2所述的方法，其特征在于，所述存储区域为链表，所述方法还包括：

为所述每个显示设备分别创建对应的链表；

所述每个显示设备的标识与对应存储区域的映射关系具体为所述每个显示设备的标识与对应链表的标识的映射关系；

根据所述多媒体数据处理请求中对应显示设备的标识以及所述映射关系确定对应的存储区域包括：

根据所述多媒体数据处理请求中对应显示设备的标识以及所述映射关系确定目标链表的标识；

将所述多媒体数据处理请求中对应应用的信息存储在所述对应的存储区域中包括：

将所述多媒体数据处理请求中对应应用的信息存储在所述目标链表的标识对应的目标链表中。

4.根据权利要求1所述的方法，其特征在于，所述处理策略包括以下其中一种或多种：

同时播放所述第一应用对应的多媒体数据和所述第二应用对应的多媒体数据；

继续播放所述第一应用对应的多媒体数据以及不播放所述第二应用对应的多媒体数据；

暂停播放所述第一应用对应的多媒体数据以及播放所述第二应用对应的多媒体数据；

继续录制所述第一应用对应的多媒体数据以及暂停录制所述第二应用对应的多媒体数据；和

暂停录制所述第一应用对应的多媒体数据以及录制所述第二应用对应的多媒体数据。

5.根据权利要求1所述的方法，其特征在于，所述每个显示设备都具有各自对应的多媒体通道；

若所述处理策略为播放或录制所述多媒体数据，则所述根据所述处理策略对所述显示设备进行相应的控制包括：

根据所述每个显示设备与多媒体通道之间的对应关系，控制所述显示设备通过对应的多媒体通道播放或录制所述多媒体数据。

6.一种显示设备控制装置，其特征在于，所述装置包括：

获取模块，用于获取对车载系统的多个显示设备中每个显示设备上触发的多媒体数据处理请求，所述多媒体数据处理请求用于请求播放或录制多媒体数据；

处理模块，用于为所述每个显示设备分别独立的处理对应的多媒体数据处理请求，得到对应的是否播放或录制所述多媒体数据的处理策略；

控制模块，用于根据所述处理策略对所述显示设备进行相应的控制；

其中，所述多媒体数据处理请求中携带有对应应用的信息以及对应显示设备的标识；所述每个显示设备具有分别对应的存储区域，所述每个显示设备分别对应的存储区域相独立，且所述每个显示设备的标识与存储区域之间存在映射关系；所述每个显示设备分别对应的存储区域用于存储所述每个显示设备上触发的多媒体数据处理请求中的应用的相关信息；

所述多个显示设备中包括有第一显示设备，所述第一显示设备上的应用包括第一应用和第二应用；

所述处理模块，包括：

获取单元，用于在所述第一显示设备播放或录制第一应用对应的多媒体数据时，获取第二应用对应的多媒体数据处理请求；

第二确定单元，用于响应于所述第二应用对应的多媒体数据处理请求，根据所述第一应用所属的应用类型和第二应用所属的应用类型确定是否播放或录制所述第一应用对应的多媒体数据的处理策略和所述第二应用对应的多媒体数据的处理策略。

7.根据权利要求6所述的装置，其特征在于，所述处理模块，包括：

第一确定单元，用于根据所述多媒体数据处理请求中对应显示设备的标识以及所述映射关系确定对应的存储区域；

存储单元，用于将所述多媒体数据处理请求中对应应用的信息存储在所述对应的存储区域中；

处理单元，用于根据各个独立的存储区域中的应用的信息对对应的多媒体数据处理请求进行处理。

8.一种显示设备控制设备，所述设备包括处理器以及存储器：

所述存储器用于存储程序代码，并将所述程序代码传输给所述处理器；

所述处理器用于根据所述程序代码中的指令执行权利要求1至5任一项所述的方法。

9.一种存储介质，所述存储介质用于存储程序代码，所述程序代码用于执行权利要求1至5任一项所述的方法。

Images