一种垃圾回收GC的管控方法及终端与流程

一种垃圾回收gc的管控方法及终端
技术领域
1.本技术涉及电子技术领域，尤其涉及一种垃圾回收gc的管控方法及终端。


背景技术：

2.终端上可安装使用例如java语言编写的各种各样的应用程序(application，app)。因为java语言的跨平台性以及开放性，为了在多种平台上实现兼容，终端在运行使用java语言编写的app时，需要创建java虚拟机(virtual machine，jvm)，jvm中存在有java的垃圾回收(garbage collection，gc)功能。当app使用的堆内存不足时，jvm将启动gc进行回收内存，使被占用的内存能够恢复空闲状态，供app后续使用。需要说明的是，终端启动gc时会占用大量的cpu资源。
3.那么，在终端启动gc时，如果终端还同时执行例如界面切换或启动新的app等也需要占用较大量的cpu资源的任务时，会造成界面切换慢，app启动时间过长，画面不流畅等问题，用户体验差。


技术实现要素：

4.本技术提供的一种垃圾回收gc的管控方法及终端，可以通过暂停部分进程执行gc来降低终端整体的系统负载，保证终端优先执行与用户体验相关的任务，提升用户的使用体验。
5.为了实现上述目的，本技术实施例提供了以下技术方案：
6.第一方面、提供一种垃圾回收gc的管控方法，包括：终端运行一个或多个app；当监测到终端处于预设场景时，终端暂停目标进程执行垃圾回收gc；其中，目标进程为一个或多个app启动的进程，目标进程的数量为一个或多个；预设场景包括app的启动场景、app界面的切换场景、横竖屏的切换场景、生物特征识别场景、终端的系统负载满足第一预设条件中的任一项。
7.可以理解的是，用户可以直接感受app的启动时长(从用户执行启动app的操作后到终端完整显示app的首页的总时长，也称为app的首页时间)，界面切换的时长，界面横竖屏切换时长，生物特征识别的时长等，因此提升这些任务的运行速度对于提升用户体验至关重要。另外，终端在执行这些与用户体验相关任务时所占用的系统资源(如cpu资源、内存资源)也较高，即这些与用户体验相关任务为高负载任务，预设场景也称之为高负载场景。
8.由此可见，当终端执行与用户体验相关的任务或者终端的系统负载过重，即处于预设场景时，通过暂停部分进程执行gc来降低终端整体的系统负载，保证终端优先执行与用户体验相关的任务，提升用户的使用体验。
9.一种可能的实现方式中，在终端暂停目标进程执行垃圾回收gc之前，该方法还包括：终端根据预设场景的时间信息确定暂停gc的时间段。
10.由此提供了一种暂停目标进程执行gc的具体方案，通过确定明确的暂停gc的时间段，有利于保证预设场景的顺利运行，也有利于保证后续目标进程恢复执行gc，回收无用的
堆内存。
11.一种可能的实现方式中，终端根据预设场景的时间信息确定暂停gc的时间段，包括：当预设场景为app的启动场景、或app界面的切换场景、或横竖屏的切换场景中任一项时，终端根据终端创建新的活动activity组件的时间确定开始暂停gc的时间；当预设场景为生物特征识别场景时，终端根据终端调用生物特征识别服务的时间确定开始暂停gc的时间；当预设场景为终端的系统负载达到第一预设条件时，终端根据监测到终端的系统负载达到第一预设条件的监测时间确定开始暂停gc的时间。由此，提供了在不同预设场景下，如何确定开始暂停gc的时间。
12.在另一些示例中，在确定开始暂停gc的时间tstart后，还可以先预估一个结束暂停gc的时间tend。例如，可以预先统计出各个预设场景的持续时长，根据各个预设场景的统计时长确定gc的暂停时长δt，从而确定出结束暂停gc的时间tend。即tend＝tstart+δt。也就是说，不同的预设场景对应的暂停时长δt不同。比如，app的启动场景对应的暂停时长δt》生物特征识别场景对应的暂停时长δt》app间的界面切换场景对应的δt》app内部的界面切换场景对应的δt。又比如，不同类型的app的启动时长不同，那么不同类型的app的启动时长对应的暂停时长δt不同。当然，在其他一些示例中，暂停时长δt为默认值。例如，统计出各个预设场景的持续时长，将持续时长的最大值设置为暂停时长δt的默认值。类似的，后续可以根据预设场景的实际进度实时调整结束时间tend。
13.可以理解的是，终端还可以根据预设场景的实际进度实时调整结束时间tend，这样使得终端暂停gc的时间更加精确，既保证了预设场景的顺利进行，又保证终端及时进行gc，回收无用的堆内存。
14.一种可能的实现方式中，在终端暂停目标进程执行垃圾回收gc之前，该方法还包括：终端从一个或多个app启动的进程中，确定当前堆内存尺寸小于m
max
*t％的进程为目标进程，其中，m
max
为进程的堆内存尺寸的最大值，t％为进程的堆内存目标占用比；或者，终端确定一个或多个app启动的全部进程为目标进程。
15.可以理解的是，当该进程的当前堆内存尺寸小于m
max
*t％时，可认为该进程的堆内存还有足够的空间可供分配，此时暂停该进程的gc不会造成堆内存溢出的问题。反之，如果某进程的当前堆内存尺寸大于或等于m
max
*t％时，则此时不能暂停该进程的gc，否则可能会造成堆内存溢出的问题。
16.一种可能的实现方式中，一个或多个app中不同的进程对应的mmax和/或t％不同。由此可见，本技术提供的方法是一种以进程为单位，对各个进程执行gc进行管控的方法，管控粒度更小，管控更加精细化。
17.一种可能的实现方式中，在终端暂停目标进程执行垃圾回收gc之后，该方法还包括：终端监测每个目标进程的当前堆内存尺寸；当监测到目标进程中第一进程的当前堆内存尺寸满足第二预设条件时，恢复第一进程执行gc。
18.换言之，本技术针对已暂停执行gc的目标进程进行持续监测，当监测到某个目标进程(如第一进程)的当前堆内存尺寸紧张(即满足第二预设条件)时，恢复该第一进程的gc，以防止出现堆内存溢出的问题。
19.一种可能的实现方式中，第一预设条件包括终端的cpu的占用率大于或等于第一阈值，或者，终端的内存的占用率大于或等于第二阈值。由此提供了一种确定终端系统负载
过重的方法。
20.一种可能的实现方式中，第二预设条件包括：第一进程的当前堆内存尺寸等于或大于mmax*t％，其中，mmax为进程的堆内存尺寸的最大值，t％为进程的堆内存目标占用比。由此提供了一种确定第一进程的当前堆内存尺寸紧张的方法。
21.第二方面、提供一种终端，包括：处理器和存储器，存储器与处理器耦合，存储器用于存储计算机程序代码，计算机程序代码包括计算机指令，当处理器从存储器中读取计算机指令，以使得终端执行如上述方面及其中任一种可能的实现方式中所述的方法。
22.第三方面、提供一种装置，该装置包含在终端中，该装置具有实现上述方面及可能的实现方式中任一方法中终端行为的功能。该功能可以通过硬件实现，也可以通过硬件执行相应的软件实现。硬件或软件包括至少一个与上述功能相对应的模块或单元。例如，app运行模块或单元，场景监测模块或单元，以及暂停gc模块或单元等。
23.第四方面、提供一种计算机可读存储介质，包括计算机指令，该计算机可读存储介质包含在终端中，当计算机指令在终端上运行时，使得终端执行如上述方面及其中任一种可能的实现方式中所述的方法。
24.第五方面、提供一种计算机程序产品，当计算机程序产品在计算机上运行时，使得计算机执行如上述方面中及其中任一种可能的实现方式中所述的方法。
25.第六方面、提供一种芯片系统，包括处理器，当处理器执行指令时，处理器执行如上述方面中及其中任一种可能的实现方式中所述的方法。
26.需要说明的是，上述第二方面提供的终端、第三方面提供的装置、第四方面提供的计算机可读存储介质、第五方面提供的计算机程序产品、以及第六方面提供的芯片系统所能达到的技术效果，可参考上述第一方面以及第一方面中任一种可能的实现方式中所述方法中关于技术效果的描述，这里不再赘述。
附图说明
27.图1为本技术实施例提供的一种终端的结构示意图；
28.图2为本技术实施例提供的另一种终端的结构示意图；
29.图3为本技术实施例提供的一种gc管控方法的流程示意图；
30.图4为本技术实施例提供的一种芯片系统的结构示意图。
具体实施方式
31.在本技术实施例中，“示例性的”或者“例如”等词用于表示作例子、例证或说明。本技术实施例中被描述为“示例性的”或者“例如”的任何实施例或设计方案不应被解释为比其它实施例或设计方案更优选或更具优势。确切而言，使用“示例性的”或者“例如”等词旨在以具体方式呈现相关概念。
32.示例性的，本技术实施例中终端例如可以为手机、平板电脑、个人计算机(personal computer，pc)、个人数字助理(personal digital assistant，pda)、智能手表、上网本、可穿戴终端、增强现实技术(augmented reality，ar)设备、虚拟现实(virtual reality，vr)设备、车载设备、智慧屏、智能音响等，本技术对该终端的具体形式不做特殊限制。
33.图1示出了终端100的结构示意图。
34.终端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等。
35.可以理解的是，本发明实施例示意的结构并不构成对终端100的具体限定。在本技术另一些实施例中，终端100可以包括比图示更多或更少的部件，或者组合某些部件，或者拆分某些部件，或者不同的部件布置。图示的部件可以以硬件，软件或软件和硬件的组合实现。
36.处理器110可以包括一个或多个处理单元，例如：处理器110可以包括应用处理器(application processor，ap)，调制解调处理器，图形处理器(graphics processing unit，gpu)，图像信号处理器(image signal processor，isp)，控制器，视频编解码器，数字信号处理器(digital signal processor，dsp)，基带处理器，和/或神经网络处理器(neural-network processing unit，npu)等。其中，不同的处理单元可以是独立的器件，也可以集成在一个或多个处理器中。
37.控制器可以根据指令操作码和时序信号，产生操作控制信号，完成取指令和执行指令的控制。
38.处理器110中还可以设置存储器，用于存储指令和数据。在一些实施例中，处理器110中的存储器为高速缓冲存储器。该存储器可以保存处理器110刚用过或循环使用的指令或数据。如果处理器110需要再次使用该指令或数据，可从所述存储器中直接调用。避免了重复存取，减少了处理器110的等待时间，因而提高了系统的效率。
39.在一些实施例中，处理器110可以包括一个或多个接口。接口可以包括集成电路(inter-integrated circuit，i2c)接口，集成电路内置音频(inter-integrated circuit sound，i2s)接口，脉冲编码调制(pulse code modulation，pcm)接口，通用异步收发传输器(universal asynchronous receiver/transmitter，uart)接口，移动产业处理器接口(mobile industry processor interface，mipi)，通用输入输出(general-purpose input/output，gpio)接口，用户标识模块(subscriber identity module，sim)接口，和/或通用串行总线(universal serial bus，usb)接口等。
40.充电管理模块140用于从充电器接收充电输入。其中，充电器可以是无线充电器，也可以是有线充电器。
41.电源管理模块141用于连接电池142，充电管理模块140与处理器110。电源管理模块141接收电池142和/或充电管理模块140的输入，为处理器110，内部存储器121，显示屏194，摄像头193，和无线通信模块160等供电。
42.终端100的无线通信功能可以通过天线1，天线2，移动通信模块150，无线通信模块160，调制解调处理器以及基带处理器等实现。
43.天线1和天线2用于发射和接收电磁波信号。终端100中的每个天线可用于覆盖单个或多个通信频带。不同的天线还可以复用，以提高天线的利用率。例如：可以将天线1复用为无线局域网的分集天线。在另外一些实施例中，天线可以和调谐开关结合使用。移动通信模块150可以提供应用在终端100上的包括2g/3g/4g/5g等无线通信的解决方案。无线通信模块160可以提供应用在终端100上的包括无线局域网(wireless local area networks，wlan)(如无线保真(wireless fidelity，wi-fi)网络)，蓝牙(bluetooth，bt)，全球导航卫星系统(global navigation satellite system，gnss)，调频(frequency modulation，fm)，近距离无线通信技术(near field communication，nfc)，红外技术(infrared，ir)等无线通信的解决方案。
44.终端100通过gpu，显示屏194，以及应用处理器等实现显示功能。gpu为图像处理的微处理器，连接显示屏194和应用处理器。gpu用于执行数学和几何计算，用于图形渲染。处理器110可包括一个或多个gpu，其执行程序指令以生成或改变显示信息。
45.显示屏194用于显示图像，视频等。
46.终端100可以通过isp，摄像头193，视频编解码器，gpu，显示屏194以及应用处理器等实现拍摄功能。
47.外部存储器接口120可以用于连接外部存储卡，例如micro sd卡，实现扩展终端100的存储能力。外部存储卡通过外部存储器接口120与处理器110通信，实现数据存储功能。例如将音乐，视频等文件保存在外部存储卡中。
48.内部存储器121可以用于存储计算机可执行程序代码，所述可执行程序代码包括指令。内部存储器121可以包括存储程序区和存储数据区。其中，存储程序区可存储操作系统，至少一个功能所需的应用程序(比如声音播放功能，图像播放功能等)等。存储数据区可存储终端100使用过程中所创建的数据(比如音频数据，电话本等)等。此外，内部存储器121可以包括高速随机存取存储器，还可以包括非易失性存储器，例如至少一个磁盘存储器件，闪存器件，通用闪存存储器(universal flash storage，ufs)等。处理器110通过运行存储在内部存储器121的指令，和/或存储在设置于处理器中的存储器的指令，执行终端100的各种功能应用以及数据处理。
49.终端100可以通过音频模块170，扬声器170a，受话器170b，麦克风170c，耳机接口170d，以及应用处理器等实现音频功能。例如音乐播放，录音等。
50.终端100的软件系统可以采用分层架构，事件驱动架构，微核架构，微服务架构，或云架构。例如，终端100的软件系统为android系统或鸿蒙系统。本发明实施例以分层架构的android系统为例，示例性说明终端100的软件结构。
51.图2是本发明实施例的终端100的软件结构框图。
52.分层架构将软件分成若干个层，每一层都有清晰的角色和分工。层与层之间通过软件接口通信。在一些实施例中，将android系统分为四层，从上至下分别为应用程序层(简称应用层)，应用程序框架层(简称框架层)，安卓运行时(android runtime)和系统库，以及内核层。
53.1、应用层
54.应用层可以包括一系列应用程序包。如图2所示，应用程序包可以包括多个应用程序，例如app1、app2以及app3等。需要说明的是，这些应用程序可以是终端100预置的应用程
序，也可以是用户通过浏览器或应用市场等下载的应用程序。
55.2、框架层
56.框架层为应用层的应用程序提供应用编程接口(application programming interface，api)和编程框架。框架层包括一些预先定义的函数。
57.如图2所示，框架层可以包括活动管理服务(activity manager service，ams)以及生物特征识别服务等。
58.其中，ams，负责所有app进程的启动，app四大组件(如活动activity、服务service、广播接收者broadcast receiver、内容提供者content provider)的启动，app之间及app内部界面之间切换和各种组件的生命周期。具体来说，app通常以activity的形式运行在操作系统中，ams可以调度app的activity进程管理每个app的生命周期。也就是说，app启动或停止activity，都将通知ams，由ams确定是否执行相应动作。在本技术的一些实施例中，ams还可以将启动或停止activity的事件、activity的变化事件等发送给内核层的场景识别模块，以便场景识别模块识别终端100是否处于特定的高负载场景，例如界面切换场景、app的启动场景、横竖屏切换场景等。
59.生物特征识别服务(包括人脸识别服务、虹膜识别服务、指纹识别服务、掌纹识别服务、声纹识别服务等)，可为终端提供对终端100采集的图像进行生物特征识别功能，如人脸识别、虹膜识别、指纹识别、掌纹识别、声纹识别等功能。在本技术的一些实施例中，生物特征识别服务还可以向内核层的场景识别模块发送生物特征识别事件，以便场景识别模块识别终端100是否处于特定的高负载场景，该特定的高负载场景还包括生物特征识别场景。
60.进一步的，框架层还可以包括窗口管理器(window manager service，wms)、内容提供器(图中未示出)，视图系统(图中未示出)，电话管理器(图中未示出)，资源管理器(图中未示出)，通知管理器(图中未示出)等。
61.其中，窗口管理器用于管理窗口程序。窗口管理器可以获取显示屏大小，判断是否有状态栏，锁定屏幕，截取屏幕等。内容提供器用来存放和获取数据，并使这些数据可以被应用程序访问。所述数据可以包括视频，图像，音频，拨打和接听的电话，浏览历史和书签，电话簿等。视图系统包括可视控件，例如显示文字的控件，显示图片的控件等。视图系统可用于构建应用程序。显示界面可以由一个或多个视图组成的。例如，包括短信通知图标的显示界面，可以包括显示文字的视图以及显示图片的视图。电话管理器用于提供终端100的通信功能。例如通话状态的管理(包括接通，挂断等)。资源管理器为应用程序提供各种资源，比如本地化字符串，图标，图片，布局文件，视频文件等等。通知管理器使应用程序可以在状态栏中显示通知信息，可以用于传达告知类型的消息，可以短暂停留后自动消失，无需用户交互。比如通知管理器被用于告知下载完成，消息提醒等。通知管理器还可以是以图表或者滚动条文本形式出现在系统顶部状态栏的通知，例如后台运行的应用程序的通知，还可以是以对话窗口形式出现在屏幕上的通知。例如在状态栏提示文本信息，发出提示音，终端振动，指示灯闪烁等。
62.3、android runtime和系统库
63.如图2所示，android runtime包括核心库和虚拟机。android runtime负责安卓系统的调度和管理。
64.核心库包含两部分：一部分是java语言需要调用的功能函数，另一部分是安卓的
核心库。
65.应用层和框架层运行在虚拟机中。虚拟机将应用层和框架层的java文件执行为二进制文件。虚拟机用于执行对象生命周期的管理，堆栈管理，线程管理，安全和异常的管理，以及垃圾回收(例如gc)等功能。以终端100运行app1为例进行说明。当终端100运行app1时，通常会启动app1的多个进程(如app1的界面对应的进程1，app1的后台服务对应的进程2)，每个进程都将对应一个虚拟机，且每个进程中都包含一个gc线程。该gc线程负责监控本进程对应的虚拟机堆内存的使用情况，并根据本进程对应的虚拟机堆内存的使用情况确定是否启动gc过程。
66.在一些实施例中，gc线程可以通过参数concurrent_start_bytes来判断是否触发gc。当该进程对应的虚拟机当前堆内存的尺寸(即参数current_heap_size的数值)达到或超过concurrent_start_bytes时，就会触发gc。其中，concurrent_start_bytes是根据前一次gc触发后的当前堆内存的尺寸(即前一次gc触发后current_heap_size的数值，记为current_heap_size’的数值)来计算生成，计算方法如下：
67.target＝current_heap_size’/heaptargetutilization-current_heap_size’；
68.target＝min(target,heapmaxfree)；
69.target＝max(target,heapminfree)；
70.concurrent_start_bytes＝current_heap_size’+target。
71.其中，heaptargetutilization，为堆目标利用率。heapmaxfree，为堆最大空闲值；heapminfree，为堆最小空闲值。
72.可以理解的是，当每次gc之后已经使用的堆内存和空闲的堆内存有一个合适的比例(即堆目标利用率，通常为0.75)，可以尽量地减少gc的次数。假设在某一次gc之后，存活对象占用的堆内存的尺寸为current_heap_size’。那么这时候堆的理想大小应该为(current_heap_size’/heaptargetutilization)。但是(current_heap_size’/heaptargetutilization)必须大于或等于(current_heap_size’+heapminfree)并且小于或等于(current_heap_size’+heapmaxfree)。否则，就要进行调整。即，当current_heap_size大于或等于concurrent_start_bytes时，触发gc。其中，concurrent_start_bytes＝current_heap_size’+target。target，可认为是每次启动gc后，concurrent_start_bytes相对于本次启动gc后增加的堆内存尺寸。
73.在另一些实施例中，当某个进程无法分配堆内存时，该进程立即执行gc，以便回收被占用的堆内存。如此，便有空闲的堆内存能够分配给新的对象使用。
74.需要说明的是，启动gc时，会扫描该进程对应的虚拟机堆内存中所有存活对象，会占用大量cpu资源。然而在实际的场景中，终端100的同一个app(例如app1)可能同时触发多个进程启动gc，或者终端100的不同app(如app1、app2)可能同时触发多个进程启动gc，从而加重了cpu的负载。
75.可以理解的是，当终端100处于高负载场景(如运行高负载的任务，例如启动app，app界面切换，生物特征识别服务等)时，若终端100多个进程同时启动了gc，或者某个或某些进程多次启动了gc，那么势必对该高负载场景造成影响，例如造成界面切换缓慢、画面不流畅、app的启动时间长等，从而影响用户体验。为此，在本技术实施例中，当识别出终端处于高负载场景时，暂停全部或部分应用进程的gc，以保证高负载场景的顺利和高效运行。
76.系统库可以包括多个功能模块。例如：表面管理器(surface manager)，媒体库(media libraries)，三维图形处理库(例如：opengl es)，2d图形引擎(例如：sgl)等。
77.表面管理器用于对显示子系统进行管理，并且为多个应用程序提供了2d和3d图层的融合。媒体库支持多种常用的音频，视频格式回放和录制，以及静态图像文件等。媒体库可以支持多种音视频编码格式，例如:mpeg4，h.264，mp3，aac，amr，jpg，png等。三维图形处理库用于实现三维图形绘图，图像渲染，合成，和图层处理等。2d图形引擎是2d绘图的绘图引擎。
78.4.内核层
79.内核层是硬件和软件之间的层。如图2所示，内核层包括场景识别模块、负载监控模块以及gc管控模块。
80.其中，场景识别模块可以通过框架层的ams获知终端100启动新的app或者执行界面切换等任务，即识别出终端100是否处于高负载场景，如app的启动场景和界面切换场景等。可选的，场景识别模块还可以通过框架层的生物特征识别服务等识别终端处于生物特征识别场景，高负载场景还包括生物特征识别场景，如人脸识别服务、虹膜识别服务、指纹识别服务、掌纹识别服务、声纹识别服务等。
81.其中，负载监控模块用于监控终端100的cpu以及内存的负载情况。当终端100的cpu和内存负载过重时，确定终端处于高负载场景，并告知gc控制模块。负载监控模块，还用于将场景识别模块发送的场景信息发送给gc控制模块。
82.其中，gc控制模块根据接收到的终端100的cpu内存等负载情况和/或高负载场景，确定是否暂停gc，暂停哪些进程的gc，以及各个进程暂停gc的时长等。
83.需要说明的是，在其他一些实施例中，场景识别模块也可以位于框架层。或者，场景识别模块与负载监控模块集成为一个功能模块。又或者，负载监控模块与gc控制模块集成为一个功能模块。又或者，场景识别模块、负载监控模块与gc控制模块可以集成为一个功能模块。又或者，场景识别模块、负载监控模块与gc控制模块中任一个或任几个与内核层中的其他功能模块集成在一起。总而言之，本技术实施例对此均不做限定。
84.可选的，内核层还可以包含显示驱动，摄像头驱动，音频驱动，传感器驱动等(图中均未示出)。
85.以下实施例中所涉及的技术方案均可以在具有上述硬件架构和软件架构的终端100中实现。下面结合附图对本技术实施例提供的技术方案进行详细说明。
86.如图3所示，为本技术实施例提供的一种gc的管控方法的流程示意图，该管控方法包括：
87.s301、终端运行一个或多个app。
88.当终端运行某个app时，该app可以启动多个进程，可以包括前台进程和后台进程。其中，前台进程可以用于呈现app的用户界面，可以和用户进行交互。后台进程不需要和用户交互。当然，一个app也可能仅启动一个进程，或者在某些场景下该app仅启动一个进程，在其他场景下启动多个进程。
89.例如，终端运行购物类app时，购物类app至少启动一个前台进程，用于呈现用户界面。购物类app还可以启动推送服务的后台进程，用于接收服务器向终端推送的信息，如聊天信息，广告信息等。
90.又例如，终端运行地图类app时，地图类app至少启动一个前台进行用于呈现地图。地图类app还可以启动定位服务的后台进程，用于对终端的位置进行实时定位，以便实时更新地图中用户的定位。地图类app还可以启动推送服务的后台进程，用于接收服务器向终端推送的信息，如天气信息、附近的美食、附近的停车场信息等。
91.在另一些实施例中，终端支持分屏显示或者支持显示悬浮窗/悬浮球/悬浮框等，终端可以同时启动两个或两个以上的app，并且终端可以同时显示该两个或两个以上app的用户界面。那么，每一个app都启动一个或多个前台进程，用于呈现各个app的用户界面。每一个app还都启动一个或多个后台进程，用于实现各个app的相关功能。
92.在又一些实施例中，终端支持同时启动多个app，但每次仅有一个app在前台运行，其他app切换至后台运行。可以理解的，在前台运行的app启动有一个或多个前台进程，用于呈现该app的用户界面，还启动有多个后台进程，分别用于实现该app的其他功能。在后台运行的app启动有多个后台进程，实现其相关功能。
93.由上可知，终端上通常启动有多个进程，可以是一个app的多个进程，也可以是多个app的多个进程。前文已说明，每个进程中均包含一个gc线程，用于监控各个进程对应的虚拟机的堆内存。当某个虚拟机的当前堆内存尺寸current_heap_size大于或等于阈值concurrent_start_bytes时，相应的进程触发gc。其中，阈值concurrent_start_bytes可以为根据上一次gc后的当前堆内存尺寸current_heap_size’和阈值target确定。其中，阈值target为根据堆目标利用率dalvik.vm.heaptargetutilization、堆最大空闲值heapmaxfree以及堆最小空闲值heapminfree计算得到。具体的计算方法请参考前文描述，这里不再赘述。
94.s302、在终端运行一个或多个app时，监测终端是否处于预设场景。
95.在一些实施例中，预设场景是指终端执行与用户体验相关的任务，例如app的启动场景、app界面的切换场景、横竖屏的切换场景、生物特征识别场景等。可以理解的是，用户可以直接感受app的启动时长(从用户执行启动app的操作后到终端完整显示app的首页的总时长，也称为app的首页时间)，界面切换的时长，界面横竖屏切换时长，生物特征识别的时长等，因此提升这些任务的运行速度对于提升用户体验至关重要。另外，终端在执行这些与用户体验相关任务时所占用的系统资源(如cpu资源、内存资源)也较高，即这些与用户体验相关任务为高负载任务，预设场景也称之为高负载场景。
96.可以理解的是，当终端执行与用户体验相关的任务时，如果终端后台运行的app同时执行gc，可能会造成终端负载过重，进而造成与用户体验相关的任务出现运行速率低的问题，更直观地带来app的启动时长过长，界面切换慢、画面不流程等问题。因此，针对终端执行与用户体验相关的任务时，需要对终端后台运行的app执行gc的情况进行管控，即执行下述步骤s303及之后的步骤。
97.在一个具体的实现方式中，本步骤可具体由图2所示的场景识别模块执行。当场景识别模块监测到终端处于预设场景后，将该预设场景的场景信息发送给负载监测模块。
98.例如：终端运行app1，且app1的界面对应activity1。若终端接收到用户启动app2的操作后，app2通过框架层的ams创建一个新的activity(如activity2)，用于呈现app2的用户界面。同时，终端关闭app1的界面对应的activity1。而后，ams将activity2的启动事件和activity1的关闭事件(其中activity1的关闭事件为可选的)传递到内核层的场景识别
模块，场景识别模块根据activity2的启动事件和activity1的关闭事件(activity1的关闭事件为可选的)确定终端处于app的启动场景。
99.又例如：终端运行app1，终端显示界面1，且界面1对应activity3。若终端接收到用户切换app1界面的操作(例如点击某个控件等)，或者终端根据app1的业务逻辑自动切换app1界面时，app1通过框架层的ams创建一个新的activity(如activity4)，用于呈现切换后的界面2。同时，终端关闭界面1对应的activity3。而后，ams将activity4的启动事件和activity3的关闭事件(其中activity3的关闭事件为可选的)传递到内核层的场景识别模块，场景识别模块根据activity4的启动事件和activity3的关闭事件(其中activity3的关闭事件为可选的)确定终端处于app的内部界面的切换场景。
100.又例如：终端同时运行app1和app2，当前终端显示app1的界面，且app1的界面对应activity1。当终端接收到用户将app1的界面切换至app2的界面的操作(例如将app2切换至前台运行)时，app2通过框架层的ams创建一个新的activity(如activity2)，用于呈现app2的用户界面。同时，终端关闭app1的界面对应的activity1。而后，ams将activity2的启动事件和activity1的关闭事件(其中activity1的关闭事件为可选的)传递到内核层的场景识别模块，场景识别模块根据activity2的启动事件和activity1的关闭事件(其中activity1的关闭事件为可选的)确定终端处于app间的界面切换场景。
101.又例如：终端运行app1，终端显示界面1(例如为竖屏状态)，且界面1对应activity5。当终端接收到用户执行横竖屏切换的操作时，app1将通过框架层的ams创建一个新的activity(如activity6)，用于呈现界面2，界面2为界面1的横屏显示状态。同时，终端关闭界面1对应的activity5。而后，ams将activity6的启动事件和activity5的关闭事件(其中activity5的关闭事件为可选的)传递到内核层的场景识别模块，场景识别模块根据activity6的启动事件和activity5的关闭事件(其中activity5的关闭事件为可选的)确定终端处于横竖屏切换场景。
102.在其他一些实施例中，app1不是通过重建activity来实现横竖屏的切换。即，不会新建activity6用于呈现横竖屏切换后的界面2，不会关闭原来的activity5。例如，通过在原来的activity5中配置configchange参数，并设置：android:configchanges＝"orientation|screensize"。那么，当终端接收到用户执行横竖屏切换的操作时，app1通过调用onconfigurationchanged方法来实现将竖屏状态的界面1切换到横屏状态的界面2。那么，ams可以将调用onconfigurationchanged方法的事件传递到内核层的场景识别模块，场景识别模块根据该调用事件确定终端处于横竖屏切换场景。
103.又例如：在终端运行的app1调用了生物特征识别服务，生物特征识别服务将本次的调用事件传递到场景识别模块，场景识别模块根据该生物特征识别服务的调用实际确定终端处于生物特征识别场景。
104.在其他一些实施例中，预设场景还包括终端的系统负载过重的场景，其中，系统负载包括cpu负载和内存负载等。例如，cpu负载过重是指终端的cpu的占用率大于或等于阈值1(如90％)。内存负载过重是指终端的内存的占用率大于或等于阈值2(例如95％)。
105.在一个具体的实现方式中，负载监控模块可以直接获取终端的cpu信息和内存信息，例如负载监控模块可以top命令获取cpu和内存的信息。而后，负载监控模块根据获取的cpu信息计算cpu的占用率，根据获取的内存信息计算内存的占用率等，并判断终端的系统
负载是否过重。
106.s303、当监测到终端处于预设场景时，确定gc的管控信息。
107.其中，gc管控信息包括但不限于暂停gc的时间段，以及暂停gc的目标进程等。
108.在一些实施例中，终端根据预设场景的时间信息确定暂停gc的时间段。在一些示例中，根据框架层的ams建立新activity的时间确定开始暂停gc的时间tstart。或者，根据app开始调用框架层的生物特征识别服务的时间确定开始暂停gc的时间tstart。又或者，根据监测到终端的系统负载过重的监测时间确定开始暂停gc的时间tstart。在另一些示例中，在确定开始暂停gc的时间tstart后，还可以先预估一个结束暂停gc的时间tend。例如，可以预先统计出各个预设场景的持续时长，根据各个预设场景的统计时长确定gc的暂停时长δt，从而确定出结束暂停gc的时间tend。即tend＝tstart+δt。也就是说，不同的预设场景对应的暂停时长δt不同。比如，app的启动场景对应的暂停时长δt》生物特征识别场景对应的暂停时长δt》app间的界面切换场景对应的δt》app内部的界面切换场景对应的δt。又比如，不同类型的app的启动时长不同，那么不同类型的app的启动时长对应的暂停时长δt不同。
109.可以理解的是，终端还可以根据预设场景的实际进度实时调整结束时间tend，这样使得终端暂停gc的时间更加精确，既保证了预设场景的顺利进行，又保证终端及时进行gc，回收无用的堆内存。
110.当然，在其他一些示例中，暂停时长δt为默认值。例如，统计出各个预设场景的持续时长，将持续时长的最大值设置为暂停时长δt的默认值。类似的，后续可以根据预设场景的实际进度实时调整结束时间tend。
111.在一个具体的实现方式中，可具体由图2所示的gc控制模块执行确定暂停gc的时间段的步骤。具体的，场景识别模块将预设场景的信息(包括预设场景的时间信息，如框架层ams建立新activity的时间，调用框架层的生物特征识别服务的时间)发送给负载监控模块，负载监控模块将接收到的预设场景的信息发送给gc控制模块。和/或，负载监控模块将自身监测到的系统负载过重的场景信息(包括预设场景的时间信息，如监测到终端的系统负载过重的时间)发送给gc控制模块。gc根据预设场景的时间信息分别确定开始暂停gc的时间tstart，以及结束暂停gc的时间tend，并根据预设场景的实际进度实时调整结束时间tend。
112.在另一些实施例中，终端还可以根据具体的控制策略确定目标进程。需要说明的是，本技术的控制策略可以是终端默认的，或者终端提供控制策略的选择界面由用户进行选择，本技术实施例对此不做限定。
113.在一些示例中，以终端中的进程为单位，从终端当前运行的全部进程中筛选满足预设条件的进程作为目标进程，后续将暂停目标进程的gc。例如，可以为进程设置堆内存尺寸的最大值m
max
以及堆内存目标占用比t％。其中预设条件为：进程的当前堆内存尺寸小于m
max
*t％。也就是说，当某个进程的当前堆内存尺寸小于m
max
*t％时，则确定该进程为目标进程。可以理解的是，当该进程的当前堆内存尺寸小于m
max
*t％时，可认为该进程的堆内存还有足够的空间可供分配，此时暂停该进程的gc不会造成堆内存溢出的问题。反之，如果某进程的当前堆内存尺寸大于或等于m
max
*t％时，则此时不能暂停该进程的gc，否则可能会造成堆内存溢出的问题。
114.在另一些示例中，也可以确定终端当前运行的全部进程为目标进程，也就是说，暂停全部进程的gc。后续，终端监测各个进程的堆内存情况，当监测到某进程当前堆内存尺寸大于或等于m
max
*t％(也可以是其他值)时，恢复该进程的gc，以防止出现堆内存溢出的问题。
115.还需要说明的是，本技术实施例可以为不同的进程设置相同或不同的m
max
、t％，本技术实施例对此不做限定。
116.在一个具体的实现方式中，可具体由图2所示的gc控制模块执行确定目标进程的步骤。具体的，gc控制模块可以通过进程间通信(inter-process communication，ipc)查询各个app中各个进程的堆内存，维护一套包括集合s(包括所有进程)的堆内存信息。而后，根据集合s中各个进程的堆内存信息，选择当前堆内存尺寸小于m
max
*t％的进程构成集合s’。集合s’中的进程即为目标进程。
117.需要注意的是，这里集合s为终端当前运行的全部进程，包括终端当前运行的各个app的全部进程。那么，集合s’中可能包括不同app的多个进程。可见，本技术实施例提供的gc管控方法是一种系统级的管控方法，能够管控多个进程的gc，管控多个app的gc。
118.s304、根据gc管控信息暂停gc。
119.在一个具体的实现方式中，图2中所示的gc控制模块可以向集合s’中各个进程发送暂停gc的指令，以指示集合s’中各个进程暂停gc。
120.需要说明的是，gc控制模块还维护有集合s’中各个进程暂停gc的结束时间tend。当监测到某个进程的结束时间tend到来时，gc控制模块还向该进程发送恢复执行gc的指令，以指示该进程恢复执行gc。在一个示例中，该进程接收到gc控制模块发送的恢复执行gc的指令后，立即执行gc。或者，该进程接收到gc控制模块发送的恢复执行gc的指令后，判断该进程是否需要执行gc。即，确定该进程的当前堆内存尺寸是否大于或等于阈值concurrent_start_bytes，具体内容的请参考前文的描述。
121.在另一个具体的实现方式中，可以设置终端内所有进程在执行gc之前，均向图2中所示的gc控制模块查询是否自身是否属于集合s’中的进程。如果属于集合s’中的进程，则暂停执行gc。如果不属于集合s’中的进程，则继续执行gc。被暂停gc的进程启动定时器，每间隔一段时间，继续向gc控制查询自身是否属于集合s’中的进程，以便当该进程不属于集合s’时及时恢复gc。
122.在又一个具体的实现方式中，gc控制模块还持续监测被暂停gc的进程的堆内存情况，当被暂停gc的进程的堆内存达到特定条件时，如堆内存的占用率达到95％时，可以立即恢复该进程的gc，以防止堆内存溢出的问题。
123.由此可见，当终端执行与用户体验相关的任务或者终端的系统负载过重，即处于预设场景时，通过暂停部分进程执行gc来降低终端整体的系统负载，保证终端优先执行与用户体验相关的任务，提升用户的使用体验。
124.另外，由于本技术实施例提供的是系统级的gc管控方法，能够在终端处于预设场景时，暂停多个进程(包括暂停一个app的多个进程，或者暂停多个app的多个进程)的gc，能够快速降低终端整体的系统负载，极大地提升终端执行与用户体验相关任务的运行速度，提升用户体验。
125.本技术实施例还提供一种芯片系统，如图4所示，该芯片系统包括至少一个处理器
1101和至少一个接口电路1102。处理器1101和接口电路1102可通过线路互联。例如，接口电路1102可用于从其它装置(例如终端100的存储器)接收信号。又例如，接口电路1102可用于向其它装置(例如处理器1101)发送信号。示例性的，接口电路1102可读取存储器中存储的指令，并将该指令发送给处理器1101。当所述指令被处理器1101执行时，可使得终端执行上述实施例中的终端100(比如，手机)执行的各个步骤。当然，该芯片系统还可以包含其他分立器件，本技术实施例对此不作具体限定。
126.本技术实施例还提供一种装置，该装置包含在终端中，该装置具有实现上述实施例中任一方法中终端行为的功能。该功能可以通过硬件实现，也可以通过硬件执行相应的软件实现。硬件或软件包括至少一个与上述功能相对应的模块或单元。例如，app运行模块或单元，场景监测模块或单元，以及暂停gc模块或单元等。可选的，该装置还可以包括存储模块或单元、通信模块或单元等。
127.本技术实施例还提供一种计算机存储介质，包括计算机指令，当计算机指令在终端上运行时，使得终端执行如上述实施例中任一方法。
128.本技术实施例还提供一种计算机程序产品，当计算机程序产品在计算机上运行时，使得计算机执行如上述实施例中任一方法。
129.可以理解的是，上述终端等为了实现上述功能，其包含了执行各个功能相应的硬件结构和/或软件模块。本领域技术人员应该很容易意识到，结合本文中所公开的实施例描述的各示例的单元及算法步骤，本技术实施例能够以硬件或硬件和计算机软件的结合形式来实现。某个功能究竟以硬件还是计算机软件驱动硬件的方式来执行，取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本发明实施例的范围。
130.本技术实施例可以根据上述方法示例对上述终端等进行功能模块的划分，例如，可以对应各个功能划分各个功能模块，也可以将两个或两个以上的功能集成在一个处理模块中。上述集成的模块既可以采用硬件的形式实现，也可以采用软件功能模块的形式实现。需要说明的是，本发明实施例中对模块的划分是示意性的，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式。
131.通过以上的实施方式的描述，所属领域的技术人员可以清楚地了解到，为描述的方便和简洁，仅以上述各功能模块的划分进行举例说明，实际应用中，可以根据需要而将上述功能分配由不同的功能模块完成，即将装置的内部结构划分成不同的功能模块，以完成以上描述的全部或者部分功能。上述描述的系统，装置和单元的具体工作过程，可以参考前述方法实施例中的对应过程，在此不再赘述。
132.在本技术实施例各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现，也可以采用软件功能单元的形式实现。
133.所述集成的单元如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本技术实施例的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的全部或部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)或处理器执行本技术各个实施
例所述方法的全部或部分步骤。而前述的存储介质包括：快闪存储器、移动硬盘、只读存储器、随机存取存储器、磁碟或者光盘等各种可以存储程序代码的介质。
134.以上所述，仅为本技术的具体实施方式，但本技术的保护范围并不局限于此，任何在本技术揭露的技术范围内的变化或替换，都应涵盖在本技术的保护范围之内。因此，本技术的保护范围应以所述权利要求的保护范围为准。

