终端及其应用杀死处理方法与流程

本发明涉及终端领域，更具体地说，涉及一种终端及其应用杀死处理方法。

背景技术：

随着科学技术的日益发展，各种移动终端(例如手机、ipad、阅读器等)已经成为用户使用热度最高的电子设备，对移动终端各项功能的用户体验要求越来越高，移动终端承载的各种功能和各类应用也越来越多，应用种类和数量的增多，随之而来的对系统反应速度、流畅度、功耗、内存等的负面影响也越来越严重，针对性的应用管理功能一经推出就得到终端用户的广泛关注和使用。针对用户广为投诉的系统卡顿、使用一段时间后手机内存变小、使用一段时候后系统慢的问题、第三方杀不死、频繁自启，占用手机内存等问题，目前的做法是针对所有应用设置一个内存占用阈值，然后对运行的应用进行监测，对于凡是占用内存大于设定阈值的应用就直接杀死。这会导致一些不能被杀死的应用被硬性杀死进而导致系统崩溃，也即会出现错杀情况；也会导致一些用户不希望被杀死的应用被硬性杀死从而中断用户当前的使用，也即出现误杀情况，导致用户体验的满意度进一步降低。因此，如何对终端内的应用进行更准确、合理的管理是目前亟需解决的问题。

技术实现要素：

本发明要解决的技术问题在于，现有对终端的应用进行杀死处理是存在错杀、误杀的情况，针对该技术问题，提供一种终端及其应用杀死处理方法。

为解决上述技术问题，本发明提供一种终端，包括：

名单管理模块，用于管理应用名单，所述应用名单中包含待管理应用名单和保留应用名单，所述待管理应用名单中包含需杀死处理的各应用之识别信息，所述保留应用名单中包含无需杀死处理的各应用之识别信息；

识别信息获取模块，用于在系统启动后，获取当前处于运行状态的各应用之识别信息；

匹配模块，用于将所述各应用的识别信息与所述应用名单进行匹配；

状态信息获取模块，用于根据匹配结果获取识别信息在所述待管理应用名单中的各目标应用当前的运行状态信息；

判断模块，用于根据所述各目标应用的运行状态信息分别判断各目标应用是否满足杀死条件；

处理模块，用于对满足杀死条件的目标应用，调用该目标应用对应的杀死策略对其进行杀死处理。

其中，所述待管理应用名单包括：特殊名单、灰名单以及普通名单；

所述特殊名单中包含伴随系统运行而运行的各应用的识别信息；

所述灰名单中包含杀死后允许重启的各应用的识别信息；

所述普通名单中包含所述系统中，除所述特殊名单、灰名单以及保留应用名单中的各应用之外的其他各应用的识别信息；

所述状态信息获取模块用于对识别信息在所述特殊名单中的目标应用，获取该目标应用当前占用的内存，对识别信息在所述普通名单和所述灰名单中的目标应用，当该目标应用为第三方应用时，获取该目标应用当前占用的内存，当该目标应用为预置应用时，获取该目标应用的系统资源使用权限标记值，并在获取的系统资源使用权限标记值小于预设标记阈值时，获取该目标应用当前占用的内存以及运行标识。

其中，所述判断模块用于对识别信息在所述特殊名单中的目标应用，判断该目标应用当前占用内存是否大于等于该目标应用对应的第一内存占用阈值，如是，判断满足杀死条件；

以及用于对识别信息在所述灰名单的目标应用，当该目标应用为第三方应用时，判断该目标应用当前占用内存是否大于等于该目标应用对应的第二内存占用阈值，如是，判断满足杀死条件；当该目标应用为预置应用时，判断该目标系统资源使用权限标记值是否大于等于所述预设标记阈值，如是，判断满足杀死条件，否则，判断该目标应用当前占用的内存是否大于等于第三内存占用阈值且其运行标识是否为假，如是，判断满足杀死条件；

以及用于对识别信息在所述普通名单的目标应用，当该目标应用为第三方应用时，判断该目标应用当前占用内存是否大于等于该目标应用对应的第四内存占用阈值，如是，判断满足杀死条件；当该目标应用为预置应用时，判断该目标系统资源使用权限标记值是否大于等于所述预设标记阈值，如是，判断满足杀死条件，否则，判断该目标应用当前占用的内存是否大于等于第五内存占用阈值且其运行标识是否为假，如是，判断满足杀死条件。

其中，所述处理模块用于对识别信息在所述特殊名单中且满足杀死条件的目标应用，保留该目标应用的服务业务，释放该目标应用的其他资源；

以及用于对识别信息在所述灰名单中且满足杀死条件的目标应用，释放该目标应用的所有资源，并允许所述目标应用的服务业务被正常唤醒；

以及用于对识别信息在所述普通名单中且满足杀死条件的目标应用，释放该目标应用的所有资源，并禁止所述目标应用的服务业务被正常唤醒。

其中，还包括内存监测模块，用于对系统内存进行监测，并在监测到剩余内存小于最小内存阈值时，通知所述处理模块；

所述处理模块还用于根据所述通知杀死当前处于后台运行状态的各应用。

进一步地，本发明还提供了一种应用杀死处理方法，包括：

在系统启动后，获取当前处于运行状态的各应用之识别信息；

将所述各应用的识别信息与预设的应用名单进行匹配，所述应用名单中包含待管理应用名单和保留应用名单，所述待管理应用名单中包含待杀死处理的各应用之识别信息，所述保留应用名单中包含无需进行杀死处理的各应用之识别信息；

根据匹配结果对识别信息在所述待管理应用名单中的各目标应用，分别获取所述各目标应用当前的运行状态信息；

根据所述各目标应用的运行状态信息分别判断各目标应用是否满足杀死条件；

对满足杀死条件的目标应用，调用该目标应用对应的杀死策略对其进行杀死处理。

其中，所述待管理应用名单包括：特殊名单、灰名单以及普通名单；

所述特殊名单中包含伴随系统运行而运行的各应用的识别信息；

所述灰名单中包含杀死后允许重启的各应用的识别信息；

所述普通名单中包含所述系统中，除所述特殊名单、灰名单以及保留应用名单中的各应用之外的其他各应用的识别信息；

