CN116774805A - 驾驶员监控系统的能耗控制方法、装置、电子设备及介质 - Google Patents

Abstract

本申请提供一种驾驶员监控系统的能耗控制方法、装置、电子设备及介质。该方法包括：响应于对监听事件的触发操作，对预先封装在前台应用或智能感知应用程序中的能耗控制信号生成方法进行调用；生成与监听事件相对应的能耗控制信号，将能耗控制信号通过智能感知应用程序中的通信模块传递给智能感知服务程序；利用智能感知服务程序中的算法库对能耗控制信号进行识别，以确定信号处理规则，依据预定的信号处理规则，对驾驶员监控系统内的智能感知识别算法的识别信号对象进行调整，以便对驾驶员监控系统的性能消耗进行控制。本申请降低驾驶员监控系统的能耗优化成本，提升驾驶员监控系统的性能和稳定性，减少智能感知识别算法对资源的消耗。

Description

驾驶员监控系统的能耗控制方法、装置、电子设备及介质

技术领域

本申请涉及新能源汽车技术领域，尤其涉及一种驾驶员监控系统的能耗控制方法、装置、电子设备及介质。

背景技术

在现代智能座舱和新能源汽车领域，驾驶员监控系统(Driver MonitoringSystem，简称DMS)的作用至关重要，用于识别和防止驾驶员的疲劳和分心驾驶行为。然而，运行DMS所需的复杂算法需要大量的计算资源，这会消耗大量的中央处理器(CPU)和图形处理器(GPU)资源。长时间高强度的运算可能会导致系统资源的过度占用，进而导致汽车的计算系统变得缓慢甚至崩溃，影响系统的稳定性和安全性。

当前，许多现有的技术方案试图通过优化DMS的资源消耗来解决此问题。然而，这些方案大多依赖于对算法进行优化，以减少运算复杂度，或是通过更强大的硬件来满足高资源消耗的需求，这些解决方案常常面临着实际应用中的种种限制，如成本过高、优化空间有限等问题。而且，现有的技术方案大多没有考虑到在不影响DMS功能的前提下，如何合理、有效地利用系统资源，以保持整个系统的高效运行。

此外，虽然现有技术已经公开了两个系统之间的前后台切换过程，但这些技术并未应用到智能座舱领域，且对于如何优化DMS在前后台切换时的资源消耗没有进行详细的技术描述。因此，对于如何在前后台切换过程中，优化DMS的资源消耗，以及如何在保证DMS功能的同时，合理利用系统资源，仍然存在技术问题需要解决。

发明内容

有鉴于此，本申请实施例提供了一种驾驶员监控系统的能耗控制方法、装置、电子设备及介质，以解决现有技术存在的成本高，能耗优化效果差，导致系统的稳定性和安全性降低的问题。

本申请实施例的第一方面，提供了一种驾驶员监控系统的能耗控制方法，包括：响应于对预设的监听事件的触发操作，对预先封装在前台应用或智能感知应用程序中的能耗控制信号生成方法进行调用；利用能耗控制信号生成方法生成与监听事件相对应的能耗控制信号，将能耗控制信号通过智能感知应用程序中设置的通信模块传递给智能感知服务程序；利用安装在智能感知服务程序中的算法库对能耗控制信号进行识别，以确定监听事件对应的信号处理规则，依据预定的信号处理规则，对驾驶员监控系统内的智能感知识别算法的识别信号对象进行调整，以便对驾驶员监控系统的性能消耗进行控制。

本申请实施例的第二方面，提供了一种驾驶员监控系统的能耗控制装置，包括：调用模块，被配置为响应于对预设的监听事件的触发操作，对预先封装在前台应用或智能感知应用程序中的能耗控制信号生成方法进行调用；生成模块，被配置为利用能耗控制信号生成方法生成与监听事件相对应的能耗控制信号，将能耗控制信号通过智能感知应用程序中设置的通信模块传递给智能感知服务程序；调整模块，被配置为利用安装在智能感知服务程序中的算法库对能耗控制信号进行识别，以确定监听事件对应的信号处理规则，依据预定的信号处理规则，对驾驶员监控系统内的智能感知识别算法的识别信号对象进行调整，以便对驾驶员监控系统的性能消耗进行控制。

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

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

本申请实施例采用的上述至少一个技术方案能够达到以下有益效果：