技术特征：
1.一种垃圾回收gc的管控方法，其特征在于，包括：终端运行一个或多个app；当监测到所述终端处于预设场景时，所述终端暂停目标进程执行垃圾回收gc；其中，所述目标进程为所述一个或多个app启动的进程，所述目标进程的数量为一个或多个；所述预设场景包括app的启动场景、app界面的切换场景、横竖屏的切换场景、生物特征识别场景、所述终端的系统负载满足第一预设条件中的任一项。2.根据权利要求1所述的方法，其特征在于，在所述终端暂停目标进程执行垃圾回收gc之前，所述方法还包括：所述终端根据所述预设场景的时间信息确定暂停gc的时间段。3.根据权利要求2所述的方法，其特征在于，所述终端根据所述预设场景的时间信息确定暂停gc的时间段，包括：当所述预设场景为app的启动场景、或app界面的切换场景、或横竖屏的切换场景中任一项时，所述终端根据所述终端创建新的活动activity组件的时间确定开始暂停gc的时间；当所述预设场景为生物特征识别场景时，所述终端根据所述终端调用生物特征识别服务的时间确定开始暂停gc的时间；当所述预设场景为所述终端的系统负载达到所述第一预设条件时，所述终端根据监测到所述终端的系统负载达到所述第一预设条件的监测时间确定开始暂停gc的时间。4.根据权利要求1-3任一项所述的方法，其特征在于，在所述终端暂停目标进程执行垃圾回收gc之前，所述方法还包括：所述终端从所述一个或多个app启动的进程中，确定当前堆内存尺寸小于m
max
*t％的进程为所述目标进程，其中，m
max
为进程的堆内存尺寸的最大值，t％为进程的堆内存目标占用比；或者，所述终端确定所述一个或多个app启动的全部进程为所述目标进程。5.根据权利要求4所述的方法，其特征在于，所述一个或多个app中不同的进程对应的m
max
和/或t％不同。6.根据权利要求1-5任一项所述的方法，其特征在于，在所述终端暂停目标进程执行垃圾回收gc之后，所述方法还包括：所述终端监测每个所述目标进程的当前堆内存尺寸；当监测到所述目标进程中第一进程的当前堆内存尺寸满足第二预设条件时，恢复所述第一进程执行gc。7.根据权利要求1-6任一项所述的方法，其特征在于，所述第一预设条件包括所述终端的cpu的占用率大于或等于第一阈值，或者，所述终端的内存的占用率大于或等于第二阈值。8.根据权利要求6所述的方法，其特征在于，所述第二预设条件包括：所述第一进程的当前堆内存尺寸等于或大于m
max
*t％，其中，m
max
为进程的堆内存尺寸的最大值，t％为进程的堆内存目标占用比。9.一种终端，其特征在于，包括：处理器和存储器，所述存储器与所述处理器耦合，所述存储器用于存储计算机程序代码，所述计算机程序代码包括计算机指令，当所述处理器从
所述存储器中读取所述计算机指令，以使得所述终端执行如权利要求1-8中任一项所述的垃圾回收gc的管控方法。10.一种计算机可读存储介质，其特征在于，包括计算机指令，所述计算机可读存储介质包含在终端中，当所述计算机指令在所述终端上运行时，使得所述终端执行如权利要求1-8中任一项所述的垃圾回收gc的管控方法。11.一种芯片系统，其特征在于，包括一个或多个处理器，当所述一个或多个处理器执行指令时，所述一个或多个处理器执行如权利要求1-8中任一项所述的垃圾回收gc的管控方法。

技术总结
一种垃圾回收GC的管控方法及终端，涉及电子技术领域，可以通过暂停部分进程执行GC来降低终端整体的系统负载，保证终端优先执行与用户体验相关的任务，提升用户的使用体验，该方法包括：终端运行一个或多个APP；当监测到终端处于预设场景时，终端暂停目标进程执行垃圾回收GC；其中，目标进程为一个或多个APP启动的进程，目标进程的数量为一个或多个；预设场景包括APP的启动场景、APP界面的切换场景、横竖屏的切换场景、生物特征识别场景、终端的系统负载满足第一预设条件中的任一项。载满足第一预设条件中的任一项。载满足第一预设条件中的任一项。


技术研发人员：庞德松 裴家俊
受保护的技术使用者：华为技术有限公司
技术研发日：2022.03.02
技术公布日：2023/9/13