CN114020652B - 一种应用程序的管理方法及电子设备 - Google Patents

Abstract

本申请实施例提供一种应用程序的管理方法，包括：在应用程序运行过程中，监测图形缓冲区的申请结果；若图像缓冲区的申请结果为申请失败，则根据申请结果分析失败类型；若失败类型为内存映射失败，则获取应用程序的虚拟内存占用情况；若应用程序占用的虚拟内存超过预设阈值，则启动所述应用程序的自杀恢复功能，以释放被该应用程序占用的内存，避免由于内存泄露导致系统崩溃、卡死等严重后果，减轻对用户使用的影响。

Description

一种应用程序的管理方法及电子设备

技术领域

本申请涉及电子领域，尤其涉及一种应用程序的管理方法及电子设备。

背景技术

内存泄露(memory leak)，是指应用程序中已动态分配的堆内存由于某种原因未释放或无法及时释放，造成系统内存的浪费的现象。

然而，由于内存泄露不是过错类错误，目前存在难检测、难定位的问题，最终就会导致内存溢出、应用程序运行异常甚至系统卡死等严重后果。

发明内容

本申请提供了一种应用程序的管理方法，可以避免目前由于内存泄漏导致的系统卡死的情况。

第一方面，提供了一种应用程序的管理方法，包括：在应用程序运行过程中，监测图形缓冲区的申请结果；若图像缓冲区的申请结果为申请失败，则根据申请结果分析失败类型；若失败类型为内存映射失败，则获取应用程序的虚拟内存占用情况；若应用程序占用的虚拟内存超过预设阈值，则启动所述应用程序的自杀恢复功能。

在应用程序运行过程中，为了绘制界面和保存绘制的数据，运行的进程会向系统内存申请图形缓冲区(graphicbuffer)。

示例性的，可以通过graphicbuffermapper申请进程间共享的图形缓冲区，也可以通过graphicbufferallocator进程接口申请应用程序使用的图形缓冲区。

由于向内存管理器申请图形缓冲区时有可能存在内存泄漏的情况，因此可以在应用程序的进程发起图形缓冲区申请时，启动内存申请监测功能来监测图形缓冲区的申请结果。

需要说明的是，也可以在应用程序开始运行时就启动内存申请监测功能，还可以实时获取应用程序的虚拟内存占用情况，在应用程序的虚拟内存占用超过某一数值时(这个数值可以根根据实际应用场景来设定，本申请对此不加以限制)，开启内存申请监测功能，还可以是在应用程序的虚拟内存占用超过某一数值且该应用程序的进程发起图形缓冲区申请时才启动内存申请监测功能，当然还可以在其他情况下启动内存申请监测功能。

示例性的，上述开启内存申请监测可以包括：用户主动开启内存申请监测功能的方式、电子设备自动开启内存申请监测功能的方式以及默认开启内存申请监测功能的方式。

上述图形缓冲区申请的申请结果包括申请成功和申请失败。

在系统可用内存满足该申请，且申请到的内存能够映射到该进程的虚拟内存的地址时，内存管理器会返回申请成功的结果。

在系统可用内存过少(申请的图形缓冲区占用的内存大于系统可用内存)、申请到的内存无法映射到进程的虚拟内存的地址中以及其他异常情况时，内存管理器会返回申请失败的结果。

其中，可以通过/proc/self/status函数来调出应用程序的虚拟内存占用情况。

其中，预设阈值可以根据应用程序来设置，例如对于32位的应用程序，上述预设阈值可以设置为3.7G。当然对于32位的应用程序，上述预设阈值可以设置为比3.7G低的某些数值，例如3.5G、3.2G等。

以上可以看出，通过监测应用程序的进程向系统内存申请图形缓冲区的情况，在内存申请失败且是由于虚拟内存占用过多的情况下，启动自杀恢复功能，以释放被该应用程序占用的内存，避免由于内存泄露导致系统崩溃、卡死等严重后果，减轻对用户使用的影响。

在第一方面的一种可能的实现方式中，上述若应用程序占用的虚拟内存超过预设阈值，则启动自杀恢复功能，包括：应用程序占用的虚拟内存超过预设阈值时，结束所述应用程序的所有进程。

在应用程序占用的虚拟内存超过预设阈值时，可以通过向进程管理器发送结束该应用程序的全部进程的命令，进程管理器响应于该命令，就会结束该应用程序的全部进程，释放被该应用程序占用的系统内存。

进程管理器中有系统当前正在运行的所有进程，通过进程管理器结束带有该应用程序名相关的所有进程，就能释放该应用程序占用的系统内存。

上述对应用程序的自动查杀可以是直接结束该应用程序的所有进程，此时，电子设备的显示界面会直接跳到显示电子设备的主屏幕界面，即用户感受到该应用程序闪退。直接结束该应用程序的所有进程，就能够释放出该应用程序占用的全部内存，避免内存泄漏导致的系统崩溃卡死等严重后果。

在第一方面的一种可能的实现方式中，上述若应用程序占用的虚拟内存超过预设阈值，则启动自杀恢复功能，包括：应用程序占用的虚拟内存超过预设阈值时，判断申请所述图形缓冲区的进程是否为所述应用程序的主进程；

若申请所述图形缓冲区的进程是否为所述应用程序的主进程，则结束应用程序的全部进程后重新拉起该应用程序的主进程；否则，结束所述应用程序的所有进程。

如果申请所述图形缓冲区的进程是该应用程序的主进程，那么电子设备显示的界面就是该应用程序的主显示界面，因此，在结束该应用程序的所有进程后自动拉起该应用程序的主进程，此时电子设备的显示界面会直接跳到该应用程序的主显示界面。

由于结束应用程序的进程后再次拉起该应用程序的主进程的间隔时间很短，因此用户对此无感知，只能感受到电子设备的显示界面又跳回该应用程序的主显示界面。此时用户不会感受到应用程序闪退，因此可以在释放被该应用程序占用的系统内存的同时避免对用户的使用造成影响，提升用户体验感。

在第一方面的一种可能的实现方式中，在所述在应用程序运行过程中，监测图形缓冲区的申请结果之后，还包括：

若图形缓冲区申请的申请结果为申请成功，则将申请到的内存映射到该进程的虚拟内存的地址中。

在图形缓冲区申请成功后(即系统将内存分配给该进程使用)，需要将该图形缓冲区映射到该进程对应的虚拟内存的地址空间中，该进程才能进行界面的显示绘制。

在第一方面的一种可能的实现方式中，上述应用程序的管理方法还包括：若失败类型不为内存映射失败，则输出与失败类型对应的异常日志。

上述申请失败时的失败类型可以包括系统可用内存过少、内存映射失败、其他异常情况等，此处不做限定。

在一些实施例中，电子设备可以根据内存管理器返回的申请结果来确定失败类型。例如可以通过分析申请结果对应的二进行编码来确定出失败类型。

示例性的，当申请结果包括两个字段，其中，第一个字段用于表示申请是否成功，第二个字段用于失败类型，表示读取第二字段的编码，并基于第二字段的编码就可以确定内存申请结果。

