基于上传到云的特定用户和设备指标优化移动设备能量管理的制作方法

本申请要求于2017年3月10日递交的、申请序列号为15/456,186、发明名称为“基于上传到云的特定用户和设备指标优化移动设备能量管理”的美国非临时专利申请案的在先申请优先权，其全部内容通过引用结合在本文中。

本发明涉及跟踪功耗性能的技术领域。

背景技术：

由于各种因素的影响，移动设备的手机续航能力可能会发生变化。最好是尽量延长移动设备的运行时间，这样用户就不必经常充电或更换电池。

技术实现要素：

在一实施例中，在移动设备中执行一种用于对所述移动设备的电源管理策略实现并获得设备特定的改进或替换的方法。所述方法包括：从所述移动设备向远程服务自动和重复地上传所述移动设备的标识以及以下各项中的至少两项：指示所述移动设备的相应应用使用模式(applicationsusagepattern，简称aup)的数据，指示所述移动设备的相应资源使用模式(resourcesusagepattern，简称rup)的数据，指示所述移动设备因所述aup和所述rup中至少一项而产生的能耗和/或功耗且由所述分别上传的所述aup和所述rup的代表性数据表示的数据，或指示移动设备相对于所述表示的aup和/或rup提供的服务质量(qualityofservice，简称qos)的数据；从所述远程服务接收所述移动设备的电源管理策略的改进或替换，所述改进或替换至少基于所述的从所述移动设备向所述远程服务自动和重复地上传。

在根据前述实施例中任一实施例的第二实施例中，所述改进或替换不是只基于从所述一个移动设备上传，而是基于从类似位置的其它移动设备进行众包上传，以便从许多类似位置的设备中采样的数据用于针对移动设备的相应制造、型号和版本就功耗、电池续航能力、应用使用模式和服务质量性能制定具有统计学意义的指标。更具体地，在根据上述第一实施例的第二实施例中，所述接收到的改进或替换也是基于类似位置的其它移动设备向所述数据采集和分析实体自动和重复上传，所述第一移动设备和类似位置的其它移动设备定义了所述自动和重复上传的来源人群。

在根据前述实施例中任一实施例的第三实施例中，所述远程服务至少部分地由软件即服务(softwareasservice，简称saas)提供商的云内资源提供。

在根据前述实施例中任一实施例的第四实施例中，所述移动设备的标识包括以下各项中的至少一项：所述移动设备的国际移动设备标识(internationalmobileequipmentidentity，简称imei)号；所述移动设备的制造商标识；所述移动设备所属的型号线的标识；所述移动设备的版本号的标识；所述移动设备的操作系统的标识；所述移动设备内的硬件资源的标识；所述移动设备内的固件资源的标识；所述移动设备内的软件资源的标识或所述移动设备立即可访问的软件资源的标识。

在根据前述实施例中任一实施例的第五实施例中，所述移动设备的应用使用模式(applicationsusagepattern，简称aup)包括以下各项中的至少一项：当前用作所述移动设备的前台可执行文件的一个或多个应用的标识；所述移动设备在预先指定的最近一段时间内使用的预先指定的n个最常用应用的标识，所述应用中的每个应用由标题、供应商编号、序列号和应用所属组或类别中的至少一个标识；当执行所述标识的n个最常用应用中的一个或多个时使用的平均复杂度的标识；所述移动设备在执行所述标识的n个最常用应用中的一个或多个时所花费的平均时间的指示；当执行所述标识的n个最常用应用中的相应一个或多个时可接受的相应最低服务质量的指示；当执行所述标识的n个最常用应用中的相应一个或多个时最有可能的相应位置和/或相应其它场景的标识；或者基于以下各项中的至少一项对所述标识的n个最常用应用进行的排序：使用所述相应应用或其所属子组的平均时间，即使电池电量低时也可使用所述相应应用的紧急性，在预先指定的位置和/或其它预先指定的场景中可使用所述相应应用的紧急性。

在根据前述实施例中任一实施例的第六实施例中，所述移动设备的资源使用模式(resourcesusagepattern，简称rup)包括以下各项中的至少一项：当前在所述移动设备中使用的一个或多个硬件和/或固件资源的标识；所述移动设备在预先指定的最近一段时间内使用的预先指定的n个最常用资源的标识，所述资源中的每个资源由类型、供应商编号、序列号和资源所属组或类别中的至少一个标识；当使用所述标识的n个最常用资源的一个或多个时使用的平均功耗或频率和电压的标识；所述移动设备在使用所述标识的n个最常用资源中的一个或多个时所花费的平均时间的指示；使用所述标识的n个最常用资源中的相应一个或多个时最有可能的相应位置和/或相应其它场景的标识；或者基于以下各项中的至少一项对所述标识的n个最常用资源进行的排序：使用所述相应资源或其所属子组的平均时间、所述相应资源或其所属子组的功耗和能耗，在预先指定的位置和/或其它预先指定的场景中可使用所述相应资源的紧急性。

在根据前述实施例中任一实施例的第七实施例中，所述指示的服务质量(qualityofservice，简称qos)涉及以下各项中的至少一项：所述移动设备中当前正在执行的应用中的一个或多个提供的服务水平；所述移动设备在预先指定的最近一段时间内使用的预先指定的n个最常用应用提供的服务水平；所述移动设备中当前使用的硬件和/或固件资源中的一个或多个提供的服务水平；或者所述移动设备在预先指定的最近一段时间内使用的预先指定的n个最常用资源提供的服务水平。

在根据前述实施例中任一实施例的第八实施例中，所述接收所述移动设备的电源管理策略的改进或替换包括：为所述移动设备的一个或多个调节器接收电源管理策略的改进或替换。

在根据前述实施例中任一实施例的第九实施例中，所述接收所述移动设备的电源管理策略的改进或替换包括：为所述移动设备的cpu缓存调整控制器接收电源管理策略的改进或替换。

在根据前述实施例中任一实施例的第十实施例中，所述接收所述移动设备的电源管理策略的改进或替换包括：为所述移动设备的预先指定的硬件或固件资源的动态使用控制器接收电源管理策略的改进或替换。

提供本发明内容是为了以简化的形式引入概念的选择，这些概念将在以下具体实施方式中进行进一步的描述。本发明内容的目的不在于识别权利要求书保护的主题的关键特征或必要特征，也不在于帮助确定权利要求书保护的主题的范围。

附图说明

图1是根据各种实施例的用于跟踪特定用户使用的特定移动设备的功耗性能并更新其电源管理子系统以根据特定使用模式优化电池续航能力的系统的方框图。

图2a是示出了根据各种实施例的给定特定用户如何可以具有可预测的使用模式的示意图；

图2b是示出了根据各种实施例的如何使用众包来采集具有统计学意义的使用数据以提供更快速的更新的示意图；

图3a是描述了根据各种实施例的第一性能跟踪和优化方法的流程图；

图3b是描述了根据各种实施例的第二性能跟踪和优化方法的流程图；

图4是描述了根据各种实施例的用于数据采集和分析实体的数据上传和策略生成方法的流程图；

图5是描述了根据各种实施例的所述数据采集和分析实体进行的分析的流程图；

图6是描述了根据各种实施例的根据本发明的系统的三种类型可操作互连引擎的方框图。

具体实施方式

图1是用于跟踪特定移动设备110a、110b、……、110n及其各自用户u1、u2、……、un的功耗性能并更新其各自电源管理子系统(例如，调节器145)以基于本发明的跟踪优化电池续航能力的系统100的方框图。

更具体地，图1示出了具有电池供电的移动客户端设备(例如，智能手机110a、110b、……、110n)且可以应用本文公开技术的集成客户服务器/互联网/云系统100(或更一般地说，即集成多设备系统100)。所述系统100也可以被称为软件即服务(softwareasaservice，简称saas)服务的分布式资源、机器系统，其中提供了各种不同位置的数据处理和数据通信机制，包括例如，客户站点单元(例如，无线智能手机、平板电脑、笔记本电脑等表示为110a-110n或通常表示为110)，所述客户站点单元用于允许其终端用户(例如，u1)从不同位置的服务主机(例如，云内服务器131、132、……、13n)请求其各自的终端用户占用位置(例如，locu1)服务，所述服务通常被认为在云130中。

应理解，所示系统100的配置仅仅是示例性的，根据本发明的特定用户设备的功耗管理可以从除所示云130之外的其它位置执行。根据图1应理解，所述系统100至少包括少数(但更典型的是包括大量，例如，数千个)终端用户设备110a、……、110n(仅有少数以无线智能手机的形式示出，但应理解为代表许多类似位置的移动和/或固定客户端机器，包括所述智能手机无线客户端类型和有线连接的桌面类型)。这些终端用户设备在本文统一标为110，并且有多种形式，包括不同的品牌(例如apple^tm、android^tm等)、不同版本(例如2015、2016、2017等)、不同大小和不同内部资源，后者资源中可以包括不同的cpu′s、不同的操作系统、不同的软件应用、不同的通信能力等。换言之，每个用户可以拥有为该用户定制的特定移动或其它电池供电的数据处理设备(例如，至少是由于该用户安装和运行的特定应用)。虽然下面的描述通常将特定的电池供电的数据处理设备(例如，移动设备)描述为连续被单个用户控制，但是在本发明的考虑范围内，对特定的电池供电的数据处理设备(例如，移动设备)采用类似的跟踪和电源管理调整，所述特定的电池供电的数据处理设备(例如，移动设备)由特定的人员组控制，其中所述组可以具有特定的使用模式。例如，教室用笔记本电脑可以由一组学生共享，并且所述使用模式可以根据所述学生是五年级历史班还是博士级工程班而变化。

