应用程序处理方法和装置、电子设备、计算机可读存储介质与流程

本申请涉及计算机技术领域，特别是涉及一种应用程序处理方法和装置、电子设备、计算机可读存储介质。

背景技术：

智能设备可以通过应用程序实现不同的应用操作，比如可以通过购物类应用程序购买商品、通过视频类应用程序查看视频等。应用程序可以被冻结，冻结后的应用程序无法再继续运行，不会占用智能设备中处理器资源。但是由于应用程序还是存在与智能设备中的，因此还会占用智能设备中的内存、硬件等资源。

技术实现要素：

本申请实施例提供一种应用程序处理方法和装置、电子设备、计算机可读存储介质，可以提高对应用程序处理的精确度。

一种应用程序处理方法，包括：

统计电子设备中安装的各个应用程序的历史冻结次数；

获取所述历史冻结次数大于次数阈值的应用程序作为目标应用程序；

获取所述目标应用程序的历史冻结时刻，并根据所述历史冻结时刻生成预测时刻序列，所述预测时刻序列中包含一个或多个预测冻结时刻；

当所述电子设备检测到达所述预测冻结时刻时，冻结所述目标应用程序。

一种应用程序处理装置，包括：

次数统计模块，用于统计电子设备中安装的各个应用程序的历史冻结次数；

应用获取模块，用于获取所述历史冻结次数大于次数阈值的应用程序作为目标应用程序；

时刻预测模块，用于获取所述目标应用程序的历史冻结时刻，并根据所述历史冻结时刻生成预测时刻序列，所述预测时刻序列中包含一个或多个预测冻结时刻；

应用冻结模块，用于当所述电子设备检测到达所述预测冻结时刻时，冻结所述目标应用程序。

一种电子设备，包括存储器及处理器，所述存储器中储存有计算机程序，所述计算机程序被所述处理器执行时，使得所述处理器执行如下步骤：

统计电子设备中安装的各个应用程序的历史冻结次数；

获取所述历史冻结次数大于次数阈值的应用程序作为目标应用程序；

获取所述目标应用程序的历史冻结时刻，并根据所述历史冻结时刻生成预测时刻序列，所述预测时刻序列中包含一个或多个预测冻结时刻；

当所述电子设备检测到达所述预测冻结时刻时，冻结所述目标应用程序。

一种计算机可读存储介质，其上存储有计算机程序，所述计算机程序被处理器执行时实现如下步骤：

统计电子设备中安装的各个应用程序的历史冻结次数；

获取所述历史冻结次数大于次数阈值的应用程序作为目标应用程序；

获取所述目标应用程序的历史冻结时刻，并根据所述历史冻结时刻生成预测时刻序列，所述预测时刻序列中包含一个或多个预测冻结时刻；

当所述电子设备检测到达所述预测冻结时刻时，冻结所述目标应用程序。

上述应用程序处理方法和装置、电子设备、计算机可读存储介质，获取各个应用程序的历史冻结次数，将历史冻结次数大于次数阈值的应用程序作为目标应用程序。并根据目标应用程序的历史冻结时刻生成包含预测冻结时刻的预测时刻序列，在电子设备检测到达预测冻结时刻时，冻结目标应用程序。这样可以根据应用程序的历史冻结数据对应用程序的冻结时刻进行预测，并根据预测的冻结时刻控制应用程序的冻结，可以更加精确地对应用程序进行控制，减少了电子设备的功耗。

附图说明

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

图1为一个实施例中应用程序处理方法的应用环境示意图；

图2为一个实施例中电子设备的内部结构示意图；

图3为一个实施例中应用程序处理方法的流程图；

图4为另一个实施例中应用程序处理方法的流程图；

图5为一个实施例中预测时刻序列的示意图；

图6为一个实施例中应用程序的资源限制状态的示意图；

图7为一个实施例中电子设备的部分架构图；

图8为一个实施例中应用程序处理装置的结构示意图；

图9为另一个实施例中应用程序处理装置的结构示意图；

图10为与本申请实施例提供的电子设备相关的手机的部分结构的框图。

具体实施方式

为了使本申请的目的、技术方案及优点更加清楚明白，以下结合附图及实施例，对本申请进行进一步详细说明。应当理解，此处所描述的具体实施例仅仅用以解释本申请，并不用于限定本申请。

可以理解，本申请所使用的术语“第一”、“第二”等可在本文中用于描述各种元件，但这些元件不受这些术语限制。这些术语仅用于将第一个元件与另一个元件区分。举例来说，在不脱离本申请的范围的情况下，可以将第一客户端称为第二客户端，且类似地，可将第二客户端称为第一客户端。第一客户端和第二客户端两者都是客户端，但其不是同一客户端。

图1为一个实施例中应用程序处理方法的应用环境示意图。如图1所示，该应用环境包括客户端102和服务器104。客户端102上可以安装应用程序，然后在运行过程中统计各个应用程序的历史冻结次数；获取历史冻结次数大于次数阈值的应用程序作为目标应用程序；获取目标应用程序的历史冻结时刻，并根据历史冻结时刻生成预测时刻序列，预测时刻序列中包含一个或多个预测冻结时刻；当检测到达预测冻结时刻时，冻结目标应用程序。服务器104可以用于向客户端102推送应用程序处理算法，客户端102根据该应用程序处理算法对应用程序进行处理。其中，客户端102为处于计算机网络最外围，主要用于输入用户信息以及输出处理结果的电子设备，例如可以是个人电脑、移动终端、个人数字助理、可穿戴电子设备等。服务器104是用于响应服务请求，同时提供计算服务的设备，例如可以是一台或者多台计算机。可以理解的是，本申请提供的其他实施例中，应用程序处理方法的应用环境可以只包含客户端102。

