CN116661985B - 一种垃圾回收的守护线程的管理方法、装置及电子设备 - Google Patents

Abstract

本申请实施例提供了一种垃圾回收的守护线程的管理方法、装置及电子设备。基于该方法，在第二线程申请GC锁时，如果第三线程持有GC锁，且SGC确定应用程序的运行场景是目标场景，由SGC指示内核层提高第三线程的线程优先级，以加快第三线程的执行速度，从而缩短应用程序执行第二线程的等待时间。并且，当第三线程进入清理弱引用对象的阶段时，基于该方法，可以通过提高第三线程的线程优先级，加快清理弱引用对象的速度，从而缩短JNI、Binder等调用弱引用对象的阻塞时间。

Description

一种垃圾回收的守护线程的管理方法、装置及电子设备

技术领域

本申请实施例涉及电子设备技术领域，尤其涉及一种垃圾回收的守护线程的管理方法、装置及电子设备。

背景技术

垃圾回收(Garbage Collection，GC)是指一种自动的存储器管理机制，当某个应用程序占用的一部分内存空间不再被该应用程序访问时，该应用程序将通过GC机制清理这部分内存空间，以向操作系统归还该部分内存空间。

执行GC的线程即为GC的守护线程(Heap Task Daemon)。GC的守护线程与应用程序的插件加载线程串行，插件加载线程必须等待GC的守护线程执行完毕后才能够执行，这将导致应用程序长时间无响应。并且，GC的守护线程在清理弱引用(Weak Reference)对象的阶段，会导致Java本地接口(Java Native Interface，JNI)、Binder等调用弱引用对象的阻塞，也会导致应用程序长时间无响应。而且，GC的守护线程的线程优先级较低，这将导致GC的守护线程执行较慢，且清理弱引用对象的阶段的耗时也较长，这将进一步延长执行插件加载线程的等待时间，以及延长JNI、Binder等调用弱引用对象的阻塞时长，导致应用程序无响应时间的进一步延长。

发明内容

本申请实施例提供了一种垃圾回收的守护线程的管理方法、装置及电子设备，通过缩短GC的守护线程的执行时长，缩短执行插件加载线程的等待时长，以及通过缩短清理弱引用对象的阶段的时长，缩短JNI、Binder等调用的阻塞时长，从而有效提高应用程序的响应速度。

第一方面，本申请实施例提供了一种垃圾回收的守护线程的管理方法，该方法包括：

第一线程接收第二线程发送的第一请求。该第一线程用于管理应用程序所占用的内存，该第二线程为应用程序当前运行的线程，该第一请求用于请求垃圾回收GC锁。第一线程响应于该第一请求，确定GC锁是否被第三线程占用，该第三线程为GC的守护线程。如果第三线程占用GC锁，第一线程向低暂停时间垃圾收集器SGC发送第一信息、第一标识和第二标识。其中，SGC与该应用程序对应，第一信息用于指示请求GC锁失败，第一标识为第二线程的标识，第二标识为第三线程的标识。SGC接收到第一信息，根据第一标识确定该应用程序的运行场景是否为目标场景。如果该应用程序的运行场景为目标场景，SGC向内核层发送第二标识和第一指示信息。该第一指示信息用于指示内核层提高第三线程的线程优先级。

根据上述方法，可以通过提高第三线程的线程优先级，加快第三线程的执行速度，从而缩短应用程序执行第二线程的等待时间。

在一种实现方式中，第二线程为用于加载应用程序的插件的线程。根据上述方法，可以有效缩短加载插件的等待时间。

在一种实现方式中，该方法还包括：第一线程在应用程序启动之后初始化，并创建与该应用程序对应的SGC。根据上述方法，各SGC分别单独管理对应应用程序的第三线程的线程优先级。

在一种实现方式中，第一线程接收第二线程发送的第一请求之前，该方法还包括：第一线程接收应用程序发送的第二请求，该第二请求用于请求系统内存。第一线程响应于该第二请求，向该应用程序分配第一内存。第一线程确定该应用程序所占用的第二内存是否到达GC水线，该GC水线是根据第一内存确定的。如果第二内存到达GC水线，第一线程启动第三线程，并为第三线程分配GC锁。如果第二内存未到达GC水线，第一线程不启动第三线程。根据上述方法，第一线程可以有效管理应用程序的GC过程，通过为应用程序动态分配合理的堆内存，以及及时启动GC的守护线程，可以及时清理应用程序所占用的堆内存。

在一种实现方式中，该方法还包括：如果应用程序的运行场景不是目标场景，SGC向内核层发送第二标识和第二指示信息。该第二指示信息用于指示内核层使用第三线程当前的线程优先级。根据上述方法，如果SGC确定应用程序的运行场景不是目标场景，无需提高第三线程的线程优先级，从而避免第三线程额外占用资源影响为其它线程调度的资源。

在一种实现方式中，该方法还包括：第一线程接收第三线程释放的GC锁。第一线程向SGC发送第二信息和第二标识，第二信息用于指示请求GC锁成功。SGC接收到第二信息，向内核层发送第二标识和第三指示信息。该第三指示信息用于指示内核层降低第三线程的线程优先级。根据上述方法，在第三线程执行完毕之后，恢复第三线程的线程优先级，以降低为第三线程调度的资源，从而可以释放为第三线程额外调度的资源，以为其它线程预留更多可调度的资源，提高资源调度的合理性。

在一种实现方式中，该方法还包括：如果第三线程未占用GC锁，第一线程向第二线程分配GC锁。根据上述方法，如果第三线程未占用GC锁，直接为第二线程分配GC锁，避免第二线程的执行等待。

在一种实现方式中，该方法还包括：SGC接收第三线程处于清理弱引用对象的阶段时发送的第二标识。SGC根据第二标识识别应用程序的运行场景是否为目标场景。如果应用程序的运行场景是目标场景，SGC向内核层发送第二标识和第四指示信息。该第四指示信息用于指示内核层提高第三线程的线程优先级。根据上述方法，当第三线程进入清理弱引用对象的阶段时，基于该方法1200，可以通过提高第三线程的线程优先级，加快清理弱引用对象的速度，从而缩短JNI、Binder等调用弱引用对象的阻塞时间。

在一种实现方式中，该方法还包括：SGC接收第三线程发送的第三信息和第二标识，该第三信息用于指示弱引用对象清理完毕。SGC接收到该第三信息，向内核层发送第二标识和第五指示信息。该第五指示信息用于指示内核层降低第三线程的线程优先级。根据上述方法，在第三线程执行清理弱引用对象的阶段完毕之后，恢复第三线程的线程优先级，以降低为第三线程调度的资源，从而可以释放为清理弱引用对象的阶段额外调度的资源，以为其它线程预留更多可调度的资源，提高资源调度的合理性。

在一种实现方式中，该方法还包括：如果应用程序的运行场景不是目标场景，SGC向内核层发送第二标识和第六指示信息。该第六指示信息用于指示内核层使用第三线程当前的线程优先级。根据上述方法，如果SGC确定应用程序的运行场景不是目标场景，无需提高第三线程的线程优先级，从而避免第三线程额外占用资源影响为其它线程调度的资源。

在一种实现方式中，目标场景为应用程序在前台运行。根据上述方法，可以仅在用户可感知应用程序出现无响应等问题的情况下，提高第三线程的线程优先级，以避免在用户无感知时提高第三线程的线程优先级所造成的资源浪费。

第二方面，本申请实施例提供了一种垃圾回收的守护线程的管理装置，所述装置包括：

第一接收模块，用于第一线程接收第二线程发送的第一请求。该第一线程用于管理应用程序所占用的内存，该第二线程为应用程序当前运行的线程，该第一请求用于请求垃圾回收GC锁。第一识别模块，用于第一线程响应于第一请求，确定GC锁是否被第三线程占用，该第三线程为GC的守护线程。第一发送模块，用于如果第三线程占用GC锁，第一线程向低暂停时间垃圾收集器SGC发送第一信息、第一标识和第二标识。其中，SGC与应用程序对应，第一信息用于指示请求GC锁失败，该第一标识为第二线程的标识，该第二标识为第三线程的标识。第二识别模块，用于SGC接收到第一信息，根据第一标识确定应用程序的运行场景是否为目标场景。第二发送模块，用于如果应用程序的运行场景为目标场景，SGC向内核层发送第二标识和第一指示信息，第一指示信息用于指示内核层提高第三线程的线程优先级。

根据本申请实施例提供的装置，可以通过提高第三线程的线程优先级，加快第三线程的执行速度，从而缩短应用程序执行第二线程的等待时间。

第三方面，本申请实施例提供了一种电子设备，包括：处理器和存储器；存储器存储有程序指令，当程序指令被处理器执行时，使得电子设备执行上述各方面及其各个实现方式中的方法。

第四方面，本申请实施例还提供了一种芯片系统，该芯片系统包括处理器和存储器，存储器存储有程序指令，当程序指令被处理器执行时，使得芯片系统执行上述各方面及其各个实现方式中的方法。例如，生成或处理上述方法中所涉及的信息。

