CN105718791B - 一种保护应用程序数据的方法和装置 - Google Patents

Abstract

本发明提供一种保护应用程序数据的方法和装置，旨在解决现有的Low Memory Killer机制容易错杀一些不应被杀死的进程导致用户体验降低的技术问题。所述方法包括：接收系统发布的告警信息，所述告警信息至少包括即将被杀死的进程的标识；判断所述将被杀死的进程是否为当前进程；若所述将被杀死的进程为所述当前进程，则对所述当前进程对应的应用程序的数据进行保护；在重启所述应用程序时，根据所述施行的保护恢复所述应用程序的数据。与现有技术提供的Low Memory Killer机制“粗暴地”杀死某个进程相比，本发明提供的方法使得即使在内存不足时，进程仍然能够不被滥杀，而是提前采取措施，有效地保护了正在运行的应用程序的数据，提高了用户的体验。

Description

一种保护应用程序数据的方法和装置

技术领域

本发明属于智能终端领域，尤其涉及一种保护应用程序数据的方法和装置。

背景技术

安卓(Android)系统是一个多任务系统，可以同时运行多个进程，进程的生命周期都由系统控制，即使用户关掉了程序的屏显，进程依然存在于内存之中，目的是为了下次能快速启动。如此，随着系统运行时间的加长，内存会越来越少，系统内核(kernel)定时执行一次检查，杀死一些进程来释放内存，该机制称为低内存杀死(Low Memory Killer)机制。

现有的Low Memory Killer机制是基于Linux操作系统的内存不足(Out OfMemory，OOM)规则改进而来的，通过进程的参数oom_adj与该进程占用内存的大小决定要杀死的进程，其中，参数oom_adj的大小与进程的类型、进程被调度的次序等有关。每个应用程序的oom_adj都有一个值(以下简称oom_adj值)，该值越小，该应用程序越重要，被系统杀死的可能性越低。Low Memory Killer驱动程序(Driver)在用户空间指定了一组内存临界值以及与之一一对应的一组oom_adj值，当系统的剩余内存位于内存临界值中的一个范围内时，如果一个进程的oom_adj值大于或等于这个临界值，对应的进程就会被杀死。

现有的Low Memory Killer机制虽然定期杀死了一些后台进程，释放了系统的内存，保证了前台应用程序的高效运行，然而，该机制是在用户并不知情的前提下运行的，即Low memory killer机制在杀死某个进程前并不会通知用户。如此，就会导致一个较大的问题，即，被杀死的应用程序数据会丢失。例如，置于后台的、用户编辑到一半的短信或邮件，用户并没有将编辑到一半的信息进行保存就打开了其它一些应用。若由于系统内存不足，一旦Low Memory Killer机制杀死用户编辑一半的短信或邮件等应用程序，用户已编辑的信息就会丢失，降低了用户体验。

发明内容

本发明的目的在于提供一种保护应用程序数据的方法和装置，旨在解决现有的Low Memory Killer机制容易错杀一些不应被杀死的进程导致用户体验降低的技术问题。

本发明是这样实现的，一种保护应用程序数据的方法，所述方法包括：

接收系统发布的告警信息，所述告警信息至少包括即将被杀死的进程的标识；

判断所述将被杀死的进程是否为当前进程；

若所述将被杀死的进程为所述当前进程，则对所述当前进程对应的应用程序的数据进行保护；

在重启所述应用程序时，根据所述施行的保护恢复所述应用程序的数据。

本发明的另一目的在于提供一种保护应用程序数据的装置，所述装置包括：

接收模块，用于接收系统发布的告警信息，所述告警信息至少包括即将被杀死的进程的标识；

判断模块，用于判断所述将被杀死的进程是否为当前进程；

保护模块，用于若所述判断模块的判断结果为所述将被杀死的进程为所述当前进程，则对所述当前进程对应的应用程序的数据进行保护；

恢复模块，用于在重启所述应用程序时，根据所述施行的保护恢复所述应用程序的数据。

