CN103324500A - 一种回收内存的方法及装置 - Google Patents

Abstract

本发明实施例提供了一种回收内存的方法及装置，所述方法包括：确定应用程序在主界面启动后占用的初始内存值，以及所述应用程序退出所述主界面后占用的内存值，以及运行时长；如果所述内存值大于或等于所述初始内存值的百分之N，或所述运行时长达到预设回收时长，其中，40≤N≤90；则对所述应用程序占用的内存进行自动回收并重启所述应用程序。本发明实施例解决了现有技术中对切换至后台的应用软件占用的大量内存不能自动清理，导致系统运行缓慢，用户体验不高的技术问题。

Description

一种回收内存的方法及装置

技术领域

本发明涉及移动通信技术领域，特别涉及一种回收内存的方法及装置。

背景技术

现有技术中，Android平台上的应用程序启动后，在平常操作过程中会不停的开辟新的内存空间，但是，在大多数情况下无法在开辟新的内存空间后及时获得内存回收，特别是常驻内存需求的应用软件，如通讯录，安全方面等需要进行后台常驻的应用软件，即便是在从前台切换至后台时，应用软件主动对图片,UI数据进行释放，但是，由于Android内存管理由系统决定，至于何时对该应用的进行垃圾回收的时机是无法预知的，因此，类似于通讯录这类需要常驻内存的应用软件，在使用过程中占用的内存会越来越大，即便用户已经不需要使用该应用软件时，该应用软件仍然会占用大量的内存空间，通常都是用户进行人工清理，或者用户通过管理软件进行清理。

发明人在对现有技术的研究过程中发现，对于切换至后台的应用软件，该应用软件程序仍然会占用大量的内存空间，系统不能自动对该内存进行清理，从而导致系统运行越来越慢，不但增加了耗电量，还降低了用户的体验。

发明内容

本发明实施例中提供了一种回收内存的方法及装置，以解决现有技术中对切换至后台的应用软件占用的大量内存不能自动清理，导致系统运行缓慢，用户体验不高的技术问题。

为了解决上述技术问题，本发明实施例公开了如下技术方案：

第一方面提供了一种回收内存的方法，所述方法包括：

确定应用程序在主界面启动后占用的初始内存值，以及所述应用程序退出所述主界面后占用的内存值，以及运行时长；

如果所述内存值大于或等于所述初始内存值的百分之N，或所述运行时长达到预设回收时长，其中，40≤N≤90；则对所述应用程序占用的内存进行自动回收并重启所述应用程序。

在第一方面的第一种可能的实现方式中，所述确定应用程序在主界面启动后占用的初始内存值，以及应用程序退出所述主界面后占用的内存值，以及运行时长，包括：

记录所述应用程序在主界面启动后占用的初始内存值以及初始运行时间；以及

记录所述应用程序退出所述主界面后占用的内存值，以及暂停运行时间；

计算所述应用程序的初始运行时间与暂停运行时间之差，得到所述应用程序的运行时长。

结合第一方面或第一方面的第一种可能的实现方式，在第二种可能的实现方式中，所述方法还包括：

判断所述应用程序退出所述主界面后的时间是否超过预设时间；或者判断是否接收到屏幕变黑事件；

如果所述应用程序退出所述主界面后的时间超过预设时间，或者接收到屏幕变黑事件，则判断所述内存值是否大于初始内存值的百分之N，或所述运行时长是否达到预设回收时长；

如果所述内存值大于初始内存值的百分之N，或所述运行时长达到预设回收时长，则执行所述对所述应用程序占用的内存进行自动回收并重启所述应用程序的步骤。

结合第一方面或第一方面的第一种或第二种可能的实现方式，在第三种可能的实现方式中，所述对所述应用程序占用的内存进行自动回收并重启所述应用程序，包括：

所述应用程序将运行时反序列化到内存中的业务数据序列化到文件中；

所述应用程序的主进程启动所述应用程序的守护进程；