第五方面，本申请实施例还提供一种计算机可读存储介质，计算机可读存储介质中存储有程序指令，当程序指令在计算机上运行时，使得计算机执行上述各方面及其各个实现方式中的方法。

第六方面，本申请实施例还提供了一种计算机程序产品，当其在计算机上运行时，使得计算机执行上述各方面及其各个实现方式中的方法。

附图说明

图1是本申请实施例提供的应用程序的内存示意图；

图2是本申请实施例提供的堆内存的结构示意图；

图3是本申请实施例提供的触发GC的守护线程的方法300的流程图；

图4是本申请实施例提供的插件的加载流程的示意图；

图5是本申请实施例提供的线程执行和资源调度示意图；

图6是本申请实施例提供的GC的守护线程的执行流程的示意图；

图7是本申请实施例提供的线程执行和资源调度示意图；

图8是本申请实施例提供的电子设备800的结构示意图；

图9是本申请实施例提供的一种GC的守护线程的管理方法900的流程图；

图10是本申请实施例提供的一种GC的守护线程的管理方法1000的流程图；

图11是本申请实施例提供的一种GC的守护线程的管理方法1100的流程图；

图12是本申请实施例提供的一种GC的守护线程的管理方法1200的流程图；

图13是本申请实施例提供的一种GC的守护线程的管理方法1300的流程图；

图14是本申请实施例提供的一种GC的守护线程的管理方法1400的流程图；

图15是本申请实施例提供的一种电子设备的硬件结构示意图；

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

具体实施方式

本申请说明书和权利要求书及附图说明中的术语“第一”、“第二”和“第三”等是用于区别不同对象，而不是用于限定特定顺序。

在本申请实施例中，“示例性的”或者“例如”等词用于表示作示例、例证或说明。本申请实施例中被描述为“示例性的”或者“例如”的任何实施例或设计方案不应被解释为比其它实施例或设计方案更优选或更具优势。确切而言，使用“示例性的”或者“例如”等词旨在以具体方式呈现相关概念。

本申请的实施方式部分使用的术语仅用于对本申请的具体实施例进行解释，而非旨在限定本申请，下面将结合附图对本申请的实施例进行详细描述。

垃圾回收(Garbage Collection，GC)是指一种自动的存储器管理机制，当某个应用程序占用的一部分内存空间不再被该应用程序访问时，该应用程序将通过GC机制清理这部分内存空间，以向操作系统归还该部分内存空间。执行GC过程的线程即为GC的守护线程(Heap Task Daemon)，可以基于“kGcCauseClassLinker，//used to implement exclusionbetween code cache matedata and GC”，触发GC的守护线程，即用于实现代码缓存元数据和GC之间的排除。以图1所示的应用程序的内存示意图为例对触发应用程序的GC的守护线程进行说明，堆内存的最大值(max size)为可以分配给应用程序的最大堆内存，GC水线(water mark)用于触发应用程序的GC的守护线程，GC水线对应的堆内存可以根据应用程序当前占用的堆内存(used size)确定，在应用程序当前占用的堆内存的基础上设置预留的空闲堆内存(free size)，GC水线对应的堆内存即为应用程序当前占用的堆内存与预留的空闲堆内存的和值。应用程序在当前占用的堆内存的基础上继续占用预留的空闲堆内存，直到所占用的堆内存到达GC水线，触发应用程序的GC的守护线程。

启动应用程序的GC的守护线程之后，将对应用程序所占用的堆内存进行清理和复制。以图2所示的堆内存的结构为例进行说明，在图2中，阴影部分表示堆内存中被使用的空间，“×”表示堆内存中不能使用的空间。堆内存的空间包括From空间和To空间，其中，应用程序运行的过程中所产生的对象放入From空间，To空间是一个空闲的空间。如图2中①所示，在From空间201被占满时，执行GC的守护线程，将From空间201内的对象复制到To空间202内，并清理复制对象后的To空间202，以及将To空间202变更为From空间203，将From空间201变更为To空间204。如图2中②所示，From空间203仅包括清理对象后剩余的对象。如果应用程序继续产生新的对象，产生的新的对象将被放入From空间203中，如图2中③所示，当From空间203被占满时，将再次执行GC的守护线程，以将From空间203中的对象复制到To空间204，并清理To空间204中的对象，该过程可以参考图2中①-②的过程，此处不赘述。如图2中④所示，再次执行GC的守护线程之后，From空间205仅包括清理对象后剩余的对象，To空间206处于空闲状态。随着应用程序的运行，将重复执行上述图2所示的过程，以通过GC的守护线程清理应用程序所占用的内存。

图3为本申请实施例提供的触发GC的守护线程的方法300。该方法300包括步骤S301-步骤S304：

步骤S301，应用程序向第一线程发送第二请求。

第一线程用于管理应用程序所占用的内存，例如：Heap线程。在应用程序启动之后，第一线程进行初始化。例如：应用程序在第一线程中注册相关的信息。

应用程序在启动时或者运行时，向第一线程发送第二请求，以向第一线程申请系统内存。

在一些实施例中，应用程序可以基于用户的选择启动，并在启动时向第一线程发送第二请求。例如：用户点击应用程序A的图标，以向电子设备发送选择应用程序A的指令，电子设备响应于该指令，启动应用程序A，此时，应用程序A向第一线程发送第二请求，以向第一线程申请系统内存。

在一些实施例中，应用程序可以基于系统设置自动启动，并在启动时向第一线程发送第二请求。例如：系统默认设置为开机启动应用程序B，电子设备开机之后，应用程序B自动启动，此时，应用程序B向第一线程发送第二请求，以向第一线程申请系统内存。

在一些实施例中，应用程序在运行时，向第一线程发送第二请求。例如：应用程序C在运行时，向第一线程发送第二请求，以向第一线程申请系统内存。

步骤S302，第一线程响应于第二请求，向应用程序分配第一内存。

第一内存为第一线程向应用程序分配的空闲堆内存。在一些实施例中，第一线程可以根据应用程序当前占用的堆内存为应用程序分配空闲堆内存。

步骤S303，第一线程确定应用程序所占用的第二内存是否到达GC水线。

结合图1进行说明，以应用程序当前占用的堆内存为图1中used size，以第一内存为图1中的free size为例。应用程序的GC水线根据used size确定，即GC水线为used size与free size的和值。应用程序在运行过程中产生新的对象，并将该新的对象放入被分配的free size中，即占用第一内存。将used size和在free size中所占用的内存的和值称为第二内存，第一线程通过比较第二内存与GC水线，可以确定第二内存是否到达GC水线。

其中，如果第二内存等于GC水线，可以确定第二内存到达GC水线，即应用程序所占用的总堆内存已经到达GC水线。在一些实施例中，如果第二内存小于GC水线，且GC水线与第二内存的差值小于或者等于预设差值阈值，也可以确定第二内存到达GC水线。

如果第二内存小于GC水线，可以确定第二内存未到达GC水线，即应用程序所占用的总堆内存未到达GC水线。在一些实施例中，如果第二内存小于GC水线，且GC水线与第二内存的差值大于预设差值阈值，也可以确定第二内存未到达GC水线。

步骤S304，如果第二内存到达GC水线，第一线程启动第三线程，并为第三线程分配GC锁。

第三线程为GC的守护线程。

如果第二内存到达GC水线，第一线程触发第三线程，即启动GC的守护线程。第三线程在启动之后，第三线程向第一线程申请GC锁，第一线程为第三线程分配GC锁，此时，由第三线程持有该GC锁。

第一线程在触发第三线程之后，记录与该第三线程相关的信息。例如：第一线程在触发第三线程时，会将GC锁被占用的占用信息、持有GC锁的第三线程的线程标识等，记录在Heap线程对应的任务处理器(task processor)中。

如果第二内存未到达GC水线，第一线程不启动第三线程。

如果第二内存未到达GC水线，第一线程不触发第三线程，即不启动GC的守护线程。

基于步骤S301-步骤S305，第一线程可以有效管理应用程序的GC过程，通过为应用程序动态分配合理的堆内存，以及及时启动GC的守护线程，可以及时清理应用程序所占用的堆内存。

在本申请实施例中，可以将应用程序当前运行的线程称为第二线程。第二线程可以为应用程序的主线程、运行在应用程序的主线程中的子线程等。例如：用于加载应用程序的插件的线程、抓取内存快照文件(Heap Profile，Hprof)的线程等。

第二线程与第三线程的执行顺序为串行执行。当第二线程和第三线程中的一个线程执行时，该线程持GC锁，另一个线程需要等待该线程执行完毕，并释放GC锁之后才能够开始执行。由此，第二线程启动之后，会向第一线程申请GC锁，并在申请GC锁成功之后开始执行。