例如，申请结果为“01，001”，则读取第二字段的内容“001”，并根据预先确定的该编码对应的含义可知，失败类型为系统可用内存过少。又例如，申请结果为“01，010”，则读取到第二字段的内容为“010”，根据预先确定的编码对应的含义可知，失败类型为内存映射失败。

又示例性的，当申请结果只包含一个字段，其中该字段的第2位至第4位用于表示失败类型，则读取第二位至第四位的编码，基于第二位至第四位的编码确定内存申请的申请结果。

例如，申请结果为“1001”，则读取第2位至第四位的编码“001”，并根据预先确定的该编码对应的含义可知，失败类型为系统可用内存过少。又例如，申请结果为“1010”，则读取第2位至第4位的编码“010”，根据预先确定的该编码对应的含义可知，失败类型为内存映射失败。

又例如当申请结果返回为error并附带错误码时，可以通过错误码来确定失败类型。

由于失败类型不为内存映射失败，那么基本不会造成内存泄漏的情况，因此无需对应用程序进行任何操作，只需要输出与该失败类型对应的异常日志即可。

在一些实施例中，上述异常日志可以包括申请发起的进程名称、异常发生的时间和异常的内容等，异常的内容即包括申请图形缓冲区失败以及失败类型。示例性的，当失败类型为系统可用内存过少时，上述异常内容可以是A应用的B进程于xx时间由于系统内存过少申请图形缓冲区失败。

在一些实施例中，当失败类型是系统内存过少时，基于该异常日志，电子设备可以启动LMK机制。

在一些实施例中，上述异常日志可以保存在日志管理器中，电子设备可以通过日志管理器来读取该异常日志。

在第一方面的一种可能的实现方式中，上述应用程序的管理方法还包括：若应用程序占用的虚拟内存未超过预设阈值，则输出内存映射失败且虚拟内存未超过阈值的异常日志。

由于应用程序占用的虚拟内存未超过预设阈值，也就是说，这不会导致内存泄漏，因此无需对应用程序进行任何操作，只需要输出内存映射失败且虚拟内存未超过阈值的异常日志。

在第一方面的一种可能的实现方式中，上述应用程序的管理方法还包括：在结束所述应用程序的全部进程后，输出由于虚拟内存占用过高，结束所述应用程序的运行的异常日志。

以异常日志的形式记录由于虚拟内存占用过高，结束所述应用程序的运行的异常情况，便于用户查看。

第二方面，本申请实施例提供一种电子设备，包括：

监测模块，用于在应用程序运行过程中，监测图形缓冲区的申请结果；

分析模块，用于若图像缓冲区的申请结果为申请失败，则根据申请结果分析失败类型；

获取模块，用于若失败类型为内存映射失败，则获取应用程序的虚拟内存占用情况；

自杀恢复模块，用于若应用程序占用的虚拟内存超过预设阈值，则启动所述应用程序的自杀恢复功能。

第三方面，本申请实施例提供一种电子设备，包括存储器、处理器以及存储在存储器中并可在处理器上运行的计算机程序，处理器执行计算机程序时实现如上述第一方面任一项的方法。

第四方面，本申请实施例提供一种计算机可读存储介质，计算机可读存储介质存储有计算机程序，计算机程序被处理器执行时实现如上述第一方面任一项的方法。

第五方面，本申请实施例提供一种芯片系统，该芯片系统包括处理器，处理器与存储器耦合，处理器执行存储器中存储的计算机程序，以实现如上述第一方面任一项所述的方法。该芯片系统可以为单个芯片，或者多个芯片组成的芯片模组。

第六方面，本申请实施例提供一种计算机程序产品，当计算机程序产品在电子设备上运行时，使得电子设备执行上述第一方面任一项所述的方法。

可以理解的是，上述第二方面至第六方面的有益效果可以参见上述第一方面中的相关描述，在此不再赘述。

附图说明

图1是本申请实施例提供的内存泄漏导致应用程序显示异常的示例性示意图。

图2是本申请实施例提供的一种手机的硬件结构示意图。

图3是本申请实施例提供的一种手机的软件系统架构的示意图。

图4是本申请实施例提供的一些应用场景下的图形用户界面的示意图。

图5是本申请实施例提供的一些开启内存申请监测功能过程中的图形用户界面的示意图。

图6是本申请实施例提供的一种应用程序管理方法的实现流程示意图。

图7是本申请实施例提供的另一种应用程序管理方法的实现流程示意图。

具体实施方式

需要说明的是，本申请实施例的实施方式部分使用的术语仅用于对本申请的具体实施例进行解释，而非旨在限定本申请。在本申请实施例的描述中，除非另有说明，“/”表示或的意思，例如，A/B可以表示A或B；本文中的“和/或”仅仅是一种描述关联物的关联关系，表示可以存在三种关系，例如，A和/或B，可以表示：单独存在A，同时存在A和B，单独存在B这三种情况。另外，在本申请实施例的描述中，除非另有说明，“多个”是指两个或多于两个，“至少一个”、“一个或多个”是指一个、两个或两个以上。

以下，术语“第一”、“第二”仅用于描述目的，而不能理解为指示或暗示相对重要性或者隐含指明所指示的技术特征的数量。由此，限定有“第一”、“第二”特征可以明示或者隐含地包括一个或者更多个该特征。

在本说明书中描述的参考“一个实施例”或“一些实施例”等意味着在本申请的一个或多个实施例中包括结合该实施例描述的特定特征、结构或特点。由此，在本说明书中的不同之处出现的语句“在一个实施例中”、“在一些实施例中”、“在其他一些实施例中”、“在另外一些实施例中”等不是必然都参考相同的实施例，而是意味着“一个或多个但不是所有的实施例”，除非是以其他方式另外特别强调。术语“包括”、“包含”、“具有”及它们的变形都意味着“包括但不限于”，除非是以其他方式另外特别强调。

为更好地理解本申请实施例，以下对实施例中可能涉及的术语或概念进行介绍。

1.图形缓冲区(graphicbuffer)

用于应用程序的界面的显示绘制和保存显示绘制的数据。应用程序在运行过程中，需要先申请用于界面的显示绘制和保存显示绘制数据的图形缓冲区，具体的图形缓冲区可以从系统内存中分配，从系统内存中分配图形缓冲区后还需要将该图形缓冲区映射到该应用程序对应的虚拟内存的地址空间中，这样应用程序才可以正常运行。对于多进程的应用程序，每个进程在运行时都会先申请图形缓冲区，同样的，图形缓冲区申请成功后(即系统存在足够的内存分配给该进程使用)，需要将该图形缓冲区映射到该进程对应的虚拟内存的地址空间中，使得该进程可以正常运行。

2.垃圾回收(garbage collection，GC)机制

将不使用的对象进行清除和回收，以释放内存的一种机制。在应用程序卡顿，响应速度慢的时候(此时内存占用过高。示例性的，对于32位应用程序来说，内存占用超过3G就会被判定为内存占用过高)，虚拟机会触发垃圾回收(GC)机制。