所述主进程在启动守护进程后，调用系统接口进行自我摧毁；

所述守护进程在所述主进程调用系统接口进行自我摧毁后，唤醒所述主进程；

所述主进程在启动后，将所述文件中的业务数据反序列化到内存中。

结合第一方面或第一方面的第一种或第二种或第三种可能的实现方式，在第四种可能的实现方式中，

所述应用程序的主进程启动所述应用程序的守护进程包括：所述应用程序的主进程通过广播消息启动所述应用程序的守护进程；

所述守护进程在所述主进程自我摧毁后，唤醒所述主进程包括：在所述主进程自我摧毁后，利用所述守护进程通过所述广播消息唤醒所述主进程；

其中，所述广播消息包括：安卓android参数，用于指示所述守护进程唤醒摧毁后的所述主进程。

第二方面提供了一种回收内存的装置，所述装置包括：

确定单元，用于确定应用程序在主界面启动后占用的初始内存值，以及所述应用程序退出所述主界面后占用的内存值，以及运行时长；

内存回收单元，用于在所述内存值大于或等于所述初始内存值的百分之N，或所述运行时长达到预设回收时长时，对所述应用程序占用的内存进行自动回收并重启所述应用程序，其中，40≤N≤90。

在第二方面的第一种可能的实现方式中，所述确定单元包括：

第一记录单元，用于记录所述应用程序在主界面启动后的占用的初始内存值以及初始运行时间；以及

第二记录单元，用于记录所述应用程序退出所述主界面后占用的内存值，以及暂停运行时间；

计算单元，用于计算初始运行时间与暂停运行时间之差，得到所述应用程序的运行时长。

结合第二方面或第二方面的第一种可能的实现方式，在第二种可能的实现方式中，还包括：

第一判断单元，用于判断所述应用程序退出所述主界面后的时间是否超过预设时间；或者判断是否接收到屏幕变黑事件；

第二判断单元，用于在所述第一判断单元判断到所述应用程序退出所述主界面后的时间超过预设时间，或者判断接收到屏幕变黑事件，则判断所述内存值是否大于初始内存值的百分之N，或所述运行时长是否达到预设回收时长，并将所述内存值大于初始内存值的百分之N，或所述运行时长达到预设回收时长的判断结果发送给所述内存回收单元；

所述内存回收单元，还用于在接收所述判断单元发送的所述判断结果时，对所述应用程序占用的内存进行自动回收并重启所述应用程序。

结合第二方面或第二方面的第一种或第二种可能的实现方式，在第三种可能的实现方式中，所述内存回收单元包括：

第一存储单元，用于在所述应用程序将运行时反序列化到内存中的业务数据序列化到文件中；

启动单元，用于通过所述应用程序的主进程启动所述应用程序的守护进程；

调用单元，用于在启动所述守护进程后，调用系统接口进行自我摧毁；

唤醒单元，用于在所述主进程自我摧毁后，所述守护进程唤醒所述主进程；

第二存储单元，用于在所述主进程启动后，将所述文件中的业务数据反序列化到内存中。

结合第二方面或第二方面的第一种或第二种或第三种可能的实现方式，在第四种可能的实现方式中，

所述启动单元，具体用于利用所述应用程序的主进程通过广播消息启动所述应用程序的守护进程；其中，所述广播消息包括：安卓android参数，用于指示所述守护进程唤醒摧毁后的所述主进程；

所述唤醒单元，具体在所述主进程自我摧毁后，利用所述守护进程通过所述广播消息唤醒所述主进程。

由上述技术方案可知，本发明实施例在保证常驻应用程序原有业务的正常运行及效率不变的情况下，大幅度的降低了应用程序所占用的内存，提高了系统的运行速度，降低了耗电量以及用户的体验。

附图说明

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

图1为本发明实施例提供的一种回收内存的方法的流程图；

图2为本发明实施例提供的一种回收内存的方法的应用实例的流程图；

图3为本发明实施例提供的一种回收内存的装置的结构示意图；

