阅读说明：本技术 云设备协同实时用户体验和性能异常检测的系统和方法 (System and method for detecting abnormal user experience and performance in cooperation with cloud equipment ) 是由 黄潘函 阿赫马德·霍达阿里-罗斯塔马巴德 奥利维亚·芸汝·李 于 2018-10-12 设计创作，主要内容包括：计算设备从远程设备获取一个或多个异常检测模型用于检测一个或多个应用在一个或多个资源用量方面的异常,获取每个应用的资源用量数据,使用所述一个或多个异常检测模型确定每个应用在资源用量方面是否存在异常,并且采取响应动作。所述异常检测模型是采用机器学习技术在所述远程设备处根据从多个设备收集的数据构建的。所述资源用量数据包括所述计算设备所使用的应用的信息,例如应用在所述设备上所访问的一个或多个硬件组件或一个或多个服务的用量或能耗。异常检测结果可以包括应用落在多个异常级别中的一个异常级别的概率。(The computing device obtains one or more anomaly detection models from the remote device for detecting anomalies in the one or more resource usage by the one or more applications, obtains resource usage data for each application, determines whether an anomaly exists in the resource usage by each application using the one or more anomaly detection models, and takes responsive action. The anomaly detection model is constructed at the remote device from data collected from a plurality of devices using machine learning techniques. The resource usage data includes information of applications used by the computing device, such as usage or energy consumption of one or more hardware components or one or more services accessed by an application on the device. The anomaly detection result may include applying a probability of falling at one of a plurality of anomaly levels.)

云设备协同实时用户体验和性能异常检测的系统和方法

本发明要求2017年10月13日递交的发明名称为“云设备协同实时用户体验异常检测的系统和方法”的第62/572,320号美国临时专利申请案的在先申请优先权，该在先申请的全部内容以引入的方式并入本文本中。

技术领域

本发明大体上涉及应用异常检测，在具体实施例中，涉及一种用于云设备协同实时用户体验和性能异常检测的系统和方法。

背景技术

计算设备在人们的日常生活中变得越来越重要，针对各种用户设备，如智能电话、智能手表、平板电脑、笔记本电脑、计算机等，已经开发了越来越多的应用或软件程序，以适应计算设备的各种使用需求。当应用或进程在计算设备中运行异常时，可能会大大影响性能、功耗或能耗，从而影响计算设备的用户体验。对应用的异常检测可以有助于选择并采取适当的动作来减轻运行异常的应用所带来的不利影响。

发明内容

根据本发明一实施例，提供了一种方法，包括：计算设备从远程设备接收第一异常检测模型。所述第一异常检测模型可采用机器学习技术训练，用于检测应用在资源用量方面的异常。所述方法还包括根据所述第一异常检测模型获取所述应用的资源用量数据。所述资源用量数据包括所述应用在所述计算设备上所访问的一个或多个硬件组件或一个或多个服务的用量或能耗信息。所述方法还包括所述计算设备使用所述第一异常检测模型根据所获取的资源用量数据确定所述应用在所述资源用量方面是否存在异常，并根据所述应用异常的判断结果采取响应动作。通过使用一个或多个异常检测模型，可以检测计算设备的一个或多个应用在一个或多个资源用量方面的异常。

根据本发明另一实施例，提供了一种计算机实现的方法，包括从多个计算设备获取应用相关的数据样本。所述数据样本包括所述应用在所述多个计算设备上所访问的一个或多个硬件组件或一个或多个服务的用量或能耗信息，每个数据样本与所述多个计算设备中的一个相关联。所述方法还包括向所述数据样本分配标签。分配给与各自计算设备相关联的数据样本的标签指示所述应用在所述各自计算设备上的第一资源用量方面所具有的一组异常级别中的一个异常级别，所述第一资源用量对应第一异常参数。所述方法还包括使用已标记的数据样本和机器学习技术来构建异常检测模型，所述异常检测模型检测所述应用在所述第一资源用量方面的异常。根据从与所述应用相关联的所述多个计算设备获取的数据样本，可以使用所述实施例方法构建一个或多个异常检测模型。可以将这些异常检测模型推送到计算设备，以检测所述应用在所述各自计算设备上的异常。可以构建异常检测模型以检测一个或多个应用针对一个或多个异常参数的异常。

根据本发明另一实施例，提供了一种方法，包括根据为应用获取的资源用量数据并使用通过机器学习技术构建的异常检测模型检测在计算设备上运行的所述应用在资源用量方面是否存在异常，从而为所述应用生成异常检测模型；根据所述异常检测结果对所述应用的执行采取动作；在一段时间内收集所述应用的异常检测结果和根据所述应用检测结果所采取的响应动作的数据；并使用适配或定制模型根据所述收集的数据来调整针对异常检测结果所要采取的所述响应动作。这样，可以根据用户行为和用量模式来定制针对异常检测结果所采取的响应动作，以提高用户体验和设备性能。

本发明实施例减少了由于应用在计算设备中运行异常而引起的过度能耗，因而有助于提高用户体验。对于采用电池供电因而在能量容量上受限的计算设备，这些实施例更为有用。如果应用、进程、工具或软件在计算设备中异常运行一段时间，会导致电池比正常情况消耗更快，因此可能导致设备用户对设备的性能和效率不满意。使用通过分析应用对硬件组件、服务和资源的用量所收集的数据来检测异常。如果应用在能耗或资源用量方面的异常发生了一段时间，可能会导致设备温度异常升高，进而可能导致设备或其组件的损坏或性能降低。因此，各实施例的异常检测也可以防止设备过热或发热问题。本发明实施例还可以检测应用或进程异常使用计算设备中的资源、组件或服务的情况或事件，以有助于防止应用降低设备的整体性能或整体用户体验。当资源存在异常使用时，该资源被分配到其它应用或系统进程可能会降低资源的性能，从而可能降低设备运行的性能。本发明实施例改善了用户体验，增强了性能，延长了电池寿命，降低了整体能耗，减少了过热或发热问题，并有助于更加正常和有效的使用计算设备中可用的软件或硬件组件等资源。

附图说明

为了更完整地理解本发明及其优点，现在参考下文结合附图进行的描述，其中：

图1示出了一种计算设备的实施例架构的图。

图2示出了一种用于应用异常检测的实施例方法的流程图。

图3示出了一种实施例异常检测模型的图。

图4示出了展示一种资源的实施例用量水平的图。

图5示出了一种用于应用异常检测定制化的实施例方法的图。

图6示出了另一种用于应用异常检测定制化的实施例方法的图。

图7示出了一种用于应用异常检测的实施例方法的图。

图8示出了一种用于计算设备和服务器之间交互以进行应用异常检测的实施例方法的图。

图9示出了一种用于构建异常检测模型的实施例方法的流程图。

图10示出了展示根据异常参数的相关用量参数定义的实施例用量组的图。

图11示出了展示对图10所示的用量组定义的多个异常级别或阈值的图。

图12示出了一种用于应用异常检测的实施例系统的框图。

图13示出了一种用于应用异常检测的实施例方法的流程图。

图14示出了一种用于构建异常检测模型的实施例方法的流程图。

图15示出了另一种用于应用异常检测的实施例方法的流程图。

图16示出了一种用于应用异常检测的实施例方法的流程图。

图17示出了一种用于确定应用异常检测的阈值的实施例方法的流程图。

图18示出了另一种用于应用异常检测的实施例方法的流程图。

图19示出了一种处理或计算系统的方框图。

图20示出了一种收发器的方框图。

具体实施方式

下文将详细论述本发明实施例的制作和使用。应了解，本文所揭示的概念可以在多种具体环境中实施且所论述的具体实施例仅作为说明而不限制权利要求书的范围。还应理解，可在不脱离由所附权利要求书界定的本发明的精神和范围的情况下对本文做出各种改变、替代和更改。

本发明实施例提供了用于应用异常检测的方法。在设备上运行异常的应用可能会严重影响性能、功耗或能耗，并最终影响设备的用户体验。因此，能够检测出在设备上运行的一个或多个应用的异常是十分必要的。根据一些实施例，设备可以从远程设备接收异常检测模型。异常检测模型可采用机器学习技术训练，用于检测应用在资源用量方面的异常。设备可以根据异常检测模型获取应用的资源用量数据。资源用量数据可以包括应用在计算设备上所访问的一个或多个硬件组件或一个或多个服务的用量或能耗信息。设备可以使用第一异常检测模型根据所获取的资源用量数据确定应用在资源用量方面是否存在异常，并根据应用在资源用量方面的异常的判断结果采取响应动作。通过使用一个或多个异常检测模型，可以检测计算设备的一个或多个应用在一个或多个资源用量方面的异常。

在一些实施例中，可以提供一种用于构建异常检测模型的方法。该方法可以从多个计算设备获取应用相关的数据样本。数据样本包括应用在多个计算设备上所访问的一个或多个硬件组件或一个或多个服务的用量或能耗信息，每个数据样本与多个计算设备中的一个相关联。然后，该方法可以向数据样本分配标签。分配给与各自计算设备相关联的数据样本的标签指示应用在各自计算设备的第一资源用量方面所具有的一组异常级别中的一个异常级别，第一资源用量对应第一异常参数。该方法使用已标记的数据样本和机器学习技术构建异常检测模型。异常检测模型检测应用在第一资源用量方面的异常。根据从与应用相关联的多个计算设备获取的数据样本，可以使用实施例方法构建一个或多个异常检测模型。可以将这些异常检测模型推送到计算设备，以检测应用在各自计算设备上的异常。可以构建异常检测模型以检测一个或多个应用针对一个或多个异常参数的异常。

在一些实施例中，可以为特定设备定制异常检测。例如，根据所获取的应用的资源用量数据并使用采用机器学习技术所构建的异常检测模型，设备可以检测在设备上运行的应用在资源用量方面是否存在异常。从而，为应用生成异常检测结果。设备可以根据异常检测结果对应用的执行采取响应动作。设备可以在一段时间内收集应用的异常检测结果以及根据异常检测结果而采取的动作的数据，并根据收集的数据使用适配或定制模型调整针对异常检测结果所采取的动作。这样，可以根据用户行为和用量模式定制针对异常检测结果所采取的动作，以提高用户体验和设备性能。

计算设备在人们的日常生活中变得越来越重要，针对各种计算设备，已经开发了越来越多的应用或软件，以适应各种需求和要求。本文中的计算设备可以是指使用一个中央处理单元(central processing unit，CPU)或多个处理单元操作的电子设备(或设备、装置)。CPU可以具有一个或多个芯片。CPU可以包括一个或多个核、微处理器、微控制器、处理器、图形处理单元(graphic processing unit，GPU)、神经网络处理单元(neural networkprocessing unit，NPU)、控制器或其任意组合。计算设备用于处理信息和/或执行计算。计算设备根据软件程序执行一系列数学和逻辑运算。计算设备的示例可以包括计算机、笔记本电脑、平板电脑、智能手机、可穿戴电子设备、服务器、健身器材、电子测量设备、监控设备、控制设备、电子辅助设备、电子宠物、自主汽车、导航设备、驾驶设备、机器人等等。