3.低内存查杀(low memory killer，LMK)机制

一种Android系统的内存清理机制，系统定时检测应用程序的内存使用情况，在系统可用内存低时，触发LMK机制通过后台将优先级低的进程杀掉，以释放内存。具体地，通过进程的oom_adj值来判断进程的优先级，oom_adj值越小，则优先级越高，在触发LMK机制时该进程被杀掉的可能性越小。需要说明的是，前台进程的oom_adj值为0，即前台进程的优先级最高。

4.虚拟内存(virtual set size，VSS)

一个进程能访问的所有内存空间地址的大小。理论上，对于32位应用程序而言，最多能使用的虚拟内存为2³²，即4G。而实际应用中，系统会预留占用一小部分，因此一个对于32位应用程序而言，最多能使用的虚拟内存为3.7G，超过3.7G就会造成内存溢出。

5.内存溢出(out of memory，OOM)

系统中存在无法回收的内存或使用的内存过多，最终使得应用程序运行要用到的内存大于能提供的最大内存的现象，内存溢出的表现为应用程序的界面显示异常或应用程序闪退。

在软件系统中，由于图片、对象、线程、文件、视图等资源的不当使用，使得资源没有及时释放，就会导致内存泄露，进而引发应用程序内存溢出，导致应用程序卡死，甚至系统卡死的情况。内存泄露大部分情况下都是一个积累的过程，在出现问题之前不会有征兆，因此很难被发现和定位。

实际应用中，内存泄露会导致以下情况：

1.应用程序卡顿、响应速度慢，触发垃圾回收机制，导致应用程序无反应(application not responding，ANR)或应用程序闪退。

2.导致应用程序显示异常，应用程序的部分功能不可用等异常。

示例性的，图1中的(a)为没有出现内存泄露时，应用程序A正常显示时的显示界面的示意图，如图1中的(b)所示，上述应用程序A发生内存泄露时出现的显示异常可以表现为出现乱码的情况；又例如图1中的(c)所示，上述应用程序A发生内存泄露时出现的显示异常可以表现为显示不完整的情况；又例如图1中的(d)所示，上述应用程序A发生内存泄露时出现的显示异常可以表现为部分功能无显示的情况，此时该部分功能就处于不可用的异常状态。

3.系统崩溃、卡死等异常。

示例性的，当用户使用手机观看视频时，由于视频播放应用程序在播放视频的过程中，会持续申请内存且不释放，由于视频播放应用程序的最多能使用的虚拟内存是一定的，因此在达到该视频播放应用程序的虚拟内存的使用上限后，就无法将申请到的内存映射到该视频播放应用程序的虚拟内存中。与此同时，系统分配的内存会被标记为已使用，无法再分配给其他应用程序(进程)使用，而内存映射失败会导致应用程序继续向系统申请内存，由此导致内存泄露。而由于系统的可用内存低，因此会触发LMK机制，但是由于视频播放应用程序还在前台运行，因此其优先级较高，故该视频播放应用程序不会被杀进程，因此占用的内存也不会被释放，最终就会导致整个系统崩溃，卡死的异常情况。系统崩溃，卡死的时候需要用户强制重启手机才能恢复正常的使用，操作麻烦且会影响用户体验。

在实际应用中，很多应用程序都是32位的应用程序，而在向系统申请系统内存时应用程序会通过不断调用graphicbufferallocator进程接口来申请内存。32位应用程序所能用的最大虚拟内存是4G，然而由于graphicbufferallocator进程是64位进程，在应用程序的虚拟内存超过4G时，还可以成功向系统申请到系统内存，而由于应用程序的虚拟内存已经超过4G了，因此无法将申请到的内存映射到虚拟内存中，导致该系统内存被申请但无法被使用，也无法被释放。而且在内存映射失败后，应用程序还会继续通过调用graphicbufferallocator接口申请内存，导致内存持续泄露，最终导致系统崩溃、卡死的异常情况。

由以上说明可知，内存泄露一旦爆发问题，引发的情况是各种各样的，而且不易重现，也就是说内存泄露这个问题不好发现和解决，且内存泄露还会严重影响用户的使用。因而，如果能够在内存泄露导致异常情况的发生之前，先对可能导致内存泄露的应用程序进行处理，就能够避免出现系统崩溃、卡死等严重异常，减轻对用户使用的影响。

针对上述问题以及用户需求，本申请实施例提供了一种应用程序的管理方法，通过监测应用程序的进程向系统内存申请图形缓冲区的情况，在内存申请失败且是由于虚拟内存占用过多的情况下，启动自杀恢复功能，结束该应用程序的所有进程，以释放被该应用程序占用的内存，避免由于内存泄露导致系统崩溃、卡死等严重后果，减轻对用户使用的影响。

下面将结合附图对本申请实施例提供的应用程序的管理方法进行详细阐述，以下描述中，为了说明而不是为了限定，提出了诸如特定系统结构、技术之类的具体细节，以便透彻理解本申请实施例。

上述应用程序的管理方法的执行主体可以是电子设备，例如可以是手机、可穿戴设备(如智能手表、智能手环、智能眼镜、智能首饰等)、平板电脑、车载设备、增强现实(augmented reality，AR)/虚拟现实(virtual reality，VR)设备、笔记本电脑、超级移动个人计算机(ultra-mobile personal computer，UMPC)、上网本、个人数字助理(personaldigital assistant，PDA)以及其他具有网络连接功能的电子设备。

上述电子设备的示例性实施例包括但不限于搭载

鸿蒙系统(Harmony OS)或者其他操作系统的设备。上述电子设备也可以是其他电子设备，诸如具有触敏表面(例如触控面板)的膝上型计算机(laptop)等，本申请实施例对电子设备的具体类型不做任何限制。

以上述电子设备为手机为例，如图2所示，为本申请实施例提供的一种手机的结构示意图。

图2示出了手机100的结构示意图。手机100可以包括处理器110，外部存储器接口120，内部存储器121，通用串行总线(universal serial bus，USB)接口130，充电管理模块140，电源管理模块141，电池142，天线11，天线12，移动通信模块150，无线通信模块160，音频模块170，传感器模块180，按键190，马达191，指示器192，摄像头193，显示屏194，以及用户标识模块(subscriber identification module，SIM)卡接口195等。其中传感器模块180可以包括压力传感器180A，陀螺仪传感器180B，气压传感器180C，磁传感器180D，加速度传感器180E，距离传感器180F，接近光传感器180G，指纹传感器180H，温度传感器180J，触摸传感器180K，环境光传感器180L，骨传导传感器180M等。

可以理解的是，本发明实施例示意的结构并不构成对手机100的具体限定。在本申请另一些实施例中，手机100可以包括比图示更多或更少的部件，或者组合某些部件，或者拆分某些部件，或者不同的部件布置。图示的部件可以以硬件，软件或软件和硬件的组合实现。