以图4所示的插件的加载流程为例进行说明，插件的加载流程包括第一流程401、第二流程402和第三流程403。其中，第一流程401是应用程序加载插件的业务流程。应用程序在加载插件之间，为用于加载应用程序的插件的线程(为了便于描述，后续简称为插件加载线程)申请GC锁，在第二流程402中，如果进入临界区，如“gc::ScopedCCriticalSection”、“gc::kGcCauseClassLinker”、“gc::kCollectorTypeClassLinker”，将触发第三线程(Start GC)。此时，应用程序在加载插件之前需要等待第三线程释放GC锁，即进入“WaitForGcToCompleteLocked”。在第三线程释放GC锁之后，进入第三流程403，即插件加载线程获得GC锁，开始加载插件。

线程优先级对应于中央处理器(Central Processing Unit，CPU)为线程调度的资源，其中，线程优先级越高，CPU为线程调度的资源越多，线程优先级越低，CPU为线程调度的资源越少。进一步地，CPU为线程调度的资源影响线程的执行速度，具体的，CPU为线程调度的资源越多，线程的执行速度越快，CPU为线程调度的资源越少，线程的执行速度越慢。

线程优先级的数值越大，线程优先级的等级越低，线程优先级的数值越小，线程优先级的等级越高。通常，第三线程(即GC的守护线程)的线程优先级较低，如第三线程的线程优先级为124。由此，CPU为第三线程调度的资源较少，第三线程的执行速度较慢。相应的，执行第二线程的等待时间越长。

以应用程序为阅读应用，第二线程为插件加载线程为例，可以参考图5所示的线程执行和资源调度示意图。如图5所示，阅读应用的主线程包括第一阶段501、第二阶段502和第三阶段503。其中，在第一阶段501，阅读应用可以正常执行各第二线程。当第一线程触发第三线程(即GC的守护线程)时，第三线程持GC锁，阅读应用的主线程进入第二阶段502，在第二阶段502内，如果阅读应用开启插件加载线程，即阅读应用开始加载插件，插件加载线程需要等待第三线程执行完毕并释放GC锁才可以执行。当第三线程执行完毕，并释放GC锁之后，阅读应用的主线程进入第三阶段503。在第二阶段502中，由于阅读应用一直未加载插件，导致阅读应用在第二阶段502无响应。第三线程执行完毕并释放GC锁之后，阅读应用的主线程进入第三阶段503。在第三阶段503中，阅读应用开始执行处于等待状态的插件加载线程，即阅读应用开始加载插件，即阅读应用恢复响应。

CPU为第三线程调度的资源可以参考资源调度条504，资源调度条504包括资源5041和空闲5042。其中，资源5041为图5所示的资源调度条504中灰度值较低的方块，空闲5042为图5所示的资源调度条504中灰度值较高的方块。在资源5041处，第三线程执行；在空闲5042处，第三线程中止执行。由资源调度条504中资源5041和空闲5042的数量及分布可知，资源5041的数量较少，且资源5041分布较分散，这将导致第三线程的执行速度较慢，从而导致第二阶段502的时间较长，即阅读应用长时间无法加载插件，长时间无响应。

第三线程(即GC的守护线程)在执行时包括多个阶段，其中，第三线程处于清理弱引用(Weak Reference)对象的阶段时，会导致Java本地接口(Java Native Interface，JNI)、Binder等调用弱引用对象的阻塞。以图6所示的GC的守护线程的执行流程为例进行说明，该执行流程包括第一流程601和第二流程602。触发GC的守护线程(即第三线程)之后，第三线程首先执行第一流程601，第一流程601包括内存复制(CopyingPhase())、切换堆内存空间(SwitchToShareMarkStackMode())、标记堆内存(ProcessThreadLocalMarkStacks())、撤销标记堆内存(RevokeThreadLocalMarkStacks())、运行检查点(RunCheckpoint())。第三线程进入清理弱引用对象的阶段(RequestCheckpoint())，即进入第二流程602，将暂停每个线程的弱引用对象访问，即暂停JNI、Binder等调用弱引用对象。

由上文可知，GC的守护线程的线程优先级较低，由此，CPU为GC的守护线程调度的资源较少，相应的，GC的守护线程中清理弱引用对象时所能够使用的资源也较少，执行清理弱引用对象的速度较慢，JNI、Binder等调用弱引用对象的阻塞时间也将延长。

以应用程序为社交应用为例，可以参考图7所示的线程执行和资源调度示意图。如图7所示，社交应用的主线程包括第一阶段701、第二阶段702和第三阶段703。其中，在第一阶段701，社交应用可以正常执行各第二线程。第一线程触发第三线程(即GC的守护线程)时，第三线程持GC锁，社交应用的主线程进入第二阶段702。其中，基于第三线程的不同阶段，第二阶段702可以划分为非阻塞阶段7021和阻塞阶段7022。其中，非阻塞阶段7021对应于第三线程除清理弱引用对象以外的阶段，阻塞阶段7022对应于第三线程的清理弱引用对象的阶段。在非阻塞阶段7021内，社交应用的第二线程可以通过JNI、Binder等正常调用弱引用对象。在阻塞阶段7022内，社交应用的第二线程将无法通过JNI、Binder等调用弱引用对象，即调用阻塞。在阻塞阶段7022中，由于JNI、Binder等调用弱引用对象的阻塞，导致社交应用在阻塞阶段7022无响应。在第三线程完成清理弱引用对象之后，社交应用的主线程进入第三阶段703。在第三阶段703中，社交应用的第二线程可以正常调用弱引用对象，即社交应用恢复响应。

CPU为第三线程清理弱引用对象的阶段调度的资源可以参考资源调度条704，资源调度条704包括资源7041和空闲7042。其中，资源7041为图7所示的资源调度条704中灰度值较低的方块，空闲7042为图7所示的资源调度条704中灰度值较高的方块。在资源7041处，第三线程执行清理弱引用对象；在空闲7042处，第三线程中止执行清理弱引用对象。由资源调度条704中资源7041和空闲7042的数量及分布可知，资源7041的数量较少，且资源7041分布较分散，这将导致第三线程执行清理若应用的速度较慢，从而导致阻塞阶段7022的时间较长，即社交应用长时间无法调用弱引用对象，长时间无响应。

为了解决上述问题，本申请实施例提供了GC的守护线程的管理方法，该方法可以应用于电子设备，基于该方法，可以管理电子设备上运行的应用程序的GC的守护线程。通过提高GC的守护线程的线程优先级，以加快GC的守护线程的执行速度，从而缩短应用程序执行其它线程的等待时长，以及缩短JNI、Binder等调用弱引用对象的阻塞时长。

其中，电子设备可以为手机、计算机、平板电脑等。图8是本申请实施例提供的电子设备的硬件结构示意图。该设备既可以作为多设备协同中的主设备，也可以作为多设备协同中的从设备。如图8所示，电子设备800可以包括处理器810，存储器820，通用串行总线(universal serial bus，USB)接口830，射频电路840，移动通信模块850，无线通信模块860，摄像头870，显示屏880，触摸传感器890，气压传感器8010和按键8020等。

处理器810可以包括一个或多个处理单元，例如：处理器810可以包括应用程序处理器(application processor，AP)，调制解调处理器，图形处理器(graphics processingunit，GPU)，图像信号处理器(image signal processor，ISP)，视频编解码器，数字信号处理器(digital signal processor，DSP)，基带处理器，和/或神经网络处理器(neural-network processing unit，NPU)等。其中，不同的处理单元可以是独立的器件，也可以集成在一个或多个处理器中，例如集成在系统芯片(system on a chip，SoC)中。处理器810中还可以设置存储器，用于存储指令和数据。在一些实施例中，处理器810中的存储器为高速缓冲存储器。该存储器可以保存处理器810刚用过或循环使用的指令或数据。

在一些实施例中，处理器810可以包括一个或多个接口。接口可以包括集成电路(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)接口等。

存储器820可以用于存储计算机可执行程序代码，可执行程序代码包括指令。存储器820可以包括存储程序区和存储数据区。其中，存储程序区可存储操作系统、至少一个功能所需的应用程序程序(比如声音播放功能，图像播放功能等)等。存储数据区可存储电子设备800使用过程中所创建的数据(比如音频数据，电话本等)等。此外，存储器820可以包括一个或者多个存储单元，例如可以包括易失性存储器(volatile memory)，如：动态随机存取存储器(dynamic random access memory，DRAM)、静态随机存取存储器(static randomaccess memory，SRAM)等；还可以包括非易失性存储器(non-volatile memory，NVM)，如：只读存储器(read-only memory，ROM)、闪存(flash memory)等。处理器810通过运行存储在存储器820的指令，和/或存储在设置于处理器中的存储器的指令，执行电子设备800的各种功能应用程序以及数据处理。

这里需要补充说明的是，本申请实施例所指的操作系统，包括但不限于Android操作系统、IOS操作系统、iPad OS、鸿蒙操作系统(HarmonyOS)、Windows操作系统、Linux操作系统、MAC OS操作系统、嵌入式系统等。

电子设备800的无线通信功能可以通过射频电路840、移动通信模块850、无线通信模块860、调制解调处理器以及基带处理器等实现。