从上述本发明技术方案可知，由于在杀死某个进程之前，通过告警信息的发布，对即将被杀死的进程是否是当前进程进行了判断；在判断将被杀死的进程为当前进程后，对当前进程对应的应用程序的数据进行了保护。因此，与现有技术提供的Low Memory Killer机制“粗暴地”杀死某个进程相比，本发明提供的方法使得即使在内存不足时，进程仍然能够不被滥杀，而是提前采取措施，有效地保护了正在运行的应用程序的数据，提高了用户的体验。

附图说明

图1是本发明实施例一提供的保护应用程序数据的方法的实现流程示意图；

图2是本发明实施例二提供的保护应用程序数据的方法的实现流程示意图；

图3是本发明实施例三提供的保护应用程序数据的方法的实现流程示意图；

图4是本发明实施例四提供的保护应用程序数据的方法的实现流程示意图；

图5是本发明实施例五提供的保护应用程序数据的方法的实现流程示意图；

图6是本发明实施例六提供的保护应用程序数据的方法的实现流程示意图；

图7是本发明实施例七提供的保护应用程序数据的装置的结构示意图；

图8是本发明实施例八提供的保护应用程序数据的装置的结构示意图；

图9是本发明实施例九提供的保护应用程序数据的装置的结构示意图；

图10是本发明实施例十提供的保护应用程序数据的装置的结构示意图；

图11-a是本发明实施例十一提供的保护应用程序数据的装置的结构示意图；

图11-b是本发明实施例十二提供的保护应用程序数据的装置的结构示意图；

图11-c是本发明实施例十三提供的保护应用程序数据的装置的结构示意图；

图11-d是本发明实施例十四提供的保护应用程序数据的装置的结构示意图。

具体实施方式

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

本发明实施例提供一种保护应用程序数据的方法，所述方法包括：接收系统发布的告警信息，所述告警信息至少包括即将被杀死的进程的标识；判断所述将被杀死的进程是否为当前进程；若所述将被杀死的进程为所述当前进程，则对所述当前进程对应的应用程序的数据进行保护；在重启所述应用程序时，根据所述施行的保护数据恢复所述应用程序的运行。本发明实施例还提供相应的保护应用程序数据的装置。以下分别进行详细说明。

请参阅附图1，是本发明实施例一提供的保护应用程序数据的方法的实现流程，其基于Low Memory Killer机制，主要包括以下步骤S101至步骤S104：

S101，接收系统发布的告警信息，所述告警信息至少包括即将被杀死的进程的标识。

在本实施例中，系统发布的告警信息可以是系统基于Low Memory Killer发布，即，系统发现当前内存不足，需要通过杀死某个或某些进行来释放内存。该告警信息除了包含即将被杀死的进程的标识(ID)之外，还可以包含即将被杀死的进程的名称和占用的内存大小等信息。

S102，判断将被杀死的进程是否为当前进程。

由于当前进程对应的应用程序可能对用户而言是不能或不宜中途终止的应用程序，例如，短信或QQ等即时通信应用程序，这一类的应用程序的突然终止会给用户带来不好的体验，因此，在本实施例中，需要对将被杀死的进程是否为当前进程进行判断。

S103，若步骤S102的判断结果是将被杀死的进程为当前进程，则对所述当前进程对应的应用程序的数据进行保护。

进程是应用程序的运行实例，也是应用程序的一次动态执行。若将被杀死的进程为当前进程，则对所述当前进程对应的应用程序的数据进行保护。例如，若当前进程对应的应用程序是短信，则对已经编辑好的短信内容、拟收件人等数据进行保护。再如，若当前进程对应的应用程序是流量监控，则对当前时刻以及截至当前时刻使用的流量等数据进行保护。

S104，在重启应用程序时，根据步骤S103施行的保护数据恢复所述应用程序的运行。

具体地，根据步骤S103施行的保护恢复所述应用程序的数据，可以是读取被保护数据，向应用程序的用户展示当前进程被杀死前所述应用程序的最后操作状态，然后，用户继续进行某种操作。例如，将已被编辑的短信数据恢复到短信编辑框中，用户在所恢复的短信数据基础上继续编辑短信。