通过响应于对预设的监听事件的触发操作，对预先封装在前台应用或智能感知应用程序中的能耗控制信号生成方法进行调用；利用能耗控制信号生成方法生成与监听事件相对应的能耗控制信号，将能耗控制信号通过智能感知应用程序中设置的通信模块传递给智能感知服务程序；利用安装在智能感知服务程序中的算法库对能耗控制信号进行识别，以确定监听事件对应的信号处理规则，依据预定的信号处理规则，对驾驶员监控系统内的智能感知识别算法的识别信号对象进行调整，以便对驾驶员监控系统的性能消耗进行控制。本申请降低对驾驶员监控系统进行能耗优化的成本，提升驾驶员监控系统的性能和稳定性，减少智能感知识别算法对资源的消耗。

附图说明

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

图1是本申请实施例提供的驾驶员监控系统的能耗控制方法在实际应用中涉及的系统架构示意图；

图2是本申请实施例提供的驾驶员监控系统的能耗控制方法的流程示意图；

图3是本申请实施例提供的驾驶员监控系统的能耗控制装置的结构示意图；

图4是本申请实施例提供的电子设备的结构示意图。

具体实施方式

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

驾驶员监控系统(Driver Monitoring System，DMS)在汽车安全和自动驾驶中有重要作用。但其运算过程中消耗大量的CPU和GPU资源，可能导致系统变慢，甚至崩溃。因此，急需优化DMS，减少其对CPU的消耗，提高其性能。虽然有一些现有技术提出在两个系统之间进行前后台切换以节省资源，但它们并未专门针对汽车智能座舱这一领域。智能座舱的需求与普通电脑或移动设备有所不同，因此现有的技术还不能完全满足需求。

为了解决上述技术问题，本申请提出了一种驾驶员监控系统的能耗控制方法，通过监听应用前台通知和休眠通知，以及摄像头状态和车身状态，本申请可以准确地确定何时需要执行DMS算法，从而降低不必要的计算量。当DMSApp接收到前台应用信息时，DMS会执行相应的动作指令。反之，当接收到休眠的应用信息或者检测到摄像头故障、车身停止并且座位传感器无重力感应变化时，DMS会暂停运行，进入休眠状态。这种动态调整的方式可以大大降低CPU和GPU的使用率，提升DMS的性能。本申请还可以实现在不必要的时候关闭DMS，避免无效运行，节约资源，通过应用休眠通知，关闭DMS的功能，减少对CPU和GPU的使用，提升系统运行效率。本申请还通过监控摄像头状态和车身状态，可以在出现异常时及时进入休眠状态，避免DMS运行引发的系统稳定性问题。

图1是本申请实施例提供的驾驶员监控系统的能耗控制方法在实际应用中涉及的系统架构示意图；如图1所示，该系统架构包括安装在车端的QNX系统和Android系统，QNX系统与Android系统之间通过FDBus进行通信连接；其中，QNX系统中设有Function Services层，Function Services层中安装有DMS&OMS&FaceID Server(智能感知服务程序)，DMS&OMS&FaceID Server中设有算法库，算法库中封装有DMS智能感知识别算法，DMS智能感知识别算法能够识别驾驶员的行为和状态，比如是否疲劳、是否专注等；Android系统内安装有DMS&OMS&FaceID App(智能感知应用程序)以及与DMS&OM S&FaceID App具有交互功能的应用程序模块，比如场景引擎应用模块、看看应用模块等，DMS&OMS&FaceID App与其他应用程序模块之间通过AIDL通信连接；DMS&OMS&FaceID App中设有Dms Core模块(通信模块)，DmsCore模块负责与QNX系统内的DMS&OMS&FaceID Server进行通信，应用程序模块及DMS&OMS&FaceID App中均设有aar包(通信工具包)，applicati onNotify()方法及sleepNotify()方法均封装在相应的aar包中，通过调用aar包中的applicationNotify()方法或sleepNotify()方法，即可自动生成能耗控制信号，并将能耗控制信号发送给DMS&OMS&FaceID Server，以使DMS&OMS&FaceID Server中的DMS智能感知识别算法利用能耗控制信号对DMS的能耗进行优化控制。

下面结合图1所示的系统架构，对本申请实施例涉及的Android系统的内部交互场景的相关内容进行说明，具体可以包括以下内容：

