氛围灯事件管理方法、装置、设备、存储介质和程序产品

技术领域

本公开实施例涉及设备管理技术领域，特别是涉及一种氛围灯事件管理方法、装置、设备、存储介质和程序产品。

背景技术

随着氛围灯在车辆上越来越普及，氛围灯的使用场景也逐渐丰富，如常见的呼吸律动、音乐律动等。通过在车辆上显示不同的氛围灯，可以便于用户快速感知到车辆当前的状态。

相关技术中，在使用车辆上的氛围灯时，通常是车辆的控制器获取到一个新的氛围灯调用事件之后，若该氛围灯调用事件比较紧急，则会放弃当前执行的氛围灯调用事件，直接执行该新的氛围灯调用事件，并控制车辆的氛围灯按照该新的氛围灯调用事件进行显示，在显示完成之后氛围灯会恢复至初始状态。

然而，上述技术存在对氛围灯事件的管理不够完善的问题。

发明内容

本公开实施例提供一种氛围灯事件管理方法、装置、设备、存储介质和程序产品，可以用于对全部氛围灯事件进行全链路管理，完善氛围灯事件的管理过程。

第一方面，本公开实施例提供一种氛围灯事件管理方法，该方法包括：

获取业务方发起的第一氛围灯调用指令；上述第一氛围灯调用指令中包括业务方所需调用的第一氛围灯事件；

对第一氛围灯事件和当前执行的第二氛围灯事件进行仲裁处理，确定仲裁成功的目标氛围灯事件和仲裁失败的非目标氛围灯事件；

执行目标氛围灯事件，并将非目标氛围灯事件进行缓存；

在目标氛围灯事件执行完毕后，执行非目标氛围灯事件。

第二方面，本公开实施例提供一种氛围灯事件管理装置，该装置包括：

接收模块，用于获取业务方发起的第一氛围灯调用指令；上述第一氛围灯调用指令中包括业务方所需调用的第一氛围灯事件；

仲裁模块，用于对第一氛围灯事件和当前执行的第二氛围灯事件进行仲裁处理，确定仲裁成功的目标氛围灯事件和仲裁失败的非目标氛围灯事件；

缓存模块，用于执行目标氛围灯事件，并将非目标氛围灯事件进行缓存；

管理模块，用于在目标氛围灯事件执行完毕后，执行非目标氛围灯事件。

第三方面，本公开实施例提供一种计算机设备，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，处理器执行计算机程序时实现上述第一方面的方法。

第四方面，本公开实施例提供一种计算机可读存储介质，其上存储有计算机程序，计算机程序被处理器执行时实现上述第一方面的方法。

第五方面，本公开实施例提供一种计算机程序产品，包括计算机程序，该计算机程序被处理器执行时实现上述第一方面的方法。

本公开实施例提供的氛围灯事件管理方法、装置、设备、存储介质和程序产品，通过获取业务方发起的所需调用第一氛围灯事件的第一氛围灯调用指令，对第一氛围灯事件以及当前执行的第二氛围灯事件进行仲裁处理，确定仲裁成功的目标氛围灯事件和仲裁失败的非目标氛围灯事件，然后执行目标氛围灯事件并将非目标氛围灯事件进行缓存，在目标氛围灯事件执行完毕后执行非目标氛围灯事件。该方法中，由于可以对仲裁失败的氛围灯事件进行缓存，并在仲裁成功的氛围灯事件执行完之后继续执行仲裁失败的氛围灯事件，这样可以保证任何业务方发出的氛围灯调用事件在仲裁失败后，氛围灯事件也不会终止，而是在仲裁成功的氛围灯事件执行完后有机会继续执行，从而可以避免丢弃仲裁失败的氛围灯事件，保证对全部氛围灯事件均执行，实现对全部氛围灯事件的全链路管理，完善氛围灯事件的管理过程。

附图说明

图1为一个实施例中计算机设备的内部结构图；

图2为一个实施例中氛围灯事件管理方法的流程示意图；

图3为另一个实施例中氛围灯事件管理方法的流程示意图；

图4为另一个实施例中氛围灯事件管理方法的流程示意图；

图5为另一个实施例中氛围灯事件管理方法的流程示意图；

图6为另一个实施例中缓存氛围灯事件的判断逻辑框图；

图7为另一个实施例中氛围灯事件缓存栈入栈流程框图；

图8为另一个实施例中氛围灯事件管理方法的流程示意图；

图9为另一个实施例中氛围灯事件缓存栈出栈流程框图；

图10为另一个实施例中氛围灯事件管理方法的流程示意图；

图11为另一个实施例中氛围灯控制框图；

图12为一个实施例中氛围灯事件管理装置的结构框图。

具体实施方式

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

