CN116027878A - 功耗调整方法和电子设备 - Google Patents

Abstract

本申请实施例提供了一种功耗调整方法和电子设备，该方法由电子设备执行，电子设备中运行第一APP，第一APP包括多个运行场景，该方法包括：确定电子设备的当前系统负载；确定第一APP当前的运行场景；根据当前系统负载和第一APP当前的运行场景确定目标功耗调整策略；根据目标功耗调整策略调整电子设备的功耗。该方法能够降低电子设备的功耗。

Description

功耗调整方法和电子设备

本申请要求于2022年05月16日提交国家知识产权局、申请号为202210529447.2、申请名称为“功耗调度方法和电子设备”的中国专利申请的优先权，其全部内容通过引用结合在本申请中。

技术领域

本申请涉及电子技术领域，具体涉及一种功耗调整方法和电子设备。

背景技术

现如今，电子设备已成为人们日常生活和工作中必不可少的物品。电子设备电池的长续航时间能给用户带来不一样的体验。

电子设备中安装的一些应用程序(application，APP)，在运行过程中存在功耗较高的问题。例如，为了获知电子设备的电池续航时间，用户会在电子设备中安装测评APP。然而，测评APP测试时运行时间长，且运行的过程电子设备存在功耗较高的问题，因而导致电池续航时间变短，严重影响用户体验。

发明内容

本申请提供了一种功耗调整方法和电子设备，能够降低电子设备功耗，延长电池续航时间。

第一方面，本申请提供一种功耗调整方法，该方法由电子设备执行，电子设备中运行第一APP，第一APP包括多个运行场景，该方法包括：确定电子设备的当前系统负载；确定第一APP当前的运行场景；根据当前系统负载和第一APP当前的运行场景确定目标功耗调整策略；根据目标功耗调整策略调整电子设备的功耗。

可选的，第一APP例如可以为测评APP。第一APP包括多个运行场景，也即第一APP能够运行于多个运行场景。

示例性的，第一APP为测评APP时，多个运行场景可以包括：测评主场景、网页浏览场景、视频场景、办公场景、空闲场景和默认场景等。其中，测评主场景是指测评APP的窗口为焦点窗口的场景，也即测评APP在前台运行，且用户可以在测评APP的窗口中通过鼠标、键盘或触摸屏等执行操作。网页浏览场景也称为模拟网页浏览场景，是指测评APP模拟用户通过预设的浏览器APP浏览网页的场景，该场景下，预设的浏览器APP的窗口为焦点窗口。视频场景也称为模拟视频场景。视频场景可以为应用视频场景，也可以为网页视频场景。应用视频场景是指测评APP模拟用户通过预设的视频播放APP观看视频的场景，该场景下，预设的视频播放APP的窗口为焦点窗口。网页视频场景，也称为模拟网页视频场景，是指测评APP模拟用户通过预设的浏览器APP观看视频的场景，该场景下，预设的浏览器APP的窗口为焦点窗口。办公场景也称为模拟办公场景，是指测评APP模拟用户通过预设的办公APP办公的场景，该场景下，预设的办公APP的窗口为焦点窗口。空闲场景，也称为模拟空闲场景，是指测评APP模拟用户对电子设备无任何操作，但是电子设备处于运行状态的场景。默认场景是指除上述几种运行场景之外，测评APP的其他运行场景。

可选的，电子设备可以包括场景识别引擎。场景识别引擎包括系统探针模块、场景识别模块、策略匹配管理器等。电子设备可以通过系统探针模块获取系统负载，通过场景识别模块确定第一APP当前的运行场景，策略匹配管理器根据系统负载和第一APP当前的运行场景匹配确定目标功耗调整策略。

目标功耗调整策略是指与当前系统负载和第一APP当前的运行场景对应的功耗调整策略。目标功耗调整策略用于指示调整电子设备的功耗。

本申请第一方面提供的功耗调度方法，在电子设备中运行第一APP的情况下，通过确定电子设备的系统负载和第一APP当前的运行场景，根据当前系统负载和第一APP当前的运行场景确定目标功耗调整策略，进而根据目标功耗调整策略调整电子设备的功耗，这样使得电子设备能够结合当前运行场景动态的调整功耗，降低电子设备在运行第一APP过程中的功耗，延长续航时间，提高用户体验。而且，该方法确定目标功耗调整策略时不仅考虑了第一APP当前的运行场景，而且考虑了当前系统负载的情况，从而在降低功耗的同时减小对系统中正在运行的进程的影响，保证了系统的流畅性，进一步提高用户体验。

一种可能的实现方式中，确定第一APP当前的运行场景，包括：获取当前焦点进程；当前焦点进程是指当前时刻电子设备中的焦点进程，焦点进程是指电子设备创建焦点窗口的线程所属的进程；根据当前焦点进程确定第一APP当前的运行场景。

具体的，焦点进程也即电子设备的焦点窗口对应的进程，焦点窗口能够体现第一APP的运行场景。因而，该实现方式中，根据当前焦点进程能够简单、快速的确定第一APP当前的运行场景，提高功耗调整的效率。

一种可能的实现方式中，根据当前焦点进程确定第一APP当前的运行场景，包括：若当前焦点进程为第一APP的进程，则确定第一APP当前的运行场景为多个场景中的第一场景；第一场景是指第一APP的窗口为焦点窗口的场景；若当前焦点进程不为第一APP的进程，则获取后台进程，并根据后台进程确定第一APP当前的运行场景，后台进程是指电子设备当前在后台运行的进程。

示例性的，第一APP为测评APP的情况下，第一场景可以为测评主场景。

可选的，可以通过系统探针模块获取焦点窗口事件，焦点窗口事件中携带有当前焦点进程的名称。场景识别模块将当前焦点进程的名称与第一APP的进程名称对比，确定当前焦点进程是否为焦点进程。若当前焦点进程为第一APP的进程，说明第一APP当前的运行场景为第一场景，否则说明第一APP当前的运行场景不为第一场景，进一步获取后台进程，根据后台进程确定第一APP当前的运行场景。

可选的，电子设备可以通过系统探针模块获取后台进程。

一种可能的实现方式中，根据后台进程确定第一APP当前的运行场景，包括：若后台进程中存在第一APP的进程，且当前焦点进程为第二APP的进程，则确定第一APP当前的运行场景为多个运行场景中的第二场景；第二APP为第一APP预设的运行于第二场景时所使用的APP。

可选的，后台进程可以以列表的形式体现，列表中可以包括后台运行的所有进程的名称。场景识别模块可以查询该列表中是否存在第一APP的进程的名称，若是，则说明后台进程中存在第一APP的进程。后台进程中存在第一APP的进程，说明第一APP运行于系统后台，进一步当前焦点进程是否为第二APP的进程。

示例性的，第一APP为测评APP的情况下，第二场景可以为办公场景。第二APP可以为一个，也可以为多个。可选的，可以预先建立第二APP进程名单，第二APP进程名单中包括所有第二APP的进程的信息。进程信息例如可以包括进程名称。场景识别模块可以将当前焦点进程的名称与第二APP进程名单对比，确定第二APP进程名单中是否存在当前焦点进程的名称，若是，则确定当前焦点进程为第二APP的进程。

该实现方式中，第一APP运行于第二场景时，第一APP运行于后台，且焦点窗口为第二场景对应的第二APP，因而，在确定后台进程中存在第一APP的进程，且当前焦点进程为第二APP的进程时，确定第一APP运行于第二场景。该实现方式能够准确的识别第二场景，提高运行场景识别的准确性，进而提高功耗调整的准确性。

一种可能的实现方式中，第二场景为办公场景，第二APP为预设的办公APP。

可选的，预设的办公APP可以为一个，也可以为多个。在一个具体的实施例中，预设的办公APP例如可以包括

和钉钉

等中的至少一个。

可以预先建立办公进程名单，办公进程名单中包括第一APP预设的运行于办公场景所使用的所有APP的进程名称。场景识别模块可以将当前焦点进程的名称与办公进程名单进行对比，若办公进程名单中包括当前焦点进程的名称，则确定当前焦点进程为预设的办公APP的进程，确定第一APP当前的运行场景为办公场景。

一种可能的实现方式中，根据后台进程确定第一APP当前的运行场景，包括：若后台进程中存在第一APP的进程，且当前焦点进程为第三APP的进程，且满足第一预设条件，则确定第一APP当前的运行场景为多个运行场景中的第三场景；第三APP为第一APP预设的运行于第三场景时所使用的APP。

示例性的，第一APP为测评APP的情况下，第三场景可以为网页浏览场景或视频场景。第一预设条件与第三场景唯一对应。第三APP可以为一个，也可以为多个。可选的，可以预先建立第三APP进程名单，第三APP进程名单中包括所有第三APP的进程的信息。进程信息例如可以包括进程名称。场景识别模块可以将当前焦点进程的名称与第三APP进程名单对比，确定第三APP进程名单中是否存在当前焦点进程的名称，若是，则确定当前焦点进程为第三APP的进程。

该实现方式中，第一APP运行于第三场景时，第一APP运行于后台，焦点窗口为第三场景对应的第三APP，且电子设备满足与第三场景对应的第一预设条件。因而，在确定后台进程中存在第一APP的进程，当前焦点进程为第三APP的进程，且满足第一预设条件时，确定第一APP运行于第三场景。该实现方式能够准确的识别第三场景，提高运行场景识别的准确性，进而提高功耗调整的准确性。

一种可能的实现方式中，第三场景为网页浏览场景，第三APP为预设的浏览器APP，第一预设条件为电子设备中不存在音视频事件。

一种可能的实现方式中，第三APP为预设的浏览器APP，第一预设条件为电子设备中存在音视频事件。

可选的，预设的浏览器APP可以为一个，也可以为多个。在一个具体的实施例中，预设的浏览器APP例如可以包括谷歌

浏览器和火狐

浏览器等中的至少一个。

可以预先建立浏览器进程名单，浏览器进程名单中包括第一APP预设的运行于网页浏览场景所使用的所有APP的进程名称。场景识别模块可以将当前焦点进程的名称与浏览器进程名单进行对比，若浏览器进程名单中包括当前焦点进程的名称，则确定当前焦点进程为预设的浏览器APP的进程。

另外，可以通过系统探针模块确定电子设备中是否存在音视频事件。若当前焦点进程为预设的浏览器APP的进程，且不存在音视频事件，则确定第一APP当前的运行场景为网页浏览场景。若当前焦点进程为预设的浏览器APP的进程，且存在音视频事件，则确定第一APP当前的运行场景为网页视频场景。

一种可能的实现方式中，第三场景为应用视频场景，第三APP为预设的视频播放APP，第一预设条件为电子设备中存在音视频事件。

可选的，预设的视频播放APP可以为一个，也可以为多个。在一个具体的实施例中，预设的视频播放APP例如可以包括爱奇艺

、腾讯视频

和优酷

等视频播放器中的至少一个。

可以预先建立视频播放器进程名单，视频播放器进程名单中包括第一APP预设的运行于应用视频场景所使用的所有APP的进程名称。场景识别模块可以将当前焦点进程的名称与视频播放器进程名单进行对比，若视频播放器进程名单中包括当前焦点进程的名称，则确定当前焦点进程为预设的视频播放APP的进程。

若当前焦点进程为预设的浏览器APP的进程，且存在音视频事件，则确定第一APP当前的运行场景为应用视频场景。

一种可能的实现方式中，根据后台进程确定第一APP当前的运行场景，包括：若后台进程中存在第一APP的进程，且满足第二预设条件，则确定第一APP当前的运行场景为多个运行场景中的第四场景。

示例性的，第一APP为测评APP的情况下，第三场景可以为空闲场景。第二预设条件与第四场景唯一对应。

该实现方式中，第一APP运行于第四场景时，第一APP运行于后台，且电子设备满足与第四场景对应的第二预设条件。因而，在确定后台进程中存在第一APP的进程，且满足第二预设条件时，确定第一APP运行于第四场景。该实现方式能够准确的识别第四场景，提高运行场景识别的准确性，进而提高功耗调整的准确性。

一种可能的实现方式中，第四场景为空闲场景，第二预设条件用于表征用户对电子设备无任何操作。可选的，第二预设条件可以包括：电子设备中不存在外设事件，且电子设备的屏幕状态为亮屏解锁状态，且电子设备的中央处理器(central processing unit，CPU)的利用率小于第一阈值，电子设备的图形处理器(graphics processingunit，GPU)的利用率小于第二阈值，且电子设备的磁盘读写速度小于第三阈值。