从上述附图1示例的保护应用程序数据的方法可知，由于在杀死某个进程之前，通过告警信息的发布，对即将被杀死的进程是否是当前进程进行了判断；在判断将被杀死的进程为当前进程后，对当前进程对应的应用程序的数据进行了保护。因此，与现有技术提供的Low Memory Killer机制“粗暴地”杀死某个进程相比，本发明提供的方法使得即使在内存不足时，进程仍然能够不被滥杀，而是提前采取措施，有效地保护了正在运行的应用程序的数据，提高了用户的体验。

请参阅附图2，是本发明实施例二提供的保护应用程序数据的方法的实现流程，其基于Low Memory Killer机制，主要包括以下步骤S201至步骤S204：

S201，接收系统专门针对将被杀死的进程的事件通知。

在Low Memory Killer机制发生作用时，例如，通过对进程列表的监测，发现某个进程占用内存过大、级别较低，而系统的内存不足以支持另一个级别更高的进程，此时就需要杀死级别低、占用内存大的进程。本实施例中，进程接收系统专门针对将被杀死的进程(即该进程)的事件通知，例如，若视频播放的某个进程占用内存太多，系统会向该进程发送一个事件通知。进程接收到的事件通知也即系统通知该进程将被杀死；事件通知至少包含即将被杀死的进程的标识，以便让某个进程核对、判断是否是自己即将被杀死。

S202，判断将被杀死的进程是否为当前进程。

本实施例中，步骤S202的实现方法与实施例一的步骤S102的实现方法完全相同，其中相关表达式、术语和概念等的说明或解释具体可参阅对步骤S102的说明或解释，此处不做赘述。

S203，若步骤S202的判断结果是将被杀死的进程为当前进程，则对所述当前进程对应的应用程序的数据进行保护。

本实施例中，步骤S203的实现方法与实施例一的步骤S103的实现方法完全相同，其中相关表达式、术语和概念等的说明或解释具体可参阅对步骤S103的说明或解释，此处不做赘述。

S204，在重启应用程序时，根据步骤S203施行的保护恢复所述应用程序的数据。

具体地，根据步骤S203施行的保护恢复所述应用程序的数据，可以是读取被保护数据，向应用程序的用户展示当前进程被杀死前所述应用程序的最后操作状态，然后，用户继续进行某种操作。例如，将已被编辑的短信数据恢复到短信编辑框中，用户在所恢复的短信数据基础上继续编辑短信。

从上述附图2示例的保护应用程序数据的方法可知，由于在杀死某个进程之前，通过告警信息的发布，对即将被杀死的进程是否是当前进程进行了判断；在判断将被杀死的进程为当前进程后，对当前进程对应的应用程序的数据进行了保护。因此，与现有技术提供的Low Memory Killer机制“粗暴地”杀死某个进程相比，本发明提供的方法使得即使在内存不足时，进程仍然能够不被滥杀，而是提前采取措施，有效地保护了正在运行的应用程序的数据，提高了用户的体验。

请参阅附图3，是本发明实施例三提供的保护应用程序数据的方法的实现流程，其基于Low Memory Killer机制，主要包括以下步骤S301至步骤S304：

S301，接收系统的广播消息。

与前述附图2示例的步骤S201不同，本实施例中，在Low Memory Killer机制发生作用时，系统不是针对某个进程发送一个事件通知，而是向当前所有的进程广播一个消息，该广播消息至少包括即将被杀死的进程的标识，以便让收到广播消息的进程核对、判断是否是自己即将被杀死。

需要说明的是，在Low Memory Killer机制需要杀死多个进程时，通过向所有进程发送一个广播消息要比对每个进程逐个发送事件通知的效率要高。

S302，判断将被杀死的进程是否为当前进程。

本实施例中，步骤S202的实现方法与实施例一的步骤S102或实施例二的步骤S202的实现方法完全相同，其中相关表达式、术语和概念等的说明或解释具体可参阅对步骤S102或步骤S202的说明或解释，此处不做赘述。