图1示出了一种计算设备的实施例架构100的图。架构100示出了计算设备中包括的组件。如图所示，计算设备包括多个硬件组件，例如显示器、GPU、CPU、Wi-Fi接口、调制解调器、照相机和全球导航卫星系统(global navigation satellite system，GNSS)。计算设备还可以包括其它硬件组件102，例如蓝牙、输入/输出设备(input/output，IO)、微机电系统(micro-electro-mechanical systems，MEMS)、机械设备、执行器或传感器。计算设备还可以包括操作系统(operating system，OS)和服务104，它们是用于支持计算设备运行的软件程序或工具。如图所示，计算设备包括图形库、网页浏览器引擎和介质管理器等服务。OS和服务使用硬件组件来执行对应的功能。例如，图形库使用显示器、GPU和CPU来执行图形相关功能。计算设备还可以包括一个或多个应用106，其中应用可以指安装在计算设备上的可执行软件程序。应用可以由用户或通过安装其它应用安装在计算设备上。应用可以从远程服务器或云服务器等远程设备下载，并安装在计算设备上。应用也可以作为计算设备的一部分预先安装在计算设备上。应用可以在后台运行、在前台运行、或者同时在后台和前台运行。如图所示，计算设备上的应用包括消息或聊天应用、电子邮件应用、游戏应用、导航或地图应用、社交媒体应用以及图像或照相机应用。应用的示例还可以包括天气预报应用、音乐或视频播放应用、网页浏览器应用、电信应用、搜索应用、病毒扫描应用、计算机工具等。应用还可以包括在计算设备上运行的进程或系统工具。应用可以使用服务和硬件组件中的一个或多个来实现其用途。例如，游戏应用在执行中可以使用图形库、网页浏览器引擎、媒体管理器和其它服务。计算设备还可以包括异常检测器108，其可用于根据应用使用或访问的服务和硬件组件来检测应用是否存在异常或运行异常。异常检测器108可以接收在计算设备上执行的每个应用在计算设备上访问或使用的一个或多个资源(例如一个或多个硬件组件和/或一个或多个服务)相关的数据(例如，用量数据)，并将每个资源的用量关联到对应的应用。异常检测器108可以根据应用的资源用量来检测应用的异常。

计算设备中的应用在未按其设计或预期运行(本文中称为应用运行异常或状态异常、或应用异常)时，可能会严重影响计算设备的性能、功耗或能耗，从而严重影响计算设备的用户体验。例如，在一些情况中，状态异常的应用可能持续在一个状态下运行(或一直执行重复操作)而无法停止或切换到不同的状态。这可能是应用由于软件缺陷等原因进入无法摆脱的死循环，可能是应用不断尝试从一种操作模式或状态转换到另一种操作模式或状态但未成功，也可能是应用不断尝试访问硬件组件但未成功。应用的持续运行会更快地消耗计算设备的功率，导致计算设备过热和性能降低。在一些情况下，这还可能会给计算设备带来安全问题。例如，在高机密性会议期间，需要断开无线连接的智能手机无法成功断开连接。

应理解的是，在计算设备上运行的应用的异常是可以检测到并采取相应的动作来防止或减轻应用异常的影响，或者向用户发出通知或告警。当应用出现消耗大量能源等行为异常时，无法访问应用内部查看发生了什么并确定应用是否异常。在一些情况下，即使有应用代码，通常也很难根据所发现的应用缺陷来确定应用是否异常。一般来说，也很难找到导致应用异常的缺陷，或者确定能量用量激增等应用异常的起因。然而，运行异常的应用可以通过应用的资源用量情况反映出来。资源用量可包括任何硬件组件和/或软件组件的资源用量，例如存储器、显示器、扬声器、调制解调器、电池、CPU、GPU或媒体管理器等服务。例如，存在异常的应用可能会消耗非预期的电池电量、在后台或前台有非预期的CPU用量、非预期次数的自重启、接入调制解调器所费时间更长、或者有非预期的存储器用量，等等。通过监控应用的资源用量，可以检测出应用是否运行异常，并且可以采取动作处理应用异常，例如冻结应用运行。

本发明的实施例在一段时间内监控应用所使用的一个或多个硬件组件以及服务的相关设备信息、环境数据和资源用量，并使用一个或多个异常检测模型来根据所监控的资源用量确定应用是否存在异常。可以使用机器学习技术根据从多个计算设备收集的资源用量数据在远程服务器或云服务器等远程设备中构建一个或多个异常检测模型，并将其部署在计算设备上用于应用异常检测。单个异常检测模型可支持检测设备在一段时间内使用或访问的若干应用的异常。单个异常检测模型还可以同时检测若干资源用量或异常参数的异常。

图2示出了一种用于应用异常检测的实施例方法200的流程图。方法200所示操作在计算设备或用户设备处执行。如图所示，在步骤202处，方法200接收异常检测模型。异常检测模型可以实现为软件程序。在一示例中，方法200可以从网络中的远程服务器、云服务器、临近服务器或支持设备等远程设备下载异常检测模型，并在计算设备中安装和运行异常检测模型。在另一示例中，异常检测模型可以由远程设备等推送到计算设备。异常检测模型可以在计算设备中执行并始终在计算设备中运行。异常检测模型可以由单独的处理单元执行，例如张量处理单元(tensor processing unit，TPU)、GPU、神经处理单元(neuralprocessing unit，NPU)或独立CPU。异常检测模型还可以称为异常检测器或预测器。异常检测模型可以是计算算法，包括对所提供的输入数据执行异常检测任务所需的计算、数学运算和/或分析。异常检测模型可以使用机器学习技术构建。例如，异常检测模型可以是分类模型、回归模型、深度神经网络模型、使用贝叶斯网络构建的模型、决策网络、决策树集合、正则化回归模型或类似的分类、预测或回归模型及其组合。可以使用的神经网络模型的示例包括多层全连接网络、卷积神经网络(convolutional neural network，CNN或ConvNet)、递归神经网络(recurrent neural network，RNN)、强化学习或其变体或组合。异常检测模型的构建将在本发明后文描述。异常检测模型可以用于检测一个或多个应用在计算设备的一个或多个资源用量方面的异常。

在一实施例中，异常检测模型可以作为与指定或描述异常检测模型的元数据相关联的软件模块(例如，库、可执行或其它适用代码)由计算设备接收。软件模块可以包括异常检测模型的底层算法的实现。计算设备可以实例化或加载所接收的根据相关联的描述配置的软件模块，以执行检测操作。在另一些实施例中，异常检测模型可以包括已配置在计算设备中的核心引擎(例如，基于实现检测操作的可训练神经网络或其它适用模型等底层算法)计算设备接收的检测模型可以包括一个或多个文件中的设置(例如，输入次数、模型的结构和类型、层数、训练循环数、从其它设备收集的用量数据训练的权重等)。计算设备可以根据所接收的文件动态地配置/定制核心引擎，以便执行异常检测操作。

在一实施例中，异常检测器或异常检测模型包括运行一个或多个任务的系统工具、软件或守护进程，所述任务可以包括数据收集、用户体验和设备性能监控、每个应用对每个资源的性能监控、数据预处理、数据分析、资源用量估计、用量和能量核算、数据库管理、异常检测以及定制或适配算法。异常检测模型可以根据异常检测结果和远程设备或服务器的要求采取动作。资源计算或估计可以包括估计每种资源的能量，或者如需要，使用可用的已记录数据对每种资源的功耗进行建模。在一示例中，异常检测工具或守护进程可以使用设置(或配置)文件和异常检测模型文件(或者包括诸如多个深度神经网络模型的文件)，这些文件共同定义异常检测守护进程的控制参数、神经网络模型的结构和算法、相关算法的参数值以及神经网络模型的权重。若异常检测模型基于深度神经网络算法，异常检测工具或守护进程可以在设备上的NPU、TPU或GPU上运行异常检测模型，以加速执行或检测进程。可以定期或按需更新或修改包括系统工具或守护进程、配置以及异常检测模型文件在内的部分或全部异常检测模型。在另一实施例中，异常检测工具或守护进程可以向远程设备或支持设备或服务器发送设备和资源用量数据，异常检测模型可以在支持或远程设备上执行，然后配套或远程设备可以将结果发送给计算设备以采取进一步动作。

资源用量可以是指应用为执行而使用或访问的资源的用量或能耗。资源可以包括计算设备的硬件组件，例如应用所使用的存储器、显示器、扬声器、调制解调器、电池、CPU、GPU、照相机、传感器、手电筒、音频等，或计算设备的软件组件如应用所使用的服务。因此，资源用量与特定资源相关。一个应用可以确定为在计算设备的一个或若干资源的资源用量方面存在异常。资源的用量可以是指资源(为执行应用)所消耗的能量的量、(为执行应用)使用或访问资源的频率、(为执行应用)使用或访问资源的时长、(为执行应用)所使用的资源的大小或数量、资源参数或属性或其任意组合。资源用量的示例可以包括CPU后台(background，BG)、CPU前台(foreground，FG)、Wi-Fi BG、Wi-Fi FG、调制解调器BG、调制解调器FG、GPS BG、GPS FG、照相机BG或照相机FG的用量或能耗。资源用量还可以包括唤醒锁保持时间、应用自启动次数、闹钟、IO设备用量、总能量用量或存储器用量。每个资源用量对应一个相关参数。可以根据对应的资源用量的测量结果分配参数的值。例如，CPU BG的能耗对应参数CPU BG能量、IO设备的用量可以对应参数IO设备访问速率、调制解调器BG的用量可以对应参数调制解调器在BG的开启时间、Wi-Fi的用量可以对应参数Wi-Fi锁保持时间等。这些参数可以称为异常参数，针对这些参数检测应用的异常。异常参数还可以包括更为复杂的或二级参数或属性，从设备中收集的若干资源用量或其它相关数据的某些组合形式中提取或计算。可以根据与一个或多个资源的用量对应的一个或多个异常参数来确定应用在一个或多个资源的资源用量方面的异常。

在步骤204处，方法200获取应用所使用的资源的资源用量数据。资源用量数据可以用于使用异常检测模型检测应用的异常。方法200可以根据异常检测模型的配置获取资源用量数据。方法200可以获取应用所使用或访问的每个资源的资源用量数据。在一示例中，计算设备可以监控应用所使用的资源，根据异常检测模型的要求收集资源的资源用量数据，并将所收集的资源用量数据提供给异常检测模型。在另一示例中，异常检测模型可以用于监控和收集应用所使用的资源的资源用量数据。在另一示例中，资源检测模型可以计算或估计每个资源消耗的能源的量，或者可以使用记录的数据对每个资源消耗的功率的量进行建模。可以使用从多个设备获取的数据或使用每个资源的相关洞察来训练或设计能量估计或功率建模算法。在另一示例中，异常检测模型可以使用从设备提取或收集的原始数据或初始变量来计算或生成一组资源用量参数、量化特征、二级或更复杂参数或属性。资源用量数据可以包括计算设备的一个或多个硬件组件或一个或多个服务的用量或能耗。设备可以监控和收集与设备内使用或访问的每个应用或进程对应的资源用量数据。

在一些实施例中，资源用量数据可以包括在应用的一个或多个执行条件下计算设备中的硬件组件的能耗、用量、能量模式或用量模式。执行条件可以包括应用对设备内的资源的前台用量、后台用量、亮屏用量或灭屏用量或消耗。执行条件可以指示应用是在前台还是后台执行，是在亮屏还是灭屏状态下执行。硬件组件的用量模式包括硬件组件在一段时间内用量的一系列测量(即，时间序列或用量序列)。在其它实施例中，用量模式还可以包括频率、平均值、最大值、最小值、速率和/或从该硬件组件的用量测量中收集/识别的其它适用统计数据。硬件组件的能量模式可以包括硬件组件在一段时间内的一系列能耗(即，时间序列或能耗序列)。在一示例中，硬件组件的用量或能耗可以包括硬件组件在一段时间(例如24小时)内的总用量或总能耗。在另一示例中，硬件组件的用量或能耗可以包括硬件组件最近(例如，在收集数据的最后5分钟)的用量或能耗。在这种情况下，硬件组件的用量或能耗还可以包括其它相关设备属性的最近数据，例如显示器的亮度水平。在另一示例中，硬件组件的用量或能耗可以包括硬件组件在一段时间内和特定解析率下的一系列用量或能耗(例如，以时间序列呈现的用量和能耗)，例如最近24小时内在5分钟解析率下(例如，每隔5分钟)。在每种情况下，还可以包括显示亮度或Wi-Fi接收质量等其它相关设备和环境数据，例如，以说明产生该用量或能耗的条件。资源数据还可以包括在计算设备中执行的应用所使用的服务、软件组件或系统工具的用量数据。