一种可能的实现方式中，若第一APP当前的运行场景不为上述第一场景、第二场景、第三场景和第四场景中的任一种，则确定第一APP当前的运行场景为默认场景。

上述实现方式中，根据第一APP运行于不同运行场景下电子设备中信息、事件等的不同，基于当前焦点进程、后台进程、第一预设条件和第二预设条件识别等设置不同的识别条件，从而能够准确的识别出第一APP当前的运行场景，提高功耗调整的准确性。

一种可能的实现方式中，目标功耗调整策略包括第一目标功耗调整策略和第二目标功耗调整策略，第一目标功耗调整策略用于指示调整电子设备的CPU的功耗参数，第二目标功耗调整策略用于指示调整电子设备中模块的工作状态。

其中，电子设备中的模块可以为能耗模块，例如CPU、GPU等。工作状态可以包括运行进程所绑定的CPU的核的类型、显示所采用的GPU的类型、GPU的工作模式、多媒体类计划程序服务(multimedia class scheduler service，MMCSS)的工作模式、CPU的最小处理器状态的百分比和CPU输出的频率信号的占空比等中的至少一种。

该实现方式中，通过第一目标功耗调整策略调整CPU的功耗参数，降低CPU功耗，且通过第二目标功耗策略调整电子设备中能耗模块的工作状态，使得电子设备中能耗模块能够结合当前运行场景下的实际需求运行，减少性能过剩的情况，从而达到降低电子设备功耗的效果。

一种可能的实现方式中，根据当前系统负载和第一APP当前的运行场景确定目标功耗调整策略，包括：根据当前系统负载确定当前系统负载等级；根据当前系统负载等级和第一APP当前的运行场景，以及第一对应关系确定第一目标功耗调整策略；第一对应关系中包括多个系统负载等级、多个运行场景与多个第一功耗调整策略的对应关系，多个第一功耗调整策略中包括第一目标功耗调整策略；根据第一APP当前的运行场景，以及第二对应关系确定第二目标功耗调整策略；第二对应关系中包括多个运行场景与多个第二功耗调整策略的对应关系，多个第二功耗调整策略中包括第二目标功耗调整策略。

其中，系统负载等级用于表征系统负载的轻重程度。可选的，系统负载等级可以包括重、中和轻三种等级。

可选的，场景识别引擎还可以包括负载管控器，负载管控器可以从系统探针模块获取当前系统负载，并根据当前系统负载确定当前系统负载等级。在一个具体的实施例中，负载管控器可以根据预设的映射关系，确定当前系统负载对应的当前系统负载等级。

该实现方式中，根据当前系统负载等级和第一APP当前的运行场景，以及第一对应关系确定第一目标功耗调整策略，不仅考虑了第一APP当前的运行场景，而且考虑了当前系统负载等级，从而在降低CPU功耗的同时减小对系统中正在运行的进程的影响，保证了系统的流畅性，进一步提高用户体验。另外，基于第一对应关系和第二对应关系分别确定第一目标功耗调整策略和第二功耗调整策略，简单、方便，而且使得每一种运行场景下对应的第一功耗调整策略和第二功耗调整策略唯一且确定，提高功耗调整策略输出的效率和准确率。

一种可能的实现方式中，CPU的功耗参数包括CPU的长时睿频功耗(power limit1，PL1)、CPU的短时睿频功耗(power limit1，PL2)以及CPU的能效比(energy performancepreference，EPP)中的至少一个。

也就是说，第一目标功耗调整策略用于调整CPU的PL1、PL2和EPP中的至少一个，通过第一目标功耗调整策略实现了对CPU功耗的直接调整，降低CPU功耗，延长电子设备的续航时间。

一种可能的实现方式中，第一APP的当前运行场景为多个运行场景中的第一场景的情况下，第二目标功耗调整策略用于指示将第一APP的进程绑定在CPU的小核上运行；第一场景是指第一APP的窗口为焦点窗口的场景。

示例性的，第一APP为测评APP的情况下，第一场景可以为测评主场景。

一般的，APP的进程运行在CPU的大核上，即通过CPU大核运行APP的线程。考虑到运行第一APP(测评APP)时无需用户参与，不会影响用户操作，因而，该实现方式中，第一场景(测评主场景)下对应的第二目标功耗调整策略将第一APP(测评APP)的进程绑定在CPU的小核上运行，节约CPU功耗。

一种可能的实现方式中，第一APP的当前运行场景为多个运行场景中的网页浏览场景的情况下，第二目标功耗调整策略用于指示采用集成显卡显示，并调整集成显卡的工作模式为节能模式。

一般的，电子设备在运行网页浏览的APP(浏览器APP)的进程时采用独立显卡，或者采用集成显卡但是集成显卡运行在平衡模式或高性能模式。考虑到运行第一APP(测评APP)时无需用户参与，不需要过优的显示效果。因而，该实现方式中，网页浏览场景下对应的第二目标功耗调整策略采用集成显卡显示，并将集成显卡工作模式调整为节能模式，从而节约GPU功耗。

一种可能的实现方式中，第一APP当前的运行场景为多个运行场景中的网页视频场景的情况下，第二目标功耗调整策略用于指示采用集成显卡显示，调整集成显卡的工作模式为节能模式，并将MMCSS的工作模式设置为节能模式。

同上，电子设备在运行浏览器APP的进程时采用独立显卡，或者采用集成显卡但是集成显卡运行在平衡模式或高性能模式。考虑到运行第一APP(测评APP)时无需用户参与，不需要过优的显示效果。因而，该实现方式中，网页视频场景下对应的第二目标功耗调整策略采用集成显卡显示，并将集成显卡工作模式调整为节能模式，从而节约GPU功耗。而且，电子设备一般在播放视频时，MMCSS采用平衡模式或最高性能模式。考虑到运行第一APP(测评APP)时无需用户参与，不需要过优的音视频效果。因而，网页视频场景下对应的第二目标功耗调整策略还可以将MMCSS设置为节能模式，从而节约功耗。

一种可能的实现方式中，第一APP当前的运行场景为多个运行场景中的应用视频场景的情况下，第二目标功耗调整策略用于指示将MMCSS的工作模式设置为节能模式。

同上，电子设备一般在播放视频时，MMCSS采用平衡模式或最高性能模式。考虑到运行第一APP(测评APP)时无需用户参与，不需要过优的音视频效果。因而，应用视频场景下对应的第二目标功耗调整策略可以将MMCSS设置为节能模式，从而节约功耗。

一种可能的实现方式中，第一APP当前的运行场景为多个运行场景中的空闲场景的情况下，第二目标功耗调整策略用于指示减小CPU的最小处理器状态的百分比，并减小CPU输出的频率信号的占空比。

一般的，系统默认CPU最小处理器状态百分比为5％(即CPU最少采用5％核运行)。在空闲场景下，CPU采用5％核运行存在资源浪费，因而，空闲场景下对应的第二目标功耗调整策略将CPU最小处理器状态百分比减小，减少资源浪费，降低功耗。同时，空闲场景下，用户对电子设备无操作，CPU的运行频率无需过高，因而第二目标功耗调整策略还通过减小CPU输出的频率信号的占空比降低CPU运行频率，降低CPU功耗。

一种可能的实现方式中，减小CPU的最小处理器状态的百分比包括：减小CPU的最小处理器状态的百分比至0。这样能够避免资源浪费，将功耗降至最低。

第二方面，本申请提供一种装置，该装置包含在电子设备中，该装置具有实现上述第一方面及上述第一方面的可能实现方式中电子设备行为的功能。功能可以通过硬件实现，也可以通过硬件执行相应的软件实现。硬件或软件包括一个或多个与上述功能相对应的模块或单元。例如，接收模块或单元、处理模块或单元等。

第三方面，本申请提供一种电子设备，电子设备包括：处理器、存储器和接口；处理器、存储器和接口相互配合，使得电子设备执行第一方面的技术方案中任意一种方法。

第四方面，本申请提供一种芯片，包括处理器。处理器用于读取并执行存储器中存储的计算机程序，以执行第一方面及其任意可能的实现方式中的方法。

可选的，芯片还包括存储器，存储器与处理器通过电路或电线连接。

进一步可选的，芯片还包括通信接口。

第五方面，本申请提供一种计算机可读存储介质，计算机可读存储介质中存储了计算机程序，当计算机程序被处理器执行时，使得该处理器执行第一方面的技术方案中任意一种方法。

第六方面，本申请提供一种计算机程序产品，计算机程序产品包括：计算机程序代码，当计算机程序代码在电子设备上运行时，使得该电子设备执行第一方面的技术方案中任意一种方法。

附图说明

图1是本申请实施例提供的一例电子设备100的结构示意图；

图2是本申请实施例提供的一例电子设备100的软件结构框图；

图3是本申请实施例提供的一例电子设备100对功耗进行调整的软件及硬件的工作流程示意图；

图4是本申请实施例提供的一例识别测评APP的运行场景的方法流程示意图；

图5是本申请实施例提供的一例确定DTT策略号和EPO策略号方法的流程示意图；

图6是本申请实施例提供的一例功耗调整方法的流程示意图；

图7是本申请实施例提供的一例界面示意图；

图8是本申请实施例提供的另一例功耗调整方法的流程示意图；

图9是本申请实施例提供的又一例功耗调整方法的流程示意图；

图10是本申请实施例提供的又一例功耗调整方法的流程示意图；

图11是本申请实施例提供的一例芯片系统的结构示意图。

具体实施方式

下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行描述。其中，在本申请实施例的描述中，除非另有说明，“/”表示或的意思，例如，A/B可以表示A或B；本文中的“和/或”仅仅是一种描述关联对象的关联关系，表示可以存在三种关系，例如，A和/或B，可以表示：单独存在A，同时存在A和B，单独存在B这三种情况。另外，在本申请实施例的描述中，“多个”是指两个或多于两个。

以下，术语“第一”、“第二”、“第三”仅用于描述目的，而不能理解为指示或暗示相对重要性或者隐含指明所指示的技术特征的数量。由此，限定有“第一”、“第二”、“第三”的特征可以明示或者隐含地包括一个或者更多个该特征。

在本申请说明书中描述的参考“一个实施例”或“一些实施例”等意味着在本申请的一个或多个实施例中包括结合该实施例描述的特定特征、结构或特点。由此，在本申请说明书中的不同之处出现的语句“在一个实施例中”、“在一些实施例中”、“在其他一些实施例中”、“在另外一些实施例中”等不是必然都参考相同的实施例，而是意味着“一个或多个但不是所有的实施例”，除非是以其他方式另外特别强调。术语“包括”、“包含”、“具有”及它们的变形都意味着“包括但不限于”，除非是以其他方式另外特别强调。

为更好地理解本申请实施例，以下对实施例中可能涉及的术语或概念进行解释说明。

长时睿频功耗(power limit1，PL1)，指CPU在正常负载下的功耗，相当于热设计功耗，CPU绝大部分时间的运行功耗不超过PL1。

短时睿频功耗(power limit2，PL2)，指CPU在短时间内可达到的最高功耗，其具有持续时间限制。一般地，PL2大于PL1。

CPU能效比(energy performance preference，EPP)，用于反映CPU的功耗调整的倾向，其取值范围为0～255。CPU能效比越小，则表明CPU趋向于高性能；CPU能效比越高，则表明CPU趋向于低功耗。

焦点窗口(focus window)，指拥有焦点的窗口。焦点窗口是唯一可以接收键盘输入的窗口。焦点窗口的确定方式与系统的焦点模式(focus mode)关联。焦点窗口的顶层窗口被称为活动窗口(active window)。同一时间只有一个窗口可以是活动窗口。焦点窗口大概率为用户当前需要使用的窗口。

焦点模式，可用于决定鼠标如何使一个窗口获得焦点。一般地，焦点模式可包括三种，分别为：

(1)点击聚焦(click-to focus)，在这种模式下，鼠标点击的窗口即可获得焦点。即当鼠标点击一个可以获得焦点的窗口的任意位置，即可激活该窗口，该窗口便被置于所有窗口的最前面，并接收键盘输入。当鼠标点击其他窗口时，该窗口会失去焦点。