S203，若步骤S202的判断结果是将被杀死的进程为当前进程，则对所述当前进程对应的应用程序的数据进行保护。

本实施例中，步骤S303的实现方法与实施例一的步骤S103或实施例二的步骤S203的实现方法完全相同，其中相关表达式、术语和概念等的说明或解释具体可参阅对步骤S103或步骤S203的说明或解释，此处不做赘述。

S304，在重启应用程序时，根据步骤S303施行的保护恢复所述应用程序的数据。

具体地，根据步骤S303施行的保护恢复所述应用程序的数据，可以是读取被进行保护的数据，向应用程序的用户展示当前进程被杀死前所述应用程序的最后操作状态，然后，用户继续进行某种控制操作。例如，将已被编辑的短信数据恢复到短信编辑框中，用户在所恢复的短信数据基础上继续编辑短信。

从上述附图3示例的保护应用程序数据的方法可知，由于在杀死某个进程之前，通过告警信息的发布，对即将被杀死的进程是否是当前进程进行了判断；在判断将被杀死的进程为当前进程后，对当前进程对应的应用程序的数据进行了保护。因此，与现有技术提供的Low Memory Killer机制“粗暴地”杀死某个进程相比，本发明提供的方法使得即使在内存不足时，进程仍然能够不被滥杀，而是提前采取措施，有效地保护了正在运行的应用程序的数据，提高了用户的体验。

请参阅附图4，是本发明实施例四提供的保护应用程序数据的方法的实现流程，其基于Low Memory Killer机制，主要包括以下步骤S401至步骤S405：

S401，接收系统发布的告警信息，所述告警信息至少包括即将被杀死的进程的标识。

本实施例中，步骤S401的实现方法与实施例一的步骤S101的实现方法完全相同，其中相关表达式、术语和概念等的说明或解释具体可参阅对步骤S101的说明或解释，此处不做赘述。

S402，将即将被杀死的进程的标识与当前进程的标识进行对比。

S403，若即将被杀死的进程的标识与当前进程的标识相同，则确定将被杀死的进程为当前进程。

S404，若步骤S402至步骤S403的判断结果是将被杀死的进程为当前进程，则对所述当前进程对应的应用程序的数据进行保护。

本实施例中，步骤S404的实现方法与实施例一的步骤S103、实施例二的步骤S203或者实施例三的步骤S303的实现方法完全相同，其中相关表达式、术语和概念等的说明或解释具体可参阅对步骤S103、步骤S203或者步骤S303的说明或解释，此处不做赘述。

S405，在重启应用程序时，根据步骤S404施行的保护恢复所述应用程序的数据。

具体地，根据步骤S404施行的保护恢复所述应用程序的数据，可以是读取被保护数据，向应用程序的用户展示当前进程被杀死前所述应用程序的最后操作状态，然后，用户继续进行某种操作。例如，将已被编辑的短信数据恢复到短信编辑框中，用户在所恢复的短信数据基础上继续编辑短信。

从上述附图4示例的保护应用程序数据的方法可知，由于在杀死某个进程之前，通过告警信息的发布，对即将被杀死的进程是否是当前进程进行了判断；在判断将被杀死的进程为当前进程后，对当前进程对应的应用程序的数据进行了保护。因此，与现有技术提供的Low Memory Killer机制“粗暴地”杀死某个进程相比，本发明提供的方法使得即使在内存不足时，进程仍然能够不被滥杀，而是提前采取措施，有效地保护了正在运行的应用程序的数据，提高了用户的体验。

请参阅附图5，是本发明实施例五提供的保护应用程序数据的方法的实现流程，其基于Low Memory Killer机制，主要包括以下步骤S501至步骤S504：

S501，接收系统发布的告警信息，所述告警信息至少包括即将被杀死的进程的标识。