在Android系统内部，DMS&OMS&FaceID App与其他应用程序模块进行交互。识别出的智能感知信号最终会传递到与DMS&OMS&FaceID App交互的模块，比如场景引擎模块。场景引擎模块也会将自身的状态通过DMS&OMS&FaceID App发送到QNX系统内的算法中。这个过程需要FDBus作为通信的桥梁。

进一步地，Android系统内部的DMS&OMS&FaceID App与其他模块间的交互是一个重要的环节。DMS&OMS&FaceID App是一个运行在Android系统Application层的应用程序，它负责执行DMS(驾驶员监控系统)、OMS(乘员监控系统)、FaceID(面部识别系统)等功能。场景引擎模块是一个在Androi d系统中与DMS&OMS&FaceID App交互的模块，它可以识别和理解各种应用场景，然后根据不同的场景提供相应的服务。FDBus是一个通信协议，它可以在QNX系统和Android系统之间传输数据。在本申请技术方案中，FDBus被用作通信的桥梁，使得QNX系统和Android系统可以互相通信。AIDL(Andr oid Interface DefinitionLanguage)即Android接口定义语言，是一种用于And roid系统中进程间通信(IPC)的接口描述语言。

在Android系统内部，DMS&OMS&FaceID App需要与其他应用程序模块(也可以称为交互模块)进行交互。例如，当DMS&OMS&FaceID App的算法识别到某种智能感知信号后，它会将这个信号传递给其他应用程序模块，比如场景引擎模块。当场景引擎模块收到这个智能感知信号后，它会根据信号内容来调整自身的状态。然后，它还会通过DMS&OMS&FaceIDApp将自身的状态信息传递给QNX系统内Function Services层的智能感知识别算法。

在上述交互过程中，DMS&OMS&FaceID App与场景引擎模块之间的通信是通过AIDL实现的。AIDL为Android系统内的进程间通信提供了一种有效的通信方式。同时，DMS&OMS&FaceID App与QNX系统中的Function Service s层之间的通信则是通过FDBus实现的。FDBus是一种用于在QNX系统和An droid系统之间进行通信的方式，可以传递包括json对象在内的可序列化对象，相比socket更加灵活。通过这样的设计，本申请技术方案能够实现在Android系统内部的不同模块之间以及Android系统与QNX系统之间的高效通信，从而实现了智能感知算法的优化和应用状态的有效管理。

下面结合附图以及具体实施例对本申请技术方案的内容进行详细描述。

图2是本申请实施例提供的驾驶员监控系统的能耗控制方法的流程示意图。图2的驾驶员监控系统的能耗控制方法可以由新能源汽车的Soc来执行。如图2所示，该驾驶员监控系统的能耗控制方法具体可以包括：

S201，响应于对预设的监听事件的触发操作，对预先封装在前台应用或智能感知应用程序中的能耗控制信号生成方法进行调用；

S202，利用能耗控制信号生成方法生成与监听事件相对应的能耗控制信号，将能耗控制信号通过智能感知应用程序中设置的通信模块传递给智能感知服务程序；

S203，利用安装在智能感知服务程序中的算法库对能耗控制信号进行识别，以确定监听事件对应的信号处理规则，依据预定的信号处理规则，对驾驶员监控系统内的智能感知识别算法的识别信号对象进行调整，以便对驾驶员监控系统的性能消耗进行控制。

DMS通常指的是驾驶员监控系统(Driver Monitoring System)。这是一种使用传感器和其他技术来监控驾驶员行为和状况的系统。其主要目的是提高道路交通安全。驾驶员监控系统可以通过诸多方式来监测驾驶员。例如，它可能使用摄像头监控驾驶员的眼睛和脸部，以检测疲劳或分心的迹象。它还可能监控驾驶员的生理数据，如心率或脑电波，以识别压力或疲劳的迹象。一些系统甚至可以监控驾驶员的手势，以检测他们是否在驾驶过程中分心。

QNX是一种实时操作系统(RTOS)，它的设计目标是为嵌入式系统提供小，快，稳定的微内核和应用程序环境。在新能源汽车中，QNX系统是广泛使用的汽车信息娱乐系统(Infotainment)和车载电子设备(例如导航系统，数字仪表盘，驾驶辅助系统等)的操作系统。它的实时特性使得它特别适合用于需要快速，准确反应的汽车系统，如自动驾驶系统等。QNX系统具有高度模块化的设计，以及稳定，可靠的性能。它可以运行在各种不同的硬件架构上，同时提供了丰富的开发工具，使得它对于开发者来说是一个灵活且强大的平台。