(2)焦点跟随鼠标(focus-follow-mouse)，在这种模式下，鼠标下的窗口可以获取焦点。即当鼠标移到一个可以获得焦点的窗口的范围内，用户不需要点击窗口的某个地方就可以激活这个窗口，接收键盘输入，但该窗口不一定被置于所有窗口的最前面。当鼠标移出这个窗口的范围时，这个窗口也会随之失去焦点。

(3)草率聚焦(sloppy focus)，这种焦点模式与focus-follow-mouse比较类似：当鼠标移到一个可以获得焦点的窗口的范围内，用户不需要点击窗口的某个地方就可以激活这个窗口，接收键盘输入，但该窗口不一定被置于所有窗口的最前面。与focus-follow-mouse不同的是，当鼠标移出这个窗口范围时，焦点并不会随之改变，只有当鼠标移动到别的可以接收焦点的窗口时，系统焦点才改变。

进程包括多个线程，线程可以创建窗口。焦点进程为创建焦点窗口的线程所属的进程，下述实施例中，也称为焦点窗口对应的进程。

转译，指对某个形式的数据或信息进行转换处理，得到另一个形式的数据或信息，该另一个形式的数据或信息可以被指定平台所识别。例如，电子设备可以对获得的策略参数进行转译，得到某一类型的CPU芯片平台能够识别的参数。

下面对本申请所要解决的技术问题进行说明。

电子设备电池的续航时间是用户使用电子设备过程中的重要关注点。为了获知电子设备电池续航时间和性能，用户会在电子设备中安装测评APP。测评APP，也称为性能测试APP、性能评估APP或性能测评APP等，是指用于测试和评估电子设备的综合性能(例如包括电池续航能力、处理器性能、图形性能、硬盘性能、内存性能等)的APP。一般的，测评APP在测试续航时间时，会在电子设备上处理不同的业务以模拟用户不同的使用场景，进而测试电子设备在不同场景下的相关性能，最终得到续航时间测评结果。也就是说，测评APP通过运行多种运行场景来模拟用户的多种使用场景，进而测试电子设备的续航时间。

然而，测评APP测试电池续航时间时，APP需要运行较长时间，且测评APP本身的运行也会存在功耗浪费的情况，因而导致电子设备电池续航时间变短，降低用户体验。

而且，发明人发现，除了测评APP之外，还存在一些其他的APP，其运行过程中也会涉及不同的运行场景。这些APP运行过程中都存在功耗浪费的问题，有待改进。因此，本申请实施例提供一种功耗调整方法，主要针对运行过程中包括不同运行场景的APP，在电子设备中运行有这些APP的情况下，识别这些APP的运行场景，根据运行场景生成相应的功耗调整策略(也可称为功耗调度策略)，从而实现对功耗的动态调整，降低电子设备运行这些APP过程中的功耗，延长续航时间，提高用户体验。

为了便于说明，本申请下述实施例中以测评APP为例进行说明，运行过程中包括不同运行场景的其他APP与此类似，不作赘述。

本申请实施例提供的功耗调整方法可以应用于笔记本电脑、超级移动个人计算机(ultra-mobile personal computer，UMPC)、上网本、个人数字助理(personal digitalassistant，PDA)、手机、平板电脑、可穿戴设备、车载设备、增强现实(augmented reality，AR)/虚拟现实(virtual reality，VR)设备等可以安装APP的电子设备上，本申请实施例对电子设备的具体类型不作任何限制。

示例性的，图1是本申请实施例提供的一例电子设备100的结构示意图。电子设备100可以包括处理器110，外部存储器接口120，内部存储器121，通用串行总线(universalserial bus，USB)接口130，充电管理模块140，电源管理模块141，电池142，无线通信模块150，显示屏160等。

可以理解的是，本实施例示意的结构并不构成对电子设备100的具体限定。在另一些实施例中，电子设备100可以包括比图示更多或更少的部件，或者组合某些部件，或者拆分某些部件，或者不同的部件布置。图示的部件可以以硬件，软件或软件和硬件的组合实现。

处理器110可以包括一个或多个处理单元，例如：处理器110可以包括应用处理器(application processor，AP)，调制解调处理器，GPU，图像信号处理器(image signalprocessor，ISP)，控制器，存储器，视频编解码器，数字信号处理器(digital signalprocessor，DSP)，基带处理器，和/或神经网络处理器(neural-network processing unit，NPU)等。其中，不同的处理单元可以是独立的器件，也可以集成在一个或多个处理器中。

控制器可以是电子设备100的神经中枢和指挥中心。控制器可以根据指令操作码和时序信号，产生操作控制信号，完成取指令和执行指令的控制。

处理器110中还可以设置存储器，用于存储指令和数据。在一些实施例中，处理器110中的存储器为高速缓冲存储器。该存储器可以保存处理器110刚用过或循环使用的指令或数据。如果处理器110需要再次使用该指令或数据，可从所述存储器中直接调用。避免了重复存取，减少了处理器110的等待时间，因而提高了系统的效率。

在一些实施例中，处理器110可以包括一个或多个接口。接口可以包括I2C接口，集成电路内置音频(inter-integrated circuit sound，I2S)接口，脉冲编码调制(pulsecodemodulation，PCM)接口，通用异步收发传输器(universal asynchronous receiver/transmitter，UART)接口，移动产业处理器接口(mobile industry processor interface，MIPI)，通用输入输出(general-purpose input/output，GPIO)接口，用户标识模块(subscriber identity module，SIM)接口，和/或USB接口等。

可以理解的是，本实施例示意的各模块间的接口连接关系，只是示意性说明，并不构成对电子设备100的结构限定。在另一些实施例中，电子设备100也可以采用上述实施例中不同的接口连接方式，或多种接口连接方式的组合。

充电管理模块140用于从充电器接收充电输入。其中，充电器可以是无线充电器，也可以是有线充电器。充电管理模块140为电池142充电的同时，还可以通过电源管理模块141为电子设备供电。

电源管理模块141用于连接电池142，充电管理模块140与处理器110。电源管理模块141接收电池142和/或充电管理模块140的输入，为处理器110，内部存储器121，外部存储器，显示屏160，和无线通信模块150等供电。在一些实施例中，电源管理模块141和充电管理模块140也可以设置于同一个器件中。

无线通信模块150可以提供应用在电子设备100上的包括WLAN(如Wi-Fi)，蓝牙，全球导航卫星系统(global navigation satellite system，GNSS)，调频(frequencymodulation，FM)，近距离无线通信技术(near field communication，NFC)，红外技术(infrared，IR)等无线通信的解决方案。例如，本申请实施例中，电子设备100可以通过无线通信模块150与终端设备(如无线耳机100)建立蓝牙连接。

无线通信模块150可以是集成至少一个通信处理模块的一个或多个器件。无线通信模块150经由天线接收电磁波，将电磁波信号调频以及滤波处理，将处理后的信号发送到处理器110。无线通信模块150还可以从处理器110接收待发送的信号，对其进行调频，放大，经天线转为电磁波辐射出去。

电子设备100通过GPU，显示屏160，以及应用处理器等实现显示功能。GPU为图像处理的微处理器，连接显示屏160和应用处理器。GPU用于执行数学和几何计算，用于图形渲染。处理器110可包括一个或多个GPU，其执行程序指令以生成或改变显示信息。

显示屏160用于显示图像，视频等。该显示屏160包括显示面板。

外部存储器接口120可以用于连接外部存储卡，例如Micro SD卡，实现扩展电子设备100的存储能力。外部存储卡通过外部存储器接口120与处理器110通信，实现数据存储功能。例如将音乐，视频等文件保存在外部存储卡中。

内部存储器121可以用于存储计算机可执行程序代码，所述可执行程序代码包括指令。处理器110通过运行存储在内部存储器121的指令，从而执行电子设备100的各种功能应用以及数据处理。例如，在本申请实施例中，处理器110可以通过执行存储在内部存储器121中的指令，内部存储器121可以包括存储程序区和存储数据区。

其中，存储程序区可存储操作系统，至少一个功能所需的APP(比如声音播放功能，图像播放功能等)等。存储数据区可存储电子设备100使用过程中所创建的数据(比如音频数据，电话本等)等。此外，内部存储器121可以包括高速随机存取存储器，还可以包括非易失性存储器，例如至少一个磁盘存储器件，闪存器件，通用闪存存储器(universalflashstorage，UFS)等。

上述电子设备100的软件系统可以采用分层架构，事件驱动架构，微核架构，微服务架构，或云架构。本发明实施例以分层架构的Windows系统为例，示例性说明电子设备100的软件结构。

示例性的，图2为本申请实施例的一例电子设备100的软件结构框图。

分层架构将软件分成若干个层，每一层都有清晰的角色和分工。层与层之间通过软件接口通信。在一些实施例中，将Windows系统分为用户态和内核态。其中，用户态包括应用层以及子系统动态链接库。内核态自下而上分为固件层、硬件抽象层(hardwareabstraction layer，HAL)、内核和驱动层及执行体。

如图2所示，应用层包括音乐、视频、游戏、办公、社交、测评等APP。应用层还包括环境子系统、场景识别引擎以及调度引擎等。其中，图中仅示出部分APP，应用层还可以包括其他APP，例如购物应用、浏览器等，本申请不做限定。

环境子系统可以将基本的执行体系统服务的某些子集以特定的形态展示给APP，为APP提供执行环境。

场景识别引擎可以识别测评APP当前的运行场景，获取电子设备100的负载情况，并确定与该运行场景和负载情况匹配的第一功耗调整策略。调度引擎可以确定与该运行场景匹配的第二功耗调整策略。其中，关于场景识别引擎和调度引擎的具体内容见后文，在此暂不描述。

子系统动态链接库包括API模块，该API模块包括Windows API，Windows原生API等。其中，Windows API，Windows原生API均可以为APP提供系统调用入口及内部函数支持，区别在于Windows原生API为Windows系统原生的API。例如，Windows API可包括user.dll、kernel.dll，Windows原生API可包括ntdll.dll。其中，user.dll是Windows用户界面接口，可用于执行创建窗口、发送消息等操作。kernel.dll用于为APP提供访问内核的接口。ntdll.dll是重要的Windows NT内核级文件，描述了windows本地NTAPI的接口。当Windows启动时，ntdll.dll就驻留在内存中特定的写保护区域，使别的程序无法占用这个内存区域。

执行体包括进程管理器、虚拟内存管理器、安全引用监视器、I/O管理器、Windows管理规范(Windows management instrumentation，WMI)、电源管理器、系统事件驱动(operating system event driver，OsEventDriver)节点、系统与芯片驱动(operatingsystem to System on Chip，OS2SOC)节点等。

进程管理器用于创建及中止进程和线程。

虚拟内存管理器实现“虚拟内存”。虚拟内存管理器也为高速缓存管理器提供基本的支持。

安全引用监视器可在本地计算机上执行安全策略，它保护了操作系统资源，执行运行时对象的保护和监视。

I/O管理器执行独立于设备的输入/输出，并进一步处理调用适当的设备驱动程序。

电源管理器可管理所有支持电源状态更改的设备的电源状态更改。

系统事件驱动节点可以与内核和驱动层进行交互，例如与显卡驱动进行交互，在确定存在GPU视频解码事件后，向场景识别引擎上报该GPU视频解码事件。

系统与芯片驱动节点可供调度引擎向硬件设备发送调整信息，例如向CPU发送调整PL1和PL2的信息。

内核和驱动层包括内核以及设备驱动程序。

内核是对处理器体系结构的抽象，将执行体与处理器体系结构的差异相隔离，保证系统的可移植性。内核可以进行线程安排和调度、陷阱处理和异常调度、中断处理和调度等。

设备驱动程序运行在内核模式下，为I/O系统和相关硬件之间的接口。设备驱动程序可包括显卡驱动、Intel DTT驱动、鼠标驱动、音视频驱动、摄像头驱动、键盘驱动等。例如，显卡驱动可以驱动GPU运行，Intel DTT驱动可以驱动CPU运行。

HAL是一个核心态模块，可以隐藏各种与硬件有关的细节，例如I/O接口、中断控制器以及多处理器通信机制等，为运行Windows的不同硬件平台提供统一的服务接口，实现多种硬件平台上的可移植性。需要说明的是，为了维护Windows的可移植性，Windows内部组件和用户编写的设备驱动程序并不直接访问硬件，而是通过调用HAL中的例程。