处理器110可以包括一个或多个处理单元，例如：处理器110可以包括应用处理器(application processor，AP)，调制解调处理器，图形处理器(graphics processingunit，GPU)，图像信号处理器(image signal processor，ISP)，控制器，存储器，视频编解码器，数字信号处理器(digital signal processor，DSP)，基带处理器，和/或神经网络处理器(neural-network processing unit，NPU)等。其中，不同的处理单元可以是独立的器件，也可以集成在一个或多个处理器中。

其中，控制器可以是手机100的神经中枢和指挥中心。控制器可以根据指令操作码和时序信号，产生操作控制信号，完成取指令和执行指令的控制。

处理器110中还可以设置存储器，用于存储指令和数据。在一些实施例中，处理器110中的存储器为高速缓冲存储器。该存储器可以保存处理器110刚用过或循环使用的指令或数据。如果处理器110需要再次使用该指令或数据，可从所述存储器中直接调用。避免了重复存取，减少了处理器110的等待时间，因而提高了系统的效率。

示例性的，手机100的软件系统可以采用分层架构，事件驱动架构，微核架构，微服务架构，或云架构。本发明实施例以分层架构的Android系统为例，示例性说明手机100的软件结构。图3是本申请实施例的手机100的软件结构框图。

分层架构将软件分成若干个层，每一层都有清晰的角色和分工。层与层之间通过软件接口通信。在一些实施例中，将Android系统分为四层，从上至下分别为应用程序层，应用程序框架层，安卓运行时(Android runtime)和系统库，以及内核层。

应用程序层可以包括一系列应用程序包。如图3所示，应用程序包可以包括相机，图库，日历，通话，地图，导航，WLAN，蓝牙，视频，即时聊天等应用程序。

应用程序框架层为应用程序层的应用程序提供应用编程接口(applicationprogramming interface，API)和编程框架。应用程序框架层包括一些预先定义的函数。如图3所示，应用程序框架层可以包括窗口管理器，内容提供器，视图系统，进程管理器，通知管理器、自杀恢复管理模块等。

窗口管理器用于管理窗口程序。窗口管理器可以获取显示屏大小，判断是否有状态栏，锁定屏幕，截取屏幕等。

内容提供器用来存放和获取数据，并使这些数据可以被应用程序访问。所述数据可以包括视频，图像，音频，拨打和接听的电话，浏览历史和书签，电话簿等。

视图系统包括可视控件，例如显示文字的控件，显示图片的控件等。视图系统可用于构建应用程序。显示界面可以由一个或多个视图组成的。例如，包括短信通知图标的显示界面，可以包括显示文字的视图以及显示图片的视图。

资源管理器为应用程序提供各种资源，比如本地化字符串，图标，图片，布局文件，视频文件等等。

通知管理器使应用程序可以在状态栏中显示通知信息，可以用于传达告知类型的消息，可以短暂停留后自动消失，无需用户交互。比如通知管理器被用于告知下载完成，消息提醒等。通知管理器还可以是以图表或者滚动条文本形式出现在系统顶部状态栏的通知，例如后台运行的应用程序的通知，还可以是以对话窗口形式出现在屏幕上的通知。例如在状态栏提示文本信息，发出提示音，终端振动，指示灯闪烁等。

自杀恢复管理模块是在检测到运行的应用程序满足本申请实施例提到的自杀恢复条件时，启动对应用程序的自动查杀，以释放内存的应用程序管理机制。

在本申请实施例中，上述自杀恢复条件可以是内存申请失败，失败类型为虚拟内存映射失败，且该应用程序占用的虚拟内存超过预设阈值。

在本申请实施例中，上述对应用程序的自动查杀可以是直接结束该应用程序的所有进程，此时，手机100的显示界面会直接跳到显示手机100的主屏幕界面，即用户感受到该应用程序闪退；上述对应用程序的自动查杀也可以是在结束该应用程序的所有进程后自动拉起该应用程序的主进程，此时手机100的显示界面会直接跳到该应用程序的主显示界面。由于结束应用程序的进程后再次拉起该应用程序的主进程的间隔时间很短，因此用户对此无感知，只能感受到手机100的显示界面又跳回该应用程序的主显示界面。

在本申请一些实施例中，自杀恢复管理模块还具备内存申请监测功能，能够在应用程序向系统内存发出内存申请时，自动启用内存申请监测功能，以监测该内存申请是否成功。

Android Runtime包括核心库和虚拟机。Android runtime负责安卓系统的调度和管理。

核心库包含两部分：一部分是java语言需要调用的功能函数，另一部分是安卓的核心库。

应用程序层和应用程序框架层运行在虚拟机中。虚拟机将应用程序层和应用程序框架层的java文件执行为二进制文件。虚拟机用于执行目标生命周期的管理，堆栈管理，线程管理，安全和异常的管理，以及垃圾回收等功能。

系统库可以包括多个功能模块。例如：表面管理器(surface manager)，媒体库(Media Libraries)，三维图形处理库(例如：OpenGL ES)，2D图形引擎(例如：SGL)等。

内核层是硬件和软件之间的层。内核层至少包含显示驱动，摄像头驱动，音频驱动，传感器驱动。

本申请实施例提供的应用程序的管理方法可以运行在应用程序框架层，即可以通过应用程序框架层中的自杀恢复管理模块来实现上述应用程序的管理方法。

本申请实施例提供的应用程序的管理方法，可以适用于多种存在内存泄露的使用场景中。举例来说，本申请实施例提供的应用程序的管理方法能够应用在用户使用电子设备观看视频或者使用即时聊天软件查看推送文章等场景中。

例如，在用户使用即时聊天软件查看推送文章(可以是新闻推送的文章/视频等)时，应用程序的进程会向系统内存申请图形缓冲区，用于界面的显示绘制和保存显示绘制的数据。在应用程序的进程向系统内存发起图形缓冲区申请时，手机启动内存申请监测功能，并在监测到即时聊天软件满足自杀恢复条件时(此时图形缓冲区申请失败，失败类型为虚拟内存映射失败，且应用程序占用的虚拟内存超过预设阈值)，启动自杀恢复，以使该应用程序释放内存，避免导致整个手机系统崩溃卡死的情况。

示例性的，如图4所示，为应用场景一中可能涉及的一些图形用户界面(graphicaluser interface，GUI)示意图。

在一些实施例中，该即时聊天软件的界面包括主显示区域10(“信息”对应的界面)，其他功能区域20(例如图4中的(a)中“通讯录”、“动态”等)，子对话30。主显示区域10会显示多个子对话30，具体地，可以如图4中的(a)中的形式进行显示。用户要查看某一个子对话推送的文章时，可以通过点击该子对话对应的控件(例如联系人1的子对话)，使得即时聊天软件的显示界面跳转到该子对话对应的显示界面(如图4中的(b)所示)。

在一些实施例中，如图4中的(c)所示，当应用程序在运行过程中，例如用户点击某一个子对话进行对话的查看时，该子对话对应的进程需要申请图形缓冲区时，此时手机可以显示提示信息，提示用户是否要开启手机的内存申请监测功能，该提示信息例如为“该操作可以导致内存泄漏，是否开启内存申请监测功能，以保证系统正常运行？”。当手机接收到用户确认开启内存申请监测功能功能的操作(如用户点击图4中的(c)中所示的“确认”图标)时，可以开启内存申请监测功能，对进程申请图形缓冲区的过程进行监测。