如图2所示，提供了一种电子设备的内部结构示意图。该电子设备包括通过系统总线连接的处理器、存储器和显示屏。其中，该处理器用于提供计算和控制能力，支撑整个电子设备的运行。存储器用于存储数据、程序、和/或指令代码等，存储器上存储至少一个计算机程序，该计算机程序可被处理器执行，以实现本申请实施例中提供的适用于电子设备的应用程序处理方法。存储器可包括磁碟、光盘、只读存储记忆体(Read-Only Memory，ROM)等非易失性存储介质，或随机存储记忆体(Random-Access-Memory，RAM)等。例如，在一个实施例中，存储器包括非易失性存储介质及内存储器。非易失性存储介质存储有操作系统和计算机程序。该计算机程序可被处理器所执行，以用于实现本申请各个实施例所提供的一种应用程序处理方法。内存储器为非易失性存储介质中的操作系统和计算机程序提供高速缓存的运行环境。显示屏可以是触摸屏，比如为电容屏或电子屏，用于显示前台进程对应的应用的界面信息，还可以被用于检测作用于该显示屏的触摸操作，生成相应的指令，比如进行前后台应用的切换指令等。

本领域技术人员可以理解，图2中示出的结构，仅仅是与本申请方案相关的部分结构的框图，并不构成对本申请方案所应用于其上的电子设备的限定，具体的电子设备可以包括比图中所示更多或更少的部件，或者组合某些部件，或者具有不同的部件布置。如该电子设备还包括通过系统总线连接的网络接口，网络接口可以是以太网卡或无线网卡等，用于与外部的电子设备进行通信，比如可用于同服务器进行通信。

图3为一个实施例中应用程序处理方法的流程图。本实施例中的应用程序处理方法，以运行于图1中的终端或服务器上为例进行描述。如图3所示，该应用程序处理方法包括步骤302至步骤308。其中：

步骤302，统计电子设备中安装的各个应用程序的历史冻结次数。

电子设备中可安装应用程序(Application，APP)，应用程序是指电子设备中针对某种应用目的所撰写的软体，电子设备可以通过应用程序实现对用户的需求服务。例如，用户可以通过游戏类应用程序玩游戏，也可以通过视频类应用程序看视频，还可以通过音乐类应用程序播放音乐等。应用程序可以根据运行的状态分为前台应用程序和后台应用程序。前台应用程序是指在电子设备的前台运行的应用程序，前台应用程序可以在与在前台显示并与用户实现交互。后台应用程序是指在电子设备的后台运行的应用程序，后台应用程序一般不能在前台显示并与用户实现交互过程。

一般地，应用程序的应用操作是由一个或多个进程(process)来共同完成，进程是是计算机中的程序关于某数据集合上的一次运行活动，是系统进行资源分配和调度的基本单位。同时，一个进程可以对应一个或多个线程，线程是程序中一个单一的顺序控制流程，是进程内一个相对独立的、可调度的执行单元。进程可包括前台进程和后台进程，前台进程即为在电子设备前台运行的进程，后台进程即为在电子设备后台运行的进程。电子设备可以控制前台进程和后台进程的切换，前台进程可切换到后台运行，后台进程也可以切换到前台运行。具体地，可以通过进程池来实现对进程的管理，进程池中可以存放一个或多个进程对应的进程标识。进程标识用于唯一标示一个进程。进程池可以包括前台进程池和后台进程池，前台进程池中包括前台进程对应的进程标识，后台进程池中包括后台进程对应的进程标识。当检测到前台进程和后台进程的运行状态发生改变时，进程池会相应地添加或删除产生变化的进程标识。例如，进程A的进程标识为“0123”，当检测到进程A由后台进程变成前台进程时，可将该进程A的进程标识“0123”从后台进程池中移除，并添加到前台进程池中。

具体地，应用程序可以被冻结，处于冻结状态的应用程序并没有被关闭，只是暂时不运行。处于冻结状态的应用程序不占用处理器资源进行运行，但是仍然占用电子设备的内存和硬件等资源。电子设备的本地框架层中的资源优先级和限制管理模块可以对应用程序的状态进行标记，通过读取应用程序的状态标记就可以知道应用程序是否处于冻结状态。当应用程序被唤醒后，资源优先级和限制管理模块会相应地更改应用程序的状态标记，从而通过对应的状态标记来实现对应用程序冻结状态的管控。

历史冻结次数是指在当前时刻之前冻结应用程序的次数，具体是指当前时刻之前的某个时间段内冻结应用程序的次数。例如，可以是从安装应用程序的时刻到当前时刻之间冻结该应用程序的次数，也可以是指在当前时刻之前的某个时刻到当前时刻之间冻结该应用程序的次数，在本实施例中不进行限定。假设历史冻结次数是统计的7月1日到7月3日内应用程序的冻结次数，若7月1日应用程序A冻结了3次，7月2日冻结了5次，7月3日冻结了7次，那么该应用程序A的历史冻结次数就是15次。

步骤304，获取历史冻结次数大于次数阈值的应用程序作为目标应用程序。

在一个实施例中，电子设备在安装应用程序的时候，会对每一个应用程序建立对应的应用标识，应用标识用于唯一标示一个应用程序。应用标识可以但不限于是应用程序的包名(packagename)。例如，应用程序的包名可以是com.qihoo.appstore。电子设备在运行过程中，会对各个应用程序的冻结次数进行记录。可以通过冻结时间表进行记录，每个应用程序对应一张冻结时间表，并建立应用标识与冻结时间表的列表标识的对应关系。应用程序每冻结一次，会在冻结时间表中记录一次，并记录对应的冻结时刻。在获取历史冻结次数的时候，可以输入统计开始时刻和统计结束时刻，并对统计开始时刻到统计结束时刻之间的冻结的次数进行统计，得到历史冻结次数。

电子设备在获取各个应用程序对应的历史冻结次数之后，可以按历史冻结次数的多少将应用程序进行排序，然后将历史冻结次数大于次数阈值的应用程序作为目标应用程序。例如，次数阈值为3次，若应用程序A对应的历史冻结次数为2次，应用程序B对应的历史冻结次数为5次，那么应用程序B就可以作为目标应用程序。

步骤306，获取目标应用程序的历史冻结时刻，并根据历史冻结时刻生成预测时刻序列，预测时刻序列中包含一个或多个预测冻结时刻。