首先，在具体介绍本公开实施例的技术方案之前，先对本公开实施例基于的技术背景或者技术演进脉络进行介绍。通常情况下，在车辆管理或车辆上的设备管理领域，当前的技术背景是：在使用车辆上的氛围灯时，通常是车辆的控制器获取到一个新的氛围灯调用事件之后，若该氛围灯调用事件比较紧急，则会放弃当前执行的氛围灯调用事件，直接执行该新的氛围灯调用事件，并控制车辆的氛围灯按照该新的氛围灯调用事件进行显示，在显示完成之后氛围灯会恢复至初始状态。基于该背景，申请人通过长期的模型模拟研发以及实验数据的搜集、演示和验证，发现在执行比较紧急的氛围灯调用事件时放弃当前执行的氛围灯调用事件，这样会导致对全部业务方的氛围灯调用事件的管理不够完善，同时个别业务方的氛围灯调用事件无法执行，这样也可能会引发相应的安全事故。另外，需要说明的是，从确定管理不够完善以及下述实施例介绍的技术方案，申请人均付出了大量的创造性劳动。

下面结合本公开实施例所应用的场景，对本公开实施例涉及的技术方案进行介绍。

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

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

在一个实施例中，如图2所示，提供了一种氛围灯事件管理方法，以该方法应用于图1中的计算机设备为例进行说明，该方法可以包括以下步骤：

S202，获取业务方发起的第一氛围灯调用指令；上述第一氛围灯调用指令中包括业务方所需调用的第一氛围灯事件。

其中，氛围灯事件也可以称为氛围灯调用事件，业务方也可以称为业务调用方，指的是发起氛围调用灯事件的对象，或者可以是需要使用氛围灯的对象，比如业务方可以是计算机设备的上游服务。这里的业务方可以是一个或多个，每个业务方均可以向计算机设备发送氛围灯调用指令。

在业务方需要使用/调用氛围灯时，可以将需要调用的氛围灯事件封装在氛围灯调用指令中发送给计算机设备，这里每个业务方各自所需调用的氛围灯事件均可以记为第一氛围灯事件，其向计算机设备发送的氛围灯指令相应也可以记为第一氛围灯调用指令。

也就是说，对于第一氛围灯调用指令，其中可以包括业务方所需调用的第一氛围灯事件，当然还可以包括其他信息，比如与第一氛围灯事件相关的信息，例如可以包括第一氛围灯事件的事件类型、所需显示的氛围灯的分区信息、所需显示的氛围灯的数量信息、所需要显示的氛围灯的亮度、颜色等信息。

在各业务方各自向计算机设备发送各自的第一氛围灯调用指令之后，计算机设备就可以获取到第一氛围灯调用指令，之后就可以对第一氛围灯调用指令进行解析等处理，获得其中的第一氛围灯事件及其相关信息。这里具体可以是计算机设备中的SOC芯片接收业务方的第一氛围灯调用指令，其中SOC指的是System on Chip，可以称为系统级芯片或片上系统；采用SOC芯片与业务方进行数据交互，可以降低车载终端的体积以及功耗，且可以提高处理效率。

S204，对第一氛围灯事件和当前执行的第二氛围灯事件进行仲裁处理，确定仲裁成功的目标氛围灯事件和仲裁失败的非目标氛围灯事件。

在本步骤中，计算机设备获取到的第一氛围灯事件可以是新的氛围灯事件，计算机设备在获得第一氛围灯事件之后，也可以获得当前执行的氛围灯事件，记为第二氛围灯事件。需要说明的是，一般计算机设备是默认会执行一种氛围灯事件，即会默认使车辆内显示一种氛围灯的，比如按照呼吸律动显示氛围灯；也就是说，计算机设备总是在执行一种氛围灯事件的，因此，在计算机设备获取到业务方发起的新的氛围灯事件之后，就可以对新的氛围灯事件和当前执行的氛围灯事件进行仲裁。

也就是说，这里计算机设备就可以对第一氛围灯事件和第二氛围灯事件进行仲裁，这里的仲裁处理可以是仲裁两个氛围灯事件具体哪个能执行，哪个不能执行；具体仲裁处理时可以是依据预先设定好的仲裁条件进行仲裁处理，这里的仲裁条件例如可以是基于两个氛围灯事件的重要程度，或者也可以是基于两个氛围灯事件的执行时间或执行时长等，或者也可以是基于其他方式，总之可以实现对第一氛围灯事件和第二氛围灯事件进行仲裁处理即可。

在对第一氛围灯事件和第二氛围灯事件进行仲裁处理之后，就可以获得两个氛围灯事件的仲裁结果，其中仲裁结果包括仲裁成功和仲裁失败，仲裁成功的氛围灯事件可以记为目标氛围灯事件，仲裁失败的氛围灯事件可以记为非目标氛围灯事件。这里目标氛围灯事件为第一氛围灯事件和第二氛围灯事件中的一个，非目标氛围灯事件为第一氛围灯事件和第二氛围灯事件中的另一个；即第一氛围灯事件和第二氛围灯事件两者中一个仲裁失败，另一个则仲裁成功。

S206，执行目标氛围灯事件，并将非目标氛围灯事件进行缓存。

在本步骤中，在上述确定出仲裁成功的目标氛围灯事件之后，就可以执行目标氛围灯事件，示例地，假设第二氛围灯事件仲裁成功，第一氛围灯事件仲裁失败，则继续执行第二氛围灯事件；再假设第一氛围灯事件仲裁成功，第二氛围灯事件仲裁失败，则可以停止执行第二氛围灯事件，改为执行第一氛围灯事件。