在一些实施例中，手机在获取到图像缓冲区的申请结果后，若申请成功，则应用程序继续正常运行；若申请失败，则进一步分析申请失败的原因，若申请失败的原因是虚拟内存映射失败，则可以进一步获取应用程序已占用的虚拟内存的大小，并在应用程序已占用的虚拟内存的大小超过预设阈值时，启动自杀恢复功能。

在一些实施例中，手机启动自杀恢复功能时，可以直接结束该应用程序的所有进程，此时手机的显示界面会跳回到手机的主屏幕界面(如图4中的(d)所示的界面)。

或者，手机启动自杀恢复功能时，还可以在结束该应用程序的所有进程后，自动拉起该应用程序的主进程，使得手机的显示界面显示该应用程序的主显示界面(如图4中的(a)所示的界面)。

可以理解的，图4所示的界面仅为示例，本申请实施例对界面显示的具体内容(如提示信息的具体内容)、提示信息等的显示位置等不作限定。例如，为了不影响用户查看信息，图4中显示的提示信息也可以设置为在状态栏中提示，并显示信息标识提示用户有相关信息可供查看。当用户需要查看时，可以下拉状态栏点击相关信息进行查看。或者，也可以以小窗口的形式，将相关信息显示在即时聊天界面的如右下角或右上角位置等，以在提示用户的同时，减小对聊天内容的遮挡，降低对用户的影响。

需要说明的是，手机启动内存申请监测功能的方式可以包括：用户主动开启内存申请监测功能的方式、手机自动开启内存申请监测功能的方式以及默认开启内存申请监测功能的方式。

方式1，用户主动开启内存申请监测功能

示例性的，如图5所示，为本申请实施例提供的开启内存申请监测功能过程中涉及的一些图形用户界面示意图。这里以电子设备是手机为例。

在一些实施例中，当应用程序开始运行时，其进程在向系统内存发起创建图形缓冲区的申请时，手机可以提示用户开启内存申请监测功能。提示用户的方式例如可以通过界面显示提示信息的方式(如图4中的(c)所示)，或者通过语音方式；或者通过界面显示提示信息结合语音方式等。

示例性的，如图5中的(a)所示，为手机的主屏幕界面示意图。该主屏幕界面可以包括应用图标显示区域51，用于显示多种类型的应用程序(application，App)图标，如时钟图标、日历图标、图库图标、备忘录图标、文件管理图标、电子邮件图标、音乐图标、计算器图标、录音机图标、运动健康图标、即时聊天图标、浏览器图标、设置图标等。多个应用程序图标下方可以有页面指示符显示区域52，该区域包括的页面指示符用于表明当前显示的页面与其他页面的位置关系。页面指示符的下方可以显示有托盘应用图标显示区域53，用于显示多个托盘应用图标，例如相机应用图标、通讯录应用图标、电话拨号应用图标、信息应用图标等。在另一些实施例中，手机主屏幕界面可以包括比图示更多或更少的应用程序图标或托盘应用图标，本申请对此不作限定。在该主屏幕界面的上方还可以显示有状态栏54，该状态栏54可以包括：移动通信信号(或称蜂窝信号)的一个或多个信号强度指示符，手机的电量指示符，时间指示符等。

在一些实施例中，手机可以接收用户针对设置图标的点击操作；响应于用户的点击操作，手机可以显示如图5中的(b)所示的设置详情界面。

如图5中的(b)所示，设置详情界面可以包括多项业务的管理栏，例如无线和网络管理栏、蓝牙管理栏、桌面和壁纸管理栏、显示管理栏、声音管理栏、应用管理栏、电池管理栏、存储管理栏、安全和隐私管理栏等。在实际应用中，设置界面还可以包括比图示更多或更少类型的管理栏，本申请对此不做限定。

在一些实施例中，手机可以接收用户针对应用管理栏的点击操作；响应于用户的点击操作，手机可以显示如图5中的(c)所示的应用程序管理界面。

示例性的，应用程序界面可以包括多项业务管理栏，该业务例如包括：系统应用设置、应用监测管理、应用双开、授权管理等。每一项业务名称的后方，可以显示该业务对应的下一页指示符。

在一些实施例中，如图5中的(c)所示，手机可以接收应用监测管理栏中下一页指示符的点击操作。响应于用户的点击操作，手机可以显示如图5中的(d)所示的应用监测管理界面。

示例性的，如图5中的(d)所示，该应用监测管理界面可以包括内存申请监测功能的说明内容、开关控件、以及该内存申请监测功能下针对各个应用程序的个性化设置区域。其中，内存申请监测功能的说明内容用于介绍该内存申请监测功能，以使用户更加清楚该功能的作用。该说明内容例如可以是“开关开启内存申请监测功能后，系统会对正在运行的应用程序申请系统内存的结果进行监测，以及时发现内存泄露的情况”。在一些实施例中，内存申请监测功能介绍的下方区域，可以显示该内存申请监测功能对应的开关控件，以实现用户对该内存申请监测功能的开启或者关闭。

应理解，通过针对不同应用程序可以独立设置控制内存申请监测功能开关的控件，这样可以使用户结合应用程序的特点，有选择性且更加贴合需求地使用该内存申请监测功能。通过这种方式，在考虑不同业务特点的基础上，使该功能得到更加合理的应用，避免内存申请监测功能对某些应用程序的进程造成干扰或中断，从而保障了用户的使用体验。

方式2，手机自动开启内存申请监测功能

在一种可能的实现方式中，当应用程序开始运行时，手机可以自动开启内存申请监测功能，也可以在应用程序的进程向系统内存发起内存申请(申请图形缓冲区)时，手机自动开启内存申请监测功能，对内存申请的情况进行监测。

可选地，当手机开启内存申请监测功能时，可以显示提示信息，以告知用户手机当前将执行申请监测功能。或者，还可以显示查询信息，以向用户询问是否确认手机执行内存申请监测功能(如图4中的(c)所示)。示例性的，该提示信息或查询信息可以在手机的状态栏中显示，或者在手机当前界面中显示，本申请对此不作限定。

应理解，该方式中手机自动开启内存申请监测功能的过程，对用户来说可以是无感知的。通过该方式内存申请监测功能，可以避免对当前运行的应用造成影响，如可以避免视频暂停等，从而保证用户体验。

方式3，默认开启内存申请监测功能

在一种可能的实现方式中，在手机出厂前，可以将内存申请监测功能设置为默认开启状态，以实现在后续用户使用手机过程中，可以随时地进行内存申请的监测和管理。

结合上述介绍的示例性开启方式，本申请实施例提供的内存申请监测的方法，可以以用户有感知的形式进程(如用户主动开启，或者向用户显示相关信息等)，或者也可以以用户无感知的形式进行，本申请实施例对此不作限定。