本实施例中，步骤S501的实现方法与实施例一的步骤S101或实施例四的步骤S401的实现方法完全相同，其中相关表达式、术语和概念等的说明或解释具体可参阅对步骤S101或步骤S401的说明或解释，此处不做赘述。

S502，判断将被杀死的进程是否为当前进程。

本实施例中，步骤S502的实现方法与实施例一的步骤S102、实施例二的步骤S202或实施例三的步骤S302的实现方法完全相同，其中相关表达式、术语和概念等的说明或解释具体可参阅对步骤S102、步骤S202或步骤S302的说明或解释，此处不做赘述。

S503，将当前进程对应的应用程序的数据保存至外存储设备。

本实施例中，可以将当前进程对应的应用程序的数据保存至外存储设备，例如，数据库、硬盘或者网络硬盘等。

S504，在重启应用程序时，根据步骤S503施行的保护恢复所述应用程序的数据。

具体地，根据步骤S503施行的保护恢复所述应用程序的数据，可以是从外存储设备读取被保护数据，向应用程序的用户展示当前进程被杀死前所述应用程序的最后操作状态，然后，用户继续进行某种操作。例如，将已被编辑的短信数据恢复到短信编辑框中，用户在所恢复的短信数据基础上继续编辑短信。

从上述附图5示例的保护应用程序数据的方法可知，由于在杀死某个进程之前，通过告警信息的发布，对即将被杀死的进程是否是当前进程进行了判断；在判断将被杀死的进程为当前进程后，对当前进程对应的应用程序的数据进行了保护。因此，与现有技术提供的Low Memory Killer机制“粗暴地”杀死某个进程相比，本发明提供的方法使得即使在内存不足时，进程仍然能够不被滥杀，而是提前采取措施，有效地保护了正在运行的应用程序的数据，提高了用户的体验。

请参阅附图6，是本发明实施例六提供的保护应用程序数据的方法的实现流程，其基于Low Memory Killer机制，主要包括以下步骤S601至步骤S604：

S601，接收系统发布的告警信息，所述告警信息至少包括即将被杀死的进程的标识。

本实施例中，步骤S501的实现方法与实施例一的步骤S101、实施例四的步骤S401或者实施例五的步骤S501的实现方法完全相同，其中相关表达式、术语和概念等的说明或解释具体可参阅对步骤S101、步骤S401或者步骤S501的说明或解释，此处不做赘述。

S602，判断将被杀死的进程是否为当前进程。

本实施例中，步骤S602的实现方法与实施例一的步骤S102、实施例二的步骤S202、实施例三的步骤S302或实施例五的步骤S502的实现方法完全相同，其中相关表达式、术语和概念等的说明或解释具体可参阅对步骤S102、步骤S202、步骤S302或步骤S502的说明或解释，此处不做赘述。

S603，向应用程序用户提示当前进程即将被杀死，以使所述用户采取相应的保护措施。

与前述实施例的步骤S503直接将当前进程对应的应用程序的数据保存至外存储设备不同，本实施例中，是向应用程序用户提示当前进程即将被杀死，用户得到提示后，采取相应的保护措施，例如，将当前进程对应的应用程序的数据保存至外存储设备，等等。

S604，在重启应用程序时，根据步骤S603施行的保护恢复所述应用程序的数据。

具体地，根据步骤S603施行的保护恢复所述应用程序的数据，可以是从外存储设备读取被保护数据，向应用程序的用户展示当前进程被杀死前所述应用程序的最后操作状态，然后，用户继续进行某种操作。例如，将已被编辑的短信数据恢复到短信编辑框中，用户在所恢复的短信数据基础上继续编辑短信。

从上述附图6示例的保护应用程序数据的方法可知，由于在杀死某个进程之前，通过告警信息的发布，对即将被杀死的进程是否是当前进程进行了判断；在判断将被杀死的进程为当前进程后，对当前进程对应的应用程序的数据进行了保护。因此，与现有技术提供的Low Memory Killer机制“粗暴地”杀死某个进程相比，本发明提供的方法使得即使在内存不足时，进程仍然能够不被滥杀，而是提前采取措施，有效地保护了正在运行的应用程序的数据，提高了用户的体验。

