CN115809139A

CN115809139A - 内存管理的方法及电子设备

Info

Publication number: CN115809139A
Application number: CN202211516173.XA
Authority: CN
Inventors: 肖名鹏; 李鹏; 李璐; 万笑凡
Original assignee: Honor Device Co Ltd
Current assignee: Honor Device Co Ltd
Priority date: 2021-06-16
Filing date: 2021-06-16
Publication date: 2023-03-17
Also published as: EP4145286A4; EP4145286A1; CN113434288A; CN113434288B; WO2022262530A1

Abstract

本申请实施例提供了一种内存管理的方法及电子设备，属于存储技术领域。该方法包括：启动应用程序，并向所述应用程序提供虚拟内存；检测所述应用程序在运行过程中占用的所述虚拟内存的空间；当所述占用的所述虚拟内存的空间大于第一阈值时，检测所述应用程序运行的进程的位数；根据所述应用程序运行的进程的位数，对所述应用程序执行杀进程的操作。上述方法通过根据运行中的应用程序发生的内存异常时对虚拟内存的占用情况结合多维度信息，按照预设策略对特定应用程序进行查杀，从而解决内存泄露的问题。

Description

内存管理的方法及电子设备

本申请是分案申请，原申请的申请号是202110669220.3，原申请的申请日是2021年6月16日，原申请的全部内容通过引用结合在本申请中。

技术领域

本申请涉及存储技术领域，尤其涉及一种内存管理的方法及电子设备。

背景技术

内存泄露(memory leak)是指由于应用程序(application，APP)运行逻辑发生错误导致不再使用的内存没有被释放，或者由于应用程序处理性能较差导致内存没有及时被释放，进而导致占用内存不断积压的现象。目前，内存泄露问题仍是软件领域的痛点问题。资源、对象、图片、线程、文件、显示等不当使用，都可能导致内存泄露。

应用程序在运行过程中如果发生内存泄漏，已被申请的内存会一直处于被占用状态，无法被释放再利用，由于系统的内存资源是有限的，此后应用程序每一次动态申请内存，都会使系统的内存资源越来越少，最终影响业务的正常运行。

因此，如何缓解内存泄露的问题，优化电子设备的内存性能，提高用户的使用体验，成为当下重要的研究课题。

发明内容

本申请提供了一种内存管理的方法及电子设备，通过根据运行中的应用程序发生的内存异常时对虚拟内存的占用情况结合多维度信息，按照预设策略对特定应用程序进行查杀，从而解决内存泄露的问题。

第一方面，提供了一种内存管理的方法，应用于电子设备，包括：启动应用程序，并向所述应用程序提供虚拟内存；检测所述应用程序在运行过程中占用的所述虚拟内存的空间；当所述占用的所述虚拟内存的空间大于第一阈值时，检测所述应用程序运行的进程的位数；根据所述应用程序运行的进程的位数，对所述应用程序执行杀进程的操作。

其中，目标进程的位数可以用于指示应用程序运行的为多少位的进程，如32位进程或64位进程等。对应用程序执行杀进程的操作在下文也可以被描述为对应用程序进行查杀。

在一种实现方式中，由于不同位数的应用程序能支持的最大的虚拟内存不同，比如32位应用程序能支持的最大的虚拟内存为4G，因此，第一阈值可以根据应用程序运行的进程的位数确定，例如，对于运行32位进程的应用程序，第一阈值可以设置为3.2G或3.5G等。换言之，第一阈值与应用程序运行的进程的位数之间可以具有对应关系。

根据本实现方式提供的方法，可以设置应用程序对应的可占用虚拟内存空间的阈值，在应用程序运行过程中，如果检测到应用程序占用的虚拟内存空间大于该阈值时，可进一步判断该进程的位数，结合进程的位数信息确定该应用程序是否导致内存泄露，若是，则对该应用程序进行查杀，从而准确地对内存占用异常的应用程序进行处理，有效管理内存资源。

结合第一方面，在第一方面的某些实现方式中，所述根据所述应用程序运行的进程的位数，对所述应用程序执行杀进程的操作，具体包括：当根据所述应用程序运行的进程的位数确定所述应用程序运行的进程为目标进程时，对所述应用程序执行杀进程的操作。

应理解，这里的目标进程可以包括与第一阈值对应的进程，例如在第一阈值是根据32位应用程序支持的最大的虚拟内存设置的情况下，则目标进程可以是32位进程；或者，目标进程也可以指与第一阈值不具有对应关系，但满足其他应用程序查杀条件的进程，例如占用的虚拟内存达到预设阈值的进程等。

根据本实现方式提供的方法，通过根据应用程序运行的进程位数确定应用程序运行的为目标进程时，对该应用程序进行查杀，能够准确地对内存占用异常的应用程序进行处理，有效管理内存资源，避免直接查杀应用程序干扰用户使用应用程，导致用户体验较差的问题。

结合第一方面，在第一方面的某些实现方式中，所述当根据所述应用程序运行的进程的位数确定所述应用程序运行的进程为目标进程时，对所述应用程序执行杀进程的操作，具体包括：当根据所述应用程序运行的进程位数确定所述应用程序运行的为32位进程时，对所述应用程序执行杀进程的操作。

结合第一方面，在第一方面的某些实现方式中，当所述应用程序处于后台运行状态时，所述方法还包括：当根据所述应用程序运行的进程位数确定所述应用程序运行的为32位进程时，检测所述应用程序处于所述后台运行状态的时长；当所述应用程序处于所述后台运行状态的时长大于预设时长时，对所述应用程序执行杀进程的操作。

应理解，在一些情形下，如果应用程序切换至后台运行状态的时间较短，可能意味着用户暂时性地不使用该应用程序，因此，为了避免直接查杀用户暂时性切换至后台，但后续仍需继续使用的应用程序，在本实现方式中进一步判断应用程序处于后台运行状态的时长，当该时长大于预设时长时，才对该应用程序进行查杀。

根据本实现方式提供的方法，当应用程序运行的进程满足目标进程时，可以进一步判断应用程序处于后台运行状态的时长，当其处于后台运行状态的时长大于预设时长时，才对应用程序执行杀进程的操作。通过进一步结合应用程序处于后台状态的时长，判断是否对应用程序进行查杀，可以避免对某一应用程序查杀后，干扰用户对应用程序的使用，从而使用户使用体验下降的问题。

结合第一方面，在第一方面的某些实现方式中，所述当所述应用程序处于所述后台运行状态的时长大于预设时长时，对所述应用程序执行杀进程的操作，还包括：当所述应用程序处于所述后台运行状态的时长大于预设时长时，检测所述应用程序的类型；当所述应用程序的类型满足预设类型时，对所述应用程序执行杀进程的操作。

应理解，满足预设类型的应用程序是指发生内存泄露时，在满足目标位进程的情况下可以进行查杀的应用程序。示例性的，满足预设类型的应用程序可以对可以包括对用户使用体验影响较大或对用户较为重要的应用程序。

在一些实现方式中，用户可以根据需要自主设置某一应用程序为能够进行查杀的应用程序；或者，系统可以默认特定的应用程序作为预设类型的应用程序；或者，也可以通过向用户查询的方式确定应用程序是否为预设类型的应用程序等。

根据本实现方式提供的方法，对于处于后台运行状态中的应用程序，可以结合该应用程序运行的进程、处于后台运行状态的时长和应用程序的类型，判断是否对其进行查杀，换言之，可以在确定该应用程序为目标位进程(即32位进程)且处于后台运行时间大于预设时长后，再判断该应用程序对应的类型是否属于预设类型，如果是，表示该应用程序具有查杀的必要性，则对该应用程序进行杀进程的操作。通过检测运行32位进程的应用程序是否属于预设类型的应用程序，并对符合预设类型的应用程序进行杀进程操作，可以避免直接查杀对用户较为重要的应用程序，影响用户的体验。