上述在执行目标氛围灯事件，具体可以是SOC执行目标氛围灯事件，具体执行时，可以是SOC将目标氛围灯事件及其相关信息通过Lin(Local Interconnect Network，局域互连网络)总线下发至MCU(Microcontroller Unit，微控制单元)，由MCU按照目标氛围灯事件的相关信息控制氛围灯进行显示。

进一步地，上述在执行目标氛围灯事件的同时，也可以将仲裁失败的非目标氛围灯事件缓存起来，这里缓存非目标氛围灯事件时，可以是将非目标氛围灯事件缓存在缓存、内存、堆栈等存储空间中。

S208，在目标氛围灯事件执行完毕后，执行非目标氛围灯事件。

在本步骤中，计算机设备可以监听目标氛围灯是否执行完毕，或者也可以由目标氛围灯执行完毕之后主动向计算机设备发送完毕响应消息，以便计算机设备可以及时获知目标氛围灯执行完毕。

在目标氛围灯事件执行完毕之后，计算机设备就可以将缓存的非目标氛围灯调取出来，然后继续执行仲裁失败的非目标氛围灯事件，对于执行非目标氛围灯事件的过程，可以和执行目标氛围灯事件的过程类似，这里就不再赘述。

由上述描述可知，本实施例中通过缓存仲裁失败的非目标氛围灯事件，这样可以避免直接丢弃或放弃执行仲裁失败的氛围灯事件，而是在后续还是有机会执行仲裁失败的氛围灯事件，从而可以提升对全部氛围灯事件管理的完善性。

上述氛围灯事件管理方法中，通过获取业务方发起的所需调用第一氛围灯事件的第一氛围灯调用指令，对第一氛围灯事件以及当前执行的第二氛围灯事件进行仲裁处理，确定仲裁成功的目标氛围灯事件和仲裁失败的非目标氛围灯事件，然后执行目标氛围灯事件并将非目标氛围灯事件进行缓存，在目标氛围灯事件执行完毕后执行非目标氛围灯事件。该方法中，由于可以对仲裁失败的氛围灯事件进行缓存，并在仲裁成功的氛围灯事件执行完之后继续执行仲裁失败的氛围灯事件，这样可以保证任何业务方发出的氛围灯调用事件在仲裁失败后，氛围灯事件也不会终止，而是在仲裁成功的氛围灯事件执行完后有机会继续执行，从而可以避免丢弃仲裁失败的氛围灯事件，保证对全部氛围灯事件均执行，实现对全部氛围灯事件的全链路管理，完善氛围灯事件的管理过程。

上述实施例中提到了可以通过预设的仲裁条件对两个氛围灯事件进行仲裁处理，以下实施例就对仲裁条件为事件类型时如何对两个氛围灯事件进行仲裁处理的过程进行说明。

在另一个实施例中，提供了另一种氛围灯事件管理方法，上述第一氛围灯调用指令中还包括第一氛围灯事件的第一事件类型，在上述实施例的基础上，如图3所示，上述S204可以包括以下步骤：

S302，获取第二氛围灯事件的第二事件类型。

其中，对于氛围灯所包括的事件类型，具体可以根据实际情况设定，比如事件类型可以包括安全事件、交互事件、娱乐事件等；其中安全事件类型指的是影响车辆安全行驶的氛围灯事件，交互事件类型指的是车辆和用户之间或各用户之间的交互形式的氛围灯事件，娱乐事件类型指的是为用户提供娱乐服务相关的氛围灯事件(比如播放音乐时的氛围灯事件)。

第一氛围灯事件的事件类型可以记为第一事件类型，第二氛围灯事件的类型记为第二事件类型，其中第一事件类型和第二事件类型可以相同，也可以不同。

对于第一氛围灯事件的事件类型，可以从获取到的第一氛围灯调用指令中获得，对于第二氛围灯事件的事件类型，在执行第二氛围灯事件时也可以获知其对应的事件类型。

S304，根据第一事件类型以及第二事件类型对第一氛围灯事件和当前执行的第二氛围灯事件进行仲裁处理，确定仲裁成功的目标氛围灯事件和仲裁失败的非目标氛围灯事件。

在本步骤中，在通过两个氛围灯事件的事件类型对两个氛围灯事件进行仲裁处理时，具体可以是基于两个事件类型的优先级进行仲裁处理，具体仲裁处理时，作为可选的实施例，可以是采用如下步骤进行仲裁处理：步骤A1，检测第一事件类型的优先级是否高于第二事件类型的优先级，获得优先级检测结果；步骤A2，根据优先级检测结果对第一氛围灯事件和当前执行的第二氛围灯事件进行仲裁处理，确定仲裁成功的目标氛围灯事件和仲裁失败的非目标氛围灯事件。