在一些实施例中，资源用量数据包括CPU前台用量、CPU后台用量、唤醒锁保持时间、自启动次数、应用的亮屏时间、应用的灭屏时间、蜂窝、电信或调制解调器的用量和模式、Wi-Fi或网络的用量和模式、存储器用量、多媒体用量和模式、成像传感器或照相机的用量和模式、GPU用量、任何其它传感器或硬件组件的用量和模式、IO设备的用量(包括IO设备访问次数)、或定位服务的用量和模式(包括所使用的定位服务的数量)。

在一些实施例中，资源用量数据还包括图形处理服务的用量、神经处理服务的用量、到达通知的数量、音频服务的用量、多媒体服务的用量、蓝牙的用量、Wi-Fi服务的用量、电信服务的用量、调制解调器或无线电服务的用量、照相机服务的用量、定位或导航服务的用量、传感器服务的用量、消息服务的用量、人机界面服务的用量、媒体管理器服务的用量、通知管理器服务的用量、每个系统服务的用量、Wi-Fi或网络接入服务的质量、调制解调器或电信服务的质量、音频的音量和质量、音频路由、多媒体路由、环境光分布、显示亮度分布、温度、湿度、电池或其它组件的电流、电池或其它组件的电压、或用户数据的访问次数。

在一些实施例中，资源用量数据可以包括有关计算设备的信息，例如计算设备的型号、计算设备的产品版本，或者可以包括有关应用的信息，例如应用的应用名称或应用标识(用于在多个应用中识别应用)、应用版本。资源用量数据还可以包括使用计算设备的环境条件，例如计算设备的位置、应用执行的日期和时间或计算设备的性能信息。

在步骤206处，方法200根据所获取的资源用量数据使用异常检测模型检测应用的异常。异常检测模型可以将资源用量数据作为输入，确定应用在计算设备的一个或多个资源的资源用量方面或异常参数方面是否存在异常。上述一个或多个资源可以在异常检测模型中预先配置，异常检测模型可以针对该一个或多个资源的资源用量输出相应的异常检测结果。例如，异常检测模型可以检测应用在CPU BG、CPU FG、唤醒锁、闹钟、Wi-Fi和调制解调器等资源的资源用量方面是否存在异常。异常检测模型可以用于同时检测多个应用在资源用量方面的异常。异常检测模型可以同时预测或检测多个资源用量或异常参数方面的异常。异常检测模型可以同时检测或识别多个级别或类别的异常。

图3示出了一种用于检测设备使用的一个或若干应用的异常的实施例异常检测模型300的图。本示例中的异常检测模型300是一种采用深度学习技术训练的深度神经网络。作为说明性示例，输入到异常检测模型300的资源用量数据包括设备每个硬件组件的用量和能耗。硬件组件包括CPU、Wi-Fi、GPU、GNSS、显示器、BT、音频、手电筒、前置摄像头、后置摄像头和传感器。输入数据还可以包括其它相关设备、性能或应用属性，例如应用名称或应用标识、CPU唤醒锁、调制解调器接收质量、地理区域和日期。基于资源用量数据输入，异常检测模型300可以立即输出异常检测结果以指示应用是否存在CPU BG异常、CPU FG异常、唤醒锁异常、闹钟异常、自启动异常、Wi-Fi异常、调制解调器异常、GPS异常或其它异常。异常检测模型300可以检测设备使用的若干应用的异常，其中应用的数据作为一批数据输入到模型，每个数据样本属于一个应用。

异常检测模型300可以使用记录的所有资源用量和设备数据，或者也可以使用部分输入数据。异常检测模型的输入数据可以包括从若干资源用量参数、设备或环境数据或信息的某种组合形式或数学映射中计算出的一个或多个属性或量化特征。例如，可以通过对四个资源用量数据或参数运用数学运算或映射来提取属性中的一个并作为异常检测模型300的输入数据的一部分，以获取对于异常检测更加有用、更相关或更有辨识力的属性。可以根据在远程服务器等中所执行的数据分析、使用从多个设备收集的数据来确定使用输入参数或属性的组合进行的输入属性设计和构建。

在一些实施例中，异常检测模型300可以生成包括异常级别的异常检测结果。在一示例中，异常级别或类别可以包括无异常、异常、高度异常或过度异常。在另一示例中，异常级别还可以包括一个或多个用量水平，例如高度使用或过度使用。例如，异常检测模型300可以检测到应用在CPU BG用量上存在高度异常、在调制解调器的用量上存在过度异常、或在CPU FG上存在过度使用。检测到应用所具有的异常的级别的异常检测模型可以称为异常级别检测模型。在一些实施例中，异常检测模型300还可以估计应用落在一组异常级别的可能性(可以称为异常可能性或概率)。例如，对于一项资源用量或异常参数，如果异常检测模型300检测到4个异常级别，则模型可以估计应用正常的概率为P1％(或无异常)，过度使用资源的概率为P2％，异常的概率为P3％，高度异常的概率为P4％，其中p1+p2+p3+p4＝100％。对应用落在一组异常级别的可能性生成估计数据的异常检测模型可以称为异常概率估计模型。

返回参考图2，在一些实施例中，在执行步骤206之前，方法200可以检查应用所使用的服务是否是可感知场景。可感知场景可以涉及为应用配置的约束、特权和/或限制，以在运行时调用某些服务(例如，系统服务)。例如，方法200可以检查社交媒体应用或消息应用是否允许在后台播放音乐以及是否被认为是正常用例。如果服务的使用场景可感知，方法200可能无需运行异常检测模型来检测该服务涉及的资源的后台用量是否异常。如果使用场景不可感知，则方法200可以将获取的数据输入异常检测模型，并运行异常检测模型来检测相关用量和能耗是否异常。在一些实施例中，可以将硬件组件的用量和能耗和其它输入数据以及服务的用量输入异常检测模型，例如模型300。异常检测模型可以在生成异常检测输出时自动考虑每个应用的可感知场景以及其它输入和用量数据。

在步骤208处，方法200根据检测到应用存在异常而采取响应动作。这里的采取动作可以是指执行具体操作。例如，在计算设备确定应用异常或在一定条件下工作异常时，计算设备配置为执行响应操作。操作可以预先配置，涉及执行软件程序、设备上的操作和/或限制资源使用或限制被检测到行为异常的应用访问一个或多个资源。所采取的动作可以减轻或避免应用异常的负面影响。在一示例中，异常检测模型可以检测多个异常级别或估计一个或多个应用在使用一个或多个资源上的资源用量的严重性或异常程度，为每个应用采取的响应动作可以取决于所检测到的异常级别和/或资源用量的重要性。在一示例中，采取的动作可以是冻结应用的运行。在另一示例中，采取的动作可以是在一段时间内冻结应用的运行。在另一示例中，采取的动作可以是限制应用可用的资源和/或服务。在另一示例中，采取的动作可以是杀死应用。在又一示例中，采取的动作可以是重启应用。在又一示例中，采取的动作可以是向计算设备的用户或控制器发出通知，例如异常通知(例如，用户界面弹出消息、声音警报、即时消息或通知用户或系统的其它适用机制)。通知可以指示异常的发生，以便用户可以采取其认为合适的响应动作。通知可以指示应用的异常检测结果。通知还可以指示一个动作列表，用户可以从中选择动作以响应于所发生的异常。在一些情况下，用户可以依据其偏好、经验或知识，选择不理会异常通知，不采取任何动作。

在一些实施例中，可以针对每个异常参数预先确定与不同异常级别或估计概率相对应的动作列表。例如，异常检测模型根据一组异常级别来检测应用在CPU FG用量方面的异常，包括正常(或无异常)、过度使用、异常和高度异常。根据一组异常级别预先确定的动作可以包括如表1所示的“无”(即无动作)、“通知”(即发出通知)、“冻结”(即冻结或停止应用一段时间)、“重启”(即重启应用)。这样，计算设备可以根据异常级别和预先确定的动作之间的对应关系针对异常检测结果选择并采取预先确定的动作。在一些实施例中，针对一个异常级别可以采取一个动作组合。在一些实施例中，动作也可以基于应用中所发生的异常的时长。例如，如果应用在某个资源用量方面的异常持续的时间超过阈值，则可以更改要采取的动作。

异常级别	动作
		正常	无
过度使用	通知
		异常	冻结
高度异常	重启

表1

在步骤210处，方法200存储有关应用的异常检测的数据。存储的数据可以包括在步骤204处获取的资源用量和其它相关数据、在步骤206处生成的检测结果、在步骤208处采取的动作、应用的异常参数、应用的用量模式、用户体验反馈或用户偏好，例如在步骤216处接收的用户体验反馈。方法200可以在一段时间内以一定间隔记录部分或全部数据，例如在2个月内每5分钟记录异常检测结果。通过记录的数据，方法可以估计应用上的用户行为或应用在计算设备上的用量模式。在步骤212处，方法200可以将存储的数据发送给远程设备。可以定期或按需将存储的数据发送给远程设备。发送给远程设备的存储数据可以用来训练或更新一个或多个异常检测模型。

在步骤214处，方法可以定制或调整动作。在一些实施例中，方法200可以根据在步骤210处记录的数据以及用户反馈信息来调整计算设备根据检测到应用的异常级别而采取的动作。例如，方法200可以根据上文表1采取动作。方法200可以根据在一段时间(例如两个星期)内记录的应用的异常结果和所采取的响应动作来确定该应用针对某个异常参数(例如，CPU前台用量)的异常模式8。如果检测到的异常级别的直方图或设备的异常模式显示出应用在两个星期内曾出现大量(例如，超过数量阈值)过度使用(例如，超过用量阈值)而用户从未采取过任何响应动作，则方法200可以确定应用实际上运行正常，从而将对应过度使用异常级别的动作从“通知”调整到“无”。这种情况可能是用户可以接收该应用的CPU前台用量的过度使用，或者视其为正常情况。在另一示例中，异常模型显示出应用在两个星期内发生若干过度使用实例(例如，少于实例数量阈值)但未检测到任何异常或过度异常，且用户偶尔采取动作重启应用。在这种情况下，方法200可以确定应用(以及用户或设备)主要处于低用量组，过度使用实际上对于该用户或设备来说是异常的。方法200可以将过度使用异常级别对应的动作从“通知”调整(例如，选择不同的操作)到“冻结”。在又一示例中，由于用户体验反馈信息，例如用户想要根据异常检测结果控制对应用的操作，方法200可以将表1中的所有动作都调整为“通知”。例如，如果在一段时间内检测到高度异常，用户可能想要冻结应用，或者如果应用的异常持续一段时间，用户可能想要重启应用。这样，计算设备要采取的动作根据计算设备用户的具体要求、需求或行为定制。可以为应用生成历史数据，历史数据可以包括应用的异常检测结果、针对应用的异常检测结果所采取的动作、应用的用量模式、应用的能耗模式、用户反馈或其任意组合。历史数据可以用来确定可以如何确定或调整动作。还可以使用机器学习模型等模型根据历史数据以及适配或定制机制(例如，根据定制算法)来定制动作。在一些实施例中，除了在一段时间内观察到的异常检测结果的历史或模式以外，其它相关信息可以用作定制算法的输入，包括资源用量模式、其它相关设备或用户的信息，包括使用的位置、日期或时间。

