CN113886180A - 控制方法及电子设备 - Google Patents

Abstract

本申请公开了一种控制方法及电子设备，方法包括：管理引擎获得状态参数，所述状态参数包括如下至少一项：至少一个应用程序的状态参数，和/或，至少一个电子元器件的状态参数；所述管理引擎基于所述状态参数设置至少一个功能引擎的运行参数和至少一个功能元件的运行参数。

Description

控制方法及电子设备

技术领域

本申请涉及计算机技术领域，尤其涉及一种控制方法及电子设备。

背景技术

在电子设备上，通常会内置参数控制逻辑，如基于设备温度控制CPU运行频率，再如基于用户的输入操作控制屏幕刷新率，等等。

因此，目前设备参数的控制逻辑单一，可能会使得控制的准确性较低，导致无法为用户提供更舒适的使用体验。

发明内容

有鉴于此，本申请提供一种控制方法及电子设备，如下：

一种控制方法，包括：

管理引擎获得状态参数，所述状态参数包括如下至少一项：至少一个应用程序的状态参数，和/或，至少一个电子元器件的状态参数；

所述管理引擎基于所述状态参数设置至少一个功能引擎的运行参数和至少一个功能元件的运行参数。

上述方法，优选的，基于所述状态参数设置至少一个功能引擎的运行参数和至少一个功能元件的运行参数，包括：

基于所述状态参数，获得当前运行场景；

获得所述当前运行场景对应的控制参数，所述控制参数对应于至少一个功能引擎和至少一个功能元件；

根据所述控制参数，设置所述功能引擎的运行参数和所述功能元件的运行参数。

上述方法，优选的，所述管理引擎中存储有预设的第一对应关系表；所述第一对应关系表中包含多个运行场景的场景标识，每个所述场景标识对应于至少一项状态参数。

其中，基于所述状态参数，获得当前运行场景，包括：

在所述第一对应关系表中，查找与所述状态参数对应的当前运行场景。

上述方法，优选的，在所述状态参数存在多个的情况下，在所述第一对应关系表中，查找与所述状态参数对应的当前运行场景，包括：

在所述第一对应关系表中，按照所述状态参数之间的优先级，在高优先级的状态参数对应的场景标识中查找低优先级的状态参数对应的场景标识，以得到最低优先级的状态参数对应的目标场景标识，所述目标场景标识对应的运行场景为当前运行场景；

或，

在所述第一对应关系标识，分别获得每个所述状态参数对应的初始场景标识，在所述初始场景标识中筛选出目标场景标识，所述目标场景标识对应的运行场景为当前运行场景。

上述方法，优选的，所述方法还包括：

利用安全引擎对所述第一对应关系表进行安全处理。

上述方法，优选的，所述状态参数由与所述管理引擎相连接的状态采集接口对所述应用程序和所述电子元器件进行参数采集得到并传输给所述管理引擎。

上述方法，优选的，所述管理引擎中存储有预设的第二对应关系表；所述第二对应关系表中包含多个运行场景的场景标识，每个所述场景标识对应于至少一项控制参数，每项所述控制参数对应所述功能引擎或所述功能元件；

获得所述当前运行场景对应的控制参数，包括：

在第二对应关系表中，查找与所述当前运行场景对应的控制参数。

上述方法，优选的，所述方法还包括：

利用安全引擎对所述第二对应关系表进行安全处理。

上述方法，优选的，根据所述控制参数，设置所述功能引擎的运行参数和所述功能元件的运行参数，包括：

通过参数下发接口将所述控制参数传输给所述控制参数对应的功能引擎或功能元件，以使得所述功能引擎或所述功能元件按照接收到的控制参数设置相应的运行参数。

一种电子设备，包括：

状态采集接口，用于采集状态参数，所述状态参数包括如下至少一项：至少一个应用程序的状态参数，或，至少一个电子元器件的状态参数；

管理引擎，用于接收所述状态采集接口发送的状态参数，基于所述状态参数设置至少一个功能引擎的运行参数和至少一个功能元件的运行参数。

从上述技术方案可以看出，本申请公开的一种控制方法及电子设备中，通过配置管理引擎，从而利用管理引擎来获得至少一个应用程序的状态参数和/或至少一个电子元器件的状态参数，进而基于这些状态参数对功能引擎和功能元件各自的运行参数。可见，本申请中通过对多软硬件多方面的状态参数进行统一管理，进而实现对软硬件多方面的运行参数的设置，由此提高控制的准确性，为用户提供更加舒适的使用体验。

附图说明

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

图1为本申请实施例一提供的一种控制方法的流程图；

图2为本申请实施例一提供的一种控制方法的部分流程图；

图3为本申请实施例二提供的一种电子设备的结构示意图；

图4为基于本申请实施例所实现的motoSXF的整体架构图；

图5为基于本申请实施例所实现的motoSXF的核心功能示意图；

图6为基于本申请实施例所实现的motoSXF的软件架构图。

具体实施方式

下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。

