CN117687769A - 一种内存修复清理方法及相关设备 - Google Patents

Abstract

本申请公开了一种内存修复清理方法及相关设备。根据该内存修复清理方法，电子设备可以在创建zygote虚拟机时申请备用虚拟地址段，若存在内存泄露的应用，电子设备可以首先基于该备用虚拟地址段对该应用进行内存扩展，并且内存泄露情况较严重时，且用户不感知该存在内存泄露的应用程序的情况下，对该存在内存泄露的应用程序进行内存修复清理。这种方法可以在不影响用户使用前台应用的前提下有效避免卡顿等问题，还可以在应用退到后台后，确保用户对应用无感知的情况下进行内存修复清理，更好的解决了内存泄漏的问题。

Description

一种内存修复清理方法及相关设备

技术领域

本申请涉及终端技术领域，尤其涉及一种内存修复清理方法及相关设备。

背景技术

部分应用程序长时间使用后可能出现内存泄露的问题。即申请Java内存后无法正常释放相应内存，造成应用程序占用的Java内存持续上升。一旦应用程序可用的Java内存不足，应用程序会触发针对Block类型的垃圾回收(Garbage Collection，GC)。在这种情况下，应用GC会变得异常繁忙，并抢占CPU和内存资源，进一步阻塞Java代码执行，最终造成严重卡顿、应用程序无响应(Application Not Responding，ANR)等性能问题。

因此，如何针对内存泄露问题来进行内存修复清理是目前亟待解决的问题。

发明内容

本申请提供了一种内存修复清理方法及相关设备。根据该内存修复清理方法，若存在内存泄露的应用，电子设备可以对该应用进行内存扩展，以及在用户不感知该应用的情况下对其进行内存修复清理。这样，既不会影响用户使用前台应用，又能有效避免卡顿等问题，更好的解决了内存泄露问题。

第一方面，本申请提供了一种内存修复清理方法。该方法可以应用于电子设备。该方法可以包括：电子设备可以接收冷启动第一应用的第一指令，响应于第一指令，电子设备可以复制zygote虚拟机，从而得到第一应用虚拟机；在满足第一预设条件的情况下，电子设备可以基于第一应用当前运行状态确定第一应用是否处于用户无感知状态；若第一应用处于用户无感知状态，电子设备可以对第一应用进行内存修复清理，即销毁第一应用。其中，第一应用虚拟机中的Java内存空间为第一Java内存空间。第一预设条件可以包括：第一Java内存空间的已占用内存大于第一阈值，以及第一应用驻留在后台的时长大于第一时长。

在本申请提供的方案中，若第一应用虚拟机的Java内存空间的已占用内存达到一定阈值(例如，第一阈值)，且第一应用驻留在后台的时长大于一定时长(例如，第一时长)，则电子设备可以获取第一应用当前的运行状态，并基于该当前的运行状态确定第一应用是否处于用户无感知状态，即确定用户是否可以感知第一应用正在运行，在第一应用处于用户无感知状态的情况下，电子设备可以对第一应用进行内存修复清理，即销毁第一应用(也称查杀第一应用)。这种方法可以待用户不使用存在内存泄露问题的应用后再对该应用进行内存修复清理，既不会影响用户使用前台应用的情况下，又可以避免卡顿、ANR等问题。

在本申请的一些实施例中，第一应用可以为应用_1。第一应用虚拟机可以为应用_1虚拟机。第一Java内存空间可以为RegionSpace_2。

在本申请的一些实施例中，第一指令可以为步骤S1中的指令(如图7所示)，可以为步骤S103中的指令(如图8所示)，可以为S203中的指令(如图9A所示)，可以为步骤S303中的指令(如图10所示)。

在本申请的一些实施例中，第一预设条件可以与后文所提及的“预设条件_1”有相同内容。例如，在第一Java内存空间为RegionSpace_2，第一阈值为内存阈值_1的情况下，第一预设条件和预设条件_1都包括：第一Java内存空间的已占用内存大于第一阈值。

在本申请的一些实施例中，第一阈值可以为内存阈值_1。

在本申请的一些实施例中，第一时长可以为时长阈值_1。

结合第一方面，在一种可能的实现方式中，电子设备基于第一应用当前运行状态确定第一应用是否处于用户无感知状态，具体可以包括：电子设备通过确定第一应用当前运行状态是否包括可感知状态项来确定第一应用是否处于用户无感知状态。第一应用处于用户无感知状态，具体可以包括：第一应用当前的运动状态中不包括可感知状态项。其中，可感知状态项包括以下任意一项或多项：小窗显示，下载，后台播放。

根据本申请提供的方案，电子设备可以通过第一应用的当前运行状态中是否存在可感知状态项来确定第一应用是否处于用户无感知状态。若第一应用的当前运行状态中存在可感知状态项，则第一应用未处于用户无感知状态(后面可简称为无感知状态)，即处于用户可感知状态(后面可简称为可感知状态)。若第一应用的当前运行状态中不存在可感知状态项，则第一应用处于无感知状态。这种方法可以基于应用的当前运行状态确定是否用户当前正在使用该应用，从而可以避免在用户使用该应用的情况下对其进行内存修复清理，既不会影响用户使用应用的情况下，又可以避免卡顿、ANR等问题。

可理解，运行状态和可感知状态项的具体描述可以参考下文，在此不展开说明。

结合第一方面，在一种可能的实现方式中，电子设备基于第一应用当前运行状态确定第一应用是否处于用户无感知状态之后，该方法还可以包括：若第一应用未处于用户无感知状态，电子设备间隔第二时长后重新基于第一应用当前运行状态确定第一应用是否处于用户无感知状态。

根据本申请提供的方案，电子设备可以在确定第一应用未处于用户无感知状态后，间隔一段时间(例如，第二时长)后在重新获取第一应用的当前运行状态，并基于重新获取的第一应用的当前运行状态确定第一应用是否处于用户无感知状态。这种方式可以在一定程度上提高对应用进行内存修复清理的几率，而不是仅凭一次运行状态就不对存在内存泄露的应用进行内存修复清理。

在本申请的一些实施例中，第二时长可以为T1。

结合第一方面，在一种可能的实现方式中，电子设备间隔第二时长后重新基于第一应用当前运行状态确定第一应用是否处于用户无感知状态之后，该方法还可以包括：若电子设备连续X次确定第一应用未处于用户无感知状态，电子设备停止执行间隔第二时长后重新基于第一应用当前运行状态确定第一应用是否处于用户无感知状态的步骤。

在本申请的一些实施例中，X为大于等于2的整数。在本申请的一些实施例中，X＝M。

根据本申请提供的方案，针对用户持续可感知的且存在内存泄露的应用，电子设备不会一直尝试对其进行内存修复清理，而是在尝试若干次之后就不再继续尝试。这种方法可以在尝试解决内存泄露问题的同时节省计算资源。

结合第一方面，在一种可能的实现方式中，电子设备基于第一应用当前运行状态确定第一应用是否处于用户无感知状态之前，该方法还可以包括：在第一Java内存空间的已占用内存大于第一阈值的情况下，电子设备可以通过第一应用虚拟机向电子设备中的SystemServer进程发送内存泄露消息；电子设备可以通过SystemServer进程确定第一应用是否在前台。

根据本申请提供的方案，在第一应用虚拟机确定其自身Java内存占用过多的情况下，第一应用虚拟机可以向SystemServer进程发送相应消息(例如，内存泄露消息)来请求进行内存修复清理。这样，只有在应用存在内存占用过多的问题时才会触发后续内存修复清理步骤，而非同时判断内存占用和驻留在后台，在一定程度上简化了程序并节省了计算资源。

结合第一方面，在一种可能的实现方式中，电子设备基于第一应用当前运行状态确定第一应用是否处于用户无感知状态，具体可以包括：在第一应用在前台的情况下，若第一应用从前台切换至后台，电子设备可以通过SystemServer进程向SystemServer进程发送第一消息，电子设备可以通过SystemServer进程接收第一消息后，基于第一应用当前运行状态确定第一应用是否处于用户无感知状态。第一消息为延迟第三时长发送的handle消息。第三时长可以大于或等于第一时长。

根据本申请提供的方案，电子设备可以在第一应用从前台切换至后台后发送延迟的handle消息，而不是立即执行后续的内存修复清理步骤。这样，一方面可以避免用户短时间内再次查看第一应用时发现第一应用已被销毁，保证用户体验，另一方面可以避免因切换时间太短获取第一应用的当前运行状态时还未更新而造成判断错误。

本申请中，handle消息的使用可以实现将一些耗时的操作放在子线程(例如，后文提及的内存修复清理模块、应用信息收集模块和应用状态管理模块所涉及的子线程)中(异步处理)，从而避免阻塞主线程，提升应用响应速度，还可以将不同组件之间的耦合度降到最低，增加代码的可重用性和扩展性。

在本申请的一些实施例中，第三时长可以为T2。在一种可能的实现方式中，T2可以等于内存阈值_1。在又一种可能的实现方式中，T2可以大于内存阈值_1。

在本申请的一些实施例中，第一消息可以为handle消息_1。

结合第一方面，在一种可能的实现方式中，在满足第一预设条件的情况下，电子设备基于第一应用当前运行状态确定第一应用是否处于用户无感知状态，具体可以包括：在第一应用在后台的情况下，若第一应用驻留在后台的时长大于第一时长，电子设备可以通过SystemServer进程向SystemServer进程发送第二消息，电子设备可以通过SystemServer进程接收第二消息后，基于第一应用当前运行状态确定第一应用是否处于用户无感知状态。

根据本申请提供的方案，电子设备可以在第一应用驻留在后台一定时间后执行后续内存修复清理步骤。这样，一方面可以避免用户短时间内再次查看第一应用时发现第一应用已被销毁，保证用户体验，另一方面可以避免因从驻留在后台的时间太短导致获取第一应用的当前运行状态时还未更新(例如，第一应用的当前运行状态仍为在前台时的状态)而造成判断错误。

在本申请的一些实施例中，第二消息可以为handle消息_2。

可理解，第二消息可以为即时发送的handle消息。通俗来说，“即时发送”表示没有刻意延迟发送。

结合第一方面，在一种可能的实现方式中，在满足第一预设条件的情况下，电子设备基于第一应用当前运行状态确定第一应用是否处于用户无感知状态，具体可以包括：在第一应用在后台的情况下，若第一应用驻留在后台的时长不大于第一时长，电子设备可以通过SystemServer进程向SystemServer进程发送第三消息，电子设备可以通过SystemServer进程接收第三消息后，基于第一应用当前运行状态确定第一应用是否处于用户无感知状态。第三消息为延迟第四时长发送的handle消息。第四时长不小于所述第一时长与所述第一应用驻留在后台的时长的差值。

根据本申请提供的方案，电子设备可以在第一应用驻留在后台的时长较短(例如，不大于第一时长)的情况下后发送延迟的handle消息，而不是立即执行后续的内存修复清理步骤。这样，一方面可以避免用户短时间内再次查看第一应用时发现第一应用已被销毁，保证用户体验，另一方面可以避免因切换时间太短获取第一应用的当前运行状态时还未更新而造成判断错误。