结合第一方面，在第一方面的某些实现方式中，所述预设类型的应用程序包括以下至少一种：通讯类型的所述应用程序、工具类型的所述应用程序、购物类型的所述应用程序、新闻类型的所述应用程序、新闻类型的所述应用程序。

结合第一方面，在第一方面的某些实现方式中，当所述应用程序处于前台运行状态时，所述方法还包括：检测系统物理内存的剩余空间；当所述系统物理内存的剩余空间小于第二阈值时，检测所述应用程序在运行过程中占用的所述虚拟内存的空间。

应理解，一般来说，前台运行状态的应用程序可能是用户正在使用中的应用程序，如果直接对其进行查杀，会对用户的正常使用造成干扰，因此，针对前台运行的应用程序，可以进一步检测系统物理内存的剩余空间，只有当该剩余空间小于第二阈值时，才执行对应用程序占用虚拟内存的检测操作。

结合第一方面，在第一方面的某些实现方式中，当确定所述应用程序对应的进程为非32位进程时，检测所述应用程序在运行过程中占用的物理内存的空间；当所述占用的物理内存的空间大于第三阈值时，对所述应用程序执行杀进程的操作。

根据本实现方式提供的方法，通过对运行的进程不是32位进程的应用程序进一步判断其占用的物理内存的空间，能够更加准确地确定该应用程序是否具有查杀的必要性，从而避免直接查杀应用程序导致的用户体验下降。

结合第一方面，在第一方面的某些实现方式中，所述检测所述应用程序在运行过程中占用的所述虚拟内存的空间，还包括：在所述应用程序的运行过程中，检测是否发生触发事件；当确定发生所述触发事件时，检测所述应用程序在运行过程中占用的所述虚拟内存的空间。

结合第一方面，在第一方面的某些实现方式中，所述当确定发生所述触发事件时，检测所述应用程序在运行过程中占用的所述虚拟内存的空间，具体包括：当确定所述电子设备中空闲的所述系统内存的空间小于第四阈值时，检测所述应用程序在运行过程中占用的所述虚拟内存的空间；或者，当确定满足预设周期时，检测所述应用程序在运行过程中占用的所述虚拟内存的空间；或者，当确定所述应用程序申请所述虚拟内存的速率大于第五阈值时，检测所述应用程序在运行过程中占用的所述虚拟内存的空间。

应理解，不管对于处于后台运行的应用程序还是处于前台运行的应用程序来说，电子设备执行这些应用程序占用的虚拟内存的检测操作可以是在触发事件的触发下执行的，也即当有触发事件发生时，电子设备才会执行对运行中的应用程序占用的虚拟内存进行检测以及后续进行的杀进程的操作。

第二方面，提供了一种电子设备，包括：一个或多个处理器；一个或多个存储器；所述一个或多个存储器存储有一个或多个计算机程序，所述一个或多个计算机程序包括指令，当所述指令被所述一个或多个处理器执行时，使得所述电子设备实现如第一方面中任一实现方式所述的内存管理的方法。

第三方面，提供了一种计算机可读存储介质，所述计算机可读存储介质存储有计算机程序，所述计算机程序包括指令，当所述指令在被计算机调用时，使所述计算机执行如第一方方面中任一实现方式所述的内存管理的方法。

第四方面，提供了一种芯片系统，包括：通信接口，用于输入和/或输出信息；存储器，用于存储计算机可执行程序；处理器，用于执行所述计算机可执行程序，使得安装有所述芯片系统的设备执行如第一方面中任一实现方式所述的内存管理的方法。

第五方面，提供了一种计算机程序产品，所述计算机程序产品包括计算机程序指令，当所述计算机程序指令在计算机上运行时，使得计算机实现如第一方面中任一实现方式所述的内存管理的方法。

附图说明

图1是一种内存泄露的示意性流程图。

图2是本申请实施例提供的一种电子设备的结构示意图。

图3是本申请实施例提供的一种电子设备的软件结构示意图。

图4是本申请实施例提供的一种内存管理的方法的示意性流程图。

图5是本申请实施例提供的一种系统各进程占用的物理内存示意图。

图6是本申请实施例提供的另一种内存管理的方法的示意性流程图。

图7A至图7D是本申请实施例提供的一些图形用户界面示意图。

图8是本申请实施例提供的一种应用程序查杀提示信息示意图。

图9是本申请实施例提供的又一种内存管理的方法的示意性流程图。

具体实施方式

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

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

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

本申请实施例的技术方案可以应用于各种通信系统。例如：全球移动通讯(globalsystem of mobile communication，GSM)系统、码分多址(code division multipleaccess，CDMA)系统、宽带码分多址(wideband code division multiple access，WCDMA)系统、通用分组无线业务(general packet radio service，GPRS)、长期演进(long termevolution，LTE)系统、LTE频分双工(frequency division duplex，FDD)系统、LTE时分双工(time division duplex，TDD)、通用移动通信系统(universal mobiletelecommunication system，UMTS)、全球互联微波接入(worldwide interoperabilityfor microwave access，WiMAX)通信系统、未来的第五代(5th generation，5G)系统或新无线(new radio，NR)等。

为了更好地理解本申请实施例提供的内存泄露管理的方法，下文首先对本申请实施例中涉及的术语定义进行介绍。

(1)物理内存(physical memory)：物理内存是相对于虚拟内存而言的，指通过物理内存条而获得的内存空间。

(2)虚拟内存(virtual memory)：操作系统中内存管理的一种技术，是操作系统提供的一种对内存的抽象，虚拟内存可以不受限于物理内存空间的限制。在应用程序进程看来，应用程序进程拥有连续的可用的虚拟内存空间(一段连续完整的地址空间)，而实质上，这段虚拟内存空间通常会被映射到物理内存中不连续的地址空间。

(3)系统内存：包括物理内存和虚拟内存，主要作用为在电子设备运行时为操作系统和各种应用程序提供临时存储。

(4)动态内存申请函数：可以用于动态申请系统中的内存，可以根据函数的申请参数值大小指定申请的内存，该函数可以返回申请到的内存的首地址(或称内存地址)。

(5)内存释放函数：可用于对动态内存申请函数申请到的内存进行释放。

(6)低内存杀手(low memory killer，LMK)：为安卓

内核层对低内存按一定策略查杀进程释放内存的管理机制。当系统低内存时，会触发查杀一些后台等优先级比较低的进程。

(7)运行状态：应用程序在操作系统中的运行状态可以分为前台运行状态和后台运行状态。前台运行状态，是指应用程序直接在显示屏的显示窗口或界面上运行，呈现出程序运行的当前界面，使电子设备可以与使用者(即用户)通过显示的界面互动。后台运行状态，是指显示屏不呈现应用程序的运行界面，但该应用程序在后台继续提供服务。对于具有可视的显示界面的应用程序来说，其可以随时从后台运行状态切换为前台运行状态，或者从前台运行状态切换为后台运行状态。

结合背景技术介绍的内容，内存持续泄露导致系统内存剩余空间较少时，虚拟机将频繁触发垃圾回收(garbage collection，GC)，这会导致在用户使用手机等电子设备的过程中，出现某一应用程序突然卡顿、响应速度慢、显示异常甚至退出应用等现象，严重影响用户的使用体验。为更好地理解本申请实施例提供的内存管理的方法，下文将以用户使用某一32位的视频应用程序观看视频的场景为例，对内存泄露产生的原理进行介绍。

应理解，一个应用程序可以对应一个进程，一个进程可以包括一个或多个线程。当启动视频应用程序时，系统会为该应用程序创建一个32位的进程。在进程运行过程中，系统还会根据进程的申请为其分配最大为4GB(即2的32次方)的虚拟内存，之所以是4G，是因为在32位操作系统中，一个指针长度为4字节，而4字节指针的寻址能力是从0×00000000～0×FFFFFFFF，最大值0×FFFFFFFF表示的即为4GB大小的虚拟内存空间。该虚拟内存地址空间与物理内存地址之间具有映射关系，当操作系统做虚拟地址到物理地址映射时，会将物理地址映射至该范围内，每个进程只能访问自己虚拟空间中的数据，而无法访问该虚拟内存之外的数据。