具体而言，可以先获得第一事件类型的优先级以及第二事件类型的优先级，然后按照预先设置好的优先级顺序，判断第一事件类型的优先级是否高于第二事件类型的优先级，获得优先级检测结果；例如上述提到的事件类型包括安全事件、交互事件以及娱乐事件，其中，安全事件的优先级>交互事件的优先级>娱乐事件的优先级。这里假设第一事件类型为安全事件，第二事件类型为娱乐事件，则第一事件类型的优先级就高于第二事件类型的优先级。

在获得两个事件类型的优先级检测结果之后，就可以据此进行仲裁处理，比如可以确定优先级高的事件类型对应的氛围灯事件仲裁成功，优先级低的事件类型对应的氛围灯事件仲裁失败，即低优先级的氛围灯事件会打断高优先级的氛围灯事件；当然，也可以通过事件类型的优先级结合其他氛围灯事件的相关参数综合进行仲裁处理，总之可以确定仲裁成功的目标氛围灯事件和仲裁失败的非目标氛围灯事件即可。

本实施例中，通过两个氛围灯事件的事件类型来对两个氛围灯事件进行仲裁处理，这样可以较为快速准确地实现对两个氛围灯事件的仲裁处理，提升仲裁效率。进一步地，可以通过两个氛围灯事件的事件类型的优先级高低来对两个氛围灯事件进行仲裁处理，这样明确通过优先级进行仲裁处理，简单直观，因此可以进一步提升仲裁处理的效率和准确性，保证后续对氛围灯事件管理的有效性。

上述实施例中提到了可以通过两个氛围灯事件的事件类型的优先级高低来对两个氛围灯事件进行仲裁处理，以下实施例就对通过优先级结合其他参数来对两个氛围灯事件进行仲裁处理的过程进行说明。

在另一个实施例中，提供了另一种氛围灯事件管理方法，上述第一氛围灯调用指令中还包括第一氛围灯事件的第一事件类型，在上述实施例的基础上，如图4所示，上述步骤A2可以包括以下步骤：

S402，若优先级检测结果为第一事件类型的优先级等于第二事件类型的优先级，则获取第一氛围灯事件的执行顺序以及第二氛围灯事件的执行顺序。

在本步骤中，在上述进行两个事件类型的优先级检测之后，就可以获得优先级检测结果，若第一事件类型的优先级等于第二事件类型的优先级，即两个事件类型的优先级相同，比如第一事件类型为安全事件，第二事件类型也为安全事件，则第一事件类型的优先级与第二事件类型的优先级相同。

在两个事件类型的优先级相同时，可以依据两个事件类型的执行顺序来对两个氛围灯事件进行仲裁处理，那么这里就需要获取两个氛围灯事件的执行顺序。这里的执行顺序比如可以以执行时间来衡量，比如由于新的氛围灯事件还未执行，因此正在执行的氛围灯事件的执行时间肯定是早于新的氛围灯事件的执行时间的，那么这里就可以根据两个氛围灯事件的执行时间来获得各自的执行顺序，比如可以是新的氛围灯事件的执行顺序高于当前正在执行的氛围灯事件的执行顺序，即后来的氛围灯事件打断先前的氛围灯事件。

S404，根据第一氛围灯事件的执行顺序以及第二氛围灯事件的执行顺序，对第一氛围灯事件和当前执行的第二氛围灯事件进行仲裁处理，确定仲裁成功的目标氛围灯事件和仲裁失败的非目标氛围灯事件。

在本实施例中，在两个氛围灯事件的优先级相同，那么在获得两个氛围灯事件的执行顺序之后，可以依据两个氛围灯事件的执行顺序进行仲裁处理，比如可以将执行顺序较高的氛围灯事件优先执行，执行顺序较低的氛围灯事件暂缓执行。示例地，比如上述提到的，可以是后来的氛围灯事件打断先前的氛围灯事件，即优先执行后来的氛围灯事件。

本实施例中，通过对两个优先级相同的氛围灯事件继续结合各自的执行顺来进行仲裁处理，这样可以保证对任意情况下的氛围灯事件均可以准确进行仲裁处理，实现全方位对全部氛围灯事件的管理，即进一步完善全部氛围灯事件的管理流程。

上述实施例中提到了可以对仲裁失败的非目标氛围灯事件进行缓存，实际缓存之前，一般还需要结合业务方的需求再确定是否需要缓存，以下实施例就对该过程进行说明。

在另一个实施例中，提供了另一种氛围灯事件管理方法，若非目标氛围灯事件为第一氛围灯事件，第一氛围灯调用指令中还包括业务方的缓存请求信息，在上述实施例的基础上，如图5所示，在上述S206之前，上述方法还可以包括以下步骤：

S502，根据业务方的缓存请求信息确定是否需要缓存非目标氛围灯事件。

在本步骤中，在业务方发起氛围灯调用指令时，在该氛围灯调用指令中也可以封装业务方对其中的氛围灯事件是否需要缓存(或者对其中的氛围灯事件在仲裁失败时是否需要缓存)的缓存请求信息，即每个业务方发起的氛围灯调用指令中均可以包括缓存请求信息，该缓存请求信息即可表示业务方是否需要缓存对应的氛围灯事件。

