CN114253872A - 电子设备及其内存回收方法、介质 - Google Patents
电子设备及其内存回收方法、介质 Download PDFInfo
- Publication number
- CN114253872A CN114253872A CN202210185733.1A CN202210185733A CN114253872A CN 114253872 A CN114253872 A CN 114253872A CN 202210185733 A CN202210185733 A CN 202210185733A CN 114253872 A CN114253872 A CN 114253872A
- Authority
- CN
- China
- Prior art keywords
- memory
- memory recovery
- subprogram
- recovery
- reclamation
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Granted
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F12/00—Accessing, addressing or allocating within memory systems or architectures
- G06F12/02—Addressing or allocation; Relocation
- G06F12/0223—User address space allocation, e.g. contiguous or non contiguous base addressing
- G06F12/023—Free address space management
- G06F12/0253—Garbage collection, i.e. reclamation of unreferenced memory
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/46—Multiprogramming arrangements
- G06F9/50—Allocation of resources, e.g. of the central processing unit [CPU]
- G06F9/5005—Allocation of resources, e.g. of the central processing unit [CPU] to service a request
- G06F9/5011—Allocation of resources, e.g. of the central processing unit [CPU] to service a request the resources being hardware resources other than CPUs, Servers and Terminals
- G06F9/5016—Allocation of resources, e.g. of the central processing unit [CPU] to service a request the resources being hardware resources other than CPUs, Servers and Terminals the resource being the memory
-
- Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y02—TECHNOLOGIES OR APPLICATIONS FOR MITIGATION OR ADAPTATION AGAINST CLIMATE CHANGE
- Y02D—CLIMATE CHANGE MITIGATION TECHNOLOGIES IN INFORMATION AND COMMUNICATION TECHNOLOGIES [ICT], I.E. INFORMATION AND COMMUNICATION TECHNOLOGIES AIMING AT THE REDUCTION OF THEIR OWN ENERGY USE
- Y02D10/00—Energy efficient computing, e.g. low power processors, power management or thermal management
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Software Systems (AREA)
- Retry When Errors Occur (AREA)
Abstract
本申请涉及计算机系统领域,具体涉及一种电子设备及其内存回收方法、介质,该内存回收方法包括:接收第一类内存回收指令;响应于第一类内存回收指令,根据第一执行顺序执行多个内存回收子程序进行内存回收;根据各内存回收子程序的执行时间和回收到的内存大小,确定各内存回收子程序的内存回收能力;根据各内存回收子程序的内存回收能力,将多个内存回收子程序的执行顺序从第一执行顺序调整为第二执行顺序。本申请提供的方法,可以根据内存回收子程序的内存回收能力调整内存回收子程序的排列顺序,实现智能调整控制链表中的内存回收子程序的排列顺序,可以优先执行内存回收能力较好的内存回收子程序。
Description
技术领域
本申请涉及计算机系统领域。尤其涉及一种电子设备及其内存回收方法、介质。
背景技术
现有电子设备的操作系统(如:Linux系统)可以通过slab(内存管理单元)来管理电子设备的内存,并在控制链表中保存与内存管理单元对应的内存回收单元(如:Linux系统中的shrinker)。在操作系统需要执行内存回收的操作时,操作系统会根据控制链表中内存回收单元的排列顺序,依次从控制链表的起始位置起执行内存回收单元来回收对应的内存管理单元。
但是,如果控制链表中靠前的位置存在大量回收能力以及回收效率低下的内存回收单元,则会使得操作系统的内核无法及时回收内存,造成操作系统卡顿影响用户体验。因此,需要一种根据内存回收单元的回收能力以及回收效率低对内存回收单元的排列顺序进行调整的方案。
发明内容
本申请的目的在于提供一种电子设备及其内存回收方法、介质。
本申请的第一方面提供了一种内存回收方法,应用于电子设备,其特征在于,包括:
接收第一类内存回收指令;
响应于第一类内存回收指令,根据第一执行顺序执行多个内存回收子程序进行内存回收;
根据各内存回收子程序的执行时间和回收到的内存大小,确定各内存回收子程序的内存回收能力;
根据各内存回收子程序的内存回收能力,将多个内存回收子程序的执行顺序从第一执行顺序调整为第二执行顺序。
在上述第一方面的一种可能的实现中,第一类内存回收指令为Linux系统生成的直接内存回收指令。
即在本申请的实施例中,第一类内存回收指令可以是Linux系统执行的直接内存回收。内存回收子程序可以是Linux系统创建内存管理单元是生成的与内存管理单元对应的内存回收单元;第一执行顺序可以是由Linux系统将多个内存回收子程序加入到控制链表的时间先后确定的,也就是,第一执行顺序可以是由操作Linux系统创建内存管理单元的时间先后确定的。内存回收能力可以是内存回收子程序的执行结果,即,执行完内存回收子程序能够回收的最大回收内存或者单位时间内执行完内存回收子程序能够回收的最大回收内存。第二执行顺序可以是Linux系统根据内存回收子程序的内存回收能力调整控制链表中内存回收子程序的排列顺序后确定的。第二执行顺序可以是根据内存回收子程序的内存回收能力的高低,从高到低对内存回收子程序进行排列。
本申请实施例的方法,可以根据确定的内存回收子程序的内存回收能力调整控制链表中的内存回收子程序的排列顺序,实现智能调整控制链表中的内存回收子程序的排列顺序,例如:根据内存回收能力在控制链表中以降序的方式排列内存回收子程序,使得内存回收能力较好的内存回收子程序位于控制链表中靠前的位置;在只需执行控制链表中起始位置起的部分内存回收子程序就能完成内存回收的情况下,可以优先执行内存回收能力较好的内存回收子程序。
在上述第一方面的一种可能的实现中,第一执行顺序根据设置内存回收子程序的时间先后确定,且Linux系统通过预设控制链表记录第一执行顺序。
即在本申请的实施例中,Linux系统在创建内存管理单元时,为内存管理单元设置对应的内存回收子程序,第一执行顺序可以根据内存回收子程序加入预设控制链表的时间先后确定。
在上述第一方面的一种可能的实现中,执行时间为多个内存回收子程序执行完毕所需要的时间。
在上述第一方面的一种可能的实现中,回收到的内存大小为内存回收子程序的最大回收内存。
在上述第一方面的一种可能的实现中,内存回收能力包括内存回收子程序在单位时间内回收到的内存大小。
即在本申请的实施例中,内存回收能力可以是内存回收子程序的执行结果,即,单位时间内执行完内存回收子程序能够回收的最大回收内存。
在上述第一方面的一种可能的实现中,根据各内存回收子程序的内存回收能力,将多个内存回收子程序的执行顺序从第一执行顺序调整为第二执行顺序,包括:
各内存回收子程序至少包括第一内存回收子程序和第二内存回收子程序,且根据第一执行顺序,第一内存回收子程序位于第二内存回收子程序之前;
确定第二内存回收子程序的内存回收能力高于第一内存回收子程序的内存回收能力后,将第一内存回收子程序和第二内存回收子程序调整为第二执行顺序,第二内存回收子程序位于第一内存回收子程序之前。
即在本申请的实施例中,第一内存回收子程序加入预设控制链表的时间早于第二内存回收子程序,对于第一执行顺序,第一内存回收子程序位于第二内存回收子程序之前;若执行了第一内存回收子程序和第二内存回收子程序后,第二内存回收子程序的内存回收能力高于第一内存回收子程序的内存回收能力,对于第二执行顺序,第二内存回收子程序位于第一内存回收子程序之前。
在上述第一方面的一种可能的实现中,内存回收子程序包括计数器,计数器用于记录内存回收子程序未被执行的次数。
即在本申请的实施例中,预设控制链表中位置靠后的内存回收子程序存在未被执行的情况,计数器用于记录内存回收子程序未被执行的次数。
在上述第一方面的一种可能的实现中,根据各内存回收子程序的内存回收能力,将多个内存回收子程序的执行顺序从第一执行顺序调整为第二执行顺序,还包括:
各内存回收子程序至少包括第三内存回收子程序和第四内存回收子程序,且根据第一执行顺序,第三内存回收子程序位于第四内存回收子程序之前;
若第四内存回收子程序的计数器达到预设计时阈值,且第三内存回收子程序的计数器未达到预设计时阈值,将第三内存回收子程序和第四内存回收子程序调整为第二执行顺序,第四内存回收子程序位于第三内存回收子程序之前。
即在本申请的实施例中,第四内存回收子程序对应的未被执行的次数超过了预设计时阈值,也就是,第四内存回收子程序存在多次未被执行的情况,则将第四内存回收子程序调整至第三内存回收子程序之前,也就是将第四内存回收子程序调整至预设控制链表中靠前的位置,避免第四内存回收子程序对应的内存管理单元长期处于未被回收的状态。
在上述第一方面的一种可能的实现中,将第三内存回收子程序和第四内存回收子程序调整为第二执行顺序之后,包括:
将第四内存回收子程序的计数器清零。
在上述第一方面的一种可能的实现中,包括:
各内存回收子程序还包括第五内存回收子程序,且根据第一执行顺序,第五内存回收子程序位于第四内存回收子程序之后;
若第四内存回收子程序和第五内存回收子程序的计数器达到预设计时阈值,且第三内存回收子程序的计数器未达到预设计时阈值,将第三内存回收子程序、第四内存回收子程序和第五内存回收子程序调整为第二执行顺序,第四内存回收子程序和第五内存回收子程序位于第三内存回收子程序之前,且第四内存回收子程序和第五内存回收子程序依次排列。
在上述第一方面的一种可能的实现中,其特征在于,第五内存回收子程序位于第四内存回收子程序之前。
即在本申请的实施例中,第四内存回收子程序和第五内存回收子程序都存在多次未被执行的情况,则将第四内存回收子程序和第五内存回收子程序调整至第三内存回收子程序之前,也就是将第四内存回收子程序和第五内存回收子程序调整至预设控制链表中靠前的位置。其中,调整后的第四内存回收子程序和第五内存回收子程序可以依次排列,第五内存回收子程序也可以排列于第四内存回收子程序之前。
本申请的第二方面提供了一种电子设备,包括:
处理器,用于前述第一方面提供的电子设备的内存回收方法;以及
存储器,可以与控制器耦合或者解耦用于存储由控制器执行的指令。
本申请的第三方面提供了一种计算机可读存储介质,计算机可读存储介质中包含有指令,当指令被电子设备的控制器执行时使电子设备实现前述第一方面提供的电子设备的内存回收方法。
附图说明
图1根据本申请的实施例示出了一种Linux系统进行内存回收的流程示意图;
图2根据本申请的实施例示出了一种内存管理单元的示意图;
图3根据本申请的实施例示出了一种控制链表的示意图;
图4根据本申请的实施例示出了一种Linux系统进行slab内存回收的流程示意图;
图5根据本申请的实施例示出了一种内存回收方法的流程示意图;
图6根据本申请的实施例示出了另一种内存回收方法的流程示意图;
图7根据本申请的实施例示出了一种内存回收单元的示意图;
图8根据本申请的实施例示出了一种电子设备的结构示意图;
图9根据本申请的实施例示出了一种电子设备的软件结构框图;
图10根据本申请的实施例示出了一种用于电子设备的内存回收方法的流程示意图;
图11根据本申请的实施例示出了一种电子设备1的应用程序申请内存的示意图;
图12根据本申请的实施例示出了一种内存回收的示意图;
图13根据本申请的实施例示出了另一种内存回收的示意图;
图14根据本申请的实施例示出了一种调整内存回收单元的排列顺序的示意图;
图15根据本申请的实施例示出了一种调整内存回收单元的排列顺序的示意图;
图16根据本申请的实施例示出了一种调整内存回收单元的排列顺序的示意图。
具体实施方式
本申请的实施例包括但不限于一种电子设备及其内存回收方法和介质、介质。为使本申请的目的、技术方案和优点更加清楚,下面将结合附图对本申请的实施方式作进一步地详细描述。
以下先对本申请涉及的关键术语进行说明。
(一)内存回收
以Linux系统为例,Linux系统的内核需要为任何时刻到来的内存申请提供足够的内存,因此内核会有一个内存回收策略,使得应用程序对内存的使用不至于让操作系统的空闲内存长期处于不足的状态。参考图1,图1示出了一种,Linux系统进行内存回收的流程示意图。可以看出,内存回收的整体流程包括:文件页回收,匿名页回收以及slab回收。其中,文件页可以是在Linux系统中进行文件读写操作的过程中用于缓存数据的内存页面,文件页回收就是先将文件页中缓存的数据写入磁盘后释放文件页;匿名页可以是Linux系统设置的共享内存,用于Linux系统的进程间通信,匿名页回收就是将回收前先换置到swap(交换分区)后回收。slab用于将内存预先初始化为不同大小的内存块并缓存上述内存块,当应用程序申请使用内存时,slab可以根据应用程序申请的内存大小分配内存块。
可以理解,在本申请实施例中,图1所示的文件页回收,匿名页回收以及slab回收没有执行的先后顺序。文件页回收,匿名页回收以及slab回收可以同时执行,也可以以其他任意顺序执行,这里不做限定。
(二)内存管理单元(slab)
参考图2,图2示出了电子设备100的操作系统创建的内存管理单元,如图2所示,电子设备100的操作系统先后创建了四个内存管理单元,其中,第一内存管理单元至第四内存管理单元的排列顺序可以是电子设备100的操作系统创建内存管理单元的顺序,以第一内存管理单元为例,第一内存管理单元包括10个内存块,内存块的大小为16MB。
(三)内存回收单元
Linux系统还会对每一个内存管理单元(slab)设置一个内存回收单元,用于回收内存管理单元中已分配的内存块。继续参考图2,第一内存管理单元都包括10个内存块,内存块的大小为16MB。对于第一内存管理单元对应的内存回收单元来说,内存回收单元用于回收内存管理单元包括的10个内存块,也就是说,执行内存回收单元能够回收的最大回收内存为160MB。
(四)控制链表
Linux系统可以使用控制链表来保存内存回收单元。参考图3,图3示出了用于保存内存回收单元的控制链表,控制链表中的四个内存回收单元排列顺序可以是根据操作系统创建与内存回收单元对应的内存管理单元的时间先后确定的。
参考图4,图4示出了一种Linux系统的slab回收的流程示意图,如图4所示,Linux系统执行slab回收的过程包括:
S401:获取内存回收单元;
Linux系统如果要执行slab内存回收,可以先获取存储的控制链表,并按控制链表中的内存回收单元的排列顺序读取内存回收单元。
S402:确定内存回收单元的数量;
Linux系统可以按顺序读取控制链表中保存的内存回收单元,确定控制链表中的内存回收单元的数量,用于判断Linux系统是否执行到控制链表中的最后一个内存回收单元。
S403:执行内存回收单元进行内存回收;
Linux系统可以从控制链表中第一个内存回收单元起依次执行控制链表中所有的内存回收单元,进行内存回收。
S404:确定内存回收单元是否都执行完。
Linux系统每执行一个内存回收单元后,可以判断是否执行到控制链表中最后一个内存回收单元,如果是,则本次slab内存回收执行完毕,Linux系统完成slab回收;如果不是,则回到步骤S401,Linux系统继续读取下一个内存回收单元。
基于上述图1至图4的描述,现有电子设备的操作系统(如:Linux系统)可以通过slab(内存管理单元)来管理电子设备的内存;并且通过内存管理单元对应的内存回收单元(如:Linux系统中的shrinker)进行内存回收。图5示出了一种本申请实施例提供的内存回收方法,Linux系统执行内存回收方法包括:
S501:注册内存回收单元。
Linux系统可以对每一个创建的内存管理单元设置一个对应的内存回收单元,Linux系统可以执行内存回收单元对内存管理单元管理的内存进行回收。
S502:生成保存内存回收单元的控制链表。
Linux系统可以将内存回收单元加入控制链表进行保存,控制链表中的内存回收单元具有排列顺序,排列顺序是根据内存回收单元加入到控制链表的时间先后确定的。
S503:执行控制链表中的内存回收单元进行内存回收。
可以看出,在Linux系统需要执行内存回收的操作时,Linux系统会根据控制链表中内存回收单元的排列顺序,依次从控制链表的起始位置起执行内存回收单元来回收对应的内存管理单元。
但是,控制链表中内存回收单元的排列顺序是根据内存回收单元加入到控制链表的时间先后确定的,也就是说,控制链表中内存回收单元的排列顺序可以是由操作系统的内核创建内存管理单元的时间先后确定的,也可以称为内存回收单元的注册顺序。由于每个内存回收单元的回收能力(可回收的内存大小)和回收效率(回收内存的耗时)是不同的,例如:有的内存回收单元只能回收1MB(Mega Byte,兆字节)内存,而有的内存回收单元却可以回收100MB内存。再如:有的内存回收单元每100ms(millisecond,毫秒)只能回收1KB(KiloByte,千字节)内存,而有的内存回收单元每10ms就能够回收1KB的内存;因此,在操作系统的内核执行直接内存回收的情况下,也就是,在操作系统的内核只需执行控制链表中起始位置起的部分内存回收单元就能完成内存回收的情况下(如:执行控制链表中靠前的位置的部分内存回收单元获得的最大回收内存大于直接内存回收需要回收的内存),如果控制链表中靠前的位置存在大量回收能力以及回收效率低下的内存回收单元,则会使得操作系统的内核无法及时回收内存,造成操作系统卡顿影响用户体验。
可以理解,上述对内存进行管理,内存回收以及对控制链表进行管理的操作都可以由操作系统的内核来执行,为了便于描述,本申请实施例中,将以操作系统作为执行主体进行描述。
在Linux系统的内核执行内存回收单元进行内存回收的过程中,由于内存块的大小以及内存回收单元的执行情况的不同,每一个内存回收单元对应的内存的回收能力以及回收效率也不同,在本申请实施例中,为了解决背景技术中提到的操作系统在进行内存回收的过程中,内存回收效率低下的问题,本申请实施例提供了一种电子设备的内存回收方法。具体地,在该内存回收方法中,电子设备的操作系统可以对控制链表中的每一个内存回收单元设置一个评价参数,用于确定内存回收单元的品质的高低(确定内存回收单元的最大回收内存以及回收效率的优劣);在电子设备的操作系统每次执行了控制链表中的内存回收单元后,根据该内存回收单元的执行结果(执行结果可以包括:内存的回收能力,即执行完内存回收单元能够回收的最大回收内存,如:200MB;内存的回收效率,即单位时间内执行完内存回收单元能够回收的最大回收内存,如:100MB/S,每一秒能够回收100MB内存),确定与该执行结果对应的评价参数(内存的回收能力以及内存的回收效率越高的内存回收单元对应的评价参数也越高);电子设备的操作系统可以根据确定的内存回收单元的评价参数调整控制链表中的内存回收单元的排列顺序,也就是实现智能调整控制链表中的内存回收单元的排列顺序,例如:根据评价参数在控制链表中以降序的方式排列内存回收单元,使得内存的回收能力以及内存的回收效率较好的内存回收单元位于控制链表中靠前的位置;在操作系统只需执行控制链表中起始位置起的部分内存回收单元就能完成内存回收的情况下,可以优先执行内存的回收能力以及内存的回收效率较好的内存回收单元。例如:若操作系统执行直接内存回收,操作系统只需要执行控制链表中起始位置起的部分的内存回收单元,获得的最大回收内存就能够大于直接内存回收的内存需求。
图6示出了另一种本申请实施例提供的内存回收方法,Linux系统执行内存回收方法包括:
S601:注册内存回收单元。
这里的步骤S601与图5的步骤S501相似,Linux系统可以对每一个创建的内存管理单元设置一个对应的内存回收单元。
S602:生成保存内存回收单元的控制链表。
这里的步骤S602与图5的步骤S502相似,Linux系统可以将内存回收单元加入控制链表进行保存,控制链表中内存回收单元的排列顺序是根据内存回收单元加入到控制链表的时间先后确定的。
S603:执行控制链表中的内存回收单元进行内存回收。
这里的步骤S603与图5的步骤S503相似,在Linux系统每一次执行内存回收的操作时,Linux系统会根据控制链表中内存回收单元的排列顺序,依次从控制链表的起始位置起执行内存回收单元来回收对应的内存管理单元。
S604:获取内存回收单元的评价参数,调整控制链表中的内存回收单元的排列顺序。
可以看出,在每一次Linux系统执行内存回收的操作后,Linux系统可以根据内存回收单元的评价参数调整控制链表中的内存回收单元的排列顺序,使得评价参数高的内存回收单元排列于控制链表中靠前的位置。在下一次次Linux系统执行内存回收的操作时,会根据调整后的控制链表中内存回收单元的排列顺序,依次从控制链表的起始位置起执行内存回收单元来回收对应的内存管理单元。可以理解,在操作系统第一次执行图6所示的内存回收方法时,由于控制链表中的内存回收单元还未有评价参数,因此,步骤S604可以不执行;在另一本申请实施例中,在操作系统执行了控制链表中的内存回收单元进行内存回收后,内存回收单元的评价参数未发生变化,或者,内存回收单元的评价参数发生变化,但控制链表中的内存回收单元的排列顺序未发生变化。
在本申请一些实施例中,内存回收单元的执行结果可以包括上述内存的回收能力以及内存的回收效率,这里的回收能力可以是指操作系统执行完该内存回收单元后能够回收的最大回收内存,例如:操作系统执行完内存回收单元能够回收的最大回收内存为100MB,则内存回收单元的回收能力就可以是100MB。这里的回收效率可以是指单位时间内内存回收单元能够回收的最大回收内存,再如:操作系统执行完内存回收单元能够回收的最大回收内存为100MB,需要耗时10秒,即,10s。因此,内存回收单元可以实现100MB/10秒,也就是,1秒能够回收10MB内存。
电子设备的操作系统可以对内存回收单元的执行结果生成评价参数,例如,对回收能力高以及回收效率快的内存回收单元,可以生成较高的评价参数。例如:第一内存回收单元的回收能力为100MB,回收效率为10MB/1秒;第二内存回收单元的回收能力为200MB,回收效率为20MB/10秒,电子设备的操作系统可以确定第二内存回收单元的评价参数高于第一内存回收单元。
通过本申请实施例的方法,在电子设备的操作系统进行内存回收时,由于内存回收效率较高的内存回收单元被调整至控制链表中靠前的位置,因此,上述内存回收效率较高的内存回收单元可以被优先执行,可以有效地提升了操作系统的内存回收效率。
下面参考图7,图7示出了一种电子设备100的内存回收单元的应用场景,如图7所示,电子设备100的操作系统可以将电子设备100的内存创建为4个内存管理单元,即,第一内存管理单元至第四内存管理单元,并为每一个内存管理单元设置了相应的内存回收单元,即,第一内存回收单元至第四内存回收单元。在控制链表中,第一内存回收单元至第四内存回收单元依次排列。在电子设备100的操作系统执行了依次内存回收的操作后,电子设备100的操作系统获取了第一内存回收单元至第四内存回收单元各自的评价参数,即,30,90,70,40。因此,电子设备100的操作系统可以根据执行内存回收的操作后的第一内存回收单元至第四内存回收单元对应的评价参数,将控制链表中的内存回收单元的排列顺序调整为第二内存回收单元、第三内存回收单元、第四内存回收单元以及第一内存回收单元。可以理解,这里的评价参数:30,90,70,40的取值范围可以是在1至100中的任意一个正整数。在另一本申请实施例中,评价参数的取值范围还可以是在1至10中的任意一个正整数,或者,通过等级1至等级10(等级由低到高表示评价参数由低到高)的方式来表示内存回收单元的评价参数,在本申请实施例中对评价参数的设置方式以及的取值范围不做限定。
可以理解,本申请的实施例中的电子设备是一种向用户提供语音和/或数据连通性的终端设备,例如,常见的终端设备可以包括:车载设备、手机、平板电脑、笔记本电脑、掌上电脑、移动互联网设备(mobile internet device,MID)、可穿戴设备(例如包括:智能手表、智能手环、计步器等)、个人数字助理、便携式媒体播放器、导航设备、视频游戏设备、机顶盒、虚拟现实和/或增强现实设备、物联网设备、工业控制设备、流媒体客户端设备、电子书、阅读设备以及其他设备。
图8示出了根据本申请的实施例的电子设备100的结构示意图,电子设备100可以包括处理器110,外部存储器接口120,内部存储器121,通用串行总线(universal serialbus,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可以包括应用处理器(AP),调制解调处理器,图形处理器(graphics processing unit,GPU),图像信号处理器(image signal processor,ISP),控制器,视频编解码器,数字信号处理器(digitalsignal processor,DSP),基带处理器(BP),和/或神经网络处理器(neural-networkprocessing unit,NPU)等。其中,不同的处理单元可以是独立的器件,也可以集成在一个或多个处理器中。
在本申请的实施例中,电子设备100可以通过处理器110确定电子设备100的操作系统执行了内存回收的操作后,控制链表中被执行的内存回收单元的评价参数,并根据评价参数调整控制链表中内存回收单元的排列顺序,使得评价参数较高的内存回收单元在控制链表中处于靠前的位置,在电子设备100的操作系统执行下一次内存回收的操作,可以执行评价参数较高,也就是回收能力以及回收效率较高的内存回收单元。
处理器110中还可以设置存储器,用于存储指令和数据。在一些实施例中,处理器110中的存储器为高速缓冲存储器。该存储器可以保存处理器110刚用过或循环使用的指令或数据。如果处理器110需要再次使用该指令或数据,可从所述存储器中直接调用。避免了重复存取,减少了处理器110的等待时间,因而提高了系统的效率。
充电管理模块140用于从充电器接收充电输入。其中,充电器可以是无线充电器,也可以是有线充电器。在一些有线充电的实施例中,充电管理模块140可以通过USB接口130接收有线充电器的充电输入。
电源管理模块141用于连接电池142,充电管理模块140与处理器110。电源管理模块141接收电池142和/或充电管理模块140的输入,为处理器110,内部存储器121,显示屏194,摄像头193,和无线通信模块160等供电。电源管理模块141还可以用于监测电池容量,电池循环次数,电池健康状态(漏电,阻抗)等参数。
电子设备100的无线通信功能可以通过天线1,天线2,移动通信模块150,无线通信模块160,调制解调处理器以及基带处理器等实现。
天线1和天线2用于发射和接收电磁波信号。电子设备100中的每个天线可用于覆盖单个或多个通信频带。不同的天线还可以复用,以提高天线的利用率。例如:可以将天线1复用为无线局域网的分集天线。在另外一些实施例中,天线可以和调谐开关结合使用。
移动通信模块150可以提供应用在电子设备100上的包括2G/3G/4G/5G等无线通信的解决方案。
无线通信模块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)等无线通信的解决方案。
电子设备100通过GPU,显示屏194,以及应用处理器等实现显示功能。GPU为图像处理的微处理器,连接显示屏194和应用处理器。GPU用于执行数学和几何计算,用于图形渲染。处理器110可包括一个或多个GPU,其执行程序指令以生成或改变显示信息。
显示屏194用于显示图像,视频等。显示屏194包括显示面板。在一些实施例中,电子设备100可以包括1个或N个显示屏194,N为大于1的正整数。
电子设备100可以通过ISP,摄像头193,视频编解码器,GPU,显示屏194以及应用处理器等实现拍摄功能。
摄像头193用于捕获静态图像或视频。在一些实施例中,电子设备100可以包括1个或N个摄像头193,N为大于1的正整数。
外部存储器接口120可以用于连接外部存储卡,例如MicroSD卡,实现扩展电子设备100的存储能力。外部存储卡通过外部存储器接口120与处理器110通信,实现数据存储功能。例如将音乐,视频等文件保存在外部存储卡中。
内部存储器121可以用于存储计算机可执行程序代码,所述可执行程序代码包括指令。内部存储器121可以包括存储程序区和存储数据区。处理器110通过运行存储在内部存储器121的指令,和/或存储在设置于处理器中的存储器的指令,执行电子设备100的各种功能应用以及数据处理。
电子设备100可以通过音频模块170,扬声器170A,受话器170B,麦克风170C,耳机接口170D,以及应用处理器等实现音频功能。例如音乐播放,录音等。
音频模块170用于将数字音频信息转换成模拟音频信号输出,也用于将模拟音频输入转换为数字音频信号。音频模块170还可以用于对音频信号编码和解码。在一些实施例中,音频模块170可以设置于处理器110中,或将音频模块170的部分功能模块设置于处理器110中。
扬声器170A,也称“喇叭”,用于将音频电信号转换为声音信号。电子设备100可以通过扬声器170A收听音乐,或收听免提通话。
受话器170B,也称“听筒”,用于将音频电信号转换成声音信号。当电子设备100接听电话或语音信息时,可以通过将受话器170B靠近人耳接听语音。
麦克风170C,也称“话筒”,“传声器”,用于将声音信号转换为电信号。当拨打电话或发送语音信息时,用户可以通过人嘴靠近麦克风170C发声,将声音信号输入到麦克风170C。电子设备100可以设置至少一个麦克风170C。在另一些实施例中,电子设备100可以设置两个麦克风170C,除了采集声音信号,还可以实现降噪功能。在另一些实施例中,电子设备100还可以设置三个,四个或更多麦克风170C,实现采集声音信号,降噪,还可以识别声音来源,实现定向录音功能等。
耳机接口170D用于连接有线耳机。耳机接口170D可以是USB接口130,也可以是3.5mm的开放移动电子设备平台(open mobile terminal platform,OMTP)标准接口,美国蜂窝电信工业协会(cellular telecommunications industry association of the USA,CTIA)标准接口。
压力传感器180A用于感受压力信号,可以将压力信号转换成电信号。在一些实施例中,压力传感器180A可以设置于显示屏194。
陀螺仪传感器180B可以用于确定电子设备100的运动姿态。
气压传感器180C用于测量气压。在一些实施例中,电子设备100通过气压传感器180C测得的气压值计算海拔高度,辅助定位和导航。
磁传感器180D包括霍尔传感器。
加速度传感器180E可检测电子设备100在各个方向上(一般为三轴)加速度的大小。
距离传感器180F,用于测量距离。
接近光传感器180G可以包括例如发光二极管(LED)和光检测器,
环境光传感器180L用于感知环境光亮度。
指纹传感器180H用于采集指纹。
温度传感器180J用于检测温度。
触摸传感器180K,也称“触控器件”。触摸传感器180K可以设置于显示屏194,由触摸传感器180K与显示屏194组成触摸屏,也称“触控屏”。
骨传导传感器180M可以获取振动信号。
按键190包括开机键,音量键等。按键190可以是机械按键。也可以是触摸式按键。电子设备100可以接收按键输入,产生与电子设备100的用户设置以及功能控制有关的键信号输入。
马达191可以产生振动提示。马达191可以用于来电振动提示,也可以用于触摸振动反馈。
指示器192可以是指示灯,可以用于指示充电状态,电量变化,也可以用于指示消息,未接来电,通知等。
SIM卡接口195用于连接SIM卡。SIM卡可以通过插入SIM卡接口195,或从SIM卡接口195拔出,实现和电子设备100的接触和分离。
图9是本申请一些实施例公开的电子设备100的软件结构框图。
如图9所示,分层架构将软件分成若干个层,每一层都有清晰的角色和分工。层与层之间通过软件接口通信。在一些实施例中,将操作系统分为四层,从上至下分别为应用程序层,应用程序框架层,安卓运行时(Android runtime)和系统库,硬件抽象层(hardwareabstract layer,HAL)以及内核层。其中:
应用程序层可以包括一系列应用程序包。如图9所示,应用程序包可以包括相机,图库,日历,通话,地图,导航,WLAN,蓝牙,音乐,视频,短信息等应用程序,还可以包括其他未示出的应用程序包。
应用程序框架层为应用程序层的应用程序提供应用编程接口(applicationprogramming interface,API)和编程框架。应用程序框架层包括一些预先定义的函数。如图9所示,应用程序框架层可以包括窗口管理器,内容提供器,视图系统,电话管理器,资源管理器,通知管理器等。
窗口管理器可用于管理窗口程序。窗口管理器可以获取显示屏大小,判断是否有状态栏,锁定屏幕,截取屏幕等。
内容提供器可用来存放和获取数据,并使这些数据可以被应用程序访问。所述数据可以包括视频,图像,音频,拨打和接听的电话,浏览历史和书签,电话簿等。
视图系统可包括可视控件,例如显示文字的控件,显示图片的控件等。视图系统可用于构建应用程序。
资源管理器为应用程序提供各种资源,比如本地化字符串,图标,图片,布局文件,视频文件等等。
通知管理器使应用程序可以在状态栏中显示通知信息,可以用于传达告知类型的消息,可以短暂停留后自动消失,无需用户交互。比如通知管理器被用于告知下载完成,消息提醒等。通知管理器还可以是以图表或者滚动条文本形式出现在系统顶部状态栏的通知,例如后台运行的应用程序的通知,还可以是以对话窗口形式出现在屏幕上的通知。例如在状态栏提示文本信息,发出提示音,电子设备振动,指示灯闪烁等。
安卓运行时包括核心库和虚拟机。安卓运行时负责安卓系统的调度和管理。核心库包含两部分:一部分是java语言需要调用的功能函数,另一部分是安卓的核心库。
应用程序层和应用程序框架层运行在虚拟机中。虚拟机将应用程序层和应用程序框架层的java文件执行为二进制文件。虚拟机用于执行对象生命周期的管理,堆栈管理,线程管理,安全和异常的管理,以及垃圾回收等功能。
HAL可以是对Linux内核驱动程序的封装,向上提供接口,屏蔽低层的实现细节。也就是说,把对硬件的支持分成了两层,一层放在用户空间(User Space),一层放在内核空间(Kernel Space),其中,硬件抽象层运行在用户空间,而Linux内核驱动程序运行在内核空间。如图9所示,HAL可以包括传感器HAL,传感器HAL可以是对内核中的传感器驱动的封装。
内核层是硬件和软件之间的层。内核层可以包括内存管理模块。其中,内存管理模块用于管理操作系统创建的内存管理单元,响应应用程序层发送的申请内存请求,执行对应的内存回收的操作。内存管理模块在操作系统执行了内存回收的操作后,确定控制链表中被执行的内存回收单元的评价参数,并根据评价参数调整控制链表中内存回收单元的排列顺序,使得评价参数较高的内存回收单元在控制链表中处于靠前的位置,在操作系统执行下一次内存回收的操作,可以执行评价参数较高,也就是回收能力以及回收效率较高的内存回收单元。可以理解,这里的内存管理模块、内存管理单元以及内存回收单元都可以是运行在内核层的软件模块。具体实现可以参见下述本申请实施例的内存回收方法中相关描述,这里不再赘述。
下面基于图8和图9所示的电子设备100的软硬件结构,通过图10对本申请的电子设备100的内存回收方法进行详细说明。
具体地,本申请图10的内存回收方法可以通过电子设备100的处理器110执行相关程序来实现。如图10所示,根据本申请的一个具体实施方式提供的用于电子设备的内存回收方法包括如下所示的步骤。
S1001:获取控制链表。
本申请实施例中,这里的控制链表可以存储在电子设备100的存储区域中,用于保存电子设备100的操作系统创建的内存管理单元对应的内存回收单元。电子设备100的操作系统可以在创建完一个内存管理单元后,为内存管理单元设置一个内存回收单元;控制链表中保存的内存回收单元的排列顺序,可以是由电子设备100的操作系统的内核创建内存管理单元的时间先后确定的。
S1002:判断是否需要执行内存回收的操作。
在本申请的实施例中,操作系统需要为任何时刻到来的内存申请提供足够的内存,因此操作系统会判断是否需要执行内存回收的操作,如果需要执行,则执行步骤S1003,操作系统可以根据控制链表中内存回收单元的排列顺序执行内存回收单元;如果不需要执行,则操作系统回到步骤S1002,继续等待执行内存回收的操作。可以理解,内存回收的操作可以包括周期性的内存回收的操作和直接内存回收操作,操作系统会执行一个周期性的内存回收的操作,使得应用程序对内存的使用不至于让操作系统的空闲内存长期处于不足的状态;而当有大于空闲内存的内存申请产生的时候,操作系统的内核会触发强制内存回收,以满足内存申请。
参考图11,图11示例性示出了一种电子设备100的应用程序申请内存的应用场景,如图11所示,电子设备100的内存大小为600MB,并且,其中的500MB都已被占用,这时,电子设备100的操作系统启动了应用程序,例如:启动了游戏应用,应用程序向电子设备100的操作系统申请300MB内存,由于电子设备100的操作系统的空闲内存为100MB,电子设备100的操作系统会执行直接内存回收的操作(强制内存回收),回收200MB内存,以满足应用程序向电子设备100的操作系统申请的300MB内存。
S1003:根据控制链表中内存回收单元的排列顺序执行内存回收单元。
本申请实施例中,在电子设备100的操作系统第一次执行内存回收的操作时,操作系统可以根据获取的控制链表中内存回收单元的默认排列顺序,执行内存回收单元进行内存回收。
本申请实施例中,电子设备100的操作系统执行的内存回收的操作可以包括:周期回收和直接内存回收。若电子设备100的操作系统正在执行周期回收,则电子设备100的操作系统可以执行控制链表中所有的内存回收单元进行内存回收。若电子设备100的操作系统正在执行直接内存回收,则电子设备100的操作系统可以根据本次内存回收需要回收的内存的大小,执行控制链表中部分的内存回收单元,也就是,电子设备100的操作系统可以从控制链表的起始位置起执行部分的内存回收单元,使得已执行的内存回收单元对应的最大内存回收,满足需要回收的内存的大小,即,电子设备100的操作系统可以执行控制链表中靠前的位置的内存回收单元。
这里,参考图2所示的电子设备100的操作系统创建的内存管理单元,如图2所示,第一内存管理单元至第四内存管理单元的内存大小分别为160MB、40MB、80MB、320MB。通过步骤S1002,电子设备100的操作系统确定需要回收200MB内存,根据图3所示的控制链表,若电子设备100的操作系统通过执行第一内存管理单元和第二内存管理单元对应的第一内存回收单元和第二内存回收单元可以回收到200MB内存,则电子设备100的操作系统可以依次执行第一内存回收单元和第二内存回收单元进行内存回收。
可以看出,图3所示的控制链表中内存回收单元的默认排列顺序可以是在操作系统创建内存管理单元,并为内存管理单元设置内存回收单元时生成的,控制链表中各个内存回收单元的排列顺序是按照操作系统创建各个内存管理单元的时间先后确定的,因此,在操作系统执行内存回收的操作时,也是按照控制链表中内存回收单元的排列顺序依次执行每个内存回收单元进行内存回收。
S1004:获取内存回收单元的执行结果,根据执行结果确定内存回收单元的评价参数。
在本申请实施例中,当电子设备100的操作系统执行过一次内存回收的操作后,电子设备100的操作系统可以获取执行过的内存回收单元的执行结果,这里的执行结果可以参考各种因素,例如,执行结果可以包括内存回收单元的回收能力和回收效率。
电子设备100的操作系统可以根据内存回收单元的执行结果对控制链表中每一个内存回收单元设置一个评价参数,也就是内存回收单元的品质,来确定内存回收单元的最大回收内存以及回收效率的优劣。例如:评价参数可以用取值范围0-100中的一个数值来表示,数值越高表明内存回收单元的品质越好;反之,表明内存回收单元的品质越差。
在电子设备100的操作系统确定了内存回收单元的评价参数后,控制链表中内存回收单元的排列顺序可以根据内存回收单元的评价参数进行调整,也就是说,电子设备100的操作系统将评价参数高的内存回收单元排列于控制链表中靠前的位置。例如,在电子设备100的操作系统执行的内存回收的操作为直接内存回收的情况下,如果操作系统只需执行控制链表中起始位置起的部分内存回收单元就能完成内存回收的情况下(如:操作系统执行控制链表中起始位置起的部分内存回收单元获得的最大回收内存大于本次内存回收的操作需要回收的内存大小),电子设备100的操作系统可以优先执行调整排列顺序后的控制链表中的评价参数高的内存回收单元。
在本申请实施例中,在操作系统每一次进行内存回收后,操作系统可以对内存回收执行的控制链表中的内存回收单元进行评价,根据评价参数将回收能力高、回收效率快的内存回收单元排列到控制链表中靠前的位置,将回收能力低、回收效率慢的内存回收单元排列到控制链表中靠后的位置。同时,随着操作系统运行的应用程序的不断变化,以及操作系统的内存管理单元也发生变化,导致各个内存回收单元的回收能力以及回收效率也会变化,因此,操作系统可以及时地更新控制链表中内存回收单元的排列顺序。
可以理解,这里的回收能力可以是指操作系统执行完该内存回收单元后能够回收的最大回收内存。如图12所示,第一内存管理单元包括5个内存块,每一个内存块的大小为20MB,且5个内存块都被占用;操作系统执行完图12所示的第一内存管理单元对应的第一内存回收单元后,回收了80MB内存,因此上述第一内存回收单元的回收能力就可以是80MB。回收效率可以是指操作系统执行完该第一内存回收单元需要花费的时间,也就是单位时间内第一内存回收单元能够回收的最大回收内存,继续参考图12,操作系统执行完第一内存管理单元对应的第一内存回收单元回收了80MB内存需要耗时10秒,即,10s。因此,操作系统可以确定执行图12所示的第一内存管理单元对应的第一内存回收单元可以实现80MB/10秒,也就是,1秒能够回收8MB内存。如图13所示,若操作系统执行完200MB的第二内存管理单元对应的第二内存回收单元回收了160MB内存需要耗时4秒,则操作系统可以确定执行图13所示的第二内存管理单元对应的第二内存回收单元可以实现160MB/4秒,也就是,1秒能够回收40MB内存。因此,操作系统可以确定图13所示的200MB的第二内存管理单元对应的第二内存回收单元优于图12所示100MB的第一内存管理单元对应的第一内存回收单元,也就是,200MB的第二内存管理单元对应的第二内存回收单元的评价参数高于100MB的第一内存管理单元对应的第一内存回收单元的评价参数。例如:200MB的第二内存管理单元对应的第二内存回收单元的评价参数可以是90,而100MB的第一内存管理单元对应的第一内存回收单元的评价参数可以是80。
可以理解,这里的评价参数:80,90的取值范围可以是在1至100中的任意一个正整数。在另一本申请实施例中,评价参数的取值范围还可以是在1至10中的任意一个正整数,或者,通过等级1至等级10(等级由低到高表示评价参数由低到高)的方式来表示内存回收单元的评价参数,在本申请实施例中对评价参数的设置方式以及的取值范围不做限定。
S1005:调整控制链表中内存回收单元的排列顺序。
在本申请实施例中,在操作系统执行完一次内存回收的操作,并确定了控制链表中被执行的内存回收单元的评价参数后,操作系统可以根据被执行的内存回收单元的评价参数调整控制链表中内存回收单元的排列顺序,将评价参数高的内存回收单元排列于控制链表中靠前的位置。如图14所示,根据步骤S1004中确定的第一内存回收单元和第二内存回收单元各自的评价参数,操作系统可以根据内存回收单元的评价参数在控制链表中对内存回收单元进行降序排列,将第二内存回收单元调整至第一内存回收单元之前,使得控制链表中起始位置起优先排列评价参数高的内存回收单元。可以看出,对于图14中没有评价参数的第三内存回收单元和第四内存回收单元,可以保持在控制链表中的排列顺序不变。
可以理解,当操作系统再次执行内存回收的操作时,操作系统可以优先执行评价参数高的内存回收单元,加快操作系统回收内存的效率。
在本申请实施例中,电子设备100的操作系统还可以设置一个怜悯机制,用于防止排列在控制链表的队列末端的内存回收单元一直得不到执行,内存回收单元的评价参数也就一直无法更新,评价参数一直维持在一个较差的值或者内存回收单元始终没有评价参数,导致内存回收单元在长时间内不会被执行,内存回收单元对应的内存管理单元不会被回收。
在本申请实施例中,电子设备100的操作系统还可以设置一个预设次数阈值(mercy_threshold,门限)以及对控制链表中的每一个内存回收单元设置一个计数器(bad_count);计数器用于记录内存回收单元未被执行的次数,例如,电子设备100的操作系统根据控制链表中的内存回收单元的排列顺序每执行一次内存回收,若一个内存回收单元排列于控制链表的队列末端,且内存回收单元未被执行,则上述内存回收单元的计数器加一,若上述内存回收单元被执行,则计数器清零;若内存回收单元的计数器大于等于预设次数阈值,则电子设备的操作系统可以将上述内存回收单元调整至控制链表中靠前的位置,避免上述内存回收单元对应的内存管理单元长期处于未被回收的状态,并将上述内存回收单元的计数器清零。
参考图15,图15示出了一种电子设备100的操作系统调整排列于控制链表的队列末端(也就是未被执行)的内存回收单元的排列顺序的示意图。如图15所示,第四内存回收单元排列于控制链表的队列末端,电子设备100的操作系统设置的预设次数阈值可以是30,电子设备100的操作系统执行了30次内存回收,每一次内存回收执行完毕,第四内存回收单元一直排列于控制链表的队列末端,因此,第四内存回收单元的计数器达到30;这时,如图15所示,电子设备100的操作系统可以将第四内存回收单元调整至控制链表中靠前的位置(前端),如:将第四内存回收单元调整至控制链表中的第一位置。使得操作系统执行下一次内存回收的操作时,第四内存回收单元对应的内存管理单元能够被操作系统回收。
可以理解,这里的预设次数阈值30只是一种示例,预设次数阈值的取值还可以是其他任意的正整数,如:20或者40,本申请实施例对此不做限定。
参考图16,图16示出了另一种电子设备100的操作系统调整多个排列于控制链表的队列末端(也就是未被执行)的内存回收单元的排列顺序的示意图,如图16所示,第三内存回收单元和第四内存回收单元排列于控制链表的队列末端,电子设备100的操作系统设置的预设次数阈值可以是30,电子设备100的操作系统执行了30次内存回收,每一次内存回收执行完毕,第三内存回收单元和第四内存回收单元一直排列于控制链表的队列末端,因此,第三内存回收单元和第四内存回收单元的计数器达到30;这时,如图16所示,电子设备100的操作系统可以将第三内存回收单元和第四内存回收单元调整至控制链表中靠前的位置(前端),如:按照第三内存回收单元和第四内存回收单元依次排列的排列顺序,将第三内存回收单元调整至控制链表中的第一位置,将第四内存回收单元调整至控制链表中的第二位置,保持调整前控制链表中第三内存回收单元和第四内存回收单元原本的默认排列顺序不变。使得操作系统执行下一次内存回收的操作时,第三内存回收单元和第四内存回收单元对应的内存管理单元能够被操作系统回收。亦或者,将第四内存回收单元调整至控制链表中的第一位置,将第三内存回收单元调整至控制链表中的第二位置,也就是,将排列在末尾的第四内存回收单元调整至控制链表中的第一位置。
可以理解,在电子设备100的操作系统将多个排列于控制链表的队列末端(也就是未被执行)的内存回收单元调整至控制链表的队列前端后,电子设备100的操作系统还可以将多个内存回收单元中对应的内存管理单元的内存大小较大的内存回收单元排列在控制链表中的第一位置,使得电子设备100的操作系统能够回收更多的内存。
可以理解,在电子设备100的操作系统执行完步骤S1005后,操作系统可以回到步骤S1002,继续等待执行下一次的内存回收的操作。
应当理解的是,虽然在本文中可能使用了术语“第一”、“第二”等等来描述各个特征,但是这些特征不应当受这些术语限制。使用这些术语仅仅是为了进行区分,而不能理解为指示或暗示相对重要性。举例来说,在不背离示例性实施例的范围的情况下,第一特征可以被称为第二特征,并且类似地第二特征可以被称为第一特征。
此外,各种操作将以最有助于理解说明性实施例的方式被描述为多个彼此分离的操作;然而,描述的顺序不应被解释为暗示这些操作必须依赖描述的顺序,其中的许多操作可以被并行地、并发地或者同时实施。此外,各项操作的顺序也可以被重新安排。当所描述的操作完成时,所述处理可以被终止,但是还可以具有未包括在附图中的附加操作。所述处理可以对应于方法、函数、规程、子例程、子程序等等。
说明书中对“一个实施例”,“实施例”,“说明性实施例”等的引用表示所描述的实施例可以包括特定特征、结构或性质,但是每个实施例也可能或不是必需包括特定的特征、结构或性质。而且,这些短语不一定是针对同一实施例。此外,当结合具体实施例描述特定特征,本领域技术人员的知识能够影响到这些特征与其他实施例的结合,无论这些实施例是否被明确描述。
除非上下文另有规定,否则术语“包含”、“具有”和“包括”是同义词。短语“A/B”表示“A或B”。短语“A和/或B”表示“(A)、(B)或(A和B)”。
如本文所使用的,术语“模块”可以指代,作为其中的一部分,或者包括:用于运行一个或多个软件或固件程序的存储器(共享、专用或组),专用集成电路(ASIC),电子电路和/或处理器(共享、专用或组),组合逻辑电路,和/或提供所述功能的其他合适组件。
在附图中,可能以特定布置和/或顺序示出了一些结构或方法特征。然而,应当理解的是,这样的特定布置和/或排序不是必需的。而是,在一些实施例中,这些特征可以以不同于说明性附图中所示的方式和/或顺序来进行说明。另外,特定附图中所包含得结构或方法特征并不意味着所有实施例都需要包含这样的特征,在一些实施例中,可以不包含这些特征,或者可以将这些特征与其他特征进行组合。
上面结合附图对本申请的实施例做了详细说明,但本申请技术方案的使用不仅仅局限于本专利实施例中提及的各种应用,各种结构和变型都可以参考本申请技术方案轻易地实施,以达到本文中提及的各种有益效果。在本领域普通技术人员所具备的知识范围内,在不脱离本申请宗旨的前提下做出的各种变化,均应归属于本申请专利涵盖范围。
Claims (14)
1.一种内存回收方法,应用于电子设备,其特征在于,包括:
接收第一类内存回收指令;
响应于所述第一类内存回收指令,根据第一执行顺序执行多个内存回收子程序进行内存回收;
根据各所述内存回收子程序的执行时间和回收到的内存大小,确定各内存回收子程序的内存回收能力;
根据各所述内存回收子程序的内存回收能力,将所述多个内存回收子程序的执行顺序从所述第一执行顺序调整为第二执行顺序。
2.根据权利要求1所述的方法,其特征在于,所述第一类内存回收指令为Linux系统生成的直接内存回收指令。
3.根据权利要求2所述的方法,其特征在于,所述第一执行顺序根据设置所述内存回收子程序的时间先后确定,且所述Linux系统通过预设控制链表记录所述第一执行顺序。
4.根据权利要求1所述的方法,其特征在于,所述执行时间为所述多个内存回收子程序执行完毕所需要的时间。
5.根据权利要求4所述的方法,其特征在于,所述回收到的内存大小为所述内存回收子程序的最大回收内存。
6.根据权利要求5所述的方法,其特征在于,所述内存回收能力包括所述内存回收子程序在单位时间内回收到的内存大小。
7.根据权利要求1所述的方法,其特征在于,根据各所述内存回收子程序的内存回收能力,将所述多个内存回收子程序的执行顺序从所述第一执行顺序调整为第二执行顺序,包括:
各所述内存回收子程序至少包括第一内存回收子程序和第二内存回收子程序,且根据所述第一执行顺序,所述第一内存回收子程序位于所述第二内存回收子程序之前;
确定所述第二内存回收子程序的内存回收能力高于所述第一内存回收子程序的内存回收能力后,将所述第一内存回收子程序和所述第二内存回收子程序调整为所述第二执行顺序,所述第二内存回收子程序位于所述第一内存回收子程序之前。
8.根据权利要求1所述的方法,其特征在于,所述内存回收子程序包括计数器,所述计数器用于记录所述内存回收子程序未被执行的次数。
9.根据权利要求8所述的方法,其特征在于,根据各所述内存回收子程序的内存回收能力,将所述多个内存回收子程序的执行顺序从所述第一执行顺序调整为第二执行顺序,还包括:
各所述内存回收子程序至少包括第三内存回收子程序和第四内存回收子程序,且根据所述第一执行顺序,所述第三内存回收子程序位于所述第四内存回收子程序之前;
若所述第四内存回收子程序的计数器达到预设计时阈值,且所述第三内存回收子程序的计数器未达到预设计时阈值,将所述第三内存回收子程序和所述第四内存回收子程序调整为所述第二执行顺序,所述第四内存回收子程序位于所述第三内存回收子程序之前。
10.根据权利要求9所述的方法,其特征在于,将所述第三内存回收子程序和所述第四内存回收子程序调整为所述第二执行顺序之后,包括:
将所述第四内存回收子程序的计数器清零。
11.根据权利要求9所述的方法,其特征在于,包括:
各所述内存回收子程序还包括第五内存回收子程序,且根据所述第一执行顺序,所述第五内存回收子程序位于所述第四内存回收子程序之后;
若所述第四内存回收子程序和所述第五内存回收子程序的计数器达到预设计时阈值,且所述第三内存回收子程序的计数器未达到预设计时阈值,将所述第三内存回收子程序、所述第四内存回收子程序和所述第五内存回收子程序调整为所述第二执行顺序,所述第四内存回收子程序和所述第五内存回收子程序位于所述第三内存回收子程序之前,且所述第四内存回收子程序和所述第五内存回收子程序依次排列。
12.根据权利要求11所述的方法,其特征在于,所述第五内存回收子程序位于所述第四内存回收子程序之前。
13.一种电子设备,其特征在于,包括:
处理器,用于执行权利要求1至12中任一项所述内存回收方法;以及
存储器,可以与控制器耦合或者解耦用于存储由所述控制器执行的指令。
14.一种计算机可读存储介质,其特征在于,所述计算机可读存储介质中包含有指令,当所述指令被电子设备的控制器执行时使电子设备实现权利要求1至12中任一项所述内存回收方法。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN202210185733.1A CN114253872B (zh) | 2022-02-28 | 2022-02-28 | 电子设备及其内存回收方法、介质 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN202210185733.1A CN114253872B (zh) | 2022-02-28 | 2022-02-28 | 电子设备及其内存回收方法、介质 |
Publications (2)
Publication Number | Publication Date |
---|---|
CN114253872A true CN114253872A (zh) | 2022-03-29 |
CN114253872B CN114253872B (zh) | 2022-07-12 |
Family
ID=80800051
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN202210185733.1A Active CN114253872B (zh) | 2022-02-28 | 2022-02-28 | 电子设备及其内存回收方法、介质 |
Country Status (1)
Country | Link |
---|---|
CN (1) | CN114253872B (zh) |
Citations (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20190205265A1 (en) * | 2017-12-29 | 2019-07-04 | Guangdong Oppo Mobile Telecommunications Corp., Ltd. | Memory processing method and device and storage medium |
CN111124254A (zh) * | 2018-10-30 | 2020-05-08 | 伊姆西Ip控股有限责任公司 | 调度存储空间回收请求的方法、电子设备和程序产品 |
CN111831440A (zh) * | 2020-07-01 | 2020-10-27 | Oppo广东移动通信有限公司 | 内存回收方法、装置、存储介质及电子设备 |
WO2021057619A1 (zh) * | 2019-09-27 | 2021-04-01 | Oppo广东移动通信有限公司 | 内存回收方法、装置、电子设备及存储介质 |
-
2022
- 2022-02-28 CN CN202210185733.1A patent/CN114253872B/zh active Active
Patent Citations (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20190205265A1 (en) * | 2017-12-29 | 2019-07-04 | Guangdong Oppo Mobile Telecommunications Corp., Ltd. | Memory processing method and device and storage medium |
CN111124254A (zh) * | 2018-10-30 | 2020-05-08 | 伊姆西Ip控股有限责任公司 | 调度存储空间回收请求的方法、电子设备和程序产品 |
WO2021057619A1 (zh) * | 2019-09-27 | 2021-04-01 | Oppo广东移动通信有限公司 | 内存回收方法、装置、电子设备及存储介质 |
CN111831440A (zh) * | 2020-07-01 | 2020-10-27 | Oppo广东移动通信有限公司 | 内存回收方法、装置、存储介质及电子设备 |
Also Published As
Publication number | Publication date |
---|---|
CN114253872B (zh) | 2022-07-12 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
CN112783564B (zh) | 一种加速应用程序启动的方法及电子设备 | |
CN112217923A (zh) | 一种柔性屏幕的显示方法及终端 | |
CN113722058B (zh) | 一种资源调用方法及电子设备 | |
WO2021159746A1 (zh) | 文件共享方法、系统及相关设备 | |
CN113704205B (zh) | 日志存储的方法、芯片、电子设备和可读存储介质 | |
CN112817736B (zh) | 一种内存的管理方法及电子设备 | |
CN114461588A (zh) | 调节预读窗口的方法及电子设备 | |
CN114489529A (zh) | 电子设备的投屏方法及其介质和电子设备 | |
CN113495744A (zh) | 一种版本升级方法及相关装置 | |
CN112667306A (zh) | 安装插件的方法、装置和存储介质 | |
CN112612539B (zh) | 数据模型卸载方法、装置、电子设备及存储介质 | |
CN113608753A (zh) | 应用卸载方法、应用恢复方法、电子设备以及存储介质 | |
CN114253737B (zh) | 电子设备及其内存回收方法、介质 | |
CN113391743A (zh) | 一种显示方法及电子设备 | |
CN114253872B (zh) | 电子设备及其内存回收方法、介质 | |
CN112835610A (zh) | 一种构建应用程序资源包的方法、构建装置及终端设备 | |
CN114461239B (zh) | 软件升级系统和软件升级方法 | |
CN113784331B (zh) | 更新用户身份识别模块卡系统数据的方法及装置 | |
CN112783418B (zh) | 一种存储应用程序数据的方法及移动终端 | |
CN111221544B (zh) | 一种预装应用软件的管理方法及终端 | |
CN113467821A (zh) | 应用程序的修复方法、装置、设备及可读存储介质 | |
CN113835802A (zh) | 设备交互方法、系统、设备及计算机可读存储介质 | |
CN113741911A (zh) | 功能包的加载方法、装置、服务器和电子设备 | |
CN114398108A (zh) | 电子设备及其驱动加载方法、介质 | |
CN114579181A (zh) | 打补丁的方法、相关设备及系统 |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
PB01 | Publication | ||
PB01 | Publication | ||
SE01 | Entry into force of request for substantive examination | ||
SE01 | Entry into force of request for substantive examination | ||
GR01 | Patent grant | ||
GR01 | Patent grant |