在一些实施例中，异常检测模型检测到的异常可以有多个级别或类别，称为异常级别。多个级别或类别可以根据多个异常阈值确定。图4所示的图展示了应用所使用的资源的实施例用量水平。用量水平从最低水平(例如，观察到的最低资源用量)到最高水平(例如，观察到的极度资源用量)。在本实施例中，可以根据一组异常阈值T1至T7(也可称为用量水平阈值)针对资源的用量为应用的异常检测定义不同的异常级别。例如，高于T7的资源用量可以定义为极度异常，例如，当考虑多个设备中的用量分布时，应用在设备群(或多个类似设备)中对资源的用量超过99％。这可能是极度罕见或不寻常的用例。T7和T6之间的资源用量可以定义为过度异常，例如，应用在设备群中对资源的用量为96％到99％。这可能也是非常罕见或不寻常的情况。T2和T1之间的资源用量可以定义为相对高度异常，例如，应用在多个设备中对资源的用量为50％到65％。低于T1的资源用量可以定义为正常。在一些实施例中，尽管可以检测和识别若干异常级别，要采取的响应动作却可以限于两三个动作。例如，低于T4的资源用量可以被视为正常(因此不采取动作)，高于T4的资源用量被视为异常(例如，可能意味着无论资源用量高于T5、T6或T7，应用都被冻结)。

在另一些实施例中，应用的异常可以通过连续用量参数或属性等连续异常参数来表征，而不是通过多个异常级别或类别来表征。在这些情况下，对于在计算设备上运行的每个应用，异常检测模型基于从计算设备收集的输入数据估计或预测连续异常参数，并且可以根据估计或预测的异常参数值和一组阈值来采取响应动作。例如，可以将连续异常参数与一组阈值比较，然后根据比较结果确定要采取的动作。在这些情况下，异常检测模型可以称为异常估计器、异常预测器或资源用量水平估计器。所用的一组阈值可以是计算设备上运行的所有应用共用的一组公共阈值，或者每个应用可以具有一组不同的阈值，用于根据所估计的异常参数的取值或范围来确定要采取的动作。

在一些实施例中，可以根据具体设备中的应用的用户反馈、用户体验、用量模式或异常模式定制应用异常检测。例如，可以接收用户反馈和控制来调整异常检测模型确定异常级别的标准。用户可以影响在应用的异常检测中要实施什么级别的异常或阈值，或者可以确定实施资源用量异常检测和控制的严格程度。以图4作为说明性示例，如果异常检测模型默认在异常级别高于阈值T4时确定是否采取冻结动作，用户可以选择更为宽松的异常评估。然后，可以将用户指示或设置控制等用户反馈提供给异常检测模型，要求异常检测模型使用T5来确定应用在资源用量方面是否异常(例如，资源用量高于T5为异常，低于T5为正常)。在另一示例中，如果用户倾向于对资源用量或能耗的最小控制，则用户可以通过设置控制等方式指示异常检测模型使用更高阈值(例如，T6或T7)作为阈值来检测应用在资源用量方面是否异常。

图5示出了一种用于应用异常检测定制化的实施例方法的图500。在本示例中，根据资源的用量模式(或异常参数的变化模式)定制异常阈值。图5示出了同一应用分别在两个不同设备或用户，即设备1和设备2，中使用一段时间的资源用量(例如，能耗)的图510和520。y轴表示使用频率或用量直方图，x轴表示资源用量水平。在本示例中，使用图4中所示的阈值确定异常级别。两个设备使用相同的异常检测模型。在本示例中，使用了两个异常级别。也就是说，异常检测模型确定低于T4的资源用量为正常，高于T4的资源用量为异常，如线条530所示。从图510和520可以看出，设备1和设备2具有不同的用量模式或用户行为。两个设备的资源用量直方图不同，因此，两个设备的异常检测结果也不同。设备1中应用的资源用量在一段时间内总是低于T2，因此在这段时间内被确定为一直正常。而设备2中的应用的资源用量在显著的时间占比内高于T4，因此被多次预测或分类为异常。在一示例中，根据用量模式可以指示(例如，通过步骤214处描述的定制机制)设备1中的异常检测模型使用T2(如线条532所示)而不使用T4来检测应用在设备1中的资源用量方面是否异常。这种情况可能是用户想要阻止可疑的应用运行。定制机制可以指示异常检测模型使用T5(如线条534所示)而不使用T4来检测应用在资源用量方面是否异常。这种情况可能是设备2的用户确定设备2和应用消耗大量资源是正常的。定制机制可以提高阈值以避免在应用实际上正常运行时收到频繁显示异常的异常检测结果。

图6示出了另一种用于应用异常检测定制化的实施例方法的图600。在本示例中，可以根据应用对于异常参数的异常模式来定制异常级别和/或动作。图6所示的图610和620展示了同一应用分别在两个不同设备，即设备1和设备2，中使用一段时间针对一个异常参数检测到的异常次数。两个设备使用相同的异常检测模型。x轴表示异常参数，y轴表示检测到的异常次数。在这段时间内检测到的异常可以落在根据一组异常阈值T至T7定义的多个异常级别。例如，异常参数小于T1时异常处于异常级别1，异常参数在T1和T2之间时异常处于异常级别2，异常参数在T2和T3之间时异常处于异常级别3，等等。因此，图610和620分别示出了设备1和设备2的异常模式。在一示例中，可以计算一段时间内每个设备的异常检测结果的直方图，并使用直方图来显示在相应设备中针对应用检测到的每个异常级别的频率或次数。历史数据，例如在图2的步骤210处记录的数据，可以用来确定直方图。假设异常检测模型如线条630所示根据T4确定应用是否异常，那么两个设备的异常阈值可以根据其各自的异常模式分别调整。如图所示，对于设备1，所有检测到的异常都发生在异常参数低于T2(即只有异常级别1和2)时，并且在该段时间内未检测到更高的异常级别。在一示例中，可以为设备1选择阈值T2(如线条632所示)作为检测异常的阈值，超过T2的任何资源用量水平对于该设备均被视为异常或非预期。另一方面，设备2是重度资源用户，异常检测模型检测到许多不同异常级别的异常实例。例如，为了避免发出过量通知，或者为了允许应用和用户拥有更多的自由来使用设备资源，设备2可以使用阈值T5(如线条634所示)而不使用T4来确定应用是否异常。也可以根据异常模式调整针对每个异常级别所要采用的动作。

返回参考图2，在步骤216处，方法200可以接收用户反馈。用户反馈可以包括用户的指示、说明或选择，例如采取具体动作、通过使用较低的异常级别或较低阈值进行异常检测来节约更多的能量、针对异常级别使用特定阈值、或使用具体的阈值级别标记应用、允许应用拥有更多或更少的自由来使用需要的资源用量、更改查看通知的频率、根据检测到的异常级别更改动作、或者任何其它可以用来检测应用异常并采取恰当动作的反馈信息。计算设备还可以在步骤210处存储反馈信息。在步骤210处记录的数据有助于改进用户体验、提高设备性能、改善设备、服务或应用(包括软件和硬件组件)的设计和开发。例如，该数据可以用来识别应用或进程中的缺陷或性能问题。该数据可以用来比较各种设备型号、软件组件或硬件组件不同版本之间的性能和用户体验。该数据还可以用来提高当前和未来产品中的软件和硬件组件的设计和性能，并提高用户对设备的满意度。

在一些实施例中，计算设备可以接收并运行多个异常检测模型，检测一个或多个应用针对一个或多个异常参数的异常。每个异常检测模型均可以使用机器学习技术构建。多个异常检测模型可以用于检测应用针对相同异常参数或不同异常参数的异常。多个异常检测模型可以设计为检测设备中同一组应用或不同组应用的异常。多个异常检测模型可以使用相同输入数据(例如，资源用量、能耗和如上所述的其它相关应用和设备数据)或者可以使用不同输入数据来检测设备中所使用的一个或多个应用的异常。由于多个异常检测模型的设计或构建不同，例如在使用深度神经网络模型进行训练时的随机初始化，或者在使用机器学习训练时使用了不同的训练方法，因此所述多个异常检测模型为同一应用针对同一异常参数可能产生不同的异常检测结果。

计算设备可以使用多个异常检测模型同时检测一个或多个应用的异常。可以使用多个异常检测模型提高整体检测性能。图7示出了用于应用异常检测的实施例方法700的图。在本示例中，计算设备使用多个异常检测模型，即模型1(702)、模型2(704)……模型K(706)来检测一个或多个应用针对M个异常参数，即参数1、参数2……参数M的异常。例如，异常参数可以是CPU FG能耗、CPU BG能耗以及自启动次数。在一些实施例中，向模型1至模型K中的每个模型输入的输入数据是相同的，例如资源用量和如图2所示的其它相关数据。不过，一个模型可以只使用一部分资源用量数据进行应用异常检测。模型1至模型K中的每个模型接收输入数据并针对M个异常参数中的每个参数生成异常检测结果。在一示例中，K个模型中的每一个可以是检测应用异常级别的异常级别检测模型。在另一示例中，前述三个模型中的每一个都可以是异常概率估计模型，可生成应用落在一组异常级别的估计概率。在又一示例中，一个模型，例如模型1，是异常级别检测模型，其它模型是异常概率估计模型。在又一示例中，模型1是异常概率估计模型，其它模型是异常级别检测模型。在又一示例中，模型1至模型K中的全部或大多数是异常检测模型，但每一个模型使用不同的机器学习方法或不同的训练算法训练。模型E(708)可以用来组合模型1至模型K的异常检测结果，并针对M个异常参数中的每个参数为应用生成组合检测或估计结果。模型E也可以由计算设备接收和运行。模型E可以使用机器学习技术构建。模型E可以是神经网络、贝叶斯网络或多数投票模型。模型E可以使用各种方法组合模型1至模型K的检测结果，例如多数投票或加权总和等。对于K＝3且M＝2，表2作为说明性示例示出了针对某个时间点或某段时间在设备上为应用所记录的示例数据模型1至模型3的异常检测结果以及模型E的组合结果。在本示例中，模型1和模型3是异常级别检测模型，生成三个异常级别的检测结果，即过度使用、异常和高度异常。模型2是异常概率估计模型，生成三个异常级别的概率。“异常检测模型”一词可以是指异常级别检测模型、异常概率估计模型或其组合。

表2

图8示出了一种用于计算设备和服务器之间交互以进行应用异常检测的实施例方法800的图。计算设备810可以从服务器820下载或接收一个或多个异常检测模型，执行该一个或多个异常检测模型，并检测一个或多个应用针对一个或多个异常参数的异常。计算设备810可以执行图2所示的方法200。计算设备810可以将其在一段时间内记录的数据发送给服务器820，类似于图2中的步骤212。

服务器820可以是局域网服务器、远程服务器或云服务器。服务器820用于从多个计算设备，例如830至834以及810收集用于构建一个或多个异常检测模型的数据。可以在用户同意或许可时从随机选择的一组设备中收集数据，以帮助改善一组应用的性能和用户体验等。随机选择是为了保护隐私，使得用户来自均匀分布在全球的各种不同地区。可以定义有关策略，要求不能集中于任何特定区域选择用户以及不可以收集可识别或隐私敏感数据。所有数据都是匿名的，保护用户数据隐私并确保用户数据安全。服务器和计算设备之间的通信或交互可以是双向的，以发送和接收数据和模型。服务器820获取收集的数据，对收集的数据进行分析，并训练一个或多个异常检测模型。服务器820可以将一个或多个异常检测模型推送给一个或多个计算设备。服务器820可以通知一个或多个计算设备，可以下载或升级异常检测模型了。服务器820可以定期收集数据并通过使用新收集的数据训练模型来更新一个或多个异常检测模型。这样，该一个或多个异常检测模型可以更新，以适应用户行为的变化或环境变化。