固件层可以包括基本输入输出系统(basic input output system，BIOS)，BIOS是一组固化到计算机主板上一个只读存储器(read only memory，ROM)芯片内的程序，它保存着计算机最重要的基本输入输出的程序、开机后自检程序和系统自启动程序，它可从互补金属氧化物半导体(complementary metal oxide semiconductor，CMOS)中读写系统设置的具体信息。其主要功能是为计算机提供最底层的、最直接的硬件设置和控制。Intel DTT驱动可以通过BIOS向CPU发送指令。

需要说明的是，本申请实施例仅以Windows系统举例来说明，在其他操作系统中(例如安卓系统，IOS系统等)，只要各个功能模块实现的功能和本申请的实施例类似也能实现本申请的方案。

示例性的，图3示出了电子设备100对资源进行调整的软件及硬件的工作流程示意图。

如图3所示，应用层的场景识别引擎包括系统探针模块、场景识别模块、负载管控器及策略匹配管理器。场景识别模块可分别与系统探针模块及策略匹配管理器进行交互。场景识别模块可以向系统探针模块发送获取探针状态的请求。系统探针模块可以获取电子设备100的运行状态。例如，系统探针模块可以包括外设状态探针、音视频状态探针、后台进程扫描探针、屏幕状态探针、磁盘读写(IO)探针、系统负载探针及系统事件探针等，除此之外，系统探针模块还可以包括电源状态探针、进程负载探针等(图未示)。

其中，电源状态探针可以向内核态订阅电源状态事件，根据内核态反馈的回调函数确定电源状态，电源状态包括电池(剩余)电量、电源模式等，电源模式可包括交流电源(alternating current，AC)和直流电源(direct current，DC)。例如，电源状态探针可向执行体层的OsEventDriver节点发送订阅电源状态事件的请求，由OsEventDriver节点向执行体层的电源管理器转发该请求。电源管理器可通过该OsEventDriver节点向电源状态探针反馈回调函数。

外设状态探针可以向内核态订阅外设事件，根据内核态反馈的回调函数确定外设事件。外设事件包括鼠标滚轮滑动事件、鼠标点击事件、键盘输入事件、麦克风输入事件、摄像头输入事件等。

进程负载探针可以向内核态订阅进程负载，根据内核态反馈的回调函数确定进程的负载。

系统负载探针可以向内核态订阅系统负载，根据内核态反馈的回调函数确定系统负载。可选的，系统负载可以通过处于可运行状态的进程和不可中断状态的进程的平均数来表征。可运行状态的进程指正在使用CPU或者等待使用CPU的进程。不可中断状态的进程为等待I/O访问(例如，磁盘I/O)的进程。可选的，系统负载也可以通过CPU的利用率和/或GPU的利用率等来表征。

音视频状态探针可以向内核态订阅音视频事件，根据内核态反馈的回调函数确定电子设备100当前存在的音视频事件。音视频事件可包括GPU解码事件等。例如，音视频状态探针可向执行体层的OsEventDriver节点发送订阅GPU解码事件的请求，由OsEventDriver节点向内核和驱动层的显卡驱动转发该请求。显卡驱动可以监控GPU的状态，在监控到GPU在进行解码操作后，通过该OsEventDriver节点向音视频状态探针反馈回调函数。

后台进程扫描探针可以向内核态订阅后台运行的进程的情况，根据内核态反馈的回调函数确定后台进程中是否存在测评APP对应的进程。

屏幕状态探针可以向内核态订阅屏幕状态，根据内核态反馈的回调函数确定屏幕状态。屏幕状态例如可以包括亮屏解锁状态、锁屏、熄屏等。

磁盘IO探针可以向内核态订阅磁盘IO事件，根据内核态反馈的回调函数确定电子设备100的磁盘的读写事件，包括磁盘的读写速度等。

系统事件探针可以向内核态订阅系统事件，根据内核态反馈的回调函数确定系统事件。系统事件可包括窗口变化事件、进程创建事件、线程创建事件等。例如，系统事件探针可向执行体层的OsEventDriver节点发送订阅进程创建事件的请求，由OsEventDriver节点向进程管理器转发该请求。进程管理器可在创建进程后，通过该OsEventDriver节点向系统事件探针反馈回调函数。又例如，系统事件探针还向API模块发送订阅焦点窗口变化事件，API模块可监控电子设备100的焦点窗口是否发生变化，并在监控到焦点窗口发生变化时，向系统事件探针反馈回调函数。

可见，系统探针模块通过向内核态订阅电子设备100的各种事件，再根据内核态反馈的回调函数确定电子设备100的运行状态，即得到探针状态。系统探针模块得到探针状态后，可向场景识别模块反馈该探针状态。场景识别模块接收到探针状态后，可根据该探针状态确定测评APP的运行场景。

负载管控器可从系统探针模块获取系统负载，并根据系统负载确定系统负载等级。负载管控器可以将系统负载等级发送至策略匹配管理器。

可以理解，测评APP不同，其所能模拟的用户使用场景不同，包括的运行场景不同。在一个具体的实施例中，测评APP的运行场景可以包括：测评主场景、模拟网页浏览场景、模拟网页视频场景、模拟办公场景、模拟空闲(idle)场景和默认场景等。其中，测评主场景是指测评APP运行于前台，用户可以通过鼠标、键盘或触摸屏等操作测评APP。模拟网页浏览场景是指测评APP正在模拟用户通过浏览器浏览网页的场景。类似的，模拟网页视频场景是指测评APP正在模拟用户通过网页观看视频。模拟办公场景是指测评APP正在模拟用户通过办公APP办公。模拟idle场景是指测评APP正在模拟用户对电子设备无任何操作，但是电子设备正在运行的场景。默认场景是指除上述几种运行场景之外测评APP的其他运行场景。

可选的，可以根据测评APP各个运行场景的运行规则，预先设置各个运行场景对应的场景识别条件。场景识别模块根据场景识别条件识别测评APP当前的运行场景，具体参见后续实施例。场景识别模块可以将识别出的测评APP当前的运行场景发送至策略匹配管理器。

策略匹配管理器根据测评APP当前的运行场景和系统负载等级匹配第一功耗调整策略。第一功耗调整策略用于调整CPU的功耗参数(例如PL1、PL2和EPP等)，以调整CPU功耗。策略匹配管理器将测评APP的运行场景和第一功耗调整策略发送至芯片策略融合器。

芯片策略融合器可基于CPU的芯片平台类型，对该第一功耗调整策略进行转译，得到第一功耗调整策略对应的策略号，并将策略号下发至调度执行器。调度执行器可以通过WMI将策略号下发至BIOS，BIOS将策略号下发至CPU，实现对CPU功耗的调整。

同时，芯片策略融合器可以根据测评APP的运行场景匹配第二功耗调整策略。第二功耗调整策略用于调整电子设备的相关硬件(例如CPU、GPU等)的工作模式、工作参数等，以调整电子设备的功耗。例如第二功耗调整策略可用于调整CPU、GPU的工作模式，或者调整多媒体类计划程序服务MMCSS的工作模式等。芯片策略融合器将第二功耗调整策略下发至调度执行器。调度执行器可以通过API模块中的相关接口调用DTT驱动、显卡驱动等执行第二功耗调整策略。

下面对测评APP的各个运行场景对应的场景识别条件及第一功耗调整策略、第二功耗调整策略进行说明。

示例性的，表1为本申请实施例提供的一例测评APP的运行场景、场景识别条件、系统负载等级以及功耗调整策略的对应关系表，其中，功耗调整策略包括第一功耗调整策略和第二功耗调整策略。

表1

需要说明的是，表1仅为一种示例，根据测评APP的不同，APP的运行场景可以不同，场景识别条件和功耗调整策略可以不同，本申请对此不做任何限定。且表1中第一功耗调整策略的编号仅作区分用途，不代表实际的策略内容。

另外，可以理解，表1仅用于示例运行场景、系统负载与第一功耗调整策略及第二功耗调整策略之间的对应关系，实际应用中，该对应关系可以不通过表格形式体现。且当本申请实施例提供的方法通过电子设备中不同的模块交互实现时，相应的模块可以仅获知上述对应关系中的部分，而不必获知上述所有的对应关系。例如，本申请实施例提供的方法通过图3实施例中所示的策略匹配管理器和芯片策略融合器等模块实现时，策略匹配管理器可以仅获知测评APP的各个运行场景、系统负载等级与第一功耗调整策略的对应关系，芯片策略融合器可以仅获知测评APP的各个运行场景与第二功耗调整策略的对应关系。

下面对表1中各个场景识别条件的识别原理，以及对应的功耗调整策略降低功耗的原理进行说明。

首先，由于测评APP可以通过运行不同的APP来模拟用户不同的使用场景，换句话说，测评APP模拟用户不同使用场景所使用的APP不同，因而测评APP在不同的运行场景下，电子设备中运行的APP不同，系统中运行的进程不同。其中，测评APP模拟用户各个使用场景所使用的APP的具体类型可以由测评APP预先设定。也就是说，测评APP运行的各个运行场景会对应预设的APP。测评APP在每个运行场景下打开运行该运行场景对应的预设APP。例如，若测评APP预设的模拟办公场景所使用的APP为

办公APP，则测评APP运行在模拟办公下时，会默认打开

办公APP。

其次，测评APP运行于某些运行场景下，电子设备中会存在一些独有的信息或特征。例如，在模拟网页视频场景下，电子设备中会存在音视频流，再例如，在模拟idle场景下，电子设备中，无外设输入，屏幕状态为亮屏解锁状态，且CPU利用率、GPU利用率和磁盘读写速度均较小。

因而，本申请实施例提供的方法通过识别焦点进程以及每个运行场景下的其他预设条件确定测评APP当前的运行场景。

另外，系统负载等级不同，电子设备所需的功耗不同。因而，本申请实施例提供的方法在识别出测评APP当前的运行场景之后，根据运行场景以及系统负载等级，匹配第一功耗策略，通过第一功耗策略调整CPU功耗参数，以降低CPU功耗。同时，根据运行场景匹配第二功耗调整策略，调整CPU、GPU等的运行模式，以降低电子设备功耗。

具体的，参见表1，在测评主场景下，测评APP未模拟用户使用场景。这种场景下，测评APP运行于前台，用户可以通过鼠标、键盘或触摸屏等操作测评APP，也即，测评APP的窗口为焦点窗口，测评APP的进程为焦点进程。因而，若当前焦点进程为测评APP的进程，则确定测评APP当前的运行场景为测评主场景。

测评主场景下，可以按照系统负载等级的不同，分别预设第一功耗调整策略：策略1-1-1、策略1-1-2和策略1-1-3。策略1-1-1、策略1-1-2和策略1-1-3用于设定PL1、PL2和EPP的值，降低CPU的功耗。另一方面，一般的，APP的进程运行在CPU的大核上，即通过CPU大核运行APP的进程。考虑到测评时无需用户参与，不会影响用户操作，因而，测评主场景下对应的第二功耗调整策略将测评APP的进程绑定在CPU的小核上运行，节约CPU功耗。

参见表1，在模拟网页浏览场景下，测评APP模拟用户通过浏览器浏览网页的场景。这种场景下，测评APP在后台运行，其进程为后台进程，而且，电子设备的焦点窗口为预设的模拟网页浏览所使用的APP的窗口，电子设备的焦点进程为预设的模拟网页浏览所使用的APP的进程。预设的模拟网页浏览所使用的APP例如可以为

浏览器和/或

浏览器等浏览器APP。因而，若后台进程中存在测评APP的进程，且焦点进程为

浏览器和/或

浏览器的进程，则确定测评APP当前的运行场景为模拟网页浏览场景。

模拟网页浏览场景下，可以按照系统负载等级的不同，分别预设第一功耗调整策略：策略1-2-1、策略1-2-2和策略1-2-3。策略1-2-1、策略1-2-2和策略1-2-3用于设定PL1、PL2和EPP的值，降低CPU的功耗。另一方面，一般的，电子设备在运行网页浏览的APP的进程时采用独立显卡，或者采用集成显卡但是集成显卡运行在平衡模式或高性能模式。考虑到测评时无需用户参与，不需要过优的显示效果。因而，该场景下对应的第二功耗调整策略可以采用集成显卡显示，并将集成显卡工作模式调整为节能模式，从而节约GPU功耗。