示例性的，如图1所示，为一种内存泄漏的示意性流程图。图1实施例以视频应用程序的绘图对象发生内存泄露时的内存申请过程为例进行说明，该过程包括以下步骤：

S101，启动视频应用程序。

S102，应用程序绘图对象申请图形缓冲区(GraphicBuffer)。

在视频应用程序启动或运行过程中，进程需要为绘图类型的任务(或称线程)申请系统内存以存储该类任务下的数据(如位图数据)，因而该步骤用于创建能被应用程序访问的内存空间。

S103，调用GraphicBufferMapper将图形Buffer映射到应用程序进程。

其中，当在步骤S102中申请到图形缓冲区后，可以调用预设函数GraphicBufferMapper锁定该图形缓冲区，并将锁定的图形缓冲区映射至当前视频应用程序进程。

S104，申请进程间共享使用图形缓冲区。

视频应用程序的绘图对象(可用于执行绘图类型任务中的任一线程)可以申请使用图形缓冲区，该绘图对象可用于执行至少一种上述所说的绘图类型的任务。

S105，内存申请返回。

其中，若绘图任务当前占用的虚拟内存较少(如小于3.7G)时，图形缓冲区分配器可以向该视频应用的绘图对象成功返回其申请的内存，之后，可以执行步骤S106，也即申请的图形缓冲区可以正常映射至应用程序的虚拟内存中。

若绘图任务发生内存泄露，导致其占用的虚拟内存大于预设值(如3.7GB)时，图形缓冲区分配器无法向该视频应用的绘图对象返回其申请的内存，也即内存申请返回失败，此时，绘图对象则可以执行步骤S107至步骤S110(或步骤S111)，通过GraphicBufferAllocator进程接口继续申请系统内存。

以步骤S105中内存申请返回失败为例，对继续申请内存的过程进行介绍：

S107，绘图对象调用图形缓冲区分配(GraphicBufferAllocator)进程接口向内存管理器申请系统内存。

S108，图形缓冲区分配(GraphicBufferAllocator)进程接口向内存管理器申请视频应用程序绘图对象使用的系统内存。

S109，内存管理器响应于内存申请，返回申请的内存。

其中，若内存管理器成功返回内存，则申请的图形缓冲区可以被映射到应用程序的虚拟内存；若内存管理器返回内存失败，则表明可能该绘图对象此时出现内存泄露。

结合上述过程，应理解，在正常情况下，视频应用程序的某一线程运行结束后，该线程占用的内存不再需要被占用，会被释放。然而，如果由于某些原因系统已分配给该线程的堆内存没有被释放或者没有被及时被释放(即内存泄露)，就会导致当前应用周期内不再使用的线程所占用的内存无法被回收再利用。视频应用程序为保证正常运行，在此后的运行过程中可能还会申请更多的内存，使得视频应用程序占用的内存越来越多，系统的内存资源越来越少。随着视频应用程序累积的内存资源越来越多，虚拟机将频繁触发垃圾回收机制，导致应用程序卡顿、响应速度变慢等问题。接着，当视频应用程序占用的虚拟内存累积高至接近其支持的最大虚拟内存(4GB)时，由于用于继续申请系统内存的进程接口(graphicbufferallocator)为64位进程，因而该进程仍可以继续向内存管理器申请内存，但实际上系统分配给该应用程序的内存却无法再被映射至虚拟内存，并且由于该内存已经被应用申请，系统会将该内存标记为处于应用程序使用中，使得该内存无法再被分配给其它应用程序。由于本次未成功获取申请的系统内存，应用程序之后会重复上述过程继续申请系统内存，由此导致系统中实际可用的内存空间越来越少，系统处于内存泄露状态。内存持续泄露，最终可能使整个系统内存被耗尽，导致系统卡死。

综上分析，内存泄露问题不仅会影响应用程序的正常运行，还可能导致系统和应用程序崩溃，严重时需要用户采用强制重启电子设备等方式才能恢复正常使用，给用户带来较差的体验。

针对内存泄露的问题，目前采用的方法通常是：电子设备在进行内存优化时，通常只要空闲的系统内存低于一定阈值，就会触发杀进程(或称查杀进程)回收内存的机制，由于优先级的限制，该机制一般会选择后台的进程进行查杀。以安卓操作系统为例，安卓操作系统中的查杀回收内存的机制为低内存查杀(low memory killer，LMK)机制，LMK机制主要通过oom_adj判断进程的重要性，oom_adj值越小说明程序越重要，被查杀的可能性越低，其中，后台运行的应用程序的优先级oom_adj的值为正值，前台运行的应用程序的优先级oom_adj的值为0，因此，当安卓系统发生系统低内存触发该LMK机制后，会优先选择后台进程杀掉，而通常不会查杀前台进程。

然而，目前直接对某一后台程序进行查杀的内存回收方式，未结合具体应用场景考虑用户对应用程序的使用体验。例如，在用户观看视频的过程中，如果有其它事项需要处理，暂时切换至其他应用程序，此时若直接查杀后台运行的视频应用程序，那么当用户向再次观看视频时，就无法直接切换至之前的视频播放页面，使用户体验较差。此外，如果前台应用程序为主要的内存泄露源头，那么只查杀后台应用的进程也无法从根本上解决内存泄露的问题，最终仍然会出现系统和应用程序卡死等问题。

针对现有技术存在的上述问题，本申请实施例提供了一种内存管理的方法，通过根据应用程序占用的虚拟内存空间判断发生内存泄漏，再结合应用程序的运行状态等多维度信息，按照预设策略有针对性地对某些应用程序进行查杀，从而根据用户的使用需求，灵活地对应用程序进行查杀，以提升用户的使用体验。

本申请实施例提供的内存管理的方法可以应用于多种类型的电子设备中，如手机、可穿戴设备(如智能手表、智能手环、智能眼镜、智能首饰等)、平板电脑、车载设备、增强现实(augmented reality，AR)/虚拟现实(virtual reality，VR)设备、笔记本电脑、超级移动个人计算机(ultra-mobile personal computer，UMPC)、上网本、个人数字助理(personal digital assistant，PDA)、智能电视、智慧屏以及其他具有显示屏幕的电子设备。上述电子设备也可以是其他电子设备，诸如具有触敏表面(例如触控面板)的膝上型计算机(laptop)等，本申请实施例对电子设备的具体类型不做任何限制。

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

如图2所示，电子设备100可以包括处理器110，外部存储器接口120，内部存储器121，通用串行总线(universal serial bus，USB)接口130，充电管理模块140，电源管理模块141，电池142，天线1，天线2，移动通信模块150，无线通信模块160，音频模块170，扬声器170A，受话器170B，麦克风170C，耳机接口170D，传感器模块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的等待时间，因而提高了系统的效率。

在一些实施例中，处理器110可以包括一个或多个接口。接口可以包括集成电路(inter-integrated circuit，I2C)接口，集成电路内置音频(inter-integrated circuitsound，I2S)接口，脉冲编码调制(pulse code modulation，PCM)接口，通用异步收发传输器(universal asynchronous receiver/transmitter，UART)接口，移动产业处理器接口(mobile industry processor interface，MIPI)，通用输入输出(general-purposeinput/output，GPIO)接口，用户标识模块(subscriber identity module，SIM)接口，和/或通用串行总线(universal serial bus，USB)接口等。