历史冻结次数大于次数阈值时，认为该应用程序被频繁冻结，则可以对该应用程序的历史冻结数据进行学习，分析该应用程序的冻结规律。具体地，历史冻结时刻是指历史冻结应用程序的时刻，可以是指当前时刻之前的某一个时间段内的每次冻结应用程序的时刻。例如，12月3日到12月6日冻结目标应用程序总共冻结目标应用程序4次，对应的历史冻结时刻分别为12月3日12:11、12月4日12:15、12月5日12:10和12月6日12:10。

获取到目标应用程序对应的历史冻结时刻后，就可以根据历史冻结时刻获取预测冻结时刻，预测冻结时刻就是预测得到的将目标应用程序进行冻结的时刻。例如，目标应用程序经常在凌晨00:00被冻结，那么得到的预测冻结时刻就可以是00:00。具体地，可以对获取的历史冻结时刻进行学习，获取目标应用程序的预测冻结时刻。根据预测冻结时刻生成一个预测时刻序列，目标应用程序就可以根据待预测时刻序列进行冻结。

在一个实施例中，预测时刻序列可以是针对各个目标应用程序单独建立的，即一个目标应用程序对应一个预测时刻序列。也可以是针对所有目标应用程序一起建立的，即多个目标应用程序对应一个预测时刻序列。若一个目标应用程序对应一个预测时刻序列，则可以建立目标应用标识与序列标识的对应关系，预测时刻序列中只存储对应的目标应用程序的预测冻结时刻。若多个目标应用程序对应一个预测时刻序列，则可以建立预测冻结时刻与目标应用标识的对应关系，预测时刻序列中存储着一个或多个预测冻结时刻，每个预测冻结时刻对应一个或多个目标应用标识。

步骤308，当电子设备检测到达预测冻结时刻时，冻结目标应用程序。

电子设备对生成的预测时刻序列进行实时检测，将当前时刻与预测时刻序列中的预测冻结时刻进行比较，当电子设备电测到达预测冻结时刻时，获取对应的目标应用程序，并将目标应用程序进行冻结。冻结之后的目标应用程序暂时不能运行，不占用处理器资源。可以设置对目标应用程序进行解冻的条件，例如，在检测到目标应用程序接收到通讯消息时，将目标应用程序进行解冻。或者在目标应用程序进入冻结状态的时长超过阈值时，将目标应用程序进行解冻。

上述实施例提供的应用程序处理方法，获取各个应用程序的历史冻结次数，将历史冻结次数大于次数阈值的应用程序作为目标应用程序。并根据目标应用程序的历史冻结时刻生成包含预测冻结时刻的预测时刻序列，在电子设备检测到达预测冻结时刻时，冻结目标应用程序。这样可以根据应用程序的历史冻结数据对应用程序的冻结时刻进行预测，并根据预测的冻结时刻控制应用程序的冻结，可以更加精确地对应用程序进行控制，减少了电子设备的功耗。

图4为另一个实施例中应用程序处理方法的流程图。本实施例中的应用程序处理方法，以运行于图1中的终端或服务器上为例进行描述。如图4所示，该应用程序处理方法包括步骤402至步骤420。其中：

步骤402，获取各个应用程序的应用优先级，根据应用优先级获取对应的次数阈值。

应用优先级可以表示应用程序的重要程度，用户或系统可以通过一定的标准对应用优先级进行设置。电子设备可以建立应用标识和应用优先级的对应关系，根据应用标识就可以获取应用程序对应的应用优先级。例如，可以将系统级应用程序设置为较高的应用优先级，第三方应用程序设置为较低的应用优先级。或者可以根据应用程序的类型来对应用程序的应用优先级进行设置，即时通讯类的应用程序设置为较高的应用优先级，工具类的应用程序设置为较低的应用优先级。电子设备预先构建应用优先级与次数阈值的对应关系，然后获取各个应用程序的应用优先级，根据预先构建的对应关系获取应用优先级对应的次数阈值。

步骤404，统计电子设备中安装的各个应用程序的历史冻结次数。

步骤406，获取历史冻结次数大于次数阈值的应用程序作为目标应用程序。

在一个实施例中，电子设备在每到预设时刻的时候统计一次历史冻结次数，并根据历史冻结次数获取目标应用程序。具体地，电子设备中可以设置定时器，每当到达定时时刻时，电子设备统计安装的各个应用程序在统计时段内的历史冻结次数，并获取历史冻结次数大于次数阈值的应用程序，作为目标应用程序。例如，电子设备可以在每个月1号00:00的时候，统计各个应用程序在上一个月内的历史冻结次数，并根据统计的历史冻结次数获取目标应用程序。

步骤408，获取统计时段内各个目标应用程序每次冻结时所对应的历史冻结时刻，根据历史冻结时刻获取各个目标应用程序对应的预测冻结时刻。

统计时段是指用于统计历史冻结时刻的时间段，具体是指当前时刻之前的某个时间段。例如，当前时刻为2017年12月12日00:00，则统计时段可以是2017年11月1日00:00到2017年11月30日23:59的时间段，就可以获取该统计时段内的历史冻结时刻。可以理解的是，统计时段可以是当前时刻之前的任意一个时间段，在本实施例中不做限定。获取到历史冻结时刻之后，可以通过预设的时刻预测模型对历史冻结时刻进行学习，获取各个目标应用程序对应的预测冻结时刻。

步骤410，根据得到的预测冻结时刻和目标应用程序的目标应用标识生成预测时刻序列。

在一个实施例中，根据各个目标应用程序获取到预测冻结时刻之后，可以根据多个目标应用程序的预测冻结时刻生成预测时刻序列，则生成的预测时刻序列中会建立预测时刻序列与目标应用标识的对应关系。图5为一个实施例中预测时刻序列的示意图。如图5所示，该预测时刻序列是根据多个目标应用程序的预测冻结时刻和目标应用标识生成的，预测时刻序列中按照时间先后顺序将预测冻结时刻进行排列，每个预测冻结时刻对应一个或多个预测冻结时刻。如图5中所示的预测冻结时刻包括“2月2日9:00”→“2月2日10:30”→“2月2日11:00”→“2月2日13:00”→“2月2日20:00”→…...，每个预测冻结时刻对应一个或多个目标应用标识。当电子设备检测到达该预测冻结时刻时，可以获取预测冻结时刻对应的目标应用标识，并将目标应用标识对应的目标应用程序进行冻结。