在一些实施例中，监听事件包括前台应用事件以及休眠事件，监听事件的触发操作，包括：当监听到至少一个应用程序处于前台时，对前台应用事件进行触发，当监听到Android系统的休眠广播、摄像头状态满足预设条件和/或车身状态满足预设条件时，对休眠事件进行触发。

具体地，首先本申请设定一些需要监听的事件，包括前台应用事件和休眠事件。对于前台应用事件，其触发操作如下：系统将实时监听当前运行的应用程序，当系统监听到至少一个应用程序处于前台运行状态时，对前台应用事件进行触发。例如，当场景引擎应用处于前台时，会触发与之相关的前台应用事件。

休眠事件的触发则与多个条件相关。这些条件包括但不限于：监听到Android系统的休眠广播、摄像头状态满足预设条件，以及车身状态满足预设条件。只有当这些条件同时满足时，才会触发休眠事件。以摄像头状态满足预设条件为例，例如包括摄像头出现故障或其他异常情况。车身状态满足预设条件可以包括车辆停止并且车内座位传感器无重力感应的变化等。

在一些实施例中，对预先封装在前台应用或智能感知应用程序中的能耗控制信号生成方法进行调用，包括：当触发前台应用事件时，对前台应用的通信工具包中预先封装的前台应用能耗控制信号生成方法进行调用，当触发休眠事件时，对智能感知应用程序的通信工具包中预先封装的休眠能耗控制信号生成方法进行调用。

具体地，对于前台应用以及智能感知应用程序中预先封装的能耗控制信号生成方法，根据具体场景进行相应调用。对于前台应用事件的处理，当系统触发前台应用事件时，会调用预先封装在前台应用的通信工具包中的能耗控制信号生成方法，即applicationNotify()方法。以场景引擎应用为例，当它处于前台时，会调用applicationNotify()方法，这个方法被封装在aar包(通信工具包)内部，被DMS&OMS&FaceID App以及与之交互的模块使用。通过调用appli cationNotify()方法，场景引擎应用可以将其状态信息通过Dms Core模块发送给QNX中的DMS&OMS&FaceID Server，进一步传递至.so库(算法库)内部的智能感知识别算法。

进一步地，对于休眠事件的处理，当系统触发休眠事件时，会调用预先封装在智能感知应用程序的通信工具包中的休眠能耗控制信号生成方法，即slee pNotify()方法。这个方法是Dms Core模块内部定义的，当DMS&OMS&FaceID App处于非活跃状态时，sleepNotify()函数会被调用。通过调用此函数，DM S&OMS&FaceID App可以向QNX系统的DMS&OMS&FaceID Server发出休眠通知。

在一些实施例中，利用能耗控制信号生成方法生成与监听事件相对应的能耗控制信号，包括：当监听事件为前台应用事件时，利用前台应用能耗控制信号生成方法生成与前台应用事件相对应的前台应用能耗控制信号，当监听事件为休眠事件时，利用休眠能耗控制信号生成方法生成与休眠事件相对应的休眠能耗控制信号。

具体地，本申请在监听事件发生之后，可以利用预先定义的能耗控制信号生成方法，生成与监听事件相对应的能耗控制信号。首先，当监听事件为前台应用事件时，系统会利用预先定义的前台应用能耗控制信号生成方法，也就是applicationNotify()方法，生成与前台应用事件相对应的前台应用能耗控制信号。在实际应用中，applicationNotify()方法被封装在aar包内部，供与DMS&OMS&FaceID App交互的模块调用。例如，当场景引擎应用处于前台运行时，该应用模块会调用applicationNotify()方法，从而生成前台应用能耗控制信号。

进一步地，当监听事件为休眠事件时，系统会利用预先定义的休眠能耗控制信号生成方法，也就是sleepNotify()方法，生成与休眠事件相对应的休眠能耗控制信号。在实际应用中，sleepNotify()方法可以被封装在Dms Core模块内部，当DMS&OMS&FaceID App处于非活跃状态时，sleepNotify()函数会被调用，从而生成休眠能耗控制信号。