以上述仲裁失败的非目标氛围灯事件为第一氛围灯事件为例，该第一氛围灯调用指令中就可以包括对第一氛围灯事件的缓存请求信息，即业务方是否需要缓存对应的第一氛围灯事件(或者第一氛围灯事件在仲裁失败时是否需要缓存第一氛围灯事件)。

参见图6所示的判断逻辑框图，计算机设备在获得业务方发起的氛围灯调用指令之后，就可以从中获得相应的缓存请求信息，然后基于该缓存请求信息判断业务方是否需要缓存相应的氛围灯事件。

S504，若需要缓存非目标氛围灯事件，则返回执行将非目标氛围灯事件进行缓存的步骤。

在本步骤中，若缓存请求信息表示业务方不需要对相应的氛围灯事件进行缓存，则在该氛围灯事件仲裁失败时可以直接丢弃或放弃该氛围灯事件，这样也可以节省一部分缓存空间。

而在缓存请求信息表示业务方需要对相应的氛围灯事件进行缓存时，则在氛围灯事件仲裁失败之后，比如获得仲裁失败的非目标氛围灯事件之后，就可以执行上述S206中的缓存步骤，将非目标氛围灯事件进行缓存，以便后续仍能执行该非目标氛围灯事件，避免丢弃业务方的氛围灯事件，提升业务方的使用体验。

本实施例中，通业务方发起的氛围灯调用指令中的缓存请求信息确定是否需要缓存相应的氛围灯事件，并在需要缓存时返回执行缓存仲裁失败的非目标氛围灯事件的步骤，这样可以保证后续仍能执行仲裁失败的非目标氛围灯事件，避免丢弃业务方的氛围灯事件，提升业务方的使用体验。

上述实施例中提到了可以对仲裁失败的非目标氛围灯事件进行缓存，缓存方式可以有多种，以下实施例就对其中一种缓存方式进行说明。

在另一个实施例中，在上述实施例的基础上，上述S206中的缓存步骤可以包括以下步骤：

步骤B，将非目标氛围灯事件缓存至预设的事件缓存栈中。

在本步骤中，也就是说，可以预设事件缓存栈，专门用来存放仲裁失败的氛围灯事件，通过事件缓存栈存储氛围灯事件，这样可以提升氛围灯事件的缓存速度以及保证存储数据的准确性。

对于这里预设的事件缓存栈的数量或类型，均可以根据实际情况而定，以下给出一种可选的实施例，上述预设的事件缓存栈包括安全事件缓存栈、交互事件缓存栈以及娱乐事件缓存栈中的至少一个。也就是说，这里可以预先设置三个不同类型的事件缓存栈，每个事件缓存栈中用于存放相应事件类型的氛围灯事件。

针对上述不同类型的事件缓存栈，在对仲裁失败的氛围灯事件进行缓存时就需要结合事件类型去缓存，基于此，上述步骤B可以包括：获取非目标氛围灯事件对应的目标事件类型；将非目标氛围灯事件缓存至目标事件类型对应的事件缓存栈中。具体而言，在获得仲裁失败的非目标氛围灯事件之后，该非目标氛围灯事件对应的业务方在发起氛围灯调用指令时，该氛围灯调用指令中一般也可以包括其中的氛围灯事件的事件类型，因此这里就可以获得非目标氛围灯事件的事件类型，记为目标事件类型。然后可以在预设的多个事件缓存栈中选择出与该目标事件类型相匹配的目标事件缓存栈，之后就可以将该非目标氛围灯事件缓存至该目标事件缓存栈中。

示例地，参见图7所示的氛围灯事件缓存栈入栈流程框图，假设当前正在执行的氛围事件是交互事件，比如当有安全事件调用时，由于安全事件的优先级高于交互事件的优先级，因此交互事件被打断，即交互事件仲裁失败，则将交互事件缓存至交互事件缓存栈。再比如当有新的交互事件调用时，旧的交互事件被打断，即旧的交互事件仲裁失败，那么可以将旧的交互事件缓存至交互事件缓存队列。再比如当有娱乐事件调用时，由于娱乐事件的优先级低于交互事件的优先级，因此娱乐事件仲裁失败，此时可以将娱乐事件缓存至娱乐事件缓存栈。

需要说明的是，由于安全事件类型的优先级最高，因此安全事件类型对应的氛围灯事件永远都是优先执行的，那么只有在两个氛围灯事件均是安全事件类型时，才会将之前执行的氛围灯事件缓存至安全事件缓存栈中。

本实施例中，通过将仲裁失败的氛围灯事件缓存至预设的事件缓存栈中，这样可以提升氛围灯事件的缓存速度以及保证存储数据的准确性。另外，事件缓存栈包括多种不同类型的缓存栈，这样可以对不同类型的氛围灯事件分开缓存，可以更好的区分不同类型的氛围灯事件。进一步地，通过将仲裁失败的氛围灯事件缓存至与其事件类型相匹配的事件缓存栈中，这样可以较为快速地实现对不同类型的氛围灯事件的准确存储。