图4为本发明实施例提供的一种采用自杀机制前的几项应用数据占用内存的示意图；

图5为本发明实施例提供的一种采用自杀机制后的几项应用数据占用内存的示意图；

图6为本发明实施例提供的一种第三方耗电榜上几项应用的耗电量的示意图。

具体实施方式

下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整的描述，显然，所描述的实施例仅仅是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。

为了便于理解，在介绍本发明技术方案之前，先介绍下述技术术语：

“自杀”：指应用程序通过特定方式进行自我摧毁并重启。

"主进程"：应用程序运行的主进程；一个应用程序至少包括一个主进程和一个子进程（即守护进程）

“守护进程”：用于主进程自杀后复活的子进程；即守护进程用于唤醒自杀后的主进程；

“广播消息”：用于主进程与守护进程之间消息通信。

请参阅图1，图1为本发明实施例提供的一种回收内存的方法的流程图；所述方法包括：

步骤101：确定应用程序在主界面启动后占用的初始内存值，以及所述应用程序退出所述主界面后占用的内存值，以及运行时长；

其中，该步骤中，应用程序在主界面（即前台）序启动后，应用程序记录启动后所占用的初始内存值以及初始运行时间，以及，该应用程序退出所述主界面（即该应用程序切换至后台，或者黑屏时）后占用的内存值，以及该应用程序切换至后台后（即待机状态）的暂停运行时间；之后，计算该应用程序的初始运行时间与暂停运行时间之差，得到所述应用程序的运行时长。

其中，在该应用程序启动后，记录该应用程序的初始内存值以及初始运行时间，以及该应用程序切换至后台后暂停运行时间，并计算得到所述应用程序的运行时长。是为了便于后续该应用程序切换至后台或黑屏后后，作为回收其所占用内存的回收判断条件。

步骤102：如果所述内存值大于或等于所述初始内存值的百分之N，或所述运行时长达到预设回收时长，其中，40≤N≤90；则对所述应用程序占用的内存进行自动回收并重启所述应用程序。

该步骤中，将所述应用程序退出所述主界面后占用的内存值与初始内存值进行对比，一种情况是，判断所述内存值是否大于或等于所述初始内存值的百分之N，其中，40≤N≤90，如果大于或等于，比如，大于或等于所述初始内存值的60%，65%、70%、75%或80%等，这种情况代表该应用程序占用的内存已经较大，存在较多无法及时回收的对象或系统资源，可以回收该应用程序所占用的内存了。另一种情况是，判断所述应用程序的运行时长是否达到了预设回收时长，其中，所述预设回收时长大于或等于6小时，小于等于48小时等，比如，可以是24小时，也可以是6小时，还可以是8小时等等，其具体的回收时长设定，可以根据终端设备内存的大小来设定，内存大，可以设定较长的回收时长，当然，也可以设置较短的回收时间；如果内存小点，可以设定较短的回收时间等。当然，如果内存特别小，设定的回收时长也可以小于6小时，但并不限于此。

其中，所述对所述应用程序占用的内存进行自动回收并重启所述应用程序，具体包括：当所述内存值大于或等于所述初始内存值的百分之N，或所述运行时长达到预设回收时长时即满足自杀条件，并进入自杀前，先保存现场，即所述应用程序将运行时反序列化到内存中的业务数据序列化到文件中；具体可以序列化的方式，但并不限于此；然后，所述应用程序的主进程启动所述应用程序的守护进程；具体可以通过广播消息启动所述应用程序的守护进程，其中，所述广播消息可以包括：安卓android参数，用于指示所述守护进程唤醒摧毁后的所述主进程；然后，所述主进程在启动守护进程后，调用系统接口进行自我摧毁；比如调用Process.killProcess(android.os.Process.myPid())等进行自我摧毁；然后，所述守护进程在所述主进程自我摧毁后，唤醒所述主进程；其唤醒的方式也可以是通过所述广播消息，该广播消息中包括安卓android参数；然后，所述主进程在启动（被唤醒）后，将所述文件中的业务数据反序列化到内存中，也就是将进入自杀前保存到所述文件的业务数据重新保存到内存中。