在本申请的一些实施例中，第四时长可以为T2-T3。在本申请的一些实施例中，第四时长可以大于(T2-T3)。

在本申请的一些实施例中，第三消息可以为handle消息_3。

结合第一方面，在一种可能的实现方式中，该方法还可以包括：电子设备可以通过SystemServer进程接收第一消息或第二消息或第三消息后，电子设备可以通过SystemServer进程获取第一应用的相关进程的相关信息。电子设备销毁所述第一应用，具体可以包括：电子设备可以基于第一应用的相关进程的相关信息清除第一应用的所有相关进程。

根据本申请提供的方案，电子设备可以通过清除第一应用的相关进程的方式来销毁第一应用。

结合第一方面，在一种可能的实现方式中，第一预设条件还可以包括：第一应用为第一预设应用。

根据本申请提供的方案，电子设备可以针对特定应用采用上述方法进行内存修复清理。这种方法可以控制进行内存修复清理的应用的数量，避免因使用上述方法进行内存修复清理的应用过多而应用用户体验。

在本申请的一些实施例中，第一预设应用可以预设应用_1。

结合第一方面，在一种可能的实现方式中，该方法还可以包括：在电子设备销毁第一应用之前，若第一Java内存空间的已占用内存小于第二阈值，或者第一应用已销毁，电子设备不再销毁第一应用。

根据本申请提供的方案，在对应用进行内存修复清理前，若该应用的内存下降到一定值或该应用已销毁，则电子设备无需再销毁该应用。这种方法可以一定程度上减少对应用内存泄露的误判，以及一定程度上节省计算资源。

在本申请的一些实施例中，第二阈值可以为内存阈值_2。

结合第一方面，在一种可能的实现方式中，zygote虚拟机中的Java内存空间为第二Java内存空间。第二Java内存空间的内存大小为第一内存。第二Java内存空间对应的虚拟地址为第一虚拟地址段和第二虚拟地址段，第一虚拟地址段对应的内存大小为第一内存。第二虚拟地址段对应的内存为zygote虚拟机申请的备用虚拟内存。第一虚拟地址段对应的内存大小与第二虚拟地址段对应的内存大小的和大于第二Java内存空间的默认内存。电子设备基于第一应用当前运行状态确定第一应用是否处于用户无感知状态之前，该方法还可以包括：在满足第二预设条件的情况下，基于第二虚拟地址段，电子设备可以将第一Java内存空间的内存大小由第一内存扩展为第二内存。第二内存为第三虚拟地址段对应的内存大小。第三虚拟地址段可以包括第一虚拟地址段，以及第二虚拟地址段中的部分或全部地址。第二内存大于第一内存。

根据本申请提供的方案，在应用的已占用Java内存达到一定值之后，电子设备可以首先对该应用的Java内存进行扩展，若该应用的已占用Java内存继续上升至一定值，则电子设备再执行后续内存修复清理步骤。这种方式可以在降低销毁应用的几率的前提下扩展Java内存，从而避免卡顿、ANR等问题。

在本申请的一些实施例中，Java内存空间对应的虚拟地址，可以理解为：Java内存空间对应的虚拟地址段，并且，该虚拟地址段对应的内存大小与Java内存空间的内存大小有关系。在本申请中，Java内存空间对应的虚拟地址段可以理解为Java内存空间可以使用的虚拟地址段。在Java内存空间对应的虚拟地址段为Java内存空间当前使用的虚拟地址的情况下，该虚拟地址段对应的内存大小即为Java内存空间当前的内存大小。在Java内存空间对应的虚拟地址段不全为Java内存空间当前使用的虚拟地址的情况下，Java内存空间当前使用的虚拟地址段对应的内存大小才为Java内存空间当前的内存大小。

在本申请的一些实施例中，第一内存可以为RegionSpace_1的默认内存。

在本申请的一些实施例中，第一内存可以为内存_2。

在本申请的一些实施例中，第二内存可以为内存_1。

在本申请的一些实施例中，第二内存可以为内存_3。

在本申请的一些实施例中，第二预设条件可以为预设条件_2。

在本申请的一些实施例中，第二虚拟地址段可以为备用虚拟地址段。

在本申请的一些实施例中，第一虚拟地址段可以为虚拟地址段_11。第二虚拟地址段可以为虚拟地址段_12。

在本申请的一些实施例中，第二Java内存空间可以为RegionSpace_1。

结合第一方面，在一种可能的实现方式中，满足第二预设条件，具体可以包括：电子设备中的第一Java内存空间满足第一内存条件，且电子设备中的第一应用为第二预设应用。其中，第一Java内存空间满足第一内存条件，具体可以包括：第一Java内存空间中的已占用内存达到第三阈值，和/或第一Java内存空间中的已占用内存的增长率大于第四阈值。

在本申请的一些实施例中，第二预设应用可以为预设应用_2。

在本申请的一些实施例中，第三阈值可以为内存阈值_3。

在本申请的一些实施例中，第四阈值可以为r％。

在本申请的一些实施例中，“第一Java内存空间满足第一内存条件”与后文中的“RegionSpace_2内存满足条件_1”所表示的含义相同。

结合第一方面，在一种可能的实现方式中，满足第二预设条件，具体可以包括：电子设备中的第一Java内存空间满足第一内存条件，且电子设备中的第一应用为第二预设应用，且电子设备的操作系统的未占用内存大于第五阈值。其中，第一Java内存空间满足第一内存条件，具体可以包括：第一Java内存空间中的已占用内存达到第三阈值，和/或第一Java内存空间中的已占用内存的增长率大于第四阈值。

在本申请的一些实施例中，第五阈值可以为内存阈值_4。

结合第一方面，在一种可能的实现方式中，第一内存可以为第二Java内存空间的默认内存。

第二方面，本申请提供了一种电子设备，该电子设备包括：一个或多个存储器，以及一个或多个处理器；该一个或多个存储器与该一个或多个处理器耦合，该存储器用于存储计算机程序代码，该计算机程序代码包括计算机指令，该一个或多个处理器调用该计算机指令以使得该电子设备执行如第一方面或第一方面的任意一种实现方式所描述的方法。

第三方面，本申请提供了一种计算机存储介质。该计算机存储介质包括计算机指令，当该计算机指令在电子设备上运行时，使得该电子设备执行如第一方面或第一方面的任意一种实现方式所描述的方法。

第四方面，本申请实施例提供一种芯片。该芯片可以应用于电子设备，该芯片包括一个或多个处理器，该处理器用于调用计算机指令以使得该电子设备执行如第一方面或第一方面的任意一种实现方式所描述的方法。

第五方面，本申请实施例提供一种包含指令的计算机程序产品。当该计算机程序产品在电子设备上运行时，使得该电子设备执行如第一方面或第一方面的任意一种实现方式所描述的方法。

可理解，上述第二方面提供的电子设备、第三方面提供的计算机存储介质、第四方面提供的芯片，以及第五方面提供的计算机程序产品均用于执行如第一方面或第一方面的任意一种实现方式所描述的方法。因此，其所能达到的有益效果可参考上述第一方面中任一种可能的实现方式的有益效果，此处不再赘述。

附图说明

图1为本申请实施例提供的一种电子设备的软件结构示意图；

图2为本申请实施例提供的一种zygote进程的孵化原理示意图；

图3A和图3B为本申请实施例提供的虚拟机的示意图；

图4为本申请实施例提供的一种运行时数据区的示意图；

图5为本申请实施例提供的一种zygote虚拟机的示意图；

图6为本申请实施例提供的一种zygote虚拟机孵化其他应用进程虚拟机的原理示意图；

图7为本申请实施例提供的一种内存修复清理方法的流程图；

图8为本申请实施例提供的又一种内存修复清理方法的流程图；

图9A和图9B为本申请实施例提供的又一组内存修复清理方法的流程图；

图10为本申请实施例提供的又一种内存修复清理方法的流程图；

图11为本申请实施例提供的一种zygote虚拟机创建方法的流程图；

图12为本申请实施例提供的一种电子设备的硬件结构示意图。

具体实施方式

下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述。其中，在本申请实施例的描述中，除非另有说明，“/”表示或的意思，例如，A/B可以表示A或B；文本中的“和/或”仅仅是一种描述关联对象的关联关系，表示可以存在三种关系，例如，A和/或B，可以表示：单独存在A，同时存在A和B，单独存在B这三种情况，另外，在本申请实施例的描述中，“多个”是指两个或多于两个。

应当理解，本申请的说明书和权利要求书及附图中的术语“第一”、“第二”等是用于区别不同对象，而不是用于描述特定顺序。此外，术语“包括”和“具有”以及它们任何变形，意图在于覆盖不排他的包含。例如包含了一系列步骤或单元的过程、方法、系统、产品或设备没有限定于已列出的步骤或单元，而是可选地还包括没有列出的步骤或单元，或可选地还包括对于这些过程、方法、产品或设备固有的其它步骤或单元。

在本申请中提及“实施例”意味着，结合实施例描述的特定特征、结构或特性可以包含在本申请的至少一个实施例中。在说明书中的各个位置出现该短语并不一定均是指相同的实施例，也不是与其它实施例互斥的独立的或备选的实施例。本领域技术人员显式地和隐式地理解的是，本申请所描述的实施例可以与其它实施例相结合。

在手机、平板电脑等电子设备的使用过程中，这些电子设备中的应用程序可用的Java内存是受到限制的。例如，对于采用安卓(Android)系统的电子设备而言，该电子设备中的应用程序的可用最大Java内存是受到限制的(例如，该最大Java内存的默认值可以为512MB)。可理解，Java内存指的是提供给Java对象使用的内存。之所以应用程序可用的Java内存受到限制，是因为应用程序使用过多的内存可能会导致系统崩溃或变得不稳定，系统需要对应用程序的内存使用进行限制，以确保系统的稳定性，并且系统可以通过限制每个应用程序可使用的内存，来避免部分应用程序占用大量内存而导致其他应用程序无法正常运行的情况，以及电子设备的硬件资源相对有限，系统需要对应用程序的内存进行限制，以确保所有应用程序都能够在设备上正常运行。

部分应用程序长时间使用后可能出现内存泄露的问题。即申请Java内存后无法正常释放相应内存，造成应用程序占用的Java内存持续上升。一旦应用程序占用Java内存接近或超出系统规定的Java内存上限(例如，512MB)，应用程序会触发针对Block类型的GC。在这种情况下，应用GC会变得异常繁忙，并抢占CPU和内存资源，进一步阻塞Java代码执行，最终造成严重卡顿、ANR等性能问题。

本申请实施例提供了一种内存修复清理方法及相关设备。根据该内存修复清理方法，存在内存泄露的应用程序的情况下，电子设备可以在用户不感知该存在内存泄露的应用程序的情况下，对该存在内存泄露的应用程序进行内存修复清理。在本申请的一些实施例中，电子设备可以在应用程序出现内存泄露情况时首先对其进行内存扩展，待内存泄露情况较严重时根据上述方法对其进行内存修复清理。这种方法可以在不影响用户使用前台应用的前提下有效避免卡顿等问题，还可以在应用退到后台后，确保用户对应用无感知的情况下进行内存修复清理，更好的解决了内存泄漏的问题。

下面首先介绍本申请涉及的电子设备的软件结构。

