CN111831440A - 内存回收方法、装置、存储介质及电子设备 - Google Patents
内存回收方法、装置、存储介质及电子设备 Download PDFInfo
- Publication number
- CN111831440A CN111831440A CN202010628802.2A CN202010628802A CN111831440A CN 111831440 A CN111831440 A CN 111831440A CN 202010628802 A CN202010628802 A CN 202010628802A CN 111831440 A CN111831440 A CN 111831440A
- Authority
- CN
- China
- Prior art keywords
- thread
- memory
- recovery
- type
- threads
- 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.)
- Pending
Links
- 230000015654 memory Effects 0.000 title claims abstract description 373
- 238000011084 recovery Methods 0.000 title claims abstract description 213
- 238000000034 method Methods 0.000 title claims abstract description 104
- 230000000903 blocking effect Effects 0.000 claims abstract description 9
- 230000003993 interaction Effects 0.000 claims description 60
- 230000008569 process Effects 0.000 claims description 56
- 238000004064 recycling Methods 0.000 claims description 40
- 238000004590 computer program Methods 0.000 claims description 20
- 238000001514 detection method Methods 0.000 claims description 6
- 230000002452 interceptive effect Effects 0.000 abstract description 3
- 230000003068 static effect Effects 0.000 description 12
- 238000010586 diagram Methods 0.000 description 6
- 238000012545 processing Methods 0.000 description 6
- 238000004891 communication Methods 0.000 description 5
- 230000006870 function Effects 0.000 description 5
- 230000007246 mechanism Effects 0.000 description 5
- 238000012360 testing method Methods 0.000 description 4
- 238000013468 resource allocation Methods 0.000 description 3
- 230000026676 system process Effects 0.000 description 3
- 238000007726 management method Methods 0.000 description 2
- 230000003287 optical effect Effects 0.000 description 2
- XLYOFNOQVPJJNP-UHFFFAOYSA-N water Substances O XLYOFNOQVPJJNP-UHFFFAOYSA-N 0.000 description 2
- 230000001133 acceleration Effects 0.000 description 1
- 239000011230 binding agent Substances 0.000 description 1
- 230000007547 defect Effects 0.000 description 1
- 238000011161 development Methods 0.000 description 1
- 238000011982 device technology Methods 0.000 description 1
- 238000007599 discharging Methods 0.000 description 1
- 238000005516 engineering process Methods 0.000 description 1
- 230000007613 environmental effect Effects 0.000 description 1
- 238000012544 monitoring process Methods 0.000 description 1
- 238000005457 optimization Methods 0.000 description 1
Images
Classifications
-
- 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
-
- 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/5022—Mechanisms to release resources
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F2209/00—Indexing scheme relating to G06F9/00
- G06F2209/50—Indexing scheme relating to G06F9/50
- G06F2209/5021—Priority
Landscapes
- Engineering & Computer Science (AREA)
- Software Systems (AREA)
- Theoretical Computer Science (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Debugging And Monitoring (AREA)
Abstract
本申请实施例公开了一种内存回收方法、装置、存储介质及电子设备，其中，本申请实施例在接收到线程发送的内存分配请求时，确定当前的空闲内存量；若空闲内存量小于预设阈值，则确定线程的类型，其中，将线程划分为优先级不同的多类线程；获取与线程的类型对应的内存回收比例，并按照内存回收比例对已分配内存空间中的内存页进行回收，不同种类的内存回收对象的回收效率不同，线程的优先级越高，则对应的内存回收比例中回收效率高的内存回收对象的占比越大。提高了第一类线程的内存分配效率，避免第一类线程因为不能及时得到内存而导致出现交互场景下的卡顿现象，提升用户体验。
Description
技术领域
本申请涉及电子设备技术领域，具体涉及一种内存回收方法、装置、存储介质及电子设备。
背景技术
随着技术的发展，电子设备中安装的各类应用程序越来越多，例如视频类应用、游戏类应用以及即时通讯类应用等。这使得电子设备经常需要在前台和后台运行很多个应用程序，容易在用户交互场景中出现卡顿现象。
发明内容
本申请实施例提供一种内存回收方法、装置、存储介质及电子设备，能够减少交互场景下的卡顿现象。
第一方面，本申请实施例提供一种内存回收方法，包括：
当接收到线程发送的内存分配请求时，确定当前的空闲内存量；
若所述空闲内存量小于预设阈值，则确定所述线程的类型，其中，将线程划分为优先级不同的多类线程，其中，第一类线程具有最高优先级，所述第一类线程为执行用户交互事件中相关任务的线程；
获取与所述线程的类型对应的内存回收比例，并按照所述内存回收比例对已分配内存空间中的内存页进行回收，其中，所述内存回收比例用于表征多种内存回收对象之间的比例，不同种类的内存回收对象的回收效率不同，线程的优先级越高，则对应的内存回收比例中回收效率高的内存回收对象的占比越大。
第二方面，本申请实施例还提供一种内存回收装置，包括：
内存检测模块，用于当接收到线程发送的内存分配请求时，确定当前的空闲内存量；
线程识别模块，用于若所述空闲内存量小于预设阈值，则确定所述线程的类型，其中，将线程划分为优先级不同的多类线程，其中，第一类线程具有最高优先级，所述第一类线程为执行用户交互事件中相关任务的线程；
内存回收模块，用于获取与所述线程的类型对应的内存回收比例，并按照所述内存回收比例对已分配内存空间中的内存页进行回收，其中，所述内存回收比例用于表征多种内存回收对象之间的比例，不同种类的内存回收对象的回收效率不同，线程的优先级越高，则对应的内存回收比例中回收效率高的内存回收对象的占比越大。
第三方面，本申请实施例还提供一种存储介质，其上存储有计算机程序，当所述计算机程序在计算机上运行时，使得所述计算机执行如本申请任一实施例提供的内存回收方法。
第四方面，本申请实施例还提供一种电子设备，包括处理器和存储器，所述存储器有计算机程序，所述处理器通过调用所述计算机程序，用于执行如本申请任一实施例提供的内存回收方法。
本申请实施例提供的技术方案，在接收到线程发送的内存分配请求时，先确定当前的空闲内存量，如果空闲内存量小于预设阈值，则要先进行内存回收，接下来对线程的类型进行识别，在内存回收时，根据请求内存的线程的类型的不同，采用不同的内存回收比例进行内存回收，该内存回收比例用于表征多种内存回收对象之间的比例，由于不同种类的内存回收对象的回收效率不同，因此若内存回收比例不同，则整体的回收效率也不相同。其中，第一类线程为执行用户交互事件中相关任务的线程，具有最高优先级，也就是说，第一类线程对应的内存回收比例中回收效率高的内存回收对象的占比在所有类别的线程中为最大占比，因此，对于第一类线程来说，在全部线程中具有最高效率的内存回收机制，可以尽快完成内存回收，提高了第一类线程的内存分配效率，避免第一类线程因为不能及时得到内存而导致出现交互场景下的卡顿现象，提升用户体验。
附图说明
为了更清楚地说明本申请实施例中的技术方案，下面将对实施例描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本申请的一些实施例，对于本领域技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。
图1为本申请实施例提供的内存回收方法的第一种流程示意图。
图2为本申请实施例提供的内存回收方法的第二种流程示意图。
图3为本申请实施例提供的内存回收装置的结构示意图。
图4为本申请实施例提供的电子设备的第一种结构示意图。
图5为本申请实施例提供的电子设备的第二种结构示意图。
具体实施方式
下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述。显然，所描述的实施例仅仅是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域技术人员在没有付出创造性劳动前提下所获得的所有其他实施例，都属于本申请的保护范围。
在本文中提及“实施例”意味着，结合实施例描述的特定特征、结构或特性可以包含在本申请的至少一个实施例中。在说明书中的各个位置出现该短语并不一定均是指相同的实施例，也不是与其它实施例互斥的独立的或备选的实施例。本领域技术人员显式地和隐式地理解的是，本文所描述的实施例可以与其它实施例相结合。
本申请实施例提供一种内存回收方法，该内存回收方法的执行主体可以是本申请实施例提供的内存回收装置，或者集成了该内存回收装置的电子设备，其中该内存回收装置可以采用硬件或者软件的方式实现。其中，电子设备可以是智能手机、平板电脑、掌上电脑、笔记本电脑、或者台式电脑等设备。
请参阅图1，图1为本申请实施例提供的内存回收方法的第一种流程示意图。本申请实施例提供的内存回收方法的具体流程可以如下：
在101中，当接收到线程发送的内存分配请求时，确定当前的空闲内存量。
本申请实施例中，电子设备的操作系统可以是基于linux内核的系统，例如，安卓操作系统等。电子设备的系统进程和应用程序的进程的运行，都需要系统内核为其分配内存空间。并且随着系统的运行情况，内核不断地进行着内存的回收与分配等。
线程是进程的一条执行路径，是程序执行时的最小单位，也是内存分配的基本单位。一个进程可以有多个线程，但至少有一个线程。
对于内核来说，在进行资源调度时，比如CPU调度，都是具体到某个线程的。进程内有一个主线程，它也会创建出很多子线程来协助工作。比如一个内容交互应用程序的进程，它会创建一个主线程来执行代码，执行途中也会创建其它子线程来协助运行各部分的任务代码。
本申请实施例中，进程有任务需要执行时，会创建一个新的线程来执行该任务，而线程需要内核为之分配一定量的内存空间供其运行。因此，线程在执行任务前，会向内核发送内存分配请求。
内核在接收到内存分配请求时，先确定当前的空闲内存量。
其中，Linux内核使用三个内存水线来标记系统空闲内存量的状态,按照从小至大的顺序，依次分别为：high水线、low水线和min水线。当系统空闲内存量低于low水线时，系统会唤醒内存回收进程kswapd进行内存回收,直到空闲内存量不低于high水线为止。内存回收进程kswapd进行内存回收时，内存消耗的速度会相对变缓，但是内存分配也会进入慢速分配路径(slowpath)，意味着内存分配效率也会变慢。需要说明的是，这里的慢速分配路径是一种抽象的概念，是指系统由于需要在后台进行内存回收而对线程的内存分配效率变慢。其中，上述low水线为本申请实施例中的预设阈值。
此外，内核主要通过回收匿名页和文件页实现内存回收。回收匿名页和文件页的策略不一样，回收匿名页一般是将其压缩后存放在RAM中，由于该过程需要使用CPU将其压缩，使用时再解压缩，回收过程需要消耗一定的CPU时间，相对较慢。回收文件页分两种，如果文件内容没有被修改过，直接将文件页内容丢弃；如果文件内容被修改了，需要将内容写回磁盘再将文件页丢弃，再次需要时重新从磁盘读取。一般而言，很多文件页是没有被修改的，回收过程相对较快。常规的回收手段，一般会倾向于回收匿名页，保留文件页，以降低再次重新读磁盘数据IO带来的代价，但是这种回收机制下，在一些场景下，可能会因为内存回收较慢可能导致卡顿，影响用户体验。
为了改善这种缺陷，本申请实施例中，从全部线程中将那些与用户体验相关的线程标记出来，对于这些用户体验相关的线程来说，采取一种高效的内存回收方式，例如，全部通过回收内存页来进行内存回收，提升内存回收速度，尽快回收到需要的内存，缩短慢速路径的时间。
在102中，若空闲内存量小于预设阈值，则确定线程的类型，其中，将线程划分为优先级不同的多类线程，其中，第一类线程具有最高优先级，第一类线程为执行用户交互事件中相关任务的线程。
执行用户交互事件中相关任务的线程是否能够流畅运行决定着是否会在用户交互事件中产生用户可感知的卡顿，故本申请实施例中，确定出执行用户交互事件中相关任务的线程，并将这些与用户体验紧密相关的线程记为ux(user experience，用户体验)线程，即第一类线程。本申请实施例中，将除ux线程之外的线程记为第二类线程。第二类线程的运行情况一般不会影响用户体验，或者对用户体验影响较小。
其中，电子设备的系统架构至少包括应用框架(framework)层和内核(kernel)层，本申请实施例，从应用框架层和内核层的角度对ux线程进行识别和标记，例如，应用框架层为一些直接执行用户交互事件中相关任务的线程添加预设标签，以将这些线程标记为静态ux线程，内核层将一些间接地影响到用户交互事件中相关任务执行的线程标记为动态ux线程。
本申请实施例中的进程包括系统级进程和应用级进程。由于产生用户可感知的界面的卡顿的场景多是相对于运行在前台的进程来说的。因此，本申请实施例的方案中，“确定出执行用户交互事件中相关任务的线程”包括：在检测到有进程切换到前台运行时，确定前台进程；从该前台进程的线程中确定出用于执行用户交互事件中相关任务的线程，作为目标线程。
例如，在一实施例中，“从前台进程的线程中确定出用于执行用户交互事件中相关任务的目标线程，并将目标线程标记为第一类线程”包括：从前台进程的线程中识别出用于执行用户交互事件中相关任务的第一预设线程，作为目标线程；为目标线程添加预设标签，以将线程标记为第一类线程。
例如，上述第一预设线程包括进程运行时创建的一些用于直接执行用户交互事件的相关任务的线程，如UI(user interface，用户界面)线程，Render(渲染)线程，GL线程，用户输入事件的分发线程，用户输入事件的检测线程等。这些线程是否能够流畅运行决定着是否会在用户与该进程的交互界面中产生用户可感知的卡顿。
比如，用户使用聊天软件与某一好友聊天，用户在对话框输入文字，电子设备通过服务器将用户输入的文字发送至该好友的电子设备。在这次交互事件中，需要UI线程、Render线程、用户输入事件的分发线程、用户输入事件的检测线程等线程共同工作，以完成本次用户交互事件，其中，每一个线程的运行都需要系统为其分配资源。因此，在检测到该聊天软件在前台运行时，识别出这些线程，将其标记为ux线程。
其中，第一预设线程一般是应用级线程，这些线程可以是通过对实际的卡顿场景进行分析来确定。比如，在测试中，如果某一用户交互场景下发生了应用卡顿，通过对该场景分析发现卡顿现象是某个线程处理任务太慢导致的，则可以认为该线程是用于执行用户交互事件中相关任务的，该线程的运行与用户体验紧密相关，可以将该线程作为第一预设线程。
基于此，可以通过对各种可能的卡顿场景进行测试，记录这些导致卡顿出现的线程。电子设备中存储这些第一预设线程的相关信息，当进程切换到前台运行时，将该进程下的属于预先记录的第一预设线程的线程都标记为ux线程。
可以理解的是，对于电子设备来说，存储的第一预设线程的相关信息并不是不可修改的，当进行系统升级时，可以对第一预设线程的相关信息进行更新。
此外，在另一实施例中，该方法还包括：当检测到有第二预设线程创建时，将创建的第二预设线程标记为第一类线程，其中，第二预设线程为系统级线程。
由于在执行用户交互事件的过程中，除了应用级线程之外，可能还涉及到一些系统级的线程来完成任务，系统框架层也需要将这些系统级线程标记为ux线程。一般这些线程在系统启动时就会创建，因此，可以在检测到系统启动时，识别出这些线程并进行标记，比如，Surfaceflinger线程、系统动画线程等。或者，在系统运行过程中，如果检测到有新的系统进程的线程创建并用来执行用户交互事件中相关任务，系统框架层也将这些线程标记为ux线程。比如，SystemUI线程。其中，第二预设线程也可以通过对实际的卡顿场景进行分析来确定。比如，在测试中，如果某一用户交互场景下发生了应用卡顿，通过对该场景分析发现卡顿现象是某个系统级线程处理任务太慢导致的，则可以认为该系统级线程是用于执行用户交互事件中相关任务的，该系统级线程的运行与用户体验紧密相关，可以将该系统级线程作为第二预设线程。电子设备中存储这些第二预设线程的相关信息，如果检测到系统创建了这些线程，则将其标记为ux线程。
其中，预设标签可以为ux标签，其添加方式如下：Linux使用task_struct结构体描述和记录线程，每个线程都有对应的task_struct结构体。task_struct中记录了线程的名称、标识符、状态、优先级、内存指针、上下文数据等属性信息。因此，应用框架层可以在task_struct结构体中增加对应的ux flag成员，以将前台进程的UI线程、Render线程、GL线程等执行用户交互事件中相关任务的线程，通过标记ux flag位，使内核层能够识别该线程的任务属性。
需要说明的是，上述几种静态ux线程仅为举例说明，并不局限于此，只要是直接地执行用户交互事件中相关任务的线程，使得其运行情况直接地影响到用户体验的线程，都可以将其标记为静态ux线程。对于应用框架层来说，在检测到新创建的线程是用来执行用户交互事件，或者检测到某些常驻系统级线程是用以处理用户交互事件时，为这些线程添加ux标签，以将其标记为静态ux线程。
在另一实施例中，“从前台进程的线程中确定出用于执行用户交互事件中相关任务的目标线程，并将目标线程标记为第一类线程”还包括：在前台进程的运行过程中，当检测到有新线程创建时，确定新创建的线程是否用于执行用户交互事件中的相关任务；当新创建的线程用于执行用户交互事件中的相关任务时，将新创建的线程标记为第一类线程。
前台进程在运行过程中，如果有用户交互事件发生，除了上述应用级的第一预设线程和系统级的第二预设线程之外，还可能会有一些临时创建的任务线程，这些任务线程的运行也会直接影响到是否会在用户与该进程的交互界面中产生用户可感知的卡顿。因此，应用框架层会将这些线程也标记为ux线程。
其中，电子设备根据检测到的用户指令确定发生的用户交互事件。用户交互事件一般是指用户触发了某指令后，电子设备需要即时的对该指令进行响应，进行某种处理并将处理结果显示在界面上的情况。例如，用户使用电子设备观看视频、编辑短信、使用聊天软件、使用游戏软件、控制电子设备界面的切换、使用浏览浏览网页等，都属于用户交互事件。比如，用户使用聊天软件与某一好友聊天，用户在对话框输入文字，电子设备通过服务器将用户输入的文字发送至该好友的电子设备。在这个过程中，电子设备需要调度多个线程以完成本次用户交互事件，从该用户交互事件的开始到完成的整个过程中，进程创建的用来完成这次用户交互事件的线程都可以认为是与用户体验相关的线程。
在另一实施例中，为目标线程添加预设标签之后，该方法还包括：若前台进程为应用进程，则在检测到前台进程切换至后台运行时，删除第一预设线程的预设标签。当前台进程切换到后台运行时，该进程的运行情况已经与用户体验无关，其线程的重要程度也有所下降，因此，可以将该进程对应的第一预设线程的ux标记删除，将这些ux线程恢复为普通线程。
此外，对于那些在用户交互事件中临时创建的任务线程来说，在执行完对应的任务后就会被销毁，其自然会丢失掉ux标签。而对于系统级的第二预设线程来说，即使发生了进程的前后台切换，这些线程始终与用户体验相关，所以始终保有ux标签。
通过上述实施例，框架层识别出那些直接影响到用户体验的线程并为其添加标记。而线程的运行，需要内核为之分配系统资源。因此，线程在执行任务前，会向内核请求资源。内核在基于该请求为其分配资源时，可以先判断该线程是否为ux线程，对于ux线程和非ux线程采用不同的资源分配方式。
需要说明的是，这里的第一类线程和第二类线程中的“第一类”和“第二类”，仅仅是为了区分线程是否具有ux标签，而不是说将系统中的线程只划分为这两种类别。本申请的资源分配优化方案是从线程是否具有ux标签这一角度出发的，如果线程同时还具有其他属性，则在资源分配时，考虑了是否具有ux标签这一属性后，仍然会考虑其他属性。
上述实施例介绍了静态ux线程的识别。还有一些线程虽然并没有直接地执行用户交互事件的相关任务，但是这些线程的运行情况也会影响到静态ux线程的运行情况，进而间接地影响到用户交互事件的相关任务的执行。也就是说，这些线程并不是总是与用户体验相关，但是这些线程在执行过程的某段时间内，可能通过资源约束与静态ux线程产生关联，因此，在一些实施例中，为了进一步地减少交互场景下的卡顿现象，内核层将这些与静态ux线程之间有约束关系的线程也标记为ux线程。而一旦这种约束关系结束，就会将该线程恢复至非ux线程。本申请实施例中将这类线程定义为动态ux线程。其中，具体的约束关系包括但不限于进程间通信、线程间通信或者持有临界资源等。比如，静态ux线程通过进程间通信请求的普通线程，静态ux线程通过某种线程间通信方式请求的普通线程，持有静态ux线程需要的等待信号量、读写信号量、互斥锁等临界资源的普通线程等，本申请实施例中将这类线程标记为动态ux线程。
基于此，在一些实施例中，该方法还包括：对第一类线程的运行状态进行检测；当检测到有第一类线程进入阻塞状态，则确定与进入阻塞状态的第一类线程之间有约束关系的关联线程；为关联线程添加预设标签，以将关联线程标记为第一类线程。
在一些实施例中，将关联线程标记为第一类线程之后，还包括：当检测到约束关系解除时，删除关联线程的预设标签。
其中，关于线程的阻塞状态，在内核层面一般会区分为D状态(Uninterruptablesleep状态，不可中断的睡眠状态)和S状态(interruptable sleep状态，可中断的睡眠状态)，比如，线程发起IO请求但得不到满足，就进入D状态；线程发起同步Binder请求，就会进入S状态。线程进入这些状态一般都是因为这些都是线程任务执行途中因为某些原因或者逻辑，需要主动或者被动地放弃CPU资源。
该实施例中，内核层对静态ux线程的状态进行检测，当检测到ux线程进入到堵塞状态时，确定出与进入堵塞状态的ux线程之间具有约束关系的关联线程，如果这些关联线程没有及时分配到资源，比如IO资源，而导致运行受阻，则由于关联线程的运行缓慢又会导致该ux线程长时间处于阻塞状态，因此，为了避免该ux线程长时间处于阻塞状态，内核层会将识别出的关联线程也标记为ux线程，以提高其IO处理效率，保证其及时执行，进而快速解除该ux线程的阻塞状态。
上文中介绍了应用框架层和内核层识别并标记ux线程的方式。对于内核来说，对于每一种线程设置有不同的内存回收比例，本申请实时中，内存回收对象包括匿名页和文件页，回收文件页的效率高于回收匿名页的效率。内存回收比例为文件页和匿名页的比例。由于对于用户体验来说，ux线程的重要程度大于非ux线程的重要程度，因此，设置ux线程的优先级大于非ux线程的优先级，ux线程的内存回收比例中文件页的占比，大于非ux线程中文件页的占比。比如，在一实施例中，ux线程的内存回收比例为200:0，非ux线程的内存回收比例为60:140。也就是说，当前线程为ux线程时，回收对象可以全部是文件页。而当前线程为非ux线程时，大部分回收对象为匿名页。需要说明的是，上述数值为举例说明，不构成对本方案的限制，只要ux线程的内存回收比例中文件页的占比大于非ux线程的内存回收比例中文件页的占比即可。
在103中，获取与线程的类型对应的内存回收比例，并按照内存回收比例对已分配内存空间中的内存页进行回收，其中，内存回收比例用于表征多种内存回收对象之间的比例，不同种类的内存回收对象的回收效率不同，线程的优先级越高，则对应的内存回收比例中回收效率高的内存回收对象的占比越大。
内核在接收到内存分配请求后，可以先根据该线程的标签确定该线程的类型。并按照与线程对应的内存回收比例，对已分配内存空间中的内存页进行回收。仍然以ux线程的内存回收比例为200:0，非ux线程的内存回收比例为60:140为例。例如，要回收到内存量为200M，当前线程为ux线程时，200M的内存量全部通过回收文件页得到。当前线程为非ux线程时，其中60M的内存量通过回收文件页得到，另外140M的内存量通过回收匿名页得到。其中，已分配内存空间是指由已经分配给线程、处于被占用状态的内存页构成的内存空间。
具体实施时，本申请不受所描述的各个步骤的执行顺序的限制，在不产生冲突的情况下，某些步骤还可以采用其它顺序进行或者同时进行。
由上可知，本申请实施例提供的内存回收方法，在接收到线程发送的内存分配请求时，先确定当前的空闲内存量，如果空闲内存量小于预设阈值，则要先进行内存回收，接下来对线程的类型进行识别，在内存回收时，根据请求内存的线程的类型的不同，采用不同的内存回收比例进行内存回收，该内存回收比例用于表征多种内存回收对象之间的比例，由于不同种类的内存回收对象的回收效率不同，因此若内存回收比例不同，则整体的回收效率也不相同。其中，第一类线程为执行用户交互事件中相关任务的线程，具有最高优先级，也就是说，第一类线程对应的内存回收比例中回收效率高的内存回收对象的占比在所有类别的线程中为最大占比，因此，对于第一类线程来说，在全部线程中具有最高效率的内存回收机制，可以尽快完成内存回收，提高了第一类线程的内存分配效率，避免第一类线程因为不能及时得到内存而导致出现交互场景下的卡顿现象，提升用户体验。
根据前面实施例所描述的方法，以下将举例作进一步详细说明。
请参阅图2，图2为本发明实施例提供的内存回收方法的第二流程示意图。
方法包括：
在201中，当接收到线程发送的内存分配请求时，确定当前的空闲内存量。
在上文的一些实施例中，将线程分为两类：ux线程和非ux线程，进行处理。在该实施例中，可以将线程分为三类进行处理，根据线程的运行情况对用户体验的影响程度的大小，将系统中的线程划分为优先级由高至低的ux线程、前台线程和后台线程。其中，ux线程的识别与标记方式请参照上述实施例，在此不再赘述。
将ux线程记为第一类线程，当检测到有线程切换至前台运行时，判断切换至前台运行的线程是否为第一类线程；若否，则为线程添加第二预设标签，以将线程标记为第二类线程；当检测到有线程切换至后台运行时，判断切换至后台运行的线程是否为第一类线程；若否，则为线程添加第三预设标签，以将线程标记为第三类线程。
通过这种方式，将除了ux线程之外的其他线程中运行在前台的线程作为第二类线程，记为FG线程，将除了ux线程之外的其他线程中运行在后台的线程作为第三类线程，记为BG线程。
其中，对于用户体验来说，ux线程的重要程度大于FG线程的重要程度，FG线程的重要程度大于BG线程的重要程度。因此，设置ux线程的优先级大于FG线程的优先级，FG线程的优先级大于BG线程的优先级。ux线程的内存回收比例中文件页的占比，大于FG线程中文件页的占比；FG线程的内存回收比例中文件页的占比，大于BG线程中文件页的占比。
在202中，若空闲内存量小于预设阈值，则获取线程携带的标签，并根据标签确定线程的类型。
内核在接收到内存分配请求后，可以先根据该线程的标签确定该线程的类型。其中，若标签为第一预设标签，则判定线程为第一类线程；若标签为第二预设标签，则判定线程为第二类线程；若标签为第三预设标签，则判定线程为第三类线程。
在203中，当线程为第一类线程时，按照第一内存回收比例对已分配内存空间中的内存页进行回收，其中，第一类线程为执行用户交互事件中相关任务的线程。
在204中，当线程为第二类线程时，按照第二内存回收比例对已分配内存空间中的内存页进行回收，其中，第一内存回收比例中回收效率高的内存回收对象的占比，高于第二内存回收比例中回收效率高的内存回收对象的占比。
在205中，当线程为第三类线程时，按照第三内存回收比例对已分配内存空间中的内存页进行回收，其中，第二内存回收比例中回收效率高的内存回收对象的占比，高于第三内存回收比例中回收效率高的内存回收对象的占比。
确定该线程的类型后，按照与线程对应的内存回收比例，对已分配内存空间中的内存页进行回收。以ux线程的内存回收比例为200:0，FG线程的内存回收比例为140:60为例，BG线程的内存回收比例为0:200。当前线程为ux线程时，以最快速度回收到所需内存，200M的内存量全部通过回收文件页得到。当前线程为FG线程时，需要较快地回收到内存，其中140M的内存量通过回收文件页得到，另外60M的内存量通过回收匿名页得到。当前线程为BG线程时，200M的内存量全部通过回收匿名页得到，尽量地保护文件页。上述参数仅作举例说明，实际使用时可以根据实际测试结果做参数调整。
由上可知，本发明实施例提出的内存回收方法，根据线程的运行情况对用户体验的影响程度的大小，将系统中的线程划分为优先级由高至低的ux线程、前台线程和后台线程。在进行内存回收时，根据线程类型的不同，采用不同的内存回收比例回收内存，线程的优先级越高，则对应的内存回收比例中文件页的占比越大。因此，当前线程为ux线程时的回收速度大于为前台线程时的回收速度，当前线程为前台线程时的回收速度大于为后台线程时的回收速度，并且在当前线程为后台线程时，能够尽量保护文件页不被回收。在避免第一类线程因为不能及时得到内存而导致出现交互场景下的卡顿现象，提升用户体验的同时，降低再次重新读磁盘数据IO带来的代价。
在一实施例中还提供一种内存回收装置。请参阅图3，图3为本申请实施例提供的内存回收装置300的结构示意图。其中该内存回收装置300应用于电子设备，该内存回收装置300包括内存检测模块301、线程识别模块302以及内存回收模块303，如下：
内存检测模块301，用于当接收到线程发送的内存分配请求时，确定当前的空闲内存量；
线程识别模块302，用于若空闲内存量小于预设阈值，则确定线程的类型，其中，将线程划分为优先级不同的多类线程，其中，第一类线程具有最高优先级，第一类线程为执行用户交互事件中相关任务的线程；
内存回收模块303，用于获取与线程的类型对应的内存回收比例，并按照内存回收比例对已分配内存空间中的内存页进行回收，其中，内存回收比例用于表征多种内存回收对象之间的比例，不同种类的内存回收对象的回收效率不同，线程的优先级越高，则对应的内存回收比例中回收效率高的内存回收对象的占比越大。
在一些实施例中，内存回收模块303还用于：当线程为第一类线程时，按照第一内存回收比例对已分配内存空间中的内存页进行回收；
当线程为第二类线程时，按照第二内存回收比例对已分配内存空间中的内存页进行回收，其中，第一内存回收比例中回收效率高的内存回收对象的占比，高于第二内存回收比例中回收效率高的内存回收对象的占比。
在一些实施例中，将线程划分为优先级不同的三类线程；内存回收模块303还用于：当线程为第三类线程时，按照第三内存回收比例对已分配内存空间中的内存页进行回收，其中，第二内存回收比例中回收效率高的内存回收对象的占比，高于第三内存回收比例中回收效率高的内存回收对象的占比。
在一些实施例中，线程识别模块302还用于：获取线程携带的标签；
若标签为第一预设标签，则判定线程为第一类线程；
若标签为第二预设标签，则判定线程为第二类线程；
若标签为第三预设标签，则判定线程为第三类线程。
在一些实施例中，该内存回收装置300还包括线程标记模块，该线程标记模块用于：确定出执行用户交互事件中相关任务的目标线程；为所述目标线程添加所述预设标签，以将所述目标线程标记为第一类线程。
在一些实施例中，线程标记模块还用于：在检测到有进程切换到前台运行时，确定前台进程；从所述前台进程的线程中识别出用于执行用户交互事件中相关任务的第一预设线程，作为目标线程。
在一些实施例中，线程标记模块还用于：对第一类线程的运行状态进行检测；当检测到有第一类线程进入阻塞状态，则确定与进入阻塞状态的第一类线程之间有约束关系的关联线程；为关联线程添加预设标签，以将关联线程标记为第一类线程。
在一些实施例中，线程标记模块还用于：当检测到有线程切换至前台运行时，判断切换至前台运行的线程是否为第一类线程；
若否，则为线程添加第二预设标签，以将线程标记为第二类线程；
当检测到有线程切换至后台运行时，判断切换至后台运行的线程是否为第一类线程；
若否，则为线程添加第三预设标签，以将线程标记为第三类线程。
应当说明的是，本申请实施例提供的内存回收装置与上文实施例中的内存回收方法属于同一构思，通过该内存回收装置可以实现内存回收方法实施例中提供的任一方法，其具体实现过程详见内存回收方法实施例，此处不再赘述。
由上可知，本申请实施例提出的内存回收装置，在接收到线程发送的内存分配请求时，先确定当前的空闲内存量，如果空闲内存量小于预设阈值，则要先进行内存回收，接下来对线程的类型进行识别，在内存回收时，根据请求内存的线程的类型的不同，采用不同的内存回收比例进行内存回收，该内存回收比例用于表征多种内存回收对象之间的比例，由于不同种类的内存回收对象的回收效率不同，因此若内存回收比例不同，则整体的回收效率也不相同。其中，第一类线程为执行用户交互事件中相关任务的线程，具有最高优先级，也就是说，第一类线程对应的内存回收比例中回收效率高的内存回收对象的占比在所有类别的线程中为最大占比，因此，对于第一类线程来说，在全部线程中具有最高效率的内存回收机制，可以尽快完成内存回收，提高了第一类线程的内存分配效率，避免第一类线程因为不能及时得到内存而导致出现交互场景下的卡顿现象，提升用户体验。
本申请实施例还提供一种电子设备。所述电子设备可以是智能手机、平板电脑等设备。请参阅图4，图4为本申请实施例提供的电子设备的第一种结构示意图。电子设备400包括处理器401和存储器402。其中，处理器401与存储器402电性连接。
处理器401是电子设备400的控制中心，利用各种接口和线路连接整个电子设备的各个部分，通过运行或调用存储在存储器402内的计算机程序，以及调用存储在存储器402内的数据，执行电子设备的各种功能和处理数据，从而对电子设备进行整体监控。
存储器402可用于存储计算机程序和数据。存储器402存储的计算机程序中包含有可在处理器中执行的指令。计算机程序可以组成各种功能模块。处理器401通过调用存储在存储器402的计算机程序，从而执行各种功能应用以及数据处理。
在本实施例中，电子设备400中的处理器401会按照如下的步骤，将一个或一个以上的计算机程序的进程对应的指令加载到存储器402中，并由处理器401来运行存储在存储器402中的计算机程序，从而实现各种功能：
当接收到线程发送的内存分配请求时，确定当前的空闲内存量；
若所述空闲内存量小于预设阈值，则确定所述线程的类型，其中，将线程划分为优先级不同的多类线程，其中，第一类线程具有最高优先级，所述第一类线程为执行用户交互事件中相关任务的线程；
获取与所述线程的类型对应的内存回收比例，并按照所述内存回收比例对已分配内存空间中的内存页进行回收，其中，所述内存回收比例用于表征多种内存回收对象之间的比例，不同种类的内存回收对象的回收效率不同，线程的优先级越高，则对应的内存回收比例中回收效率高的内存回收对象的占比越大。
在一些实施例中，请参阅图5，图5为本申请实施例提供的电子设备的第二种结构示意图。电子设备400还包括：射频电路403、显示屏404、控制电路405、输入单元406、音频电路407、传感器408以及电源409。其中，处理器401分别与射频电路403、显示屏404、控制电路405、输入单元406、音频电路407、传感器408以及电源409电性连接。
射频电路403用于收发射频信号，以通过无线通信与网络设备或其他电子设备进行通信。
显示屏404可用于显示由用户输入的信息或提供给用户的信息以及电子设备的各种图形用户接口，这些图形用户接口可以由图像、文本、图标、视频和其任意组合来构成。
控制电路405与显示屏404电性连接，用于控制显示屏404显示信息。
输入单元406可用于接收输入的数字、字符信息或用户特征信息(例如指纹)，以及产生与用户设置以及功能控制有关的键盘、鼠标、操作杆、光学或者轨迹球信号输入。其中，输入单元406可以包括指纹识别模组。
音频电路407可通过扬声器、传声器提供用户与电子设备之间的音频接口。其中，音频电路407包括麦克风。所述麦克风与所述处理器401电性连接。所述麦克风用于接收用户输入的语音信息。
传感器408用于采集外部环境信息。传感器408可以包括环境亮度传感器、加速度传感器、陀螺仪等传感器中的一种或多种。
电源409用于给电子设备400的各个部件供电。在一些实施例中，电源409可以通过电源管理系统与处理器401逻辑相连，从而通过电源管理系统实现管理充电、放电、以及功耗管理等功能。
虽然图中未示出，电子设备400还可以包括摄像头、蓝牙模块等，在此不再赘述。
在本实施例中，电子设备400中的处理器401会按照如下的步骤，将一个或一个以上的计算机程序的进程对应的指令加载到存储器402中，并由处理器401来运行存储在存储器402中的计算机程序，从而实现各种功能：
当接收到线程发送的内存分配请求时，确定当前的空闲内存量；
若所述空闲内存量小于预设阈值，则确定所述线程的类型，其中，将线程划分为优先级不同的多类线程，其中，第一类线程具有最高优先级，所述第一类线程为执行用户交互事件中相关任务的线程；
获取与所述线程的类型对应的内存回收比例，并按照所述内存回收比例对已分配内存空间中的内存页进行回收，其中，所述内存回收比例用于表征多种内存回收对象之间的比例，不同种类的内存回收对象的回收效率不同，线程的优先级越高，则对应的内存回收比例中回收效率高的内存回收对象的占比越大。
由上可知，本申请实施例提供了一种电子设备，所述电子设备在接收到线程发送的内存分配请求时，先确定当前的空闲内存量，如果空闲内存量小于预设阈值，则要先进行内存回收，接下来对线程的类型进行识别，在内存回收时，根据请求内存的线程的类型的不同，采用不同的内存回收比例进行内存回收，该内存回收比例用于表征多种内存回收对象之间的比例，由于不同种类的内存回收对象的回收效率不同，因此若内存回收比例不同，则整体的回收效率也不相同。其中，第一类线程为执行用户交互事件中相关任务的线程，具有最高优先级，也就是说，第一类线程对应的内存回收比例中回收效率高的内存回收对象的占比在所有类别的线程中为最大占比，因此，对于第一类线程来说，在全部线程中具有最高效率的内存回收机制，可以尽快完成内存回收，提高了第一类线程的内存分配效率，避免第一类线程因为不能及时得到内存而导致出现交互场景下的卡顿现象，提升用户体验。
本申请实施例还提供一种存储介质，所述存储介质中存储有计算机程序，当所述计算机程序在计算机上运行时，所述计算机执行上述任一实施例所述的内存回收方法。
需要说明的是，本领域普通技术人员可以理解上述实施例的各种方法中的全部或部分步骤是可以通过计算机程序来指令相关的硬件来完成，所述计算机程序可以存储于计算机可读存储介质中，所述存储介质可以包括但不限于：只读存储器(ROM，Read OnlyMemory)、随机存取存储器(RAM，Random Access Memory)、磁盘或光盘等。
此外，本申请中的术语“第一”、“第二”和“第三”等是用于区别不同对象，而不是用于描述特定顺序。此外，术语“包括”和“具有”以及它们任何变形，意图在于覆盖不排他的包含。例如包含了一系列步骤或模块的过程、方法、系统、产品或设备没有限定于已列出的步骤或模块，而是某些实施例还包括没有列出的步骤或模块，或某些实施例还包括对于这些过程、方法、产品或设备固有的其它步骤或模块。
以上对本申请实施例所提供的内存回收方法、装置、存储介质及电子设备进行了详细介绍。本文中应用了具体个例对本申请的原理及实施方式进行了阐述，以上实施例的说明只是用于帮助理解本申请的方法及其核心思想；同时，对于本领域的技术人员，依据本申请的思想，在具体实施方式及应用范围上均会有改变之处，综上所述，本说明书内容不应理解为对本申请的限制。
Claims (11)
1.一种内存回收方法，其特征在于，包括：
当接收到线程发送的内存分配请求时，确定当前的空闲内存量；
若所述空闲内存量小于预设阈值，则确定所述线程的类型，其中，将线程划分为优先级不同的多类线程，其中，第一类线程具有最高优先级，所述第一类线程为执行用户交互事件中相关任务的线程；
获取与所述线程的类型对应的内存回收比例，并按照所述内存回收比例对已分配内存空间中的内存页进行回收，其中，所述内存回收比例用于表征多种内存回收对象之间的比例，不同种类的内存回收对象的回收效率不同，线程的优先级越高，则对应的内存回收比例中回收效率高的内存回收对象的占比越大。
2.如权利要求1所述的内存回收方法，其特征在于，所述获取与所述线程的类型对应的内存回收比例，并按照所述内存回收比例对已分配内存空间中的内存页进行回收，包括：
当所述线程为第一类线程时，按照第一内存回收比例对已分配内存空间中的内存页进行回收；
当所述线程为第二类线程时，按照第二内存回收比例对已分配内存空间中的内存页进行回收，其中，所述第一内存回收比例中回收效率高的内存回收对象的占比，高于所述第二内存回收比例中回收效率高的内存回收对象的占比。
3.如权利要求2所述的内存回收方法，其特征在于，将线程划分为优先级不同的三类线程；所述获取与所述线程的类型对应的内存回收比例，并按照所述内存回收比例对已分配内存空间中的内存页进行回收，还包括：
当所述线程为第三类线程时，按照第三内存回收比例对已分配内存空间中的内存页进行回收，其中，所述第二内存回收比例中回收效率高的内存回收对象的占比，高于所述第三内存回收比例中回收效率高的内存回收对象的占比。
4.如权利要求3所述的内存回收方法，其特征在于，所述确定所述线程的类型，包括：
获取所述线程携带的标签；
若所述标签为第一预设标签，则判定所述线程为第一类线程；
若所述标签为第二预设标签，则判定所述线程为第二类线程；
若所述标签为第三预设标签，则判定所述线程为第三类线程。
5.如权利要求1至4任一项所述的内存回收方法，其特征在于，所述方法还包括：
确定出执行用户交互事件中相关任务的目标线程；
为所述目标线程添加所述预设标签，以将所述目标线程标记为第一类线程。
6.如权利要求5所述的内存回收方法，其特征在于，所述确定出执行用户交互事件中相关任务的目标线程，包括：
在检测到有进程切换到前台运行时，确定前台进程；
从所述前台进程的线程中识别出用于执行用户交互事件中相关任务的第一预设线程，作为目标线程。
7.如权利要求5所述的内存回收方法，其特征在于，所述方法还包括：
对所述第一类线程的运行状态进行检测；
当检测到有第一类线程进入阻塞状态，则确定与进入阻塞状态的第一类线程之间有约束关系的关联线程；
为所述关联线程添加预设标签，以将所述关联线程标记为所述第一类线程。
8.如权利要求5所述的内存回收方法，其特征在于，所述方法还包括：
当检测到有线程切换至前台运行时，判断切换至前台运行的线程是否为第一类线程；
若否，则为所述线程添加第二预设标签，以将所述线程标记为第二类线程；
当检测到有线程切换至后台运行时，判断切换至后台运行的线程是否为第一类线程；
若否，则为所述线程添加第三预设标签，以将所述线程标记为第三类线程。
9.一种内存回收装置，其特征在于，包括：
内存检测模块，用于当接收到线程发送的内存分配请求时，确定当前的空闲内存量；
线程识别模块，用于若所述空闲内存量小于预设阈值，则确定所述线程的类型，其中，将线程划分为优先级不同的多类线程，其中，第一类线程具有最高优先级，所述第一类线程为执行用户交互事件中相关任务的线程；
内存回收模块，用于获取与所述线程的类型对应的内存回收比例，并按照所述内存回收比例对已分配内存空间中的内存页进行回收，其中，所述内存回收比例用于表征多种内存回收对象之间的比例，不同种类的内存回收对象的回收效率不同，线程的优先级越高，则对应的内存回收比例中回收效率高的内存回收对象的占比越大。
10.一种存储介质，其上存储有计算机程序，其特征在于，当所述计算机程序在计算机上运行时，使得所述计算机执行如权利要求1至8任一项所述的内存回收方法。
11.一种电子设备，包括处理器和存储器，所述存储器存储有计算机程序，其特征在于，所述处理器通过调用所述计算机程序，用于执行如权利要求1至8任一项所述的内存回收方法。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202010628802.2A CN111831440A (zh) | 2020-07-01 | 2020-07-01 | 内存回收方法、装置、存储介质及电子设备 |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202010628802.2A CN111831440A (zh) | 2020-07-01 | 2020-07-01 | 内存回收方法、装置、存储介质及电子设备 |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CN111831440A true CN111831440A (zh) | 2020-10-27 |
Family
ID=72900398
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202010628802.2A Pending CN111831440A (zh) | 2020-07-01 | 2020-07-01 | 内存回收方法、装置、存储介质及电子设备 |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN111831440A (zh) |
Cited By (7)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN113778662A (zh) * | 2021-07-28 | 2021-12-10 | 荣耀终端有限公司 | 内存回收方法及装置 |
| CN114020461A (zh) * | 2021-11-03 | 2022-02-08 | 无锡沐创集成电路设计有限公司 | 内存分配方法、系统、存储介质及电子设备 |
| CN114253872A (zh) * | 2022-02-28 | 2022-03-29 | 荣耀终端有限公司 | 电子设备及其内存回收方法、介质 |
| CN116185890A (zh) * | 2023-04-23 | 2023-05-30 | 荣耀终端有限公司 | 内存回收方法及电子设备 |
| CN116225976A (zh) * | 2023-05-05 | 2023-06-06 | 麒麟软件有限公司 | 一种Linux操作系统下的水位线自调整方法及系统 |
| CN117130767A (zh) * | 2023-02-08 | 2023-11-28 | 荣耀终端有限公司 | 回收内存的方法、电子设备及存储介质 |
| WO2023231900A1 (zh) * | 2022-05-28 | 2023-12-07 | 华为技术有限公司 | 一种内存管理方法及相关装置 |
Citations (9)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US5428789A (en) * | 1993-08-27 | 1995-06-27 | Waldron, Iii; Theodore C. | Method and apparatus for optimizing user response time in a priority preemptive operating system |
| US5515538A (en) * | 1992-05-29 | 1996-05-07 | Sun Microsystems, Inc. | Apparatus and method for interrupt handling in a multi-threaded operating system kernel |
| CN109213596A (zh) * | 2018-08-01 | 2019-01-15 | 青岛海信移动通信技术股份有限公司 | 一种分配终端内存的方法和设备 |
| CN109783028A (zh) * | 2019-01-16 | 2019-05-21 | Oppo广东移动通信有限公司 | I/o调度的优化方法、装置、存储介质及智能终端 |
| CN109992400A (zh) * | 2017-12-29 | 2019-07-09 | 广东欧珀移动通信有限公司 | 资源分配方法、装置、移动终端及计算机可读存储介质 |
| WO2019137258A1 (zh) * | 2018-01-10 | 2019-07-18 | Oppo广东移动通信有限公司 | 内存处理方法、电子设备及计算机可读存储介质 |
| CN110727607A (zh) * | 2019-09-27 | 2020-01-24 | Oppo（重庆）智能科技有限公司 | 内存回收方法、装置以及电子设备 |
| CN111078408A (zh) * | 2019-12-10 | 2020-04-28 | Oppo（重庆）智能科技有限公司 | 内存分配方法、装置、存储介质及电子设备 |
| CN111158910A (zh) * | 2019-12-27 | 2020-05-15 | Oppo广东移动通信有限公司 | 内存管理方法、装置、存储介质及电子设备 |
-
2020
- 2020-07-01 CN CN202010628802.2A patent/CN111831440A/zh active Pending
Patent Citations (9)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US5515538A (en) * | 1992-05-29 | 1996-05-07 | Sun Microsystems, Inc. | Apparatus and method for interrupt handling in a multi-threaded operating system kernel |
| US5428789A (en) * | 1993-08-27 | 1995-06-27 | Waldron, Iii; Theodore C. | Method and apparatus for optimizing user response time in a priority preemptive operating system |
| CN109992400A (zh) * | 2017-12-29 | 2019-07-09 | 广东欧珀移动通信有限公司 | 资源分配方法、装置、移动终端及计算机可读存储介质 |
| WO2019137258A1 (zh) * | 2018-01-10 | 2019-07-18 | Oppo广东移动通信有限公司 | 内存处理方法、电子设备及计算机可读存储介质 |
| CN109213596A (zh) * | 2018-08-01 | 2019-01-15 | 青岛海信移动通信技术股份有限公司 | 一种分配终端内存的方法和设备 |
| CN109783028A (zh) * | 2019-01-16 | 2019-05-21 | Oppo广东移动通信有限公司 | I/o调度的优化方法、装置、存储介质及智能终端 |
| CN110727607A (zh) * | 2019-09-27 | 2020-01-24 | Oppo（重庆）智能科技有限公司 | 内存回收方法、装置以及电子设备 |
| CN111078408A (zh) * | 2019-12-10 | 2020-04-28 | Oppo（重庆）智能科技有限公司 | 内存分配方法、装置、存储介质及电子设备 |
| CN111158910A (zh) * | 2019-12-27 | 2020-05-15 | Oppo广东移动通信有限公司 | 内存管理方法、装置、存储介质及电子设备 |
Cited By (11)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN113778662A (zh) * | 2021-07-28 | 2021-12-10 | 荣耀终端有限公司 | 内存回收方法及装置 |
| CN113778662B (zh) * | 2021-07-28 | 2022-12-06 | 荣耀终端有限公司 | 内存回收方法及装置 |
| CN114020461A (zh) * | 2021-11-03 | 2022-02-08 | 无锡沐创集成电路设计有限公司 | 内存分配方法、系统、存储介质及电子设备 |
| CN114253872A (zh) * | 2022-02-28 | 2022-03-29 | 荣耀终端有限公司 | 电子设备及其内存回收方法、介质 |
| CN114253872B (zh) * | 2022-02-28 | 2022-07-12 | 荣耀终端有限公司 | 电子设备及其内存回收方法、介质 |
| WO2023231900A1 (zh) * | 2022-05-28 | 2023-12-07 | 华为技术有限公司 | 一种内存管理方法及相关装置 |
| CN117130767A (zh) * | 2023-02-08 | 2023-11-28 | 荣耀终端有限公司 | 回收内存的方法、电子设备及存储介质 |
| CN116185890A (zh) * | 2023-04-23 | 2023-05-30 | 荣耀终端有限公司 | 内存回收方法及电子设备 |
| CN116185890B (zh) * | 2023-04-23 | 2023-09-19 | 荣耀终端有限公司 | 内存回收方法及电子设备 |
| CN116225976A (zh) * | 2023-05-05 | 2023-06-06 | 麒麟软件有限公司 | 一种Linux操作系统下的水位线自调整方法及系统 |
| CN116225976B (zh) * | 2023-05-05 | 2023-08-08 | 麒麟软件有限公司 | 一种Linux操作系统下的水位线自调整方法及系统 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN111831441A (zh) | 内存回收方法、装置、存储介质及电子设备 | |
| CN111831440A (zh) | 内存回收方法、装置、存储介质及电子设备 | |
| CN109960582B (zh) | 在tee侧实现多核并行的方法、装置及系统 | |
| CN111831433A (zh) | 资源分配方法、装置、存储介质及电子设备 | |
| CN111831434A (zh) | 资源分配方法、装置、存储介质及电子设备 | |
| CN111831435A (zh) | 内存分配方法、装置、存储介质及电子设备 | |
| CN111831414A (zh) | 线程迁移方法、装置、存储介质及电子设备 | |
| US8490118B2 (en) | Wait on address synchronization interface | |
| CN111831438A (zh) | 资源分配方法、装置、存储介质及电子设备 | |
| CN111813521A (zh) | 线程调度方法、装置、存储介质及电子设备 | |
| CN111813520A (zh) | 线程调度方法、装置、存储介质及电子设备 | |
| CN110990132B (zh) | 异步任务处理方法、装置、计算机设备和存储介质 | |
| CN111831410A (zh) | 任务处理方法、装置、存储介质及电子设备 | |
| CN113495780A (zh) | 任务调度方法、装置、存储介质及电子设备 | |
| CN111954072B (zh) | 一种多媒体播放方法、装置、多媒体播放器和介质 | |
| CN111831432B (zh) | Io请求的调度方法、装置、存储介质及电子设备 | |
| CN107977275B (zh) | 基于消息队列的任务处理方法及相关设备 | |
| CN111475299A (zh) | 内存分配方法、装置、存储介质及电子设备 | |
| CN111831462A (zh) | Io请求的处理方法、装置、存储介质及电子设备 | |
| CN111831439A (zh) | Io请求的处理方法、装置、存储介质及电子设备 | |
| CN111831436A (zh) | Io请求的调度方法、装置、存储介质及电子设备 | |
| CN111831437A (zh) | 设备管理方法、装置、存储介质及电子设备 | |
| CN111831411A (zh) | 任务处理方法、装置、存储介质及电子设备 | |
| CN115509953A (zh) | 内存回收方法及其装置 | |
| CN111831413A (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 |