本发明实施例中，当应用程序切换至后台（即暂停运行）后所占用的内存达到一定值时，比如达到初始内存值的60%等，或者所述运行时长达到预设回收时长，比如该应用程序运行时间达到6小时，则对进入自杀机制，即对所述应用程序占用的内存进行自动回收并重启所述应用程序。也就是会所，保存现场（即保存当前运行的业务数据），杀死主进程，等待资源释放后，恢复主进程，即重启该应用程序。本发明实施例在保证常驻应用程序原有业务的正常运行及效率不变的情况下，大幅度的降低了应用程序所占用的内存，提高了系统的运行速度，降低了耗电量以及用户的体验。

可选，在另一实施例中，该实施例在上述实施例的基础上，所述方法还可以包括：判断所述应用程序退出所述主界面后的时间是否超过预设时间（其中，所述预设时间可以大于或等于7秒或者小于等于超过了15秒，通常情况下为10秒，但并不限于此）；或者判断是否接收到屏幕变黑事件；如果所述应用程序退出所述主界面后的时间超过预设时间后，或者接收到屏幕变黑事件，则判断所述内存值是否大于初始内存值的百分之N，或所述运行时是否长达到预设回收时长；如果所述内存值大于初始内存值的百分之N，或所述运行时长达到预设回收时长，则执行所述对所述应用程序占用的内存进行自动回收并重启所述应用程序的步骤。

也就是说，当应用程序切换至后台后的预设时间（比如大约10s左右）后或者接收到屏幕黑屏之后，触发自杀机制的判断条件，需要说明的是，如果切至后台的时间小于预设时间台（比如小于（10s内）再次进入主界面（前台），将取消本次自杀机制的判断，等待下次切至后台时再触发。

该实施例中，当所述应用程序切换到后台的预设时间内（比如10s左右等）时，保存现场，杀死主进程，等待资源释放（1s），恢复主进程，确切的说就是重启应用程序，只是保存了当前的运行现象。该方案在保证常驻应用原有业务的正常运行情况及效率不变情况下，使得用户在把应用切换至后台进行其他操作时候有更多的内存空间可使用。从而大幅度的降低应用内存占用。

还请参阅图2，图2为本发明实施例提供的一种回收内存的方法的应用实例的流程图，具体包括：

步骤201：应用程序启动；即应用程序在主界面启动。

步骤202：所述应用程序记录启动后占用的初始内存值和初始运行时间；

其中，所述初始内存值和初始运动时间用于切换至后台进行回收内存条件的判断。

其记录的方式，可以通过自身的计数器等来记录，当然，也可以通过其他方式来记录，本实施例不作限制。

步骤203：所述应用程序切换至后台；即所述应用程序退出主界面。

步骤204：所述应用程序记录切换至后台后所占用的内存值，以及切换至后台时的当前时间（即应用程序的暂停运行时间）；

步骤205：所述应用程序切换至后台预设时间（比如10秒等）内，或者接收到屏幕变黑事件（即黑屏）；

也就是所，当应用程序切换至后台后大约10s左右或者接收或检测到屏幕黑屏之后，触发进入自杀流程的判断，需要说明的是，如果在切至后台10s内再次进入主界面，将取消本次进入自杀流程的判断，等待下次切至后台时再触发。

步骤206：所述应用程序判断切换至后台后所占用的内存值是否达到所述初始内存值的百分之N，其中，40≤N≤90,，比如达到初始内存值的60%等，或者所述应用程序的运行时长是否达到预设回收时长，其中，预设回收时长大于或等于6小时，小于等于48小时；比如预设回收时长为6小时等；如果是，即所述内存值大于初始内存值的百分之N，或所述运行时长达到预设回收时长；执行步骤207；否则，步骤213：维持现状；

其中，所述应用程序的运行时长的计算方式为：应用程序的暂停运行时间与初始运行时间之差。