请参阅图1，图1为本申请实施例提供的一种电子设备的软件结构示意图。

如图1所示，本申请涉及的电子设备的软件框架可以包括应用程序层、应用程序框架层(framework，FWK)、系统库、运行时、硬件抽象层(HAL)和内核层(kernel)。

其中，应用程序层可以包括一系列应用程序包。例如，应用_1、日历、图库、通话、蓝牙、视频、音乐、短信息和WLAN等应用程序(也可以简称为应用)。其中，应用_1可以为系统应用，也可以为三方应用，本申请对此不作限制。示例性的，应用_1可以为短视频类应用，可以为直播类应用，还可以为新闻类应用。

应用程序框架层为应用程序层的应用程序提供应用编程接口(ApplicationProgramming Interface，API)和编程框架。应用程序框架层包括一些预先定义的函数。应用程序框架层可以包括一系列系统服务。系统服务是专注于特定功能的模块化组件。应用框架API所提供的功能可与系统服务通信，以访问底层硬件。应用程序框架层可以包括SystemServer(系统服务)进程。SystemServer进程是由zygote进程孵化(fork)生成的。SystemServer进程是zygote进程fork的第一个进程SystemServer进程负责启动和管理整个应用程序框架层，包含活动管理器(ActivityManager)、窗口管理器(WindowManager)、包管理器(PackageManager)和电源管理器(PowerManager)等服务。SystemServer进程可以包括应用信息收集模块、应用状态管理模块和内存修复清理模块。应用信息收集模块用于收集应用的进程信息。例如，应用对应的主进程和相关子进程等。应用状态管理模块用于获取应用的状态信息(即运行状态)。在本申请的一些实施例中，应用的运行状态可以包括应用的一个或多个状态项(例如，前后台状态、录屏、备份、下载、小窗显示、播放音频和/或视频等)。内存修复清理模块可以用于确定应用是否处于用户无感知状态(后面可简称为无感知状态)，以及对应用的内存进行修复清理。无感知状态指的是用户感知不到应用正在运行。例如，应用处于后台运行状态，且其在显示屏上没有相应显示，也没有后台播放。可理解，本申请所涉及的对应用进行的“修复清理”可以理解为销毁应用，也可以理解为查杀应用。

应用程序框架层还可以包括窗口管理器、内容提供器、视图系统、电话管理器、资源管理器和通知管理器等。其具体含义可以参考相关技术文档，在此不展开说明。

应用程序框架层还可以包括任务栈恢复模块。任务栈恢复模块可以用于恢复应用程序在被查杀前所显示的界面。可理解，任务栈恢复模块可以将应用程序在被查杀前所显示的界面恢复至后台。也就是说，该应用程序恢复相应界面的过程可以不被用户感知。在本申请的一些实施例中，任务栈恢复模块可以根据优先级决策确定是否重新拉起并恢复被查杀的应用程序的相应界面。可理解，该优先级指的是被查杀的应用程序的优先级。在本申请的一些实施例中，在被查杀的应用程序的优先级较高的情况下，任务栈恢复模块可以重新拉起并恢复该应用程序的相应界面。可理解，优先级的相关设置规则可以参考相关技术文档，在此不展开说明。

运行时(Runtime)负责系统的调度和管理。Runtime包括核心库和虚拟机。其中，核心库包含两部分：一部分是编程语言(例如，java语言)需要调用的功能函数，另一部分是系统的核心库。应用程序层和应用程序框架层运行在虚拟机中。虚拟机将应用程序层和应用程序框架层的编程文件(例如，java文件)执行为二进制文件。虚拟机用于执行对象生命周期的管理、堆栈管理、线程管理、安全和异常的管理，以及垃圾回收等功能。可理解，虚拟机可以包括若干进程对应的虚拟机实例。例如，zygote进程对应的虚拟机实例(本申请中记为zygote虚拟机)、应用_1进程对应的虚拟机实例(本申请中记为应用_1虚拟机)等。

zygote(孵化器)是Android中的一个非常重要的守护进程服务。zygote进程对应有zygote虚拟机。所有的其他进程都是通过zygote进程孵化(fork)出来的。其他进程的虚拟机的初始空间布局继承了zygote虚拟机的空间布局。Android应用程序是由Java语言编写的，运行在各自独立的虚拟机中。如果每个应用程序在启动之时都需要单独运行和初始化一个虚拟机，会大大降低系统性能。因此Android首先创建一个zygote虚拟机，然后通过它孵化出其他的虚拟机进程，进而共享虚拟机内存和框架层资源，这样大幅度提高应用程序的启动和运行速度。

具体地，请参阅图2，zygote进程对应有zygote虚拟机。zygote虚拟机为zygote进程对应的虚拟机实例。zygote进程可以fork应用程序进程(例如，应用_1进程)和SystemServer进程。应用程序进程对应有应用程序虚拟机(例如，应用_1虚拟机)，应用程序虚拟机为应用程序进程对应的虚拟机实例。可理解，应用程序进程为应用程序对应的进程，应用程序运行在应用程序进程上。值得注意的是，应用程序虚拟机继承有zygote虚拟机的空间布局。简单来说，也可以理解为zygote虚拟机fork应用程序虚拟机。

可理解，每一个应用程序都运行在其自己的进程中。每一个应用程序进程都对应有其自己的虚拟机实例。简单来说，可以理解为应用程序运行在虚拟机(例如，Dalvik/ART虚拟机)中。例如，应用_1运行在应用_1进程中，应用_1进程对应的虚拟机实例为应用_1虚拟机。也可以简单理解为，应用_1对应的虚拟机实例为应用_1虚拟机。

可理解，应用_1虚拟机和zygote虚拟机的具体描述可参见下文，在此先不展开说明。

可理解，Dalvik虚拟机为Android 5.0版本之前使用的Android虚拟机，ART虚拟机为Android 5.0版本全面使用的Android虚拟机。

Runtime还可以包括进程管控模块。进程管控模块可以用于对进程进行管控。例如，创建zygote进程对应的虚拟机实例(即zygote虚拟机)和应用程序对应的虚拟机实例(例如，应用_1虚拟机)。

系统库可以包括多个功能模块。例如，表面管理器(Surface Manager)、媒体库(Media Libraries)、三维图形处理库(例如，OpenGL ES)和二维图形引擎(例如，SGL)等。这些功能模块的具体含义和作用可以参考相关技术文档，在此不展开说明。

硬件抽象层(HAL)是位于操作系统内核与上层软件之间的接口层，其目的在于将硬件抽象化。硬件抽象层是设备内核驱动的抽象接口，用于实现向更高级别的Java API框架提供访问底层设备的应用编程接口。HAL可以提供标准界面，向更高级别的Java API框架显示设备硬件功能。HAL包含多个库模块，例如相机HAL、音频HAL等。其中每个库模块都为特定类型的硬件组件实现一个界面。为当系统框架层API要求访问便携设备的硬件时，操作系统将为该硬件组件加载库模块。

内核层是Android操作系统的基础。内核层负责硬件的驱动程序、网络、电源、系统安全以及内存管理等功能。内核层是硬件与软件之间的一个中间层，其作用是将应用程序的请求传递给硬件。内核层可以包括相机驱动、显示驱动、摄像头驱动、音频驱动和传感器驱动。

需要说明的是，本申请提供的图1所示的电子设备的软件结构示意图仅作为一种示例，并不限定Android操作系统不同分层中的具体模块划分，具体可以参考常规技术中对Android操作系统软件结构的介绍。另外，本申请提供的方法还可以基于其他操作系统实现，本申请不再一一举例。

下面具体介绍虚拟机及其对应的内存空间。

请参阅图3A，图3A为本申请实施例提供的一种虚拟机的示意图。

如图3A所示，虚拟机可以包括Runtime(运行时)模块和运行时数据区。Runtime模块可以用于管控虚拟机中的内存空间(例如，运行时数据区)。运行时数据区可以用于存储类Class文件元数据、对象和数组，以及方法参数局部变量等。运行时数据区可以包括若干Space(空间)，该若干Space的功能可以不同。例如，如图3A所示，运行时数据区可以包括Java内存空间。Java内存空间指的是提供给Java对象使用的内存空间。Java内存空间对应的内存即为Java内存。可理解，如图3B所示，对于Android操作系统来说，Java内存空间可以为RegionSpace(区域空间)。当然，针对其他操作系统，Java内存空间还可以为其他模块，本申请对此不作限制。RegionSpace通过平均分配256千字节(KB)的region(区域，也可理解为内存块)来对内存进行分片管理。也就是说，RegionSpace将内存资源划分成一个个固定大小的region，然后从region中分配。并且，一个region的大小为256KB。

在本申请的一些实施例中，Runtime模块可以控制运行时数据区中的若干Space申请虚拟地址，并建立该虚拟地址与物理地址之间的映射关系。具体地，在一种可能的实现方式中，运行时数据区中的若干Space可以调用地址管理模块来申请虚拟地址。可理解，地址管理模块可以用于实现Java内存空间(例如，RegionSpace)的内存所对应的虚拟地址和物理地址之间的映射关系。需要说明的是，本申请中所涉及的虚拟地址可以理解为虚拟内存地址，物理地址可以理解为物理内存地址(即RAM内存地址)。虚拟内存指的是利用磁盘空间虚拟出的一块逻辑内存。物理内存指的是真实物理内存(即RAM内存)所能表达的地址空间范围。

可理解，RAM的英文全称为Random Access Memory，即随机存取寄存器。RAM也被叫做主存，是与中央处理器(Central Processing Unit，CPU)直接交换数据的内部存储器。它可以随时读写(刷新时除外)，而且速度很快，通常作为操作系统或其他正在运行中的程序的临时数据存储介质。RAM工作时可以随时从任何一个指定的地址写入(存入)或读出(取出)信息。

需要说明的是，运行时数据区不仅可以包括Java内存空间(例如，RegionSpace)，还可以包括其他Space。示例性的，如图4所示，运行时数据区可以包括RegionSpace、LargeObjectSpace(大对象空间)、ZygoteSpace(孵化器空间)、ImageSpace(镜像文件空间)和jit code cache(即时编译代码缓存区)等。这些内存空间的具体含义和功能可以参考相关技术文档，在此不展开说明。

可理解，运行时数据区还可以对栈、方法区等其他模块进行管控。栈(Stack)是内存指令区，用于存储基本数据类型、指令代码和常量。方法区(Method Area)与运行时数据区类似，是各个线程共享的内存区域，可以用于存储已被虚拟机加载的类型信息、常量、静态变量、即时编译器编译后的代码缓存等数据。

可理解，在运行时数据区中分配的内存，通过虚拟机的GC机制来管理。可理解，GC的相关描述可以参考上文及相关技术文档，在此不再赘述。

可理解，Runtime模块还可以包括执行引擎、本地库接口、本地方法库和Java线程等，本申请对Runtime模块的具体结构不作限制。

可理解，本申请中所提及的虚拟机可以为Java虚拟机(Java Virtual Machine，JVM)。

下面介绍zygote虚拟机和其孵化过程。

可理解，如图5所示，本申请将zygote虚拟机中的Runtime模块记为Runtime模块_1，将zygote虚拟机中的运行时数据区记为运行时数据区_1，将zygote虚拟机中的Java内存空间记为RegionSpace_1。