以上结合附图，对本申请实施例提供的应用程序的管理方法所适用的应用场景、对应功能的开启方式等进行了介绍。为更好地理解本申请实施例提供的信号强度预测的方法，以下结合附图对其具体实现过程进行示例性介绍。

示例性的，如图6所示，为本申请实施例提供的电子设备在执行本申请实施例提供的应用程序的管理方法的过程中电子设备的系统内的交互流程示意图。具体可以包括以下步骤：

S601，在应用程序运行过程中，应用程序的进程向内存管理器申请图形缓冲区。

其中，上述应用程序可以是多进程的应用程序，也可以是单进程的应用程序。在实际应用中，为了提高运行速率，降低应用程序的冗余度，应用程序通常为多进程的应用程序，多个进程之间可以是主从关系。

在应用程序运行过程中，为了绘制界面和保存绘制的数据，运行的进程会向内存管理器申请图形缓冲区(graphicbuffer)，以Android系统为例，上述进程向内存管理器申请图形缓冲区可以使用以下方式：

方式1：通过graphicbuffermapper申请进程间共享的图形缓冲区。

Android系统提供了graphicbuffermapper工具类，该工具类为上层访问硬件抽象层(gralloc模块)中提供了接口。

用户空间的应用程序在使用图形缓冲区时，需要先加载gralloc模块，并且获得一个gralloc设备和一个fb设备，有了gralloc设备之后，用户空间中的应用程序就可以申请分配一块图形缓冲区，并且将这块图形缓冲区映射到应用程序的地址空间中，以便可以向里面写入要绘制的画面的内容。最后，用户空间中的应用程序就通过fb设备来将已经准备好了的图形缓冲区渲染到帧缓冲区中去，即将图形缓冲区的内容绘制到显示屏中去，实现应用程序的界面显示。

方式2：通过graphicbufferallocator进程接口申请应用程序使用的图形缓冲区。

Android系统还提供了graphicbufferallocator进程接口，通过graphicbufferallocator进程接口通用可以申请到图像缓冲区。

S602，自杀恢复管理模块启动内存申请监测功能。

在此，自杀恢复管理模块在启动内存申请监测功能后，就会向内存管理器发送获取图形缓冲区申请的申请结果的指令。

在一些实施例中，自杀恢复管理模块可以在应用程序开始运行时就启动内存申请监测功能，也可以在应用程序的进程向系统内存发起图形缓冲区申请时再启动内存申请监测功能，自杀恢复管理模块还可以实时获取应用程序的虚拟内存占用情况，在应用程序的虚拟内存占用超过某一数值时(这个数值可以根根据实际应用场景来设定，本申请对此不加以限制)，开启内存申请监测功能，还可以是在应用程序的虚拟内存占用超过某一数值且该应用程序的进程发起图形缓冲区申请时才启动内存申请监测功能，当然还可以在其他情况下启动内存申请监测功能，本申请对此不加以赘述。

其中，上述启动内存申请监测功能的方式可以参见上述相关的内容，为避免重复，在此不再赘述。

在此，上述图形缓冲区申请的申请结果包括申请成功和申请失败。

申请结果可以以二进制编码的形式来表示。例如申请结果可以包括两个字段，一个字段用于表示申请是否成功，一个字段用于表示申请失败时对应的错误类型。示例性的，用于表示申请是否成功的字段包括2位，其中，00表示申请成功，01表示申请失败；用于表示申请失败时对应的失败类型包括3位，其中，001表示系统可用内存过少、010表示内存映射失败、011表示其他异常情况等(当第一个字段为00时对应的第二个字段为000)。

当然，上述申请结果也可以只包括一个字段，该字段即可以表示出申请是否成功，也可以表示在申请失败时对应的失败类型。示例性的，该字段包括4位，其中第一位用于表示申请是否成功，第二至第四位用于表示申请失败时对应的失败类型，例如0000就表示申请成功，1001就表示申请失败且失败类型为系统可用内存过少，1010就表示申请失败且失败类型为内存映射失败，1011就表示申请失败且失败类型为其他异常情况。

当然，当申请成功时，可以返回no_error；当申请失败时，可以返回error，并附带错误码，通过错误码表示失败类型。

可以理解的是，上述仅是申请结果的示例，上述申请结果还可以包含其他内容，例如返回的时间等，本申请对此不进行限制。

S603，内存管理器响应于上述获取图形缓冲区申请的申请结果的指令，将图像缓冲区申请的申请结果发送至自杀恢复管理模块。

具体地，应用程序的进程向系统内存发出图像缓冲区申请时，在系统可用内存满足该申请，且申请到的内存能够映射到该进程的虚拟内存的地址时，内存管理器会将申请成功的结果发送给到自杀恢复管理模块。

在系统可用内存过少(申请的图形缓冲区占用的内存大于系统可用内存)、申请到的内存无法映射到进程的虚拟内存的地址中以及其他异常情况时，内存管理器会将申请失败的结果发送给到自杀恢复管理模块。

需要说明的是，如果应用程序的进程是通过S601中的方式2去申请图形缓冲区的，即通过graphicbufferallocator进程接口申请应用程序使用的图形缓冲区时，虽然对于该进程而言，图形缓冲区的申请是失败了，但是实际上内存管理器已经将其申请的图形缓冲区所需的内存分配给该进程了，而进程申请失败后会继续发起申请，这样就系统为其分配的内存(实际上没有被使用)就会越积累越多，最终导致系统内存不足，整机崩溃卡死的情况。

S604，自杀恢复管理模块检测到接收到的图形缓冲区申请的申请结果为申请成功，则自杀恢复管理模块发送映射指令给到应用程序。

S605，应用程序响应于该映射指令，将申请到的内存映射到应用程序的进程的虚拟内存的地址中。

当自杀恢复管理模块接收到内存管理器发送过来的申请结果后，通过分析申请结果对应的二进制编码就可以确定出图形缓冲区申请是否成功。示例性的，当申请结果包括两个字段，其中，第一个字段用于表示申请是否成功，读取该字段的编码，并基于该字段的编码就可以确定图形缓冲区申请结果。

例如，自杀恢复管理模块接收到的申请结果为“00，000”，则读取第一字段的内容“00”，并根据预先确定的该编码对应的含义可知，申请结果为申请成功。又例如，申请结果为“01，010”，则读取到第一字段的内容为“01”，根据预先确定的编码对应的含义可知，申请结果为申请失败。

又示例性的，当申请结果只包含一个字段，其中该字段的第1位用于表示申请是否成功，则读取该位的编码，基于该位的编码确定内存申请的申请结果。

例如，申请结果为“0000”，则读取第一位的编码“0”，并根据预先确定的该编码对应的含义可知，申请结果为申请成功。又例如，申请结果为“1010”，则读取第一位的编码“1”，根据预先确定的该编码对应的含义可知，申请结果为申请失败。

其中，应用程序将申请到的内存映射到进程的虚拟内存的地址中的内存映射过程是常用的一种内存管理方法，具体的内存映射过程可以参见现有的方式来实现，本申请在此不加以赘述。