最后，无论是前台应用能耗控制信号还是休眠能耗控制信号，都将通过预先设置在智能感知应用程序中的通信模块(即Dms Core模块)，传递给智能感知服务程序(即QNX系统中的DMS&OMS&FaceID Server)。在收到能耗控制信号后，智能感知服务程序会根据具体的能耗控制信号，调整自身的运行状态，从而实现对DMS性能的优化。

在一些实施例中，利用安装在智能感知服务程序中的算法库对能耗控制信号进行识别，以确定监听事件对应的信号处理规则，包括：当监听事件为前台应用事件时，利用智能感知服务程序中的算法库对前台应用能耗控制信号进行识别，依据识别结果确定前台应用事件对应的信号处理规则；当监听事件为休眠事件时，利用智能感知服务程序中的算法库对休眠能耗控制信号进行识别，依据识别结果确定休眠事件对应的信号处理规则。

具体地，本申请技术方案还能够利用安装在智能感知服务程序中的算法库，对生成的能耗控制信号进行识别和处理。首先，当监听事件为前台应用事件时，系统会利用位于智能感知服务程序中的算法库，对前台应用能耗控制信号进行识别。系统根据识别的结果，确定并执行前台应用事件对应的信号处理规则。

在一个示例中，以场景引擎应用为例，当此应用处于前台时，系统会调用aar包内的applicationNotify()方法，生成前台应用能耗控制信号。然后，这个信号会通过DMS&OMS&FaceID App内部的Dms Core模块，传递给QNX系统中的DMS&OMS&FaceID Server。在这里，系统将利用其内部的算法库，对传递来的前台应用能耗控制信号进行识别。经过识别，系统确定了前台应用事件对应的信号处理规则，比如信号处理规则为只对场景引擎应用定义的手势信号进行识别，而不去识别其他手势信号，以此优化DMS的识别算法，提升DMS的性能。

在另一个示例中，当监听事件为休眠事件时，系统同样会利用智能感知服务程序中的算法库，对休眠能耗控制信号进行识别。根据识别的结果，系统确定并执行休眠事件对应的信号处理规则。例如，当智能感知服务程序收到由sleepNotify()方法生成的休眠能耗控制信号时，利用算法库对该休眠能耗控制信号进行识别，得到休眠事件对应的信号处理规则，例如将自身(智能感知服务程序)置于休眠状态，从而减少不必要的资源消耗，进一步提升DMS的性能。

在一些实施例中，依据预定的信号处理规则，对驾驶员监控系统内的智能感知识别算法的识别信号对象进行调整，包括：当监听事件为前台应用事件时，依据预定的前台应用事件对应的信号处理规则，利用智能感知识别算法对前台应用对应的预设手势信号进行处理，并对其他手势信号进行忽略。

具体地，本申请实施例将根据预定的信号处理规则，对驾驶员监控系统(DMS)内部的智能感知识别算法的识别信号对象进行调整。例如，当监听事件为前台应用事件时，系统会根据预设的前台应用事件对应的信号处理规则，调整智能感知识别算法。在这种情况下，智能感知识别算法将只对与前台应用对应的预设手势信号进行处理，对其他手势信号则进行忽略。

在一个示例中，假设场景引擎应用目前是前台应用，此时系统接收到前台应用的通知。根据预设的信号处理规则，智能感知识别算法会优化自己的运行，只处理与场景引擎应用相关的手势信号，忽略所有其他手势信号。通过这种方式，系统可以避免进行无关的计算，从而减少计算资源的消耗，提高整个系统的运行效率。

在一些实施例中，依据预定的信号处理规则，对驾驶员监控系统内的智能感知识别算法的识别信号对象进行调整，包括：当监听事件为休眠事件时，依据预定的休眠事件对应的信号处理规则，使智能感知识别算法停止对智能感知应用程序的手势信号进行处理，并将智能感知识别算法的计算资源进行释放。

具体地，当监听事件为休眠事件时，本申请实施例还将根据预定的休眠事件对应的信号处理规则，调整智能感知识别算法。例如，智能感知识别算法会停止对智能感知应用程序的手势信号进行处理，并释放相应的计算资源。

在一个示例中，当系统监听到休眠事件时，会调用sleepNotify()方法，这个方法会通过预定的通信路径，通知运行在DMS&OMS&FaceID Server中的智能感知识别算法可以停止对智能感知应用程序的手势信号进行处理。这样，系统就可以释放出用于处理该应用信号的计算资源，这些资源可以用于其他的计算任务。