参见表1，在模拟网页视频场景下，测评APP模拟用户通过浏览器观看视频的场景。这种场景下，测评APP在后台运行，其进程为后台进程，而且，电子设备的焦点窗口为预设的模拟网页视频所使用的APP的窗口，电子设备的焦点进程为预设的模拟网页视频所使用的APP的进程。可选的，测评APP预设的模拟网页浏览所使用的APP和模拟网页视频所使用的APP可以相同，也可以不同。例如，两种场景下对应的预设APP可以均包括

浏览器和/或

浏览器。这两种场景的不同，在于模拟网页视频场景下，电子设备中存在音视频流，即系统中存在音视频事件。因而，若后台进程中存在测评APP的进程，焦点进程为

浏览器和/或

浏览器的进程，且存在音视频事件，则确定测评APP当前的运行场景为模拟网页视频场景。

模拟网页视频场景下，可以按照系统负载等级的不同，分别预设第一功耗调整策略：策略1-3-1、策略1-3-2和策略1-3-3。策略1-3-1、策略1-3-2和策略1-3-3用于设定PL1、PL2和EPP的值，降低CPU的功耗。另一方面，同模拟网页浏览场景，模拟网页视频场景下对应的第二功耗调整策略采用集成显卡显示，并将集成显卡工作模式调整为节能模式，从而节约GPU功耗。而且，电子设备一般在播放视频时，MMCSS采用平衡模式或最高性能模式。考虑到测评时无需用户参与，不需要过优的音视频效果。因而，该场景下对应的第二功耗调整策略还可以将MMCSS设置为节能模式，从而节约功耗。

参见表1，在模拟办公场景下，测评APP模拟用户通过办公APP办公的场景。这种场景下，测评APP在后台运行，其进程为后台进程，而且，电子设备的焦点窗口为预设的模拟办公场景所使用的APP的窗口，电子设备的焦点进程为预设的模拟办公场景所使用的APP的进程。预设的模拟办公场景所使用的APP例如可以为

和/或钉钉

等办公APP。因而，若后台进程中存在测评APP的进程，且焦点进程为

和/或钉钉

的进程，则确定测评APP当前的运行场景为模拟办公场景。

模拟办公场景下，可以按照系统负载等级的不同，分别预设第一功耗调整策略：策略1-4-1、策略1-4-2和策略1-4-3。策略1-4-1、策略1-4-2和策略1-4-3用于设定PL1、PL2和EPP的值，降低CPU的功耗。

参见表1，在模拟idle场景下，测评APP模拟用户对电子设备无任何操作，但是电子设备正在运行的场景。这种场景下，测评APP在后台运行，其进程为后台进程，而且，电子设备中无外设输入(包括鼠标输入、键盘输入和触摸屏输入等)，屏幕状态为亮屏解锁状态，CPU利用率、GPU利用率、磁盘读写速度均较低。因而，若后台进程中存在测评APP的进程，系统中无外设事件，屏幕状态为亮屏解锁状态，且CPU利用率、GPU利用率、磁盘读写速度均小于各自的预设阈值，则确定测评APP当前的运行场景为模拟idle场景。

模拟idle场景下，可以按照系统负载等级的不同，分别预设第一功耗调整策略：策略1-5-1、策略1-5-2和策略1-5-3。策略1-1-5-1、策略1-5-2和策略1-5-3用于设定PL1、PL2和EPP的值，降低CPU的功耗。另一方面，一般的，系统默认CPU最小处理器状态百分比为5％(即CPU最少采用5％核运行)。在模拟idle场景下，CPU采用5％核运行存在资源浪费，因而，该场景下对应的第二功耗调整策略将CPU最小处理器状态百分比调整为0，避免资源浪费，降低功耗。同时，idle场景下，用户对电子设备无操作，CPU的运行频率无需过高，因而第二功耗调整策略还通过减小CPU输出的频率信号的占空比降低CPU运行频率，降低CPU功耗。

参见表1，在默认场景下，测评APP在后台运行，其进程为后台进程。默认场景即以上几种场景之外测评APP的其他运行场景。因而，若后台进程中存在测评APP的进程，且不满足测评主场景、模拟网页浏览场景、模拟网页视频场景、模拟办公场景和模拟idle场景等场景的识别条件，则确定测评APP当前的运行场景为默认场景。

默认场景下，可以按照系统负载等级的不同，分别预设第一功耗调整策略：策略1-6-1、策略1-6-2和策略1-6-3。策略1-6-1、策略1-6-2和策略1-6-3用于设定PL1、PL2和EPP的值，降低CPU的功耗。

总而言之，本实施例提供的方法，在不同的运行场景下，通过第一功耗调整策略调整CPU的功耗，且通过第二功耗调整策略调整CPU、GPU等硬件的工作模式和参数，使得电子设备的CPU、GPU等硬件可以按照当前运行场景下的实际需求进行运行，减少CPU、GPU等出现性能过剩的情况，从而达到降低电子设备功耗的效果。

示例性的，图4为本申请实施例提供的一例识别测评APP的运行场景的方法的流程示意图。该方法的执行主体为电子设备。在一个具体的实施例中，该方法的执行主体可以为图3所示的场景识别引擎中的场景识别模块。本实施例中，以测评APP预设的模拟网页浏览场景所使用的APP和模拟网页视频场景所使用的APP相同为例进行说明。如图4所示，该方法包括：

S101、确定焦点进程是否为测评APP的进程；若是，则确定测评APP当前的运行场景为测评主场景；若否，则执行步骤S102。

可选的，在系统探针模块已向API模块订阅窗口事件的情况下，API模块向场景识别引擎中的系统探针模块上报焦点窗口事件，系统探针模块可以将焦点窗口事件发送至场景识别模块。场景识别模块确定焦点进程是否为测评APP的进程。

具体的，API模块将焦点窗口事件发送至系统探针模块，焦点窗口事件携带有焦点窗口对应的进程(即焦点进程)的名称。系统探针模块再将焦点窗口事件发送至场景识别模块，场景识别模块确定焦点窗口事件中焦点进程的名称与测评APP的进程名称是否一致；若一致，则说明焦点进程为测评APP的进程，确定测评APP当前的运行场景为测评主场景；若不一致，则说明焦点进程不为测评APP的进程，确定测评APP的运行场景不为测评主场景，执行步骤S102。

S102、判断后台进程中是否存在测评APP的进程；若是，则执行步骤S103；若否，则说明测评APP未运行，结束流程。

具体的，若场景识别模块在步骤S101中确定焦点进程不为测评APP的进程，则场景识别模块进一步判断后台进程中是否存在测评APP的进程。

可选的，场景识别模块可以从系统探针模块获取后台进程的扫描结果，根据后台进程的扫描结果，确定后台进程中是否存在测评APP的进程。具体的，后台进程的扫描结果可以包括后台进程列表，后台进程列表中包括在后台运行的所有进程的信息(如进程名称)。场景识别模块确定后台进程列表中是否包括测评APP。例如，测评APP的进程名称为a.exe，场景识别模块确定后台进程列表中是否包括名称为a.exe的进程。若是，则说明后台进程中存在测评APP的进程，即测评APP正在后台运行，执行步骤S103；若否，则说明后台进程中不存在测评APP的进程，即测评APP不在后台运行，且根据步骤S101的判断结果可知，当前时刻焦点进程也不为测评APP的进程，即测评APP也不在前台运行，因而说明测评APP未运行，结束流程。

S103、判断焦点进程是否为测评APP预设的模拟用户办公场景所使用的APP的进程；若是，则确定测评APP当前的运行场景为模拟办公场景；若否，则执行步骤S104。

具体的，若场景识别模块在步骤S102中确定后台进程中存在测评APP的进程，则场景识别模块进一步判断焦点进程是否为测评APP预设的模拟用户办公场景所使用的APP的进程，以确定测评APP当前的运行场景是否为模拟办公场景。

可选的，场景识别模块可以将焦点进程的信息与预设的办公进程名单进行对比，确定办公进程名单中是否包括焦点进程的信息。办公进程名单中存储有测评APP预设的模拟用户办公场景所使用的所有APP的进程信息(如进程名称)。例如，办公进程名单中可以包括office的进程名称soffice.exe，焦点进程的名称也为soffice.exe。经对比，办公进程名单中包括焦点进程的名称，说明焦点进程为测评APP预设的模拟用户办公场景所使用的APP的进程，确定测评APP当前的运行场景为模拟办公场景。若办公进程名单中不包括焦点进程的名称，则说明焦点进程不为测评APP预设的模拟用户办公场景所使用的APP的进程，执行步骤S104。

S104、判断焦点进程是否为测评APP预设的模拟用户网页浏览场景(也即模拟用户网页视频场景)所使用的APP的进程；若是，则执行步骤S105；若否，则执行步骤S106。

具体的，若场景识别模块在步骤S103中确定焦点进程不为测评APP预设的模拟用户办公场景所使用的APP的进程，则场景识别模块进一步判断焦点进程是否为测评APP预设的模拟用户网页浏览场景(也即模拟用户网页视频场景)所使用的APP的进程，以确定测评APP当前的运行场景是否为模拟网页浏览场景或模拟网页视频场景。

可选的，场景识别模块可以根据将焦点进程的信息与预设的浏览器进程名单进行对比，确定浏览器进程名单中是否包括焦点进程的信息。浏览器进程名单中存储有测评APP预设的模拟用户网页浏览场景(也即模拟用户网页视频场景)所使用的APP的进程信息(如进程名称)。例如浏览器进程名单中可以包括

浏览器的进程名称chrome.exe和

浏览器的进程名称firefox.exe等，焦点进程的进程名称为chrome，经对比，浏览器进程名单中包括焦点进程的名称，说明焦点进程是测评APP预设的模拟用户网页浏览场景所使用的APP的进程，执行步骤S105。若浏览器进程名单中不包括焦点进程的名称，则说明焦点进程不是测评APP预设的模拟用户网页浏览场景(也即模拟用户网页视频场景)所使用的APP的进程，测评APP当前的运行场景不为模拟网页浏览场景，也不为模拟网页视频场景，执行步骤S106。

S105、判断是否有音视频事件存在；若是，则确定测评APP当前的运行场景为网页视频场景；若否，则确定测评APP当前的运行场景为网页浏览场景。

具体的，若场景识别模块在步骤S104中确定测评APP预设的模拟用户网页浏览场景(也即模拟用户网页视频场景)所使用的APP的进程，则场景识别模块进一步判断是否有音视频事件存在，以确定测评APP当前的运行场景是模拟网页视频场景还是模拟网页浏览场景。

可选的，场景识别模块可以通过音视频探针的状态确定是否存在音视频事件。若存在音视频事件，则说明测评APP的运行场景为模拟网页视频场景；若否，则说明测评APP的运行场景为模拟网页浏览场景。

S106、判断是否存在外设事件；若是，则确定测评APP当前的运行场景为默认场景；若否，则执行步骤S107。

具体的，若场景识别模块在步骤S104中确定焦点进程不为测评APP预设的模拟用户网页浏览场景(也即模拟用户网页视频场景)所使用的APP的进程，则场景识别模块进一步判断是否有外设事件，以确定测评APP当前的运行场景是否可能为模拟idle状态。

可选的，场景识别模块可以通过外设探针的状态确定是否有外设事件；若是，则说明测评APP当前的运行场景不为模拟idle场景，进而说明当前时刻测评APP未运行在预设的几种场景下，为默认场景；若否，则执行步骤S107。

S107、判断屏幕状态是否为亮屏解锁状态；若是，则执行步骤S108；若否，则确定测评APP当前的运行场景为默认场景。

可选的，场景识别模块可以通过屏幕状态探针的状态确定屏幕状态是否为亮屏解锁状态；若否，则说明测评APP当前的运行场景不为模拟idle场景，进而说明当前时刻测评APP未运行在预设的几种场景下，为默认场景；若是，则执行步骤S108。

S108、确定是否CPU利用率小于第一阈值，且GPU的利用率小于第二阈值，且磁盘的读写速度小于第三阈值；若是，则确定测评APP的运行场景为模拟idle场景；若否，则说明测评APP当前的运行场景不为模拟idle场景，进而说明当前时刻测评APP未运行在预设的几种场景下，确定测评APP的运行场景为默认场景。

可选的，场景识别模块可以通过系统负载探针的状态获取CPU利用率和GPU的利用率，并通过磁盘IO探针的状态确定磁盘的读写速度。