射频电路840可以包括至少一个天线841，用于发射和接收电磁波信号。电子设备800中的每个天线可用于覆盖单个或多个通信频带。在一些实施例中，天线可以和调谐开关结合使用。

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

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

无线通信模块860可以包括无线保真(wireless fidelity，Wi-Fi)模块，蓝牙(bluetooth，BT)模块、GNSS模块、近距离无线通信技术(near field communication，NFC)模块、红外(infrared，IR)模块等。无线通信模块860可以是集成上述至少一个模块的一个或多个器件。无线通信模块860经由天线841接收电磁波，将电磁波信号调频以及滤波处理，将处理后的信号发送到处理器810。无线通信模块860还可以从处理器810接收待发送的信号，对其进行调频，放大，经天线841转为电磁波辐射出去。

本申请实施例中，电子设备800的无线通信功能例如可以包括全球移动通讯系统(global system for mobile communications，GSM)，通用分组无线服务(general packetradio service，GPRS)，码分多址接入(code division multiple access，CDMA)，宽带码分多址(wideband code division multiple access，WCDMA)，时分码分多址(time-divisioncode division multiple access，TD-SCDMA)，长期演进(long term evolution，LTE)，第五代移动通信技术新空口(5th generation mobile networks new radio，5G NR)，BT，GNSS，WLAN，NFC，FM，和/或IR等功能。GNSS可以包括全球卫星定位系统(globalpositioning system，GPS)，全球导航卫星系统(global navigation satellite system，GLONASS)，北斗卫星导航系统(beidou navigation satellite system，BDS)，准天顶卫星系统(quasi-zenith satellite system，QZSS)和/或星基增强系统(satellite basedaugmentation systems，SBAS)。

摄像头870用于捕获静态图像或视频。摄像头870包括镜头和感光元件，物体通过镜头生成光学图像投射到感光元件。感光元件可以是电荷耦合器件(charge coupleddevice，CCD)或互补金属氧化物半导体(complementary metal-oxide-semiconductor，CMOS)光电晶体管。感光元件把光信号转换成电信号，之后将电信号传递给ISP转换成数字图像信号。ISP将数字图像信号输出到DSP加工处理。DSP将数字图像信号转换成标准的RGB，YUV，RYYB等格式的图像信号。在一些实施例中，电子设备800可以包括1个或N个摄像头870，N为大于1的正整数。

NPU为神经网络(neural-network，NN)计算处理器，通过借鉴生物神经网络结构，例如借鉴人脑神经元之间传递模式，对输入信息快速处理，还可以不断的自学习。通过NPU可以实现电子设备800的智能认知等应用程序，例如：图像识别，人脸识别，语音识别，文本理解等。

显示屏880用于显示图像，视频等。显示屏880包括显示面板。显示面板可以采用液晶显示屏(liquid crystal display，LCD)，有机发光二极管(organic light-emittingdiode，OLED)，有源矩阵有机发光二极体或主动矩阵有机发光二极体(active-matrixorganic light emitting diode的，AMOLED)，柔性发光二极管(flex light-emittingdiode，FLED)，MiniLED，MicroLED，Micro-OLED，量子点发光二极管(quantum dot lightemitting diodes，QLED)等。在一些实施例中，电子设备800可以包括1个或N个显示屏880，N为大于1的正整数。

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

气压传感器8010用于测量气压。在一些实施例中，电子设备800通过气压传感器8010测得的气压值计算海拔高度，辅助定位和导航。

按键8020包括开机键，音量键等。按键8020可以是机械按键。也可以是触摸式按键。电子设备800可以接收按键输入，产生与电子设备800的用户设置以及功能控制有关的键信号输入。

可以理解的是，本申请实施例示意的结构并不构成对电子设备800的具体限定。在本申请另一些实施例中，电子设备800可以包括比图示更多或更少的部件，或者组合某些部件，或者拆分某些部件，或者不同的部件布置。图示的部件可以以硬件，软件或软件和硬件组合实现。

实施例1

图9为本申请的实施例1提供的一种GC的守护线程的管理方法900。该方法900可以应用于如图8所示的电子设备800。结合步骤S301-S304，以及图4-5，如果在步骤S304之后，应用程序启动第二线程，即在第三线程持有GC锁时，应用程序启动第二线程，基于该方法900，可以通过提高第三线程的线程优先级，加快第三线程的执行速度，从而缩短应用程序执行第二线程的等待时间。该方法900包括步骤S901-步骤S908：

步骤S901，第二线程向第一线程发送第一请求。

第二线程在执行时，向第一线程发送第一请求，以申请持有GC锁。

由上文的描述可知，如果第二线程与第三线程的执行顺序为串行执行，持有GC锁的线程将优先执行。以第二线程为用于加载应用程序的插件的线程为例，如果第三线程持有GC锁，优先执行第三线程，并在第三线程执行完毕，并释放GC锁之后，执行该用于加载应用程序的插件的线程。如果用于加载应用程序的插件的线程持有GC锁，优先执行该用于加载应用程序的插件的线程，并在该线程执行完毕，并释放GC锁之后，执行第三线程。

步骤S902，第一线程响应于第一请求，确定GC锁是否被第三线程占用。

由步骤S304可知，第一线程在触发第三线程时，会记录与第三线程相关的信息。以第一线程将与第三线程相关的信息记录在task processor中为例，第一线程响应于第一请求，根据task processor中记录的任务信息可以判断GC锁是否为第三线程占用。其中，如果task processor中记录有GC锁被占用的占用信息，以及第三线程的线程标识，第一线程可以确定第三线程持有GC锁。

步骤S903，如果第三线程占用GC锁，第一线程向低暂停时间垃圾收集器SGC发送第一信息、第一标识和第二标识。

在本申请实施例中，SGC为原生层(Native)中的一个对象或者实例。第一线程在应用程序启动之后初始化，并创建与该应用程序对应的SGC。SGC用于在第二线程申请GC锁失败时，确定第三线程的线程优先级。其中，不同的应用程序对应不同的第一线程和SGC，也就是说，各应用程序的第一线程可以单独管理对应的应用程序的内存，各应用程序的SGC可以单独管理对应的应用程序的第三线程的线程优先级。

如果第三线程占用GC锁，第一线程生成第一信息，该第一信息用于指示请求GC锁失败。第三线程向SGC发送该第一信息，以及第一标识和第二标识。其中，第一标识为第二线程的线程标识，第二标识为第三线程的线程标识。线程标识用于唯一标识对应的线程，在一些实施例中，第一标识和第二标识可以为线程的身份识别码ID。

如果第三线程占用GC锁，第一线程获取第一标识和第二标识。由图3可知，如果第三线程占用GC锁，第一线程进入等待释放GC锁的程序，以等待第三线程释放GC锁。以第一线程调用“WaitForGcToCompleteLocked”，进入等待释放GC锁的程序为例，第一线程可以通过“WaitForGcToCompleteLocked”获取第二线程的线程标识，即第一标识。根据步骤S304和步骤S902可知，第一线程触发第三线程之后会记录与第三线程相关的信息，以第一线程在task processor中记录第三线程的任务信息为例，第一线程可以从task processor获取到第三线程的线程标识，即第二标识。

第一线程将生成的第一信息，以及获取到的第一标识和第二标识发送给SGC。

步骤S904，SGC接收到第一信息，根据第一标识确定应用程序的运行场景是否为目标场景。

SGC接收到第一信息之后，根据该第一信息确定第二线程申请GC锁失败。SGC在确定第二线程申请GC锁失败之后，根据第一标识确定应用程序的运行场景是否为目标场景。

由上文对GC锁的作用的描述可知，当第三线程持有GC锁时，第二线程需要等待第三线程执行完毕，并释放GC锁之后执行。也就是说，在等待第三线程执行的过程中，第二线程不执行，应用程序也就无法通过第二线程实现对应的功能，也即应用程序无响应。如果该应用程序的运行场景是，该应用程序对于用户的响应可以被用户所感知，该应用程序的运行场景是目标场景。在一些实施例中，目标场景可以为应用程序在前台运行。如果该应用程序的运行场景是，该应用程序对于用户的响应不会被用户所感知，该应用程序的运行场景不是目标场景。在一些实施例中，应用程序在后台运行不是目标场景。

在一些实施例中，SGC可以通过调用预设函数确定应用程序的运行场景是否为目标场景。该预设函数可以为“WaitForGcToCompleteLocked”，SGC通过调用该预设函数，获取与第一标识对应的判断结果，该判断结果为判断应用程序的运行场景是否为目标场景的判断结果。其中，该判断结果可以用“是”或者“1”表示应用程序的运行场景是目标场景，该判断结果可以用“否”或者“0”表示应用程序的运行场景不是目标场景。

步骤S905，如果应用程序的运行场景为目标场景，SGC向内核层发送第二标识和第一指示信息。

如果SGC确定应用程序的运行场景为目标场景，当第二线程等待执行时，应用程序无响应会被用户感知，即用户会感知到应用程序的卡顿，影响用户的体验感。为了解决上述问题，SGC在确定应用程序的运行场景为目标场景时，向内核层发送第二标识和第一指示信息。