分别获取所述各目标应用当前的运行状态信息包括：

对识别信息在所述特殊名单中的目标应用，获取该目标应用当前占用的内存；

对识别信息在所述普通名单和所述灰名单中的目标应用，当该目标应用为第三方应用时，获取该目标应用当前占用的内存，当该目标应用为预置应用时，获取该目标应用的系统资源使用权限标记值，并在获取的系统资源使用权限标记值小于预设标记阈值时，获取该目标应用当前占用的内存以及其运行标识。

其中，根据所述各目标应用的运行状态信息分别判断各目标应用是否满足杀死条件包括：

对识别信息在所述特殊名单中的目标应用，判断该目标应用当前占用内存是否大于等于该目标应用对应的第一内存占用阈值，如是，判断满足杀死条件；

对识别信息在所述灰名单的目标应用，当该目标应用为第三方应用时，判断该目标应用当前占用内存是否大于等于该目标应用对应的第二内存占用阈值，如是，判断满足杀死条件；当该目标应用为预置应用时，判断该目标系统资源使用权限标记值是否大于等于所述预设标记阈值，如是，判断满足杀死条件，否则，判断该目标应用当前占用的内存是否大于等于第三内存占用阈值且其运行标识是否为假，如是，判断满足杀死条件；

对识别信息在所述普通名单的目标应用，当该目标应用为第三方应用时，判断该目标应用当前占用内存是否大于等于该目标应用对应的第四内存占用阈值，如是，判断满足杀死条件；当该目标应用为预置应用时，判断该目标系统资源使用权限标记值是否大于等于所述预设标记阈值，如是，判断满足杀死条件，否则，判断该目标应用当前占用的内存是否大于等于第五内存占用阈值且其运行标识是否为假，如是，判断满足杀死条件。

其中，对满足杀死条件的目标应用，调用该目标应用对应的杀死策略对其进行杀死处理包括：

对识别信息在所述特殊名单中且满足杀死条件的目标应用，调用的杀死策略包括保留该目标应用的服务业务，释放该目标应用的其他资源；

对识别信息在所述灰名单中且满足杀死条件的目标应用，调用的杀死策略包括杀死策略为释放该目标应用的所有资源，并允许所述目标应用的服务业务被正常唤醒；

对识别信息在所述普通名单中且满足杀死条件的目标应用，调用的杀死策略包括杀死策略为释放该目标应用的所有资源，并禁止所述目标应用的服务业务被正常唤醒。

其中，在系统启动后还包括对系统内存进行监测；

在监测到剩余内存小于最小内存阈值时，杀死当前处于后台运行状态的各应用。

有益效果

本发明提供的终端及其应用杀死处理方法，先设置好包含待管理应用名单和保留应用名单的应用名单中，设置待管理应用名单中包含需杀死处理的各应用之识别信息，并设置保留应用名单中包含无需杀死处理的各应用(例如不能杀死或用户不希望杀死的应用)之识别信息；然后在系统启动后，获取当前处于运行状态的各应用之识别信息，将各应用的识别信息与应用名单进行匹配，进而根据匹配结果获取识别信息在待管理应用名单中的各目标应用当前的运行状态信息，并根据运行状态信息判断出满足杀死条件的目标应用时，调用该目标应用对应的杀死策略对其进行杀死处理。通过本发明提供的方法可以将不需要进行杀死处理的应用进行有效隔离，使得对终端内的应用进行的杀死处理更为准确、合理，避免错杀、误杀的情况发生，提升用户体验的满意度。

附图说明

下面将结合附图及实施例对本发明作进一步说明，附图中：

图1为实现本发明各个实施例一个可选的移动终端的硬件结构示意图；

图2为本发明第一实施例提供的终端结构示意图；

图3为本发明第二实施例提供的终端结构示意图；

图4为本发明第三实施例提供的应用杀死处理方法流程示意图；

图5为本发明第四实施例提供的应用杀死处理方法流程示意图。

具体实施方式

应当理解，此处所描述的具体实施例仅仅用以解释本发明，并不用于限定本发明。

现在将参考附图描述实现本发明各个实施例的终端，在后续的描述中，使用用于表示元件的诸如“模块”、“部件”或“单元”的后缀仅为了有利于本发明的说明，其本身并没有特定的意义。因此，"模块"与"部件"可以混合地使用。

终端可以以各种形式来实施。例如，本发明中描述的终端可以包括诸如移动电话、智能电话、笔记本电脑、数字广播接收器、pda(个人数字助理)、pad(平板电脑)、pmp(便携式多媒体播放器)、导航装置等等的移动终端以及诸如数字tv、台式计算机等等的固定终端。下面，假设终端是移动终端，然而，本领域技术人员将理解的是，除了特别用于移动目的的元件之外，根据本发明的实施方式的构造也能够应用于固定类型的终端。

图1为实现本发明各个实施例一个可选的移动终端的硬件结构示意图。

移动终端100可以包括无线通信单元110、a/v(音频/视频)输入单元120、用户输入单元130、感测单元140、输出单元150、存储器160、接口单元170、控制器180和电源单元190等等。图1示出了具有各种组件的移动终端，但是应理解的是，并不要求实施所有示出的组件，可以替代地实施更多或更少的组件，将在下面详细描述移动终端的元件。

无线通信单元110通常包括一个或多个组件，其允许移动终端100与无线通信系统或网络之间的无线电通信。例如，无线通信单元可以包括广播接收模块、移动通信模块、无线互联网模块、短程通信模块和位置信息模块中的至少一个。

a/v输入单元120用于接收音频或视频信号。a/v输入单元120可以包括相机和麦克风，相机对在视频捕获模式或图像捕获模式中由图像捕获装置获得的静态图片或视频的图像数据进行处理。处理后的图像帧可以显示在显示模块上。经相机处理后的图像帧可以存储在存储器160(或其它存储介质)中或者经由无线通信单元110进行发送，可以根据移动终端的构造提供两个或更多相机。麦克风可以在电话通话模式、记录模式、语音识别模式等等运行模式中经由麦克风接收声音(音频数据)，并且能够将这样的声音处理为音频数据。处理后的音频(语音)数据可以在电话通话模式的情况下转换为可经由移动通信模块发送到移动通信基站的格式输出。麦克风可以实施各种类型的噪声消除(或抑制)算法以消除(或抑制)在接收和发送音频信号的过程中产生的噪声或者干扰。