可以理解的是，在生成预测时刻序列之前还可以将目标应用程序进行分类，并针对每一类目标应用程序建立对应的预测时刻序列。则步骤410具体可以包括：将目标应用程序进行分类，根据每一类目标应用程序对应的预测冻结时刻和目标应用标识生成预测时刻序列。例如，可以将目标应用程序分为游戏类应用程序、购物类应用程序、即时通讯类应用程序等，生成预测时刻序列之后，可以将预测时刻序列进行分类管理。

步骤412，当电子设备检测到达预测冻结时刻时，判断目标应用程序的运行状态。

建立预测时刻序列之后，可以根据预测时刻序列进行实时监控。当到达预测时刻序列中的预测冻结时刻时，可以获取预测冻结时刻对应的目标应用标识，然后获取目标应用标识对应的目标应用程序。运行状态可以包括前台运行和后台运行，前台运行的应用程序被认为是比较重要的应用程序，后台运行的应用程序被认为是重要性较低的应用程序。到达预测冻结时刻时，可以先获取目标应用程序的运行状态，根据目标应用程序的运行状态来对目标应用程序进行冻结处理。

步骤414，若检测到目标应用程序处于后台运行，则冻结目标应用程序。

当到达预测冻结时刻时，获取目标应用程序的运行状态。若检测到目标应用程序处于后台运行，则冻结目标应用程序。若检测到目标应用程序处于前台运行，则可以获取该目标应用程序从前台切换到后台的切换时刻，若上一预测冻结时刻与切换时刻之间的切换时长小于切换时长阈值，则冻结目标应用程序。例如，上一预测冻结时刻为9:12，切换时长阈值为3分钟。若在9:12时，目标应用程序为前台运行，那么该目标应用程序不会进行冻结。若目标应用程序在9:14的时候，切换到后台运行，那么该目标应用程序的切换时长就为2分钟，由于切换时长小于切换时长阈值，则可以将该目标应用程序进行冻结处理。

若目标应用程序处于后台运行，还可以判断目标应用程序是否依赖于前台应用程序。根据目标应用程序与前台应用程序的依赖关系来对目标应用进行冻结处理。具体地，若检测到目标应用程序处于后台运行，则检测目标应用程序是否依赖于前台应用程序；若否，则冻结目标应用程序。依赖表示一个应用程序需要利用于另一个或多个应用程序的数据才能顺利实现对该一个应用程序的执行的关系。存在依赖关系的两个应用程序，分别为被依赖的应用程序和依赖的应用程序。举例来说，应用程序A依赖于应用程序B，或应用程序B被应用程序A依赖，即表示应用程序A需要利用应用程序B的数据才能实现对该应用程序A的执行，此时，应用程序A即为依赖于应用程序B的应用程序，应用程序B即为被应用程序A依赖的应用程序。具体地，在本申请实施例中，依赖应用程序就是指被前台应用程序依赖的后台应用程序。

应用程序之间的依赖关系并非一直不变的，而是实时变化的。电子设备可将应用程序之间的依赖关系进行记录。具体地，两个应用程序之间的相互依赖是建立在它们需要互相通信的基础之上的。因此，检测目标应用程序是否依赖于前台应用程序包括：检测目标应用程序与前台应用程序之间是否存在通信关系。若是，则说明目标应用程序依赖于前台应用程序；若否，则说明目标应用程序不依赖于前台应用程序。

在操作系统中，是通过定义通信机制来建立应用程序之间的通信关系的。其中，通信机制包括Socket、Binder、共享内存等。Binder通信是Android系统中实现的一种高效的IPC(Inter-Process Communication，应用程序间通信)机制，是一种client-server(客户端-服务器)的通信结构。客户端与服务器会定义一个对应的代理接口，客户端调用代理接口中的方法时，代理接口的方法会将客户端的参数打包成一个Parcel对象，然后代理接口将Parcel对象发送给内核层中的Binder驱动。服务器可以读取Binder驱动中的请求数据，然后将Parcel对象进行解析并处理，并将处理结果返回。Socket通信可以对两个网络应用程序进行通信连接，从而实现网络上的应用程序的数据交换。具体地，本地应用程序间通信可以通过PID(Process Identity，应用程序标识)来唯一标识一个应用程序，但是在网络应用程序间通信是没有办法实现的。而在网络通信中IP(Internet Protocol，网络之间互连的协议)地址可以唯一标识网络中的主机，“协议+端口”可以唯一标识主机中的应用程序，因此在Socket通信中通常是通过“IP地址+协议+端口”的形式来唯一标识一个应用程序的。共享内存就是允许两个不相关的应用程序访问同一个逻辑内存，共享内存是在两个正在运行的应用程序之间共享和传递数据的一种非常有效的方式，不同应用程序之间共享的内存通常安排为同一段物理内存。

可选地，检测目标应用程序是否依赖于前台应用程序包括以下方式中至少一种：检测目标应用程序与前台应用程序之间是否存在socket通信关系；检测目标应用程序与前台应用程序之间是否存在binder通信关系；检测目标应用程序与前台应用程序之间是否进行内存共享。

在本申请提供的其他实施例中，若检测到目标应用程序处于后台运行，则获取目标应用程序的后台运行时长；若后台运行时长超过第一时长阈值，则冻结目标应用程序。后台运行时长具体可以表示上一次从前台切换到后台的时刻到当前时刻之间的时长，根据目标应用程序的后台运行时长来进行冻结处理。例如，第一时长阈值可以为1分钟，若目标应用程序的后台运行时长为2分钟，则可以将该目标应用程序进行冻结。