各种终端用户设备110包括一个或多个特定应用(“应用”)，每个特定应用能够发起并发送最终转发到云环境130内的服务提供主机(例如，云内服务器131、132、……、13n)的服务请求。此后，通常将来自所述服务提供主机的结果返回至终端用户设备110，其中，所述结果中的一些结果被显示和/或以其它方式(例如，通过音频方式)传送至所述终端用户(例如，u1、u2、……、un)。发送请求通常耗电(电能通常来自所述移动设备的电池)。结果的显示和/或音频输出(例如，流媒体视频电影或实时动作游戏)通常也会耗电。因此，功耗可以是每个特定客户端设备的相应用户的特定使用模式的函数。

所述各种终端用户中的每个终端用户在每个特定客户端设备上的使用模式可能不同，至少是因为设备上安装了不同应用程序的设备和/或具有特定设备输入/输出装置(例如，键盘、触摸屏、语音控制等)。更具体地，作为第一示例，第一终端用户(u1)可以在所述用户的智能手机(110a)上安装第一软件应用(“app1”)，所述第一软件应用(“app1”)自动重复且经常地从所述云请求和下载流式视听娱乐使得所述第一用户的智能手机110a持续显示所述流式视听娱乐，其扬声器持续播放音乐，且其通信模块(例如147)自动重复地发送对更多流式视频馈送的请求(例如，蜂窝电话中介请求)。在这种电能需求的使用模式出现期间，电池的排水会比较大。另一方面，第二终端用户(u2)可以在所述用户的智能手机(110b)上安装不同的应用(app2)，所述不同的应用(app2)不对所述本机显示、音频装置和/或本地通信模块执行重复的功率需求作业。因此，对所述第二客户端设备110b的移动电源的需求可能不太严格。每个用户(u1、u2、……、un)可以具有基于每天习惯(或基于每种场景)的各自唯一的使用模式。或者，在本发明的考虑范围内，确定每个用户属于一组学习的分类使用类别中的哪一类。根据本发明的一方面，应用使用模式(applicationusagepattern，简称aup′s)的信息存储在元数据(关于其它数据的数据)中，并上传到中央处理点进行分析。

正如各个用户可以具有特定的应用使用模式(applicationusagepattern，简称aup′s)一样，特定的应用或这些应用的分类可以在所述不同移动设备的特定应用中具有相应的资源使用模式(resourceusagepattern，简称rup′s)。所述aup′s和所述rup′s的组合通常会影响从所述移动电源提供所需服务质量(qualityofservice，简称qos)所消耗功率的速度。在某些情况下，如下文所详述，可以智能地管理电源，以减少功耗、延长电池续航能力并提供合理可接受的qos(例如，对特定用户、特定用户组或子组或至少大多数用户都是合理可接受的)。根据本发明的一方面，关于资源使用模式(resourceusagepattern，简称rup′s)的信息存储在元数据(关于其它数据的数据)中，并上传到中央处理点进行分析(例如，作为数据采集和分析实体的示例协同工作并提供相应远程服务的一个或多个远程saas提供商)。

虽然上面列出了采集和分析关于设备分类的元数据、应用使用模式(applicationusagepattern，简称aup′s)和资源使用模式(resourceusagepattern，简称rup′s)的各种可能性，但在一实施例中，所述待采集的元数据被细分为主元数据或核心元数据以及次要元数据，其中，如果通信和/或处理带宽有时受限，则可以绕过次要元数据的采集。所述核心元数据例如可以包括：用于识别每个设备及其硬件类别的设备国际移动设备标识(internationalmobileequipmentidentity，简称imei)和设备型号标识；用于根据各自监控软件类别识别每个设备的当前os版本；用于根据各自应用软件类别识别每个设备的当前运行的应用的id和版本号；用于根据各自当前资源配置和每个核心资源(例如cpu、内存、gpu)的当前功耗识别每个设备的核心资源使用模式(resourceusepattern，简称rup)。其它因素(如温度、湿度、位置等)可以认为是次要的。

除了上述终端用户设备(例如，110)和所述云内服务器(例如，131、132、……、13n)之外，所述系统100通常包括：一个或多个有线和/或无线通信网络115(仅一个以无线双向互连的形式示出)，所述有线和/或无线通信网络115将终端用户客户端110耦合到网络服务器120(未显式示出，并且可以是内联网或互联网的一部分)，其中，后者可以通过进一步的有线和/或无线通信网络125(未显式示出)与设置在云130中进一步联网的服务器(例如，131、132、……、13n)进行操作性耦合。

所述第二组联网服务器130被描述为“云”130，其目的是指示一组云状、不断变化、持续演进的硬件、固件和软件资源。云内资源通常被大型企业运营所使用，目的是使任务关键型任务不受不必要的中断。如云计算领域的技术人员所理解的，“云”130可以实现为可重构的虚拟服务器和虚拟软件模块，所述虚拟服务器和虚拟软件模块在相对无缝的物理服务器、存储单元(包括闪存bios单元以及光和/或磁和/或固态存储单元)、通信单元等网络中实现，从而通过将所述支持的虚拟资源移动到所述物理层中的其它备用支持区域来克服所述物理层中特定单元的点故障。由于资源规模大，而且其结构不断变化和自重配置，对所述系统100的所有硬件和软件资源进行监控和管理非常困难。后一项任务通常委派给具有云内资源和跟踪各种系统组件性能参数的能力的saas(软件即服务)提供商，其中所述系统组件性能参数包括终端用户设备110的自上报参数。更一般地说，本文可以将所述saas提供商视为提供相应远程服务的相对集中的数据采集和分析实体的示例，尽管该数据采集和分析实体的特定资源本身不需要集中放置，而是可以分布在网络上和/或在云中实现。在本发明的考虑范围内，多个saas提供商可以联合协作地提供本发明公开的数据采集和分析操作，其中所述协作的多个saas提供商因此成为用于实现本发明目的的数据采集和分析实体。saas随着时间的推移采集来自类似位置的移动设备中的单个或多个移动设备的数据可以建立数据库，所述数据库的记录可用于发现设备制造和/或型号和/或应用使用模式(applicationusagepattern，简称aup′s)和/或资源使用模式(resourceusagepattern，简称rup′s)与相应的能耗最小化策略之间的相关性，同时仍然提供用户可接受的服务质量(qualityofservice，简称qos)。根据本发明各种实施例的系统可包括：安装在所述一个或多个移动设备中并用于自动重复上传至远程服务的自动上传装置：指示所述设备标识的数据；指示所述设备当前应用使用模式(applicationusagepattern，简称aup′s)的数据；指示所述设备当前资源使用模式(resourceusagepattern，简称rup′s)的数据；指示所述设备当前能耗或功耗的数据以及指示当前服务质量与用户可接受的服务质量(qualityofservice，简称qos)之间差异的数据。所述saas采集的数据存储在数据库中，然后通过分析器装置自动重复分析，以识别类似位置的移动设备以及相应的能耗最小化策略，所述能耗最小化策略根据每个移动设备当前运行模式的当前aup′s、rup′s和/或其它场景方面提供用户可接受的服务质量(qualityofservice，简称qos)。所述saas提供商提供自动下载装置和相应能耗最小化策略，所述自动下载装置用于下载到所述远程移动设备，所述能耗最小化策略根据每个移动设备当前运行模式的当前aup′s、rup′s和/或其它场景方面提供用户可接受的服务质量(qualityofservice，简称qos)。这种系统的优点在于，数据采集可以在所述后台进行，并且可以自适应地改变以满足不断变化的应用使用模式。这种系统的众包版本的优势在于，可以更快地从一批类似位置的移动设备中采集数据，并下载更优化的数据，从而使能耗最小化策略发生得更快。

继续参考图1，这里提供了快速路径图，让读者可以一览整个情况。项目111表示可以从示例性移动客户端110a(例如，智能手机，但可以是平板电脑、笔记本电脑、可穿戴计算设备；即智能手表等)内启动的第一个安装和用户可激活的软件应用(第一移动应用)。项目112标识第二个这种用户可激活的软件应用(第二移动应用)，并且通常还有更多的用户可激活的软件应用。每个终端用户安装的应用(例如，111、112、……)可以以非瞬时性记录的数字代码(即，目标代码或源代码)的形式出现，所述非瞬时性记录的数字代码定义并存储在存储器中，用于指示目标类别的数据处理单元根据终端用户定义的应用程序(简称为“移动应用”)执行以及与通信链路115和/或125的另一侧上实现的服务器侧应用合作。每个应用(例如，111和112)可以来自不同的业务或其它企业，并且可能需要各种不同在线资源(例如，互联网、内部网和/或云计算资源)的协助来执行其任务。通常，每个企业负责使其在所述分布式系统(例如，互联网、内部网和/或云计算资源)中的各部分保持良好的运行秩序，从而使最终用户体验到令人满意的服务质量(qos′s)。为了简单起见，这里假设一个saas提供商(数据采集和分析实体的一个示例)已被指定管理包括所有或大多数终端用户设备110的电源管理方面的所有在线资源。在更实际的环境里，多个企业或其它企业可以将其部分资源汇集到由单个saas提供商监控的资源的共同核心中，从而降低运营成本。根据本发明的一方面，各种不同移动用户设备110的供应商要求单个saas提供商处理其各自设备110的电池续航能力优化。