也就是说，一种情况是，在应用程序切换至后台后，根据当前所占用的内存值与初始内存值进行对比，看看是否当前所占的内存值是否已经比初始值大于某个值，比如60%等，如果是，则说明该应用程序占用内存已经较大，存在较多无法及时回收的对象或系统资源，可以进入自杀流程，进行大规模的内存回收。另一种情况，还可以判断所述应用程序的运行时长是否达到预设回收时长，如果达到，则说明该应用程序占用内存已经较大，存在较多无法及时回收的对象或系统资源，也可以进入自杀流程。

步骤207：启动自杀流程；

先进入自杀流程，然后启动自杀流程（即进行内存回收）。

步骤208：保存现场；即在进行自杀前，先将该应用程序运行时的业务数据从内存中序列化到文件中；

步骤209：所述应用程序的主进程通过广播消息启动所述应用程序的守护进程（也称为子进程）；

其中，所述广播消息中包括配置文件的安卓android参数，该android参数通过process指定即可，其中，android参数用于指示所述守护进程唤醒摧毁后的所述主进程；需要说明的是，android参数的功能是主进程和守护进程预先约定好的。

步骤210：所述主进程在通过广播消息启动守护进程后，主进程调用系统接口进行自我摧毁（即自杀）；

一种方式，可以通过Process.killProcess(android.os.Process.myPid())进行自杀，但并不限于此，还可以包括其他方式。

步骤211：守护进程收到该广播后，延时预设时间（比如1秒）再通过广播唤醒所述主进程；

其中，该实施例中，主进程广播的接收者（守护进程）要与主进程配有相同的android：process。另外，本实施例中，延时预设时间（比如1秒）是为了确保主进程调用自杀接口后，系统能够比较充足时间的杀死主进程。

步骤212：所述主进程收到来自守护进程的广播就会启动起来，并进行现场恢复；即把一些序列化到文件的业务数据等反序列化回内存，至此自杀流程结束。

本发明实施例在保证常驻应用程序原有业务的正常运行情况及效率不变情况下，大幅度的降低应用内存占用，并提供一种可以强制进行内存回收的方式，使得用户在把应用程序切换至后台进行其他操作时候有更多的内存空间可使用，同时，也减低了耗电量。

基于上述方法的实现过程，本发明实施例还提供一种回收内存的装置，其结构示意图如图3所示，所述回收内存的装置包括：确定单元31和内存回收单元32，其中，所述确定单元31，用于确定应用程序在主界面启动后占用的初始内存值，以及所述应用程序退出所述主界面后占用的内存值，以及运行时长；所述内存回收单元32，用于在所述内存值大于或等于所述初始内存值的百分之N，或所述运行时长达到预设回收时长时，对所述应用程序占用的内存进行自动回收并重启所述应用程序，其中，40≤N≤90。

可选的，所述确定单元包括：第一记录单元，第二记录单元和计算单元，其中，所述第一记录单元，用于记录所述应用程序在主界面启动后的占用的初始内存值以及初始运行时间；以及所述第二记录单元，用于记录所述应用程序退出所述主界面后占用的内存值，以及暂停运行时间；所述计算单元，用于计算初始运行时间与暂停运行时间之差，得到所述应用程序的运行时长。

可选的，在上述实施例的基础上，所述装置还可以包括：第一判断单元和第二判断单元，其中，所述第一判断单元，用于判断所述应用程序退出所述主界面后的时间是否超过预设时间；或者判断是否接收到屏幕变黑事件；所述第二判断单元，用于在所述第一判断单元判断到所述应用程序退出所述主界面后的时间超过预设时间，或者判断接收到屏幕变黑事件，则判断所述内存值是否大于初始内存值的百分之N，或所述运行时长是否达到预设回收时长，并将所述内存值大于初始内存值的百分之N，或所述运行时长达到预设回收时长的判断结果发送给所述内存回收单元；所述内存回收单元，还用于在接收所述判断单元发送的所述判断结果时，对所述应用程序占用的内存进行自动回收并重启所述应用程序。