参考图1所示，为本申请实施例一提供的一种控制方法的实现流程图，该方法可以适用于具有电子元器件且配置有应用程序的电子设备中，如手机、pad、计算机或服务器等设备。本实施例中的方法主要用于提高对电子设备中运行参数进行控制的准确性。

具体的，本实施例中的方法可以包含如下步骤：

步骤101：管理引擎获得状态参数。

其中，状态参数包含如下至少一项：至少一个应用程序的状态参数，和/或，至少一个电子元器件的状态参数。这里的应用程序可以包含原装在电子设备的操作系统中的应用程序，如短消息应用、通话应用或图像处理应用等，也可以包含由应用提供商所提供且由用户根据需求装载在电子设备中的应用程序，如游戏应用、视频播放应用等。而电子元器件可以为电子设备上配置的硬件，如摄像头、麦克风、显示屏、马达、中央处理器CPU(centralprocessing unit)、图形处理器GPU(graphics processing unit)、存储器、天线modem等元器件。

基于此，由电子设备中配置的管理引擎对应用程序的状态参数和/或电子元器件的状态参数进行统一获得以及管理。这里的管理引擎可以为配置在电子设备中能够被执行以实现参数控制的程序模块。

具体的，本实施例中可以首先由电子设备中配置的状态采集接口对应用程序和电子元器件进行参数采集，在状态采集接口采集到应用程序的状态参数和电子元器件的状态参数之后，将这些状态参数传输给与状态采集接口相连接的管理引擎，由此，管理引擎可以获得到应用程序的状态参数和/或电子元器件的状态参数。

其中，状态采集接口为配置在电子设备中的能够实现参数采集的程序模块，在被执行时能够采集到应用程序的状态参数和/或电子元器件的状态参数。

具体实现中，状态采集接口可以通过被动接收的方式和/或主动读取的方式采集到应用程序的状态参数和/或电子元器件的状态参数。例如，状态采集接口可以通过与应用程序之间的连接接收应用程序所发送的状态参数，和/或，状态采集接口可以通过与电子元器件之间的连接接收电子元器件所发送的状态参数。再如，状态采集接口可以在电子设备中用于存储状态参数的存储区域中主动读取应用程序的状态参数和/或电子元器件的状态参数。

其中，应用程序的状态参数可以包含多个方面的状态参数，如应用程序的应用名称、版本号、应用权限、应用类型、应用运行阶段等参数。以游戏应用为例，其状态参数可以包含有：游戏应用的名称、游戏更新版本、游戏应用在电子设备的操作系统中所获得到的运行权限如允许使用定位的权限、游戏类型、游戏应用当前所处的运行阶段如加载阶段、启动后的等待阶段、启动后的运行阶段以及正在关闭的阶段，等等。以视频播放应用为例，其状态参数可以有：视频应用的名称、更新版本、在电子设备的操作系统中所获得到的运行权限如允许使用存储的权限、应用类型如能识别并播放的视频格式等类型、视频被播放的分辨率、视频被播放的窗口尺寸、视频应用当前所处的运行阶段如启动的加载阶段、启动后的加载视频的阶段、启动后的视频播放阶段以及正在关闭的阶段，等等。

而电子元器件的状态参数可以包含有多个方面的状态参数，如电子元器件的器件名称、器件型号、器件权限、器件类型、器件运行阶段以及器件性能参数等。以显示屏为例，其状态参数可包含名称、显示屏型号、显示屏在电子设备的操作系统中所获得到的权限、显示屏类型、显示屏的刷新率、显示屏的分辨率、显示屏的尺寸、显示屏当前所处的运行阶段如接电正在启动的阶段、启动后输出内容的阶段以及正在关闭的阶段，等等。以马达为例，其状态参数可以包含：马达名称、型号、马达的震动波形类型、马达震动时长、马达震动频率或震动间隔、马达当前所处的运行阶段如正在震动、正在待机等。以WiFi天线为例，其状态参数可以包含：发射功率、接收功率、传输数据量、通道顺畅度等。以天线为例，其状态参数可以包含：发射功率、接收功率、传输数据量、通道顺畅度等。

步骤102：管理引擎基于状态参数设置至少一个功能引擎的运行参数和至少一个功能元件的运行参数。

其中，功能引擎是指电子设备中实现相应功能的软件程序，如为实现视频播放应用所配置的视频编解码器、为实现相机功能的软件模块、为实现扬声器的声音信号的音频输出模块、调整解调器modem、为实现马达震动的软件模块等。功能引擎的运行参数是指为功能引擎实现相应功能所采用的参数，如应用程序的窗口尺寸、窗口位置、视频或图像的分辨率等。

而功能元件是指电子设备中实现相应功能的硬件组件。如CPU、GPU、摄像头、麦克风、天线、显示屏等。功能元件的运行参数是指功能元件为实现相应功能所采用的参数，如CPU运行频率、GPU运行频率、内存的垃圾回收阈值、显示屏刷新率、分辨率、天线发射功率等等。