上述实施例中提到了多种不同类型的事件缓存栈，也就是说，预设的事件缓存栈可以包括多个事件缓存栈，基于此，那么具体如何执行各事件缓存栈中的氛围灯事件，以下实施例就对该过程进行说明。

在另一个实施例中，提供了另一种氛围灯事件管理方法，在上述实施例的基础上，如图8所示，上述S208中执行非目标氛围灯事件的步骤可以包括以下步骤：

S602，获取各事件缓存栈的优先级。

其中，各事件缓存栈的优先级可以与其中存储的氛围灯事件的事件类型相关，具体可以是各事件缓存栈的优先级与其对应存储的事件类型的优先级相同。比如安全事件缓存栈中存储的是安全事件类型的氛围灯事件，交互事件缓存栈中存储的是交互事件类型的氛围灯事件，娱乐事件缓存栈中存储的是娱乐事件类型的氛围灯事件，则安全事件缓存栈的优先级>交互事件缓存栈的优先级>娱乐事件缓存栈的优先级。

S604，根据各事件缓存栈的优先级，依次从高到低检测各事件缓存栈中是否存在未执行的氛围灯事件；上述未执行的氛围灯事件中包括非目标氛围灯事件。

在本步骤中，参见图9所示的氛围灯事件缓存栈出栈流程框图，假设具有安全事件缓存栈、交互事件缓存栈、娱乐事件缓存栈这三个不同类型的事件缓存栈，则可以依次从安全事件缓存栈到交互事件缓存栈再到娱乐事件缓存栈，依次检测各事件缓存栈中是否为空，若不为空，则说明其中包括未执行的氛围灯事件，若为空，则说明其中没有未执行的氛围灯事件，可以继续判断下一个事件缓存栈中是否为空，直至检测完全部的事件缓存栈为止。

需要说明的是，由于仲裁失败的非目标氛围灯事件肯定是缓存在上述多个事件缓存栈中的一个事件缓存栈中的，因此在出栈过程中肯定会检测到该仲裁失败的非目标氛围灯事件，即肯定会找到该非目标氛围灯事件是未执行的氛围灯事件的，后续就可以执行该非目标氛围灯事件。

S606，若存在，则执行未执行的氛围灯事件。

在本步骤中，在按照优先级依次检测各个事件缓存栈中是否存在未执行的氛围灯事件时，假设当前检测的事件缓存栈中存在未执行的氛围灯事件，则将该未执行的氛围灯事件出栈，恢复该氛围灯事件，即执行该氛围灯事件。在当前检测的事件缓存栈为空之后才会去检测下一个事件缓存栈，并执行其中存在的未执行的氛围灯事件，直至全部的事件缓存栈均为空为止。

作为可选的实施例，若各事件缓存栈中均为空，则将氛围灯恢复至初始状态进行显示。这里氛围灯的初始状态可以是氛围灯常亮/呼吸模式等基础状态或基础效果，通过在没有业务方的氛围灯调用事件时将氛围灯恢复至初始状态进行显示，这样可以提高车辆的仪式感，提升用户体验。

本实施例中，通过按照各事件缓存栈的优先级，依次从高到低检测并执行其中未执行的氛围灯事件，这样可以保证优先执行重要的氛围灯事件，保证业务方的具体需求，进一步保证车辆的安全行驶。

在实际执行氛围灯事件时，为了提升氛围灯控制粒度的精度，本实施例中提出了可以对车辆上的氛围灯进行分区控制，示例地，若非目标氛围灯事件为第一氛围灯事件，第一氛围灯调用指令中还包括第一氛围灯事件的显示信息以及分区信息，以下实施例就对具体如何分区控制的过程进行说明。

在另一个实施例中，提供了另一种氛围灯事件管理方法，在上述实施例的基础上，如图10所示，上述S208中执行非目标氛围灯事件的步骤可以包括以下步骤：

S702，根据分区信息确定待显示区域。

在本步骤中，参见图11所示的氛围灯控制框图，车载的氛围灯一般分布在车辆的左前门、右前门、左脚窝、右脚窝、前挡风(也可以称为Ip灯带)和中控区域等多个区域。其中每个区域的氛围灯的具体显示情况可以根据本实施例的方式进行控制。

其中，针对每个氛围灯调用事件而言，其中包括第一氛围灯事件，每个氛围灯调用事件对应的氛围灯调用指令中均包括相应氛围灯事件对应的分区信息，这里的分区信息表示需要该氛围灯事件所要显示的氛围灯的区域信息，可以采用区域标识等方式表示。

在计算机设备，具体可以是SOC芯片获得业务方发起的氛围灯调用指令，然后从氛围灯调用指令中获得分区信息，之后可以分析该分区信息，获得该分区信息表示的待显示区域，即所需显示的氛围灯区域。

另外，这里的待显示区域可以是一个区域，也可以是多个区域，通过分区信息，从而可以实现对氛围灯进行分区控制。

S704，按照显示信息控制待显示区域中的氛围灯进行显示。

在本步骤中，每个氛围灯调用事件对应的氛围灯调用指令中也可以包括该氛围灯事件对应的显示信息，这里的显示信息可以包括氛围灯的显示颜色、显示亮度、显示频率等信息。