可选的，在上述实施例的基础上，所述内存回收单元包括：第一存储单元，启动单元，调用单元，唤醒单元和第二存储单元，其中，所述第一存储单元，用于在所述应用程序将运行时反序列化到内存中的业务数据序列化到文件中；所述启动单元，用于通过所述应用程序的主进程启动所述应用程序的守护进程；所述调用单元，用于在启动所述守护进程后，调用系统接口进行自我摧毁；所述唤醒单元，用于在所述主进程自我摧毁后，所述守护进程唤醒所述主进程；所述第二存储单元，用于在所述主进程启动后，将所述文件中的业务数据反序列化到内存中。

其中，所述启动单元，具体用于利用所述应用程序的主进程通过广播消息启动所述应用程序的守护进程；其中，所述广播消息包括：安卓android参数，用于指示所述守护进程唤醒摧毁后的所述主进程；

所述唤醒单元，具体在所述主进程自我摧毁后，利用所述守护进程通过所述广播消息唤醒所述主进程。

所述装置中各个单元的功能和作用的实现过程详见上述方法中对应步骤的实现过程，在此不再赘述。

本发明实施例在保证常驻应用程序原有业务的正常运行情况及效率不变情况下，大幅度的降低应用内存占用，并提供一种可以强制进行内存回收的方式，使得用户在把应用程序切换至后台进行其他操作时候有更多的内存空间可使用，同时，也减低了耗电量。

本发明实施例中，由于降低了后台待机应用程序占用内存，进一步减少了应用程序被系统主动回收的情况，因为在很多情况下，系统强制回收进程后，该进程不会被系统重启。特别在Android4.0以上，很多情况下进程被杀，就不会再获得唤醒机会，故减少应用程序在后台待机时内存占用将能进一步解决在4.0以上rom频繁被杀导致启动慢的问题。

本发明实施例中，由于采用了自杀机制降低了常驻内存占用，耗电量也会相应降低，另外应用的耗电量将无法被第三方软件统计出来，耗电排行榜上面，应用排行将会很低，使得在用户角度上，认为该应用是低内存占用，低功耗的，从而能够一定层面带来正体验。

对于像通讯录，或者安全软件，必须24小时挂机在后台运行的软件来讲，由于业务原因，必须长时间占用系统内存块，且由于运行时间长，在程序设计带来的内存泄露问题会随着时间越来越明显，再好的程序也难以保证不出现内存泄露的情况，且android是基于java作为主语言，内存管理更困难，更容易出现内存泄露的情况，且由于业务特殊性，需要长时间与系统接口打交道，有各种特殊情况可能导致因调用系统接口带来各种无法回收的内存占用，当越积越大时候，容易导致应用直接被系统杀掉，该结果是很多程序很多内存没有被序列化就直接被系统清空，导致记录/或其他结果丢失，且很多情况下，不会被系统再次重启。另外由于长时间运行，本身就容易被第三方耗电软件监测出来，为了避免用户通过类似安全大师等第三方软件查出应用的耗电占用，适时的自我进行重启，能有效解决耗电排行问题，在“负体验”上影响降至最低。

为了便于本领域技术人员的理解，下面以具体的实例来说明。

本实施例以来电通4.4版本采用了自杀机制为例。在主流的2.3及4.0以上Android固件版本中，通过自杀，把切至后台后原本一直居高不下的内存进行大幅度压缩，使得在自杀后内存占用回归初始占用值，比如360通讯录,QQ通讯录占用更低。其具体的实现与上述流程相同。主要是该应用切至后台时判断其当前内存是否已经增长到满足自杀条件或运行时长是否已经达到预设回收时长来决定是否进行自我回收，从而有效降低切换至后台应用占用的内存。

还请参阅图4和图5，图4为本发明实施例提供的一种采用自杀机制前几项应用数据占用内存的示意图；图5为本发明实施例提供的一种采用自杀机制后几项应用数据占用内存的示意图。