其中，功能元件和电子元器件可以为同一器件，如步骤101中获得CPU的当前运行频率，在步骤102中对CPU的运行频率进行控制。当然功能元件和电子元器件也可以为不同的器件。

可见，本实施例中的管理引擎基于所获得到的软硬件多方面的状态参数对软硬件多方面的运行参数进行设置，从而使得电子设备的运行能够符合用户的使用需求。

具体的，管理引擎可以通过预设的综合控制策略，对不同的状态参数设置相同或不同的运行参数为相同或不同的参数值。也就是说，在状态参数存在种类或参数值不同时，基于综合控制策略，管理引擎所设置的运行参数的种类可能相同也可能不同，而对于同一种类的运行参数所设置的参数值也可能相同或不同。

由上述方案可知，本申请实施例一提供的一种控制方法中，通过配置管理引擎，从而利用管理引擎来获得至少一个应用程序的状态参数和/或至少一个电子元器件的状态参数，进而基于这些状态参数对功能引擎和功能元件各自的运行参数。可见，本实施例中通过对多软硬件多方面的状态参数进行统一管理，进而实现对软硬件多方面的运行参数的设置，由此提高控制的准确性，为用户提供更加舒适的使用体验。

在一种实现方式中，步骤102中在基于状态参数设置至少一个功能引擎的运行参数和至少一个功能元件的运行参数时，具体可以通过以下方式实现，如图2中所示：

步骤201：基于状态参数，获得当前运行场景。

其中，本实施例中，管理引擎可以通过状态参数来识别当前运行场景，即用户使用电子设备所实现的功能运行场景。如用户使用手机进行游戏的场景，再如，用户观看视频的场景，等等。

具体的，管理引擎中存储有预设的第一对应关系表。在一种实现方式中，该第一对应关系表仅存储在管理引擎中。在另一种实现方式中，第一对应关系表可以存储在电子设备的存储区域，如硬盘中，在管理引擎需要进行运行参数的控制时，即电子设备开机并启动管理引擎之后，管理引擎从电子设备的存储区域中读取第一对应关系表。

在一种可能的实现方式中，第一对应关系表中可以包含多个运行场景的场景标识，每个场景标识对应于至少一项状态参数，具体表现为：场景标识对应于状态参数的参数值或参数值范围，如游戏场景对应马达正在运行的参数值1(马达没有运行的参数值为0)以及马达震动频率的频率范围，视频观看场景对应于CPU的运行频率的频率范围。其中，每个场景标识可以分别对应于一个或多项状态参数，不同的场景标识可能对应有相同或不同的状态参数，而不同的场景标识所对应的同一状态参数的参数值或参数值范围相同或不同。这里所说的状态参数不同是指状态参数的类型不同，如马达运行频率的状态参数和CPU运行频率的状态参数不同。而参数值或参数值范围不同是指同一类型的状态参数下不同的参数值或不同的参数值范围，如马达运行频率的第一频率和第二频率不同。

在另一种可能的实现方式中，第一对应关系表中可以包含有多个状态参数，每个状态参数对应于至少一个场景标识，具体表现为：状态参数的参数值或参数值范围对应于场景标识，如马达正在运行的参数值1以及马达震动频率的频率范围对应于游戏场景，再如马达没有运行的参数值0对应于视频观看场景。其中，每个状态参数可以分别对应于一个或多个场景标识，不同的状态参数可能对应于同一场景标识或不同的场景标识，而同一状态参数在不同的参数值或参数范围下可以对应于不同的场景标识。

需要说明的是，场景标识对应于运行场景，其中，场景标识之间具有并列或父子关系，在运行场景之间相应具有并列或父子关系。例如，游戏场景标识对应于游戏正在加载的场景标识、游戏启动后正在待机的场景标识和游戏启动后正在运行的场景标识。另外，第一对应关系表中，场景标识对应的状态参数还对应有概率值，该概率值表征在该状态参数处于参数值或参数值范围下对应于场景标识的可能性，概率值越大，在该状态参数处于参数值或参数值范围下对应于场景标识的可能性越高。

基于此，步骤201中可以在第一对应关系表中，查找与状态参数对应的当前运行场景。

在一种实现方式中，如果状态参数仅存在一个，那么本实施例中可以在第一对应关系表中查找到该状态参数对应的一个或多个场景标识，在这些场景标识中获得到对应场景范围最大的场景标识作为目标场景标识，而该目标场景标识对应的运行场景即为当前运行场景。例如，在仅有游戏应用被启动的状态参数时，在第一对应关系表中可以查找到相应的游戏场景标识、游戏正在加载的场景标识、游戏启动后正在待机的场景标识和游戏启动后正在运行的场景标识等等，基于此，将范围最大的游戏场景标识确定为目标场景标识，进而确定当前运行场景为游戏场景。