可理解，zygote进程可以通过fork来创建应用程序进程和SystemServer进程。应用程序进程和SystemServer进程可以向zygote进程获取一个虚拟机的实例拷贝。即应用程序进程和System Server进程可以获得由zygote进程对应的虚拟机实例(即zygote虚拟机)拷贝得到的虚拟机实例。也就是说，电子设备可以通过复制zygote虚拟机来得到其他进程对应的虚拟机实例。

示例性的，如图6所示，电子设备可以通过zygote进程来fork应用_1对应的进程(即应用_1进程)。应用_1进程对应的虚拟机实例(即应用_1虚拟机)可以由zygote进程对应的虚拟机实例(即zygote虚拟机)拷贝(或称复制)得到。也就是说，初始状态的应用_1虚拟机(即刚创建完成的应用_1虚拟机)与zygote虚拟机是一样的。为了便于描述，本申请将应用_1虚拟机中的Runtime模块记为Runtime模块_2，将应用_1虚拟机中的运行时数据区记为运行时数据区_2，将应用_1虚拟机中的Java内存空间记为RegionSpace_2。可理解，针对初始状态的应用_1虚拟机，Runtime模块_2和Runtime模块_1是一样的，运行时数据区_2和运行时数据区_1是一样的，RegionSpace_2和RegionSpace_1是一样的。在本申请的一些实施例中，应用_1虚拟机创建完成后，应用_1可以根据实际需要对应用_1虚拟机进行设置(例如，改变应用_1虚拟机中的内存空间布局)，本申请对此不作限制。可理解，zygote进程还可以fork其他应用程序进程(例如，短信应用对应的进程)。如图6所示，短信应用对应的虚拟机实例(即短信虚拟机)可以由zygote虚拟机拷贝得到。类似的，初始状态下，短信虚拟机中的Runtime模块_3和Runtime模块_1是一样的，运行时数据区_3和运行时数据区_1是一样的，RegionSpace_3和RegionSpace_1是一样的。

可理解，zygote进程还可以fork其他进程(例如，音乐、视频等其他应用程序进程)，本申请不再一一举例说明。

可理解，在Android操作系统中，zygote虚拟机中的Java内存空间可以为RegionSpace，然而，在其他操作系统中，zygote虚拟机中的Java内存空间可以不为RegionSpace，而是其他模块，本申请对此不作限制。

下面介绍本申请实施例提供的一种内存修复清理方法。

请参阅图7，图7为本申请实施例提供的一种内存修复清理方法的流程图。该方法可以包括但不限于以下步骤：

S1：电子设备接收到冷启动应用_1的指令，响应于该指令，电子设备基于zygote虚拟机孵化得到应用_1虚拟机，并监测应用_1虚拟机中的Java内存空间的内存占用情况。其中，应用_1虚拟机为应用_1进程对应的虚拟机实例。

用户可以通过触摸、声音等方式冷启动应用_1。相应的，电子设备可以接收到冷启动应用_1的指令，响应于该指令，电子设备可以基于zygote虚拟机孵化得到应用_1虚拟机。由zygote虚拟机孵化得到应用_1虚拟机之后，进一步的，电子设备可以对应用_1虚拟机中的Java内存空间的内存占用情况进行监测。可理解，应用_1虚拟机指的是应用_1进程对应的虚拟机实例。应用_1虚拟机的初始内存空间布局与创建完成的zygote虚拟机中的内存空间布局是一致的。

在本申请的一些实施例中，电子设备可以每隔一段时间(例如，1分钟)查看一次应用_1虚拟机中的Java内存空间的已占用内存。

在本申请的一些实施例中，电子设备可以在每一次GC之后查看一次应用_1虚拟机中的Java内存空间的已占用内存。

可理解，电子设备还可以通过其他方式来对应用_1虚拟机中的Java内存空间的内存占用情况进行监测，本申请对此不作限制。

可理解，当应用程序启动时，电子设备后台没有该应用程序的进程，这时系统会重新创建一个新的进程分配给该应用，这个启动方式就叫做冷启动(后台不存在该应用程序进程)。

可理解，执行步骤S1之前，电子设备可以创建并启动zygote虚拟机。具体地，用户可以通过长按电源键等方式来触发启动电子设备，相应的，电子设备可以接收到启动电子设备的指令，响应于该指令，电子设备可以创建并启动zygote虚拟机。创建并启动zygote虚拟机的具体实现方式可以参考下文，在此不展开说明。

S2：在应用_1虚拟机中的Java内存空间的已占用内存大于内存阈值_1，且应用_1驻留在后台的时长大于时长阈值_1的情况下，电子设备确定应用_1是否处于无感知状态。

可理解，电子设备可以对应用_1虚拟机中的Java内存空间的内存占用情况进行监测。在应用_1虚拟机中的Java内存空间的已占用内存大于内存阈值_1，且应用_1驻留在后台的时长大于时长阈值_1的情况下，电子设备可以确定应用_1是否处于无感知状态。可理解，无感知状态指的是用户对应用_1无感知。无感知状态的具体描述可以参考下文，在此不展开说明。

在本申请的一些实施例中，若电子设备监测到应用_1虚拟机中的Java内存空间的已占用内存大于内存阈值_1，则电子设备可以确定应用_1是在前台，还是在后台。若应用_1在前台，则电子设备待应用_1从前台切换至后台，且应用_1驻留在后台的时长大于时长阈值_1之后，再确定应用_1是否处于无感知状态。若应用_1在后台，则电子设备确定应用_1驻留在后台的时长是否大于时长阈值_1，在应用_1驻留在后台的时长大于时长阈值_1的情况下，电子设备确定应用_1是否处于无感知状态，而在应用_1驻留在后台的时长不大于时长阈值_1的情况下，电子设备待应用_1驻留在后台的时长大于时长阈值_1之后，再确定应用_1是否处于无感知状态。

可理解，内存阈值_1和时长阈值_1可以根据实际需要进行设置，本申请对此不作限制。在本申请的一些实施例中，内存阈值_1为600兆字节(MB)。在本申请的一些实施例中，时长阈值_1为30秒(s)。

在本申请的一些实施例中，电子设备针对特定应用进行内存清理。在一种可能的实现方式中，电子设备仅在应用_1为预设应用_1的情况下才执行步骤S2。也就是说，在应用_1为预设应用_1，且应用_1虚拟机中的Java内存空间的已占用内存大于内存阈值_1，且应用_1驻留在后台的时长大于时长阈值_1的情况下，电子设备确定应用_1是否处于无感知状态。

在一种可能的实现方式中，应用_1为预设应用_1，具体可以包括：应用_1为预设应用名单_1中的应用。

在又一种可能的实现方式中，应用_1为预设应用_1，具体可以包括：应用_1为预设类别_1的应用。

可理解，预设应用名单/预设类别可以根据实际需要进行设置，本申请对此不作限制。在本申请的一些实施例中，预设应用名单/预设类别可以基于各个应用的历史内存占用情况来设置。例如，预设应用名单_1可以包括：针对a次冷启动后的内存占用情况，内存占用率超过b％的次数达到c％*a的应用。可理解，a、b和c可以根据实际需要进行设置，本申请对此不作限制。例如，a可以为5，b可以为90，c可以为80。

S3：电子设备对应用_1进行内存修复清理。

若电子设备确定应用_1处于无感知状态，则电子设备对应用_1进行内存修复清理。即销毁应用_1。具体地，电子设备可以清除与应用_1相关的所有进程和线程。

S4：电子设备判断是否连续M次确定应用_1未处于无感知状态。M为正整数。

若电子设备确定应用_1未处于无感知状态，即应用_1处于可感知状态(即用户可以感知到应用_1在运行)，电子设备判断电子设备是否已经连续M次确定应用_1未处于无感知状态。若电子设备判断电子设备已经连续M次确定应用_1未处于无感知状态，则电子设备执行步骤S6(即取消对应用_1进行内存修复清理)，若电子设备判断电子设备并未连续M次确定应用_1未处于无感知状态，则电子设备执行步骤S5之后再执行步骤S2。可理解，M可以为正整数。例如，M＝3。

S5：电子设备等待T1。

若电子设备判断电子设备并未连续M次确定应用_1未处于无感知状态，则电子设备等待T1之后再执行步骤S2。

可理解，T1可以根据实际需要进行设置，本申请对此不作限制。例如，T1可以为10s。

S6：电子设备取消对应用_1进行内存修复清理。

若电子设备判断电子设备已经连续M次确定应用_1未处于无感知状态，则电子设备取消本次对应用_1进行内存修复清理。

需要说明的是，在本申请的一些实施例中，电子设备执行步骤S2之后，若电子设备确定应用_1处于无感知状态，则电子设备可以执行步骤S6。在这种情况下，电子设备无需执行步骤S4和步骤S5，也无需执行步骤S2和步骤S3。

还需要说明的是，在本申请的一些实施例中，在电子设备对应用_1进行内存修复清理之前，若应用_1虚拟机中的Java内存空间的已占用内存小于内存阈值_2，则电子设备取消对应用_1进行内存修复清理。在本申请的又一些实施例中，在电子设备对应用_1进行内存修复清理之前，若应用_1销毁，则电子设备取消对应用_1进行内存修复清理。

可理解，内存阈值_2可以根据实际需要进行设置，本申请对此不作限制。例如，内存阈值_2可以为450MB。

下面结合图8进一步说明本申请实施例提供的一种内存修复清理方法。

请参阅图8，图8为本申请实施例提供的又一种内存修复清理方法的流程图。该方法可以包括但不限于以下步骤：

S101：电子设备接收到启动电子设备的指令。

可理解，用户可以通过长按电源键等方式来触发启动电子设备。相应的，电子设备可以接收到启动电子设备的指令。该指令用于触发电子设备创建zygote虚拟机。

S102：响应于电子设备接收到的启动电子设备的指令，电子设备创建并启动zygote虚拟机。

响应于该启动电子设备的指令，电子设备可以创建zygote虚拟机，对zygote虚拟机中的内存空间进行布局，并在创建完成后启动zygote虚拟机，具体可以参考下文，在此不展开说明。

在本申请的一些实施例中，电子设备可以在创建zygote虚拟机的过程中申请备用虚拟地址段，以便后续得以实现内存扩展，具体可以参考下文，在此不展开说明。

S103：电子设备接收到冷启动应用_1的指令。

用户可以通过触摸、声音等方式冷启动应用_1。相应的，电子设备可以接收到冷启动应用_1的指令。该指令用于触发启动应用_1。

S104：响应于电子设备接收到的冷启动应用_1的指令，电子设备基于zygote虚拟机孵化应用_1虚拟机。

响应于该冷启动应用_1的指令，电子设备可以开始启动应用_1。具体地，电子设备可以基于zygote虚拟机孵化应用_1虚拟机。应用_1虚拟机为应用_1进程对应的虚拟机实例。

可理解，由于应用_1虚拟机是由zygote虚拟机孵化得到的，应用_1虚拟机中的Java内存空间的初始内存与zygote虚拟机中的Java内存空间的内存相同。