步骤416，获取目标应用程序的历史冻结时长，并根据历史冻结时长获取预测冻结时长。

历史冻结时长是指目标应用程序每次冻结时的冻结时长，即每次从冻结时刻到解冻时刻之间所间隔的时长。电子设备在每次冻结应用程序时，会通过冻结时间表记录应用程序的冻结时刻和解冻时刻，并计算每次冻结时的冻结时刻到解冻时刻的时间间隔，作为冻结时长。例如，应用程序在07:11被冻结，07:31被解冻。那么该应用程序的冻结时刻就为07:11，解冻个时刻就为07:31，计算得到的冻结时长就为20分钟。

获取历史冻结时长具体可以是获取统计时段内的历史冻结时长，在获取到历史冻结时长之后，可以根据历史冻结时长获取预测冻结时长。具体地，可以根据历史冻结时长获取时长平均值，并将获取的时长平均值作为预测冻结时长。也可以是根据大于冻结时长阈值的历史冻结时长获取时长平均值，然后将获取的时长平均值作为预测冻结时长。还可以根据时长预测模型会历史冻结时长进行学习，得到预测冻结时长。在本实施例中，获取预测冻结时长的方法不进行具体限定。

步骤418，从目标应用程序进入冻结状态的时刻开始计时。

从目标应用程序进入冻结状态的时刻，电子设备可以启动计时器开始计时。电子设备可以针对每一个目标应用程序建立一个对应的计时器，每个目标应用程序进入冻结状态时，都可以根据对应的计时器进行计时。预先建立目标应用程序的目标应用标识与计时器的计时标识的对应关系，通过目标应用标识对应的计时标识查找并启动计时器开始计时。以Android系统为例，系统可以预先定义一个计时器，当检测到目标应用程序被冻结时，目标应用标识查找对应的计时器，并通过timer.setBase(SystemClock.elapsedRealtime())函数将计时器清零，然后通过timer.start()函数启动计时器，开始计时。

步骤420，当计时时长超过第二时长阈值，则将目标应用程序进行解冻。

在一个实施例中，当计时时长超过第二时长阈值时，说明目标应用程序被冻结的时长超过第二时长阈值，则可以将目标应用程序进行解冻。以Android系统中，实现应用程序的冻结和解冻的方法有多种。以其中一种为例，可以通过pm(package manager，包管理)命令来实现，在pm命令中，可以通过冻结命令pm disable[–user USER_ID]PACKAGE_OR_COMPONENT将应用程序设置为冻结状态，然后还可以通过解冻命令pm enable[–user USER_ID]PACKAGE_OR_COMPONENT将处于冻结状态的应用程序进行唤醒，通过冻结列表查询命令pm list packages–d获取处于冻结状态的应用程序列表，以查看处于冻结状态的应用程序。可以理解的是，本申请中以Android操作系统为例对应用程序处理方法进行说明，但是本申请的应用程序处理方法并不仅限于在Android系统中实现，还可以应用在IOS、塞班、Windows、MAC OS(Macintosh Operating System)等操作系统中。

当目标应用程序被解冻之后，可以控制目标应用程序进入资源限制状态。其中，处于资源限制状态的应用程序在运行时对电子设备的资源占用率小于占用率阈值。资源是指电子设备在处理应用事件时所必须用到的软件或硬件资源，比如电子设备的CPU(Central Processing Unit，中央处理器)、内存(Memory)、硬件、网络资源、IO(Input-Output，输入输出)等。当目标应用程序处于资源限制状态时，目标应用程序对电子设备的资源占用率就不能超过占用率阈值，这样可以控制目标应用程序的运行效率，降低电子设备的功耗。例如，控制目标应用程序在运行时的CPU占用率不能超过5％，以减少目标应用程序对CPU的过度消耗，降低用户对手机的依赖。在手机系统中可以通过cgroups(control groups，控制组)来控制目标应用程序的CPU、内存、IO等资源占用率，即控制所获取的目标应用程序进入资源限制状态。

具体地，还可以获取电子设备的资源总占用率，根据电子设备的资源总占用率来控制目标应用程序进入资源限制状态。其中，资源总占用率是指电子设备中被占用的资源和总资源的比例。当目标应用程序被解冻之后，获取电子设备的资源总占用率，并根据资源总占用率来控制目标应用程序进入资源限制状态。具体地，可以预先建立资源总占用率和资源限制级别的对应关系，处于资源限制状态时目标应用程序对电子设备的资源占用率不能超过占用率阈值。处于不同的资源限制级别时，目标应用程序对应的占用率阈值不同。获取电子设备的资源总占用率，并根据资源总占用率获取资源限制级别；控制目标应用程序进入资源限制级别对应的资源限制状态。例如，将电子设备的资源总占用率划分为50％～60％、60％～80％、80％～100％等三个占用级别，然后分别对应轻度资源限制级别、普通资源限制级别和深度资源限制级别等三个等级，根据资源总占用率可以获取对应的资源限制级别，不同的资源限制级别对应的占用率阈值不同。可以理解的是，不同资源对应的占用率阈值还可以不同。比如，CPU占用率阈值可以为5％，内存占用率阈值可以为10％。

在其他实施例中，还可以根据目标应用程序的应用优先级来控制对资源的占用情况，预先建立应用优先级与资源限制级别的对应关系，然后根据目标应用程序的应用优先级来控制进入资源限制状态的资源限制级别。具体可以包括：当目标应用程序被解冻之后，获取目标应用程序对应的应用优先级；根据应用优先级获取对应的资源限制级别；控制目标应用程序进入资源限制级别对应的资源限制状态。

图6为一个实施例中应用程序的资源限制状态的示意图。如图6所示，电子设备的资源包括CPU、内存、IO、网络资源等，应用程序的状态可以分为正常运行状态、资源限制状态和冻结状态。其中，资源限制状态又可以分为轻度资源限制状态、普通资源限制状态和深度资源限制状态。在不同资源限制状态下，对应的可用资源602和不可用资源604不相同。从轻度资源限制状态、普通资源限制状态到深度资源限制状态，可用资源602递减。在正常运行状态下，应用程序的可用资源602为100％。