用户输入单元130可以根据用户输入的命令生成键输入数据以控制移动终端的各种操作。用户输入单元130允许用户输入各种类型的信息，并且可以包括键盘、锅仔片、触摸板(例如，检测由于被接触而导致的电阻、压力、电容等等的变化的触敏组件)、滚轮、摇杆等等。特别地，当触摸板以层的形式叠加在显示模块上时，可以形成触摸屏。

感测单元140检测移动终端100的当前状态，(例如，移动终端100的打开或关闭状态)、移动终端100的位置、用户对移动终端100的接触(即，触摸输入)的有无、移动终端100的取向、移动终端100的加速或减速移动和方向等等，并且生成用于控制移动终端100的操作的命令或信号。例如，当移动终端100实施为滑动型移动电话时，感测单元140可以感测该滑动型电话是打开还是关闭。另外，感测单元140能够检测电源单元190是否提供电力或者接口单元170是否与外部装置耦接。感测单元140可以包括接近传感器。

例如，本发明中，第一电池和第二电池当前电量的监测可以通过感测单元140来实现，以及外部电源与数据传输接口连接将对第二电池进行充电时，感测单元140也可以监测数据传输接口电压，当数据传输接口电压达到预设电压值时，启动充电模式对第二电池进行充电。

接口单元170用作至少一个外部装置与移动终端100连接可以通过的接口。例如，外部装置可以包括有线或无线头戴式耳机端口、外部电源(或电池充电器)端口、有线或无线数据端口、存储卡端口、用于连接具有识别模块的装置的端口、音频输入/输出(i/o)端口、视频i/o端口、耳机端口等等。识别模块可以是存储用于验证用户使用移动终端100的各种信息并且可以包括用户识别模块(uim)、客户识别模块(sim)、通用客户识别模块(usim)等等。另外，具有识别模块的装置(下面称为"识别装置")可以采取智能卡的形式，因此，识别装置可以经由端口或其它连接装置与移动终端100连接。接口单元170可以用于接收来自外部装置的输入(例如，数据信息、电力等等)并且将接收到的输入传输到移动终端100内的一个或多个元件或者可以用于在移动终端和外部装置之间传输数据。

例如，本发明中的充电接口和数据传输接口可以用于接收外部电源输入的电流信号，对第一电池和第二电池进行充电。

另外，当移动终端100与外部底座连接时，接口单元170可以用作允许通过其将电力从底座提供到移动终端100的路径或者可以用作允许从底座输入的各种命令信号通过其传输到移动终端的路径。从底座输入的各种命令信号或电力可以用作用于识别移动终端是否准确地安装在底座上的信号。输出单元150被构造为以视觉、音频和/或触觉方式提供输出信号(例如，音频信号、视频信号、警报信号、振动信号等等)。

输出单元150可以包括显示模块、音频输出模块、警报模块等等。

显示模块可以显示在移动终端100中处理的信息。例如，当移动终端100处于电话通话模式时，显示模块可以显示与通话或其它通信(例如，文本消息收发、多媒体文件下载等等)相关的用户界面(ui)或图形用户界面(gui)。当移动终端100处于视频通话模式或者图像捕获模式时，显示模块可以显示捕获的图像和/或接收的图像、示出视频或图像以及相关功能的ui或gui等等。

例如，本发明中的电池电量显示可以通过显示模块显示在移动终端显示界面上。

同时，当显示模块和触摸板以层的形式彼此叠加以形成触摸屏时，显示模块可以用作输入装置和输出装置。显示模块可以包括液晶显示器(lcd)、薄膜晶体管lcd(tft-lcd)、有机发光二极管(oled)显示器、柔性显示器、三维(3d)显示器等等中的至少一种。这些显示器中的一些可以被构造为透明状以允许用户从外部观看，这可以称为透明显示器，典型的透明显示器可以例如为toled(透明有机发光二极管)显示器等等。根据特定想要的实施方式，移动终端100可以包括两个或更多显示模块(或其它显示装置)，例如，移动终端可以包括外部显示模块(未示出)和内部显示模块(未示出)。触摸屏可用于检测触摸输入压力以及触摸输入位置和触摸输入面积。

存储器160可以存储由控制器180执行的处理和控制操作的软件程序等等，或者可以暂时地存储己经输出或将要输出的数据(例如，电话簿、消息、静态图像、视频以及各种名单等等)。而且，存储器160可以存储关于当触摸施加到触摸屏时输出的各种方式的振动和音频信号的数据。

存储器160可以包括至少一种类型的存储介质，所述存储介质包括闪存、硬盘、多媒体卡、卡型存储器(例如，sd或dx存储器等等)、随机访问存储器(ram)、静态随机访问存储器(sram)、只读存储器(rom)、电可擦除可编程只读存储器(eeprom)、可编程只读存储器(prom)、磁性存储器、磁盘、光盘等等。而且，移动终端100可以与通过网络连接执行存储器160的存储功能的网络存储装置协作。

控制器180通常控制移动终端的总体操作。例如，控制器180执行与语音通话、数据通信、视频通话等等相关的控制和处理。另外，控制器180可以包括用于名单管理模块、识别信息获取模块、匹配模块、判断模块以及处理模块，且以上模块可以构造在控制器180内，或者可以构造为与控制器180分离。控制器180可以执行名单管理、应用信息的获取、匹配以及应用运行状态信息的获取、判断和应用的杀死处理等。

电源单元190在控制器180的控制下接收外部电力或内部电力并且提供操作各元件和组件所需的适当的电力。

例如，本发明中的第一电池和第二电池可以设置在电源单元190中，控制器180可以控制外部电源对第一电池和第二电池的充电过程，以及可以控制第二电池对第一电池的充电过程。