请参阅附图7，是本发明实施例九提供的保护应用程序数据的装置的结构示意图，附图7示例的保护应用程序数据的装置可以是附图1至附图6示例的保护应用程序数据的方法的执行主体。为了便于说明，附图7仅示出了与本发明实施例相关的部分。附图7示例的保护应用程序数据的装置主要包括接收模块701、判断模块702、保护模块703和恢复模块704，各功能模块详细说明如下：

接收模块701，用于接收系统发布的告警信息，所述告警信息至少包括即将被杀死的进程的标识；

判断模块702，用于判断将被杀死的进程是否为当前进程；

保护模块703，用于若判断模块702的判断结果是将被杀死的进程为当前进程，则对所述当前进程对应的应用程序的数据进行保护；

恢复模块704，用于在重启应用程序时，根据保护模块703施行的保护恢复所述应用程序的数据。

需要说明的是，以上附图7示例的保护应用程序数据的装置的实施方式中，各功能模块的划分仅是举例说明，实际应用中可以根据需要，例如相应硬件的配置要求或者软件的实现的便利考虑，而将上述功能分配由不同的功能模块完成，即将所述保护应用程序数据的装置的内部结构划分成不同的功能模块，以完成以上描述的全部或者部分功能。而且，实际应用中，本实施例中的相应的功能模块可以是由相应的硬件实现，也可以由相应的硬件执行相应的软件完成。例如，前述的判断模块，可以是具有执行前述判断将被杀死的进程是否为当前进程的硬件，例如判断器，也可以是能够执行相应计算机程序从而完成前述功能的一般处理器或者其他硬件设备；再如前述的恢复模块，可以是执行在重启应用程序时，根据保护模块(或保护器)施行的保护恢复所述应用程序的数据的硬件，例如恢复器，也可以是能够执行相应计算机程序从而完成前述功能的一般处理器或者其他硬件设备(本说明书提供的各个实施例都可应用上述描述原则)。

附图7示例的接收模块701可以包括通知接收单元801或广播接收单元802，如附图8所示本发明实施例八提供的保护应用程序数据的装置，其中：

通知接收单元801，用于接收系统专门针对将被杀死的进程的事件通知，该事件通知至少包括所述即将被杀死的进程的标识；

广播接收单元802，用于接收系统的广播消息，所述广播消息至少包括即将被杀死的进程的标识。

附图7示例的判断模块702可以包括对比单元901和确定单元902，如附图9所示本发明实施例九提供的保护应用程序数据的装置，其中：

对比单元901，用于将即将被杀死的进程的标识与当前进程的标识进行对比；

确定单元902，用于若即将被杀死的进程的标识与当前进程的标识相同，则确定所述将被杀死的进程为所述当前进程。

附图7示例的保护模块703可以包括保存单元1001或提示单元1002，如附图10所示本发明实施例十提供的保护应用程序数据的装置，其中：

保存单元1001，用于将当前进程对应的应用程序的数据保存至外存储设备；

提示单元1002，用于向应用程序用户提示当前进程即将被杀死，以使所述用户采取相应的保护措施。

附图7至附图10示例的恢复模块704可以包括数据读取单元1101和状态展示单元1102，如附图11-a至附图11-d所示本发明实施例十一至实施例十四提供的保护应用程序数据的装置，其中：

数据读取单元1101，用于读取被保护数据；

状态展示单元1102，用于向应用程序的用户展示所述当前进程被杀死前所述应用程序的最后操作状态。

需要说明的是，上述装置各模块/单元之间的信息交互、执行过程等内容，由于与本发明方法实施例基于同一构思，其带来的技术效果与本发明方法实施例相同，具体内容可参见本发明方法实施例中的叙述，此处不再赘述。

本领域普通技术人员可以理解上述实施例的各种方法中的全部或部分步骤是可以通过程序来指令相关的硬件来完成，该程序可以存储于一计算机可读存储介质中，存储介质可以包括：只读存储器(ROM，Read Only Memory)、随机存取存储器(RAM，RandomAccess Memory)、磁盘或光盘等。