在本申请的一些实施例中，电子设备可以在创建zygote虚拟机的过程中申请备用虚拟地址段，在这种情况下，由于应用_1虚拟机是基于zygote虚拟机孵化得到的，应用_1虚拟机后续可以基于该备用虚拟地址段来实现内存扩展。

S105：应用_1虚拟机对应用_1虚拟机中的Java内存空间的内存占用情况进行监测。

可理解，应用_1虚拟机孵化完成后，可以对其中的Java内存空间的内存占用情况进行监测。

在本申请的一些实施例中，电子设备中的应用_1虚拟机可以每隔一段时间(例如，1分钟)查看一次应用_1虚拟机中的Java内存空间的已占用内存。

在本申请的一些实施例中，电子设备中的应用_1虚拟机可以在每一次GC之后查看一次应用_1虚拟机中的Java内存空间的已占用内存。

可理解，应用_1虚拟机还可以通过其他方式来对应用_1虚拟机中的Java内存空间的内存占用情况进行监测，本申请对此不作限制。

S106：在满足预设条件_1的情况下，应用_1虚拟机向SystemServer进程发送内存泄露消息。

在满足预设条件_1的情况下，应用_1虚拟机可以向SystemServer进程发送内存泄露消息。相应的，SystemServer进程可以接收应用_1虚拟机发送的内存泄露消息。内存泄露消息用于表示应用_1虚拟机中的剩余Java内存不足。内存泄露消息可以携带有应用_1的包名和进程pid。

可理解，pid指的是操作系统中的进程标识(Process Identification)。每个进程有唯一的pid。应用程序一运行系统就会给该程序对应的进程自动分配一个pid。pid是进程运行时系统分配的，并不代表专门的进程。进程运行时，其pid不会改变，但是进程终止后，其pid会被系统回收。系统可能将回收的pid重新分配给其他新运行的程序。

在本申请的一些实施例中，满足预设条件_1，具体可以包括：应用_1虚拟机中的Java内存空间的已占用内存大于内存阈值_1。

在本申请的一些实施例中，满足预设条件_1，具体可以包括：应用_1虚拟机中的Java内存空间的已占用内存大于内存阈值_1，且应用_1为预设应用_1。

在本申请的一些实施例中，在执行步骤S106之前，应用_1虚拟机可以基于备用虚拟地址段来实现内存扩展，从而避免卡顿等问题。

S107：在应用_1驻留在后台的时长大于时长阈值_1的情况下，SystemServer进程确定应用_1是否处于无感知状态。

SystemServer进程接收应用_1虚拟机发送的内存泄露消息之后，可以确定应用_1是在前台，还是在后台。若应用_1在前台，那么SystemServer进程待应用_1从前台切换至后台，且应用_1驻留在后台的时长大于时长阈值_1之后，SystemServer进程再确定应用_1是否处于无感知状态。若应用_1在后台，则SystemServer进程确定应用_1驻留在后台的时长是否大于时长阈值_1，在应用_1驻留在后台的时长大于时长阈值_1的情况下，电子设备确定应用_1是否处于无感知状态，而在应用_1驻留在后台的时长不大于时长阈值_1的情况下，电子设备待应用_1驻留在后台的时长大于时长阈值_1之后，再确定应用_1是否处于无感知状态。

可理解，无感知状态的具体描述可以参考下文，在此不展开说明。

S108：在应用_1处于无感知状态的情况下，SystemServer进程对应用_1进行内存修复清理。

若SystemServer进程确定应用_1处于无感知状态，则SystemServer进程对应用_1进行内存修复清理。

在本申请的一些实施例中，若SystemServer进程确定应用_1未处于无感知状态，即应用_1处于可感知状态，则SystemServer进程取消本次对应用_1进行内存修复清理。

在本申请的一些实施例中，若SystemServer进程确定应用_1未处于无感知状态，即应用_1处于可感知状态，则SystemServer进程间隔T1后再次确定应用_1是否处于无感知状态。若SystemServer进程确定应用_1处于无感知状态，则SystemServer进程对应用_1进行内存修复清理，然而，若SystemServer进程确定应用_1未处于无感知状态，则SystemServer进程还可以间隔T1后再次确定应用_1是否处于无感知状态。需要说明的是，SystemServer进程确定应用_1是否处于无感知状态的次数最多为M次，若SystemServer进程连续M次确定应用_1未处于无感知状态，则SystemServer进程取消本次对应用_1进行内存修复清理。

需要说明的是，在本申请的一些实施例中，应用_1虚拟机执行步骤S106之后，可以继续对应用_1虚拟机中的Java内存空间的内存占用情况进行监测，一旦应用_1虚拟机中的Java内存空间的已占用内存小于内存阈值_2，应用_1虚拟机可以向SystemServer进程发送相应消息以告知SystemServer进程应用_1的Java内存占用已恢复。若SystemServer进程接收到该相应消息时还未开始对应用_1进行内存修复清理，则SystemServer进程可以取消对应用_1进行内存修复清理。

还需要说明的是，在本申请的一些实施例中，在SystemServer进程对应用_1进行内存修复清理之前，若应用_1销毁，则SystemServer进程取消对应用_1进行内存修复清理。

下面结合图9A和图9B说明上述实施例的一种具体实现方式。

1、应用_1虚拟机监测到出现内存泄露情况，并将其报告给SystemServer进程(如图9A所示)

S201：进程管控模块接收到启动电子设备的指令。

可理解，电子设备可以检测到启动电子设备的用户操作(例如，长按电子设备上的电源键)。具体的，用户可以长按电子设备上的电源键，电子设备中的进程管控模块可以接收到启动电子设备的指令。

S202：进程管控模块创建并启动zygote虚拟机。zygote虚拟机为zygote进程对应的虚拟机实例。zygote虚拟机包括Runtime模块_1和运行时数据区_1。运行时数据区_1包括RegionSpace_1。

电子设备接收到启动电子设备的指令之后，响应于该启动电子设备的指令，电子设备中的进程管控模块可以创建并启动zygote虚拟机。具体的，进程管控模块接收到启动电子设备的指令之后，可以创建并启动zygote虚拟机。可理解，zygote虚拟机为zygote进程对应的虚拟机实例。zygote虚拟机包括Runtime模块_1和运行时数据区_1。运行时数据区_1包括RegionSpace_1。zygote虚拟机的相关描述可以参考上文，在此不展开说明。

S203：进程管控模块接收到冷启动应用_1的指令。

用户可以触发应用_1冷启动。例如，用户可以通过点击应用_1的应用图标来触发应用_1冷启动。相应的，进程管控模块可以接收到冷启动应用_1的指令。可理解，冷启动的相关含义可以参考上文和相关技术文档，在此不展开说明。

S204：进程管控模块基于zygote虚拟机孵化应用_1虚拟机。应用_1虚拟机为应用_1进程对应的虚拟机实例。应用_1虚拟机继承zygote虚拟机的空间布局。应用_1虚拟机包括Runtime模块_2和运行时数据区_2。运行时数据区_2包括RegionSpace_2。

可理解，进程管控模块可以通过zygote进程来fork应用_1进程。具体地，进程管控模块可以拷贝(即复制)zygote进程对应的虚拟机实例(即zygote虚拟机)来作为应用_1进程对应的虚拟机实例(即应用_1虚拟机)。相应的，应用_1虚拟机中的Runtime模块_2和运行时数据区_2得以创建。其中，运行时数据区_2包括RegionSpace_2。

可理解，应用_1虚拟机继承zygote虚拟机的空间布局，具体指的是：基于zygote虚拟机孵化的应用_1虚拟机的空间布局与zygote虚拟机的空间布局一样。也就是说，初始状态的应用_1虚拟机与zygote虚拟机是一样的，其相关描述可以参考上下文，在此不展开说明。

S205：Runtime模块_2对RegionSpace_2内存进行监测。

应用_1虚拟机fork完成之后，应用_1中的Runtime模块_2可以对RegionSpace_2内存进行监测。具体地，Runtime模块_2可以对RegionSpace_2的已占用内存进行监测。

在本申请的一些实施例中，Runtime模块_2可以每隔一段时间(例如，1分钟)查看一次RegionSpace_2的已占用内存。

在本申请的一些实施例中，Runtime模块_2可以在每一次GC之后都查看RegionSpace_2中已占用的内存。

S206：在满足预设条件_1的情况下，Runtime模块_2向SystemServer发送内存泄露消息。内存泄露消息携带有应用_1的包名。

在满足预设条件_1的情况下，电子设备中的Runtime模块_2可以向SystemServer进程发送内存泄露消息。相应的，SystemServer进程可以接收Runtime模块_2发送的内存泄露消息。

在本申请的一些实施例中，内存泄露消息还可以携带有进程pid。

可理解，预设条件_1和内存泄露消息的相关描述可以参考上文，在此不展开说明。

2、SystemServer进程对应用_1进行内存修复清理(如图9B所示)

S207：内存修复清理模块接收内存泄露消息。

Runtime模块_2向SystemServer进程发送内存泄露消息之后，具体可以由SystemServer进程中的内存修复清理模块接收该内存泄露消息。

S208：内存修复清理模块确定应用_1是否在前台。

SystemServer进程中的内存修复清理模块接收Runtime模块_2发送的内存泄露消息之后，可以确定应用_1是否在前台。若应用_1在前台，则内存修复清理模块可以执行步骤S209-步骤S211。若应用_1在后台，则内存修复清理模块可以执行步骤S212-步骤S214。

在本申请的一些实施例中，内存修复清理模块可以调用相应接口确定应用_1是运行在前台，还是运行在后台。

S209：在应用_1在前台的情况下，内存修复清理模块指示应用信息收集模块监听应用_1前后台切换事件。

若内存修复清理模块确定应用_1在前台，内存修复清理模块可以指示SystemServer进程中的应用信息收集模块监听应用_1前后台切换事件。可理解，应用_1前后台切换事件指的是应用_1由前台运行状态切换至后台运行状态。

在本申请的一些实施例中，电子设备启动，创建并启动zygote进程后，zygote进程可以孵化生成SystemServer进程。SystemServer进程生成后，SystemServer进程中的线程可以初始化参数。例如，SystemServer进程中的内存修复清理模块可以初始化参数。可理解，在内存修复清理模块初始化参数之后，内存修复清理模块可以向应用信息收集模块注册应用前后台切换事件。可理解，内存修复清理模块向应用信息收集模块注册应用前后台切换事件之后，内存修复清理模块具备通过应用信息收集模块来监听应用程序的前台运行状态和后台运行状态的切换事件(后面简称为前后台切换事件)的能力。需要说明的是，应用信息收集模块可以监听电子设备中包括应用_1在内的多个应用程序的前后台切换事件。具体地，在内存修复清理模块确定应用_1在前台的情况下，内存修复清理模块可以使用通过应用信息收集模块来监听应用程序的前后台切换事件的能力，从而确定针对应用_1是否存在有前后台切换事件。

S210：内存修复清理模块通过应用信息收集模块监听到存在应用_1前后台切换事件。

在本申请的一些实施例中，若应用_1从前台切换至后台，内存修复清理模块可以通过应用信息收集模块监听到存在应用_1前后台切换事件。即针对应用_1存在前后台切换事件，可以表示应用_1从前台切换至后台。