在另一个示例中，当DMS&OMS&FaceID App不再运行在前台时(比如用户切换到了其他应用，或者将应用最小化)，该应用会发送一个休眠通知。在收到这个休眠通知后，DMS&OMS&FaceID Server会知道DMS&OMS&Fac eID App不再需要算法服务，于是可以将这部分资源释放，供其他程序使用。

根据本申请实施例提供的技术方案，本申请通过对前台应用通知和休眠事件的智能感知和处理，精确地控制了智能感知识别算法的工作状态，降低了驾驶员监控系统(DMS)的CPU和GPU使用率，优化了计算资源的分配和使用。本申请通过根据前台应用信息或休眠应用信息调整DMS&OMS&FaceID Server中的算法工作状态，使得DMS能够根据具体情况执行动作指令或休眠指令，以此提升DMS的性能。本申请在Android系统中设置了监听器，对休眠广播、摄像头状态和车身状态进行实时监听，一旦发生特定事件，例如摄像头出现故障，或者车身处于停止，并且车内座位传感器无重力感应变化时，系统会发出休眠信号，调用sleepNotify()方法，使得智能感知算法停止工作，从而避免不必要的计算和资源浪费。本申请还通过对计算资源的精细化管理和调度，使得系统在处理用户需求和执行任务时，能够更快速、更稳定，大大提升了用户体验。总体来说，本申请技术方案通过在DMS&OMS&FaceID Server中实现智能感知算法，并根据前台和休眠通知进行算法的动态优化，实现了更高效的资源利用，提高了系统性能。

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

图3是本申请实施例提供的驾驶员监控系统的能耗控制装置的结构示意图。如图3所示，该驾驶员监控系统的能耗控制装置包括：

调用模块301，被配置为响应于对预设的监听事件的触发操作，对预先封装在前台应用或智能感知应用程序中的能耗控制信号生成方法进行调用；

生成模块302，被配置为利用能耗控制信号生成方法生成与监听事件相对应的能耗控制信号，将能耗控制信号通过智能感知应用程序中设置的通信模块传递给智能感知服务程序；

调整模块303，被配置为利用安装在智能感知服务程序中的算法库对能耗控制信号进行识别，以确定监听事件对应的信号处理规则，依据预定的信号处理规则，对驾驶员监控系统内的智能感知识别算法的识别信号对象进行调整，以便对驾驶员监控系统的性能消耗进行控制。

在一些实施例中，监听事件包括前台应用事件以及休眠事件，图3的调用模块301当监听到至少一个应用程序处于前台时，对前台应用事件进行触发，当监听到Android系统的休眠广播、摄像头状态满足预设条件和/或车身状态满足预设条件时，对休眠事件进行触发。

在一些实施例中，图3的调用模块301当触发前台应用事件时，对前台应用的通信工具包中预先封装的前台应用能耗控制信号生成方法进行调用，当触发休眠事件时，对智能感知应用程序的通信工具包中预先封装的休眠能耗控制信号生成方法进行调用。

在一些实施例中，图3的生成模块302当监听事件为前台应用事件时，利用前台应用能耗控制信号生成方法生成与前台应用事件相对应的前台应用能耗控制信号，当监听事件为休眠事件时，利用休眠能耗控制信号生成方法生成与休眠事件相对应的休眠能耗控制信号。

在一些实施例中，图3的调整模块303当监听事件为前台应用事件时，利用智能感知服务程序中的算法库对前台应用能耗控制信号进行识别，依据识别结果确定前台应用事件对应的信号处理规则；当监听事件为休眠事件时，利用智能感知服务程序中的算法库对休眠能耗控制信号进行识别，依据识别结果确定休眠事件对应的信号处理规则。

在一些实施例中，图3的调整模块303当监听事件为前台应用事件时，依据预定的前台应用事件对应的信号处理规则，利用智能感知识别算法对前台应用对应的预设手势信号进行处理，并对其他手势信号进行忽略。

在一些实施例中，图3的调整模块303当监听事件为休眠事件时，依据预定的休眠事件对应的信号处理规则，使智能感知识别算法停止对智能感知应用程序的手势信号进行处理，并将智能感知识别算法的计算资源进行释放。

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