上述实施例提供的应用程序处理方法，获取各个应用程序的历史冻结次数，将历史冻结次数大于次数阈值的应用程序作为目标应用程序。并根据目标应用程序的历史冻结时刻生成包含预测冻结时刻的预测时刻序列，在电子设备检测到达预测冻结时刻时，根据目标应用程序的运行状态冻结目标应用程序。然后获取目标应用程序的历史冻结时长，并根据历史冻结时长获取预测冻结时长，在目标应用程序被冻结的时长超过预测冻结时长时，将目标应用程序进行解冻。这样可以根据应用程序的历史冻结数据对应用程序的冻结时刻进行预测，根据历史冻结时长获取预测冻结时长，并根据预测的冻结时刻和预测冻结时长控制应用程序的冻结和解冻，可以更加精确地对应用程序进行控制，同时减少了电子设备的功耗。

应该理解的是，虽然图3和图4的流程图中的各个步骤按照箭头的指示依次显示，但是这些步骤并不是必然按照箭头指示的顺序依次执行。除非本文中有明确的说明，这些步骤的执行并没有严格的顺序限制，这些步骤可以以其它的顺序执行。而且，图3和图4中的至少一部分步骤可以包括多个子步骤或者多个阶段，这些子步骤或者阶段并不必然是在同一时刻执行完成，而是可以在不同的时刻执行，这些子步骤或者阶段的执行顺序也不必然是依次进行，而是可以与其它步骤或者其它步骤的子步骤或者阶段的至少一部分轮流或者交替地执行。

在一个实施例中应用程序处理方法还可以包括：

(1)获取各个应用程序的应用优先级，根据应用优先级获取对应的次数阈值；

(2)统计电子设备中安装的各个应用程序的历史冻结次数；

(3)获取历史冻结次数大于次数阈值的应用程序作为目标应用程序；

(4)获取统计时段内各个目标应用程序每次冻结时所对应的历史冻结时刻，根据历史冻结时刻获取各个目标应用程序对应的预测冻结时刻；

(5)根据得到的预测冻结时刻和目标应用程序的目标应用标识生成预测时刻序列；

(6)当电子设备检测到达预测冻结时刻时，判断目标应用程序的运行状态；

(7)若检测到所述目标应用程序处于后台运行，则检测所述目标应用程序是否依赖于前台应用程序；

(8)若否，则获取所述目标应用程序的后台运行时长；

(9)若所述后台运行时长超过第一时长阈值，则冻结所述目标应用程序；

(10)获取目标应用程序的历史冻结时长，并根据历史冻结时长获取预测冻结时长；

(11)从目标应用程序进入冻结状态的时刻开始计时；

(12)当计时时长超过第二时长阈值，则将目标应用程序进行解冻。

在一个实施例中，如图7所示，提供了一种电子设备的部分架构图。其中，该电子设备的架构系统中包括JAVA空间层71、本地框架层72以及内核(Kernel)空间层73。JAVA空间层71上可包含策略应用程序710，电子设备可通过该策略应用程序710来发起对各个应用程序的冻结和解冻策略，从而实现对电子设备中的各个应用程序实现冻结和解冻的操作。例如，通过策略应用程序710来判断后台耗电的应用程序，并发起对该后台耗电的应用程序做冻结操作。本地框架层72中包含资源优先级和限制管理模块720及平台冻结管理模块722。电子设备可通过资源优先级和限制管理模块720来实时维护应用程序的优先级和对应的资源组，根据上层的需求来调整应用程序的优先级和资源组，从而达到优化性能，节省功耗的作用。电子设备可通过平台冻结管理模块722将后台可以冻结的任务按照进入冻结时间的长短，分配到对应预设的不同层次的冻结层，可选地，该冻结层可包括：CPU限制睡眠模式、CPU冻结睡眠模式、进程深度冻结模式。内核空间层73中包括UID管理模块730、Cgroup模块732、超时冻结退出模块734、Binder管控模块736、进程内存回收模块738。其中，UID管理模块730可以基于应用程序的用户身份标识(User Identifier，UID)来管理第三方应用程序的资源或进行冻结。相比较于基于进程身份标识(Process Identifier，PID)来进行进程管控，通过UID更便于统一管理一个用户的应用的资源。Cgroup模块732用于提供一套完善的中央处理器(Central Processing Unit，CPU)、CPUSET、内存(memory)、输入/输出(input/output，I/O)和Net相关的资源限制机制。超时冻结退出模块734用于解决出现冻结超时场景产生的异常。Binder管控模块736用于实现后台binder通信的优先级的控制。进程内存回收模块738用于实现进程的深度冻结模式，当第三方应用程序长期处于冻结状态的时候，可以释放进程的文件区，从而达到节省内存的模块，也加快该应用程序在下次启动时的速度。通过上述的架构，可实现本申请各个实施例中的应用程序处理方法。

图8为一个实施例中应用程序处理装置的结构示意图。如图8所示，该应用程序处理装置800包括次数统计模块802、应用获取模块804、时刻预测模块806和应用冻结模块808。其中：

次数统计模块802，用于统计电子设备中安装的各个应用程序的历史冻结次数。

应用获取模块804，用于获取所述历史冻结次数大于次数阈值的应用程序作为目标应用程序。

时刻预测模块806，用于获取所述目标应用程序的历史冻结时刻，并根据所述历史冻结时刻生成预测时刻序列，所述预测时刻序列中包含一个或多个预测冻结时刻。

应用冻结模块808，用于当所述电子设备检测到达所述预测冻结时刻时，冻结所述目标应用程序。

上述实施例提供的应用程序处理装置，获取各个应用程序的历史冻结次数，将历史冻结次数大于次数阈值的应用程序作为目标应用程序。并根据目标应用程序的历史冻结时刻生成包含预测冻结时刻的预测时刻序列，在电子设备检测到达预测冻结时刻时，冻结目标应用程序。这样可以根据应用程序的历史冻结数据对应用程序的冻结时刻进行预测，并根据预测的冻结时刻控制应用程序的冻结，可以更加精确地对应用程序进行控制，减少了电子设备的功耗。