在另一种实现方式中，如果状态参数为多个，那么本实施例中可以在第一对应关系表中，按照状态参数之间的优先级，在高优先级的状态参数对应的场景标识中查找低优先级的状态参数对应的场景标识，以得到最低优先级的状态参数对应的目标场景标识，此时，目标场景标识对应的运行场景为当前运行场景。具体为：在第一对应关系表中，对最高优先级的状态参数查找对应的场景标识，组成第一集合，在第一集合中按照第一对应关系表对次高优先级的状态参数查找对应的场景标识，组成第二集合，在第二集合中按照第一对应关系表对下一优先级的状态参数查找对应的场景标识，组成第三集合，直到在最近得到的集合中按照第一对应关系表对最低优先级的状态参数查找对应的场景标识，即目标场景标识，如果目标场景标识由多个，那么选择场景范围最大的目标场景标识，即可确定相应的运行场景。

例如，首先确定前台运行的应用程序的程序名，然后确定应用类型以及应用启动阶段(如正在加载、已经启动后等待、正在运行、正在关闭等阶段)，最后确定其他应用程序或电子元器件的状态参数，如相机被启动或停止、编解码器被启动或停止、数据通信流畅与否等。基于此，按照这些状态参数的次序，先在第一对应关系表中查找前台运行的应用程序的程序名对应的场景标识，再在程序名对应的场景标识中查找应用类型对应的场景标识，再在应用类型对应的场景标识中查找应用启动阶段对应的场景标识，再在应用启动阶段对应的场景标识中查找相机被启动或停止对应的场景标识，再在相机被启动或停止对应的场景标识中查找编解码器被启动或停止对应的场景标识，再在编解码器被启动或停止对应的场景标识中查找数据通信流畅与否对应的场景标识，直到对最后的状态参数进行场景标识查找后，得到最终的目标场景标识，以确定当前运行场景，如游戏应用正在加载且没有播放视频也没有使用相机的场景。

在另一种实现方式中，如果状态参数为多个，那么本实施例中可以在第一对应关系表中，分别获得每个状态参数对应的初始场景标识，此时的初始场景标识可能有多个，因此，再在初始场景标识中筛选出目标场景标识，例如，在初始场景标识中筛选出关联度最高或概率最大的场景标识作为目标场景标识。例如，在第一对应关系表中分别查找前台运行的应用程序的程序名对应的场景标识、应用类型对应的场景标识、应用启动阶段对应的场景标识、相机被启动或停止对应的场景标识、编解码器被启动或停止对应的场景标识、数据通信流畅与否对应的场景标识等等，再在这些场景标识中找到相关联或一致或预设概率值最大的场景标识，如筛选出重复多次游戏应用正在加载且没有播放视频也没有使用相机的场景。

进一步的，本实施例中还可以利用安全引擎对第一对应关系表进行安全处理。安全引擎可以为在电子设备中为管理引擎所配置的执行程序，用以对第一对应关系表进行安全保护，避免信息泄露。

在一种实现方式中，安全引擎可以采用签名算法对第一对应关系表中的状态参数以及其与场景标识之间的对应关系进行签名，将得到的数字签名与第一对应关系表一起存储，在管理引擎使用第一对应关系表之前，先使用数字签名对第一对应关系表进行验证，如果验证不通过，那么表明第一对应关系表可能被篡改或损坏，此时，管理引擎不再继续执行，只有验证通过，管理引擎才会继续使用第一对应关系表进行场景识别以及后续处理。

在另一种实现方式中，安全引擎可以采用加密算法对第一对应关系表中的状态参数以及其与场景标识之间的对应关系进行加密处理，再存储被加密的第一对应关系表，在管理引擎使用第一对应关系表之前，先对第一对应关系表进行解密，如果解密不成功，那么表明第一对应关系表可能被篡改或损坏，此时，管理引擎不再继续执行，只有解密成功后，管理引擎才会继续使用第一对应关系表进行场景识别以及后续处理。

步骤202：获得当前运行场景对应的控制参数。

其中，控制参数对应于至少一个功能引擎和至少一个功能元件。例如，对应于编解码器的控制参数、对应于CPU的控制参数和对应于GPU的控制参数。

具体的，管理引擎中存储有预设的第二对应关系表。在一种实现方式中，该第二对应关系表仅存储在管理引擎中。在另一种实现方式中，第二对应关系表可以存储在电子设备的存储区域，如硬盘中，在管理引擎需要进行运行参数的控制时，即电子设备开机并启动管理引擎之后，管理引擎从电子设备的存储区域中读取第二对应关系表。

在一种可能的实现方式中，第二对应关系表中可以包含多个运行场景的场景标识，每个场景标识对应于至少一项控制参数，每项控制参数对应功能引擎或功能元件，具体表现为：场景标识对应于控制参数的参数值或参数值范围，如游戏场景对应马达震动频率的频率范围，视频观看场景对应于CPU的运行频率的频率范围。其中，每个场景标识可以分别对应于一个或多项控制参数，不同的场景标识可能对应有相同或不同的控制参数，而不同的场景标识所对应的同一控制参数的参数值或参数值范围相同或不同。这里所说的控制参数不同是指控制参数的类型不同，如马达运行频率的控制参数和CPU运行频率的控制参数不同。而参数值或参数值范围不同是指同一类型的控制参数下不同的参数值或不同的参数值范围，如马达运行频率的第一频率和第二频率不同。