如上所述，各种终端用户设备110(例如，特定品牌)中的功耗可以是除当前安装的且最常被各个用户作为其最常用应用使用的应用之外的多个变量的函数。位置(包括当地温度条件、气压、湿度等))和各种通信装置的无干扰可用性是其它因素。更具体地，一个用户的智能手机(例如，110a)可以主要依赖于通信网络115的蜂窝电话业务提供部分，并且通常可以在较热位置上运行，使得内部半导体组件(例如，qn、qp)运行时温度往往相对高。另一用户的智能手机(例如，110b)可以主要依赖于wifi^tm或bluetooth^tm，并且通常可以在较冷位置上运行，使得内部半导体组件(例如，qn、qp)运行时温度往往更低。当用于不同的最常用应用、不同的设备品牌和/或版本以及在不同的终端用户位置(例如，locu1、locu2)上使用时，而且当受到相应不同的温度和湿度影响和/或使用不同的通信资源(例如，蜂窝、wifi^tm等)在不同通信干扰条件下工作时，所述电源管理saas提供商(未明确显示，被理解为具有13n等云服务器)了解相应终端用户和/或其设备110(例如，特定品牌)的这些操作条件并定制其设备如何运行电源管理可能是有利的，这样尽管在不同的特定硬件平台中使用不同的应用和/或在不同的环境和/或不同的条件下由不同的特定固件平台支持，但是每个最终用户都具有令人满意的电池续航体验。

在一实施例中，移动设备110的至少一个子集(例如，同意其使用情况被监控的各自用户的设备)被插桩，使得在所述背景中，所述移动设备自动重复地提供有用的功耗相关数据和性能相关数据(例如，qos)，例如，所述saas提供商(例如，服务器13n)在不同情况下可用于监控其各自用户设备的功耗和性能所采集的元数据，其中，所述相关数据的采集可以针对不同的最常用应用、不同的设备品牌和/或版本在例如具有代表性温度条件和/或通信能力的不同位置(例如，locx1、locx2、……、locxn)执行。

插桩可以从一个用户设备(例如，110a)变化到下一个用户设备(例如，110b)。一些设备可能具有内置的功率测量传感器(未示出，可以是153的一部分)，其直接测量在不同时间和不同条件下从所述移动设备电池系统中消耗的功率。通常情况并非如此。然而，特定客户设备消耗的功率量可以从许多代理因素中推断出来，例如，提供给数字逻辑电路(例如，141a′)的电流时钟频率(clockfrequency，简称clk)和电流dc电压(dcvoltage，简称vdd)。在放大率140中描述了部分仪器化移动设备的示例。所述插桩移动设备可以具有各自的本地操作系统(例如，appleios^tm或android^tm)，并且可以包括从api(应用程序编程接口)至各种本地应用(例如，111、112、……)。它还可以包括插桩执行代码，其中所述插桩部分使各种元数据自动嵌入到设备140的中继往返于saas服务器13n的往返通信包中。这些嵌入元数据的示例可以包括以下各项的指示：时间(时间戳)、当前功耗水平、当前运行的前台应用、当前位置、当前温度、当前终端用户id、本地操作系统的类型、当前使用的蜂窝载波或wifi^tm业务的id等。所述嵌入的元数据由后端saas服务器上传和采集，并根据本发明用于确定移动设备110n在不同运行条件下的功耗和性能。上传的元数据还可以提供关于每个相应用户的应用使用模式(applicationusagepattern，简称aup′s)以及每个相应和特定客户端设备的资源使用模式(resourceusagepattern，简称aup′s)的信息。

移动应用(例如111、112)、移动操作系统(os′s)、终端用户设备(例如110a、110b、……)和通信模式(例如115)不断变化。因此，saas提供商(例如，13n)可能需要不断更新其为现场和新引入的移动设备处理已安装的电源管理代理(例如，调节器145)的方式。本发明提供了用于进行此类操作的方法和系统。

终端用户设备(例如，110a、110b、……)的内部资源通常细分为具有不同职责和/或能力的部分。此处以示例性设备110a的内部放大图140为例说明各设备部分。后者设备部分可以包括有限数量的互连的“本地”资源，例如一个或多个本地数据处理单元(例如cpu′s141)、一个或多个本地数据存储单元(例如ram′s142、rom′s143、磁盘146，例如ssd′s)、一个或多个本地数据通信单元(例如comm单元147)和本地骨干(例如本地总线149)，这些资源可操作地耦合在一起并可选地耦合到本地资源148中的其它本地资源。所述其它本地资源可以包括但不限于专用或通用传感器153，其包括用于自动确定设备位置、本地温度、本地时间、海拔高度等的传感器(例如，gps)。其它传感器可以包括一个或多个摄像机、麦克风、辐射检测器(例如，rf能量)等。可以有用于闪光摄影、夜视等的光源或其它信号源。还可以包括专用高速图形处理单元(graphicsprocessingunit，简称gpu′s，未示出)、专用高速数字信号处理单元(digitalsignalprocessingunit，简称dspu′s，未示出)、定制可编程逻辑单元(例如，programmablelogicunit，简称fpga′s，未示出)、模数接口单元(模数接口单元，简称a/d/a单元，未示出)、并行数据处理单元(例如，simd′s、mimd′s，未示出)、本地用户界面显示器(例如，156)等。

应理解，仅所述示例性和图示的“本地”最终用户资源部分(例如141-148、156等)中的各种部分可以包括或可以分为更细化的类型。例如，所述本地cpu′s(仅将一个示出为141)可以包括单核、多核和与gpu集成的类型。所述本地存储单元(例如，142、143和146)可以包括高速sram、dram类型以及用于可重编程的非易失性固态数据存储(solidstatedatastorage，简称ssd)和/或磁和/或其它相变类型。所述本地通信实现单元(仅将一个示出为147)可以可操作地耦合到串行、并行、光学、有线或无线类型等各种外部数据通信链路，通常根据预定通信协议(例如，互联网传输协议、tcp/ip；wifi^tm；蓝牙^tm)中的各种通信协议进行操作。类似地，所述其它本地资源(仅将一个示出为148)可以可操作地耦合到各种外部电磁或其它链接148a，并且通常根据各种预定操作协议进行操作。此外，各种本地软件和/或固件可以可操作地安装在所述本地存储单元(例如142、143和146)中的一个或多个，用于由所述本地数据处理单元(例如141)执行并用于彼此之间进行可操作交互。所述各种本地软件和/或固件可以包括不同的操作系统(os′s)、不同的安全特征(例如，防火墙)、不同的网络程序(例如，web浏览器)、不同的应用程序(例如，文字处理、电子邮件、电话、电子表格、数据库、多媒体娱乐等)等等。

所述本地设备资源中包括至少一个插装性能跟踪器155，插装性能跟踪器155可操作地耦合到所述其它资源中的各种资源(例如，通过链路155a到骨干149和/或通过链路155b到特定资源，例如145、151、152、153)，使性能跟踪器155可以将有用的性能指示数据转发到所述saas提供商13n进行分析和反应。根据本发明，所述包括的性能跟踪器155使远程的saas分析器(例如，13n)可以发现新出现的问题(例如，与电源管理和电池续航能力相关的问题)，并尝试缓解这些问题和/或改善性能，而不必在每个用户的位置(例如，locu1、locu2、……、locun)都物理上存在。在一实施例中，一种自动化的人工智能分析器13m依靠例如专家规则知识数据库，使用随时间变化制定规则(例如，启发式开发规则)来解决监控所述系统100内的不同问题，包括基于所述单个用户及其各自的特定客户端设备的特定应用使用模式(applicationusagepattern，简称aup′s)和特定资源使用模式(resourceusagepattern，简称rup′s)在特定客户端设备(110a、110b、……、110n)内调整功率控制的问题。虽然这一命题用肯定形式表述，即确定aup′s和rup′s在特定场景中是什么(例如，在特定时间和/或特定地点使用的最常用应用)；应理解，节电也可以用该命题略微修改的否定形式表述，即针对相应的场景确定哪些应用不是最常用的(并且应该置入睡眠模式中)和/或哪些设备资源是不需要的(并且应该置入睡眠或关闭模式中)和/或哪些高端性能质量(例如，qos′s)不被要求，从而基于所述确定的特定应用模式(applicationusagepattern，简称aup′s)和特定资源使用模式(resourceusagepattern，简称rup′s)，减少在不同场景中使用的单个用户及其特定客户端设备和特定应用程序的功耗。所述不必要的应用和/或设备资源和/或哪些高端性能质量可以基于确定相应的当前场景而相应地置入睡眠模式或关闭模式中。

应理解，不必对每个终端用户设备(110a、110b、……、110n)进行监控，而且不必对每个此类终端用户设备在经常重复的时间进行监控。根据本发明的一方面，仅每个预定类别的终端用户设备和/或代表用户(例如，u1、u10、u20、……、un--并非全部示出)的代表子集(例如，10％)需要随机或基于错时轮循调度报告一天中不同位置和/或不同时间的应用使用模式(applicationusagepattern，简称aup′s)和资源使用模式(resourceusagepattern，简称rup′s)。在一实施例中，要求各类设备的用户自愿让用户选择其类内设备参与所述使用监测和报告过程。对自愿用户的请求可以向预期自愿用户解释，这是一种众包过程，其中，自愿用户参与不仅有利于自己的利益，而且有利于所有将在不同条件下使用所述各自类别设备的用户的更大利益，所述不同条件例如包括不同地理位置、一天中的不同时间、不同天气条件和/或不同其它环境。理想情况下，所述自愿用户充分分布，能够为所述相应不同条件和/或这种不同条件的组合提供具有统计学意义的样本。如下文结合图2b所示，对数据进行众包采集可以导致采集时间缩短和更新速度加快。所述saas提供商(13n)累积所述代表用户的稀疏报告的aup和rup使用模式数据并将其组合(聚合、存储、分类、自适应地将其转换为机器学习专家规则)，以便在识别出的不同操作条件中的相应条件下，为终端用户设备110所代表的类别和/或终端用户(u1、……、un)所代表的类别生成统计代表性数据。稀疏分布式报告过程有几个优点。它不会消耗任何一个终端用户设备的大量功率。它不会增加任何一种通信路径的带宽利用率。如果一些通信路径目前处于下降状态，则仍通过其它仍在运行的路径获得代表性数据。代表终端用户设备110和代表终端用户的整个用户群体可以受益于saas对从所述插装终端代表用户设备/用户(例如，110a/u1)中采集的性能数据的分析，以及受益于saas对从改进的电源管理固件和/或因该性能数据采集和分析而下载和安装的参数中采集的性能数据的分析。