具体的，SOC芯片获得业务方发起的氛围灯调用指令，然后从氛围灯调用指令中获得氛围灯的显示信息，之后可以按照氛围灯的显示信息，通过MCU控制相应待显示区域内的氛围灯显示相应的颜色或亮度。

示例地，继续参见图11所示，氛围灯硬件由MCU进行控制，MCU通过Lin总线和SOC进行通讯。在SOC中搭建氛围灯平台服务，氛围灯平台服务主要包含氛围灯调用仲裁功能和氛围灯分区控制功能，其中氛围灯调用仲裁功能主要按照上述实施例的方式对两个及以上的氛围灯事件进行仲裁处理，氛围灯分区控制功能主要按照本实施例的方式对不同区域的氛围灯进行显示控制；另外，SOC中的各个业务方或者外部业务方可以通过氛围灯平台服务发起调用氛围灯的指令，后续通过MCU实现对氛围灯的控制。

本实施例中，通过根据氛围灯调用指令中的分区信息确定待显示区域，再根据氛围灯调用指令中的显示信息控制待显示区域中的氛围灯进行显示，这样可以实现对氛围灯的分区控制显示，提升用户的体验度。

以下给出一个详细实施例来对本公开实施例的技术方案进行说明，在上述实施例的基础上，该方法可以包括以下步骤：

S1，获取业务方发起的第一氛围灯调用指令；第一氛围灯调用指令中包括业务方所需调用的第一氛围灯事件、第一事件类型、缓存请求信息、分区信息以及显示信息；

S2，获取当前执行的第二氛围灯事件的第二事件类型；

S3，检测第一事件类型的优先级是否高于第二事件类型的优先级，若高于，则执行S4，若低于，则执行S5，若等于，则执行S6；

S4，确定第一氛围灯事件为仲裁成功的目标氛围灯事件，以及确定第二氛围灯事件为仲裁失败的非目标氛围灯事件；

S5，确定第二氛围灯事件为仲裁成功的目标氛围灯事件，以及确定第一氛围灯事件为仲裁失败的非目标氛围灯事件；

S6，获取第一氛围灯事件的执行顺序以及第二氛围灯事件的执行顺序；

S7，将执行顺序高的氛围灯事件确定为仲裁成功的目标氛围灯事件，以及将执行顺序低的氛围灯事件确定为仲裁失败的非目标氛围灯事件；

S8，执行目标氛围灯事件；

S9，根据缓存请求信息确定是否需要缓存非目标氛围灯事件，若是，则执行S10，否则，结束缓存流程；

S10，获取非目标氛围灯事件对应的目标事件类型；

S11，将非目标氛围灯事件缓存至目标事件类型对应的事件缓存栈中；

S12，在目标氛围灯事件执行完毕后，获取各事件缓存栈的优先级；

S13，根据各事件缓存栈的优先级，依次从高到低检测各事件缓存栈中是否存在未执行的氛围灯事件；未执行的氛围灯事件中包括非目标氛围灯事件；

S14，若存在，则根据分区信息确定待显示区域；

S15，按照显示信息控制待显示区域中的氛围灯进行显示；

S16，若各事件缓存栈中均为空，则将氛围灯恢复至初始状态进行显示。

以下给出一个具体场景举例：

假设氛围灯处于超速提醒调用事件下(超速提醒调用事件优先级最高，此时氛围灯以红光闪烁)，此时有业务方调用氛围灯音乐律动事件，会被仲裁逻辑判定为失败，此时会将音乐律动调用事件缓存进娱乐事件缓存栈中，当超速提醒调用事件结束时，会从缓存事件栈中取出音乐律动调用事件，恢复到音乐律动事件上执行，而不是直接回到初始状态。

由此可见，本公开实施例的方法可以保证任何业务方发出的氛围灯调用事件在仲裁失败后，氛围灯事件也不会终止，而是在仲裁成功的氛围灯事件执行完后有机会继续执行，从而可以避免丢弃仲裁失败的氛围灯事件，保证对全部氛围灯事件均执行，实现对全部氛围灯事件的全链路管理，完善氛围灯事件的管理过程。

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

在一个实施例中，如图12所示，提供了一种氛围灯事件管理装置，包括：接收模块、仲裁模块、缓存模块以及管理模块，其中：

接收模块，用于获取业务方发起的第一氛围灯调用指令；上述第一氛围灯调用指令中包括业务方所需调用的第一氛围灯事件；

仲裁模块，用于对第一氛围灯事件和当前执行的第二氛围灯事件进行仲裁处理，确定仲裁成功的目标氛围灯事件和仲裁失败的非目标氛围灯事件；

缓存模块，用于执行目标氛围灯事件，并将非目标氛围灯事件进行缓存；

管理模块，用于在目标氛围灯事件执行完毕后，执行非目标氛围灯事件。

在另一个实施例中，提供了另一种氛围灯事件管理装置，在上述实施例的基础上，上述第一氛围灯调用指令中还包括第一氛围灯事件的第一事件类型，上述仲裁模块可以包括：

类型获取单元，用于获取上述第二氛围灯事件的第二事件类型；