S606，自杀恢复管理模块检测到接收到的图形缓冲区申请的申请结果为申请失败，则根据申请结果分析失败类型。

自杀恢复管理模块确定内存申请的申请结果为申请失败的过程可以参见S604的描述，为避免重复，在此不加以赘述。

其中，上述申请失败时的失败类型可以包括系统可用内存过少、内存映射失败、其他异常情况等，此处不做限定。

在一些实施例中，自杀恢复管理模块可以根据内存管理器返回的申请结果来确定失败类型。例如可以通过分析申请结果对应的二进行编码来确定出失败类型。

示例性的，当申请结果包括两个字段，其中，第一个字段用于表示申请是否成功，第二个字段用于失败类型，表示读取第二字段的编码，并基于第二字段的编码就可以确定内存申请结果。

例如，申请结果为“01，001”，则读取第二字段的内容“001”，并根据预先确定的该编码对应的含义可知，失败类型为系统可用内存过少。又例如，申请结果为“01，010”，则读取到第二字段的内容为“010”，根据预先确定的编码对应的含义可知，失败类型为内存映射失败。

又示例性的，当申请结果只包含一个字段，其中该字段的第2位至第4位用于表示失败类型，则读取第二位至第四位的编码，基于第二位至第四位的编码确定内存申请的申请结果。

例如，申请结果为“1001”，则读取第2位至第四位的编码“001”，并根据预先确定的该编码对应的含义可知，失败类型为系统可用内存过少。又例如，申请结果为“1010”，则读取第2位至第4位的编码“010”，根据预先确定的该编码对应的含义可知，失败类型为内存映射失败。

又例如当申请结果返回为error并附带错误码时，可以通过错误码来确定失败类型。

S607，自杀恢复管理模块在确定失败类型不为内存映射失败的情况下，发送第一异常日志输出指令给到日志管理器。

判断失败类型的相关内容可以参见S606的描述，在此不加以赘述。

S608，日志管理器响应于该第一异常日志输出指令，生成并保存与失败类型对应的异常日志。

在此，上述第一异常日志输出指令用于指示日志管理器生成并保存与失败类型对应的异常日志。

由于失败类型不为内存映射失败，那么基本不会造成内存泄漏的情况，因此无需对应用程序进行任何操作，只需要控制日志管理器生成并保存与该失败类型对应的异常日志即可，以便用户知悉该图形缓冲区申请失败的失败类型，以及其他相关信息(例如申请时间、申请主体(即哪个应用程序的哪个进程提交的申请)等)。

在一些实施例中，上述异常日志可以包括申请发起的进程名称、异常发生的时间和异常的内容等，异常的内容即包括申请图形缓冲区失败以及失败类型。示例性的，当失败类型为系统可用内存过少时，上述异常内容可以是A应用的B进程于xx时间由于系统内存过少申请图形缓冲区失败。

在一些实施例中，当失败类型是系统内存过少时，基于该异常日志，电子设备可以启动LMK机制。

在一些实施例中，上述异常日志可以保存在日志管理器中，电子设备可以通过日志管理器来读取该异常日志。

S609，自杀恢复管理模块在确定失败类型为内存映射失败的情况下，获取应用程序的虚拟内存占用情况。

当失败类型为内存映射失败时，很大概率是因为该应用程序的虚拟内存占用过多了，这种情况很容易导致系统内存泄漏，为了确定是否是由于虚拟内存占用过多，此时可以获取该应用程序的虚拟内存使用情况，继而分析出是否存在内存泄漏的风险。

在一些实施例中，自杀恢复管理模块可以通过/proc/self/status函数来调出应用程序的虚拟内存占用情况。在确定了内存申请失败且失败类型为内存映射失败后，自动调用/proc/self/status函数，就可以获取到该应用程序当前的虚拟内存占用情况。

S610，自杀恢复管理模块判断应用程序占用的虚拟内存是否超过预设阈值。

其中，预设阈值可以根据应用程序来设置，例如对于32位的应用程序，上述预设阈值可以设置为3.7G。当然对于32位的应用程序，上述预设阈值可以设置为比3.7G低的某些数值，例如3.5G、3.2G等。

S611，自杀恢复管理模块在确定应用程序占用的虚拟内存未超过预设阈值的情况下，发送第二异常日志输出指令给到日志管理器。

S612，日志管理器响应于该第二异常日志输出指令，生成并保存内存映射失败且虚拟内存未超过阈值的异常日志。

在此，上述第一异常日志输出指令用于指示日志管理器生成并保存内存映射失败且虚拟内存未超过阈值的异常日志。

在此，由于应用程序占用的虚拟内存未超过预设阈值，也就是说，这不会导致内存泄漏，因此无需对应用程序进行任何操作，只需要通过日志管理器生成并保存内存映射失败且虚拟内存未超过阈值的异常日志。

S613，自杀恢复管理模块在确定应用程序占用的虚拟内存超过预设阈值的情况下，发送启动自杀恢复功能的指令给到进程管理器。

S614，进程管理器响应于该启动自杀恢复功能的指令，结束应用程序的所有进程。

在一些实施例中，在应用程序占用的虚拟内存超过预设阈值时，自杀恢复管理模块可以通过向进程管理器发送启动自杀恢复功能的指令，该指令用于指示进程管理器结束该应用程序的全部进程，释放被该应用程序占用的系统内存。

进程管理器中有系统当前正在运行的所有进程，通过进程管理器结束带有该应用程序名相关的所有进程，就能释放该应用程序占用的系统内存。

在一些实施例中，电子设备启动自杀恢复功能时，可以直接结束该应用程序的所有进程，此时电子设备的显示界面会跳回到电子设备的主屏幕界面，即用户感受到应用程序闪退。

在一些实施例中，进程管理器在结束该应用程序的全部进程后，日志管理器还可以生成并保存由于虚拟内存占用过高，结束该应用程序的运行的异常日志。

根据本申请实施例提供的应用程序管理方法，通过监测应用程序的进程向内存管理器申请图形缓冲区的情况，在内存申请失败且是由于虚拟内存占用过多的情况下，启动自杀恢复功能，结束该应用程序的所有进程，以释放被该应用程序占用的内存，避免由于内存泄露导致系统崩溃、卡死等严重后果，减轻对用户使用的影响。

上述实施例会使得应用程序直接闪退，导致用户侧感受不佳，为了减轻对用户使用的影响，本申请另一实施例还提供了一种应用程序管理方法，如图7所示，为本申请实施例提供的电子设备在执行本申请实施例提供的应用程序的管理方法的过程中电子设备的系统内另一的交互流程示意图。具体可以包括以下步骤：

S701～S712的内容可以参见S601～S612的内容，为避免重复，在此不加以赘述。

S713，自杀恢复管理模块在确定应用程序占用的虚拟内存超过预设阈值的情况下，判断发起图形缓冲器申请的进程是否为主进程。

在此，自杀恢复管理模块可以通过进程的ID确定发起图形缓冲器申请的进程(当前运行的进程)是否是主进程。