以上对本发明实施例所提供的一种保护应用程序数据的方法和装置进行了详细介绍，本文中应用了具体个例对本发明的原理及实施方式进行了阐述，以上实施例的说明只是用于帮助理解本发明的方法及其核心思想；同时，对于本领域的一般技术人员，依据本发明的思想，在具体实施方式及应用范围上均会有改变之处，综上所述，本说明书内容不应理解为对本发明的限制。

Claims (8)

1.一种保护应用程序数据的方法，其特征在于，所述方法包括：

接收系统发布的告警信息，所述告警信息至少包括即将被杀死的进程的标识；所述接收系统发布的告警信息，包括：接收系统专门针对所述将被杀死的进程的事件通知；或者，接收系统的广播消息，使收到广播消息的进程核对、判断是否是自己即将被杀死；所述事件通知至少包括所述即将被杀死的进程的标识，所述广播消息至少包括所述即将被杀死的进程的标识；

判断所述将被杀死的进程是否为当前进程；

若所述将被杀死的进程为所述当前进程，则对所述当前进程对应的应用程序的数据进行保护；

在重启所述应用程序时，根据所述施行的保护恢复所述应用程序的数据；

所述对所述当前进程对应的应用程序的数据进行保护，包括：

将所述当前进程对应的应用程序的数据保存至外存储设备。

2.如权利要求1所述的方法，其特征在于，所述判断所述将被杀死的进程是否为当前进程，包括：

将所述即将被杀死的进程的标识与所述当前进程的标识进行对比；

若所述即将被杀死的进程的标识与所述当前进程的标识相同，则确定所述将被杀死的进程为所述当前进程。

3.如权利要求1所述的方法，其特征在于，所述对所述当前进程对应的应用程序的数据进行保护，包括：

向所述应用程序用户提示所述当前进程即将被杀死，以使所述用户采取相应的保护措施。

4.如权利要求1至3任意一项所述的方法，其特征在于，所述根据所述施行的保护恢复所述应用程序的数据，包括：

读取所述被进行保护的数据；

向所述应用程序的用户展示所述当前进程被杀死前所述应用程序的最后操作状态。

5.一种保护应用程序数据的装置，其特征在于，所述装置包括：

接收模块，用于接收系统发布的告警信息，所述告警信息至少包括即将被杀死的进程的标识；所述接收模块包括：通知接收单元，用于接收系统专门针对所述将被杀死的进程的事件通知；或者，广播接收单元，用于接收系统的广播消息，使收到广播消息的进程核对、判断是否是自己即将被杀死；所述事件通知至少包括所述即将被杀死的进程的标识，所述广播消息至少包括所述即将被杀死的进程的标识；

判断模块，用于判断所述将被杀死的进程是否为当前进程；

保护模块，用于若所述判断模块的判断结果为所述将被杀死的进程是所述当前进程，则对所述当前进程对应的应用程序的数据进行保护；

恢复模块，用于在重启所述应用程序时，根据所述施行的保护恢复所述应用程序的数据；

所述保护模块包括：

保存单元，用于将所述当前进程对应的应用程序的数据保存至外存储设备。

6.如权利要求5所述的装置，其特征在于，所述判断模块包括：

对比单元，用于将所述即将被杀死的进程的标识与所述当前进程的标识进行对比；

确定单元，用于若所述即将被杀死的进程的标识与所述当前进程的标识相同，则确定所述将被杀死的进程为所述当前进程。

7.如权利要求5所述的装置，其特征在于，所述保护模块包括：

提示单元，用于向所述应用程序用户提示所述当前进程即将被杀死，以使所述用户采取相应的保护措施。

8.如权利要求5至7任意一项所述的装置，其特征在于，所述恢复模块包括：

数据读取单元，用于读取所述被进行保护的数据；

状态展示单元，用于向所述应用程序的用户展示所述当前进程被杀死前所述应用程序的最后操作状态。