图9为一种用于构建异常检测模型的实施例方法900的流程图。方法900指示了服务器，例如图8中的服务器820，执行的操作。下文以一个应用和一个异常参数为说明性示例描述方法900。当然，方法900所构建的异常检测模型也可以检测多个应用针对一个或多个异常参数的异常。如图所示，在步骤902处，方法900获取与在多个计算设备上运行的一个应用有关的数据样本。在有多个应用的情况下，方法900可以获取与在多个计算设备上运行的多个应用有关的数据样本。从每个计算设备收集的数据样本可以包括图2中的步骤212中描述的计算设备发送的数据。例如，从每个计算设备收集的数据样本可以包括应用的资源用量数据，例如针对图2描述的资源用量数据；为应用生成的检测结果，例如在图2中的步骤206处获取的检测结果；对应用采取的动作，例如在图2中的步骤208处采取的动作；应用的异常参数，例如CPU BG能耗、CPU FG能耗、唤醒锁保持时间、IO访问速率、存储器空间、功耗等；应用的用量模式；或用户体验反馈，例如在图2中的步骤216处接收的反馈。从每个计算设备收集的数据样本可以包括多组数据样本，每组数据样本可以与特定时间戳相关联。

在步骤904处，方法900确定异常参数。异常参数与应用所访问的资源的相关资源用量相对应。方法900可以确定或选择用于训练异常检测模型的异常参数，以检测应用针对该异常参数的异常。异常参数指示将使用计算设备的哪种资源来判断应用是否运行正常。可以根据从专家、设计师或服务提供商等接收的输入来确定异常参数。异常参数的选择可以基于设计目标、节能要求或客户要求。可以确定多个异常参数，每个异常参数用于一个或多个应用的异常检测。异常参数可以通过对若干资源用量参数进行组合或执行数学运算所得出的组合参数、属性或量化特征。例如，异常参数可以是Wi-Fi BG用量、调制解调器BG用量和蓝牙BG用量的加权总和。在另一示例中，异常参数可能是后置摄像头的用量、前置摄像头的用量和多媒体用量的加权总和。

在步骤906处，方法900确定针对所确定的异常参数要生成的异常检测结果的格式。例如，异常检测结果的格式可以指示应用是正常还是异常。在另一示例中，异常检测结果的格式可以指示应用在一组异常级别中的一个级别上是否存在异常。在另一示例中，异常检测结果的格式可以指示应用落在一组异常级别中的概率。所述一组异常级别可以包括图4所述的异常级别。方法900也可以使用组合格式。例如，方法900可以针对CPU FG能耗检测应用在一组异常级别中的一个级别上是否存在异常，并且也可以估计应用落在该组异常级别的概率。对于不同的异常参数，异常检测结果或异常级别的格式可能不同。异常检测结果或异常级别或异常类别的格式可以由专家、设计师或服务提供商根据知识和经验、设计目标、节能要求或客户要求确定。

在步骤908处，方法900对收集的数据样本进行数据分析。对数据样本进行的数据分析可以用来识别异常参数的一个或多个相关或从属参数。不同的资源用量可以彼此相关或从属。因此，确定第一资源用量方面的异常时可能需要考虑第二相关或从属的资源用量。异常参数的相关或从属参数也可以称为用量参数。图10所示的图1000展示了第一异常参数和相关资源用量参数或属性(为方便说明统称为相关参数)之间的关系。所示关系基于从多个用户设备收集的与应用相关的数据样本。图10中的每个点(或实心小圆圈)表示一个计算设备或一个用量数据样本。x轴表示高度相关或从属于第一异常参数的相关参数(即相关资源用量参数或属性)，y轴表示第一异常参数。如图所示，相关参数与第一异常参数之间存在显著的相关性。第一异常参数(可以是资源用量)随着相关参数的上升而上升。在一示例中，相关参数(x轴)可能是指示活跃或主动资源使用量的参数，由用户或设备选择使用，而第一异常参数(y轴)可能被视为自主资源使用量，在某种程度上与用户的资源主动用量相关或由其引发。

针对第一异常参数(可以是CPU BG用量等资源用量)的应用异常通过检查第一异常参数是否超过线条1002所示的固定阈值来确定。如果第一异常参数超过阈值，则确定应用在第一异常参数上异常。然而，在一些情况下，较高的第一异常参数值是由应用的相关资源用量参数值较高而导致的，因此也可能是正常的。在这种情况下，当相关资源用量参数出现较大取值时，应用不会被确定为异常。

在一实施例中，可以对多个计算设备的高度相关或从属的资源用量参数(图10中的x轴)的值进行分析，并将其划分为若干用户组，例如1至6。组1至组6中的每一组对应相关资源用量参数的一个取值范围。然后，该多个计算设备根据其与第一异常参数高度相关或从属的资源用量参数的值划分成用量组。计算设备上的应用所使用的相关资源用量参数的值可以使用从计算设备收集的数据样本生成。然后，可以根据每个用量组的相关资源用量参数为每个用量组计算一个或多个异常阈值。当只考虑一个异常级别(可以识别正常和异常使用)时，线条1004至1014分别示出了根据统计异常分析、异常评估或异常检测标准、或使用专业知识或应用日志或系统日志为图10的示例中的组1至组6计算的阈值。下表3示出了为组1至组6计算的六个阈值(T1,1)至(T1,6)。(T1,i)表示组i的阈值T1。阈值的计算考虑了各个组中的相关资源用量参数的影响。异常阈值确定后，当判断计算设备上的应用针对第一异常参数是否异常时，可以首先根据计算设备相关资源用量参数将计算设备划分到组1至组6中的一个组，然后识别该组的阈值并将该阈值与应用的第一异常参数相比较。如果应用的第一异常参数超过所识别的阈值，则确定应用在第一异常参数上异常。通过将计算设备划分到不同的用量组并使用组专用阈值可以减少或避免异常检测中的缺陷或失误。基于每个用量参数所划分的用量组可以更新或重新定义，并且可以根据新收集的数据样本重新计算对应的阈值。

组

G1

G2

G3

G4

G5

G6

阈值

T1,1

T1,2

T1,3

T1,4

T1,5

T1,6

表3

在一些实施例中，可以在一个异常参数和多个相关资源用量参数之间确立或识别从属关系。可以根据每个相关或从属参数定义多个组。在这种情况下，阈值的计算可以考虑根据部分或全部相关或从属参数的组合所定义的组。例如，某个异常参数被识别为从属于两个不同的资源用量参数，即参数1和参数2。参数1和参数2的示例可以包括亮屏时间、Wi-Fi锁定时间、音频使用时间和多媒体使用时间。例如，基于对所收集的数据样本的数据分析，根据参数1定义四个组，根据参数2定义两个组。每个用量参数的组可以按照类似于上述有关图10的方式定义。然后，可以在计算阈值时考虑计算设备落在根据所有相关参数定义的组的各种可能组合的情况。表4示出了针对这种情况计算的示例阈值。在表4中，Gki表示根据参数k定义的第i个组，其中，k＝1，2，i＝1，2，3，4。对应于组的每种组合，确定八个阈值，即(T1,1)至(T1,8)。例如，当计算设备落在根据参数1和参数2定义的G11和G21的组合时，使用阈值(T1,1)来比较异常参数，以确定应用在异常参数上是否存在异常。当计算设备落在根据参数1和参数2定义的G13和G22的组合时，使用阈值(T1,6)。在一些实施例中，可以将落在组的同一组合的计算设备划分为一个组合组。如表4所示，落在G11和G21的组合的计算设备划分为组合组CG1，落在G11和G22的组合的计算设备划分为组合组CG2，落在G12和G21的组合的计算设备划分为组合组CG3，等等。这样，根据本示例的两个相关或从属资源用量参数，参数1和2，可以定义八个组合组，即CG1至CG8，每个组合组分别对应一个阈值(T1,1)至(T1,8)。当某个异常参数只识别出一个相关或从属参数时，所产生的组合组将会与根据单个相关或从属参数所划分的组相同。由于异常检测基于具有对应阈值的用量组进行，因此本发明中组合组也可以被称为用量组。

组合组

CG1

CG2

CG3

CG4

CG5

CG6

CG7

CG8

参数1

G11

G11

G12

G12

G13

G13

G14

G14

参数2

G21

G22

G21

G22

G21

G22

G21

G22

阈值

T1,1

T1,2

T1,3

T1,4

T1,5

T1,6

T1,7

T1,8

表4

在一些实施例中，可以为每个用量组确定多个异常级别、多个异常类别或多个异常阈值，而不是如图10所说明的为每个用量组使用单个异常阈值。作为示例，图11示出了存在3个异常阈值的情况，即意味着有四个异常类别(例如，正常、过度使用、异常和高度异常)。在图11中，Ti,j表示用量组j的阈值Ti，其中，i＝1，2，3，j＝1，2，……6。当相关资源用量参数属于组1时，用量组1中的“正常”类别是指异常参数的值低于阈值(T1,1)。对于用量组1，“高度异常”是指异常参数的值高于(T3,1)，以此类推。

返回参考图9，根据在步骤908处进行的数据分析，方法900在步骤910处识别异常参数的一个或多个相关或从属参数。在步骤912处，方法900根据一个或多个相关或从属参数确定多个用量组。在步骤914处，方法900为每个用量组计算异常级别。可以根据统计分析和异常评估算法进行计算。当考虑检测多个异常级别时，方法900可以如图11中所述为每个用量组识别多个阈值而不是一个阈值。在步骤916处，方法900针对异常参数确定来自每个计算设备的每个数据样本的异常级别。异常级别的确定基于从对应计算设备收集的数据样本并使用对应于多个组合组所生成的阈值。例如，方法900确定计算设备属于哪个组合组，例如表4中的CG4，并将计算设备上应用的异常参数的值与对应于所确定的组合组的阈值，即(T1,4)，相比较。然后，方法900生成与相应计算设备的数据样本相对应的异常检测结果。例如，如果从计算设备收集的数据样本包括计算设备在不同时间记录的6组数据样本，每组数据样本包括图2中所存储的数据，则方法可以生成6个异常检测结果，如表5中作为示例所示出的。每个数据样本都具有对应的异常检测结果，指示每个样本所属的异常类别。

数据样本标识	1	2	3	4	5	6
							检测结果	正常	过度使用	正常	异常	异常	高度异常

表5

方法900可以为每个计算设备或其中一部分设备的每个数据样本生成异常类别或级别。所生成的类别或级别可以称为参考异常类别或级别。参考异常类别或级别生成后，在步骤918处，方法900为每个数据样本分配异常标签。分配给数据样本的异常标签指示与数据样本相对应的异常类别或级别。以表5为例，可以为数据样本1分配“正常”标签，为数据样本2分配“过度使用”标签，为数据样本3分配“正常”标签，分别为数据样本4和5分配“异常”标签，为数据样本6分配“高度异常”标签。这样，可标记所收集的全部或部分数据样本。在步骤920处，方法900使用部分或全部已标记的数据样本训练异常检测模型。可以使用对该任务适用且有效的机器学习技术训练异常检测模型。例如，异常检测模型可以是人工神经网络、深度神经网络或贝叶斯网络等等。在步骤922处，方法900可以将更新的异常检测模型通知给用户或设备。方法900可以通知异常检测模型已可以下载或升级了。在步骤924处，方法900可以将异常检测模型推送给设备。