每个进程都有自己的ID，而且主进程的ID与子进程的ID明显不同，因此，通过进程的ID就可以确定出其是主进程还是子进程。

S714，自杀恢复管理模块在确定发起图形缓冲器申请的进程不为主进程的情况下，发送结束该应用程序的全部进程的指令给到进程管理器。

S715，进程管理器响应于上述结束该应用程序的全部进程的指令，结束应用程序的所有进程。

由于发起图形缓冲器申请的进程不是主进程，故此时电子设备显示的界面也不是该应用程序的主进程的显示界面，可能是经过用户多次操作后才进入到的页面，电子设备也无法重现该页面，因此，电子设备只会通过进程管理器结束该应用程序的全部进程以释放被其占用的系统内存。

结束应用程序的全部进程的实现过程可以参见S614的描述，为避免重复，在此不加以赘述。

S716，自杀恢复管理模块在确定发起图形缓冲器申请的进程为主进程的情况下，发送结束应用程序的全部进程后重新拉起该应用程序的主进程的指令给到进程管理器。

S717，进程管理器响应于上述结束应用程序的全部进程后重新拉起该应用程序的主进程的指令，结束应用程序的全部进程后重新拉起该应用程序的主进程。

由于发起图形缓冲器申请的进程是该应用程序的主进程，故此时电子设备显示的界面就是该应用程序的主显示界面，因此，在结束该应用程序的所有进程后自动拉起该应用程序的主进程，此时电子设备的显示界面会直接跳到该应用程序的主显示界面。

由于结束应用程序的进程后再次拉起该应用程序的主进程的间隔时间很短，因此用户对此无感知，只能感受到电子设备的显示界面又跳回该应用程序的主显示界面。此时用户不会感受到应用程序闪退，因此可以在释放被该应用程序占用的系统内存的同时避免对用户的使用造成影响，提升用户体验感。

本申请实施例还提供了一种计算机可读存储介质，该计算机可读存储介质中存储有指令，当其在计算机或处理器上运行时，使得计算机或处理器执行上述任一个方法中的一个或多个步骤。

本申请实施例还提供了一种包含指令的计算机程序产品。当该计算机程序产品在计算机或处理器上运行时，使得计算机或处理器执行上述任一个方法中的一个或多个步骤。

本申请实施例还提供了一种包含指令的芯片系统。当该指令在计算机或处理器上运行时，使得计算机或处理器执行上述任一个方法中的一个或多个步骤。

在上述实施例中，可以全部或部分地通过软件、硬件、固件或者其任意组合来实现。当使用软件实现时，可以全部或部分地以计算机程序产品的形式实现。所述计算机程序产品包括一个或多个计算机指令。在计算机上加载和执行所述计算机程序指令时，全部或部分地产生按照本申请实施例所述的流程或功能。所述计算机可以是通用计算机、专用计算机、计算机网络、或者其他可编程装置。所述计算机指令可以存储在计算机可读存储介质中，或者通过所述计算机可读存储介质进行传输。所述计算机指令可以从一个网站站点、计算机、服务器或数据中心通过有线(例如同轴电缆、光纤、数字用户线)或无线(例如红外、无线、微波等)方式向另一个网站站点、计算机、服务器或数据中心进行传输。所述计算机可读存储介质可以是计算机能够存取的任何可用介质或者是包含一个或多个可用介质集成的服务器、数据中心等数据存储设备。所述可用介质可以是磁性介质，(例如，软盘、硬盘、磁带)、光介质(例如，DVD)、或者半导体介质(例如，固态硬盘(solid state disk，SSD))等。

本领域普通技术人员可以理解实现上述实施例方法中的全部或部分流程，该流程可以由计算机程序来指令相关的硬件完成，该程序可存储于计算机可读取存储介质中，该程序在执行时，可包括如上述各方法实施例的流程。而前述的存储介质包括：ROM或随机存储记忆体RAM、磁碟或者光盘等各种可存储程序代码的介质。

以上所述，仅为本申请实施例的具体实施方式，但本申请实施例的保护范围并不局限于此，任何在本申请实施例揭露的技术范围内的变化或替换，都应涵盖在本申请实施例的保护范围之内。因此，本申请实施例的保护范围应以所述权利要求的保护范围为准。

Claims (10)

1.一种应用程序的管理方法，其特征在于，包括：

在应用程序运行过程中，监测图形缓冲区的申请结果；

若图像缓冲区的申请结果为申请失败，则根据申请结果分析失败类型；

若失败类型为内存映射失败，则获取应用程序的虚拟内存占用情况；

若应用程序占用的虚拟内存超过预设阈值，则启动所述应用程序的自杀恢复功能。

2.如权利要求1所述的应用程序的管理方法，其特征在于，所述若应用程序占用的虚拟内存超过预设阈值，则启动自杀恢复功能，包括：

应用程序占用的虚拟内存超过预设阈值时，结束所述应用程序的所有进程。

3.如权利要求1所述的应用程序的管理方法，其特征在于，若应用程序占用的虚拟内存超过预设阈值，则启动自杀恢复功能，包括：

应用程序占用的虚拟内存超过预设阈值时，判断申请所述图形缓冲区的进程是否为所述应用程序的主进程；

若申请所述图形缓冲区的进程是否为所述应用程序的主进程，则结束应用程序的全部进程后重新拉起该应用程序的主进程；否则，结束所述应用程序的所有进程。

4.如权利要求1所述的应用程序的管理方法，其特征在于，在所述在应用程序运行过程中，监测图形缓冲区的申请结果之后，还包括：

若图形缓冲区申请的申请结果为申请成功，则将申请到的内存映射到进程的虚拟内存的地址中。

5.如权利要求1至4任一项所述应用程序的管理方法，其特征在于，还包括：

若失败类型不为内存映射失败，则输出与失败类型对应的异常日志。

6.如权利要求1所述的应用程序的管理方法，其特征在于，还包括：

若应用程序占用的虚拟内存未超过预设阈值，则输出内存映射失败且虚拟内存未超过阈值的异常日志。

7.如权利要求2或3所述的应用程序的管理方法，其特征在于，还包括：

在结束所述应用程序的全部进程后，输出由于虚拟内存占用过高，结束所述应用程序的运行的异常日志。

8.如权利要求1所述的应用程序的管理方法，其特征在于，所述在应用程序运行过程中，监测图形缓冲区的申请结果包括：

在应用程序的进程发起图形缓冲区申请时，启动内存申请监测功能，获取图形缓冲区的申请结果。

9.一种电子设备，其特征在于，包括处理器和存储器，所述处理器和存储器耦合，所述存储器用于存储计算机程序，当所述处理器执行所述计算机程序时，使得电子设备执行权利要求1至8中任意一项所述的方法的步骤。

10.一种计算机可读存储介质，其特征在于，所述计算机可读存储介质包括计算机程序，当所述计算机程序在计算机上运行时，使得计算机执行如权利要求1至8任意一项所述的方法的步骤。

Images