基于此，步骤202中可以在第二对应关系表中，查找与当前运行场景对应的控制参数，这里的控制参数可以有一项或多项，且控制参数以参数值或参数值范围表征。例如，在确定当前运行场景为游戏正在加载的场景后，在第二对应关系表中查找到对应于CPU运行频率的频率范围的控制参数。

进一步的，本实施例中还可以利用安全引擎对第二对应关系表进行安全处理。安全引擎可以为在电子设备中为管理引擎所配置的执行程序，用以对第二对应关系表进行安全保护，避免信息泄露。

在一种实现方式中，安全引擎可以采用签名算法对第二对应关系表中的状态参数以及其与场景标识之间的对应关系进行签名，将得到的数字签名与第二对应关系表一起存储，在管理引擎使用第二对应关系表之前，先使用数字签名对第二对应关系表进行验证，如果验证不通过，那么表明第二对应关系表可能被篡改或损坏，此时，管理引擎不再继续执行，只有验证通过，管理引擎才会继续使用第二对应关系表进行场景识别以及后续处理。

在另一种实现方式中，安全引擎可以采用加密算法对第二对应关系表中的状态参数以及其与场景标识之间的对应关系进行加密处理，再存储被加密的第二对应关系表，在管理引擎使用第二对应关系表之前，先对第二对应关系表进行解密，如果解密不成功，那么表明第二对应关系表可能被篡改或损坏，此时，管理引擎不再继续执行，只有解密成功后，管理引擎才会继续使用第二对应关系表进行场景识别以及后续处理。

步骤203：根据控制参数，设置功能引擎的运行参数和功能元件的运行参数。

具体的，管理引擎可以通过参数下发接口将控制参数传输给控制参数对应的功能引擎或功能元件，以使得功能引擎或功能元件按照接收到的控制参数设置相应的运行参数。

其中，参数下发接口为配置在电子设备中的能够实现参数传输的程序模块，在被执行时能够将控制参数传输到对应的功能引擎或功能元件。例如，通过参数下发接口将CPU运行频率的频率范围下发给CPU，以便于CPU按照该频率范围进行运行；再如，通过参数下发接口将马达的波长范围下发给马达，以便于马达按照该波长范围输出震动波；再如，通过参数下发接口将视频分辨率下发给编解码器，以便于编解码按照该视频分辨率解码视频文件进行输出。

可见，本实施例中，管理引擎通过状态参数实现当前运行场景的识别，从而在对功能引擎和功能元件的控制逻辑上，基于当前运行场景对相应的控制参数进行设置，使得被调整的控制参数能够使得电子设备的运行更满足用户的需求。

例如，手机中的管理引擎通过前台运行的应用程序、应用程序的启动阶段以及CPU的当前运行频率等状态参数，识别手机当前的运行场景，如游戏正在进行的场景，此时，对CPU的运行频率按照CPU温度进行控制时，采用该场景下对应的运行参数实现，例如，在没有应用在运行的场景下，如果CPU温度过高，那么CPU的运行频率被控制在较低的第一频率下，通过降低CPU运行频率实现CPU降温；而在游戏正在进行的场景下，如果CPU温度过高，CPU的运行频率被控制在较高的第二频率以下，由此，避免CPU运行频率被过多的降低导致用户游戏体验较差。

参考图3，为本申请实施例二提供的一种电子设备的结构示意图，该电子设备可以为具有电子元器件且配置有应用程序的电子设备，如手机、pad、计算机或服务器等设备。本实施例中的方法主要用于提高对电子设备中运行参数进行控制的准确性。

具体的，本实施例中的电子设备可以包含如下结构：

状态采集接口301，用于采集状态参数，所述状态参数包括如下至少一项：至少一个应用程序的状态参数，或，至少一个电子元器件的状态参数；

管理引擎302，用于接收所述状态采集接口发送的状态参数，基于所述状态参数设置至少一个功能引擎的运行参数和至少一个功能元件的运行参数。

其中，管理引擎302在设置运行参数时，具体用于：基于所述状态参数，获得当前运行场景；获得所述当前运行场景对应的控制参数，所述控制参数对应于至少一个功能引擎和至少一个功能元件；根据所述控制参数，设置所述功能引擎的运行参数和所述功能元件的运行参数。

具体的，所述管理引擎中存储有预设的第一对应关系表；所述第一对应关系表中包含多个运行场景的场景标识，每个所述场景标识对应于至少一项状态参数。管理引擎302在基于所述状态参数，获得当前运行场景时，可以在所述第一对应关系表中，查找与所述状态参数对应的当前运行场景。例如，在所述第一对应关系表中，按照所述状态参数之间的优先级，在高优先级的状态参数对应的场景标识中查找低优先级的状态参数对应的场景标识，以得到最低优先级的状态参数对应的目标场景标识，所述目标场景标识对应的运行场景为当前运行场景；或，在所述第一对应关系标识，分别获得每个所述状态参数对应的初始场景标识，在所述初始场景标识中筛选出目标场景标识，所述目标场景标识对应的运行场景为当前运行场景。