S211：内存修复清理模块向内存修复清理模块发送handle消息_1。handle消息_1为延迟T2发送的handle消息。

内存修复清理模块接收应用信息收集模块发送的应用_1前后台切换消息之后，可以向自己发送handle消息_1。handle消息_1为延迟T2发送的handle消息。也就是说，内存修复清理模块可以延迟T2发送handle消息。

可理解，T2可以根据实际需要进行设置，本申请对此不作限制。例如，T2可以为30s。可理解，T2可以为上文所提及的“时长阈值_1”。在本申请的一些实施例中，T2可以大于时长阈值_1。

可理解，handle机制是Android系统中的一种消息传递机制。handler机制可以用于同进程的线程间通信。为了便于描述，本申请中将基于handle机制发送的消息记为handle消息(例如，handle消息_1、handle消息_2和handle消息_3)。

S212：在应用_1在后台的情况下，内存修复清理模块确定应用_1驻留在后台的时长是否超过T2。

若内存修复清理模块确定应用_1在后台，内存修复清理模块可以获取应用_1驻留在后台的时长，并确定应用_1驻留在后台的时长是否超过T2。

在本申请的一些实施例中，内存修复清理模块可以调用相应接口来获取应用_1驻留在后台的时长。

S213：若应用_1驻留在后台的时长超过T2，内存修复清理模块向内存修复清理模块发送handle消息_2。handle消息_2为即时的handle消息。

若应用_1驻留在后台的时长超过T2，内存修复清理模块可以向自己发送handle消息_2。handle消息_2为即时的handle消息。也就是说，在内存修复清理模块确定应用_1驻留在后台的时长超过T2的情况下，可以即时向自己发送handle消息，无需延迟。

S214：若应用_1驻留在后台的时长未超过T2，发送handle消息_3。handle消息_2为延迟(T2-T3)发送的handle消息。T3为应用_1驻留在后台的时长。

若应用_1驻留在后台的时长未超过T2，内存修复清理模块可以向自己发送handle消息_3。handle消息_2为延迟(T2-T3)发送的handle消息。也就是说，在内存修复清理模块确定应用_1驻留在后台的时长未超过T2的情况下，可以延迟(T2-T3)向自己发送handle消息。其中，T3为应用_1驻留在后台的时长。

S215：内存修复清理模块向应用信息收集模块获取应用_1的相关进程的相关信息。

内存修复清理模块接收到handle消息(例如，handle消息_1，或者handle消息_2，或者handle消息_3)之后，可以向应用信息收集模块获取应用_1的相关进程的相关信息。

在本申请的一些实施例中，电子设备启动后，SystemServer进程中的内存修复清理模块可以初始化参数，具体可以参考上文，在此不展开说明。可理解，在内存修复清理模块初始化参数之后，内存修复清理模块可以向应用信息收集模块注册应用进程信息收集事件。可理解，内存修复清理模块向应用信息收集模块注册应用进程信息收集事件之后，应用信息收集模块具备收集应用程序的相关进程的相关信息(例如，进程名称、相关文件名称等)的能力。需要说明的是，应用信息收集模块可以收集电子设备中包括应用_1在内的多个应用程序的相关进程的相关信息。具体地，在内存修复清理模块接收到handle消息之后，内存修复清理模块可以使用应用信息收集模块收集应用程序的相关进程的相关信息的能力。即应用信息收集模块可以收集应用_1的相关进程的相关信息。

在本申请的一些实施例中，内存修复清理模块可以向应用信息收集模块获取应用_1的所有相关进程(例如，应用_1主进程、子进程等)的相关信息。

S216：内存修复清理模块向应用状态管理模块获取应用_1当前的运行状态。

内存修复清理模块接收到handle消息(例如，handle消息_1，或者handle消息_2，或者handle消息_3)之后，可以向应用状态管理模块获取应用_1当前的运行状态。

在本申请的一些实施例中，运行状态可以包括以下任意一个或多个状态项：前后台状态、录屏、备份、下载、小窗显示、播放音频和/或视频等。可理解，运行状态可以包括更多状态项，本申请不再一一举例。

S217：内存修复清理模块确定应用_1当前的运行状态中是否存在可感知状态项。

内存修复清理模块可以确定获取的应用_1当前的运行状态中是否存在可感知状态项。可理解，可感知状态项指的是用户能够感知的应用的状态。可感知状态项可以包括以下任意一项或多项：小窗显示，下载，后台播放。当然，可感知状态项还可以包括其他状态项，本申请对此不作限制。

S218：若应用_1当前的运行状态中不存在可感知状态项，内存修复清理模块基于应用_1的相关进程的相关信息对应用_1进行内存修复清理。

若应用_1当前的运行状态中不存在可感知状态项，内存修复清理模块可以基于应用_1的相关进程的相关信息(例如，进程名称，相关文件名称等)对应用_1进行修复清理。可理解，内存修复清理模块基于应用_1的相关进程的相关信息对应用_1进行修复清理，具体可以包括：内存修复清理模块基于应用_1的相关进程的相关信息来清除应用_1的所有相关进程。即销毁应用_1。

S219：若应用_1当前的运行状态中存在可感知状态项，内存修复清理模块间隔T1后向应用状态管理模块重新获取应用_1当前的运行状态。

若应用_1当前的运行状态中存在可感知状态项，内存修复清理模块可以间隔T1后向应用状态管理模块重新获取应用_1当前的运行状态。可理解，内存修复清理模块重新获取应用_1当前的运行状态之后，可以再执行步骤S217，即确定应用_1当前的运行状态中是否存在可感知状态项。需要说明的是，内存修复清理模块再执行步骤S217时针对的是重新获取的应用_1当前的运行状态。

S220：若连续M次获取的应用_1当前的运行状态中均存在可感知状态项，内存修复清理模块不对应用_1进行内存修复清理。

若内存修复清理模块连续M次获取的应用_1当前的运行状态中均存在可感知状态项，则内存修复清理模块不对应用_1进行内存修复清理，即取消本次对应用_1进行内存修复清理。

需要说明的是，在本申请的一些实施例中，应用_1虚拟机执行步骤S206之后，可以继续对应用_1虚拟机中的Java内存空间的内存占用情况进行监测，一旦应用_1虚拟机中的Java内存空间的已占用内存小于内存阈值_2，应用_1虚拟机可以向SystemServer进程中的内存修复清理模块发送相应消息以告知应用_1的Java内存占用已恢复。若内存修复清理模块接收到该相应消息时还未开始对应用_1进行内存修复清理，则内存修复清理模块可以取消对应用_1进行内存修复清理。

还需要说明的是，在本申请的一些实施例中，在内存修复清理模块对应用_1进行内存修复清理之前，若应用_1销毁，则内存修复清理模块取消对应用_1进行内存修复清理。在这种情况下，在内存修复清理模块初始化参数后，内存修复清理模块可以注册应用销毁事件，以便内存修复清理模块后续可以获取应用_1销毁事件。

在本申请的一些实施例中，应用_1虚拟机在将内存泄漏情况报告给SystemServer进程之前，可以进行内存扩展。

下面结合图10和图9B介绍上述实施例的又一种具体实现方式。

首先，需要说明的是，电子设备执行图10所示的步骤之后，可以继续执行图9B所示的步骤。由于上文已对图9B所示的内容进行了详细描述，在此不再说明图9B所示的内容。

S301：进程管控模块接收到启动电子设备的指令。

可理解，步骤S301的具体实现方式可以参考步骤S201的相关描述，在此不再赘述。

S302：进程管控模块创建并启动zygote虚拟机。zygote虚拟机为zygote进程对应的虚拟机实例。zygote虚拟机包括Runtime模块_1和运行时数据区_1。运行时数据区_1包括RegionSpace_1。RegionSpace_1使用的虚拟地址段对应的内存大小为RegionSpace_1的默认内存，RegionSpace_1对应有备用虚拟地址段。

电子设备接收到启动电子设备的指令之后，响应于该启动电子设备的指令，电子设备中的进程管控模块可以创建并启动zygote虚拟机。具体的，进程管控模块接收到启动电子设备的指令之后，可以创建并启动zygote虚拟机。

需要说明的是，在创建zygote虚拟机的过程中，zygote虚拟机中的RegionSpace_1可以申请备用虚拟地址段，具体实现方式请参考下文，在此不展开说明。

S303：进程管控模块接收到冷启动应用_1的指令。

可理解，步骤S303的具体实现方式可以参考步骤S203的相关描述，在此不再赘述。

S304：进程管控模块基于zygote虚拟机孵化应用_1虚拟机。应用_1虚拟机为应用_1进程对应的虚拟机实例。应用_1虚拟机继承zygote虚拟机的空间布局。应用_1虚拟机包括Runtime模块_2和运行时数据区_2。运行时数据区_2包括RegionSpace_2。RegionSpace_2使用的虚拟地址段对应的内存大小为RegionSpace_1的默认内存，RegionSpace_2对应有备用虚拟地址段。

可理解，由于应用_1虚拟机继承zygote虚拟机的空间布局，则初始状态(即刚创建应用_1虚拟机)下，RegionSpace_2使用的虚拟地址段对应的内存大小为RegionSpace_1的默认内存，并且RegionSpace_2对应有备用虚拟地址段。

可理解，步骤S304的具体实现方式可以参考步骤S204的相关描述，在此不再赘述。

S305：Runtime模块_2对RegionSpace_2内存进行监测。

可理解，步骤S305的具体实现方式可以参考步骤S205的相关描述，在此不再赘述。

S306：在满足预设条件_2的情况下，Runtime模块_2控制RegionSpace_2基于备用虚拟地址段来扩展RegionSpace_2的内存。

在满足预设条件_2的情况下，Runtime模块_2可以控制RegionSpace_2基于备用虚拟地址段来扩展RegionSpace_2的内存。

在本申请的一些实施例中，满足预设条件_2，具体可以包括以下任意一项或多项：RegionSpace_2内存满足条件_1，应用_1满足条件_2，电子设备的操作系统的未占用内存满足条件_3。

在本申请的一些实施例中，RegionSpace_2内存满足条件_1，具体可以包括以下任意一项或多项：RegionSpace_2中的已占用内存超过内存阈值_3，RegionSpace_2在一段时间内的已占用内存超过内存阈值_3，连续n次GC之后的RegionSpace_2中的已占用内存均超过内存阈值_3，以及RegionSpace_2中的已占用内存的增长率超过r％。

可理解，内存阈值_3、r和n可以根据实际需要进行设置，本申请对此不作限制。例如，内存阈值_3可以为480MB。在本申请的一些实施例中，内存阈值_3可以小于或等于预设内存阈值。在本申请的一些实施例中，内存阈值_3可以为预设内存阈值的f％。可理解，f可以根据实际需要进行设置，本申请对此不作限制。例如，f可以为80。在本申请的一些实施例中，r可以为30。n可以为正整数。例如，n可以为5。

在本申请的一些实施例中，应用_1满足条件_2，具体可以包括：应用_1为预设应用_2。在一种可能的实现方式中，应用_1为预设应用_2，具体可以包括：应用_1为预设应用名单_2中的应用。在又一种可能的实现方式中，应用_1为预设应用_2，具体可以包括：应用_1为预设类别_2的应用。