其中，SGC根据应用程序的运行场景是目标场景的判断结果，生成第一指示信息，该第一指示信息用于指示提高第三线程的线程优先级。内核层(Kernel)对外提供调整线程的线程优先级的功能。SGC向内核层发送第二标识和该第一指示信息，以指示内核层提高第三线程的线程优先级。

在一些实施例中，SGC可以向内核层发送第二标识和第一指示信息，该第一指示信息包括线程优先级的具体等级，该具体等级高于第三线程当前的线程优先级。

步骤S906，内核层根据第二标识和第一指示信息，提高第三线程的线程优先级。

内核层可以根据第二标识确定对应的线程，即第三线程。并将第三线程的线程优先级调整为第一指示信息中的具体等级，以提高第三线程的线程优先级。

第三线程的线程优先级提高之后，CPU将为第三线程调度更多的资源，第三线程的执行速度加快，从而有效缩短第二线程等待第三线程执行完毕的时间，进而有效缩短应用程序无响应的时间，以有效提高应用程序的响应速度，提高用户的体验感。

步骤S907，第三线程向第一线程释放GC锁。

第三线程可以在执行完毕之后，向第一线程发送执行完毕的信息，第一线程根据该信息可以确定第三线程执行完毕，并释放第三线程的GC锁。以第一线程调用“WaitForGcToCompleteLocked”，进入等待释放GC锁的过程为例，第一线程接收到第三线程发送的执行完毕的信息之后，结束调用“WaitForGcToCompleteLocked”，退出等待释放GC锁的过程。

步骤S908，第一线程向第二线程分配GC锁。

第三线程为处于等待中的第二线程分配GC锁，第二线程申请到GC锁之后，开始执行。

示例1

结合示例1对本申请实施例1提供的GC的守护线程的管理方法900进行进一步说明。

以应用程序为阅读应用，第一线程为Heap线程，第二线程为插件加载线程，插件加载线程的线程标识为“25265”，第三线程的线程标识为“25265”为例。阅读应用加载插件，插件加载线程向Heap线程发送第一请求申请GC锁：例如：插件加载线程向Heap线程发送“申请GC锁”。Heap线程触发第三线程的过程与步骤S301-步骤S304相类似，此处不再赘述。如果Heap线程在将与第三线程相关的信息记录在task processor中，Heap线程响应于“申请GC锁”，在task processor中查询记录的任务信息。如果task processor中记录有GC锁被占用的占用信息，以及“25265”，Heap线程可以确定第三线程持有GC锁。Heap线程确定第三线程占用GC锁之后，Heap线程进入等待释放GC锁的阶段。例如：Heap线程通过调用“WaitForGcToCompleteLocked”进入等待释放GC锁的阶段。Heap线程生成第一信息，如：“GC锁申请失败”。Heap线程可以通过“WaitForGcToCompleteLocked”获取到插件加载线程的线程标识“25265”。Heap线程可以从task processor中获取到第三线程的线程标识“25265”。Heap线程向SGC发送“GC锁申请失败”、“25265”和“25265”。SGC为阅读应用启动之后创建的，该SGC与阅读应用唯一对应，用于单独管理阅读应用的第三线程的线程优先级。SGC接收到“GC锁申请失败”之后，根据“25265”确定阅读应用的运行场景是否为目标场景。以目标场景为应用程序在前台运行为例。如果阅读应用在前台运行，SGC确定阅读应用的运行场景是目标场景。SGC生成第一指示信息，如“50”，以指示内核层提高第三线程的线程优先级。内核层根据“25265”确定第三线程为线程标识“25265”对应的GC的守护线程。如果第三线程当前使用的线程优先级为“124”，内核层根据“50”，将第三线程的线程优先级从“124”提高至“50”。表1为第三线程的线程优先级在提高前后的运行状态参数。

表1

可以通过第三线程等待执行的时间Runnable(Runnable)/第三线程执行的时间Running(Running)表征第三线程的执行速度，其中，该比值越小，第三线程的执行速度越快。根据表1，第三线程的线程优先级在提高之后的执行速度显著高于提高之前的执行速度，即在第三线程的线程优先级提高之后，CPU将为第三线程调度更多的资源，第三线程的执行速度将显著提高。

第三线程在执行完毕之后，可以向Heap线程发送执行完毕的信息，Heap线程根据该信息可以确定第三线程执行完毕，并接收第三线程释放的GC锁。Heap线程向插件加载线程分配GC锁，插件加载线程开始执行，即阅读应用程序开始加载插件，插件加载线程执行完毕，阅读应用完成响应。

阅读应用在加载插件时，如果正在执行GC的守护线程，当SGC确定阅读应用在前台运行时，SGC向内核层发送第一指示信息，以指示内核层提高GC的守护线程的线程优先级，令CPU为GC的守护线程调度更多的资源，以提高GC的守护线程的执行速度，从而缩短阅读应用加载插件的等待时间，进而缩短阅读应用的无响应时间，提高阅读应用的响应速度。在其它示例中，例如应用程序在其它需要申请GC锁的情况下，均可以按照方法900，通过提高GC的守护线程的线程优先级，以缩短执行相应线程的等待时间，提高应用程序的响应速度。

实施例2

基于实施例1，在第三线程执行完毕之后，恢复第三线程的线程优先级，以降低为第三线程调度的资源，从而可以释放为第三线程额外调度的资源，以为其它线程预留更多可调度的资源，提高资源调度的合理性。

图10为本申请实施例提供的一种GC的守护线程的管理方法1000。该方法1000包括：步骤S1001-步骤S1011，其中，步骤S1001-步骤S1008与步骤S901-步骤S908相类似，此处不再赘述。对步骤S1009-步骤S1011做出具体说明：

步骤S1009，第一线程向SGC发送第二信息和第二标识。

内核层提高第三线程的线程优先级之后，CPU将按照该较高的线程优先级为第三线程分配资源。但是，由于第三线程在多数情况下相较于其他线程的重要程度较低，如果为第三线程分配过多的资源，其它重要程度更高的线程将被分配到较少的资源，从而降低这些重要程度较高的线程的执行速度。为了解决上述问题，在执行步骤S908之后，第一线程生成第二信息，该第二信息用于指示请求GC锁成功。

第一线程向SGC发送第二信息和第二标识。

步骤S1010，SGC接收到第二信息，向内核层发送第二标识和第三指示信息。

第三指示信息用于指示降低第三线程的线程优先级。SGC向内核层发送第二标识和该第三指示信息，以指示内核层降低第三线程的线程优先级。

在一些实施例中，第三指示信息包括线程优先级的具体等级，该具体等级可以为低于第三线程当前的线程优先级(即基于步骤S906提高后的线程优先级)的任一等级。该具体等级也可以为第三线程的原线程优先级(即基于步骤S906提高线程优先级之前的线程优先级)。

步骤S1011，内核层根据第二标识和第三指示信息，降低第三线程的线程优先级。

内核层根据第二标识确定对应的线程，即第三线程。并将第三线程的线程优先级调整为第三指示信息中的具体等级，以降低第三线程的线程优先级。

例如：如果第三指示信息指示低于第三线程当前的线程优先级的任一等级，内核层将第三线程的线程优先级降低至该等级。

又如：如果第三指示信息指示第三线程的原线程优先级，内核层将第三线程的线程优先级恢复至提高前的等级。

第三线程的线程优先级降低之后，CPU将减少为第三线程调度的资源，从而为其它线程预留出更多的资源，以满足其它重要程度更高的线程对资源的需求，提高资源调度的合理性。

示例2

结合示例2对本申请实施例2提供的GC的守护线程的管理方法1000进行进一步说明。

以应用程序为阅读应用，第一线程为Heap线程，第二线程为插件加载线程，插件加载线程的线程标识为“25265”，第三线程的线程标识为“25265”为例。与示例1的区别在于，Heap线程向插件加载线程分配GC锁之后，Heap线程生成第二信息，如“请求GC锁成功”。Heap线程向SGC发送“请求GC锁成功”和“25265”。SGC接收到“请求GC锁成功”之后，确定第三线程执行完毕，即需要降低第三线程的线程优先级。SGC生成第三指示信息，以指示降低第三线程的线程优先级。以将第三线程的优先级恢复至提高优先级之前的线程优先级为例，第三指示信息为“124”。SGC向内核层发送“25265”和“124”。内核层根据“25265”确定第三线程为线程标识“25265”对应的GC的守护线程。内核层根据“124”，将第三线程的线程优先级从“50”降低(恢复)至“124”。

实施例3

实施例3与实施例1的区别在于，如果SGC确定应用程序的运行场景不是目标场景，无需提高第三线程的线程优先级，从而避免第三线程额外占用资源影响为其它线程调度的资源。

图11为本申请实施例提供的一种GC的守护线程的管理方法1100。该方法1100包括：步骤S1101-步骤S1108，其中，步骤S1101-步骤S1104与步骤S901-步骤S904相类似，步骤S1107-步骤S1108与步骤S907-步骤S908相类似，此处不再赘述。对步骤S1105-步骤S1108做出具体说明：