另外，所述管理引擎中存储有预设的第二对应关系表；所述第二对应关系表中包含多个运行场景的场景标识，每个所述场景标识对应于至少一项控制参数，每项所述控制参数对应所述功能引擎或所述功能元件；管理引擎302在获得所述当前运行场景对应的控制参数时，可以在第二对应关系表中，查找与所述当前运行场景对应的控制参数。

另外，本实施例中的电子设备还可以包含有参数下发接口303，以及用于安全存储信息的存储模块304。

其中，参数下发接口303用于将所述控制参数传输给所述控制参数对应的功能引擎或功能元件，以使得所述功能引擎或所述功能元件按照接收到的控制参数设置相应的运行参数。

而存储模块304中利用安全引擎对所述第一对应关系表进行安全处理，而且，利用安全引擎对所述第二对应关系表进行安全处理。

从上述技术方案可以看出，本申请实施例二的一种电子设备中，通过配置管理引擎，从而利用管理引擎来获得至少一个应用程序的状态参数和/或至少一个电子元器件的状态参数，进而基于这些状态参数对功能引擎和功能元件各自的运行参数。可见，本申请中通过对多软硬件多方面的状态参数进行统一管理，进而实现对软硬件多方面的运行参数的设置，由此提高控制的准确性，为用户提供更加舒适的使用体验。

另外，本申请实施例三还提供了一种电子设备，其中包含存储器和处理器，存储器用于存储实现以上功能的程序，而处理器用于执行存储器中的程序以实现上述功能。

以手机为例，基于本申请中的技术方案，对手机中的运行控制进行举例说明：

首先，手机出厂时，会设定一种通用的性能控制参数。但实际使用手机的过程中，这种通用的性能参数很难兼顾不同的场景需求，要么性能过剩，要么性能不足。例如，对屏幕刷新率进行控制时，仅按照用户是否触屏进行控制，而忽略其他应用的运行；再如，对CPU运行频率进行控制时，仅基于CPU温度进行控制，等等，均会降低用户使用体验。

针对上述问题，本申请的技术方案提出在手机中建立自下而上的性能优化公共框架motoSXF(motorola System eXperience Framework)，由手机中的对应于应用程序和电子元器件的各个功能模块向motoSXF其提供当前状态参数，如图4所示的motoSXF整体架构，motoSXF据此做出决策，得到控制参数，然后指示相应的功能引擎和功能元件等各个执行模块调整相关的运行参数，以达到更好的性能。由此，如果没有motoSXF。那么各个功能引擎和功能元件的运行参数的控制如温控引擎thermal engine，只能根据片面的、特定的、局部的状态来做粗暴的一刀切式的控制处理。而采用motoSXF后，特殊场景就会被特殊对待，例如，结合多种状态参数在相应的运行场景下，提高CPU频率以使能高性能模式，改善用户体验，或者，降低CPU频率，以保证用户体验的条件下，节省功耗，或者提高屏幕刷新率，或者降低屏幕刷新率，等等。

以thermal engine为例，thermal engine可以控制CPU运行频率，但thermalengine是根据thermal sensor反馈的设备温度值来控制CPU运行频率的。如果不采用motoSXF，那么并不区分当前的用户使用场景，也不甄别用户当前的特殊需求。以用户玩游戏的场景为例，游戏App(application)会大量消耗CPU、GPU及其其他软硬件资源，因而很容易导致设备温度的快速上升。这时，CPU运行频率很快就会被thermal engine重新设定较低的上限值，CPU运行频率受限，就会导致游戏App出现卡顿、触屏不响应等性能问题。但用户在玩游戏时，是可以承受较平时一般使用场景更高的温度的。基于本申请的技术方案，引入motoSXF后，motoSXF会识别出这种特殊场景，然后给各个功能引擎和功能元件重新设定动作域，即重新设置运行参数。以游戏场景为例，motoSXF识别到当前为游戏场景后，会向thermal engine请求CPU限频的阈值，假设一般场景是42摄氏度时就会限频CPU，游戏场景时就会被motoSXF要求达到45摄氏度时才限频CPU，从而使用户玩游戏的时间更长久，保障游戏不容易出现因卡顿而中途被迫退出的问题。

具体的，motoSXF包含4个核心功能，如图5中所示：

状态采集：各个应用程序和电子元器件对应的功能模块向motoSXF发送状态参数，或者motoSXF主动查询状态参数；

场景识别：motoSXF根据收集的各种状态参数，确定当前所处的使用场景，即前文中的当前运行场景。其中，motoSXF的场景识别中，识别算法可以由算法程序和算法输入参数的两部分构成。算法输入参数指什么状态参数的参数值对应什么场景，或者什么状态参数的参数值范围对应什么场景，即前文中的第一对应关系表。例如，前置照相机的视频被启动，则可能对应视频通话场景。