可理解，预设应用名单/预设类别的设置方式可以参考上文，在此不再赘述。

需要说明的是，预设应用名单_2和预设应用名单_1可以完全相同或部分相同，类似的，预设类别_2和预设类别_1也可以完全相同或部分相同。在本申请的一些实施例中，应用_1可以对应多个类别。在这种情况下，预设类别_1和预设类别_2可以完全不同。可理解，预设应用名单和预设类别的相关描述可以参考上文，在此不再赘述。

在本申请的一些实施例中，电子设备的操作系统的未占用内存满足条件_3，具体可以包括以下任意一项或多项：电子设备的操作系统的未占用内存大于内存阈值_4，以及电子设备的操作系统的未占用内存与该操作系统的总内存的比值大于比值_1。可理解，内存阈值_4和比值_1可以根据实际需要进行设置，本申请对此不作限制。例如，比值_1可以为0.2。

可理解，上述条件_1、条件_2和条件_3还可以包括其他内容，本申请对此不作限制。

S307：在满足预设条件_1的情况下，Runtime模块_2向SystemServer发送内存泄露消息。

可理解，步骤S307的具体实现方式可以参考步骤S206的相关描述，在此不再赘述。

在本申请的一些实施例中，电子设备执行图10所示的步骤S302时可以具体执行如图11所示的步骤。具体步骤如下：

S401：进程管控模块创建zygote虚拟机。

电子设备接收到启动电子设备的指令之后，响应于该启动电子设备的指令，电子设备中的进程管控模块可以创建zygote虚拟机。可理解，进程管控模块创建zygote虚拟机的过程中可以对zygote虚拟机中的内存空间进行布局。

根据上文，zygote虚拟机包括Runtime模块_1和运行时数据区_1。运行时数据区_1包括RegionSpace_1。

S402：进程管控模块启动zygote虚拟机。

电子设备创建zygote虚拟机之后，电子设备中的进程管控模块可以启动zygote虚拟机。

其中，电子设备执行步骤S401时可以具体执行如下步骤：

S4011：进程管控模块创建Runtime模块_1。

进程管控模块接收到启动电子设备的指令之后，响应于该启动电子设备的指令，可以开始创建zygote虚拟机。具体地，进程管控模块可以首先创建Runtime模块_1。Runtime模块_1的相关描述可以参考上文，在此不展开说明。

S4012：Runtime模块_1创建运行时数据区_1。

进程管控模块创建Runtime模块_1之后，Runtime模块_1可以再创建运行时数据区_1。运行时数据区_1的相关描述可以参考上文，在此不展开说明。

可理解，Runtime模块_1创建运行时数据区_1之后，运行时数据区_1可以进行内存空间的布局。即电子设备可以进行运行时数据区_1的布局。该运行时数据区_1的布局的具体实现可以包括步骤S4013-步骤S4016。

S4013：运行时数据区_1确定运行时数据区_1中的RegionSpace_1对应的内存大小为内存_1。内存_1大于RegionSpace_1对应的默认内存。

Runtime模块_1创建运行时数据区_1之后，运行时数据区_1可以确定运行时数据区_1中各个Space对应的内存大小。具体地，运行时数据区_1可以确定RegionSpace_1对应的内存大小为内存_1。也可以理解为，运行时数据区_1可以确定RegionSpace_1对应的初始内存大小为内存_1。内存_1大于RegionSpace_1对应的默认内存。可理解，RegionSpace_1为运行时数据区_1中的一块内存空间，其详细描述可参考上文。

当然，运行时数据区_1还可以确定运行时数据区_1中其他Space(例如，ImageSpace等)对应的内存大小，其具体实现可参考相关技术文档，在此不展开说明。

在本申请的一些实施例中，运行时数据区_1可以通过读取相关配置文件来确定运行时数据区_1中各个Space对应的内存大小。可理解，该配置文件中记录有运行时数据区_1中各个Space对应的内存。这样，运行时数据区_1可以根据该配置文件中记录的各个Space对应的内存来进行布局。

可理解，该配置文件中可以记录有RegionSpace_1对应的初始内存大小为内存_1，以及记录有RegionSpace_1对应的默认内存。

示例性的，内存_1可以为768MB，RegionSpace_1对应的默认内存可以为512MB。

当然，内存_1还可以设置为其他大于RegionSpace_1对应的默认内存的值，本申请对此不作限制。在本申请的一些实施例中，内存_1不大于预设内存阈值。可理解，预设内存阈值可以根据实际需要进行设置，本申请对此不作限制。例如，预设内存阈值可以为768MB。

S4014：运行时数据区_1基于内存_1创建RegionSpace_1。

运行时数据区_1确定RegionSpace_1对应的内存大小为内存_1之后，可以在运行时数据区_1中划分一块内存空间作为RegionSpace_1。在这种情况下，RegionSpace_1还没有完成创建。后续过程中，RegionSpace_1可以申请内存_1对应的虚拟地址段，并建立该虚拟地址段与真实物理地址之间的映射，以及划分region，从而实现RegionSpace_1的创建。

S4015：RegionSpace_1申请虚拟地址段_1，并基于虚拟地址段_1的相关信息划分RegionSpace_1中的region。虚拟地址段_1对应的内存大小为内存_1。虚拟地址段_1由虚拟地址段_11和虚拟地址段_12组成。虚拟地址段_11对应的内存大小为RegionSpace_1的默认内存。

运行时数据区_1划分RegionSpace_1之后，RegionSpace_1可以申请虚拟地址段_1，并基于虚拟地址段_1的相关信息划分RegionSpace_1中的region。

在本申请的一些实施例中，RegionSpace_1可以申请内存_1对应的匿名页。内存_1对应的匿名页可以用于表示虚拟地址段_1。可理解，匿名页用于表示与物理地址建立有映射关系的进程虚拟地址空间中的一段虚拟地址。进程虚拟地址空间中的堆、栈和数据段一般被称为匿名页。匿名页指的是没有文件背景的页面，它不是以文件形式存在，因此无法和磁盘文件交换。

在本申请的一些实施例中，虚拟地址段_1的相关信息可以包括以下任意一项或多项：虚拟地址段_1的首地址，虚拟地址段_1的尾地址。

在一种可能的实现方式中，虚拟地址段_1的相关信息包括虚拟地址段_1的首地址。在这种情况下，RegionSpace_1可以基于虚拟地址段_1的首地址和内存_1确定虚拟地址段_1的尾地址，并基于虚拟地址段_1的首地址和其尾地址将其划分为大小为256KB的地址段。可理解，每一个大小为256KB的地址段即为一个region。

需要说明的是，RegionSpace_1申请的虚拟地址段_1对应的内存大小为内存_1，内存_1大于RegionSpace_1的默认内存。也就是说，RegionSpace_1申请的虚拟地址段_1对应的内存大小要大于RegionSpace_1的默认内存。为了便于描述和理解，本申请将虚拟地址段_1记为由虚拟地址段_11和虚拟地址段_12组成。其中，虚拟地址段_11对应的内存大小为RegionSpace_1的默认内存。

S4016：运行时数据区_1向RegionSpace_1获取并记录RegionSpace_1中的region的相关信息。

RegionSpace_1划分region之后，运行时数据区_1可以向RegionSpace_1获取并记录RegionSpace_1所划分的region的相关信息。可理解，region的相关信息可以包括region对应的地址段，还可以包括region的状态和类型。当然，region的相关信息还可以包括其他内容(例如，region中的存储对象的类型)，本申请对此不作限制。

S4017：运行时数据区_1布局完成后，Runtime模块_1释放RegionSpace_1的部分内存。释放部分内存后的RegionSpace_1的内存为RegionSpace_1的默认内存。释放部分内存后的RegionSpace_1对应的虚拟地址段为虚拟地址段_11。

Runtime模块_1确定运行时数据区_1布局完成之后，针对RegionSpace_1申请的内存_1，Runtime模块_1可以释放其中的部分内存，而保留其中的其他内存。释放内存后，RegionSpace_1的内存大小可以为RegionSpace_1对应的默认内存。也就是说，释放的部分内存对应的虚拟地址为虚拟地址段_12，而保留下来的内存对应的虚拟地址为虚拟地址段_11。

可理解，虚拟地址段_12可以理解为RegionSpace_1对应的备用虚拟地址段。RegionSpace_1中记录有虚拟地址段_12，后续过程中可以再次使用虚拟地址段_12对应的内存。可理解，由zygote虚拟机fork得到的其他虚拟机(例如，应用_1虚拟机)中的RegionSpace也记录有虚拟地址段_12，后续过程中也可以基于虚拟地址段_12来实现内存扩展。

可理解，本申请所涉及的释放内存，具体指的是解除内存对应的虚拟地址段与物理地址之间的映射关系。

需要说明的是，在本申请的一些实施例中，电子设备执行步骤S4017时，电子设备可以释放内存_1中除内存_2外的内存。可理解，内存_2小于内存_1。在一种可能的实现方式中，如图11所示，内存_2可以为RegionSpace_1对应的默认内存。在又一种可能的实现方式中，内存_2可以大于RegionSpace_1对应的默认内存。这样，所有经由zygote进程fork的应用程序进程的Java内存空间都可以得以扩展。在又一种可能的实现方式中，内存_2可以小于RegionSpace_1对应的默认内存。这样，经由zygote进程fork的应用程序进程的Java内存空间都会缩小，可以便于后续针对特定应用程序来进行Java内存空间的扩展。

可理解，若电子设备执行步骤S4017时，释放的是内存_1中除内存_2外的内存，则电子设备执行步骤S306时，可以将RegionSpace_2的内存大小由内存_2调整为内存_3。可理解，内存_3大于内存_2，且内存_3小于或等于内存_1。

需要说明的是，基于图11所示的内容，步骤S302中所提及的“RegionSpace_1使用的虚拟地址段”可以为虚拟地址段_11，步骤S302中所提及的“RegionSpace_1对应的备用虚拟地址段”可以为虚拟地址段_12。电子设备执行步骤S306时，可以建立虚拟地址段_12中的部分或全部地址段与物理地址之间的映射关系，这样，RegionSpace_1对应的内存大小可以在原本的默认内存(即RegionSpace_1的默认内存)的基础上得以扩展，并且RegionSpace_1的内存大小最多可以扩展至内存_1。

可理解，上述方法不仅适用于使用Android操作系统的电子设备，还可以适用于使用其他操作系统的电子设备，在这种情况下，该电子设备中的Java内存空间可能不为上述RegionSpace。

下面介绍本申请涉及的电子设备的硬件结构。

请参阅图12，图12为本申请实施例提供的一种电子设备的硬件结构示意图。

电子设备可以包括处理器110，外部存储器接口120，内部存储器121，音频模块130，扬声器130A，受话器130B，麦克风130C，耳机接口130D，显示屏140，摄像头150，触摸传感器160。

可以理解的是，本申请实施例示意的结构并不构成对电子设备的具体限定。可理解，图示的部件可以以硬件，软件或软件和硬件的组合实现。在本申请的一些实施例中，电子设备可以包括比图示更多的部件。示例性的，电子设备可以包括加速度传感器、陀螺仪传感器和温度传感器等其他类型的传感器。在本申请的又一些实施例中，电子设备可以包括比图示更少的部件，或者组合某些部件，或者拆分某些部件，或者不同的部件布置。本申请实施例示意的各模块间的接口连接关系，只是示意性说明，并不构成对电子设备的结构限定。