其中，图4和图5中的数据均通过第三方内存监控软件检测得到。从两幅图中数据占用内存的值可知，比如，自杀前，切换至后台后来电通占用的内存值最大，即43.58MB,如图4所示，而采用本发明实施例所述技术方案进行自杀后，其来电通占用的内存值降低至25.98MB，也就是说，自杀后，回收了17.6MB的内存。而其他的几项应用占用的内存，不再一一举例说明。

还请参阅表1和表2，表1和表2为本发明实施例提供通过prorank linux层指令检测出的结果。

其中，表1的数据分别为应用程序运行一段时间，切至后台后占用的内存值。

表2中的数据为采用本发明实施例提供的自杀机制回收部分内存后该应用占用的内存值。

表1和表2中，分别以四个属性Vss Rss Pss Uss为例来说明。

所述Vss：虚拟耗用内存（Virtual Set Size），包含共享库占用的内存；

所述Rss：实际使用物理内存（Resident Set Size），包含共享库占用的内存；

所述Pss：实际使用的物理内存（Proportional Set Size），比例分配共享库占用的内存；

所述Uss：进程独自占用的物理内存（Unique Set Size），不包含共享库占用的内存。

 通常情况下，观察Uss来反映一个Process的内存使用情况，Uss的大小代表了只属于本进程正在使用的内存大小，这些内存在此Process被杀掉之后，会被完整的回收掉。

                           表1

该表1中的com.blovestorm对应的就是来电通在经过用户一般操作，并运行一段时间后，切至后台的数据。有Uss对应项可见，其当前内存达到45.6M。

采用本发明实施例提供的内存回收方法后，即重启并把必要内存反序列化回来之后，如表2所示。       表2

可见，本发明实施例中，在能保证必要业务正常的情况下。通过自杀机制，能把来电通后台时候内存占用降至启动值24.9M左右，而且这个时候已经把所有必需的数据通过反序列化等方式还原到内存。中间能腾出接近80%的内存回收。

上述在4.0机型上测试。因rom不同或有差异。2.3系列节省的相对小些，但也将近30%左右内存回收。

另外，由于满足自杀机制的应用程序进行自我销毁后，也降低了内存的占用，同时也降低了该应用的耗电量，具体如图6所示，图6为本发明实施例提供一种第三方耗电榜上几项应用的耗电量的示意图，该图6中以降低了来电通的实际耗电情况为例。

需要说明的是，在本文中，诸如第一和第二等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来，而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、物品或者设备中还存在另外的相同要素。

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

以上所述仅是本发明的优选实施方式，应当指出，对于本技术领域的普通技术人员来说，在不脱离本发明原理的前提下，还可以作出若干改进和润饰，这些改进和润饰也应视为本发明的保护范围。

Claims (10)

1.一种回收内存的方法，其特征在于，包括：

确定应用程序在主界面启动后占用的初始内存值，以及所述应用程序退出所述主界面后占用的内存值，以及运行时长；

如果所述内存值大于或等于所述初始内存值的百分之N，或所述运行时长达到预设回收时长，其中，40≤N≤90；则对所述应用程序占用的内存进行自动回收并重启所述应用程序。

2.根据权利要求1所述的方法，其特征在于，所述确定应用程序在主界面启动后占用的初始内存值，以及应用程序退出所述主界面后占用的内存值，以及运行时长，包括：

记录所述应用程序在主界面启动后占用的初始内存值以及初始运行时间；以及

记录所述应用程序退出所述主界面后占用的内存值，以及暂停运行时间；

计算所述应用程序的初始运行时间与暂停运行时间之差，得到所述应用程序的运行时长。

3.根据权利要求1所述的方法，其特征在于，还包括：

判断所述应用程序退出所述主界面后的时间是否超过预设时间；或者判断是否接收到屏幕变黑事件；