参数对应表，即前文中的第二对应关系表：motoSXF存储根据识别的当前运行场景，查询对应关系表，确定控制参数。其中，motoSXF参数对应表中，每个场景对应的控制参数不同。识别出场景后，对应确定一组控制参数，然后分别下发到对应的执行模块。例如，视频播放场景，确定了最佳的屏幕刷新率后，将目标刷新率下发到屏幕控制模块。

参数下发：motoSXF向功能引擎和功能元件等执行模块下发控制参数，设定当前所需的运行参数的参数值或参数值范围。其中，motoSXF通过各个执行模块提供的接口，将决策后的控制参数下发给各个执行模块，调整运行参数。

可见，如果没有motoSXF，很难做到准确的识别用户使用场景。而且，单独的功能模块或性能控制模块如应用程序、电子元器件、功能引擎、功能元件等也无法统筹全局，通过本申请中的motoSXF可以在确定某种特殊场景的情况下确定是提升CPU频率更优还是提高屏幕刷新率更优。

其中，motoSXF收集的状态参数包括但不限于：

1、前端App的信息，例如版本、包名、AndroidManifest声明的权限；

2、多媒体编解码器收到的请求，包括视频的宽/高、刷新率；

3、照相机被启动，前置或后置，视频或拍照；

4、振动马达被启动，波形类别，振动时长和间隔；

5、扬声器被启动，播放功率，播放时长；

6、数据流量大小。

各个应用程序、电子元器件等功能模块可以在适当的软件流程中，主动向motoSXF发送状态参数，也可以由motoSXF主动查询相关功能模块的状态参数。

另外，本申请提出的motoSXF中，还提供安全保护的功能，例如，对于场景识别和决策中所使用的第一对应关系表和第二对应关系表属于motoSXF的核心数据和核心算法，须保证其不被篡改，即，要保证其完整性。采用的方案可以有：这些数据和算法参数放置到只读文件分区，靠文件系统的属性来保证其不会被改写；或者，对这些数据和算法参数进行数字签名保护，当读取这些数据和参数时，先验证其数字签名是否有效，哈希值是否匹配，如果发现异常，则拒绝执行和动作。

而对于motoSXF的更新和升级方案可以有：

1、通过软件大版本的OTA升级，来完成motoSXF程序和数据的更新；

2、通过独立的专有服务器，来远程更新motoSXF数据。这时，需要建立可信的安全通道，更新的数据在安全通道内传输，到达设备时，要验证其有效性，保证没有被篡改和伪造。可以采用数字签名或数字信封的方式来保护更新数据；

3、通过本地更新。这时，需要保证更新数据的来源合法性。可以用数字签名或数字信封的方法来保证其合法性。

具体的，如图6中所示，为motoSXF的软件架构，其中，

motoSXF HAL service：负责联通各层的软件组件；

motoSXF TZ App：负责profiles的解密，这里的profile是指决策文件，具体可以包含前文中的第一对应关系表和第二对应关系表；

motoSXF engine：负责管理profiles，并负责管理相应各种功能引擎和功能元件，其中可以包含手机操作系统原有的功能引擎，也可以包含出厂后配置操作操作系统中的功能引擎，通过motoSXF engine进行管理，使得motoSXF HAL service的决策能够分发到相应的功能引擎和功能元件；

motoSXF driver是motoSXF在kernel层的代理，可以执行profiles的策略，也可以收集kernel层的状态信息；

motoSXF service是motoSXF在framework层的代理，可以在手机操作系统上的framework层执行时序要求比较严格的profiles策略或设备的规则如CPU控制策略、温度升级策略、屏幕刷新率控制策略等等避免的冲突，或者执行有状态依赖的profiles策略，也可以收集framework层的状态信息，例如前端App的状态参数；

另外，motoSXF TZ App可以替换成Secure VM上的App这样，profiles的解密操作就是在另一个基于Hypervisor的安全环境里执行，以实现安全保护。

综上，motoSXF的核心功能在于是决策(Verdict Maker)模块，即motoSXF HALservice，也就是前文中的管理引擎。它根据收集到的各种相关状态参数，结合配置好的profiles，判定出当前的用户使用场景，然后再通过查找profiles中对应该场景的策略如控制参数，再将这些策略下发到各个对应的功能引擎或功能元件，由相应的功能引擎或功能元件负责执行确定的策略，即设置相应的运行参数。

例如：以游戏为例，用户打开游戏APP之后，motoSXF service采集到各项状态参数，如游戏APP被打开、游戏APP类型、APP运行状态如游戏加载状态等参数，这些状态参数传输给motoSXF HAL service，进而利用profile识别出当前运行场景以及相应的控制参数，如游戏加载阶段所对应的控制参数，如CPU的运行频率和WiFi接收功率之后，将这些控制参数发送给相应的CPU和WiFi模块，以调节CPU运行频率和WiFi的接收功率，使得即使CPU温度较高，也不糊将CPU运行频率降低到过低的数值，同时将WiFi接收功率调整到较高的值，提高游戏帧下载速率以及游戏运行速率。