场景识别模块通过上述步骤S101至S108步骤得到运行场景的识别结果，并将运行场景识别结果发送至场景识别引擎中的策略匹配管理器。可选的，运行场景识别结果可以通过场景信息表示。也即，场景信息用于指示测评APP当前的运行场景。示例性的，电子设备可以预先为测评APP的各个运行场景分别分配唯一标识(可称为场景号)，该场景信息则可包括测评APP的运行场景的唯一标识。例如，该标识(例如为V00)可指示测评APP的运行场景为测评主场景。又例如，该标识(例如为V02)可指示测评APP的运行场景为模拟网页视频场景。再例如，该标识(例如为V-1)可指示测评APP的运行场景为默认场景。当然，在其他的实施例中，场景信息也可以包括场景名称等信息。

另外，负载管控器从系统探针模块获取当前的系统负载，并根据当前的系统负载确定系统负载等级。系统负载等级用于表征系统负载的轻重程度。可选的，系统负载等级例如可以包括重、中和轻三个等级。可选的，各个系统负载等级可以通过预设的编号表示。例如，1表示系统负载等级为“轻”，2表示系统负载等级为“中”，3表示系统负载等级为“重”。

在一个具体的实施例中，负载管控器可以根据预设的系统负载与系统负载等级的映射关系，查询确定当前的系统负载对应的系统负载等级。例如，根据映射关系，CPU利用率小于b，对应的系统负载等级为轻；CPU利用率大于或等于b且小于c，对应的系统负载等级为中；CPU利用率大于或等于c，对应的系统负载等级为重。

负载管控器将确定出的系统负载等级发送至策略匹配管理器。策略匹配管理器可以根据场景识别模块发送的场景信息和负载管控器发送的系统负载等级，按照表1中的对应关系，匹配得到对应的第一功耗调整策略。例如，场景识别模块识别出测评APP当前的运行场景为测评主场景，则场景设备模块向策略匹配管理器发送表征测评主场景的场景信息。另外，负载管控器确定出的系统负载等级为“轻”，负载管控器向策略匹配管理器发送系统功耗等级“轻”，则策略匹配管理器根据表1中测评APP的运行场景、系统负载等级与第一功耗调整策略的对应关系，匹配得到的第一功耗调整策略为策略1-1-1。如上实施例所述，第一功耗调整策略中包括用于调整CPU的功耗参数。为了便于描述，以下将第一功耗调整策略中的参数统称为第一功耗参数。第一功耗参数可以包括参数类型和参数的目标值。可选的，第一功耗参数可以包括PL1目标值、PL2目标值、EPP目标值和EPO开关(switch)的状态等参数。其中，EPO开关用于选择是否由DTT自动分配功耗。当EPO开关处于打开状态时，由DTT按照EPO Gear(可根据EPP计算得到)分配功耗，即DTT参照EPP目标值分配功耗。当EPO开关处于关闭状态时，由DTT自动动态分配功耗(即DTT自主设置EPP)，这种情况下不向CPU下发EPP目标值。在一个具体的实施例中，可以通过EPO开关参数的值确定EPO开关是否打开，例如，值为1表示EPO开关打开，值为0表示EPO开关关闭。

策略匹配管理器将场景信息和第一功耗参数发送至芯片策略融合器。一方面，芯片策略融合器根据表1中测评APP的运行场景与第二功耗调整策略的对应关系，确定场景信息对应的第二功耗调整策略。芯片策略融合器将第二功耗调整策略发送至调度执行器。调度执行器可以通过API模块中的相关接口调用DTT驱动、显卡驱动等执行第二功耗调整策略。继续以测评APP当前的运行场景为测评主场景为例，芯片策略融合器接收策略匹配管理器发送的场景信息，根据表1中测评APP的运行场景与第二功耗调整策略的对应关系，确定测评主场景对应的第二功耗调整策略为策略2-1：将测评APP的进程绑定在CPU的小核上运行。芯片策略融合器将策略2-1发送至调度执行器。调度执行器通过API模块中的相关接口调用DTT驱动，将测评APP的进程绑定在CPU的小核上运行。

另一方面，芯片策略融合器基于CPU的芯片平台类型，对第一功耗参数进行转译，得到策略号，并将策略号下发至调度执行器。调度执行器可以通过WMI将策略号下发至BIOS，BIOS将策略号下发至CPU，实现对CPU功耗的调整。关于芯片策略融合器对第一功耗参数的转译方法在后述实施例进行详细说明。

可以理解，实际应用中，电子设备可以实时或者周期性执行上述步骤S101至S108以识别测评APP当前的运行场景，之后按照上述实施例所述的方法匹配并下发执行功耗调整策略，从而能够持续进行功耗调整，降低测评APP运行过程中的功耗，延长电池续航时间，提高用户体验。

需要说明的是，上述实施例中以测评APP为例对功耗调整方法进行说明，实际的应用中，并不限于测评APP，只要是存在多种运行场景的APP，均可以按照该方法进行功耗调整，降低APP运行过程中的功耗。例如，某一APP，运行过程中包括第一场景、第二场景、第三场景……则可以按照本实施例提供的方法针对不同的场景设置不同的场景识别条件和功耗调整策略，按照预设的流程逐一判断是否满足相关的场景识别条件，并确定对应的第一目标功耗策略和第二功耗策略。总而言之，本申请实施例对于APP的类型不做任何限定，可以根据实际需求设计和选择。

下面对芯片策略融合器基于CPU的芯片平台类型，对第一功耗参数进行转译，得到策略号的具体实现方法进行进一步说明。

策略号用于标识CPU实现功耗调整的策略。可选的，策略号可以包括DTT策略号和EPO策略号。

DTT策略号也称为DTT策略ID，用于标识DTT策略。DTT策略号对应的DTT策略用于调整CPU的PL1和PL2的值。

EPO策略号，也称为EPO策略ID，用于标识EPO策略。EPO策略号对应的EPO策略用于调整CPU的EPO Gear。

可以理解地，DTT策略号与CPU的功耗参数可以存在映射关系，EPO策略号与CPU的EPO Gear可以存在映射关系，芯片策略融合器可以根据这两种映射关系分别确定策略匹配管理器下发的第一功耗参数对应的DTT策略号(下称目标DTT策略号)和EPO策略号(下称目标EPO策略号)。具体的，可以预先在BIOS中构建一张策略表，用于存储DTT策略号和/或EPO策略号与CPU的PL1、PL2和EPO Gear等参数的值的对应关系。在一个实施例中，策略表可以如表2所示。可以理解，DTT策略号和EPO策略号可以仅通过编号区分。例如，表2中，策略号0至21、40、41为DTT策略号，策略号50至55为EPO策略号。

表2

可以理解，表2仅为一种示例，并不构成对策略表的限定。实际应用中，策略表中的内容可以包括比表2更多或更少的内容，且各个策略号及对应的参数值可以与表2中不同。

可选的，芯片策略融合器可以根据运行场景和第一功耗参数，或者根据第一功耗参数确定策略号。

示例性的，图5为本申请实施例提供的一例确定DTT策略号和EPO策略号的方法流程示意图。本实施例中，执行主体可以为图3中所示的芯片策略融合器，不再赘述。如图5所示，在策略表为表2的情况下，可以按照以下方法确定目标DTT策略号和目标EPO策略号：

S201、确定第一功耗参数是否为默认策略参数；若第一功耗参数为默认策略参数，则执行步骤S202；若第一功耗参数不为默认策略参数，则执行步骤S203。

默认策略参数是指默认场景对应的第一功耗参数。

可选的，在一种实现方式中，可以根据场景信息(如场景号)判断第一功耗参数是否为默认策略参数。例如，预先设定的默认场景的场景号为V-1，则可以判断当前场景号是否为V-1，若是，则表明第一功耗参数为默认策略参数，执行步骤S202；否则表明第一功耗参数不为默认策略参数，执行步骤S203。

S202、根据第一功率参数对应的系统负载等级情况确定目标DTT策略号。

可选的，可以根据第一功率参数确定对应的系统负载等级为重、中或轻，若第一功率参数对应的系统负载等级为“重”，则确定目标DTT策略号为0；若第一功率参数对应的系统负载等级为“轻”，则确定目标DTT策略号为40；若第一功率参数对应的系统负载等级为“中”，则确定目标DTT策略号为41。

此处的系统负载等级可以向系统负载探针订阅得到，也可以由芯片策略融合器随场景号一同下发。

可选的，系统也可以预先指定一个DTT策略号为所有默认场景对应的策略号。也就是说，在第一CPU功耗参数为默认策略参数时，将某一默认场景对应的DTT策略号(例如默认策略(重载)对应的DTT策略号0)确定为目标DTT策略号。

可选的，在另一种实现方式中，在确定第一功耗参数是否为默认策略参数时，也可以直接根据第一功耗参数中的PL1目标值来确定，且若根据PL1目标值确定第一功耗参数为默认策略参数后，可以直接确定出对应的策略号。也就是说，上述步骤S201和步骤S202也可以通过下述方式替换：

判断第一功耗参数中的PL1目标值是否等于默认策略参数(重载)对应的PL1的值(35)；若是，则确定第一功耗参数为默认策略参数(重载)，将默认策略参数(重载)对应的策略号(0)确定为目标DTT策略号；若否，则判断第一功耗参数中的PL1目标值是否等于默认策略参数(轻载)对应的PL1的值(12)，若是，则确定第一功耗参数为默认策略参数(轻载)，将默认策略参数(轻载)对应的策略号(40)确定为目标DTT策略号；若否，则判断第一功耗参数中的PL1目标值是否等于默认策略参数(中载)对应的PL1的值(20)，若是，则确定第一功耗参数为默认策略参数(中载)，将默认策略参数(中载)对应的策略号(41)确定为目标DTT策略号；若否，则确定第一功耗参数不为默认策略参数，执行步骤S203。

S203、根据第一功耗参数中的PL1目标值，通过计算公式(1)确定目标DTT策略号。

其中，

表示向下取整，step表示策略表中的PL1的步进值(即相邻两个DTT策略号对应的PL1值的差值的绝对值)，在PL1目标值小于45的情况下，step＝2，在PL1目标值大于或等于45的情况下，step＝5。

offset1表示DTT补偿值，在PL1目标值小于45的情况下，offset1＝-1，在PL1目标值大于或等于45的情况下，offset1＝9。

举例：假设第一功耗参数中，PL1目标值为8，则step＝2，offset1＝-1，

该实现方式中，通过公式(1)能够快速的确定出策略表中与第一功耗参数中的PL1目标值最接近的PL1值对应的策略号，从而能够快速的确定出目标DTT策略号，无需遍历查询策略表，提高参数转译效率。

S204、判断EPO开关的状态是否为打开状态；若EPO开关的状态为打开状态(是)，则执行步骤S205；若EPO开关的状态为关闭状态(否)，则执行步骤S206。

可选的，可以确定EPO开关参数的返回值是否为1，若返回值为1，则确定EPO开关为打开状态；若返回值为0，则确定EPO开关为关闭状态。

S205、根据公式(2)确定EPO策略号。

其中，

表示向下取整，255为EPP的最大取值，offset2表示EPO补偿值，offset2可以为50。

举例：假设第一功耗参数中，EPO开关状态为打开，EPP目标值为127，则

该实现方式中，通过公式(2)能够快速的确定出策略表中与第一功耗参数中的EPP目标值对应的EPO Gear最接近的EPO Gear，从而能够快速的确定出目标EPO策略号，无需遍历查询策略表，提高参数转译效率。

S206、确定目标EPO策略号为EPO开关关闭状态下对应的策略号，即50。

为了便于理解，本申请以下实施例将以具有图1和图2所示结构的电子设备为例，结合图3，对本申请实施例提供的功耗调整方法进行具体阐述。

本申请实施方式所提供的功耗调整方法，主要分为三个过程，分别为：(1)确定测评APP当前的运行场景；(2)根据测评APP当前的运行场景及系统负载等级确定第一功耗调整策略。(3)根据运行场景确定第二功耗调整策略，并根据功耗调整策略(包括第一功耗调整策略和第二功耗调整策略)进行功耗调整。下面将分别以测评APP当前的运行场景为测评主场景和模拟网页视频场景为例，结合附图，对上述三个过程进行说明。

A、测评主场景

(1)确定测评APP当前的运行场景

为了便于理解，首先对订阅过程进行简要说明。

a)系统探针模块可以预先向内核态订阅内核事件。