确定和/或控制本地功耗的一种技术称为动态电压频率调整(dynamicvoltageandfrequencyscaling，简称dvfs)。基于数字电路功耗的建模，所述功耗由两个主要分量组成：(a)由于电容负载加时钟振荡速率而消耗的动态功率(dynamicpower，简称pdyn)和(b)由于例如在高温和/或高电压下运行而消耗的静态功率泄漏(staticleakageofpower，简称pleak)。求和公式可以表示为：ptotal＝pdyn+pleak。所述分量可表示为施加电压的函数，且当前使用的时钟频率如下：

pdyn＝α·cl·v2·f

pleak＝vdd·ileak

在上述公式中，α是表示所述电路的动态切换活动的活动因子(例如，由于不同应用对所述电路的密集与低密集使用)。其中，cl为所述电路的负载电容，vdd为所述施加的直流电压，f为所述时钟频率，ileak为当前温度和/或所述当前施加的dc电压vdd引起的当前漏电流量。代表电路如图1的141a所示，其中代表电路141a被理解为位于数字逻辑电路141’内，并且数字逻辑电路141’可以是本地cpu141的一部分或者其它本地数字逻辑电路的一部分。所述示例描述了cmos电路，所述cmos电路具有p型第一mosfetqp和n型第二mosfetqn，所述n型第二mosfetqn与从可变dc源施加到qp的的vdd以及根据给定的活动因子α施加到qn和qp的连接门的时钟信号clk串联。在一实施例中，自动调节器模块145a自动确定将应用哪对vdd和时钟频率f。进而，这可以确定给定活动因子α和外部因素(例如温度)的当前功耗。虽然示出了一个调节器145a耦合到相应一个逻辑电路141a，但是应理解，现代客户端设备可以具有多个此类调节器，每个所述调节器耦合到客户端设备的不同部分(例如，110a)，并且所述每个调节器根据其自身的电源管理规则或参数运行。更具体地，每个cpu(例如141)或其它此类处理器(例如gpu)可以具有各自的调节器和/或预先指定的处理器组可以共享各自的调节器。每个存储器单元(例如，142、143和146)可以具有各自的调节器和/或预先指定的存储器单元组可以共享各自的调节器。每个通信单元(例如147)可以具有各自的调节器和/或预先指定的通信单元组可以共享各自的调节器等。当从一个(vdd，f)配置切换到下一个(vdd，f)配置时，所述每个调节器可以具有自已的输入集合(如145所示的“输入”)。通过确定特定客户端设备中的所有调控器的当前(vdd，f)配置，以及确定所有在用电路的α活动因子和电容负载(capacitiveloading，简称cl)，可以通过代理估计所述设备的总当前功耗。可选地或附加地，可以通过检测分别使用的资源的各自调节器保持在一个(vdd，f)配置中多长时间来确定每个应用的当前功耗，然后基于为该应用建立的自动调控器策略规则切换到下一个配置。当根据用户通常如何使用该应用(而不是根据所谓的“高级用户”如何最大限度地着重使用该应用)时，还可以确定当前的每个自动调节器策略规则的应用集是否是最佳(在能耗最小化方面)。在一实施例中，通过采集使用分析数据确定每个特定用户或特定类别用户如何实际使用并着重使用每个相应的应用，其中所述采集的使用分析数据随后可用于为所述相应特定用户或特定类别用户创建更优的(在能耗最小化方面)自动调控器策略规则。根据本发明的各种实施例，可以在自动重复测试时为预先定义的条件以及基于检测到的条件对所述客户端设备的内部管理者和/或其它电源管理控制器的设置所做的相应修改，提供所述客户端设备的内部调节器和/或其它电源管理控制器的相应策略规则。在一实施例中，当满足触发条件或通过分支转到闭合且自动重复执行环路的下一个测试时，每个策略规则可以包括对所述触发条件的测试(例如，硬件，实现iftrig1＝truethenaction1else......软件的固件，有条件执行或分支操作)并执行相应的控制器修改动作。

电源管理不限于动态电压频率调整(dynamicvoltageandfrequencyscaling，简称dvfs)。在基本数字逻辑电路级之上，已经提出了各种微架构技术来提高能量效率，例如：(a)cpu缓存调整(《acm计算调查》2013年6月第45卷第3期中的w.zang等人撰写《关于从功率/能量角度进行缓存调整的调查》)；(b)存储器压缩(2002年第449-453页《欧洲设计、自动化和测试》中的l.benini等撰写的《用于在嵌入处理器的系统中实现能量最小化的硬件辅助数据压缩》)；(c)使用非对称内核，例如arm的big.little架构(www.arm.com/products/processors/technologies/biglittleprocesing.php)。由于所述操作系统(operatingsystem，简称os)在控制系统行为中的特殊作用，在操作系统级别上有大量的能量感知资源管理技术，其中许多技术已被诸如linux之类的流行操作系统采用。dvfs最初仅限于所述cpu，现在也可用于管理gpu′s、内存带宽、总线等。如前所述，每个设备可以在每个部分分别具有单独的调节器(例如，图1中的145a)，其旨在根据qos等需求提供该部分的管理功率性能。在一些系统中，实现了缺省空闲策略，其中，即如果所述组件未被使用，则该组件将进入低功率空闲状态，从而实现节电。

这些上述技术属于通用系统类型，因为这些技术通常被设计为解决移动设备的整体能效，而不考虑在哪些场景中正在执行哪些应用和/或在哪些地理位置和/或由哪些用户(或用户类型)在哪些场景中执行的具体情况。它们不仅是关于应用运行的通用目的，而且也是关于使用哪个品牌、大小、类型的移动设备的通用目的。对基于电池的电源系统的功耗实现有效管理可能取决于特定的终端使用模式和特定客户设备品牌的特定版本。在大多数情况下，每个设备上的每个用户的硬件特性和/或使用特性将显著不同。此外，随着每个设备的老化，其性能可能以显著的方式恶化。管理性能和电池续航能力的“一刀切”策略往往效率低下，可能导致用户体验不佳。根据本发明的一方面，为在消耗较少电池电量的同时实现用户可接受的性能，进行与当前电源管理相关的自动重复数据采集，其中所采集的数据包括当前用户的特定数据(例如，用户当前运行的应用的类型)、所述当前位置及其条件的数据(例如，温度、气压、通信选项等)，所述移动设备的特定数据(例如，年龄、可用速度、显示分辨率等)。

更具体地，根据本发明，将与每个特定移动设备(例如，特定品牌、版本)相关的功耗和性能跟踪元数据上传到所述云(或数据采集、集中和分析实体的另一种形式)，以便能够在所述云(例如，在图1的13n.2和13m内)内自适应学习特定应用使用模式、特定应用运行时间性能、每个特定设备特有的硬件特征或每个设备操作环境(例如，温度，海拔等)特有的这类设备的特定类别等等。然后，所述自适应云内学习用于动态地生成专家规则，所述专家规则用于生成电源管理策略，以在保持用户可接受的性能水平(例如，qos)的同时，提高在所述特定机器品牌和/或版本和/或其差异化类别中运行的应用的能量效率。再次，尽管这一命题用肯定形式表述，即在特定场景(例如，特定品牌、版本、最常用的应用、最常用的通信链路、典型时间和/或典型地点)中确定所述aup′s和rup′s是什么；应理解，节电也可以用该命题略微修改的否定形式表述，即针对相应的场景确定哪些应用和/或设备资源不应该(不需要)处于相应场景的耗电运行模式中，其中所述相应场景是通过自动确定(跟踪)所述单个用户及其特定客户端设备的特定应用模式(applicationusagepattern，简称aup′s)和特定资源使用模式(resourceusagepattern，简称rup′s)发现的。然后，基于对相应单独用户的相应当前场景的自动检测，所述不必要的应用和/或设备资源可以相应地置入休眠或关闭模式中。

基于特定场景检测的优化过程分为三个阶段：(1)第一，自动采集指示单个用户及其特定客户端设备的场景和应用使用模式(applicationusagepattern，简称aup′s)和资源使用模式(resourceusagepattern，简称rup′s)的有用元数据；(2)第二，在大量集中所述采集的数据之后，使用自动机器学习来发现和分类各种设备(或设备类别)的设备使用特征和/或各种用户(或用户类别)的设备使用特征，其中，该学习可以包括识别和分类各个设备类别和/或用户类别以及所述各个设备中的相同功耗和服务质量的结果；以及(3)第三，在适当的时候，基于所述学习的使用模式及其结果来调整(或替换)每个特定设备上(或针对移动设备的每个特定类别)运行的电源管理控制器(例如，调节器)，以关闭或减少在所述分类的场景中引发不必要功耗的因素。

然而，基于个人化一次一个用户采集所述使用元数据存在问题。并不是所有用户都一直使用各自的设备，而是当他们使用该设备时，他们可能不会每次都使用每个应用程序。因此，基于个人化采集使用元数据的系统可能需要等待很长时间，才能针对给定的单个用户采集具有统计学意义的使用数据。用户到那时可能会改变电话(或移动设备的电话)，也可能改变所使用的应用，或者所述操作系统(operatingsystem，简称os)版本和/或其它监控固件/软件也可能会改变。然后，基于个人化采集的元数据可能会过时。