图9为另一个实施例中应用程序处理装置的结构示意图。如图9所示，该应用程序处理装置900包括次数统计模块802、应用获取模块804、时刻预测模块806和应用冻结模块808。其中：

阈值获取模块902，用于获取各个应用程序的应用优先级，根据所述应用优先级获取对应的次数阈值。

次数统计模块904，用于统计电子设备中安装的各个应用程序的历史冻结次数。

应用获取模块906，用于获取所述历史冻结次数大于次数阈值的应用程序作为目标应用程序。

时刻预测模块908，用于获取所述目标应用程序的历史冻结时刻，并根据所述历史冻结时刻生成预测时刻序列，所述预测时刻序列中包含一个或多个预测冻结时刻。

应用冻结模块910，用于当所述电子设备检测到达所述预测冻结时刻时，冻结所述目标应用程序。

应用解冻模块912，用于获取所述目标应用程序的历史冻结时长，并根据所述历史冻结时长获取预测冻结时长；从所述目标应用程序进入冻结状态的时刻开始计时；当计时时长超过第二时长阈值，则将所述目标应用程序进行解冻。

上述实施例提供的应用程序处理装置，获取各个应用程序的历史冻结次数，将历史冻结次数大于次数阈值的应用程序作为目标应用程序。并根据目标应用程序的历史冻结时刻生成包含预测冻结时刻的预测时刻序列，在电子设备检测到达预测冻结时刻时，根据目标应用程序的运行状态冻结目标应用程序。然后获取目标应用程序的历史冻结时长，并根据历史冻结时长获取预测冻结时长，在目标应用程序被冻结的时长超过预测冻结时长时，将目标应用程序进行解冻。这样可以根据应用程序的历史冻结数据对应用程序的冻结时刻进行预测，根据历史冻结时长获取预测冻结时长，并根据预测的冻结时刻和预测冻结时长控制应用程序的冻结和解冻，可以更加精确地对应用程序进行控制，同时减少了电子设备的功耗。

在一个实施例中，时刻预测模块908还用于获取统计时段内各个目标应用程序每次冻结时所对应的历史冻结时刻，根据所述历史冻结时刻获取各个目标应用程序对应的预测冻结时刻；根据得到的所述预测冻结时刻和所述目标应用程序的目标应用标识生成预测时刻序列。

在一个实施例中，应用冻结模块910还用于当所述电子设备检测到达所述预测冻结时刻时，判断所述目标应用程序的运行状态；若检测到所述目标应用程序处于后台运行，则冻结所述目标应用程序。

在一个实施例中，应用冻结模块910还用于若检测到所述目标应用程序处于后台运行，则检测所述目标应用程序是否依赖于前台应用程序；若否，则冻结所述目标应用程序。

在一个实施例中，应用冻结模块910还用于若检测到所述目标应用程序处于后台运行，则获取所述目标应用程序的后台运行时长；若所述后台运行时长超过第一时长阈值，则冻结所述目标应用程序。

上述应用程序处理装置中各个模块的划分仅用于举例说明，在其他实施例中，可将应用程序处理装置按照需要划分为不同的模块，以完成上述应用程序处理装置的全部或部分功能。

本申请实施例中提供的应用程序处理装置中的各个模块的实现可为计算机程序的形式。该计算机程序可在终端或服务器上运行。该计算机程序构成的程序模块可存储在终端或服务器的存储器上。该计算机程序被处理器执行时，实现本申请实施例中所描述方法的步骤。

本申请实施例还提供了一种计算机可读存储介质。一个或多个包含计算机可执行指令的非易失性计算机可读存储介质，当所述计算机可执行指令被一个或多个处理器执行时，使得所述处理器执行上述实施例提供的应用程序处理方法。

一种包含指令的计算机程序产品，当其在计算机上运行时，使得计算机执行上述实施例提供的应用程序处理方法。

本申请实施例还提供了一种电子设备。如图10所示，为了便于说明，仅示出了与本申请实施例相关的部分，具体技术细节未揭示的，请参照本申请实施例方法部分。该电子设备可以为包括手机、平板电脑、PDA(Personal Digital Assistant，个人数字助理)、POS(Point of Sales，销售终端)、车载电脑、穿戴式设备等任意终端设备，以电子设备为手机为例：

图10为与本申请实施例提供的电子设备相关的手机的部分结构的框图。参考图10，手机包括：射频(Radio Frequency，RF)电路1010、存储器1020、输入单元1030、显示单元1040、传感器1050、音频电路1060、无线保真(wireless fidelity，WiFi)模块1070、处理器1080、以及电源1090等部件。本领域技术人员可以理解，图10所示的手机结构并不构成对手机的限定，可以包括比图示更多或更少的部件，或者组合某些部件，或者不同的部件布置。

其中，RF电路1010可用于收发信息或通话过程中，信号的接收和发送，可将基站的下行信息接收后，给处理器1080处理；也可以将上行的数据发送给基站。通常，RF电路包括但不限于天线、至少一个放大器、收发信机、耦合器、低噪声放大器(Low Noise Amplifier，LNA)、双工器等。此外，RF电路1010还可以通过无线通信与网络和其他设备通信。上述无线通信可以使用任一通信标准或协议，包括但不限于全球移动通讯系统(Global System of Mobile communication，GSM)、通用分组无线服务(General Packet Radio Service，GPRS)、码分多址(Code Division Multiple Access，CDMA)、宽带码分多址(Wideband Code Division Multiple Access，WCDMA)、长期演进(Long Term Evolution，LTE))、电子邮件、短消息服务(Short Messaging Service，SMS)等。