如果所述应用程序退出所述主界面后的时间超过预设时间，或者接收到屏幕变黑事件，则判断所述内存值是否大于初始内存值的百分之N，或所述运行时长是否达到预设回收时长；

如果所述内存值大于初始内存值的百分之N，或所述运行时长达到预设回收时长，则执行所述对所述应用程序占用的内存进行自动回收并重启所述应用程序的步骤。

4.根据权利要求1至3任一项所述的方法，其特征在于，所述对所述应用程序占用的内存进行自动回收并重启所述应用程序，包括：

所述应用程序将运行时反序列化到内存中的业务数据序列化到文件中；

所述应用程序的主进程启动所述应用程序的守护进程；

所述主进程在启动守护进程后，调用系统接口进行自我摧毁；

所述守护进程在所述主进程调用系统接口进行自我摧毁后，唤醒所述主进程；

所述主进程在启动后，将所述文件中的业务数据反序列化到内存中。

5.根据权利要求4所述的方法，其特征在于，

所述应用程序的主进程启动所述应用程序的守护进程包括：所述应用程序的主进程通过广播消息启动所述应用程序的守护进程；

所述守护进程在所述主进程自我摧毁后，唤醒所述主进程包括：在所述主进程自我摧毁后，利用所述守护进程通过所述广播消息唤醒所述主进程；

其中，所述广播消息包括：安卓android参数，用于指示所述守护进程唤醒摧毁后的所述主进程。

6.一种回收内存的装置，其特征在于，包括：

确定单元，用于确定应用程序在主界面启动后占用的初始内存值，以及所述应用程序退出所述主界面后占用的内存值，以及运行时长；

内存回收单元，用于在所述内存值大于或等于所述初始内存值的百分之N，或所述运行时长达到预设回收时长时，对所述应用程序占用的内存进行自动回收并重启所述应用程序，其中，40≤N≤90。

7.根据权利要求6所述的装置，其特征在于，所述确定单元包括：

第一记录单元，用于记录所述应用程序在主界面启动后的占用的初始内存值以及初始运行时间；以及

第二记录单元，用于记录所述应用程序退出所述主界面后占用的内存值，以及暂停运行时间；

计算单元，用于计算初始运行时间与暂停运行时间之差，得到所述应用程序的运行时长。

8.根据权利要求6所述的装置，其特征在于，还包括：

第一判断单元，用于判断所述应用程序退出所述主界面后的时间是否超过预设时间；或者判断是否接收到屏幕变黑事件；

第二判断单元，用于在所述第一判断单元判断到所述应用程序退出所述主界面后的时间超过预设时间，或者判断接收到屏幕变黑事件，则判断所述内存值是否大于初始内存值的百分之N，或所述运行时长是否达到预设回收时长，并将所述内存值大于初始内存值的百分之N，或所述运行时长达到预设回收时长的判断结果发送给所述内存回收单元；

所述内存回收单元，还用于在接收所述判断单元发送的所述判断结果时，对所述应用程序占用的内存进行自动回收并重启所述应用程序。

9.根据权利要求6至8任一项所述的装置，其特征在于，所述内存回收单元包括：

第一存储单元，用于在所述应用程序将运行时反序列化到内存中的业务数据序列化到文件中；

启动单元，用于通过所述应用程序的主进程启动所述应用程序的守护进程；

调用单元，用于在启动所述守护进程后，调用系统接口进行自我摧毁；

唤醒单元，用于在所述主进程自我摧毁后，所述守护进程唤醒所述主进程；

第二存储单元，用于在所述主进程启动后，将所述文件中的业务数据反序列化到内存中。

10.根据权利要求9所述的装置，其特征在于，

所述启动单元，具体用于利用所述应用程序的主进程通过广播消息启动所述应用程序的守护进程；其中，所述广播消息包括：安卓android参数，用于指示所述守护进程唤醒摧毁后的所述主进程；

所述唤醒单元，具体在所述主进程自我摧毁后，利用所述守护进程通过所述广播消息唤醒所述主进程。

Images