这里描述的各种实施方式可以以使用例如计算机软件、硬件或其任何组合的计算机可读介质来实施。对硬件实施，这里描述的实施方式可以通过使用特定用途集成电路(asic)、数字信号处理器(dsp)、数字信号处理装置(dspd)、可编程逻辑装置(pld)、现场可编程门阵列(fpga)、处理器、控制器、微控制器、微处理器、被设计为执行这里描述的功能的电子单元中的至少一种来实施，在一些情况下，这样的实施方式可以在控制器180中实施。对软件实施，诸如过程或功能的实施方式可以与允许执行至少一种功能或操作的单独的软件模块来实施。软件代码可以由以任何适当的编程语言编写的软件应用程序(或程序)来实施，软件代码可以存储在存储器160中并且由控制器180执行。

至此，己经按照其功能描述了移动终端。下面，为了简要起见，将描述诸如折叠型、直板型、摆动型、滑动型移动终端等等的各种类型的移动终端中的滑动型移动终端作为示例。因此，本发明能够应用于任何类型的移动终端，并且不限于滑动型移动终端。

以下通过具体实施例进行详细说明。

第一实施例

本实施例提供的终端参见图2所示，包括：

名单管理模块21，用于管理应用名单。其中实施例中的应用名单中包含待管理应用名单和保留应用名单，待管理应用名单中包含需杀死处理的各应用之识别信息，保留应用名单中包含无需杀死处理的各应用之识别信息。本实施例中的名单管理模块21的功能可以通过终端的控制器或处理器实现，其可以构造于控制器或处理器内。

本实施例中名单管理模块21对应用名单的管理包括但不限于对名单中应用的识别信息进行增加、删除、变更等更新，且这些更新操作可以由用户触发，也可以设置一个具体的更新机制自动触发。本实施例中待管理应用名单和保留应用名单中的应用的识别信息支持用户自定义，也可以根据各应用自身的特点、属性等自动分类。其中保留应用名单中的应用可以是保证系统正常运行而不能被杀死的应用，或者用户自定义的不希望被杀死的各种应用。待管理应用名单中的应用则可以是终端系统中，除保留应用名单之外的其他应用，也可以支持用户自定义设置。

另外，应当理解的是，本实施例中的待管理应用名单和保留应用名单可以存储在终端本地，也可以存储在云端，并在终端需要使用时从云端下载到本地，或者直接将待匹配的识别信息发送到云端，在云端完成匹配，并将匹配结果返回给终端。

应当理解的是，本实施例中的应用的识别信息可以是任意能唯一识别个应用的信息，例如在安卓系统中，不同应用的安装包名称不同时，则应用的识别信息可以包含应用的安装包名称；当然也可以通过应用的多个属性信息的组合以对不同应用进行区分。

本实施例中的待管理应用名单和保留应用名单可以时终端出厂前就设置好的，并在终端出厂后的使用过程中提供用户自定义接口，以接受不同用户的个性化自定义，满足不同用户的个性化需求，以进一步提升用户体验的满意度。当然，上述待管理应用名单和保留应用名单也可以是在终端出厂后由用户自己建立及设置。

识别信息获取模块22，用于在系统启动后，获取当前处于运行状态的各应用之识别信息。本实施例中的识别信息获取模块22的功能也可以通过终端的控制器或处理器实现，其可以构造于控制器或处理器内。

本实施例中的识别信息获取模块22可以通过各种方式获取到当前处于运行状态的应用的识别信息。

匹配模块23，用于将各应用的识别信息与应用名单进行匹配。

具体的，匹配模块23针对获取到的每一应用的识别信息，可以将应用的识别信息先与保留应用名单中的各应用的识别信息进行匹配，以判断该应用是否属于不需要进行杀死处理的应用，如果保留应用名单中的某一识别信息与该应用的识别信息匹配(可以通过判断二者是否相同或者其他匹配算法以确定二者是否匹配)，则判定该应用属于不需要杀死的应用。如果该应用的识别信息与保留应用名单中的各应用的识别信息都不匹配，则可以直接判定该应用属于需要进行杀死处理的应用(适用于终端系统内的所有应用的识别信息设置于应用名单中的情况)；或者再将该应用的识别信息与待管理应用名单中的各识别信息进行匹配，如果该应用的识别信息与待管理应用名单中的某一识别信息匹配，则判定为需要进行杀死处理的应用。

匹配模块23针对获取到的每一应用的识别信息，也可以将应用的识别信息先与待管理应用名单中的各应用的识别信息进行匹配，以判断该应用是否属于需要进行杀死处理的应用，如果待管理应用名单中的某一识别信息与该应用的识别信息匹配(可以通过判断二者是否相同或者其他匹配算法以确定二者是否匹配)，则判定该应用属于需要杀死的应用。如果该应用的识别信息与待管理应用名单中的各应用的识别信息都不匹配，则可以直接判定该应用属于不需要进行杀死处理的应用(适用于终端系统内的所有应用的识别信息设置于应用名单中的情况)；或者再将该应用的识别信息与保留应用名单中的各识别信息进行匹配，如果该应用的识别信息与保留应用名单中的某一识别信息匹配，则判定为不需要进行杀死处理的应用。

匹配模块23的功能也可以通过终端的控制器或处理器实现，其可以构造于控制器或处理器内。匹配模块23采用的具体匹配规则以及匹配顺序具体可以根据实际场景灵活设定。

状态信息获取模块24，用于根据匹配结果获取识别信息在待管理应用名单中的各目标应用当前的运行状态信息。

对于识别信息在待管理应用名单中的应用为目标应用，也即为需要进行杀死处理的目标应用，需要判定其当前是否满足杀死条件，本实施例则是根据其运行状态信息来判定其是否满足杀死条件。当然，在一些实施方式中，也可以不判断而对其直接进行杀死处理。

应当理解的是，本实施例中的杀死条件的设置除了根据应用运行状态设置外，也可以采用其他的设置规则，例如根据当前系统的内存占用情况等进行设置。本实施例中获取的应用的运行情况包括但不限于应用当前运行占用的内存或者应用的数据流量等等。状态信息获取模块24的功能也可以通过终端的控制器或处理器实现，其可以构造于控制器或处理器内。