I2C接口是一种双向同步串行总线，包括一根串行数据线(serial data line，SDA)和一根串行时钟线(derail clock line，SCL)。在一些实施例中，处理器110可以包含多组I2C总线。处理器110可以通过不同的I2C总线接口分别耦合触摸传感器180K，充电器，闪光灯，摄像头193等。例如：处理器110可以通过I2C接口耦合触摸传感器180K，使处理器110与触摸传感器180K通过I2C总线接口通信，实现电子设备100的触摸功能。

I2S接口可以用于音频通信。在一些实施例中，处理器110可以包含多组I2S总线。处理器110可以通过I2S总线与音频模块170耦合，实现处理器110与音频模块170之间的通信。在一些实施例中，音频模块170可以通过I2S接口向无线通信模块160传递音频信号，实现通过蓝牙耳机接听电话的功能。

PCM接口也可以用于音频通信，将模拟信号抽样，量化和编码。在一些实施例中，音频模块170与无线通信模块160可以通过PCM总线接口耦合。在一些实施例中，音频模块170也可以通过PCM接口向无线通信模块160传递音频信号，实现通过蓝牙耳机接听电话的功能。所述I2S接口和所述PCM接口都可以用于音频通信。

UART接口是一种通用串行数据总线，用于异步通信。该总线可以为双向通信总线。它将要传输的数据在串行通信与并行通信之间转换。在一些实施例中，UART接口通常被用于连接处理器110与无线通信模块160。例如：处理器110通过UART接口与无线通信模块160中的蓝牙模块通信，实现蓝牙功能。在一些实施例中，音频模块170可以通过UART接口向无线通信模块160传递音频信号，实现通过蓝牙耳机播放音乐的功能。

MIPI接口可以被用于连接处理器110与显示屏194，摄像头193等外围器件。MIPI接口包括摄像头串行接口(camera serial interface，CSI)，显示屏串行接口(displayserial interface，DSI)等。在一些实施例中，处理器110和摄像头193通过CSI接口通信，实现电子设备100的拍摄功能。处理器110和显示屏194通过DSI接口通信，实现电子设备100的显示功能。

GPIO接口可以通过软件配置。GPIO接口可以被配置为控制信号，也可被配置为数据信号。在一些实施例中，GPIO接口可以用于连接处理器110与摄像头193，显示屏194，无线通信模块160，音频模块170，传感器模块180等。GPIO接口还可以被配置为I2C接口，I2S接口，UART接口，MIPI接口等。

USB接口130是符合USB标准规范的接口，具体可以是Mini USB接口，Micro USB接口，USB Type C接口等。USB接口130可以用于连接充电器为电子设备100充电，也可以用于电子设备100与外围设备之间传输数据。也可以用于连接耳机，通过耳机播放音频。该接口还可以用于连接其他终端，例如AR设备等。

可以理解的是，本发明实施例示意的各模块间的接口连接关系，只是示意性说明，并不构成对电子设备100的结构限定。在本申请另一些实施例中，电子设备100也可以采用上述实施例中不同的接口连接方式，或多种接口连接方式的组合。

充电管理模块140用于从充电器接收充电输入。其中，充电器可以是无线充电器，也可以是有线充电器。在一些有线充电的实施例中，充电管理模块140可以通过USB接口130接收有线充电器的充电输入。在一些无线充电的实施例中，充电管理模块140可以通过电子设备100的无线充电线圈接收无线充电输入。充电管理模块140为电池142充电的同时，还可以通过电源管理模块141为终端供电。

电源管理模块141用于连接电池142，充电管理模块140与处理器110。电源管理模块141接收电池142和/或充电管理模块140的输入，为处理器110，内部存储器121，外部存储器，显示屏194，摄像头193，和无线通信模块160等供电。电源管理模块141还可以用于监测电池空间，电池循环次数，电池健康状态(漏电，阻抗)等参数。在其他一些实施例中，电源管理模块141也可以设置于处理器110中。在另一些实施例中，电源管理模块141和充电管理模块140也可以设置于同一个器件中。

电子设备100的无线通信功能可以通过天线1，天线2，移动通信模块150，无线通信模块160，调制解调处理器以及基带处理器等实现。

天线1和天线2用于发射和接收电磁波信号。电子设备100中的每个天线可用于覆盖单个或多个通信频带。不同的天线还可以复用，以提高天线的利用率。例如：可以将天线1复用为无线局域网的分集天线。在另外一些实施例中，天线可以和调谐开关结合使用。

移动通信模块150可以提供应用在电子设备100上的包括2G/3G/4G/5G等无线通信的解决方案。移动通信模块150可以包括至少一个滤波器，开关，功率放大器，低噪声放大器(low noise amplifier，LNA)等。移动通信模块150可以由天线1接收电磁波，并对接收的电磁波进行滤波，放大等处理，传送至调制解调处理器进行解调。移动通信模块150还可以对经调制解调处理器调制后的信号放大，经天线1转为电磁波辐射出去。在一些实施例中，移动通信模块150的至少部分功能模块可以被设置于处理器110中。在一些实施例中，移动通信模块150的至少部分功能模块可以与处理器110的至少部分模块被设置在同一个器件中。

调制解调处理器可以包括调制器和解调器。其中，调制器用于将待发送的低频基带信号调制成中高频信号。解调器用于将接收的电磁波信号解调为低频基带信号。随后解调器将解调得到的低频基带信号传送至基带处理器处理。低频基带信号经基带处理器处理后，被传递给应用处理器。应用处理器通过音频设备(不限于扬声器170A，受话器170B等)输出声音信号，或通过显示屏194显示图像或视频。在一些实施例中，调制解调处理器可以是独立的器件。在另一些实施例中，调制解调处理器可以独立于处理器110，与移动通信模块150或其他功能模块设置在同一个器件中。

无线通信模块160可以提供应用在电子设备100上的包括无线局域网(wirelesslocal area networks，WLAN)(如无线保真(wireless fidelity，Wi-Fi)网络)，蓝牙(bluetooth，BT)，全球导航卫星系统(global navigation satellite system，GNSS)，调频(frequency modulation，FM)，近距离无线通信技术(near field communication，NFC)，红外技术(infrared，IR)等无线通信的解决方案。无线通信模块160可以是集成至少一个通信处理模块的一个或多个器件。无线通信模块160经由天线2接收电磁波，将电磁波信号调频以及滤波处理，将处理后的信号发送到处理器110。无线通信模块160还可以从处理器110接收待发送的信号，对其进行调频，放大，经天线2转为电磁波辐射出去。

在一些实施例中，电子设备100的天线1和移动通信模块150耦合，天线2和无线通信模块160耦合，使得电子设备100可以通过无线通信技术与网络以及其他设备通信。所述无线通信技术可以包括全球移动通讯系统(global system for mobile communications，GSM)，通用分组无线服务(general packet radio service，GPRS)，码分多址接入(codedivision multiple access，CDMA)，宽带码分多址(wideband code division multipleaccess，WCDMA)，时分码分多址(time-division code division multiple access，TD-SCDMA)，长期演进(long term evolution，LTE)，BT，GNSS，WLAN，NFC，FM，和/或IR技术等。

电子设备100通过GPU，显示屏194，以及应用处理器等实现显示功能。显示屏194用于显示图像，视频等。

电子设备100可以通过ISP，摄像头193，视频编解码器，GPU，显示屏194以及应用处理器等实现拍摄功能。

数字信号处理器用于处理数字信号，除了可以处理数字图像信号，还可以处理其他数字信号。例如，当电子设备100在频点选择时，数字信号处理器用于对频点能量进行傅里叶变换等。视频编解码器用于对数字视频压缩或解压缩。NPU为神经网络(neural-network，NN)计算处理器，通过借鉴生物神经网络结构，例如借鉴人脑神经元之间传递模式，对输入信息快速处理，还可以不断的自学习。