根据本发明的一方面，将用户分为使用基本相同或相似的移动设备的用户组，以及在基本相同或相似的场景中使用基本相同或相似的应用的用户组。在所述云中(或者在另一合适的数据采集和集中实体的存储资源中)对采集到的所述子组的元数据进行排序，并根据分类的组或子组进行聚合，以定义众包采集的元数据，因此，采集代表性使用模式数据的速度比所述系统必须等待基于个人化采集的速度快得多，从每个单独用户的一个或多个个人移动设备获得具有统计学意义数量的使用数据。然后，基于所述众包采集的元数据的分析结果，即使每个定义的子组中的一些成员没有参与提供关于其各自应用使用模式(applicationusagepattern，简称aup′s)、资源使用模式(resourceusagepattem，简称rup′s)、能耗或功耗模式以及相应的服务质量(qua1itiesofservice，简称qos′s)的上传数据，也将对各自移动设备的电源管理策略的改进或替换下载到各自子组的成员中。在一实施例中，下载到每个单独移动设备的电源管理策略规则或其改进仅为该一个移动设备的应用使用模式(applicationusagepattern，简称aup′s)所必需的。

数据采集和关联机器学习

如上所述，由于不同人之间的使用模式不同，每个设备的可采集元数据可以具有特有的变化。此外，所述内部硬件本身可能因不同的移动设备而不同(例如，在散热特征、显示功耗特征、模拟发射器特征等方面)。同一品牌的不同型号可以具有非常不同的硬件以及相应不同的性能和能耗特征。

根据本发明的一方面，在所述移动设备上安装性能跟踪应用(和/或固件和/或软件补丁)，以尽可能利用所述特定移动设备以及在其上运行的os和消费者应用程序收集使用统计数据，优选地在不同的操作条件下，例如在不同的地理位置、在一天的不同时间、在不同的天气条件下和/或在不同的其它背景下。如果安装了这种额外的软件支持，则在每个场景中运行的消费者应用程序(例如，一天中的时间、位置等)设定在特定的移动设备中以及在相应的场景中采集其特定的性能信息。当新移动设备被终端用户购买时，所述新移动设备及其每个终端用户被分配相应的云存储空间(例如，在数据库中)，其中可以存储所述新移动设备及其一个或多个终端用户的所有采集的元数据。机器学习算法在所述云中运行，并且随着时间的推移就所述插装移动设备在不同地理位置、在一天中的不同时间和/或在运行不同终端用户应用程序的其它场景状态下如何执行(在功耗和qos方面)学习自动和重复上传的相关信息。所述机器学习算法定期更新所述插装移动设备及其各自的一个或多个用户特有的一组参数。自适应专家规则被自动制定并存储在数据库中，用于将场景与应用使用模式(applicationusagepattern，简称aup′s)和资源使用模式(resourceusagepattern，简称rup′s)进行关联。例如，馈送到所述机器学习算法中的所述采集的元数据可用于制定专家规则，以预测当第一特定应用将最常使用，而一个或多个其它应用不被使用或不需要时特定位置一天中的时间。然后，该使用模式信息可用于自动确定在给定场景中运行最可能的一个或少数耗电应用时，应何时自动关闭哪些其它应用或将这些应用置于空闲模式。因此，基于时间和/或位置或其它用户场景，可以分析使用模式数据并随后用于降低功耗。

电源管理控制器

所述电源管理控制器动态调整系统电源管理配置(dvfs是用于管理电源的多个可能的此类配置中的一种)，同时在相关场景(例如，时间、位置、用户场景)中特定应用在所述特定移动设备上运行。所述控制器的目的是为每个用户使用的当前运行的应用动态保持用户可接受的性能(例如，qos)，同时最小化功率和/或能耗。在一实施例中，每个终端用户为相应场景下的终端用户应用(或这些应用的类别)中的一个或多个指定可接受的性能目标，控制器相应动态地选择系统设置(例如，由每个相应调节器控制的已使用vdd电压和频率f对)，从而减少或最小化能耗，同时仍为所述特定应用提供所述期望或可接受的qos。较低的能量和/或功耗通常转化为较长的电池续航能力。

每类设备的电源管理控制器可以不同，并且可能需要所述特定设备(例如，老化设备)的特定数据来动态优化该特定设备中的功耗。例如，如表1a所示，对于在特定客户设备上运行且使用两个受控电路资源的给定第一应用(app1)，每个调节器在给定时刻具有各自选择的配置，则为该配置关联平均性能评级(qos--由适当的代理指标确定)和平均功耗(也由适当的代理指标确定)。通常，所述电源管理控制器的动态设置配置根据下载的策略进行本地调整，每秒一次，甚至更频繁(例如，每几毫秒一次)。虽然表1a的示例性电源管理控制器示出为具有两个调控器(gov_1和gov_2)，但更一般地说，电源管理控制器不限于特定数量的调控器，并且通常情况下，所述电源管理控制器将具有更多的部件，例如缓存调整部件、存储器压缩/解压缩控制部件等。对于给定的本地更新阶段，每个部件可以具有各自的配置。此外，针对qos和功耗给出的示例值可能不代表典型采集的分析数据。在其它示例(未示出)中，每个相应的行可以具有各自不同的qos值和各自不同的功耗值。虽然下面的表1a和表1b描述为具有少量的行和列，但在本发明的考虑范围内，一次一个或同时组合运行的不同应用或者每个应用的不同执行阶段(状态)具有更大和/或更复杂的表征表。例如，参见表1a和表1b下面的表1c。

表1a应用app1的分析数据

如表1b所示，对于在同一特定客户端设备上运行且使用两个受控电路资源的给定第二应用(app2)，可以为这些配置关联不同的平均性能评级(qos)和平均功耗。换言之，每个应用可能表现出不同的行为。

表1b应用app2的分析数据

表1a和表1b的qos和功耗(或能耗)指标可以是单个定量或定性指标之外的形式。例如，所述qos可以先包括几个单独的因素，然后再通过计算将qos缩减为单个指示。类似地，所述功耗/能耗可以先包括几个单独的因素，然后再通过计算将功耗/能耗缩减为单个指示。在一实施例中，所述本地特定客户端设备将其原始计算前数据上传至所述云，然后在所述云中进行所有计算。在其它实施例中，所述本地特定客户端设备可以在本地执行一些计算(例如，数据平均)，然后将部分结果上传到所述云中，然后进行进一步的计算。目标是最小化由于支持所述性能跟踪功能的本地计算和传输导致的能耗开销。

表1c应用app3的分析数据

如表1c所示，所述动态系统电源管理控制器的策略配置部件并不是只需要v/f设置调节器。例如，自动缓存调整器也可以加入。如表1c所示，所述性能参数不必限于每个应用的总(随着时间推移相加)性能，而是可以为每个应用的不同执行状态或阶段采集用于指示qos和指示功耗和/或能耗的单独参数。

当所述设备发货时，将所述动态电源管理控制器(例如，调节器g_1和g_2和/或缓存调整器cache_2)使用的设备特定配置策略计划设置为默认参数。然而，一旦终端用户开始使用设备，元数据(例如，原始数据或部分压缩数据)开始自动采集、上传并存储到所述云中。一旦采集到所述上传数据的预定临界数量并生成设备特定的新控制器优化策略计划，便会开始机器学习。然后，所述控制器优化策略计划或表示它们的增量可以作为空中(over-the-air，简称ota)更新数据下载到所述特定的客户端设备。更新后的具有新(更好)配置规则的控制器实现所述更新后的配置策略计划。在一实施例中，所述更新的配置策略计划自动改变策略，以响应检测到保证发生所述相应改变的相应场景。调用改变的场景可以是基于时间、基于位置、基于应用运行时间(其它应用程序有多少以及哪些正在运行)和/或其它。所述控制器可以按多种方式设计以响应确定的本地场景，例如：(i)用于所述整个设备的单一策略(类似于所述默认调节器设置，无论哪个或哪些应用正在运行)以及(ii)应用特定策略，其考虑使用何种优先级权重运行多少个和哪些特定应用。在这两种情况下，控制器策略计划都可以在所述云中定期更新。在一实施例中，所述云采集大约一周的性能跟踪数据，基于该周的性能跟踪数据确定所述特定客户端设备的平均应用使用模式(applicationusagepattern，简称aup′s)和平均资源使用模式(resourceusagepattern，简称rup′s)，并相应地生成对应的策略计划。如果所述终端用户早些时候在所述控制器策略中所做的改变，则只需将新控制器(或其增量)作为更新发送给所述移动设备。

参见图2a，其通过正常工作日的三个示例性部分示出了特定用户(u1)的可能用户应用使用模式(applicationusagepattern，简称aup′s)和相应资源使用模式(resourceusagepattern，简称rup′s)的时间轴示例200，其中，所述部分由第一时间范围201、第二时间范围202和第三时间范围203表示。

如图2a所示，在第一时间范围201内，所述对应的用户u1(例如，在正常工作周内)通常平均位于第一地理位置locu1a，具有表示为context_a的附加用户场景属性，并且具有在特定客户端设备(210a)上运行的第一组已安装应用(例如，211、212)，而所述已安装应用中的其它已安装应用(例如，213、214)处于空闲或关闭状态。

在一周时间内，针对第一用户u1特定的第一时间范围201，将元数据上传至所述云，以显示对应的一组使用模式231。将基于元数据的模式231划分为用户的应用使用模式集(aup1)和设备资源使用模式集(rup1)。为了避免说明杂乱，未示出所述上的数据的更详细方面，例如指示每个应用的服务质量(qualityofservice，简称qos)和每个资源的能耗或功耗的那些方面。如所述示例性第一组使用模式231所示，在第一时间范围201中，第一用户倾向于以较高的比率使用app1，以较低的比率使用app2，并且通常不使用app3。同样，对于所述给定的用户位置locu1a和/或其它用户场景属性context_a，所述特定客户端设备(210a)的第一资源即cpu1平均以中等比率运行，而第二资源(wifi)以较高比率运行，第三资源(显示器)也以较高比率运行，且通常不使用第四标识资源(照相机)。