方法900可以收集大量数据样本来训练一个或多个异常检测模型。方法900可以用于构建根据多个异常参数检测多个应用的异常的异常检测模型。方法900可以获取与多个计算设备上运行的多个应用相关的数据样本，并可以为每个应用执行方法900的步骤904至920。然后，使用应用组合的标记数据和异常参数构建一个或多个能够立即为多个应用和多个异常参数检测异常或生成预测输出的异常检测模型。

图12示出了一种用于应用异常检测的实施例系统1200的框图。如图所示，实施例系统1200包括计算设备1210和服务器1250。计算设备1210包括监控和数据记录模块1212、异常检测模块1214、动作模块1216、收发模块1218、存储器或内存1220以及定制或设备适配模块1222。服务器1250包括收发模块1252、数据检索和数据分析模块1254、机器学习模块1256和存储模块1258。

监控模块1212可以用于监控应用在计算设备1210上运行或执行期间的资源用量，并获取和收集应用的资源用量数据以及其它相关的设备和环境数据。监控模块1212获取的数据可以存储在存储器1220中。异常检测模块1214可以用于使用一个或多个异常检测模型检测在计算设备1210上运行的一个或多个应用的异常，例如使用图2或图7中所示的实施例方法。动作模块1216可以用于针对异常检测模块1214的结果采取动作，例如执行图2中的步骤208。动作模块1216可以从存储器1220中检索动作，并将所采取的与异常检测结果对应的动作记录在存储器1220中。收发模块1218可以用于检索存储器1220中存储的数据，将数据发送给服务器1250，并从服务器1250接收一个或多个异常检测模型。定制模块1222可以用于执行图2中的步骤214，并调整1216用来采取动作的标准，如上文结合图4至图6所讨论的。

收发模块1252可以用于从存储器1258中检索一个或多个异常检测模型，并将一个或多个异常检测模型发送给计算设备1210和其它计算设备。收发模块1252还可以用于从计算设备1210和其它计算设备接收数据，并将接收到的数据存储在存储器1258中。数据检索模块1254用于从存储器1258中检索数据，由机器学习模块1256用来构建或训练一个或多个异常检测模型。机器学习模块1256可以用于执行步骤908至920，构建一个或多个异常检测模型，并将设计或构建的异常检测模型存储在存储器1258中。服务器1250可以连接到多个计算设备，从多个计算设备接收相关数据，并使用从多个计算设备接收到的数据构建一个或多个异常检测模型。

在一些实施例中，异常检测模块1214可以不全部在设备中执行，而是可以将资源用量和其它相关数据发送给本地计算服务器或远程计算服务器以执行异常检测。这意味着设备可能没有模块1214，可以在设备外部执行异常检测任务，然后将检测结果发回到设备。然后，设备可以针对为设备使用的每个应用所检测的异常级别采取响应动作。在另一实施例中，异常检测模型1214可以分为两部分。例如，第一部分，包括属性或资源用量参数提取、数据分析和预处理，可以在设备内部执行，异常检测进程的剩余部分可以在本地或远程计算服务器或配套设备上执行，然后将检测结果被发回到设备。

图13示出了一种用于应用异常检测的实施例方法1300的流程图。方法1300可以指示在用户设备处执行的操作。如图所示，在步骤1302处，方法1300从远程设备接收第一异常检测模型。第一异常检测模型采用机器学习技术，是可训练的，用于检测应用在资源用量方面的异常。在步骤1304处，方法1300获取应用的资源用量数据。可以根据第一异常检测模型获取资源用量数据。资源用量数据包括相关设备和环境数据以及应用在计算设备上所访问的一个或多个硬件组件或一个或多个服务的用量或能耗信息。在步骤1306处，方法1300使用第一异常检测模型根据所获取的资源用量数据确定应用在资源用量方面是否存在异常。在步骤1308处，方法1300根据对应用在资源用量方面的异常的判断结果采取响应动作。

图14为一种用于构建异常检测模型的实施例方法1400的流程图。方法1400可以指示在本地计算服务器、远程服务器或云服务器等远程设备处的操作。如图所示，在步骤1402处，方法1400获取从多个计算设备获取有关应用的数据样本。数据样本可以包括应用在多个计算设备上所访问的一个或多个硬件组件或一个或多个服务的用量或能耗信息，以及其它相关设备和环境数据。每个数据样本可以与一个计算设备相关联。在步骤1404处，方法1400向数据样本分配标签。分配给与相应计算设备相关联的数据样本的标签指示应用在相应计算设备的第一资源用量上所具有的异常级别，该级别是多个异常级别中的一个。在步骤1406处，方法1400使用已标记的数据样本和机器学习技术构建异常检测模型。异常检测模型用于检测应用在第一资源用量方面的异常。

可以确定所检测到的应用异常所针对的第一资源用量(或参数、属性或量化参数)。第一资源用量对应第一异常参数或属性。可以确定一组异常级别来指示应用在第一资源用量方面的异常级别。对于每个计算设备，可以根据相应计算设备的数据样本检测或确定应用在第一资源用量方面是否存在异常。这样，针对多个计算设备的数据样本可以生成多个异常评估(或检测)结果，每个异常评估结果指示一组异常级别中的一个。然后，可以根据评估结果为数据样本标记对应的异常级别。

可以使用在图9中的步骤912至916处所述的方法来确定应用的异常。在一些实施例中，也可以使用其它方法根据对所收集的数据样本的分析来确定应用的异常。例如，可以使用异常评估和数据分析方法来评估数据样本的异常级别，异常评估和数据分析方法包括诸如基于密度或分布的方法、基于距离的方法、基于集群的方法、基于相似度的方法、基于机器学习的方法或基于重构误差的方法。对于与一个应用相关联的数据样本，可以针对每个相关属性或资源用量给每个数据样本分配对应的异常标签。在另一实施例中，给每个数据样本分配的不是一组标签或异常级别，而是连续的异常或用量严重程度值并用其训练模型以估计或预测资源用量和异常级别。在一些实施例中，确定应用在资源用量方面是否存在异常不是通过对从多个设备收集的大量数据进行统计分析、异常评估和数据分析实现，而是使用性能日志、使用日志、事故报告或用户体验反馈来进行。另外，专家可以根据其经验、洞察和知识来评估所收集的数据样本和记录，以确定设备中是否发生了应用异常。

图15示出了另一种用于应用异常检测的实施例方法1500的流程图。如图所示，在步骤1502处，方法1500检测在计算设备上运行的应用在资源用量方面是否存在异常。可以使用以机器学习技术构建的异常检测模型根据所获取的应用的资源用量数据来检测应用的异常。方法1500可以检测应用在多个异常级别和用量水平方面是否存在异常。然后可以生成应用的异常检测结果，异常检测结果可以包括所检测出的一个或多个异常级别以及每个级别的概率。在步骤1504处，方法1500可以根据异常检测结果对应用的执行采取动作。在步骤1506处，方法1500可以在一段时间内收集应用的异常检测结果以及所采取的相应动作相关的数据。在步骤1508处，方法1500可以使用适配或定制模型根据收集的数据来调整异常检测结果对应的响应动作。此举可以有助于改善计算设备的用户体验或性能。

本发明实施例减少了由于应用在计算设备中运行异常而引起的过度能耗，因而有助于改善用户体验。对于采用电池供电因而在能量容量上受限的计算设备，这些实施例更为有用。如果应用、进程、工具或软件在设备中异常运行一段时间，会导致电池比正常情况更快消耗，因此可能导致设备用户对设备的性能和效率不满意。使用通过分析应用对硬件组件、服务和资源的用量所收集的数据来检测异常。如果应用在能耗或资源用量方面的异常发生了一段时间，可能会导致设备温度异常升高，进而可能导致设备或其组件的损坏或性能降低。因此，各实施例的异常检测也可以防止设备过热或发热问题。本发明实施例还可以检测应用或进程异常使用计算设备中的资源、组件或服务的情况或事件，以有助于防止应用降低设备的整体性能或整体用户体验。当资源存在异常使用时，该资源被分配到其它应用或系统进程可能会降低资源的性能，因此，设备运行的性能可能会降低。本发明实施例改善了用户体验，增强了性能，延长了电池寿命，降低了整体能耗，减少了过热或发热问题，并有助于更加正常和有效的使用计算设备中可用的软件或硬件组件等资源。

图16示出了一种用于在计算设备上运行的应用的异常检测的实施例方法1600的流程图。方法1600在应用运行时根据在应用执行期间收集的数据检测应用的异常，实现实时的应用异常检测。如图所示，在步骤1602处，方法1600监控计算设备上正在运行的应用。在一些实施例中，监控应用包括监控应用直接或间接使用或访问的资源的用量，例如在应用运行或执行期间所访问的一个或多个硬件、一个或多个服务、一个或多个软件组件或一个或多个资源的用量。硬件的用量可以包括访问或使用硬件的模式，例如访问时长、访问速率、访问开始时间和结束时间等。方法1600可以获取(例如收集或接收)应用所使用的一个或多个硬件的用量数据。在一些实施例中，一个或多个硬件的用量数据可以包括CPU前台用量、CPU后台用量、唤醒锁保持时间、自启动次数、应用的亮屏时间、蜂窝用量和模式(例如，包括前台和/或后台的蜂窝用量和/或接收质量)、Wi-Fi用量和模式(例如，包括前台和/或后台的Wi-Fi用量和/或接收质量)、存储器用量、输入输出(input-output，IO)设备的用量或定位服务的用量(例如所使用的定位服务的数量)或其任意组合。在一些实施例中，一个或多个硬件的用量数据还可以包括GPU用量(例如，包括前台和/或后台GPU用量)、到达通知的数量、版本信息、音频服务的用量(例如，前台和/或后台音频用量)或用户数据的访问次数或其任意组合。一个或多个硬件的用量数据将用于检测应用执行的异常。本领域普通技术人员将认识到，此处给出的有关一个或多个硬件的用量的示例只是为了说明，有关硬件用量的任何数据在实施例方法中都适用。

以智能手机中安装的名为“Whatsapp”的社交网络应用为例。该应用可以访问智能手机的硬盘以播放硬盘中存储的音乐，可以使用存储器缓存来暂时存储要播放的音乐数据，可以访问智能手机的屏幕以显示音乐的播放，可以访问扬声器以播放音乐。方法1600可以监控Whatsapp对硬盘、存储器、屏幕和扬声器这些硬件的使用，并相应地收集用量数据。例如，用量数据可以包括屏幕显示时长、扬声器开启时长、用于播放的缓存大小以及硬盘的访问次数。所述数据还可以包括Whatsapp执行所消耗的功率(例如，电池功率)。所述数据还可以包括在Whatsapp执行期间的一段时间内显示器消耗的能量、CPU消耗的能量等。在一示例中，当Whatsapp通过Wi-Fi在线播放歌曲时，方法1600还可以监控诸如无线接口的用量，并获取Wi-Fi锁保持时间等Wi-Fi接口用量相关数据。

在一些实施例中，方法1600可以将所获取的一个或多个硬件的用量数据与应用相关联。这种关联对于某些情况是有利的。比如，应用所访问的硬件用量数据实际上由应用之外的其它实体如计算设备中的其它进程或计算设备的操作系统等生成，但没有识别出用量的贡献者即应用。在Whatsapp播放音乐的示例中，实际上被激活为Whatsapp传送流式音频并消耗能量的是智能手机中的音频服务器或媒体管理器。如果音频服务器由于Whatsapp的音乐播放而消耗了x的能量，该x能量可能被记录为音频服务器的操作，而没有关联到实际上消耗能量的源贡献者Whatsapp。将所获取的一个或多个硬件的用量数据与数据的源贡献者即应用相关联，有助于识别与应用的运行关联的用量数据以用于确定该应用的异常。当应用存在不同版本时，关联信息可以包括应用版本的标识信息。