判断模块25，用于根据获取的各目标应用的运行状态信息分别判断各目标应用是否满足杀死条件。

本实施例中针对待管理应用名单中的所有应用可以设置相同的杀死条件，也可以针对各应用分别各自设置杀死条件，且设置结果可以是部分应用的杀死条件相同，部分应用的杀死条件不同。

另外，本实施例中各应用的杀死条件可以支持用户自定义设置。

处理模块26，用于对满足杀死条件的目标应用，调用该目标应用对应的杀死策略对其进行杀死处理。

本实施例中针对待管理应用名单中的所有应用可以设置相同的杀死策略，也可以针对各应用分别各自设置杀死策略，且设置结果可以是部分应用的杀死策略相同，部分应用的杀死策略不同。

本实施例中判断模块25和处理模块26的功能也可以通过终端的控制器或处理器实现，其可以构造于控制器或处理器内。

本实施例提供的终端可以通过保留应用名单和待管理应用名单将不需要进行杀死处理的应用进行有效隔离，使得仅对待管理应用处理内的应用进行杀死处理，对于不能杀死或者用户不希望杀死的应用则可以设置于保留应用名单中，这样终端内的应用进行的杀死处理更为准确、合理，避免错杀、误杀的情况发生，提升用户体验的满意度。

第二实施例

本实施例中，对于在待管理应用名单中的各应用，还可以根据各应用自身的特性进行再次分类，并针对不同类的需要进行杀死处理的应用设置相应的杀死条件和/或杀死策略，以更准确、合理的对终端内的应用进行杀死处理，进一步提升用户体验的满意度。

为了便于理解，本实施例先对终端内的应用自身类型进行示例说明。一般终端包括：

系统应用：系统及芯片等厂商提供的不可下载的应用，例如android和高通提供的不可卸载应用；

预置应用：系统应用和终端厂商预置的自研应用，例如android和高通提供的不可卸载应用以及努比亚自己研发的一些应用，且这些应用可以在出厂前就预置在终端内。

第三方应用：预置应用以外的应用，例如腾讯提供的qq、微信、云盘等应用都属于第三方应用。

本实施例中保留应用名单中的应用包含上述几种应用中的至少一种，例如可以仅包含预置应用，也可以包含预置应用和第三方应用，这些应用都是用户不希望进行杀死处理的应用，以保证应用的功能不失效。

本实施例中，对于待管理应用名单包括，还可以进一步将其分类为包括特殊名单、灰名单以及普通名单，其中：

特殊名单中包含伴随系统运行而运行的各应用的识别信息，例如输入法应用、桌面应用、动态壁纸应用、桌面上有widget的应用等等；特殊名单中的应用包含上述几种应用中的至少一种。

灰名单中包含杀死后允许重启的各应用的识别信息，灰名单中包含的应用可以根据用户的使用习惯、应用的自身特性以及用户下发的选择命令中的至少一种选择相应的应用进行设置。灰名单中的应用也包含上述几种应用中的至少一种。

普通名单中包含系统中，除特殊名单、灰名单以及保留应用名单中的各应用之外的其他各应用的识别信息。普通名单中的应用也包含上述几种应用中的至少一种。

状态信息获取模块24用于：

对识别信息在特殊名单中的目标应用，获取该目标应用的运行状态包括获取其当前占用的内存，

对识别信息在普通名单和灰名单中的目标应用，当该目标应用为第三方应用时，获取该目标应用的运行状态包括获取该目标应用当前占用的内存，当该目标应用为预置应用时，获取该目标应用的运行状态包括获取该目标应用的系统资源使用权限标记值(在安卓系统中为应用的adj值)，并在获取的系统资源使用权限标记值小于预设标记阈值(例如8，具体阈值可以灵活设定)时，获取该目标应用当前占用的内存以及其运行标识(其运行标识可能为真(ture)或假(false))。

对应的，判断模块25用于：

对识别信息在特殊名单中的目标应用，判断该目标应用当前占用内存是否大于等于该目标应用对应的第一内存占用阈值，如是，判断满足杀死条件；

本实施例中特殊名单中的各应用可以共用一个第一内存占用阈值，也可以针对不同的应用设置不同的第一内存占用阈值。例如：

如输入法应用对应的第一内存占用阈值可以设置为200m；

桌面应用对应的第一内存占用阈值可以设置为250m；

动态壁纸应用对应的第一内存占用阈值可以设置为200m；

桌面上有widget的应用对应的第一内存占用阈值可以设置为150m等。

判断模块25还用于对识别信息在灰名单的目标应用，当该目标应用为第三方应用时，判断该目标应用当前占用内存是否大于等于该目标应用对应的第二内存占用阈值，如是，判断满足杀死条件；当该目标应用为预置应用时，判断该目标系统资源使用权限标记值是否大于等于预设标记阈值，如是，判断满足杀死条件，否则，判断该目标应用当前占用的内存是否大于等于第三内存占用阈值且其运行标识是否为假false，如是，判断满足杀死条件。

本实施例中普通名单中的第三方应用可以共用一个第二内存占用阈值(例如30m)，也可以针对不同的第三方应用设置不同的第二内存占用阈值。本实施例中普通名单中的阈值应用可以共用一个预设标记阈值(例如8)，也可以针对不同的第三方应用设置不同的预设标记阈值。本实施例中普通名单中的预置应用可以共用一个第三内存占用阈值(例如50m)，也可以针对不同的预置应用设置不同的第三内存占用阈值。

判断模块25还用于对识别信息在普通名单的目标应用，当该目标应用为第三方应用时，判断该目标应用当前占用内存是否大于等于该目标应用对应的第四内存占用阈值，如是，判断满足杀死条件；当该目标应用为预置应用时，判断该目标系统资源使用权限标记值是否大于等于预设标记阈值，如是，判断满足杀死条件，否则，判断该目标应用当前占用的内存是否大于等于第五内存占用阈值且其运行标识是否为假false，如是，判断满足杀死条件。