如图2a进一步所示，在第二时间范围202内，所述对应的用户u1(例如，在正常工作周内)通常平均位于第二地理位置locu1b，具有表示为context_b的附加用户场景属性，并且具有在相同特定客户端设备(210a′；因为其处于另一状态而引发)上运行的第二组已安装应用(例如，215、216)，而所述已安装应用中的其它已安装应用(例如，217、218)处于空闲或关闭状态。

在同一周时间内，针对第一用户u1特定的第二时间范围202(例如，午餐时间)，将进一步的元数据上传至所述云，以显示对应的第二组使用模式232。将第二组基于元数据的模式232划分为用户的应用使用模式集(aup2)和设备资源使用模式集(rup2)。如所述示例性第二组使用模式232中所示，在第二时间范围202中，第一用户往往不使用app1，而是以中等比率使用app4并以高比率使用app3。同样，对于所述给定的用户位置locu1b和/或其它用户场景属性context_b(例如，驾驶汽车往返午餐地点)，所述特定客户端设备(210a′)的第一资源即cpu1平均以高比率运行，而第二资源(wifi)不运行，第三资源(显示器)以中等比率运行，且通常不使用第四标识资源(照相机)。

又如图2a所示，在第三时间范围203内，所述对应的用户u1(例如，在正常工作周内)通常平均位于第三地理位置locu1c，具有表示为context_c的附加用户场景属性，并且具有在相同特定客户端设备(210a″；因为其处于又一状态而再次引发)上运行的第三组已安装应用(例如，221、222)，而所述已安装应用中的其它已安装应用(例如，223、224)处于空闲或关闭状态。

在同一周时间内，但针对第一用户u1特定的第三时间范围203(例如，午餐时间后)，将进一步的元数据上传至所述云，以显示对应的第三组使用模式233。将第三组基于元数据的模式233划分为与第三时间范围203对应的用户应用使用模式集(aup3)和设备资源使用模式集(rup3)。如所述示例性第三组使用模式233中所示，在第三时间范围203中，第一用户往往以相对中等的比率使用app1，以高比率使用app2，也以高比率使用app5。同样，对于所述给定的用户位置locu1c和/或其它用户场景属性context_c(例如，午餐后)，所述特定客户端设备(210a′)的第一资源即cpu1平均以高比率运行，第二资源(wifi)以高比率运行，第三资源(显示器)以高比率运行，第四标识资源(照相机)以高比率附加运行。

考虑到在各自的时间范围201、202和203内从上传至所述云的元数据中导出的已识别的使用模式集231、232和233；所述云内的人工智能数据处理资源(例如，图1的13n)可以生成相应的基于时间和/或其它基于场景的电源管理策略，供特定客户端设备210a在本地使用，以最小化所述已识别特定资源用于所述各自已识别的使用模式集231、232和233的功耗和/或能耗。重要的是，当相应特定的应用集(如所述aup′s标识的)在所述相应位置中和/或在所述相应场景中(例如，在午餐之前、期间和之后)的其它场景下执行时，所述生成的电源管理策略是特定于特定用户设备210a的，并且可选地特定于该特定用户设备的正常状态的。此外，当所述生成的电源管理策略与特定应用或两个或多个特定应用的组合一起运行时可以特定于特定用户设备210a的特定资源使用模式。因此，可以更精细地调整所述生成的电源管理策略，以与所述使用的特定应用以及特定客户端设备210a的特定资源协同工作。这些电源管理策略不是与设备和/或应用无关的。

参考图2b，其示出了一种众包实施例250的示意图。这里，为每个特定品牌/版本的移动设备和/或为操作类似的每个特定类别的移动设备，从一个或多个相对大的自愿用户池(例如，u1’、u2’、……、un’)中自动采集使用模式数据。由于使用模式数据(例如，aup′s、rup′s)是从相对大的类似位置的用户池(例如，位置locuxa处的用户)中采集的(例如，在预先指定的数据采集周期中，例如，每小时、每3小时、每天等)，因此可以为分类的移动设备组以及相应分类的用户组和子组更快地采集具有统计学意义的使用数据，于是用于提供的更新快于基于为每个用户基于个人化采集的数据。更具体地，第一组被称为人群-a的用户251被描述为在包括第一用户的使用期251a1以及包括至少一个其它用户使用期(例如，251an)的预先指定的时间段内共享表示为locuxa的第一地理区域和/或共享表示为userx_context_a的第一其它场景属性。这里，一般形式的使用期参考标记251ym对应于命名为y的场景和/或命名为locy的位置以及命名为um′的用户，其中m′是1′和n′之间的标识，用于人群-a的用户u1′到un′。应理解，在一实施例中，地理位置和一天中的时间不被认为是对设备、资源使用模式(resourceusagepattern，简称rup′s)和应用使用模式(applicationusagepattern，简称aup′s)进行分类所需的核心数据，而是所述核心元数据例如可以包括：用于识别每个设备及其硬件类别的imei和设备型号标识；用于根据各自监控软件类别识别每个设备的当前os版本；用于根据各自应用软件类别识别每个设备的当前运行的应用的id和版本号；用于根据各自当前资源配置和每个核心资源(例如cpu、内存、gpu)的当前功耗识别每个设备的核心资源使用模式(resourceusepattern，简称rup)。其它因素(例如位置、时间、温度、湿度)可以视为次要因素。

移动设备210a1至210an由人群-a的用户u1′至un’在表示为locuxa的第一地理区域中和/或在共享表示为userx_context_a的其它第一场景属性时以及在包括用户使用期251a1-251an的预先指定的时间段内分别使用，被理解为这类移动设备的类别基本上相同和/或属于基本相同，这是由于至少与以下各项中的至少一项存在共性：(1)设备的品牌；(2)所述设备的版本号；(3)所述设备使用的操作系统；(4)所述设备内使用的硬件资源；(5)至少一个不是所述设备中运行的特定前台应用集的应用。在所述预先指定的时间段内，人群-a的相应用户u1’至un’的相应使用模式(例如，aup′s、rup′s)231a-233a从相应移动设备210a1至210an自动上传到云230中进行累积，并在采集到足够数量的使用模式数据后进行分析，以提供具有统计学意义的分析结果。

类似地，在包括相应的第一用户使用期252b1且包括至少一个其它用户使用期(例如252bn)的预先指定的时间段内，将被称为人群-b的第二组用户252描述为共享表示为locuxb的第二地理区域和/或共享表示为userx_context_b的第一其它场景属性。其中，所述用户名的形式为um″，其中m″是1″和n″之间的标识，用于人群-b的用户u1″到un″。

移动设备210b1到210bn由人群-b的用户u1″到un”在表示为locuxb的第二地理区域中和/或在共享表示为userx_context_b的其它第二场景属性时以及在包括用户使用期252b1-252bn的预先指定的时间段内分别使用，被理解为这类移动设备的类别基本上相同和/或属于基本相同，这是由于至少与以下各项中的至少一项存在共性：(1)设备的品牌(例如，android^tm、apple^tm、samsung^tm等)；(2)所述设备的版本号(例如，iphone5^tm、iphone6^tm、iphone7^tm等)；(3)所述设备使用的操作系统(例如，ios9、ios10)；(4)所述设备内使用的硬件资源(例如，特定的cpu′s、gpu′s等)；(5)至少一个不是所述设备中运行的特定前台应用(例如，图2a的211、212)集的应用。在所述相应预先指定的时间段内，人群-b的相应用户u1’至un’的相应使用模式(例如，aup′s、rup′s)231b-233b从相应移动设备210b1至210bn自动上传到云230中进行累积，并在采集到足够数量的使用模式数据后进行分析，以提供具有统计学意义的分析结果。

为了显示所述模式的持续性，图2b另外描述了被称为人群-c的第三组用户253，其用户u1″′到un″′在表示为locuxc的第三地理区域中和/或在共享表示为userx_context_c的其它第二场景属性时以及在包括用户使用期253c1-253cn的预先指定的时间段内占用相应的活动移动设备210c1至210cn，其中这些移动设备被理解为这类移动设备的类别基本上相同和/或属于基本相同。所述相应使用模式(例如，aup′s、rup′s)231c-233c(后者未示出)从相应移动设备210c1至210cn自动上传到云230中进行累积，并在采集到足够数量的使用模式数据后进行分析，以提供具有统计学意义的分析结果。应当理解，一旦采集了足够数量的相应使用模式数据，便对其它人群的其它相应使用模式233x进行类似的上传、累积和分析，以提供具有统计学意义的分析结果，所述分析结果将指示当前获得的是否是最佳使用模式，以向所述各自的前台应用提供所述期望或可接受的qos′s，同时最小化功耗和/或能耗，从而最大化电池续航能力。

所述分析结果可以包括确定用于提高所述各自qos′s和/或降低功耗和/或能耗以提高电池充电间续航能力的更好的电源管理策略。如果制定了此类更好的电源管理策略，则将其下载到所述各自的用户设备中，以提供更好的性能。应理解，由于数据是并行地从每个人群(例如，人群-a、人群-b等)的用户采集的，因此随着每个人群的规模增加，将会更快地采集所期望的足够数量的具有统计学意义的数据。然后，可以制定改进的电源管理策略，并将所述分析结果和所述改进的电源管理策略在相应的较快时间内反馈给所述相应的人群。根据本发明的一实施例，通过识别参与者数量较少的人群、识别可能加入所述人群的额外用户以及向那些请求他们加入自愿用户的已识别额外用户自动发送请求，来帮助解决常见原因促使更快地采集具有统计学意义的信息，然后根据监控的使用模式更快速地为所述电源管理策略提供迭代改进。