基于所获取的数据，方法1600可以检测应用是否运行异常，或者应用是否发生异常。方法1600可以监控应用在一段时间内对硬件、服务或其它资源的用量，获取相关数据，并定期检测是否发生异常。可以根据各种异常检测条件或要求来检测是否发生异常。异常检测条件或要求可以触发或发起应用异常检测操作。例如，当应用占用的存储器空间超过阈值时，可以确定应用存在异常。这种情况下，要求或条件就是存储器空间超过阈值。在另一示例中，当应用消耗超过阈值量的功率时，可以确定应用存在异常。这种情况下，要求或条件就是功耗超过阈值或限制。在又一示例中，当应用的Wi-Fi锁定时长超过阈值时，可以确定应用处于异常状态。这种情况下，要求或条件就是Wi-Fi锁定时长。异常检测要求或条件的示例包括存储器空间、Wi-Fi锁保持时间、功率、IO访问、CPU用量、GPU用量、唤醒锁保持时间等。在本发明中，术语“异常检测条件”和“异常检测要求”可互换使用。在一实施例中，单个异常检测条件满足时即可检测到应用的异常。在另一实施例中，多个异常检测条件或要求满足时才检测到应用的异常。可将不同异常检测条件组合并用于确定应用异常。也可以将异常检测条件或要求理解为对应于一个参数，例如存储器空间大小、功耗量或Wi-Fi锁定时长等用于确定应用异常的参数。参数指示应用在执行期间所访问的硬件的用量。根据异常检测条件指示的参数检测应用的异常。参数的示例可以包括平均存储器空间大小、IO设备的访问速率、平均唤醒锁保持时间、平均Wi-Fi锁定保持时间、GPU工作时间、CPU工作时间、平均能量用量或CPU后台运行时间。本领域普通技术人员将认识到适用于实施例方法的各种异常检测要求和参数。

如图16所述，在步骤1604处，根据异常检测条件，方法1600根据一个或多个硬件的用量数据计算与异常检测条件指示的参数对应的值。在一些实施例中，方法1600可以建立(或配置)一组模型，每个模型对应一个异常检测条件。每个模型将获取的一个或多个硬件的用量数据作为输入，生成一个与异常检测条件指示的参数对应的值作为输出。这些模型也可以合并为单个模型，该模型能够生成与不同异常检测条件对应的参数值。在这种情况下，单个模型可以将所获取的一个或多个硬件或服务的用量数据作为输入，并将指示使用哪个异常检测条件来计算参数值的指示信息作为输出。模型可以是为应用异常检测预先确定的数学模型。例如，数学模型可以根据以下公式计算参数的值：

ω0+ω1*Tx+ω2*Rx+ω3*carrier+ω4*RAT+ω5*f+ω6*MIMO+ω7*CA+ω8*S+ω9*mobility+ω10*location

其中，ωi为使用机器学习技术训练的系数，“Tx”为上传的数据量，“Rx”为下载的数据量，“carrier”是指服务提供商，“RAT”为使用的无线电技术，“f”为使用的无线信道，“MIMO”指示是否启用MIMO模式，“CA”为载波聚合状态，“S”为信号强度，“mobility”指示设备的移动，“location”指示设备的服务基站塔。在另一实施例中，用于应用异常检测的数学模型可以是更为复杂的多阶段或多层次模型，例如深度神经网络或贝叶斯估计网络，其使用更多的收集的输入数据、输入数据的各种组合或各种二级或更高级别的属性或量化来为一个或多个应用估计异常参数或检测异常条件。

在步骤1606处，方法确定所计算的参数值是否超过与异常检测条件/要求对应的阈值。例如，当该值对应于功耗参数时，阈值可以是功率阈值。在另一示例中，当该值对应CPU工作时长参数时，阈值可以是时长阈值。在又一示例中，当该值对应IO访问速率参数时，阈值为访问速率阈值。计算设备可以以表格形式等维护一个与不同异常检测条件/要求相对应的阈值列表。如果没有定义对应于异常检测条件/要求的阈值或没有为应用确定阈值，方法1600可以在这一步骤停止，不进行任何后续步骤。

在步骤1608处，当所计算的值超过阈值时，方法1600确定应用发生异常，并采取响应动作。所采取的动作可以减轻或避免应用异常的负面影响。在一示例中，采取的动作是冻结应用的运行。在另一示例中，采取的动作是杀死应用。在又一示例中，采取的动作是向计算设备的用户发出通知，例如异常通知。通知可以指示异常的发生，以便用户可以采取其认为合适的响应动作。通知可以指示计算的值以及用于确定异常的阈值。通知还可以指示一个动作列表，用户可以从中选择动作以响应于所发生的异常。在一些情况下，用户可以依据其喜好、经验或知识，选择不理会异常通知，不采取任何动作。

在一些实施例中，方法1600可以根据两个或两个以上不同的异常检测要求的组合来检测应用的异常。例如，方法1600可以根据有关硬件用量的数据计算电池功耗的值以及Wi-Fi锁定保持时间的值，并将每个值与对应的阈值相比较。可以定义不同的标准来确定是否检测到异常。例如，当两个值都超过对应阈值时，方法1600确定检测到异常。在另一示例中，当两个值中的一个超过对应阈值时即可确定检测到异常。

在步骤1610处，方法1600可以根据在步骤1606中的判断结果来更新阈值。可以更新阈值以更谨慎地保护计算设备在功耗、过热、性能、用户体验等方面免受应用异常的负面影响。以Whatsapp为例说明，当Whatsapp消耗的功率为10瓦(即根据Whatsapp访问的硬件有关的数据、使用模型计算出的值)而阈值为3瓦时，方法1600确定Whatsapp运行异常，并关闭Whatsapp。由于检测到Whatsapp的异常，方法1600可以决定进一步降低阈值例如降低0.5瓦以便下次更早检测到异常。在另一示例中，如果用户针对检测到Whatsapp的异常不采取任何响应动作，则可以将计算出的功耗，即10瓦，作为该用户专用的新阈值，并用于自此之后基于功耗的异常检测。可以定义各种规则来确定是否更新阈值以及如何更新阈值。方法1600可以在每次检测到异常时或在检测到的异常达到预定次数后更新或调整阈值。方法1600还可以请求计算设备的用户来决定是否更新阈值和/或如何更新阈值。从步骤1610处得到的更新阈值为在计算设备上运行的应用专用且对应于异常检测条件。

在一些实例中，计算设备可以从云服务器等服务器接收阈值或一组阈值。从服务器接收的阈值可以称为在某个异常检测要求方面适用于所有应用或一组应用的公共阈值。计算设备可以使用同一公共阈值根据异常检测要求对任何应用(或组中的任何应用)进行异常检测。计算设备可以根据一组异常检测要求从服务器接收并维护公共阈值列表。计算设备还可以接收更新的公共阈值，并将对应的旧的公共阈值替换为更新的公共阈值。

在一些实施例中，计算设备可以接收与异常检测要求相对应的初始公共阈值，并使用该初始公共阈值确定应用异常，例如通过将异常检测要求所指示的参数值与初始公共阈值相比较。计算设备稍后可能接收到初始公共阈值的更新(第二公共阈值)，并将初始公共阈值替换为更新的公共阈值，用于应用异常检测。当计算设备如图16的步骤1610中所示在检测到异常后(例如，使用第二公共阈值)进行阈值更新、从而生成第三阈值时，计算设备不会将第二更新公共阈值替换为第三阈值。相反，计算设备可以将第三阈值储存为对应于异常检测要求的专门适用于计算设备上的应用的设备专用阈值。这样，对应于异常检测要求，计算设备可以具有两个阈值，即公共阈值和设备专用阈值。

在一些实施例中，计算设备可以有一份公共阈值列表以及与不同异常检测要求相对应的一组用户专用阈值，如表6所示。表6示出了三个异常检测条件，即Wi-Fi锁定保持时间、GPU工作时间和IO访问速率，每个条件对应一个公共阈值和一个设备专用阈值。设备专用阈值可以使用应用名称等与应用相关联。设备专用阈值与应用的关联信息还可以包括应用的版本信息。例如，如表6所示，IO访问速率对应的设备专用阈值还包括应用名称，即“Whatsapp”，以及Whatsapp的版本号，即“1.0.3”。

表6

当计算设备既具有公共阈值又具有与异常检测条件相对应的设备专用阈值时，计算设备可以根据预定义的规则或标准等选择使用这两种阈值中的任一种进行异常检测。例如，当公共阈值和设备专用阈值取值相近时，例如，当两个阈值之差小于差值阈值时，计算设备可以随机挑选公共阈值和设备专用阈值中的一个。否则，当两个阈值之差不小于差值阈值时，可以使用设备专用阈值。还可以定义其它标准来选择公共阈值或设备专用阈值以检测应用异常。

在步骤1610处更新阈值后，方法1600可以返回步骤1602，继续监控应用(如果该应用未被杀死或冻结)并检测应用的异常，或监控其它应用(如果该应用已被杀死或冻结)。当计算出的参数值不超过步骤1606处的阈值时，方法1600返回步骤1602。方法1600不对应用采取任何动作，应用将继续运行。

方法1600可以实现为计算设备上可执行的单独应用。方法1600也可以实现为在计算设备后台运行的守护进程或系统进程。在任一种情况下，当实施例应用(或守护进程)启动或激活，实施例应用可以首先加载一个或多个用于计算参数值的模型，以确定应用的异常。还可以加载一个或多个公共阈值(和一个或多个设备专用阈值)和一个或多个异常检测要求。方法1600可以检测计算设备上运行的单个应用、一组应用或每个应用的异常。

在一些实施例中，计算设备可以与云服务器等服务器交互，以确定和更新与不同异常检测条件相对应的阈值。计算设备可以通过有线或无线的方式连接到服务器。如上所述，计算设备可以从云服务器接收公共阈值和/或公共阈值的更新。在一些实施例中，计算设备可以将计算设备上运行的应用所访问的硬件或服务的用量相关的数据(例如上述结合图16所讨论的数据)发送给云服务器。计算设备可以定期将所获取的全部此类数据上传到云服务器。计算设备还可以将与异常检测条件相对应的公共阈值和设备专用阈值发送给云服务器。在发送设备专用阈值的情况下，计算设备还可以发送对应应用的标识信息和版本信息。计算设备发送给服务器的数据/信息可以由服务器用来确定或更新公共阈值。在一些实施例中，服务器可以用于向一个或多个设备发送公共阈值或更新的公共阈值。服务器可以定期更新公共阈值并将其发送给一个或多个设备。服务器还可以用于从一个或多个计算设备接收数据/信息，以确定和/或更新与不同的异常检测条件对应的一个或多个公共阈值。信息的示例包括应用在计算设备上所访问的硬件或服务的用量有关的数据、与异常检测条件相对应的公共阈值、与异常检测条件相对应的设备专用阈值以及应用相关信息，例如应用名称、版本号等。

在一些实施例中，服务器或远程控制设备可以从多个设备接收上述信息，并根据接收的信息确定与异常检测条件相对应的公共阈值(或更新的公共阈值)。图17示出了一种用于确定与异常检测条件相对应的公共阈值的实施例方法1700的流程图。方法1700可以由云服务等服务器或配套设备执行。如图所示，在步骤1702处，服务器从存储设备检索多个计算设备发送的有关在这些计算设备上运行的一个或多个应用的信息。如结合图16所述，该信息可以包括各应用在各自计算设备上所访问的硬件、服务或其它资源的用量相关的数据。所述数据可以包括CPU前台用量、CPU后台用量、唤醒锁保持时间、自启动次数、应用的亮屏时间、蜂窝用量和模式、Wi-Fi用量和模式、存储器用量、IO设备的访问次数、或定位服务的用量、GPU用量、到达通知的数量、音频服务的用量、或用户数据的访问次数或其任意组合。该信息还可以包括应用数据，例如应用的名称或标识以及应用的版本信息。该信息还可以包括计算设备所使用的对应于异常检测条件的公共阈值和/或设备专用阈值。该信息可以在云存储器中存储由终端用户许可证协议(end user license agreement，EULA)所指定的一段固定时间。方法1700可以定期从云存储器检索最新上传的信息，提取所需特征进行分析，并编译公共阈值或公共阈值列表。