仲裁单元，用于根据上述第一事件类型以及上述第二事件类型对上述第一氛围灯事件和当前执行的第二氛围灯事件进行仲裁处理，确定仲裁成功的目标氛围灯事件和仲裁失败的非目标氛围灯事件。

可选的，上述仲裁单元，可以包括：

优先级检测子单元，用于检测上述第一事件类型的优先级是否高于上述第二事件类型的优先级，获得优先级检测结果；

仲裁子单元，用于根据上述优先级检测结果对上述第一氛围灯事件和当前执行的第二氛围灯事件进行仲裁处理，确定仲裁成功的目标氛围灯事件和仲裁失败的非目标氛围灯事件。

可选的，上述仲裁子单元，具体用于若上述优先级检测结果为上述第一事件类型的优先级等于上述第二事件类型的优先级，则获取上述第一氛围灯事件的执行顺序以及第二氛围灯事件的执行顺序；根据上述第一氛围灯事件的执行顺序以及第二氛围灯事件的执行顺序，对上述第一氛围灯事件和当前执行的第二氛围灯事件进行仲裁处理，确定仲裁成功的目标氛围灯事件和仲裁失败的非目标氛围灯事件。

在另一个实施例中，提供了另一种氛围灯事件管理装置，在上述实施例的基础上，若非目标氛围灯事件为第一氛围灯事件，第一氛围灯调用指令中还包括业务方的缓存请求信息，上述缓存模块将非目标氛围灯事件进行缓存之前，上述装置还可以包括：

缓存检测模块，用于根据上述业务方的缓存请求信息确定是否需要缓存上述非目标氛围灯事件；

返回模块，用于若需要缓存上述非目标氛围灯事件，则返回执行上述将上述非目标氛围灯事件进行缓存的步骤。

在另一个实施例中，提供了另一种氛围灯事件管理装置，在上述实施例的基础上，上述缓存模块，可以包括：

缓存单元，用于将上述非目标氛围灯事件缓存至预设的事件缓存栈中。

可选的，上述预设的事件缓存栈包括安全事件缓存栈、交互事件缓存栈以及娱乐事件缓存栈中的至少一个。

可选的，上述缓存单元，具体用于获取上述非目标氛围灯事件对应的目标事件类型；将上述非目标氛围灯事件缓存至上述目标事件类型对应的事件缓存栈中。

在另一个实施例中，提供了另一种氛围灯事件管理装置，在上述实施例的基础上，上述预设的事件缓存栈包括多个事件缓存栈，上述管理模块，可以包括：

优先级获取单元，用于获取各上述事件缓存栈的优先级；

事件检测单元，用于根据各上述事件缓存栈的优先级，依次从高到低检测各上述事件缓存栈中是否存在未执行的氛围灯事件；上述未执行的氛围灯事件中包括上述非目标氛围灯事件；

执行单元，用于若存在，则执行上述未执行的氛围灯事件。

可选的，上述装置还可以包括：

恢复模块，用于若各上述事件缓存栈中均为空，则将氛围灯恢复至初始状态进行显示。

在另一个实施例中，提供了另一种氛围灯事件管理装置，若上述非目标氛围灯事件为上述第一氛围灯事件，上述第一氛围灯调用指令中还包括上述第一氛围灯事件的显示信息以及分区信息，在上述实施例的基础上，上述管理模块，可以包括：

分区确定单元，用于根据上述分区信息确定待显示区域；

分区控制单元，用于按照上述显示信息控制上述待显示区域中的氛围灯进行显示。

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

在示例性实施例中，还提供了一种计算机设备，包括存储器和处理器，存储器中存储有计算机程序，该处理器执行计算机程序时实现上述氛围灯事件管理方法。

在示例性实施例中，还提供了一种包括指令的非临时性计算机可读存储介质，例如包括指令的存储器，上述指令可由计算机设备的处理器执行以完成上述方法。例如，所述非临时性计算机可读存储介质可以是ROM、随机存取存储器(RAM)、CD-ROM、磁带、软盘和光数据存储设备等。

在示例性实施例中，还提供了一种包括指令的存储介质，例如包括指令的存储器，上述指令可由服务器的处理器执行以完成上述方法。存储介质可以是非临时性计算机可读存储介质，例如，所述非临时性计算机可读存储介质可以是ROM、随机存取存储器(RAM)、CD-ROM、磁带、软盘和光数据存储设备等。

在示例性实施例中，还提供了一种计算机程序产品，该计算机程序被处理器执行时，可以实现上述方法。该计算机程序产品包括一个或多个计算机指令。在计算机上加载和执行这些计算机指令时，可以全部或部分地按照本公开实施例所述的流程或功能实现上述方法中的部分或者全部。

需要说明的是，本说明书及实施例中所述方案，如涉及个人信息处理，则均会在具备合法性基础(例如征得个人信息主体同意，或者为履行合同所必需等)的前提下进行处理，且仅会在规定或者约定的范围内进行处理。用户拒绝处理基本功能所需必要信息以外的个人信息，不会影响用户使用基本功能。

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

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

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