参考图3a，其示出了在每个插装移动设备中执行的第一机器实现的自动过程300的流程图。在步骤301中，可以定期或在发生预先指定的事件时进行输入。

在步骤302中，所述特定移动设备由唯一标识指示标识。在一实施例中，这包括获取所述设备的国际移动设备标识(internationalmobileequipmentidentity，简称imei)号。可以使用替代或附加的识别方法。可选地，在步骤302中，还获取所述特定移动设备的当前用户的唯一标识。这可用于当多个用户在一天中的不同时间使用相同的特定移动设备的时候。

在步骤303中，确定所述特定移动设备的当前硬件和软件资源。这可以包括获取硬件版本号、固件版本号、操作系统版本号和通信资源版本号。

在步骤304中，确定所述特定移动设备的当前环境条件。该步骤可以包括使用gps或其它地理位置确定用于确定所述移动设备的当前位置的机制。此外或者可替代地，所述步骤还可以包括确定所述设备的至少当前环境温度和所述设备内特定芯片或其它组件的可选工作温度。所述步骤还可以包括测量所述设备的气压、湿度和/或当前散热率。这种环境条件确定可用于确定所述设备当前可以安全运行的最大功率水平。

在步骤310中，确定所述特定移动设备的当前应用特定使用(aup′s)。这种确定的示例可以包括确定哪些是在所述设备中运行的前n个前台应用，其中n为小整数，例如介于1和10之间(含1和10)的整数。此外或者可替代地，可以确定当前在所述设备中运行的前n个前台应用的类型或分类。可选地，可以确定所述当前正在执行的前n个前台应用的各个状态或阶段，例如，启动、关闭、处于密集活动状态以及处于次密集活动状态。为所述当前前n个前台应用采集的附加信息可以包括所述应用分别提供的当前服务质量(qualitiesofservice，简称qos′s)和应用任务完成时间。

在步骤312中，确定所述移动设备内特定内部资源的当前资源特定利用率(rup′s)。在一实施例中，通过使用性能监测单元(performancemonitoringunit，简称pmu)按标准化参数指标单位报告所述资源利用率，所述性能监测单元基于预先指定的标准将本地测量的性能指标自动转换为标准化参数指标单位(normalizedparametermetricunit，简称npmu′s)。所述确定的资源利用率应包括可以为所述各自资源和/或所述移动设备整体计算或以其它方式确定当前功耗和/或能耗的资源利用率。利用率信息的示例可以包括显示利用率信息，例如多媒体帧/秒和屏幕亮度。利用率信息的另一示例是与当前cpu利用率相关的信息，例如以每秒计算浮点运算报告的信息。使用信息的另一示例是与当前模拟无线传输功率相关的信息，所述当前模拟无线传输功率可以按每发射机的活动水平或毫瓦(或每最近传输的能耗)来报告。每个特定移动设备提供的特定rup′s可以根据该设备的内部资源和可用于报告其相应参数的部分而变化。由于每个特定移动设备可以具有不同的参数，因此将其留待所述接收云资源确定如何基于所述移动设备imei和/或其它此类唯一标识来解释所述上传的参数。在一实施例中，所述pmu在各自预先确定的时间段内自动重复确定实际和期望或所需qos指标之间的误差。所述误差量可以是每个预先确定的时间段内随时间推移的瞬时误差的积分。所述系统的目标是使误差最小化，同时使能耗和/或功耗最小化。

在步骤320中，步骤302至312中确定的参数存储在所述特定移动设备的本地缓存中。在本发明的考虑范围内，在时间允许的情况下适时地采集步骤302至312的信息，并将所述信息放置在所述缓冲器中，直至采集到预先确定的足够数量的此类信息，然后再将这类信息上传到所述云。此外或者可替代地，在将预先确定的足够数量的这类信息采集到所述缓冲器中之后，所述移动设备在本地对所述采集的信息进行压缩，使得在上传至所述云时，这类传输的传输时间和功耗降低。压缩可以包括确定所述采集的原始信息的平均值或中位数。

步骤322表示等待最佳时机上传所述采集的信息，同时不增加所述本地移动设备的功耗和/或不在所述服务器同时接收来自大量其它移动设备的信息时让附加数据压垮所述目标云内服务器(13n)。所述传输时间可以由预先确定的事件调度或触发，例如来自所述云内服务器的信息轮询请求。

在步骤325中，将所述存储的原始或部分压缩信息上传到预先指定的服务器或所述云预先指定的部分进行进一步分析。在条件允许的情况下，控制通常通过路径327返回至步骤301以进行进一步的自动化重复。

通常，但频率远低于环路327，云内或其它位置的服务器会将正在更新的策略数据推送至所述特定移动设备。这由延续路径329和接收步骤330表示。在步骤330中，所述移动设备接收用于所述设备中安装的一个或多个特定应用的更新后或正在更新的功率控制器配置策略数据。在一实施例中，所述正在更新的策略信息可以采用增量值的形式而不是绝对值的形式，以便最小化传输更新信息所需的时间。所述接收的移动设备实现所述更新后的电源管理策略，然后通过路径337环路回到步骤301。

有时，频率远低于环路337，所述云内或其它位置的服务器将向所述特定移动设备推送完整且修改后的电源管理策略。这由进入步骤340的虚线延续路径表示。在步骤340中，所述移动设备接收用于其所有应用的完整更新后的功率控制器配置策略。所述接收的移动设备实现所述完全修改后的电源管理策略，然后通过路径347环路回到步骤301。

图3b描述了一种替代实施例300，其中在上传到所述云之前，所述移动设备不将采集的数据收集到本地缓存中，并且不对原始数据进行部分预计算。当然，必须先执行识别步骤302′，以使任何进一步上传的信息能够与唯一设备标识耦合，并可选地与所述设备的唯一用户耦合。在步骤303中，确定所述设备的当前硬件和/或软件配置。这可以包括硬件资源版本、固件版本、操作系统版本、通信模块版本等。步骤304可选地确定所述移动设备的当前场景条件，包括但不限于当前地理位置、当前温度、当前气压、湿度、设备散热等场景属性。在步骤310中，采集所述当前应用使用模式(applicationusagepattern，简称aup)数据。这可以包括识别按照cpu利用率、存储器利用率和/或网络利用率排序的前n个当前运行的前台应用程序。可以识别所述特定应用和/或所述应用所属的特定类别。在步骤312中，采集所述当前资源使用模式(resourceusagepattern，简称rup)数据。这可以包括由内部性能监测单元(performancemonitoringunit，简称pmu′s)采集与所述当前执行的特定应用相关联的资源使用数据。所述rup数据可以包括基于每个应用或集体应用的当前功耗或能耗。所述采集的附加信息可以包括实际qos指标和/或实际qos与期望或所需qos之间的误差。其它可以作为服务质量和/或当前功耗的代理的数据可以包括当前每秒多媒体帧数、每秒cpu浮点运算数、应用任务完成次数等。

在步骤325′中，将所述采集的数据上传到服务器或所述云进行进一步分析。应理解，所述数据的上传不需要只在步骤325中共同进行。相反，上传可以发生在数据包分别具有上传时当前可用的设备imeiid和aup或rup数据时。然后，所述环路通常通过路径327'返回到步骤301’进行重复，以响应预先确定的重复率和/或响应一个或多个预先确定的事件的发生。

前移(329’)至步骤330’的发生频率低于监控环路327’。在一实施例中，所述前移329'大约每周发生一次或每月发生一次，而所述监控回路327'每天发生一次或多次。在步骤330中，所述移动设备从所述云或合适的服务器接收所述功率/能量控制器的一个或多个更新的策略。这些下载的策略可以包括针对所述移动设备的一个或多个标识的调控器的策略，其中所述更新基于步骤325′中上传的使用模式数据的分析。在使用众包的情况下，所述更新的功率/能量控制器策略可以基于对所述当前移动设备所属人群中的多个用户的上传数据的分析。步骤330可以包括接收全新的功率/能量控制器代码，而不是仅接收更新的特定控制器策略。在所述更新验证并实例化之后，通过返回路径337'返回步骤301’。

参考图4，其示出了可以发生在远离所述移动设备和/或所述云的一个或多个服务器中的过程400。在步骤401中，定期或在发生一个或多个预定事件时进行输入。在步骤402中，过程400基于推送或基于拉出接收最近采集的来自相应的一个或多个移动设备的aup和/或rup数据，例如，来自属于预定人群的预定移动设备组。

在步骤403中，当接收到所述推送或拉出的信息时，过程400确定每个设备的相应唯一标识，并存储(步骤404)所述采集的aup和/或rup数据，其中，所述aup和/或rup数据与该标识设备的数据库记录有关。可选地，所述采集的aup和/或rup数据也与所述标识设备的特定用户逻辑关联。

随后，在步骤410中，针对特定移动设备或特定人群的移动设备和/或用户采集了具有统计学意义的足够数量的数据后，通过基于规则的专家系统分析数据处理等适当的人工智能手段分析数据，并根据特定设备和/或特定人群和/或类别的移动设备对所述结果进行排序和分类。还可以根据特定用户和/或特定类别用户对所述数据进行分类和排序。可以使用各种数据分析工具将所述数据库记录分类为移动设备和用户的不同类别和/或子类别，这些数据分析工具包括但不限于自动模式识别和分类以及根据所述识别模式进行排序；基于回归分析和基于曲线拟合分析。

在步骤412中，基于在步骤410中执行的分类分析，针对所述移动设备中的特定移动设备和/或特定人群或类别的移动设备和/或其用户类别的优化功率管理策略，基于这些设备和/或其特定用户的历史和最近接收到的aup和rup数据进行计算。