在步骤1704处，方法1700根据检索到的信息生成与异常检测条件相对应的公共阈值。方法1700可以根据检索到的信息生成与不同的异常检测条件相对应的公共阈值。在一些实施例中，方法1700可以将全部或部分信息输入云端学习模块，由该学习模块输出与异常检测条件相对应的公共阈值。云端学习模块可以是一个机器学习模块，用于使用输入信息训练学习网络。例如，云端学习模块可以包括但不限于贝叶斯估计模型、回归模型、卷积神经网络(convolution neural network，CNN)或决策树集合等。学习网络的示例可以包括多层神经网络或回归学习网络。云端学习模块可以使用任何机器学习机制来根据从计算设备检索到的信息获取公共阈值。

在步骤1706处，方法1700验证所生成的公共阈值。例如，领域专家可以使用系统或应用日志等检查所生成的公共阈值或验证其准确性。公共阈值也可以根据专家的输入变更。在步骤1708处，方法1700将所生成的公共阈值发送给计算设备。所生成的公共阈值可以是计算设备用来根据异常检测条件确定应用异常的初始公共阈值。所生成的公共阈值也可以是发送给计算设备的更新的公共阈值。在这种情况下，计算设备将其公共阈值替换为该更新的公共阈值。方法1700可以通过空中(over-the-air，OTA)推送或传送方式发送所生成的公共阈值。方法1700还可以通过软件更新的方式将所生成的公共阈值发送给计算设备。在这种情况下，所生成的公共阈值可以在更新软件时与系统软件捆绑在一起，或者从软件商店下载。

在实施例方法中，计算设备可以在应用运行期间根据一个或多个异常检测条件并使用收集的有关应用运行的数据以及云服务器提供的一个或多个阈值来检测应用的异常，并且云服务器根据该计算设备和/或与应用执行相关的其它计算设备提供的数据确定一个或多个阈值。计算设备和云服务器都可以(在云端根据该计算设备和/或其它计算设备提供的数据)定期更新一个或多个公共阈值并(在设备端根据异常检测结果)生成一个或多个设备专用阈值。这样，计算设备和云服务器协同工作实时实施应用异常检测，从而提高计算设备的性能并最终改善用户体验。

图18示出了一种用于应用异常检测的实施例方法1800的流程图。方法1800可以是计算机实现的方法。方法1800指示计算设备处的操作。如图所示，在步骤1802处，方法1800获取在计算设备上运行的应用所使用的一个或多个硬件的用量相关数据，其中，该应用在计算设备上的执行期间访问该计算设备的一个或多个硬件。方法1800可以获取有关应用所访问的一个或多个其它资源(例如，服务)的用量的数据，并将数据用于检测应用的异常。在步骤1804处，方法1800根据异常检测要求基于数据检测应用是否运行异常。所述异常检测要求指示一个用于确定应用异常的参数确定应用异常。通过将基于前述数据计算出的参数值与异常检测要求对应的阈值相比较来检测应用是否运行异常。在步骤1806处，方法1800根据应用运行异常的判断结果对应用的执行采取动作。

在一些实施例中，一个或多个硬件的用量数据包括CPU前台用量、CPU后台用量、唤醒锁保持时间、自启动次数、应用的亮屏时间、蜂窝用量和模式、Wi-Fi用量和模式、存储器用量、IO设备的访问次数等IO设备用量或所使用的定位服务的数量等定位服务用量。

在一些实施例中，一个或多个硬件的用量数据还可以包括图形处理单元(graphicprocessing unit，GPU)的用量、到达通知的数量、应用的版本信息、音频服务的用量或用户数据的访问次数。

在一些实施例中，所述参数包括应用占用的存储器空间、IO设备的访问速率、唤醒锁保持时间、Wi-Fi锁保持时间、GPU工作时间、CPU工作时间或CPU后台运行时间。

在一些实施例中，对应用的执行采取的动作包括冻结应用的执行或杀死应用。

在一些实施例中，对应用的执行采取的动作包括生成报告应用运行异常的通知。

在一些实施例中，方法1800可以在应用执行期间的一段时间内监控一个或多个硬件的使用情况。

在一些实施例中，方法1800可以将所获取的数据与应用相关联。

在一些实施例中，方法1800可以使用预先建立的模型计算参数的值。

在一些实施例中，方法1800可以在参数值超过阈值时确定应用发生异常。

在一些实施例中，方法1800可以从云服务器接收阈值。在一些实施例中，接收到的阈值是适用于不同应用的公共阈值。

在一些实施例中，方法1800可以在确定应用运行异常后更新阈值。

在一些实施例中，更新的阈值是专门适用于在计算设备上运行的应用的对应于异常检测要求的设备专用阈值。

在一些实施例中，方法1800可以将有关用量数据和阈值发送给云服务器。

在一些实施例中，方法1800可以将更新的阈值发送给云服务器。在一些实施例中，定期将有关用量数据和阈值发送给云服务器。

在一些实施例中，定期或按需检测应用是否运行异常。

在一些实施例中，方法1800可以从云服务器接收更新的阈值，并将阈值替换为更新的阈值。

本发明实施例可以实现为计算机实现的方法。实施例可以由处理系统执行。本发明中的实施例方法可以实现为存储在非瞬时性计算机可读介质中的可由一个或多个处理器执行的计算机指令。非瞬时性计算机可读介质包括磁性存储介质、光存储介质、闪存介质和固态存储介质等各种类型的计算机可读介质。应当理解，异常检测模型和相关软件可以预先安装在计算设备中。或者，该软件可以被获取并加载到计算设备中，获取途径包括通过物理介质或分发系统获取，例如从软件开发者所拥有或所使用的服务器获取软件。该软件可以存储在服务器上以供通过互联网分发等。

图19示出了用于执行本文所述方法的实施例处理系统1900的框图，其中，处理系统1900可以安装在主机设备中。如图所示，处理系统1900包括处理器1904、存储器1906和接口1910至1914，它们可以(或可以不)如图19所示排列。处理器1904可以是用于执行计算和/或其它相关处理任务的任何组件或组件集合，存储器1906可以是用于存储程序和/或指令以供处理器1904执行的任何组件或组件集合。在一实施例中，存储器1906包括非瞬时性计算机可读介质。接口1910、1912、1914可以是允许处理系统1900与其它设备/组件和/或用户通信的任何组件或组件集合。例如，接口1910、1912、1914中的一个或多个可以用于将数据消息、控制消息或管理消息从处理器1904传送到安装在主机设备和/或远程设备上的应用。又例如，接口1910、1912、1914中的一个或多个可以用于支持用户或用户设备(例如，个人计算机(personal computer，PC)等)与处理系统1900进行交互/通信。处理系统1900可以包括图19中未示出的额外组件，例如长期存储器(例如，非易失性存储器等)。

在一些实施例中，处理系统1900包括在一个正在接入电信网络或其部分的网络设备中。在一个示例中，处理系统1900位于无线或有线电信网络的网络侧设备中，例如基站、中继站、调度器、控制器、网关、路由器、应用服务器或任何其它电信网络中的设备。在其它实施例中，处理系统1900位于接入无线或有线电信网络的用户侧设备中，例如移动台、用户设备(user equipment，UE)、个人计算机(personal computer，PC)、平板电脑、可穿戴通信设备(例如，智能手表等)或任何其它适于接入电信网络的设备。

在一些实施例中，接口1910、1912、1914中的一个或多个将处理系统1900连接到用于通过电信网络发送和接收信令的收发器。图20示出了用于通过电信网络发送和接收信令的收发器2000的框图。收发器2000可以安装在主机设备中。如图所示，收发器2000包括网络侧接口2002、耦合器2004、发射器2006、接收器2008、信号处理器2010和设备侧接口2012。网络侧接口2002可以包括用于通过无线或有线电信网络发送或接收信令的任何组件或组件集合。耦合器2004可以包括有助于通过网络侧接口2002进行双向通信的任何组件或组件集合。发射器2006可以包括用于将基带信号转换成适于通过网络侧接口2002发送的调制载波信号的任何组件(例如，上变频器和功率放大器等)或组件集合。接收器2008可以包括用于将通过网络侧接口2002接收的载波信号转换为基带信号的任何组件(例如，下变频器和低噪声放大器等)或组件集合。信号处理器2010可以包括用于将基带信号转换成适于通过设备侧接口2012进行通信的数据信号或者进行相反转换的任何组件或组件集合。设备侧接口2012可以包括用于在信号处理器2010与主机设备内的组件(例如，处理系统1900、局域网(local area network，LAN)端口等)之间传送数据信号的任何组件或组件集合。

收发器2000可以通过任何类型的通信介质发送和接收信令。在一些实施例中，收发器2000通过无线介质发送和接收信令。例如，收发器2000可以是用于根据无线电信协议进行通信的无线收发器，该无线电信协议可以是蜂窝协议(例如，长期演进(long-termevolution，LTE)等)、无线局域网(wireless local area network，WLAN)协议(例如，Wi-Fi等)或任何其它类型的无线协议(例如，蓝牙、近场通信(near field communication，NFC)等)。在这些实施例中，网络侧接口2002包括一个或多个天线/辐射元件。例如，网络侧接口2002可以包括单个天线、多个单独的天线或为多层通信配置的多天线阵列，其中，多层通信可以是单输入多输出(single input multiple output，SIMO)、多输入单输出(multipleinput single output，MISO)、多输入多输出(multiple input multiple output，MIMO)等。在其它实施例中，收发器2000通过双绞线电缆、同轴电缆、光纤等有线介质发送和接收信令。具体处理系统和/或收发器可利用所有示出的组件或仅使用组件的某子集，且集成程度可能随设备变化。

应当理解，本文提供的实施例方法的一个或多个步骤可以由相应的单元或模块执行。例如，可以由发送单元或发送模块发送信号。可以由接收单元或接收模块接收信号。可以由处理单元或处理模块处理信号。其它步骤可由不同单元/模块执行，包括：可由获取单元/模块来执行以获取数据和获取异常检测模块，可由确定单元/模块来执行以确定应用或进程的异常，可由分配单元/模块来执行以向应用关联的数据分配异常级别，或其它可由计算单元/模块、动作采取单元/模块、下载单元/模块、上传单元/模块、异常分类单元/模块、数据分析单元/模块、异常检测单元/模块、定制单元/模块、数据检索单元/模块、数据采集单元/模块、概率估计单元/模块、机器学习单元/模块、检测结果合并单元/模块、识别单元/模块、训练单元/模块、通知单元/模块、推送单元/模块、模型构建单元/模块、监控单元/模块、更新单元/模块和/或检测单元/模块来执行的步骤。各个单元/模块可以是硬件、软件或其组合。例如，这些单元/模块中的一个或多个可以是现场可编程门阵列(fieldprogrammable gate array，FPGA)或专用集成电路(application-specific integratedcircuit，ASIC)等集成电路。

虽然已参考说明性实施例描述了本发明，但此描述并不意图限制本发明。所属领域的技术人员在参考该描述后，将会明白说明性实施例的各种修改和组合，以及本发明其它实施例。因此，所附权利要求书意图涵盖任何此类修改或实施例。