步骤S1105，如果应用程序的运行场景不是目标场景，SGC向内核层发送第二标识和第二指示信息。

如果SGC确定应用程序的运行场景不是目标场景，当第二线程等待执行时，应用程序无响应不会被用户感知，即用户不会感知到应用程序的卡顿，不会影响用户的体验感，或者对用户的体验感影响较小。也就是说，即使第三线程的执行速度较慢，令执行第二线程的等待时间较长，导致应用程序长时间无响应，也不会影响用户的体验感，也就无需提高第三线程的执行速度，即无需提高第三线程的线程优先级。由此，SGC在确定应用程序的运行场景不是目标场景时，向内核层发送第二标识和第二指示信息。

其中，SGC根据应用程序的运行场景不是目标场景的判断结果，生成第二指示信息，该第二指示信息用于指示使用第三线程当前的线程优先级。SGC向内核层发送第二标识和该第二指示信息，以指示内核层使用第三线程当前的线程优先级，即内核层无需调整第三线程的线程优先级。

在一些实施例中，SGC可以向内核层发送第二标识和第二指示信息，该第二指示信息包括线程优先级的具体等级，该具体等级为第三线程当前的线程优先级。

步骤S1106，内核层根据第二标识和第二指示信息，使用第三线程当前的线程优先级。

在应用程序的运行场景不是目标场景时，无需提高第三线程的线程优先级，也即无需为第三线程调度更多的资源，避免第三线程占用过多的资源，从而保证其他线程所能够调度的资源，以保证其他线程的执行速度。

示例3

结合示例3对本申请实施例3提供的GC的守护线程的管理方法1100进行进一步说明。

以应用程序为阅读应用，第一线程为Heap线程，第二线程为插件加载线程，插件加载线程的线程标识为“25265”，第三线程的线程标识为“25265”为例。与示例1的区别在于，如果SGC确定阅读应用在前台运行，SGC生成第二指示信息，以指示内核层使用第三线程当前的线程优先级，即无需调整第三线程的线程优先级。基于示例1，第三线程当前使用的线程优先级为“124”为例，第二指示信息为“124”。SGC向内核层发送“25265”和“124”。内核层根据“25265”确定第三线程为线程标识“25265”对应的GC的守护线程。内核层根据“124”，将第三线程的线程优先级调整至“124”。由于第三线程当前的线程优先级为“124”，内核层调整后的第三线程仍使用原线程优先级，相当于未对第三线程的线程优先级做出调整，即沿用第三线程当前的线程优先级。

阅读应用在加载插件时，如果正在执行GC的守护线程，当SGC确定阅读应用在后台运行时，即使GC的守护线程的执行速度较慢，由于阅读应用不会被用户感知，阅读应用无响应也不会影响用户的体验感，SGC向内核层发送第二指示信息，以指示内核层使用GC的守护线程当前的线程优先级，CPU无需为GC的守护线程额外调度更多的资源，从而可以为其它线程预留更多可调度的资源。

在其它示例中，例如应用程序在其它需要申请GC锁的情况下，均可以按照方法1100，准确确定无需提高第三线程的线程优先级的场景，从而避免第三线程额外占用资源影响为其它线程调度的资源。

实施例4

图12为本申请的实施例4提供的一种GC的守护线程的管理方法1200。该方法1200可以应用于如图8所示的电子设备800。结合步骤S301-S304，以及图6-7，在执行步骤S304之后，开始执行第三线程，当第三线程进入清理弱引用对象的阶段时，基于该方法1200，可以通过提高第三线程的线程优先级，加快清理弱引用对象的速度，从而缩短JNI、Binder等调用弱引用对象的阻塞时间。该方法1200包括步骤S1201-步骤S1204：

步骤S1201，第三线程向SGC发送第二标识。

SGC可以参考步骤S903中的描述，此处不再赘述。

当第三线程(即GC的守护线程)进入清理弱引用对象的阶段，第三线程向SGC发送第三线程的线程标识，即第二标识。

步骤S1202，SGC根据第二标识确定应用程序的运行场景是否为目标场景。

SGC根据第二标识可以确定应用程序的运行场景，进而确定该运行场景是否为目标场景。例如：SGC根据第二标识可以确定与第三线程具有调用关系的线程，其中，该调用关系是指调用弱引用对象。如果SGC确定存在与第三线程具有调用关系的线程，确定该线程所属的应用程序的运行场景。可以参考步骤S904中对目标场景的描述，以目标场景为在前台运行为例。如果应用程序在前台运行，应用程序的运行场景是目标场景。如果应用程序在后台运行，应用程序的运行场景不是目标场景。

在一些实施例中，与第三线程具有调用关系的线程，可以为插件加载线程，即应用程序在加载插件的过程中需要调用弱引用对象。与第三线程具有调用关系的线程，还可以为应用程序中其它通过JNI、Binder等调用弱引用对象的线程，此处不做限制。

步骤S1203，如果应用程序的运行场景是目标场景，SGC向内核层发送第二标识和第四指示信息。

由上文对GC的守护线程的描述可知，当GC的守护线程处于清理弱引用对象的阶段时，JNI、Binder等无法调用这些弱引用对象，由此会造成JNI、Binder等的调用阻塞，进而导致应用程序无响应。

以目标场景为在前台运行为例，如果SGC确定应用程序在前台运行，应用程序的无响应将被用户感知，影响用户的体验感。由此，如果第三线程清理弱引用对象的时间较长，将导致JNI、Binder等长时间无法调用弱引用对象，从而导致应用程序长时间无响应。为了解决该问题，SGC可以在确定应用程序的运行场景是目标场景之后，指示内核层提高第三线程的线程优先级。

SGC在确定应用程序的运行场景是目标场景之后，生成第四指示信息，该第四指示信息用于指示提高第三线程的线程优先级。SGC向内核层发送该第四指示信息和第二标识，以指示内核层提高第三线程的线程优先级。

在一些实施例中，SGC可以向内核层发送第二标识和第四指示信息，该第四指示信息包括线程优先级的具体等级，该具体等级高于第三线程当前的线程优先级。

步骤S1204，内核层根据第二标识和第四指示信息，提高第三线程的线程优先级。

内核层可以根据第二标识确定对应的线程，即第三线程。并将第三线程的线程优先级调整为第四指示信息中的具体等级，以提高第三线程的线程优先级。

第三线程的线程优先级提高之后，CPU将为第三线程调度更多的资源。具体的，CPU将为第三线程清理弱引用对象的阶段调度更多的资源，第三线程清理弱引用对象的速度加快，从而有效缩短第三线程清理弱引用对象的时间，进而有效缩短JNI、Binder等调用弱引用对象的阻塞时间，以有效提高应用程序的响应速度，提高用户的体验感。

示例4

结合示例4对本申请实施例4提供的GC的守护线程的管理方法1200进行进一步说明。

以应用程序为社交应用，该社交应用在运行时通过JNI、Binder等调用弱引用对象，应用程序的主线程的线程标识为“4362”，第一线程为Heap线程，第三线程的线程标识为“4384”为例。第三线程进入清理弱引用对象的阶段之后，向SGC发送“4384”。SGC根据“4384”确定与第三线程(即GC的守护线程)相关联的应用程序的运行场景是否为目标场景。其中，SGC根据“4384”确定与第三线程具有调用关系的线程，即调用第三线程所清理的弱引用对象的线程。例如：SGC确定线程标识为“4362”的主线程，并进一步根据“4362”确定该主线程对应的社交应用在前台运行。如果目标场景为在前台运行，该社交应用的运行场景是目标场景。SGC确定社交应用在前台运行之后，生成第四指示信息，如线程优先级更高的“50”。SGC向内核层发送“4384”和“50”。内核层根据“4384”确定第三线程为线程标识“4384”对应的GC的守护线程。如果第三线程当前的线程优先级为“124”，内核层根据“50”，将第三线程的线程优先级从“124”提高至“50”。

表2为第三线程的线程优先级在提高前后，清理弱引用对象的运行状态参数。

表2

可以通过清理弱引用对象的实际时间(cpu-time)/(清理弱引用对象的总时间(run-time)+清理弱引用对象的实际时间)表征第三线程中清理弱引用对象的执行速度，其中，该比值越大，清理弱引用对象的执行速度越快。根据表2，第三线程的线程优先级在提高之后的执行速度显著高于提高之前的执行速度，即在第三线程的线程优先级提高之后，CPU将为第三线程中清理弱引用对象的阶段调度更多的资源，第三线程清理弱引用对象的执行速度将显著提高。

执行GC的守护线程的过程中，当GC的守护线程进入清理弱引用对象的阶段，SGC确定与GC的守护线程具有关联关系的社交应用在前台运行时，SGC向内核层发送第四指示信息，以指示内核层提高GC的守护线程的线程优先级，令CPU为GC的守护线程中清理弱引用对象的阶段调度更多的资源，以加快清理弱引用对象的速度，从而缩短清理弱引用对象的时间，缩短社交应用中JNI、Binder等调用弱引用对象的阻塞时间，以有效提高社交应用的响应速度，提高用户的体验感。