图4是本申请实施例提供的电子设备4的结构示意图。如图4所示，该实施例的电子设备4包括：处理器401、存储器402以及存储在该存储器402中并且可以在处理器401上运行的计算机程序403。处理器401执行计算机程序403时实现上述各个方法实施例中的步骤。或者，处理器401执行计算机程序403时实现上述各装置实施例中各模块/单元的功能。

示例性地，计算机程序403可以被分割成一个或多个模块/单元，一个或多个模块/单元被存储在存储器402中，并由处理器401执行，以完成本申请。一个或多个模块/单元可以是能够完成特定功能的一系列计算机程序指令段，该指令段用于描述计算机程序403在电子设备4中的执行过程。

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

处理器401可以是中央处理单元(Central Processing Unit，CPU)，也可以是其它通用处理器、数字信号处理器(Digital Signal Processor，DSP)、专用集成电路(Application Specific Integrated Circuit，ASIC)、现场可编程门阵列(Field-Programmable Gate Array，FPGA)或者其它可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件等。通用处理器可以是微处理器或者该处理器也可以是任何常规的处理器等。

存储器402可以是电子设备4的内部存储单元，例如，电子设备4的硬盘或内存。存储器402也可以是电子设备4的外部存储设备，例如，电子设备4上配备的插接式硬盘，智能存储卡(Smart Media Card，SMC)，安全数字(Secure Digital，SD)卡，闪存卡(Flash Card)等。进一步地，存储器402还可以既包括电子设备4的内部存储单元也包括外部存储设备。存储器402用于存储计算机程序以及电子设备所需的其它程序和数据。存储器402还可以用于暂时地存储已经输出或者将要输出的数据。

所属领域的技术人员可以清楚地了解到，为了描述的方便和简洁，仅以上述各功能单元、模块的划分进行举例说明，实际应用中，可以根据需要而将上述功能分配由不同的功能单元、模块完成，即将装置的内部结构划分成不同的功能单元或模块，以完成以上描述的全部或者部分功能。实施例中的各功能单元、模块可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中，上述集成的单元既可以采用硬件的形式实现，也可以采用软件功能单元的形式实现。另外，各功能单元、模块的具体名称也只是为了便于相互区分，并不用于限制本申请的保护范围。上述系统中单元、模块的具体工作过程，可以参考前述方法实施例中的对应过程，在此不再赘述。

在上述实施例中，对各个实施例的描述都各有侧重，某个实施例中没有详述或记载的部分，可以参见其它实施例的相关描述。

本领域普通技术人员可以意识到，结合本文中所公开的实施例描述的各示例的单元及算法步骤，能够以电子硬件、或者计算机软件和电子硬件的结合来实现。这些功能究竟以硬件还是软件方式来执行，取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本申请的范围。

在本申请所提供的实施例中，应该理解到，所揭露的装置/计算机设备和方法，可以通过其它的方式实现。例如，以上所描述的装置/计算机设备实施例仅仅是示意性的，例如，模块或单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通讯连接可以是通过一些接口，装置或单元的间接耦合或通讯连接，可以是电性，机械或其它的形式。

作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。

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

集成的模块/单元如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读存储介质中。基于这样的理解，本申请实现上述实施例方法中的全部或部分流程，也可以通过计算机程序来指令相关的硬件来完成，计算机程序可以存储在计算机可读存储介质中，该计算机程序在被处理器执行时，可以实现上述各个方法实施例的步骤。计算机程序可以包括计算机程序代码，计算机程序代码可以为源代码形式、对象代码形式、可执行文件或某些中间形式等。计算机可读介质可以包括：能够携带计算机程序代码的任何实体或装置、记录介质、U盘、移动硬盘、磁碟、光盘、计算机存储器、只读存储器(Read-Only Memory，ROM)、随机存取存储器(Random Access Memory，RAM)、电载波信号、电信信号以及软件分发介质等。需要说明的是，计算机可读介质包含的内容可以根据司法管辖区内立法和专利实践的要求进行适当的增减，例如，在某些司法管辖区，根据立法和专利实践，计算机可读介质不包括电载波信号和电信信号。

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

Claims (10)

1.一种驾驶员监控系统的能耗控制方法，其特征在于，包括：

响应于对预设的监听事件的触发操作，对预先封装在前台应用或智能感知应用程序中的能耗控制信号生成方法进行调用；