本实施例中普通名单中的第三方应用可以共用一个第四内存占用阈值(且可等于第二内存占用阈值)，也可以针对不同的第三方应用设置不同的第四内存占用阈值。本实施例中普通名单中的阈值应用可以共用一个预设标记阈值(例如8)，也可以针对不同的第三方应用设置不同的预设标记阈值。本实施例中普通名单中的预置应用可以共用一个第五内存占用阈值(且可等于第三内存占用阈值)，也可以针对不同的预置应用设置不同的第五内存占用阈值。

本实施例中，针对特殊名单中的应用，设置其杀死策略为：保留服务杀死，也即在对该特殊名单中的目标应用进行杀死时，保留该目标应用的服务业务，释放该目标应用的其他资源，这样可以保证应用功能的完整性；

针对灰名单中的应用，设置其杀死策略为：允许重启杀死，也即在对该特殊名单中的目标应用进行杀死时，释放该目标应用的所有资源，并允许目标应用的服务业务(例如该应用之前注册的各种广播服务)被正常唤醒以保证应用功能的完整性；

针对普通名单中的应用，设置其杀死策略为：彻底杀死，也即在对该特殊名单中的目标应用进行杀死时，释放该目标应用的所有资源，并禁止目标应用的服务业务，避免该目标应用自动重启。

对应的，本实施例中的处理模块26对识别信息在特殊名单中且满足杀死条件的目标应用，调用保留服务杀死策略，保留该目标应用的服务业务，释放该目标应用的其他资源；

处理模块26对识别信息在灰名单中且满足杀死条件的目标应用，调用允许重启杀死策略，释放该目标应用的所有资源，并允许目标应用的服务业务被正常唤醒；

处理模块26对识别信息在普通名单中且满足杀死条件的目标应用，调用彻底杀死策略，释放该目标应用的所有资源，并禁止目标应用的服务业务被正常唤醒。

参见图3所示，在本实施例中的终端还包括内存监测模块27，用于对系统内存进行监测，并在监测到剩余内存小于最小内存阈值时(例如仅剩余2％的内存时)，通知处理模块26；

处理模块26还用于根据接收到的通知杀死当前处于后台运行状态的各应用，仅保留前台运行的应用，以保证系统正常运行。

本实施例对于允许杀死的各应用，还可根据各应用所属的具体类别分别设置不同的杀死条件以及杀死策略，从而对相应的应用进行更为准确、合理的杀死操作，在尽可能减少对用户的使用影响的前提下，保证系统的流畅性以及省电性能。

第三实施例

本实施例提供了一种应用杀死处理方法，先针对终端系统设置管理应用名单。其中实施例中的应用名单中包含待管理应用名单和保留应用名单，待管理应用名单中包含需杀死处理的各应用之识别信息，保留应用名单中包含无需杀死处理的各应用之识别信息。本实施例中对应用名单的管理包括但不限于对名单中应用的识别信息进行增加、删除、变更等更新，且这些更新操作可以由用户触发，也可以设置一个具体的更新机制自动触发。本实施例中待管理应用名单和保留应用名单中的应用的识别信息支持用户自定义，也可以根据各应用自身的特点、属性等自动分类。其中保留应用名单中的应用可以是保证系统正常运行而不能被杀死的应用，或者用户自定义的不希望被杀死的各种应用。待管理应用名单中的应用则可以是终端系统中，除保留应用名单之外的其他应用，也可以支持用户自定义设置。另外，应当理解的是，本实施例中的待管理应用名单和保留应用名单可以存储在终端本地，也可以存储在云端，并在终端需要使用时从云端下载到本地，或者直接将待匹配的识别信息发送到云端，在云端完成匹配，并将匹配结果返回给终端。应当理解的是，本实施例中的应用的识别信息可以是任意能唯一识别个应用的信息，例如在安卓系统中，不同应用的安装包名称不同时，则应用的识别信息可以包含应用的安装包名称；当然也可以通过应用的多个属性信息的组合以对不同应用进行区分。本实施例中的待管理应用名单和保留应用名单可以时终端出厂前就设置好的，并在终端出厂后的使用过程中提供用户自定义接口，以接受不同用户的个性化自定义，满足不同用户的个性化需求，以进一步提升用户体验的满意度。当然，上述待管理应用名单和保留应用名单也可以是在终端出厂后由用户自己建立及设置。

基于上述设置，本实施例中的应用杀死处理方法参见图4所示，包括：

s401：在系统启动后，获取当前处于运行状态的各应用之识别信息。

s402：将各应用的识别信息与预设的应用名单进行匹配。

针对获取到的每一应用的识别信息，可以将应用的识别信息先与保留应用名单中的各应用的识别信息进行匹配，以判断该应用是否属于不需要进行杀死处理的应用，如果保留应用名单中的某一识别信息与该应用的识别信息匹配(可以通过判断二者是否相同或者其他匹配算法以确定二者是否匹配)，则判定该应用属于不需要杀死的应用。如果该应用的识别信息与保留应用名单中的各应用的识别信息都不匹配，则可以直接判定该应用属于需要进行杀死处理的应用(适用于终端系统内的所有应用的识别信息设置于应用名单中的情况)；或者再将该应用的识别信息与待管理应用名单中的各识别信息进行匹配，如果该应用的识别信息与待管理应用名单中的某一识别信息匹配，则判定为需要进行杀死处理的应用。匹配顺序也可以对调，先与待管理应用名单中的各识别信息进行匹配，再与保留应用名单中的各应用的识别信息进行匹配。

s403：根据匹配结果对识别信息在所述待管理应用名单中的各目标应用，分别获取所述各目标应用当前的运行状态信息。

对于识别信息在待管理应用名单中的应用为目标应用，也即为需要进行杀死处理的目标应用，需要判定其当前是否满足杀死条件，本实施例则是根据其运行状态信息来判定其是否满足杀死条件。当然，在一些实施方式中，也可以不判断而对其直接进行杀死处理。

应当理解的是，本实施例中的杀死条件的设置除了根据应用运行状态设置外，也可以采用其他的设置规则，例如根据当前系统的内存占用情况等进行设置。本实施例中获取的应用的运行情况包括但不限于应用当前运行占用的内存或者应用的数据流量等等。