具体的，系统探针模块向OsEventDriver节点发送第一订阅请求。OsEventDriver节点再向执行体或内核和驱动层的相应模块发送第一订阅请求。第一订阅请求例如可以包括订阅进程创建事件的请求、订阅后台进程的请求、订阅GPU解码事件的请求、订阅外设事件的请求、订阅系统负载的请求和订阅磁盘IO事件的请求中的一种或多种。

第一订阅请求中可以携带有进程名称。即场景识别引擎可以仅订阅指定进程的相关事件，减少不相干进程的创建事件的干扰。例如，指定进程可以为测评APP的进程、视频APP的进程、浏览器APP的进程、办公APP的进程等等。当然，在其他实施方式中，场景识别引擎也可以不对订阅的事件做出限制。

以订阅进程创建事件的请求为例，如图3所示，场景识别引擎包括系统探针模块，系统探针模块包括系统事件探针。在本申请实施例中，可以由系统事件探针向位于执行体层的OsEventDriver节点发送订阅进程创建事件的请求。OsEventDriver节点向进程管理器发送第一订阅请求。也就是说，场景识别引擎的系统事件探针可以通过OsEventDriver节点向进程管理器发送第一订阅请求。可以理解地，OsEventDriver节点会向进程管理器注册一个回调，注册该回调的作用是当进程管理器创建进程后，可以向OsEventDriver节点返回该进程创建事件。

再以第一订阅请求为订阅GPU解码事件的请求为例，如图3所示，系统探针模块包括音视频状态探针。可以由音视频状态探针向OsEventDriver节点发送订阅GPU解码事件的请求。OsEventDriver节点向显卡驱动发送订阅GPU解码事件的请求。也就是说，场景识别引擎的音视频状态探针可以通过OsEventDriver节点向显卡驱动发送订阅GPU解码事件的请求。同样地，OsEventDriver节点可向显卡驱动注册一个回调，注册该回调的作用是当显卡驱动监控到GPU进行解码操作后，可以向OsEventDriver节点返回该GPU解码事件。

订阅后台进程、订阅外设事件、订阅系统负载和订阅磁盘IO事件等的过程与上述过程类似，区别在于信息或事件的检测或监控的主体不同。具体的，后台进程可以由进程管理器监控，外设事件可以由外设驱动检测，系统负载可以由进程管理器检测，磁盘IO事件可以由磁盘驱动监控。

b)系统探针模块可以预先向API模块订阅焦点窗口变化事件。

API模块可包括由user32.dll实现的windows用户界面接口，该接口可用于创建窗口。在一种可选的实施方式中，可以由系统探针模块的系统事件探针向API模块的windows用户界面接口发送订阅焦点窗口变化事件的请求。

同样地，该系统事件探针可向API模块注册一个回调，注册该回调的作用是当API模块(的windows用户界面接口)监控到焦点窗口发生变化时，可以向系统事件探针返回该焦点窗口变化事件。

焦点窗口为拥有焦点的窗口，大概率为测评APP当前运行场景对应的窗口。例如，测评APP运行于测评主场景，焦点窗口为测评APP的某一窗口。又例如，测评APP运行于办公场景，焦点窗口为测评APP预设的模拟用户办公场景所使用的APP的窗口。通过监控焦点窗口是否发生变化，可以确定测评APP运行场景的变化，具体的可以参见上述表1及对应的实施例，不再赘述。

系统探针模块预先完成内核事件的订阅后，相关的模块会按照回调中要求的上报方式上报信息或事件。

c)场景识别模块可以预先向系统探针模块订阅探针状态。

具体的，场景识别模块可以向系统探针模块发送第二订阅请求，第二订阅请求用于请求订阅探针状态，包括系统事件探针的状态、音视频状态探针的状态、外设状态探针的状态和磁盘IO探针的状态等。其中，系统事件探针的状态可以包括焦点窗口事件。

场景识别模块可向系统探针模块注册一个回调，注册该回调的作用是当系统探针模块确定探针状态后，可以向场景识别模块返回该探针状态。

当然，在一些其他的实施例中，也可以由场景识别模块根据需要向系统探针模块获取探针状态。例如，场景识别模块需要判断焦点进程是否为测评APP的进程时，可以向系统探针模块获取系统事件探针的状态，系统事件探针将系统事件探针的状态(包括焦点窗口事件)发送至场景识别模块。

d)负载管控器可以预先向系统探针模块订阅系统状态。

具体的，负载管控器可以向系统探针模块发送订阅系统负载探针状态的请求。负载管控器可向系统探针模块注册一个回调，注册该回调的作用是当系统探针模块确定系统负载探针的状态后，可以向负载管控器返回该探针状态。

当然，在一些其他的实施例中，也可以由负载管控器根据需要向系统探针模块获取探针状态。例如，场景识别模块需要判断系统负载等级时，可以向系统探针模块获取系统负载探针的状态，系统负载探针将当前的系统负载发送至负载管控器。

示例性的，图6是本申请实施例提供的一例功耗调整方法的流程示意图，该方法包括：

S301、响应于接收到用户开启测评APP的操作，测评APP向进程管理器发送创建进程请求。

其中，创建进程请求包括测评APP的存储地址。

测评APP可以通过API模块的kernel32.dll接口及Ntdll.dll接口向进程管理器发送创建进程的请求(图未示)。

S302、进程管理器创建测评APP进程。

具体的，进程管理器可以通过测评APP的存储地址查询到测评APP的二进制文件。通过加载测评APP的二进制文件，可以创建进程运行的环境，启动测评APP进程。

其中，Windows操作系统将一个APP的一次运行定义为一个进程。一个进程可以拥有多个线程。窗口是窗口结构的实例，是一种图形用户界面(graphical user interface，GUI)资源，窗口是由线程创建的，线程可以拥有它所创建的所有窗口。在本申请实施例中，电子设备运行测评APP，则进程管理器需创建该测评APP的进程。测评APP进程包括多个线程，多个线程包括线程1，线程1可用于创建测评APP的主窗口。

S303、进程管理器向OsEventDriver节点上报进程创建事件。

其中，进程创建事件可包括进程管理器所创建的进程的名称。在本申请实施例中，该进程的名称为测评APP进程的名称。当然，若进程管理器创建的是其他应用的进程，该进程的名称也对应为其他应用进程的名称。

前文已经说明，OsEventDriver节点向进程管理器发送了订阅进程创建事件的请求，且注册了回调。因此，进程管理器在创建测评APP进程后可向OsEventDriver节点上报进程创建事件。

S304、OsEventDriver节点向系统探针模块上报进程创建事件。

在本申请实施例中，该OsEventDriver节点可向系统探针模块的系统事件探针上报该进程创建事件。

S305、系统探针模块向场景识别模块发送进程创建事件。

S306、响应于线程1的调用请求，API模块创建窗口1。

进程管理器创建测评APP进程后，测评APP进程的线程1主动调用API模块的windows用户界面接口创建窗口1。示例性的，如图7中(a)所示，电子设备可以显示窗口101，该窗口101可以为桌面，也可以称为主界面。该窗口101包括测评APP的图标102。电子设备可以接收用户点击该测评APP的图标102的操作，响应于该操作，如图7中的(b)所示，电子设备显示窗口103(即窗口1)。在上述过程中，焦点窗口由原本的窗口101变为窗口103。

需要说明的是，在电子设备已经启动测评APP的情况下，电子设备可以不用执行S301～S306。

S307、API模块向系统探针模块上报焦点窗口事件。

在本申请实施例中，API模块的windows用户界面接口创建窗口1后，可以获取当前焦点进程及上一个焦点进程，也即获取当前的焦点窗口(即窗口1)对应的进程及上一个焦点窗口(例如，窗口2)对应的进程。示例性的，窗口1对应的进程为测评APP的进程，该进程的名称例如为amark11.exe，窗口2对应的进程为windows程序管理器的进程，该进程的名称例如为explorer.exe。由于当前焦点进程及上一个焦点进程的名称不一致，API模块确定焦点窗口发生变化，向系统探针模块的系统事件探针上报焦点窗口事件。其中，焦点窗口事件包括当前焦点进程的名称。示例性的，第一进程为测评APP进程，焦点窗口事件携带有测评APP进程的名称。

S308、系统探针模块向场景识别模块发送焦点窗口事件。

S309、场景识别模块确定焦点进程为测评APP的进程，确定测评APP当前的运行场景为测评主场景。

如上实施例所述，场景识别模块可以将当前焦点进程的名称与测评APP的进程名称进行对比，确定是否一致，若一致，则确定当前焦点进程为测评APP的进程，测评APP当前的运行场景为测评主场景；否则，确定当前焦点进程不为测评APP的进程，测评APP当前的运行场景不为测评主场景。

(2)根据测评APP当前的运行场景及系统负载等级确定第一功耗调整策略

参见图8，图8接续图7，如图8所示，本实施例提供的功耗调整方法可以包括下述过程：

S310、场景识别模块向策略匹配管理器发送场景信息。

其中，场景信息用于指示测评APP当前的运行场景。本实施例中，场景信息用于指示测评APP当前的运行场景为测评主场景。

S311、进程管理器获取系统负载。

S312、进程管理器向OsEventDriver节点上报系统负载。

S313、OsEventDriver节点向系统探针模块上报系统负载。

具体的，进程管理器可以向系统探针模块的系统负载探针发送该系统负载。在一种可选的实施方式中，也可以由OsEventDriver节点向系统负载探针转发该系统负载(图未示)。

S314、系统探针模块向负载管控器发送系统负载。

S315、负载管控器根据系统负载确定系统负载等级。

具体的，可以参见上述实施例，不再赘述。本实施例中，以系统负载等级为“轻”为例进行说明。

S316、负载管控器将系统负载等级发送至策略匹配管理器。

S317、策略匹配管理器根据场景信息和系统负载等级匹配得到第一功耗调整策略。

参照表1，本实施例中，测评APP当前的运行场景为测评主场景，对应的第一功耗调整策略为策略1-1-1。

(3)根据运行场景确定第二功耗调整策略，并根据功耗调整策略进行功耗调整

参见图9，图9接续图8，如图9所示，本实施例提供的功耗调整方法可以包括下述过程：

S318、策略匹配管理器向芯片策略融合器发送场景信息和第一功耗调整策略。

S319、芯片策略融合器根据芯片平台对第一功耗调整策略进行转译，输出策略号。

具体的，可以参见图5所示实施例，不再赘述。

S320、芯片策略融合器根据场景信息匹配第二功耗调整策略。

参照表1，本实施例中，测评APP当前的运行场景为测评主场景，对应的第二功耗调整策略为策略2-1。

S321、芯片策略融合器向调度执行器发送策略号和第二功耗调整策略。

S322、调度执行器向WMI发送策略号。

S323、WMI向BIOS发送策略号。

S324、BIOS向CPU发送策略号。

S325、CPU根据策略号进行功耗调整。

S326、调度执行器向API模块发送第二功耗调整策略。

可以理解，API模块中可以包括各种第二功耗调整策略对应的接口，调度执行器可以将第二功耗调整策略发送至对应的接口。

S327、API模块调用相关接口进行功耗调整。

本实施例中，第二功耗调整策略为策略2-1：将测评APP的进程绑定在CPU的小核上运行。API模块中用于绑定小核的接口可以通过Inter DTT驱动将测评APP的进程绑定在CPU的小核上运行，从而降低CPU功耗。

B、模拟网页视频场景

(1)确定测评APP当前的运行场景

示例性的，图10是本申请实施例提供的一例功耗调整方法的流程示意图，该方法包括：

S401、API模块向系统探针模块上报焦点窗口事件。

如上述实施例所述，焦点窗口事件中携带有焦点进程的名称。

S402、系统探针模块向场景识别模块发送焦点窗口事件。

S403、场景识别模块根据焦点窗口事件确定焦点进程不为测评APP的进程。

S404、进程管理器向OsEventDriver节点上报后台进程。

S405、OsEventDriver节点向系统探针模块上报后台进程。

S406、系统探针模块向场景识别模块发送后台进程。

S407、场景识别模块确定后台进程中存在测评APP的进程。

可选的，场景识别模块可以确定后台进程列表中是否存在测评APP的进程的名称，若是，则确定后台进程中存在测评APP的进程。

S408、场景识别模块根据焦点窗口事件确定焦点进程不为测评APP预设的模拟用户办公场景所使用的APP的进程。

S409、场景模拟模块根据焦点窗口事件确定焦点进程为测评APP预设的模拟用户网页浏览场景(也即模拟用户网页视频场景)所使用的APP的进程。