实施例5

基于实施例4，在第三线程执行清理弱引用对象的阶段完毕之后，恢复第三线程的线程优先级，以降低为第三线程调度的资源，从而可以释放为清理弱引用对象的阶段额外调度的资源，以为其它线程预留更多可调度的资源，提高资源调度的合理性。

图13为本申请实施例提供的一种GC的守护线程的管理方法1300。该方法1300包括：步骤S1301-步骤S1307，其中，步骤S1301-步骤S1304与步骤S1201-步骤S1204相类似，此处不再赘述。对步骤S1305-步骤S1307做出具体说明：

步骤S1305，第三线程向SGC发送第三信息和第二标识。

内核层提高第三线程的线程优先级之后，CPU将按照该较高的线程优先级为第三线程中清理弱引用对象的阶段分配资源。但是，由于第三线程在多数情况下相较于其他线程的重要程度较低，如果为第三线程分配过多的资源，其它重要程度更高的线程将被分配到较少的资源，从而降低这些重要程度较高的线程的执行速度。为了解决上述问题，第三线程在弱引用对象清理完毕之后，向SGC发送第三信息和第二标识，该第三信息用于指示弱引用对象清理完毕。

步骤S1306，SGC接收到第三信息，向内核层发送第二标识和第五指示信息。

第五指示信息用于指示降低第三线程的线程优先级。SGC向内核层发送第二标识和该第五指示信息，以指示内核层降低第三线程的线程优先级。

其中，第五指示信息的内容可以参考第三指示信息，此处不再赘述。

步骤S1307，内核层根据第二标识和第五指示信息，降低第三线程的线程优先级。

内核层根据第二标识确定对应的线程，即第三线程。并将第三线程的线程优先级调整为第五指示信息中的具体等级，以降低第三线程的线程优先级。步骤S1707与步骤S1111相类似，此处不再赘述。

第三线程的线程优先级降低之后，CPU将减少为第三线程中清理弱引用对象的阶段调度的资源，从而为其它线程预留出更多的资源，以满足其它重要程度更高的线程对资源的需求，提高资源调度的合理性。

示例5

结合示例5对本申请实施例5提供的GC的守护线程的管理方法1300进行进一步说明。

以应用程序为社交应用，该社交应用在运行时通过JNI、Binder等调用弱引用对象，应用程序的主线程的线程标识为“4362”，第一线程为Heap线程，第三线程的线程标识为“4384”为例。与示例4的区别在于，第三线程在弱引用对象清理完毕之后，生成第三信息，该第三信息用于指示弱引用对象清理完毕，如“弱引用对象清理完毕”。第三线程向SGC发送“弱引用对象清理完毕”和“4384”。SGC接收到“弱引用对象清理完毕”之后，确定第三线程执行弱引用对象清理完毕，即需要降低第三线程的线程优先级。SGC生成第五指示信息，以指示降低第三线程的线程优先级。以将第三线程的优先级恢复至提高优先级之前的线程优先级为例，基于示例4，第三线程的原线程优先级为“124”，第五指示信息可以为“124”。SGC向内核层发送“4384”和“124”。内核层根据“4384”确定第三线程为线程标识“4384”对应的GC的守护线程。内核层根据“124”，将第三线程的线程优先级从“50”降低至“124”。

实施例6

实施例6与实施例4的区别在于，如果SGC确定应用程序的运行场景不是目标场景，无需提高第三线程的线程优先级，从而避免第三线程额外占用资源影响为其它线程调度的资源。

图14为本申请实施例提供的一种GC的守护线程的管理方法1400。该方法1400包括：步骤S1401-步骤S1404，其中，步骤S1401-步骤S1402与步骤S1201-步骤S1202相类似，此处不再赘述。对步骤S1403-步骤S1404做出具体说明：

步骤S1403，如果应用程序的运行场景不是目标场景，SGC向内核层发送第二标识和第六指示信息。

如果SGC确定应用程序的运行场景不是目标场景，当应用程序中的JNI、Binder等调用弱引用对象阻塞时，应用程序无响应不会被用户感知，即用户不会感知到应用程序的卡顿，不会影响用户的体验感，或者对用户的体验感影响较小。也就是说，即使第三线程执行清理弱引用对象的速度较慢，令JNI、Binder等调用弱引用对象的阻塞时间较长，导致应用程序长时间无响应，也不会影响用户的体验感，也就无需提高第三线程的执行速度，即无需提高第三线程的线程优先级。由此，SGC在确定应用程序的运行场景不是目标场景时，向内核层发送第二标识和第六指示信息。

其中，SGC根据应用程序的运行场景不是目标场景的判断结果，生成第六指示信息，该第六指示信息用于指示使用第三线程当前的线程优先级。SGC向内核层发送第二标识和该第六指示信息，以指示内核层使用第三线程当前的线程优先级，即内核层无需调整第三线程的线程优先级。

在一些实施例中，SGC可以向内核层发送第二标识和第六指示信息，该第六指示信息包括线程优先级的具体等级，该具体等级为第三线程当前的线程优先级。

步骤S1404，内核层根据第二标识和第六指示信息，使用第三线程当前的线程优先级。

在应用程序的运行场景不是目标场景时，无需提高第三线程的线程优先级，也即无需为第三线程调度更多的资源，避免第三线程占用过多的资源，从而保证其他线程所能够调度的资源，以保证其他线程的执行速度。

示例6

结合示例6对本申请实施例6提供的GC的守护线程的管理方法1400进行进一步说明。

以应用程序为社交应用，该社交应用在运行时通过JNI、Binder等调用弱引用对象，应用程序的主线程的线程标识为“4362”，第一线程为Heap线程，第三线程的线程标识为“4384”为例。与示例4的区别在于，如果SGC确定应用程序的运行场景不是目标场景，SGC生成第六指示信息，以指示内核层使用第三线程当前的线程优先级，即无需调整第三线程的线程优先级。基于示例4，如果第三线程当前使用的线程优先级为“124”，第六指示信息为“124”。SGC向内核层发送“4384”和“124”。内核层根据“4384”确定第三线程为线程标识“4384”对应的GC的守护线程。内核层根据“124”，将第三线程的线程优先级调整至“124”。由于第三线程当前的线程优先级为“124”，内核层调整后的第三线程仍使用原线程优先级，相当于未对第三线程的线程优先级做出调整，即沿用第三线程当前的线程优先级。

在执行GC的守护线程的过程中，当GC的守护线程进入清理弱引用对象的阶段，如果SGC确定与清理弱引用对象的阶段有关联的社交应用在后台运行，即使清理弱引用对象的速度较慢，由于社交应用不会被用户感知，社交应用无响应也就不会影响用户的体验感，SGC向内核层发送第六指示信息，以指示内核层使用GC的守护线程当前的线程优先级，CPU无需为GC的守护线程额外调度更多的资源，从而可以为其它线程预留更多可调度的资源。

上述主要从电子设备的角度对本申请实施例提供的方案进行了介绍。可以理解的是，电子设备为了实现上述功能，其包含了执行各个功能相应的硬件结构和/或软件模块。本领域技术人员应该很容易意识到，结合本申请所公开的实施例描述的各示例的垃圾回收的守护线程的管理方法的步骤，本申请能够以硬件或硬件和计算机软件的结合形式来实现。某个功能究竟以硬件还是电子设备软件驱动硬件的方式来执行，取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本申请的范围。

本申请实施例可以根据上述方法示例对上述电子设备进行功能模块或者功能单元的划分，例如，可以对应各个功能划分各个功能模块或者功能单元，也可以将两个或两个以上的功能集成在一个处理模块中。上述集成的模块既可以采用硬件的形式实现，也可以采用软件功能模块或者功能单元的形式实现。其中，本申请实施例中对模块或者单元的划分是示意性的，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式。

在一些实施例中，电子设备的硬件结构可以如图15所示。电子设备可以包括：显示屏1501、存储器1502、处理器1503和通信模块1504。上述各器件可以通过一个或多个通信总线1505连接。显示屏1501可以包括显示面板15011和触摸传感器15012，其中，显示面板15011用于显示图像，触摸传感器15012可以将检测到的触摸操作传递给应用处理器，以确定触摸事件类型，通过显示面板15011提供与触摸操作相关的视觉输出。处理器1503可以包括一个或多个处理单元，例如：处理器1503可以包括应用处理器，调制解调处理器，图形处理器，图像信号处理器，控制器，视频编解码器，数字信号处理器，基带处理器，和/或神经网络处理器等。其中，不同的处理单元可以是独立的器件，也可以集成在一个或多个处理器中。存储器1502与处理器1503耦合，用于存储各种软件程序和/或计算机指令，存储器1502可包括易失性存储器和/或非易失性存储器。当处理器1503执行计算机指令时，电子设备可执行与下述各实施例中的方法对应的各个功能或者步骤。