存储器1020可用于存储软件程序以及模块，处理器1080通过运行存储在存储器1020的软件程序以及模块，从而执行手机的各种功能应用以及数据处理。存储器1020可主要包括程序存储区和数据存储区，其中，程序存储区可存储操作系统、至少一个功能所需的应用程序(比如声音播放功能的应用程序、图像播放功能的应用程序等)等；数据存储区可存储根据手机的使用所创建的数据(比如音频数据、通讯录等)等。此外，存储器1020可以包括高速随机存取存储器，还可以包括非易失性存储器，例如至少一个磁盘存储器件、闪存器件、或其他易失性固态存储器件。

输入单元1030可用于接收输入的数字或字符信息，以及产生与手机1000的用户设置以及功能控制有关的键信号输入。具体地，输入单元1030可包括触控面板1031以及其他输入设备1032。触控面板1031，也可称为触摸屏，可收集用户在其上或附近的触摸操作(比如用户使用手指、触笔等任何适合的物体或附件在触控面板1031上或在触控面板1031附近的操作)，并根据预先设定的程式驱动相应的连接装置。在一个实施例中，触控面板1031可包括触摸检测装置和触摸控制器两个部分。其中，触摸检测装置检测用户的触摸方位，并检测触摸操作带来的信号，将信号传送给触摸控制器；触摸控制器从触摸检测装置上接收触摸信息，并将它转换成触点坐标，再送给处理器1080，并能接收处理器1080发来的命令并加以执行。此外，可以采用电阻式、电容式、红外线以及表面声波等多种类型实现触控面板1031。除了触控面板1031，输入单元1030还可以包括其他输入设备1032。具体地，其他输入设备1032可以包括但不限于物理键盘、功能键(比如音量控制按键、开关按键等)等中的一种或多种。

显示单元1040可用于显示由用户输入的信息或提供给用户的信息以及手机的各种菜单。显示单元1040可包括显示面板1041。在一个实施例中，可以采用液晶显示器(Liquid Crystal Display，LCD)、有机发光二极管(Organic Light-Emitting Diode,OLED)等形式来配置显示面板1041。在一个实施例中，触控面板1031可覆盖显示面板1041，当触控面板1031检测到在其上或附近的触摸操作后，传送给处理器1080以确定触摸事件的类型，随后处理器1080根据触摸事件的类型在显示面板1041上提供相应的视觉输出。虽然在图10中，触控面板1031与显示面板1041是作为两个独立的部件来实现手机的输入和输入功能，但是在某些实施例中，可以将触控面板1031与显示面板1041集成而实现手机的输入和输出功能。

手机1000还可包括至少一种传感器1050，比如光传感器、运动传感器以及其他传感器。具体地，光传感器可包括环境光传感器及接近传感器，其中，环境光传感器可根据环境光线的明暗来调节显示面板1041的亮度，接近传感器可在手机移动到耳边时，关闭显示面板1041和/或背光。运动传感器可包括加速度传感器，通过加速度传感器可检测各个方向上加速度的大小，静止时可检测出重力的大小及方向，可用于识别手机姿态的应用(比如横竖屏切换)、振动识别相关功能(比如计步器、敲击)等；此外，手机还可配置陀螺仪、气压计、湿度计、温度计、红外线传感器等其他传感器等。

音频电路1060、扬声器1061和传声器1062可提供用户与手机之间的音频接口。音频电路1060可将接收到的音频数据转换后的电信号，传输到扬声器1061，由扬声器1061转换为声音信号输出；另一方面，传声器1062将收集的声音信号转换为电信号，由音频电路1060接收后转换为音频数据，再将音频数据输出处理器1080处理后，经RF电路1010可以发送给另一手机，或者将音频数据输出至存储器1020以便后续处理。

WiFi属于短距离无线传输技术，手机通过WiFi模块1070可以帮助用户收发电子邮件、浏览网页和访问流式媒体等，它为用户提供了无线的宽带互联网访问。虽然图10示出了WiFi模块1070，但是可以理解的是，其并不属于手机1000的必须构成，可以根据需要而省略。

处理器1080是手机的控制中心，利用各种接口和线路连接整个手机的各个部分，通过运行或执行存储在存储器1020内的软件程序和/或模块，以及调用存储在存储器1020内的数据，执行手机的各种功能和处理数据，从而对手机进行整体监控。在一个实施例中，处理器1080可包括一个或多个处理单元。在一个实施例中，处理器1080可集成应用处理器和调制解调处理器，其中，应用处理器主要处理操作系统、用户界面和应用程序等；调制解调处理器主要处理无线通信。可以理解的是，上述调制解调处理器也可以不集成到处理器1080中。

手机1000还包括给各个部件供电的电源1090(比如电池)，优选的，电源可以通过电源管理系统与处理器1080逻辑相连，从而通过电源管理系统实现管理充电、放电、以及功耗管理等功能。

在一个实施例中，手机1000还可以包括摄像头、蓝牙模块等。

在本申请实施例中，该电子设备所包括的处理器1080执行存储在存储器上的计算机程序时实现上述实施例提供的应用程序处理方法的步骤。

本申请所使用的对存储器、存储、数据库或其它介质的任何引用可包括非易失性和/或易失性存储器。非易失性存储器可包括只读存储器(ROM)、可编程ROM(PROM)、电可编程ROM(EPROM)、电可擦除可编程ROM(EEPROM)或闪存。易失性存储器可包括随机存取存储器(RAM)，它用作外部高速缓冲存储器。作为说明而非局限，RAM以多种形式可得，诸如静态RAM(SRAM)、动态RAM(DRAM)、同步DRAM(SDRAM)、双数据率SDRAM(DDR SDRAM)、增强型SDRAM(ESDRAM)、同步链路(Synchlink)DRAM(SLDRAM)、存储器总线(Rambus)直接RAM(RDRAM)、直接存储器总线动态RAM(DRDRAM)、以及存储器总线动态RAM(RDRAM)。

以上所述实施例仅表达了本申请的几种实施方式，其描述较为具体和详细，但并不能因此而理解为对本申请专利范围的限制。应当指出的是，对于本领域的普通技术人员来说，在不脱离本申请构思的前提下，还可以做出若干变形和改进，这些都属于本申请的保护范围。因此，本申请专利的保护范围应以所附权利要求为准。