外部存储器接口120可以用于连接外部存储卡，例如Micro SD卡，实现扩展电子设备100的存储能力。外部存储卡通过外部存储器接口120与处理器110通信，实现数据存储功能。例如将音乐，视频等文件保存在外部存储卡中。内部存储器121可以用于存储计算机可执行程序代码，所述可执行程序代码包括指令。

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

压力传感器180A用于感受压力信号，可以将压力信号转换成电信号。陀螺仪传感器180B可以用于确定电子设备100的运动姿态。磁传感器180D包括霍尔传感器。电子设备100可以利用磁传感器180D检测翻盖皮套的开合。加速度传感器180E可检测电子设备100在各个方向上(一般为三轴)加速度的大小。当电子设备100静止时可检测出重力的大小及方向。还可以用于识别终端姿态，应用于横竖屏切换，计步器等应用。接近光传感器180G可以包括例如发光二极管(LED)和光检测器，例如光电二极管。发光二极管可以是红外发光二极管。电子设备100通过发光二极管向外发射红外光。环境光传感器180L用于感知环境光亮度。电子设备100可以根据感知的环境光亮度自适应调节显示屏194亮度。指纹传感器180H用于采集指纹。温度传感器180J用于检测温度。触摸传感器180K，也称“触控面板”。触摸传感器180K可以设置于显示屏194，由触摸传感器180K与显示屏194组成触摸屏，也称“触控屏”。触摸传感器180K用于检测作用于其上或附近的触摸操作。骨传导传感器180M可以获取振动信号。

此外，电子设备100还包括气压传感器180C和距离传感器180F。其中，气压传感器180C用于测量气压。在一些实施例中，电子设备100通过气压传感器180C测得的气压值计算海拔高度，辅助定位和导航。

距离传感器180F，用于测量距离。电子设备100可以通过红外或激光测量距离。在一些实施例中，拍摄场景，电子设备100可以利用距离传感器180F测距以实现快速对焦。

示例性的，如图3所示，为本申请实施例提供的一种电子设备100的软件结构示意图。

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

应用程序层可以包括一系列应用程序包。

如图3所示，应用程序包可以包括相机，图库，日历，通话，地图，导航，WLAN，蓝牙，音乐，视频，短信息等应用程序。

应用程序框架层为应用程序层的应用程序提供应用编程接口(applicationprogramming interface，API)和编程框架。应用程序框架层包括一些预先定义的函数，如动态内存申请函数、内存释放函数等。

如图3所示，Android应用程序框架分为应用层、应用框架层、系统运行库层和Linux内核层。应用框架层包括窗口管理器，内容提供器，视图系统，电话管理器，资源管理器，通知管理器。

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

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

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

电话管理器用于提供电子设备100的通信功能。例如通话状态的管理(包括接通，挂断等)。

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

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

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

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

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

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

表面管理器用于对显示子系统进行管理，并且为多个应用程序提供了2D和3D图层的融合。

媒体库支持多种常用的音频，视频格式回放和录制，以及静态图像文件等。媒体库可以支持多种音视频编码格式，例如:MPEG4，H.264，MP3，AAC，AMR，JPG，PNG等。

三维图形处理库用于实现三维图形绘图，图像渲染，合成，和图层处理等。

2D图形引擎是2D绘图的绘图引擎。

示例性的，在本申请实施例中，2D图形引擎可以用于绘制车辆的地理围栏。

Linux内核层是硬件和软件之间的层。内核层至少包含显示驱动，摄像头驱动，音频驱动，传感器驱动。在本申请实施例中，内存异常分析模块、内存管理模块、内存分配模块等可以设置于Linux内核层。

示例性的，如图4所示，为本申请实施例提供的一种内存管理的方法的示意性流程图。该方法可以由如图2和图3所示的电子设备作为主体来执行，该流程可以包括以下步骤：

S401，启动应用程序，并向该应用程序提供虚拟内存。

其中，应用程序可以包括安卓操作系统自带的应用程序或者第三方应用程序，本申请实施例对此不作限定。示例性的，电子设备启动应用程序的过程例如可以包括：电子设备接收用户点击应用程序图标的操作，并响应于该点击操作启动应用程序；或者，电子设备接收用户通过语音助手输入的指示应用程序打开的操作，并响应于该语音指示启动对应的应用程序。本申请实施例对电子设备启动应用程序的具体场景不作限定。

在一些实施例中，在进程启动过程中，应用程序可以向操作系统申请虚拟内存；响应于应用程序的申请操作，操作系统可以向该应用程序提供虚拟内存。具体地，该过程可以包括；应用程序通过电子设备中的内存分配器调用动态内存申请函数向操作系统申请虚拟内存；响应于应用程序的申请，操作系统可以通过电子设备的内存分配器向应用程序提供对应的虚拟内存空间。

应理解，32位进程的应用程序可用的虚拟内存不超过4GB，因而在正常(即未发生内存泄漏)情况下应用程序申请的虚拟内存应不超过4GB。

S402，检测该应用程序在运行过程中占用的虚拟内存的空间。

在一些实施例中，电子设备可以在满足预设条件时，执行检测应用程序占用虚拟内存空间的操作(下称虚拟内存检测)。该预设条件例如可以分为第一预设条件和第二预设条件，其中，第一预设条件可以是触发电子设备虚拟内存检测的基础条件或简单条件，例如可以包括：(1)系统内存处于低内存状态；(2)达到预设的检测周期等；第二预设条件可以是触发电子设备虚拟内存检测的高级条件或复杂条件，例如可以包括：(1)电子设备剩余的物理内存空间小于第二阈值，该第二阈值例如为200M或300M；(2)电子设备中剩余的物理内存空间达到预设等级；(3)应用程序申请虚拟内存的速率大于第三阈值。

考虑到在实际应用中，处于不同运行状态的应用程序对用户的重要性可能不相同，因而，可以对处于不同运行状态的应用程序分别将第一预设条件和/或第二预设条件设置为虚拟内存检测的触发条件。例如，处于后台运行状态中的应用程序(下称后台应用程序)可能是用户已经使用完毕或者当前不需要使用的应用程序，其对用户的重要性较低，因而可以将第一预设条件作为触发电子设备对后台运行的应用程序进行虚拟内存检测的预设条件。具体来说，也即当系统内存处于低内存状态时，可以触发电子设备执行虚拟内存检测；或者，当达到预设的检测周期时，可以触发电子设备执行虚拟内存检测，也即电子设备每隔一段时间会对该应用程序占用的虚拟内存空间进行一次检测。

又例如，处于前台运行状态中的应用程序(下称前台应用程序)可能是用户正在使用过程中的应用程序，对用户使用的重要性较高，因而可以将第一预设条件和第二预设条件共同作为检测前台运行的应用程序占用的虚拟内存的预设条件，也即电子设备可以依次检测是否满足第一预设条件和第二预设条件，若两者均满足，则可以触发电子设备对该前台应用程序执行虚拟内存检测。示例性的，以上述列举的几种第二预设条件为例，触发对前台应用程序进行虚拟内存检测的过程可以包括以下几种情形：

情形一，当满足任一第一预设条件后，该电子设备可以进一步检测剩余的物理内存空间，当该剩余的物理内存空间小于第二阈值时，可以触发电子设备对该前台应用程序执行虚拟内存检测。其中，第二阈值例如可以设置为200M或300M，本申请对此不作限定。电子设备检测的物理内存剩余量是否小于预设阈值的过程可以包括：电子设备通过内存异常分析模块调用activitymanager.getmemoryInfo接口获取系统当前剩余的物理内存，之后比较该物理内存的剩余量是否小于预设阈值。

情形二，当满足任一第一预设条件后，电子设备可以进一步检测剩余的物理内存空间，当该电子设备中剩余的物理内存空间达到预设等级时，可以触发电子设备对该前台应用程序执行虚拟内存检测。

这里的预设等级可以是根据电子设备剩余的系统内存(如物理内存)预设的杀进程等级。示例性的，如表1所示，为剩余的物理内存空间与其对应的杀进程等级之间的对应关系。