在一些实施例中，电子设备的软件结构可以如图16所示。电子设备可以包括：第一接收模块1601，用于第一线程接收第二线程发送的第一请求。该第一线程用于管理应用程序所占用的内存，该第二线程为应用程序当前运行的线程，该第一请求用于请求垃圾回收GC锁。第一识别模块1602，用于第一线程响应于第一请求，确定GC锁是否被第三线程占用，该第三线程为GC的守护线程。第一发送模块1603，用于如果第三线程占用GC锁，第一线程向低暂停时间垃圾收集器SGC发送第一信息、第一标识和第二标识。其中，SGC与应用程序对应，第一信息用于指示请求GC锁失败，该第一标识为第二线程的标识，该第二标识为第三线程的标识。第二识别模块1604，用于SGC接收到第一信息，根据第一标识确定应用程序的运行场景是否为目标场景。第二发送模块1605，用于如果应用程序的运行场景为目标场景，SGC向内核层发送第二标识和第一指示信息，第一指示信息用于指示内核层提高第三线程的线程优先级。

本申请实施例还提供一种芯片系统，该芯片系统包括至少一个处理器和至少一个接口电路。处理器和接口电路可通过线路互联。例如，接口电路可用于从其它装置(例如控制设备的存储器)接收信号。又例如，接口电路可用于向其它装置发送信号。示例性的，接口电路可读取存储器中存储的指令，并将该指令发送给处理器。当所述指令被处理器执行时，可使得控制设备执行上述实施例中的各个步骤。当然，该芯片系统还可以包含其他分立器件，本申请实施例对此不作具体限定。

本申请实施例还提供一种计算机可读存储介质，该计算机可读存储介质包括计算机指令，当所述计算机指令在上述电子设备(如图8所示的电子设备800)上运行时，使得该电子设备执行上述方法实施例中执行的各个功能或者步骤。

本申请实施例还提供一种计算机程序产品，当所述计算机程序产品在计算机上运行时，使得所述计算机执行上述方法实施例中控制设备执行的各个功能或者步骤。

通过以上实施方式的描述，所属领域的技术人员可以清楚地了解到，为描述的方便和简洁，仅以上述各功能模块的划分进行举例说明，实际应用中，可以根据需要而将上述功能分配由不同的功能模块完成，即将装置的内部结构划分成不同的功能模块，以完成以上描述的全部或者部分功能。

在本申请所提供的几个实施例中，应该理解到，所揭露的装置和方法，可以通过其它的方式实现。例如，以上所描述的装置实施例仅仅是示意性的，例如，所述模块或单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个装置，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，装置或单元的间接耦合或通信连接，可以是电性，机械或其它的形式。

所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是一个物理单元或多个物理单元，即可以位于一个地方，或者也可以分布到多个不同地方。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。

另外，在本申请各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现，也可以采用软件功能单元的形式实现。

所述集成的单元如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个可读取存储介质中。基于这样的理解，本申请实施例的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的全部或部分可以以软件产品的形式体现出来，该软件产品存储在一个存储介质中，包括若干指令用以使得一个设备(可以是单片机，芯片等)或处理器(processor)执行本申请各个实施例所述方法的全部或部分步骤。而前述的存储介质包括：U盘、移动硬盘、只读存储器(read only memory，ROM)、随机存取存储器(random access memory，RAM)、磁碟或者光盘等各种可以存储程序代码的介质。

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

Claims (16)

1.一种垃圾回收的守护线程的管理方法，其特征在于，所述方法包括：

第一线程接收第二线程发送的第一请求，所述第一线程用于管理应用程序所占用的内存，所述第二线程为应用程序当前运行的线程，所述第一请求用于请求垃圾回收GC锁；

所述第一线程响应于所述第一请求，确定所述GC锁是否被第三线程占用，所述第三线程为GC的守护线程；

如果所述第三线程占用所述GC锁，所述第一线程向低暂停时间垃圾收集器SGC发送第一信息、第一标识和第二标识，其中，所述SGC与所述应用程序对应，所述第一信息用于指示请求所述GC锁失败，所述第一标识为所述第二线程的标识，所述第二标识为所述第三线程的标识；

所述SGC接收到所述第一信息，根据所述第一标识确定所述应用程序的运行场景是否为目标场景，所述目标场景为所述应用程序对于用户的响应可以被用户所感知；

如果所述应用程序的运行场景为所述目标场景，所述SGC向内核层发送所述第二标识和第一指示信息，所述第一指示信息用于指示所述内核层提高所述第三线程的线程优先级。

2.根据权利要求1所述的方法，其特征在于，所述第二线程为用于加载所述应用程序的插件的线程。

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

所述第一线程在所述应用程序启动之后初始化，并创建与所述应用程序对应的所述SGC。

4.根据权利要求1或2所述的方法，其特征在于，所述第一线程接收第二线程发送的第一请求之前，所述管理方法还包括：

所述第一线程接收所述应用程序发送的第二请求，所述第二请求用于请求系统内存；

所述第一线程响应于所述第二请求，向所述应用程序分配第一内存；

所述第一线程确定所述应用程序所占用的第二内存是否到达GC水线，所述GC水线是根据所述第一内存确定的；

如果所述第二内存到达所述GC水线，所述第一线程启动所述第三线程，并为所述第三线程分配所述GC锁；

如果所述第二内存未到达所述GC水线，所述第一线程不启动所述第三线程。

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

如果所述应用程序的运行场景不是所述目标场景，所述SGC向所述内核层发送所述第二标识和第二指示信息，所述第二指示信息用于指示所述内核层使用所述第三线程当前的线程优先级。

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

所述第一线程接收所述第三线程释放的所述GC锁；

所述第一线程向所述SGC发送第二信息和所述第二标识，所述第二信息用于指示请求所述GC锁成功；

所述SGC接收到所述第二信息，向所述内核层发送所述第二标识和第三指示信息，所述第三指示信息用于指示所述内核层降低所述第三线程的线程优先级。

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

如果所述第三线程未占用所述GC锁，所述第一线程向所述第二线程分配所述GC锁。

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

所述SGC接收所述第三线程处于清理弱引用对象的阶段时发送的所述第二标识；

所述SGC根据所述第二标识识别所述应用程序的运行场景是否为所述目标场景；

如果所述应用程序的运行场景是所述目标场景，所述SGC向所述内核层发送所述第二标识和第四指示信息，所述第四指示信息用于指示所述内核层提高所述第三线程的线程优先级。

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

所述SGC接收所述第三线程发送的第三信息和所述第二标识，所述第三信息用于指示弱引用对象清理完毕；

所述SGC接收到所述第三信息，向所述内核层发送所述第二标识和第五指示信息，所述第五指示信息用于指示所述内核层降低所述第三线程的线程优先级。

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

如果所述应用程序的运行场景不是所述目标场景，所述SGC向所述内核层发送所述第二标识和第六指示信息，所述第六指示信息用于指示所述内核层使用所述第三线程当前的线程优先级。

11.根据权利要求1、2、8-10中任一所述的方法，其特征在于，所述目标场景为所述应用程序在前台运行。

12.一种垃圾回收的守护线程的管理装置，其特征在于，所述装置包括：

第一接收模块，用于第一线程接收第二线程发送的第一请求，所述第一线程用于管理应用程序所占用的内存，所述第二线程为应用程序当前运行的线程，所述第一请求用于请求垃圾回收GC锁；

第一识别模块，用于所述第一线程响应于所述第一请求，确定所述GC锁是否被第三线程占用，所述第三线程为GC的守护线程；

第一发送模块，用于如果所述第三线程占用所述GC锁，所述第一线程向低暂停时间垃圾收集器SGC发送第一信息、第一标识和第二标识，其中，所述SGC与所述应用程序对应，所述第一信息用于指示请求所述GC锁失败，所述第一标识为所述第二线程的标识，所述第二标识为所述第三线程的标识；

第二识别模块，用于所述SGC接收到所述第一信息，根据所述第一标识确定所述应用程序的运行场景是否为目标场景，所述目标场景为所述应用程序对于用户的响应可以被用户所感知；

第二发送模块，用于如果所述应用程序的运行场景为所述目标场景，所述SGC向内核层发送所述第二标识和第一指示信息，所述第一指示信息用于指示所述内核层提高所述第三线程的线程优先级。

13.一种电子设备，其特征在于，包括：处理器和存储器；所述存储器存储有程序指令，当所述程序指令被所述处理器执行时，使得所述电子设备执行权利要求1-11中任一项所述的方法。

14.一种芯片系统，其特征在于，包括：存储器和处理器；所述存储器存储有程序指令，当所述程序指令被所述处理器执行时，使得所述芯片系统执行权利要求1-11中任一项所述的方法。

15.一种计算机存储介质，其特征在于，所述计算机可读存储介质中存储有程序指令，当所述程序指令在计算机上运行时，使得计算机执行权利要求1-11中任一项所述的方法。

16.一种计算机程序产品，其特征在于，当其在计算机上运行时，使得计算机执行权利要求1-11中任一项所述的方法。