S410、显卡驱动向OsEventDriver节点上报GPU解码事件。

S411、OsEventDriver节点向系统探针模块上报GPU解码事件。

S412、系统探针模块向场景识别模块发送音视频事件。

音视频事件用于表征当前系统中存在音视频流。

S413、场景模拟模块根据音视频事件确定测评APP当前的运行场景为模拟网页视频场景。

(2)根据测评APP当前的运行场景及系统负载等级确定第一功耗调整策略

该过程与图8实施例所示的过程相似，区别在于策略匹配管理器匹配得到的策略结果不同。本实施例中，策略匹配管理器根据场景信息和系统负载等级匹配得到第一功耗调整策略为策略1-3-1，得到第二功耗调整策略为策略2-3。

(3)根据运行场景确定第二功耗调整策略，并根据功耗调整策略进行功耗调整

该过程与图9实施例所示的过程相似，区别在于，本实施例中，第二功耗调整策略为策略2-3：1)采用集成显卡显示，且调整集成显卡的工作模式为节能模式；2)将MMCSS设置为节能模式。因而，调度执行器将第二功耗调整策略发送至API模块后，API模块中用于调整显卡的接口通过显卡驱动调整显示方式为集成显卡，并将集成显卡的工作模式调整为节能模式；另外，API模块中用于调整MMCSS的接口将MMCSS设置为节能模式。

需要说明的是，以上各实施例提供的功耗调整方法中的步骤之间没有严格的先后顺序，只要符合实现逻辑即可。以图10所示实施例为例，步骤S401、S404及S410可以按照图4中所示的顺序依次执行，也可以同时执行，还可以按照S404、S401、S410的顺序依次执行、按照S404、S410、S401的顺序依次执行、按照S410、S401、S404的顺序依次执行或者按照S410、S404、S401的顺序依次执行。

上文详细介绍了本申请实施例提供的功耗调整方法的示例。可以理解的是，电子设备为了实现上述功能，其包含了执行各个功能相应的硬件和/或软件模块。本领域技术人员应该很容易意识到，结合本文中所公开的实施例描述的各示例的单元及算法步骤，本申请能够以硬件或硬件和计算机软件的结合形式来实现。某个功能究竟以硬件还是计算机软件驱动硬件的方式来执行，取决于技术方案的特定应用和设计约束条件。本领域技术人员可以结合实施例对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本申请的范围。

本申请实施例可以根据上述方法示例对电子设备进行功能模块的划分，例如，可以对应各个功能划分为各个功能模块，例如检测单元、处理单元、显示单元等，也可以将两个或两个以上的功能集成在一个模块中。上述集成的模块既可以采用硬件的形式实现，也可以采用软件功能模块的形式实现。需要说明的是，本申请实施例中对模块的划分是示意性的，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式。

需要说明的是，上述方法实施例涉及的各步骤的所有相关内容均可以援引到对应功能模块的功能描述，在此不再赘述。

本实施例提供的电子设备，用于执行上述功耗调整方法，因此可以达到与上述实现方法相同的效果。

在采用集成的单元的情况下，电子设备还可以包括处理模块、存储模块和通信模块。其中，处理模块可以用于对电子设备的动作进行控制管理。存储模块可以用于支持电子设备执行存储程序代码和数据等。通信模块，可以用于支持电子设备与其他设备的通信。

其中，处理模块可以是处理器或控制器。其可以实现或执行结合本申请公开内容所描述的各种示例性的逻辑方框，模块和电路。处理器也可以是实现计算功能的组合，例如包含一个或多个微处理器组合，数字信号处理(digital signal processing，DSP)和微处理器的组合等等。存储模块可以是存储器。通信模块具体可以为射频电路、蓝牙芯片、Wi-Fi芯片等与其他电子设备交互的设备。

在一个实施例中，当处理模块为处理器，存储模块为存储器时，本实施例所涉及的电子设备可以为具有图1所示结构的设备。

本申请实施例还提供一种芯片系统，如图11所示，该芯片系统包括至少一个处理器801和至少一个接口电路802。处理器801和接口电路802可通过线路互联。例如，接口电路802可用于从其它装置(例如电子设备的存储器)接收信号。又例如，接口电路802可用于向其它装置(例如处理器801)发送信号。示例性的，接口电路802可读取存储器中存储的指令，并将该指令发送给处理器801。当所述指令被处理器801执行时，可使得电子设备执行上述实施例中的各个步骤。当然，该芯片系统还可以包含其他分立器件，本申请实施例对此不作具体限定。

本申请实施例还提供了一种计算机可读存储介质，计算机可读存储介质中存储了计算机程序，当计算机程序被处理器执行时，使得处理器执行上述任一实施例的功耗调整方法。

本申请实施例还提供了一种计算机程序产品，当该计算机程序产品在计算机上运行时，使得计算机执行上述相关步骤，以实现上述实施例中的功耗调整方法。

另外，本申请的实施例还提供一种装置，这个装置具体可以是芯片，组件或模块，该装置可包括相连的处理器和存储器；其中，存储器用于存储计算机执行指令，当装置运行时，处理器可执行存储器存储的计算机执行指令，以使芯片执行上述各方法实施例中的功耗调整方法。

其中，本实施例提供的电子设备、计算机可读存储介质、计算机程序产品或芯片均用于执行上文所提供的对应的方法，因此，其所能达到的有益效果可参考上文所提供的对应的方法中的有益效果，此处不再赘述。

通过以上实施方式的描述，所属领域的技术人员可以了解到，为描述的方便和简洁，仅以上述各功能模块的划分进行举例说明，实际应用中，可以根据需要而将上述功能分配由不同的功能模块完成，即将装置的内部结构划分成不同的功能模块，以完成以上描述的全部或者部分功能。

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

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

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

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

以上内容，仅为本申请的具体实施方式，但本申请的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本申请揭露的技术范围内，可轻易想到变化或替换，都应涵盖在本申请的保护范围之内。因此，本申请的保护范围应以权利要求的保护范围为准。

Claims (19)

1.一种功耗调整方法，所述方法由电子设备执行，其特征在于，所述电子设备中运行第一应用程序APP，所述第一APP包括多个运行场景，所述方法包括：

确定所述电子设备的当前系统负载；

确定所述第一APP当前的运行场景；

根据所述当前系统负载和所述第一APP当前的运行场景确定目标功耗调整策略；

根据所述目标功耗调整策略调整所述电子设备的功耗。

2.根据权利要求1所述的方法，其特征在于，所述确定所述第一APP当前的运行场景，包括：

获取当前焦点进程；所述当前焦点进程是指当前时刻所述电子设备中的焦点进程，所述焦点进程是指创建焦点窗口的线程所属的进程；

根据所述当前焦点进程确定所述第一APP当前的运行场景。

3.根据权利要求2所述的方法，其特征在于，所述根据所述当前焦点进程确定所述第一APP当前的运行场景，包括：

若所述当前焦点进程为所述第一APP的进程，则确定所述第一APP当前的运行场景为所述多个场景中的第一场景；所述第一场景是指所述第一APP的窗口为焦点窗口的场景；

若所述当前焦点进程不为所述第一APP的进程，则获取后台进程，并根据所述后台进程确定所述第一APP当前的运行场景，所述后台进程是指所述电子设备当前在后台运行的进程。

4.根据权利要求3所述的方法，其特征在于，所述根据所述后台进程确定所述第一APP当前的运行场景，包括：

若所述后台进程中存在所述第一APP的进程，且所述当前焦点进程为第二APP的进程，则确定第一APP当前的运行场景为所述多个运行场景中的第二场景；所述第二APP为所述第一APP预设的运行于所述第二场景时所使用的APP。

5.根据权利要求4所述的方法，其特征在于，所述第二场景为办公场景，所述第二APP为预设的办公APP。

6.根据权利要求3所述的方法，其特征在于，所述根据所述后台进程确定所述第一APP当前的运行场景，包括：

若所述后台进程中存在所述第一APP的进程，且所述当前焦点进程为第三APP的进程，且满足第一预设条件，则确定第一APP当前的运行场景为所述多个运行场景中的第三场景；所述第三APP为所述第一APP预设的运行于所述第三场景时所使用的APP。

7.根据权利要求6所述的方法，其特征在于，所述第三场景为网页视频场景，所述第三APP为预设的浏览器APP，所述第一预设条件为所述电子设备中存在音视频事件；

或者，所述第三场景为应用视频场景，所述第三APP为预设的视频播放APP，所述第一预设条件为所述电子设备中存在音视频事件；

或者，所述第三场景为网页浏览场景，所述第三APP为预设的浏览器APP，所述第一预设条件为所述电子设备中不存在音视频事件。

8.根据权利要求3所述的方法，其特征在于，所述根据所述后台进程确定所述第一APP当前的运行场景，包括：

若所述后台进程中存在所述第一APP的进程，且满足第二预设条件，则确定第一APP当前的运行场景为所述多个运行场景中的第四场景。

9.根据权利要求8所述的方法，其特征在于，所述第四场景为空闲场景，所述第二预设条件包括：所述电子设备中不存在外设事件，所述电子设备的屏幕状态为亮屏解锁状态，所述电子设备的中央处理器CPU的利用率小于第一阈值，所述电子设备的图形处理器GPU的利用率小于第二阈值，且所述电子设备的磁盘读写速度小于第三阈值。

10.根据权利要求1至9中任一项所述的方法，其特征在于，所述目标功耗调整策略包括第一目标功耗调整策略和第二目标功耗调整策略，所述第一目标功耗调整策略用于指示调整所述电子设备的CPU的功耗参数，所述第二目标功耗调整策略用于指示调整所述电子设备中模块的工作状态。

11.根据权利要求10所述的方法，其特征在于，所述根据所述当前系统负载和所述第一APP当前的运行场景确定目标功耗调整策略，包括：

根据所述当前系统负载确定当前系统负载等级；

根据所述当前系统负载等级和所述第一APP当前的运行场景，以及第一对应关系确定所述第一目标功耗调整策略；所述第一对应关系中包括多个系统负载等级、所述多个运行场景与多个第一功耗调整策略的对应关系，所述多个第一功耗调整策略中包括所述第一目标功耗调整策略；

根据所述第一APP当前的运行场景，以及第二对应关系确定所述第二目标功耗调整策略；所述第二对应关系中包括所述多个运行场景与多个第二功耗调整策略的对应关系，所述多个第二功耗调整策略中包括所述第二目标功耗调整策略。

12.根据权利要求10或11所述的方法，其特征在于，所述CPU的功耗参数包括所述CPU的长时睿频功耗PL1、短时睿频功耗PL2以及能效比EPP中的至少一个。

13.根据权利要求10至12中任一项所述的方法，其特征在于，所述第一APP的当前运行场景为所述多个运行场景中的第一场景的情况下，所述第二目标功耗调整策略用于指示将所述第一APP的进程绑定在所述CPU的小核上运行；所述第一场景是指所述第一APP的窗口为焦点窗口的场景。

14.根据权利要求10至12中任一项所述的方法，其特征在于，所述第一APP的当前运行场景为所述多个运行场景中的网页浏览场景的情况下，所述第二目标功耗调整策略用于指示采用集成显卡显示，并调整所述集成显卡的工作模式为节能模式。

15.根据权利要求10至12中任一项所述的方法，其特征在于，所述第一APP当前的运行场景为所述多个运行场景中的网页视频场景的情况下，所述第二目标功耗调整策略用于指示采用集成显卡显示，调整所述集成显卡的工作模式为节能模式，并将多媒体类计划程序服务MMCSS的工作模式设置为节能模式。

16.根据权利要求10至12中任一项所述的方法，其特征在于，所述第一APP当前的运行场景为所述多个运行场景中的空闲场景的情况下，所述第二目标功耗调整策略用于指示减小所述CPU的最小处理器状态的百分比，并减小所述CPU输出的频率信号的占空比。

17.根据权利要求16所述的方法，其特征在于，所述减小所述CPU的最小处理器状态的百分比包括：减小所述CPU的最小处理器状态的百分比至0。

18.一种电子设备，其特征在于，包括：处理器、存储器和接口；

所述处理器、所述存储器和所述接口相互配合，使得所述电子设备执行如权利要求1至17中任一项所述的方法。

19.一种计算机可读存储介质，其特征在于，所述计算机可读存储介质中存储了计算机程序，当所述计算机程序被处理器执行时，使得所述处理器执行权利要求1至17中任一项所述的方法。

Images