表1

剩余的物理内存	杀进程等级
		小于或等于100M	第一级
大于100M且小于或等于150M	第二级
		大于150M且小于或等于200M	第三级

应理解，上述表1中不同的杀进程等级可以对应不同的查杀条件，具体可以包括以下情形：

1、当杀进程等级为第一级(剩余的物理内存小于或等于100M)时，对应的杀进程过程可以为：确定应用程序占用的虚拟内存空间大于第一阈值后，电子设备检测该应用程序运行的进程的位数，若运行的进程的位数满足目标位数，则直接对应用程序执行杀进程操作，释放应用程序占用的系统内存；

2、当杀进程等级为第二级(剩余的物理内存大于100M且小于或等于150M)时，对应的杀进程过程可以为：确定应用程序占用的虚拟内存空间大于第一阈值且运行的进程的位数满足目标位数后，进一步检测应用程序的类型是否符合查杀类型，若符合，则可以对该应用程序执行杀进程的操作，释放应用程序占用的系统内存；

3、当杀进程等级为第三级(剩余的物理内存大于150M且小于或等于200M)时，对应的杀进程过程可以为：确定应用程序占用的虚拟内存空间大于第一阈值，运行的进程的位数满足目标位数，并且应用程序的类型符合查杀类型后，进一步判断应用程序占用的物理内存是否大于预设阈值，若均符合，则可以对该应用程序执行杀进程的操作，释放应用程序占用的系统内存。

应理解，在本情形二下，若电子设备剩余的物理内存满足某一杀进程等级时，可以被触发执行对前台应用程序的虚拟内存检测操作，若存在内存异常，则后续可以按照该杀进程等级对应的查杀条件查杀应用程序。其中，物理内存剩余空间越少，其对应查杀检测可以越简单，从而能够高效查杀应用程序，优化内存。

还应理解，上述针对不同杀进程等级设置的杀进程的过程仅为示例，在实际应用时，不同的杀进程等级下可以设置不同的杀进程过程或在杀进程之前设置不同的检测项目，本申请实施例对此不作限定。

情形三，当满足任一第一预设条件后，电子设备可以检测应用程序申请虚拟内存的速率，当该申请虚拟内存的速率大于第三阈值时，可以触发电子设备对该前台应用程序执行虚拟内存检测。

电子设备检测应用程序申请虚拟内存的速率的过程可以包括：电子设备可以通过计时器设置检测应用程序进程pid占用的虚拟内存的轮训时间(如2min一轮训)；之后，按照轮训时间周期性地从/proc/pid/status文件的VmSize(虚拟内存)字段查询进程pid占用的虚拟内存的大小，并通过进程接口intgetProcessVssMemoryInfo返回两个时间点t1和t2分别对应的虚拟内存的占用大小Vm1和Vm2；之后，内存异常分析模块可以根据时间点及其分别对应的占用虚拟内存的大小，按照公式(1-1)计算进程pid在t1至t2时间段内申请虚拟内存的平均速率v：

应理解，上述针对前台用程序所列举的第二预设条件仅为示例，在实际应用中，还可以采用其他条件作为触发电子设备对前台应用程序进行内存检测的条件。比如，在另一种实现方式中，当满足任一第一预设条件后，电子设备也可以检测应用程序申请物理内存的速率，若申请物理内存的速率大于预设阈值时，可以触发电子设备对该前台应用程序执行虚拟内存检测。与上述情形三的描述类似，在该实现方式中，电子设备获取应用程序申请的物理内存的速率的过程可以包括：电子设备通过计时器设置检测应用程序进程pid占用的物理内存的轮训时间(如2min一轮训)；之后，可以按照轮训时间周期性地由/proc/pid/status文件中的VmPSS(物理内存)字段查询进程pid占用的物理内存的大小(系统各进程占用的物理内存如图5所示)，并通过进程接口intgetProcessRssMemoryInfo返回两个时间点t3和t4分别对应的物理内存的占用大小Vm3和Vm4；之后，内存异常分析模块可以根据时间点及其分别对应的占用虚拟内存的大小，按照公式(1-2)计算进程pid在t1至t2时间段内申请的物理内存的平均速率：

在一些实施例中，电子设备检测应用程序占用的虚拟内存的空间的过程可以包括：在满足预设条件时，电子设备可以通过内存异常分析模块由/proc/pid/status文件的VmSize(虚拟内存)字段查询应用程序运行的进程pid所占用的虚拟内存的大小。

S403，当占用的所述虚拟内存的空间大于第一阈值时，检测应用程序运行的进程的位数。

在一些实施例中，第一阈值和应用程序运行的进程的位数之间具有对应关系，该第一阈值是根据目标位数的进程所支持的最大虚拟内存而设置的。例如，对于32位进程，由于其支持的最大的虚拟内存为4G，则第一阈值可以设置为接近4G的值，如3.2G或3.5G。

应理解，占用虚拟内存的空间大于第一阈值，意味着该应用程序可能发生内存泄露，但也可能包含其他位数进程正常占用内存的情况，比如，当某一应用程序占用的虚拟内存大于3.5G时，若该应用程序的位数为64位，则该应用程序内存占用正常，可能并不存在内存泄漏。因而，为了准确判断该应用程序是否发生内存泄露，可以进一步检测该应用程序运行的进程是否为目标位数的进程，也即判断应用程序运行的进程与该预设阈值是否对应，若是，则表示应用程序占用的虚拟内容已经达到对应的虚拟内存占用限定值(即预设阈值)，能够确定该应用程序实际发生内存泄漏。

示例性的，以32位和64位为例，电子设备检测应用程序进程位数的过程可以包括以下几种方式：方式一，系统会由zygote分叉出一个子进程来提供应用程序运行的虚拟机和runtime环境；系统中会同时存在两个zygote进程，即对应于32位进程的zygote和对应于64位进程的zygote64，通过intcheckProcessType(intpid)接口传入pid，可以获取返回的进程类型，如10：32位或1：64位，从而获知当前的应用程序为32位或64位进程。方式二，运行时通过native进程的内存映射列表(maps)来检测应用程序为32位进程或64位进程，其中，若应用native程序映射到system/lib，则判断该应用程序为32位进程；方式三，通过判断应用程序的lib库路径确定该应用程序为32位进程或64位进程，其中，当应用程序的lib库的路径为lib/arm等32位进程对应的路径时，确定该应用程序为32位进程。

S404，根据应用程序运行的进程的位数，对该应用程序执行杀进程的操作。

其中，对应用程序执行杀进程是指：在系统内存中清除应用程序的进程，将进程强制退出运行，以释放系统内存，释放的系统内存可以被操作系统重新分配。可选地，在释放应用占用的系统内存后，还可以重启该应用程序，本申请对此不做限定。

在一些实施例中，当根据该应用程序运行的进程的位数确定应用程序运行的进程为目标进程时，可以对应用程序执行杀进程的操作。其中，目标进程例如可以是32位进程。

在一些实施例中，电子设备对应用程序执行杀进程操作的具体过程可以包括：调用android.os.process.killProcess(android.os.Process.myPid)或forcestoppackage进程接口清除系统内存中该应用程序各线程占用的内存，清除后的系统内存可以用于电子设备的内存分配模块重新分配。

可选地，在对应用程序执行完杀进程操作后，还可以重新启动该应用程序，以便应用程序以未发生内存泄露的正常状态运行。

根据本申请实施例提供的内存管理的方法，通过根据运行中的应用程序发生的内存异常占用情况结合应用程序的应用场景等多维度信息，对特定应用程序进行查杀，从而在满足用户对应用程序的不同使用需求的前提下，优化系统内存，提升了用户的使用体验。

为更好地理解本申请实施例提供的内存管理的方法，以下结合附图分别介绍对后台应用程序执行内存管理的过程，以及对前台应用程序执行内存管理的过程。