在步骤425中，优选地在通信带宽允许和/或各自的移动设备处于空闲模式时的空闲时间内，将所述相应的更新功率控制策略下载到所述特定移动设备和/或特定人群的设备或特定类别的设备或特定类别用户的设备。然后，通过路径427返回步骤401，以重复执行所述环路。在一实施例中，不是自动更新功率控制策略，而是先向所述终端用户发送请求，询问所述终端用户是想现在、以后还是从不更新其功率策略。如果所述终端用户接受，则在用户指定的时间(和/或地点)安装新策略。或者，可以要求所述用户接受最终用户协议，让所述用户自愿允许在系统确定的时间自动发送和安装这些ota更新。

在最近的较短时期内可能会更频繁地调整下载策略。步骤430表示较不频繁的(路径429不频繁采用)以及更全面的策略调整，这些策略调整基于所述对应服务器或云内服务在较长时间内分析的较长期平均性能数据。如上所述，与仅从单个移动设备采集信息相比，通过依靠众包可以提高从字段中采集性能数据的速度。在执行步骤430之后，通过路径437返回步骤401，以重复执行所述环路。

参考图5，在步骤501中，机器分析过程500包括定期和/或事件驱动的输入。在步骤502中，所述过程500接收最近采集的aup、rup和qos数据并将其对比功耗进行分析，这些数据来自可选地相应识别用户或用户类别的相应识别移动设备。在步骤503中，所述过程500使用步骤502的分析结果，根据所述设备品牌、型号和版本号、aup模式和rup模式中的一个或多个将所述移动设备分为设备组和子组。可选地，所述过程500还使用步骤502的分析结果，根据所述设备品牌、型号和版本号、aup模式、rup模式和用户可接受的qos相对于最小化的功耗模式中的一个或多个将所述用户分为用户组和子组。

在步骤510中，所述过程500将更近期的分析和分类结果与较早的历史结果进行比较，以识别新的趋势和新的模式或新的相关性。例如，由于一个或多个新移动应用和/或新操作系统(operatingsystem，简称os′s)或其修订版发布和被用户群广泛接受，可以确定新的aup模式正在出现。此外，由于一个或多个新移动设备(例如，新型号、新品牌)发布和被用户群广泛接受，可以确定新的rup模式正在出现。由于一些用户迁移到所述更新的软件和/或硬件选项，而其它用户保留在所述旧版本中，可以确定新的用户组或子组正在出现。结合机器实现的对所述出现的新组或子组的自动识别，步骤510确定相应用户组或子组与aup模式、rup模式和/或用户可接受的qos的相应类别或子类别与最小化功耗模式之间的相关性。

在步骤512中，所述过程500还针对所述识别的移动设备类别或子类别中的相应类别以及它们相应识别的aup模式、rup模式和/或用户可接受的qos的的类别或子类别相对于最小化的功耗模式识别所述可能的功率管理策略中更好的功率管理策略与所述识别的用户或用户组或子组可能通常位于的相应使用场景该识别不仅可以基于最近采集的采样数据(例如，众包数据)，还可以基于时间加权的历史数据。

在步骤512中，所述过程500使用其分析结果来识别所述移动设备的相应类别或子类别和/或用户的相应组或子组和/或相应使用场景的当前最佳电源管理策略，所述相应使用场景例如aup模式和rup模式的相应类别或子类别。基于这些标识，所述过程下载或调度下载所述移动设备的相应类别或子类别和/或用户的相应组或子组的识别的电源管理策略。然后，可以通过路径527返回步骤501，以自动重复执行所述过程500。

参考图6，其示出了描述根据本发明的系统的三种类型可操作互连引擎的方框图600。所述互连引擎包括一个或多个采样数据上传和采集引擎610、一个或多个数据分析引擎630和一个或多个策略修订下载引擎650。所述引擎610、630和650通过常见通信结构620可操作地相互耦合。所述通信结构620可以包括无线和/或有线通信资源。在相应的引擎610、630和650中提供适当的接口614、634和654，用于通过所述通信结构620进行通信。虽然未示出，但应理解，所述通信结构620可以扩展到与部分示出的系统600的其它部分可操作地通信，部分示出的系统600包括一个或多个专家规则，所述一个或多个专家规则提供和实现相应saas提供商(例如，图1中的13n、13m)或其它此类数据采集和分析实体的数据库或其它组件。

所示引擎610、630和650中的每个包括相应的存储器子系统611、631和651，用于存储该相应引擎的相应一个或多个处理器(612、632和652)可使用的可执行代码和数据。为使简化描述和使描述清晰，并未示出所有的可执行代码和存储器中的数据。

每个采样数据上传和采集引擎610可以包含由作业调度器(未示出)加载到其存储器611中的作业代码611a。空白存储器空间611b(也就是中间结果暂存器空间)可预留用于调度的所述作业代码611a的计算需求。所述作业代码611a可以包括机器代码和/或更高级别的代码(例如，sql代码)，其用于识别和获取期望的采样数据以及将所述数据存储到各自的数据库记录中。预先规划的数据格式或模板可以存储在为这些格式分配的存储器空间611c中。不同数据库记录的目录(例如，根据预先确定的类别和子类别进行预排序)可以存储在分配用于存储这些目录的存储器空间611d中。在存储器区域611e中可以提供用于搜索数据库和/或向数据库添加数据的专用接口。

在执行预定数量的数据采集作业和/或定期执行数据采集作业之后，所述上传的采样数据上传和采集引擎610的采样数据被所述一个或多个数据分析引擎630访问。所述引擎630可以包括模式识别算法、分类算法和相关检测算法631b，其用于识别相关对象、类别和子类别的组或子组以及这些对象之间的相关关系。在一实施例中，在物理存储器631b中可读取存储的算法可用于生成指示组、子组和关联的qos性能与能耗指标之间的相关性的性能模型和图形或图表。数据分析引擎630还可以包括算法631c，其用于为特定移动设备和/或这类移动设备的特定类别优化性能和/或最小化能耗。一些数据分析任务可能由于该领域的紧急趋势或新出现的趋势需要优先于其它任务。区域631a中可以提供调度日志和优先级排序算法，用于处理这些方面。

通过区域651a中提供的日志和优先级排序算法，可以在策略修订下载引擎650中管理将策略增量或完全修订的电源管理策略下载到特定移动设备、移动设备的特定类别或子类别、特定用户或用户的特定组或子群组。针对特定移动设备、特定移动设备的特定类别或子类别、特定用户或用户的特定组或子组已经制定的策略增量或完全修订的电源管理策略可以存储在区域651b中。下载可以由包括通信结构620的系统的适当数据传输资源(未具体示出)执行。

在一示例性实施例中，采样数据上传和采集引擎610包括上传模块和策略接收模块，所述上传模块从所述移动设备向远程服务自动和重复地上传所述移动设备的标识以及以下各项中的至少两项：指示所述移动设备的相应应用使用模式(applicationsusagepattern，简称aup)的数据，指示所述移动设备的相应资源使用模式(resourcesusagepattern，简称rup)的数据，指示所述移动设备因所述aup和所述rup中至少一项而产生的能耗和/或功耗且由所述分别上传的所述aup和所述rup的代表性数据表示的数据，或指示移动设备相对于所述表示的aup和/或rup提供的服务质量(qualityofservice，简称qos)的数据；所述策略接收模块从所述远程服务接收所述移动设备的电源管理策略的改进或替换，所述改进或替换至少基于所述的从所述移动设备向所述远程服务自动和重复地上传。在一些实施例中，采样数据上传和采集引擎610可以包括其它或附加模块，用于执行实施例中描述的步骤中的任意一个或其组合。此外，如所述附图中的任意图所示或所述权利要求中任一项所述，所述方法中的附加或替代实施例或方面中的任意实施例或方面也预期包括类似的模块。

在一示例性实施例中，数据分析引擎630包括上传模块和数据排序模块，所述上传模块从多个移动设备中的每个移动设备中自动和重复地采集所述移动设备和使用模式数据的相应标识，所述采集的使用模式数据包括以下各项中的至少一项：设备国际移动设备标识(internationalmobileequipmentidentity，简称imei)、所述个性化移动设备上当前运行的应用程序或固件的标识和版本号、关于处理器频率和内存带宽中的至少一种的核心资源使用模式(resourceusagepattern，简称rup)或正在采集每个核心资源的当前rup或交付的服务质量时所述每个核心资源的当前功耗或能耗；所述数据排序模块根据以下各项中的至少一项对所采集的数据进行排序：设备硬件的类型、设备固件的类型、在所述移动设备上运行的最常用应用的类型或特定类型、应用使用模式(applicationsusagepattern，简称aup)的类型、设备用户的类型。在一些实施例中，数据分析引擎630可以包括用于执行所述实施例中描述的步骤的任一或组合的其它或者附加模块。此外，如所述附图中的任意图所示或所述权利要求中任一项所述，所述方法中的附加或替代实施例或方面中的任意实施例或方面也预期包括类似的模块。

本文描述的计算机可读非瞬时性介质可以包括所有类型的非瞬时性计算机可读介质，包括磁存储介质、光存储介质和固态存储介质，并且具体不包括瞬时性信号以及承载它们的导线、线缆或光纤。应理解，所述软件可以安装在所述预计算和/或预加载规划子系统中，并与所述预计算和/或预加载规划子系统一起销售。或者，可以获取软件并加载到所述预计算和/或预加载计划子系统中，包括通过光盘介质或以网络或分发系统的任何方式获取软件，例如，包括从软件开发者所有的服务器或从非软件开发者所有但为其所用的服务器获取软件。例如，该软件可以存储在服务器上以便通过因特网分发。

虽然已经以特定于结构特征和/或方法动作的语言描述了主题，但是应理解，权利要求书定义的主题不必局限于上面描述的具体特征或动作。相反，上述具体的特征和动作被公开作为实施权利要求的示例性方式。