s404：根据所各目标应用的运行状态信息分别判断各目标应用是否满足杀死条件。本实施例中针对待管理应用名单中的所有应用可以设置相同的杀死条件，也可以针对各应用分别各自设置杀死条件，且设置结果可以是部分应用的杀死条件相同，部分应用的杀死条件不同。

s405：对满足杀死条件的目标应用，调用该目标应用对应的杀死策略对其进行杀死处理。本实施例中针对待管理应用名单中的所有应用可以设置相同的杀死策略，也可以针对各应用分别各自设置杀死策略，且设置结果可以是部分应用的杀死策略相同，部分应用的杀死策略不同。

通过图4所示的应用杀死管理方法，可以使得仅对待管理应用处理内的应用进行杀死处理，对于不能杀死或者用户不希望杀死的应用则可以设置于保留应用名单中，这样终端内的应用进行的杀死处理更为准确、合理，避免错杀、误杀的情况发生，提升用户体验的满意度。

本实施例中，对于在待管理应用名单中的各应用，还可以根据各应用自身的特性进行再次分类，并针对不同类的需要进行杀死处理的应用设置相应的杀死条件和/或杀死策略，以更准确、合理的对终端内的应用进行杀死处理，进一步提升用户体验的满意度。因此本实施例中的待管理应用名单还可进一步包括：特殊名单、灰名单以及普通名单，其中：

特殊名单中包含伴随系统运行而运行的各应用的识别信息，例如输入法应用、桌面应用、动态壁纸应用、桌面上有widget的应用等等。

灰名单中包含杀死后允许重启的各应用的识别信息，灰名单中包含的应用可以根据用户的使用习惯、应用的自身特性以及用户下发的选择命令中的至少一种选择相应的应用进行设置。

普通名单中包含系统中，除特殊名单、灰名单以及保留应用名单中的各应用之外的其他各应用的识别信息。

此时s403中分别获取各目标应用当前的运行状态信息包括：

对识别信息在特殊名单中的目标应用，获取该目标应用的运行状态包括获取其当前占用的内存，

对识别信息在普通名单和灰名单中的目标应用，当该目标应用为第三方应用时，获取该目标应用的运行状态包括获取该目标应用当前占用的内存，当该目标应用为预置应用时，获取该目标应用的运行状态包括获取该目标应用的系统资源使用权限标记值(在安卓系统中为应用的adj值)，并在获取的系统资源使用权限标记值小于预设标记阈值(例如8，具体阈值可以灵活设定)时，获取该目标应用当前占用的内存以及其运行标识(其运行标识可能为真(ture)或假(false))。

s404中，根据各目标应用的运行状态信息分别判断各目标应用是否满足杀死条件包括：

对识别信息在特殊名单中的目标应用，判断该目标应用当前占用内存是否大于等于该目标应用对应的第一内存占用阈值，如是，判断满足杀死条件；

本实施例中特殊名单中的各应用可以共用一个第一内存占用阈值，也可以针对不同的应用设置不同的第一内存占用阈值。例如：

如输入法应用对应的第一内存占用阈值可以设置为200m；

桌面应用对应的第一内存占用阈值可以设置为250m；

动态壁纸应用对应的第一内存占用阈值可以设置为200m；

桌面上有widget的应用对应的第一内存占用阈值可以设置为150m等。

对识别信息在灰名单的目标应用，当该目标应用为第三方应用时，判断该目标应用当前占用内存是否大于等于该目标应用对应的第二内存占用阈值，如是，判断满足杀死条件；当该目标应用为预置应用时，判断该目标系统资源使用权限标记值是否大于等于预设标记阈值，如是，判断满足杀死条件，否则，判断该目标应用当前占用的内存是否大于等于第三内存占用阈值且其运行标识是否为假false，如是，判断满足杀死条件。

本实施例中普通名单中的第三方应用可以共用一个第二内存占用阈值(例如30m)，也可以针对不同的第三方应用设置不同的第二内存占用阈值。本实施例中普通名单中的阈值应用可以共用一个预设标记阈值(例如8)，也可以针对不同的第三方应用设置不同的预设标记阈值。本实施例中普通名单中的预置应用可以共用一个第三内存占用阈值(例如50m)，也可以针对不同的预置应用设置不同的第三内存占用阈值。

对识别信息在普通名单的目标应用，当该目标应用为第三方应用时，判断该目标应用当前占用内存是否大于等于该目标应用对应的第四内存占用阈值，如是，判断满足杀死条件；当该目标应用为预置应用时，判断该目标系统资源使用权限标记值是否大于等于预设标记阈值，如是，判断满足杀死条件，否则，判断该目标应用当前占用的内存是否大于等于第五内存占用阈值且其运行标识是否为假false，如是，判断满足杀死条件。

本实施例中普通名单中的第三方应用可以共用一个第四内存占用阈值(且可等于第二内存占用阈值)，也可以针对不同的第三方应用设置不同的第四内存占用阈值。本实施例中普通名单中的阈值应用可以共用一个预设标记阈值(例如8)，也可以针对不同的第三方应用设置不同的预设标记阈值。本实施例中普通名单中的预置应用可以共用一个第五内存占用阈值(且可等于第三内存占用阈值)，也可以针对不同的预置应用设置不同的第五内存占用阈值。

本实施例中，针对特殊名单中的应用，设置其杀死策略为：保留服务杀死，也即在对该特殊名单中的目标应用进行杀死时，保留该目标应用的服务业务，释放该目标应用的其他资源，这样可以保证应用功能的完整性；

针对灰名单中的应用，设置其杀死策略为：允许重启杀死，也即在对该特殊名单中的目标应用进行杀死时，释放该目标应用的所有资源，并允许目标应用的服务业务(例如该应用之前注册的各种广播服务)被正常唤醒以保证应用功能的完整性；

针对普通名单中的应用，设置其杀死策略为：彻底杀死，也即在对该特殊名单中的目标应用进行杀死时，释放该目标应用的所有资源，并禁止目标应用的服务业务，避免该目标应用自动重启。

对应的，本实施例中s405中对识别信息在特殊名单中且满足杀死条件的目标应用，调用保留服务杀死策略，保留该目标应用的服务业务，释放该目标应用的其他资源；