综上，采用本申请的方案之后，能够应对更特殊的使用场景，例如游戏、电子书阅读等，通过统一管理应用程序和电子元器件各方面的状态参数对多个功能引擎和功能元件的运行参数，实现各种使用场景的最佳性能，改善用户对手机等设备的使用体验。

本说明书中各个实施例采用递进的方式描述，每个实施例重点说明的都是与其他实施例的不同之处，各个实施例之间相同相似部分互相参见即可。对于实施例公开的装置而言，由于其与实施例公开的方法相对应，所以描述的比较简单，相关之处参见方法部分说明即可。

专业人员还可以进一步意识到，结合本文中所公开的实施例描述的各示例的单元及算法步骤，能够以电子硬件、计算机软件或者二者的结合来实现，为了清楚地说明硬件和软件的可互换性，在上述说明中已经按照功能一般性地描述了各示例的组成及步骤。这些功能究竟以硬件还是软件方式来执行，取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本申请的范围。

结合本文中所公开的实施例描述的方法或算法的步骤可以直接用硬件、处理器执行的软件模块，或者二者的结合来实施。软件模块可以置于随机存储器(RAM)、内存、只读存储器(ROM)、电可编程ROM、电可擦除可编程ROM、寄存器、硬盘、可移动磁盘、CD-ROM、或技术领域内所公知的任意其它形式的存储介质中。

对所公开的实施例的上述说明，使本领域专业技术人员能够实现或使用本申请。对这些实施例的多种修改对本领域的专业技术人员来说将是显而易见的，本文中所定义的一般原理可以在不脱离本申请的精神或范围的情况下，在其它实施例中实现。因此，本申请将不会被限制于本文所示的这些实施例，而是要符合与本文所公开的原理和新颖特点相一致的最宽的范围。

Claims (10)

1.一种控制方法，包括：

管理引擎获得状态参数，所述状态参数包括如下至少一项：至少一个应用程序的状态参数，和/或，至少一个电子元器件的状态参数；

所述管理引擎基于所述状态参数设置至少一个功能引擎的运行参数和至少一个功能元件的运行参数。

2.根据权利要求1所述的方法，基于所述状态参数设置至少一个功能引擎的运行参数和至少一个功能元件的运行参数，包括：

基于所述状态参数，获得当前运行场景；

获得所述当前运行场景对应的控制参数，所述控制参数对应于至少一个功能引擎和至少一个功能元件；

根据所述控制参数，设置所述功能引擎的运行参数和所述功能元件的运行参数。

3.根据权利要求2所述的方法，所述管理引擎中存储有预设的第一对应关系表；所述第一对应关系表中包含多个运行场景的场景标识，每个所述场景标识对应于至少一项状态参数；

其中，基于所述状态参数，获得当前运行场景，包括：

在所述第一对应关系表中，查找与所述状态参数对应的当前运行场景。

4.根据权利要求3所述的方法，在所述状态参数存在多个的情况下，在所述第一对应关系表中，查找与所述状态参数对应的当前运行场景，包括：

在所述第一对应关系表中，按照所述状态参数之间的优先级，在高优先级的状态参数对应的场景标识中查找低优先级的状态参数对应的场景标识，以得到最低优先级的状态参数对应的目标场景标识，所述目标场景标识对应的运行场景为当前运行场景；

或，

在所述第一对应关系标识，分别获得每个所述状态参数对应的初始场景标识，在所述初始场景标识中筛选出目标场景标识，所述目标场景标识对应的运行场景为当前运行场景。

5.根据权利要求3所述的方法，所述方法还包括：

利用安全引擎对所述第一对应关系表进行安全处理。

6.根据权利要求1所述的方法，所述状态参数由与所述管理引擎相连接的状态采集接口对所述应用程序和所述电子元器件进行参数采集得到并传输给所述管理引擎。

7.根据权利要求2所述的方法，所述管理引擎中存储有预设的第二对应关系表；所述第二对应关系表中包含多个运行场景的场景标识，每个所述场景标识对应于至少一项控制参数，每项所述控制参数对应所述功能引擎或所述功能元件；

获得所述当前运行场景对应的控制参数，包括：

在第二对应关系表中，查找与所述当前运行场景对应的控制参数。

8.根据权利要求7所述的方法，所述方法还包括：

利用安全引擎对所述第二对应关系表进行安全处理。

9.根据权利要求2所述的方法，根据所述控制参数，设置所述功能引擎的运行参数和所述功能元件的运行参数，包括：

通过参数下发接口将所述控制参数传输给所述控制参数对应的功能引擎或功能元件，以使得所述功能引擎或所述功能元件按照接收到的控制参数设置相应的运行参数。

10.一种电子设备，包括：

状态采集接口，用于采集状态参数，所述状态参数包括如下至少一项：至少一个应用程序的状态参数，或，至少一个电子元器件的状态参数；

管理引擎，用于接收所述状态采集接口发送的状态参数，基于所述状态参数设置至少一个功能引擎的运行参数和至少一个功能元件的运行参数。

Images