利用所述能耗控制信号生成方法生成与所述监听事件相对应的能耗控制信号，将所述能耗控制信号通过所述智能感知应用程序中设置的通信模块传递给智能感知服务程序；

利用安装在所述智能感知服务程序中的算法库对所述能耗控制信号进行识别，以确定所述监听事件对应的信号处理规则，依据预定的所述信号处理规则，对驾驶员监控系统内的智能感知识别算法的识别信号对象进行调整，以便对所述驾驶员监控系统的性能消耗进行控制。

2.根据权利要求1所述的方法，其特征在于，所述监听事件包括前台应用事件以及休眠事件，所述监听事件的触发操作，包括：

当监听到至少一个应用程序处于前台时，对所述前台应用事件进行触发，当监听到Android系统的休眠广播、摄像头状态满足预设条件和/或车身状态满足预设条件时，对所述休眠事件进行触发。

3.根据权利要求2所述的方法，其特征在于，所述对预先封装在前台应用或智能感知应用程序中的能耗控制信号生成方法进行调用，包括：

当触发所述前台应用事件时，对所述前台应用的通信工具包中预先封装的前台应用能耗控制信号生成方法进行调用，当触发所述休眠事件时，对所述智能感知应用程序的通信工具包中预先封装的休眠能耗控制信号生成方法进行调用。

4.根据权利要求3所述的方法，其特征在于，所述利用所述能耗控制信号生成方法生成与所述监听事件相对应的能耗控制信号，包括：

当所述监听事件为前台应用事件时，利用所述前台应用能耗控制信号生成方法生成与所述前台应用事件相对应的前台应用能耗控制信号，当所述监听事件为休眠事件时，利用所述休眠能耗控制信号生成方法生成与所述休眠事件相对应的休眠能耗控制信号。

5.根据权利要求4所述的方法，其特征在于，所述利用安装在所述智能感知服务程序中的算法库对所述能耗控制信号进行识别，以确定所述监听事件对应的信号处理规则，包括：

当所述监听事件为前台应用事件时，利用所述智能感知服务程序中的算法库对所述前台应用能耗控制信号进行识别，依据识别结果确定所述前台应用事件对应的信号处理规则；

当所述监听事件为休眠事件时，利用所述智能感知服务程序中的算法库对所述休眠能耗控制信号进行识别，依据识别结果确定所述休眠事件对应的信号处理规则。

6.根据权利要求5所述的方法，其特征在于，所述依据预定的所述信号处理规则，对驾驶员监控系统内的智能感知识别算法的识别信号对象进行调整，包括：

当所述监听事件为前台应用事件时，依据预定的所述前台应用事件对应的信号处理规则，利用所述智能感知识别算法对所述前台应用对应的预设手势信号进行处理，并对其他手势信号进行忽略。

7.根据权利要求5所述的方法，其特征在于，所述依据预定的所述信号处理规则，对驾驶员监控系统内的智能感知识别算法的识别信号对象进行调整，包括：

当所述监听事件为休眠事件时，依据预定的所述休眠事件对应的信号处理规则，使所述智能感知识别算法停止对所述智能感知应用程序的手势信号进行处理，并将所述智能感知识别算法的计算资源进行释放。

8.一种驾驶员监控系统的能耗控制装置，其特征在于，包括：

调用模块，被配置为响应于对预设的监听事件的触发操作，对预先封装在前台应用或智能感知应用程序中的能耗控制信号生成方法进行调用；

生成模块，被配置为利用所述能耗控制信号生成方法生成与所述监听事件相对应的能耗控制信号，将所述能耗控制信号通过所述智能感知应用程序中设置的通信模块传递给智能感知服务程序；

调整模块，被配置为利用安装在所述智能感知服务程序中的算法库对所述能耗控制信号进行识别，以确定所述监听事件对应的信号处理规则，依据预定的所述信号处理规则，对驾驶员监控系统内的智能感知识别算法的识别信号对象进行调整，以便对所述驾驶员监控系统的性能消耗进行控制。

9.一种电子设备，包括存储器，处理器及存储在存储器上并可在处理器上运行的计算机程序，其特征在于，所述处理器执行所述计算机程序时实现如权利要求1至7中任一项所述的方法。

10.一种计算机可读存储介质，所述计算机可读存储介质存储有计算机程序，其特征在于，所述计算机程序被处理器执行时实现如权利要求1至7中任一项所述的方法。