对识别信息在灰名单中且满足杀死条件的目标应用，调用允许重启杀死策略，释放该目标应用的所有资源，并允许目标应用的服务业务被正常唤醒；

对识别信息在普通名单中且满足杀死条件的目标应用，调用彻底杀死策略，释放该目标应用的所有资源，并禁止目标应用的服务业务被正常唤醒。

本实施例中，在系统启动后还包括：

对系统内存进行监测；

在监测到剩余内存小于最小内存阈值时，杀死当前处于后台运行状态的各应用。

可见，本实施例对于允许杀死的各应用，还可根据各应用所属的具体类别分别设置不同的杀死条件以及杀死策略，从而对相应的应用进行更为准确、合理的杀死操作，在尽可能减少对用户的使用影响的前提下，保证系统的流畅性以及省电性能。

第四实施例

为了更好的理解本发明，本实施例以终端运行安卓系统为示例，对本发明的方案进行进一步示例说明。

本实施例中，系统资源使用权限标记值对应的预设标记阈值取值为8；获取一个应用进程的系统资源使用权限标记值adj的过程如下所示：

获取进程的adj的值的流程说明：

(1)通过包名获取某个应用进程的pid的值；

(2)然后读取节点/proc/<pid>/oom_adj；

(3)获取该进程的adj的值；

本实施例中，获取某个应用当前占用的内存大小的过程如下所示：

(1)通过包名获取该应用进程的pid的值；

(2)获取activitymanager的对象；

(3)调用am的getprocessmemoryinfo(int[]pids)来获取该应用进程占用的内存大小。

本实施例中，具体可以通过serviceconnection启动进程管理服务，并获得进程管理服务.stub实例；然后调用getcanbekilledrunningapps获得当前正在运行的应用的相关信息，具体获取的某一应用的信息(或数据)格式示例说明如下：

process_name:类型string；表示该进程的进程名；

num_packages：类型int型；表示该进程中的包名的个数；

pkg_list：类型string[]数组；表示该进程中含有的所有包名；

pss：类型long型；表示该进程所占内存的大小；

app_type：类型int；1表示内置应用；0表示第三方应用。

本实施例中的三种杀死策略表示参见如下表1所示：

表1

本实施例中，对于终端存储满的异常处理:

当检测终端内存占用超过98％的时候,弹出提示“存储已经快满了，请大侠释放存储空间的内存”，在检测到用户确认或者超时不确认时，自动清理所有当前正在运行的应用，除了正在处于前台的激活应用。

基于上述设置，本实施例中的应用杀死处理方法参见图5所示，包括：

s501：启动多任务的同时，绑定进程管理服务，获得i进程管理服务.stub的binder客户端。

s502：触发清理，通过binder客户端将对onkeycleanexcludecurrentapp(stringcurrentpkgname)进行一键清理。

s503：过虑掉当前应用中多任务传递过来的currentpkgname，获得系统中正在运行的应用。

s504：将系统中正在运行的应用的识别信息与应用名单进行匹配，过滤掉保留名单中的各应用，剩下需要进行杀死处理的应用。

s505：挑选出满足杀死条件的各目标应用。

对于识别信息在特殊名单中的目标应用，判断该目标应用当前占用内存是否大于等于该目标应用对应的第一内存占用阈值，例如当前目标应用为输入法，判断输入法应用占用的内存大于对应的第一内存占用阈值200m时，判定满足杀死条件。

对识别信息在灰名单的目标应用，当该目标应用为第三方应用时，判断该目标应用当前占用内存是否大于等于该目标应用对应的第二内存占用阈值30m，如是，判断满足杀死条件；当该目标应用为预置应用时，判断该目标系统资源使用权限标记值是否大于等于预设标记阈值8，如是，判断满足杀死条件，否则，判断该目标应用当前占用的内存是否大于等于第三内存占用阈值50m且其运行标识是否为假false，如是，判断满足杀死条件。

对识别信息在普通名单的目标应用，当该目标应用为第三方应用时，判断该目标应用当前占用内存是否大于等于该目标应用对应的第四内存占用阈值30m，如是，判断满足杀死条件；当该目标应用为预置应用时，判断该目标系统资源使用权限标记值是否大于等于预设标记阈值8，如是，判断满足杀死条件，否则，判断该目标应用当前占用的内存是否大于等于第五内存占用阈值50m且其运行标识是否为假false，如是，判断满足杀死条件。

s506：选择满足杀死条件的目标应用对应的杀死策略进行查杀。

如果满足杀死条件的目标应用为特殊名单中的目标应用，调动killbackgroundprocesses()对其进行杀死，以保证保留应用的功能的完整性；

如果满足杀死条件的目标应用为灰名单中的目标应用，调动killapplicationprocess()对其进行杀死，以保证保留应用的功能的完整性；

如果满足杀死条件的目标应用为普通名单中的目标应用，调动forcestoppackage()对其进行杀死，以保证最大限度的释放内存来。

通过本实施例提供的应用杀死处理方法，可以对应用进行合理的分类和管理，以提升应用查杀的准确度和用户体验。

需要说明的是，在本文中，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者装置不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者装置所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括该要素的过程、方法、物品或者装置中还存在另外的相同要素。

上述本发明实施例序号仅仅为了描述，不代表实施例的优劣。

通过以上的实施方式的描述，本领域的技术人员可以清楚地了解到上述实施例方法可借助软件加必需的通用硬件平台的方式来实现，当然也可以通过硬件，但很多情况下前者是更佳的实施方式。基于这样的理解，本发明的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质(如rom/ram、磁碟、光盘)中，包括若干指令用以使得一台终端设备(可以是手机，计算机，服务器，空调器，或者网络设备等)执行本发明各个实施例所述的方法。

上面结合附图对本发明的实施例进行了描述，但是本发明并不局限于上述的具体实施方式，上述的具体实施方式仅仅是示意性的，而不是限制性的，本领域的普通技术人员在本发明的启示下，在不脱离本发明宗旨和权利要求所保护的范围情况下，还可做出很多形式，这些均属于本发明的保护之内。