处理器110可以包括一个或多个处理单元，例如：处理器110可以包括应用处理器(application processor，AP)，调制解调处理器，图形处理器(graphics processingunit，GPU)，图像信号处理器(image signal processor，ISP)，控制器，视频编解码器，数字信号处理器(digital signal processor，DSP)，基带处理器，和/或神经网络处理器(neural-network processing unit，NPU)等。处理器110中还可以设置存储器，用于存储指令和数据。

电子设备通过GPU，显示屏140，以及应用处理器等实现显示功能。

GPU为图像处理的微处理器，连接显示屏140和应用处理器。GPU用于执行数学和几何计算，用于图形渲染。处理器110可包括一个或多个GPU，其执行程序指令以生成或改变显示信息。显示屏140用于显示图像，视频等。在一些实施例中，电子设备可以包括一个或多个显示屏140。

摄像头150用于捕获静态图像或视频。ISP用于处理摄像头150反馈的数据。光线通过镜头被传递到摄像头感光元件上，光信号转换为电信号，摄像头感光元件将所述电信号传递给ISP处理，转化为肉眼可见的图像。电子设备可以包括一个或多个摄像头150。

内部存储器121可以包括一个或多个RAM和一个或多个非易失性存储器(non-volatile memory，NVM)。随机存取存储器可以由处理器110直接进行读写，可以用于存储操作系统或其他正在运行中的程序的可执行程序(例如，机器指令)，还可以用于存储用户及应用程序的数据等。非易失性存储器也可以存储可执行程序和存储用户及应用程序的数据等，可以提前加载到随机存取存储器中，用于处理器110直接进行读写。

在本申请实施例中，实现本申请实施例所述的内存修复清理方法的代码可存储在非易失性存储器上。在运行相机应用时，电子设备可将非易失性存储器中存储的可执行代码加载到随机存取存储器。

外部存储器接口120可以用于连接外部的非易失性存储器，实现扩展电子设备的存储能力。

电子设备可以通过音频模块130，扬声器130A，受话器130B，麦克风130C，耳机接口130D，以及应用处理器等实现音频功能。

音频模块130用于将数字音频信息转换成模拟音频信号输出，也用于将模拟音频输入转换为数字音频信号。扬声器130A，也称“喇叭”，用于将音频电信号转换为声音信号。受话器130B，也称“听筒”，用于将音频电信号转换成声音信号。麦克风130C，也称“话筒”，“传声器”，用于将声音信号转换为电信号。耳机接口130D用于连接有线耳机。

在本申请实施例中，电子设备在开启语音转文本的功能的情况下，可以启用麦克风130C采集声音信号，并将声音信号转换为相应的文字。

触摸传感器160，也称“触控器件”。触摸传感器160可以设置于显示屏140，由触摸传感器160与显示屏140组成触摸屏，也称“触控屏”。触摸传感器160用于检测作用于其上或附近的触摸操作。触摸传感器可以将检测到的触摸操作传递给应用处理器，以确定触摸事件类型。可以通过显示屏140提供与触摸操作相关的视觉输出。在另一些实施例中，触摸传感器160也可以设置于电子设备的表面，与显示屏140所处的位置不同。

以上实施例仅用以说明本申请的技术方案，而非对其限制；尽管参照前述实施例对本申请进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本申请各实施例技术方案的范围。

Claims (17)

1.一种内存修复清理方法，其特征在于，应用于电子设备；所述方法包括：

所述电子设备接收冷启动第一应用的第一指令；

响应于所述第一指令，所述电子设备复制zygote虚拟机，得到第一应用虚拟机；所述第一应用虚拟机中的Java内存空间为第一Java内存空间；

在满足第一预设条件的情况下，所述电子设备基于所述第一应用当前运行状态确定所述第一应用是否处于用户无感知状态；

若所述第一应用处于所述用户无感知状态，所述电子设备销毁所述第一应用；

其中，所述第一预设条件包括：所述第一Java内存空间的已占用内存大于第一阈值，以及所述第一应用驻留在后台的时长大于第一时长。

2.如权利要求1所述的方法，其特征在于，所述电子设备基于所述第一应用当前运行状态确定所述第一应用是否处于用户无感知状态，具体包括：

所述电子设备通过确定所述第一应用当前运行状态是否包括可感知状态项来确定所述第一应用是否处于所述用户无感知状态；

所述第一应用处于所述用户无感知状态，具体包括：所述第一应用当前的运动状态中不包括所述可感知状态项；

其中，所述可感知状态项包括以下任意一项或多项：小窗显示，下载，后台播放。

3.如权利要求1或2所述的方法，其特征在于，所述电子设备基于所述第一应用当前运行状态确定所述第一应用是否处于用户无感知状态之后，所述方法还包括：

若所述第一应用未处于所述用户无感知状态，所述电子设备间隔第二时长后重新基于所述第一应用当前运行状态确定所述第一应用是否处于所述用户无感知状态。

4.如权利要求3所述的方法，其特征在于，所述电子设备间隔第二时长后重新基于所述第一应用当前运行状态确定所述第一应用是否处于所述用户无感知状态之后，所述方法还包括：

若所述电子设备连续X次确定所述第一应用未处于所述用户无感知状态，所述电子设备停止执行所述间隔第二时长后重新基于所述第一应用当前运行状态确定所述第一应用是否处于所述用户无感知状态的步骤；所述X为大于等于2的整数。

5.如权利要求1-4中任一项所述的方法，其特征在于，所述电子设备基于所述第一应用当前运行状态确定所述第一应用是否处于用户无感知状态之前，所述方法还包括：

在所述第一Java内存空间的已占用内存大于所述第一阈值的情况下，所述电子设备通过所述第一应用虚拟机向所述电子设备中的SystemServer进程发送内存泄露消息；

所述电子设备通过所述SystemServer进程确定所述第一应用是否在前台。

6.如权利要求5所述的方法，其特征在于，所述在满足第一预设条件的情况下，所述电子设备基于所述第一应用当前运行状态确定所述第一应用是否处于用户无感知状态，具体包括：

在所述第一应用在前台的情况下，若所述第一应用从前台切换至后台，所述电子设备通过所述SystemServer进程向所述SystemServer进程发送第一消息，所述电子设备通过所述SystemServer进程接收所述第一消息后，基于所述第一应用当前运行状态确定所述第一应用是否处于所述用户无感知状态；所述第一消息为延迟第三时长发送的handle消息；所述第三时长大于或等于所述第一时长。

7.如权利要求5所述的方法，其特征在于，所述在满足第一预设条件的情况下，所述电子设备基于所述第一应用当前运行状态确定所述第一应用是否处于用户无感知状态，具体包括：

在所述第一应用在后台的情况下，若所述第一应用驻留在后台的时长大于所述第一时长，所述电子设备通过所述SystemServer进程向所述SystemServer进程发送第二消息，所述电子设备通过所述SystemServer进程接收所述第二消息后，基于所述第一应用当前运行状态确定所述第一应用是否处于所述用户无感知状态。

8.如权利要求5所述的方法，其特征在于，所述在满足第一预设条件的情况下，所述电子设备基于所述第一应用当前运行状态确定所述第一应用是否处于用户无感知状态，具体包括：

在所述第一应用在后台的情况下，若所述第一应用驻留在后台的时长不大于所述第一时长，所述电子设备通过所述SystemServer进程向所述SystemServer进程发送第三消息，所述电子设备通过所述SystemServer进程接收所述第三消息后，基于所述第一应用当前运行状态确定所述第一应用是否处于所述用户无感知状态；所述第三消息为延迟第四时长发送的handle消息；所述第四时长不小于所述第一时长与所述第一应用驻留在后台的时长的差值。

9.如权利要求6-8中任一项所述的方法，其特征在于，所述方法还包括：

所述电子设备通过所述SystemServer进程接收第一消息或第二消息或第三消息后，所述电子设备通过所述SystemServer进程获取所述第一应用的相关进程的相关信息；

所述电子设备销毁所述第一应用，具体包括：所述电子设备基于所述第一应用的相关进程的相关信息清除所述第一应用的所有相关进程。

10.如权利要求1-9中任一项所述的方法，其特征在于，所述第一预设条件还包括：所述第一应用为第一预设应用。

11.如权利要求1-10中任一项所述的方法，其特征在于，所述方法还包括：在所述电子设备销毁所述第一应用之前，若所述第一Java内存空间的已占用内存小于第二阈值，或者第一应用已销毁，所述电子设备不再销毁所述第一应用。

12.如权利要求1-11中任一项所述的方法，其特征在于，所述zygote虚拟机中的Java内存空间为第二Java内存空间；所述第二Java内存空间的内存大小为第一内存；所述第二Java内存空间对应的虚拟地址为第一虚拟地址段和第二虚拟地址段，所述第一虚拟地址段对应的内存大小为所述第一内存，所述第二虚拟地址段对应的内存为所述zygote虚拟机申请的备用虚拟内存；所述第一虚拟地址段对应的内存大小与所述第二虚拟地址段对应的内存大小的和大于所述第二Java内存空间的默认内存；

所述电子设备基于所述第一应用当前运行状态确定所述第一应用是否处于用户无感知状态之前，所述方法还包括：

在满足第二预设条件的情况下，基于所述第二虚拟地址段，所述电子设备将所述第一Java内存空间的内存大小由所述第一内存扩展为第二内存；所述第二内存为第三虚拟地址段对应的内存大小；所述第三虚拟地址段包括所述第一虚拟地址段，以及所述第二虚拟地址段中的部分或全部地址；所述第二内存大于所述第一内存。

13.如权利要求12中所述的方法，其特征在于，所述满足第二预设条件，具体包括：

所述电子设备中的所述第一Java内存空间满足第一内存条件，且所述电子设备中的所述第一应用为第二预设应用；

其中，所述第一Java内存空间满足所述第一内存条件，具体包括：所述第一Java内存空间中的已占用内存达到第三阈值，和/或所述第一Java内存空间中的已占用内存的增长率大于第四阈值。

14.如权利要求12所述的方法，其特征在于，所述满足第二预设条件，具体包括：

所述电子设备中的所述第一Java内存空间满足第一内存条件，且所述电子设备中的所述第一应用为第二预设应用，且所述电子设备的操作系统的未占用内存大于第五阈值；

其中，所述第一Java内存空间满足所述第一内存条件，具体包括：所述第一Java内存空间中的已占用内存达到第三阈值，和/或所述第一Java内存空间中的已占用内存的增长率大于第四阈值。

15.如权利要求12-14中任一项所述的方法，其特征在于，所述第一内存为所述第二Java内存空间的默认内存。

16.一种电子设备，包括一个或多个存储器，以及一个或多个处理器，其特征在于，所述存储器用于存储计算机程序；所述处理器用于调用所述计算机程序，使得所述电子设备执行权利要求1-15中任一项所述的方法。

17.一种计算机存储介质，其特征在于，包括：计算机指令；当所述计算机指令在电子设备上运行时，使得所述电子设备执行权利要求1-15中任一项所述的方法。