示例性的，如图6所示，为本申请实施例针对处于后台运行状态的应用程序进行内存管理的示例性流程图。该流程可以由电子设备作为主体来执行，包括以下步骤：

S601，启动应用程序，并向该应用程序提供虚拟内存。

该步骤可以对应于步骤S401，相关描述可参见上述内容，此处不再赘述。

S602，应用程序退至后台运行。

在一些实施例中，应用程序(如视频应用程序)在启动过程中或启动后的很短时间内可以处于前台运行状态，当运行一段时间后可以由前台运行状态退至后台运行状态。例如，用户需要使用电子设备的其它应用程序或功能，将该应用程序切换至后台运行状态。

S603，检测占用的该虚拟内存空间是否大于第一阈值。

在一些实施例中，电子设备可以在满足预设条件时，执行对应用程序的虚拟内存检测。其中，该后台应用程序对应的预设条件可以对应于上述介绍的第一预设条件，例如可以包括：(1)系统内存处于低内存状态；(2)达到预设的检测周期等。

在一些实施例中，当系统内存处于低内存状态时，可以触发电子设备执行虚拟内存检测；或者，当达到预设的检测周期时，可以触发电子设备执行虚拟内存检测，也即电子设备每隔一段时间会对该应用程序占用的虚拟内存空间进行一次检测。

在一些实施例中，当获取后台应用程序当前占用的虚拟内存的空间后，判断该虚拟内存的空间是否大于第一阈值(如3.2GB或3.5GB)，若是，则执行步骤S604；若否，则执行步骤S607，也即继续运行该应用程序。

S604，检测应用程序对应的进程是否为32位进程。

在一些实施例中，当在步骤S603中检测到应用程序占用的虚拟内存大于第一阈值时，电子设备可以进一步判断该应用程序是否为32位进程。若是，则执行步骤S605；若否，则执行步骤S607，也即继续运行该应用程序。

在一些实施例中，内存异常分析模块判断应用程序是否为32位进程的过程可以包括以下几种方式：(1)系统会由zygote分叉出一个子进程来提供应用程序运行的虚拟机和runtime环境；系统中会同时存在两个Zygote进程，即对应于32位进程的zygote和对应于64位进程的zygote64，电子设备通过intcheckProcessType(intpid)接口传入pid，可以获取返回的进程类型，如10：32位或1：64位，从而获知当前的应用程序是否为32位进程；(2)运行时通过native进程的内存映射列表(maps)来检测应用程序为32位进程，其中，若应用native程序映射到system/lib，则判断该应用程序为32位进程；(3)通过判断应用程序的lib库路径确定该应用程序为32位进程，其中，当应用程序的lib库的路径为lib/arm等32位进程对应的路径时，确定该应用程序为32位进程。

S605，判断应用程序的类型是否为预设类型。

应理解，在应用程序处于后台运行状态的场景下，由于应用程序的类型不同，对于某些场景下的应用程序，查杀后对用户的使用体验影响不大，则可以直接对该应用程序执行杀进程；而在另一些场景下，如果对某些后台运行的应用程序执行杀进程操作，会影响用户的使用体验，如给用户的生活、工作、娱乐等带来不利的应用，则即使应用程序占用的虚拟内存大于第一阈值，也可以保持该应用程序继续运行。

在一些实施例中，预设类型的应用程序可以指对其进行杀进程操作后，不会影响用户的使用体验的后台应用程序，例如可以包括：即时通讯类型的应用程序、工具类型的应用程序、购物类型的应用程序、新闻类型的应用程序、新闻类型的应用程序等。不属于该预设类型的应用程序例如可以包括：运行中的游戏类型的应用程序、播放中途退至后台运行的视频类型的应用程序或音乐类型的应用程序、运行中的导航类型的应用程序等。

在一些实施例中，某一类型的应用程序是否属于预设类型的应用程序，可以由用户预先设置。示例性的，以电子设备是手机为例，对用户设置是否允许应用程序被查杀的过程进行介绍。如图7A至图7D所示，为本申请实施例提供的用户设置是否允许应用程序在内存管理时被查杀的过程中的图形用户界面(garphical user interface，GUI)示意图。

如图7A所示，为解锁模式下，手机当前输出的界面内容，该界面内容包括了多款应用程序(Application，App)，例如时钟、日历、图库、备忘录、文件管理、电子邮件、音乐、计算器、视频、运动健康、天气、浏览器、智慧生活、设置、录音机、相机、通讯录、电话、信息等。应理解，在一些实施例中，该界面可以包括比图7A所示更多或更少的应用程序，本申请实施例对此不作限定。

如图7A所示，用户点击设置图标，响应于用户的点击操作，手机运行设置应用程序，并显示如图7B所示的界面。其中，图7B中的界面为设置列表界面，该设置列表可以包括多项用户能够操作的选项，例如包括无线和网络、蓝牙、桌面和壁纸、显示、声音、应用程序管理、电池、存储、健康使用手机、安全和隐私等。应理解，在一些实施例中，该界面可以包括比图7B所示更多或更少的选项或与图7B中类型不同的选项，本申请实施例对此不作限定。

如图7B所示，用户可以点击应用管理设置选项，响应于用户的点击操作，手机可以显示如图7C所示的应用管理界面。如图7C所示，在该应用管理界面可以包括多项手机中已安装的不同类型的应用程序，如视频应用程序、购物应用程序、新闻应用程序(如新闻应用程序1、新闻应用程序2)、金融应用程序等。以视频应用程序为例，当用户需要将该视频应用程序设置为在优化内存时不允许查杀进程时，用户可以点击该视频应用程序，响应于用户的点击操作，手机可以显示如图7D所示的视频应用程序权限管理界面。

如图7D所示，在该视频应用程序权限管理界面可以包括多项针对该视频应用程序权限的设置栏，例如定位权限的管理栏、访问相册权限的管理栏、访问麦克风权限的管理栏、通知推送权限的管理栏、应用查杀权限的管理栏、网络权限的管理栏等。用户可以通过点击应用查杀权限的管理栏中的开关控件，设置是否允许对该视频应用程序进行查杀，其中，点击打开该开关控件表示在内存异常时允许对该视频应用程序进行查杀，点击关闭该开关控件表示在内存异常时不允许对该视频应用程序进行查杀。应理解，当允许对该视频应用程序进行查杀时，该视频应用程序也即归属于预设类型的应用程序。

应理解，某一类型的应用程序是否属于预设类型的应用程序，即在满足触发条件时，是否会被查杀，还可以通过默认策略设置，如对于某一类型的应用程序，默认设置为预设类型；或者，应用程序的类型也可以根据查杀通知信息进行设置，如当某一后台应用程序满足查杀条件时，电子设备可以向用户查询是否同意对该后台应用程序进行查杀，如显示查询信息，若用户同意，则此时该应用程序的类型被设置属于预设类型，若用户不同意，则该应用程序的类型被设置不属于预设类型。本申请实施例对应用程序所属类型的具体设置方式不作限定。

在一些实施例中，若应用程序的类型符合预设类型，则可以执行步骤S606；若应用程序的类型符合第二预设类型，则可以执行步骤S607，也即保持应用程序继续运行。

在一些实施例中，为了避免在用户为了解原因的情况下，直接将某些后台运行的应用程序查杀，还可以在查杀之前向用户显示即将对某一应用程序进行查杀的提示信息。示例性的，如图8所示，当确定处于后台运行状态的新闻应用程序1的类型符合预设类型时，电子设备需要对该应用程序执行杀进程操作，在执行该杀进程操作之前，可以在电子设备当前界面(如手机解锁后的主界面)弹出应用程序查杀提示信息，该提示信息的内容例如可以是“当前设备系统内存不足，将对后台运行的新闻应用程序1执行查杀操作”，使得用户可以提前获知后台应用程序被中断或强制退出的原因。

S606，对应用程序执行杀进程操作。

应理解，现有的LMK查杀机制按照adj优先级查杀进程，一般不会查杀处于前台运行状态的应用程序，因而如果前台运行的应用程序发生内存泄露导致系统内存不足时，无法有效解决问题。针对这种情况，本申请实施例提供的内存管理方法还可以对前台运行的应用程序进行查杀。示例性的，如图9所示，为本申请实施例针对处于前台运行状态的应用程序进行内存管理的示例性流程图。该流程可以由电子设备作为主体来执行，包括以下步骤：

S901，启动应用程序，并向该应用程序提供虚拟内存。

S902，触发事件触发电子设备进入杀进程模式。

在一些实施例中，触发事件可以对应于电子设备满足第一预设条件，如系统内存处于低内存状态；或者，达到预设的检测周期等。

其中，这里的杀进程模式可以包括虚拟内存检测过程，查杀条件检测过程以及杀进程操作等。电子设备进入杀进程模式意味着该电子设备开始执行对前台应用程序的虚拟内存检测、进程位数检测等操作。

S903，检测系统的物理内存是否小于第二阈值。

应理解，前台应用程序可能是用户正在使用过程中的应用程序，对用户使用的重要性较高，因而在对该前台应用程序执行虚拟内存检测之前，需要先检测是否满足第二预设条件。其中，第二预设条件例如可以为：电子设备剩余的物理内存空间小于第二阈值，该第二阈值例如为200M或300M。

在一些实施例中，当电子设备检测到该剩余的物理内存空间小于第二阈值时，可以触发电子设备执行步骤S904。其中，第二阈值例如可以设置为200M或300M，本申请对此不作限定。

电子设备检测的物理内存剩余量是否小于预设阈值的过程可以包括：电子设备通过内存异常分析模块调用activitymanager.getmemoryInfo接口获取系统当前剩余的物理内存，之后比较该物理内存的剩余量是否小于预设阈值。

S904，检测应用程序占用的虚拟内存是否大于第一阈值。

S905，检测应用程序对应的进程是否为32位进程。

应理解，当在步骤S904中检测到前台应用程序占用虚拟内存的空间大于第一阈值，意味着该应用程序可能发生内存泄露，但也可能包含其他位数进程正常占用内存的情况，比如，当该应用程序占用的虚拟内存大于3.5G，但该应用程序的位数为64位，则此时可能并不存在内存泄漏。因而，为了准确判断该应用程序是否发生内存泄露，可以进一步检测该应用程序运行的进程是否为目标位数的进程，也即判断应用程序运行的进程与该预设阈值是否对应，若是，则表示应用程序占用的虚拟内容已经达到对应的虚拟内存占用限定值(即预设阈值)，能够确定该应用程序实际发生内存泄漏。

电子设备检测应用程序是否为32位进程的过程可以通过应用程序对应的pid，调用接口，查看对应进程文件系统相关文件目录，获取应用位类型，具体方式可以参见上述相关内容的描述，此处不再详述。

在一些实施例中，当电子设备检测到应用程序运行的进程为32位进程时，可以执行步骤S907，对应用程序执行杀进程操作；若检测到应用程序运行的进程不是32位进程时，则执行步骤S906，进一步判断该应用程序占用的物理内存是否大于第四阈值。

S906，检测应用程序占用的物理内存是否大于第四阈值。

在一些实施例中，电子设备判断应用程序占用的物理内存的过程可以包括：通过内存异常分析模块调用activitymanager.getmemoryInfo接口，由系统数据库中的由/proc/pid/status文件的VmRSS(物理内存)查询获取该应用程序占用的物理内存。

在一些实施例中，若检测到该应用程序占用的物理内存大于第四阈值，则可以执行步骤S906，对应用程序执行杀进程操作；若检测到该应用程序占用的物理内存等于或小于第四阈值，则可以执行步骤S908，也即继续运行该应用程序。示例性的，第四阈值例如可以为1GB或2GB，本申请对此不作限制。

示例性的，本申请实施例还提供了一种计算机可读存储介质，所述计算机可读存储介质存储有计算机程序，所述计算机程序包括指令，当所述指令在被计算机调用时，使所述计算机执行本申请实施例所述的内存管理的方法。

本申请实施例还提供了一种芯片系统，包括：通信接口，用于输入和/或输出信息；存储器，用于存储计算机可执行程序；处理器，用于执行所述计算机可执行程序，使得安装有所述芯片系统的设备执行如本申请实施例所述的内存管理的方法。

本申请实施例还提供了一种计算机程序产品，所述计算机程序产品包括计算机程序指令，当所述计算机程序指令在计算机上运行时，使得计算机实现如本申请实施例所述的内存管理的方法。

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

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

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

Claims

1.一种内存管理的方法，其特征在于，应用于电子设备，包括：

启动应用程序，并向所述应用程序提供虚拟内存；

在前台运行所述应用程序；

在满足至少以下条件时，对前台运行的所述应用程序执行杀进程的操作：所述应用程序占用的所述虚拟内存的空间大于第一阈值，所述应用程序运行的进程位数为32位。

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

所述电子设备中剩余的物理内存空间小于第二阈值，或所述电子设备中剩余的物理空间达到预设等级，或所述应用程序申请所述虚拟内容的速率大于第三阈值。

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

检测所述电子设备中剩余的物理内存空间；

当所述剩余的物理内存空间小于第二阈值时，检测所述应用程序在运行过程中占用的所述虚拟内存的空间；或者，

当所述电子设备中剩余的物理内存空间达到预设等级时，检测所述应用程序在运行过程中占用的所述虚拟内存的空间；或者，

检测所述应用程序申请所述虚拟内存的速率；

当所述应用程序申请所述虚拟内存的速率大于第三阈值时，检测所述应用程序在运行过程中占用的所述虚拟内存的空间。

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

将所述应用程序退至后台运行；

如果根据所述应用程序运行的进程位数确定所述应用程序运行的为32位进程，检测所述应用程序处于后台运行状态的时长；

当所述应用程序处于所述后台运行状态的时长大于预设时长时，对所述应用程序执行杀进程的操作。

5.根据权利要求4所述的方法，其特征在于，所述当所述应用程序处于所述后台运行状态的时长大于预设时长时，对所述应用程序执行杀进程的操作，具体包括：

当所述应用程序处于所述后台运行状态的时长大于预设时长时，检测所述应用程序的类型；

当所述应用程序的类型满足预设类型时，对所述应用程序执行杀进程的操作。

6.根据权利要求5所述的方法，其特征在于，所述预设类型的应用程序包括以下至少一种：

通讯类型的所述应用程序、工具类型的所述应用程序、购物类型的所述应用程序、新闻类型的所述应用程序。

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

当根据所述应用程序运行的进程位数确定所述应用程序运行的为非32位进程时，检测所述应用程序在运行过程中占用的物理内存的空间；

当所述占用的物理内存的空间大于第四阈值时，对所述应用程序执行杀进程的操作。

8.一种电子设备，其特征在于，包括：

一个或多个处理器；

一个或多个存储器；

所述一个或多个存储器存储有一个或多个计算机程序，所述一个或多个计算机程序包括指令，当所述指令被所述一个或多个处理器执行时，使得所述电子设备实现如权利要求1至7中任一项所述的内存管理的方法。

9.一种计算机可读存储介质，其特征在于，所述计算机可读存储介质存储有计算机程序，所述计算机程序包括指令，当所述指令在被计算机调用时，使所述计算机执行如权利要求1至7中任一项所述的内存管理的方法。

10.一种芯片系统，其特征在于，包括：

通信接口，用于输入和/或输出信息；

存储器，用于存储计算机可执行程序；

处理器，用于执行所述计算机可执行程序，使得安装有所述芯片系统的设备执行如权利要求1至7中任一项所述的内存管理的方法。