具体实施方式

为了使本申请的目的、技术方案和优点更加清楚，下面将结合附图对本申请作进一步地详细描述，所描述的实施例不应视为对本申请的限制，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其它实施例，都属于本申请保护的范围。

在以下的描述中，涉及到“一些实施例”，其描述了所有可能实施例的子集，但是可以理解，“一些实施例”可以是所有可能实施例的相同子集或不同子集，并且可以在不冲突的情况下相互结合。

在以下的描述中，所涉及的术语“第一\第二\第三”仅仅是是区别类似的对象，不代表针对对象的特定排序，可以理解地，“第一\第二\第三”在允许的情况下可以互换特定的顺序或先后次序，以使这里描述的本申请实施例能够以除了在这里图示或描述的以外的顺序实施。

除非另有定义，本文所使用的所有的技术和科学术语与属于本申请的技术领域的技术人员通常理解的含义相同。本文中所使用的术语只是为了描述本申请实施例的目的，不是旨在限制本申请。

对本申请实施例进行进一步详细说明之前，对本申请实施例中涉及的名词和术语进行说明，本申请实施例中涉及的名词和术语适用于如下的解释。

1)客户端，终端中运行的用于提供各种服务的应用程序，例如即时通讯客户端、视频播放客户端。

2)响应于，用于表示所执行的操作所依赖的条件或者状态，当满足所依赖的条件或状态时，所执行的一个或多个操作可以是实时的，也可以具有设定的延迟；在没有特别说明的情况下，所执行的多个操作不存在执行先后顺序的限制。

3)垂直同步：为了让系统绘制UI的频率与屏幕硬件的刷新率一致，Android的绘制系统引入了VSYNC(垂直同步)的概念。比如在屏幕刷新率为60Hz的手机上，Android系统会每隔1/60秒发送一个VSYNC信号，当绘制模块接受到信号后，就会将已经绘制完成的画面发送到屏幕上。如果每一帧的绘制周期(绘制一帧所需要的CPU耗时+GPU耗时)都小于1/60秒，就能够保证屏幕每次刷新都能及时的将最新的内容投放到屏幕上。否则，就会造成卡顿。

基于上述对本申请实施例中涉及的名词和术语的解释，下面说明本申请实施例提供的应用程序的画面处理系统。参见图1，图1是本申请实施例提供的应用程序的画面处理系统100的架构示意图，为实现支撑一个示例性应用，终端(示例性示出了终端400-1)通过网络300连接服务器200，网络300可以是广域网或者局域网，又或者是二者的组合，使用无线或有线链路实现数据传输。

终端(如终端400-1)，用于发送针对应用程序的各级画面处理单元所对应的画面处理时长的获取请求至服务器200；

服务器200，用于接收并响应于获取请求，返回针对应用程序的各级画面处理单元所对应的画面处理时长至终端；

终端(如终端400-1)，用于接收到应用程序的各级画面处理单元所对应的画面处理时长，并获取应用程序的画面刷新时间间隔；基于各级画面处理单元对应的画面处理时长和画面刷新时间间隔，确定应用程序输出目标画面帧所需的缓冲帧队列的队列长度、以及各级画面处理单元对应的目标画面处理时长；基于队列长度和各级画面处理单元对应的目标画面处理时长，通过各级画面处理单元输出目标画面帧。

这里，该画面处理时长为，相应画面处理单元对应应用程序输出画面帧所需的最大处理时长。

在实际应用中，服务器200可以是独立的物理服务器，也可以是多个物理服务器构成的服务器集群或者分布式系统，还可以是提供云服务、云数据库、云计算、云函数、云存储、网络服务、云通信、中间件服务、域名服务、安全服务、CDN、以及大数据和人工智能平台等基础云计算服务的云服务器。终端(如终端400-1)可以是智能手机、平板电脑、笔记本电脑、台式计算机、智能音箱、智能电视、智能手表等，但并不局限于此。终端(如终端400-1和终端400-2)以及服务器200可以通过有线或无线通信方式进行直接或间接地连接，本申请在此不做限制。

参见图2，图2是本申请实施例提供的实施应用程序的画面处理方法的电子设备500的结构示意图。在实际应用中，电子设备500可以为图1示出的服务器或终端，以电子设备500为图1示出的终端为例，对实施本申请实施例的应用程序的画面处理方法的电子设备进行说明，本申请实施例提供的电子设备500包括：至少一个处理器510、存储器550、至少一个网络接口520和用户接口530。电子设备500中的各个组件通过总线系统540耦合在一起。可理解，总线系统540用于实现这些组件之间的连接通信。总线系统540除包括数据总线之外，还包括电源总线、控制总线和状态信号总线。但是为了清楚说明起见，在图2中将各种总线都标为总线系统540。

处理器510可以是一种集成电路芯片，具有信号的处理能力，例如通用处理器、数字信号处理器(DSP，Digital Signal Processor)，或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件等，其中，通用处理器可以是微处理器或者任何常规的处理器等。

用户接口530包括使得能够呈现媒体内容的一个或多个输出装置531，包括一个或多个扬声器和/或一个或多个视觉显示屏。用户接口530还包括一个或多个输入装置532，包括有助于用户输入的用户接口部件，比如键盘、鼠标、麦克风、触屏显示屏、摄像头、其他输入按钮和控件。

存储器550可以是可移除的，不可移除的或其组合。示例性的硬件设备包括固态存储器，硬盘驱动器，光盘驱动器等。存储器550可选地包括在物理位置上远离处理器510的一个或多个存储设备。

存储器550包括易失性存储器或非易失性存储器，也可包括易失性和非易失性存储器两者。非易失性存储器可以是只读存储器(ROM，Read Only Me mory)，易失性存储器可以是随机存取存储器(RAM，Random Access Memor y)。本申请实施例描述的存储器550旨在包括任意适合类型的存储器。

在一些实施例中，存储器550能够存储数据以支持各种操作，这些数据的示例包括程序、模块和数据结构或者其子集或超集，下面示例性说明。

操作系统551，包括用于处理各种基本系统服务和执行硬件相关任务的系统程序，例如框架层、核心库层、驱动层等，用于实现各种基础业务以及处理基于硬件的任务；

网络通信模块552，用于经由一个或多个(有线或无线)网络接口520到达其他计算设备，示例性的网络接口520包括：蓝牙、无线相容性认证(WiFi)、和通用串行总线(USB，Universal Serial Bus)等；

呈现模块553，用于经由一个或多个与用户接口530相关联的输出装置531(例如，显示屏、扬声器等)使得能够呈现信息(例如，用于操作外围设备和显示内容和信息的用户接口)；

输入处理模块554，用于对一个或多个来自一个或多个输入装置532之一的一个或多个用户输入或互动进行检测以及翻译所检测的输入或互动。

在一些实施例中，本申请实施例提供的应用程序的画面处理装置可以采用软件方式实现，图2示出了存储在存储器550中的应用程序的画面处理装置555，其可以是程序和插件等形式的软件，包括以下软件模块：获取模块5551、确定模块5552和输出模块5553，这些模块是逻辑上的，因此根据所实现的功能可以进行任意的组合或进一步拆分，将在下文中说明各个模块的功能。

在另一些实施例中，本申请实施例提供的应用程序的画面处理装置可以采用软硬件结合的方式实现，作为示例，本申请实施例提供的应用程序的画面处理装置可以是采用硬件译码处理器形式的处理器，其被编程以执行本申请实施例提供的应用程序的画面处理方法，例如，硬件译码处理器形式的处理器可以采用一个或多个应用专用集成电路(ASIC，Application Specific Integrated Cir cuit)、DSP、可编程逻辑器件(PLD，ProgrammableLogic Device)、复杂可编程逻辑器件(CPLD，Complex Programmable Logic Device)、现场可编程门阵列(FPGA，Field-Programmable Gate Array)或其他电子元件。

基于上述对本申请实施例提供的应用程序的画面处理系统及电子设备的说明，下面说明本申请实施例提供的应用程序的画面处理方法。在一些实施例中，本申请实施例提供的应用程序的画面处理方法可由服务器或终端单独实施，或由服务器及终端协同实施，下面以终端实施为例说明本申请实施例提供的应用程序的画面处理方法。参见图3，图3是本申请实施例提供的应用程序的画面处理方法的流程示意图，本申请实施例提供的应用程序的画面处理方法包括：

步骤101：终端获取应用程序的各级画面处理单元所对应的画面处理时长、以及应用程序的画面刷新时间间隔。

其中，该画面处理时长为，相应画面处理单元对应应用程序输出画面帧所需的最大处理时长。

这里，终端安装有应用程序，在应用程序运行时，通过终端的显示屏幕显示应用程序输出的画面帧。在实际应用中，终端屏幕刷新显示的画面帧与屏幕刷新时间间隔相关，比如在屏幕刷新率为60Hz的手机终端，其对应的屏幕刷新时间间隔为1/60秒，终端每隔1/60秒会将渲染完成的画面帧发送至屏幕进行显示。在实际实施时，终端通过应用程序对应的各级画面处理单元进行画面帧的计算、渲染、输出等处理，不同的画面处理单元对应的处理操作是不同的，所对应的画面处理时长也是不同的。

在本申请实施例中，对画面处理单元对应应用程序输出画面帧所需的画面处理时长进行获取，以基于该画面处理时长，对画面处理单元对应应用程序输出画面帧所需的目标画面处理时长进行计算，以保证在输出画面帧时，每个画面帧都可以按照设定的时长内(比如屏幕刷新时间间隔内)输出。因此，该画面处理时长为，相应画面处理单元对应应用程序输出画面帧所需的最大处理时长。通过该最大处理时长所计算得到画面处理单元对应应用程序输出画面帧所需的目标画面处理时长，可以保证在输出画面帧时，每个画面帧都可以按照设定的时长内(比如屏幕刷新时间间隔内)输出，不会出现卡帧的现象发生。

在终端获取应用程序的各级画面处理单元所对应的画面处理时长后，还需要继续获取应用程序的画面刷新时间间隔，该应用程序的画面刷新时间间隔需要与屏幕刷新时间间隔一致，即可以将屏幕刷新时间间隔作为该应用程序的画面刷新时间间隔。

在一些实施例中，终端可通过如下方式获取应用程序的各级画面处理单元所对应的画面处理时长：分别针对应用程序的各级画面处理单元执行如下处理：对画面处理单元对应应用程序输出画面帧所需的处理时长，进行目标次数的采集；将采集得到的目标次数的处理时长中的最大处理时长，作为画面处理单元所对应的画面处理时长。

这里，终端可分别针对应用程序的各级画面处理单元执行如下处理：预先设置用于采集的目标次数，然后画面处理单元对应应用程序输出画面帧所需的处理时长，进行目标次数的采集；将采集得到的目标次数的处理时长中的最大处理时长，作为画面处理单元所对应的画面处理时长。

在一些实施例中，终端可通过如下方式对画面处理单元对应应用程序输出画面帧所需的处理时长，进行目标次数的采集：

针对目标次数中每次采集执行以下处理：针对非最后一级的画面处理单元，通过目标函数，监听画面处理单元对应的子应用程序运行时的第一时间点、以及画面处理单元的下一级画面处理单元对应的子应用程序运行时的第二时间点；基于第一时间点和第二时间点，确定并采集非最后一级的画面处理单元对应的处理时长；针对最后一级的画面处理单元，通过目标函数，监听画面处理单元对应的子应用程序运行时的第三时间点、以及画面处理单元对应的子应用程序运行结束时的第四时间点；基于第三时间点和第四时间点，确定并采集最后一级的画面处理单元对应的处理时长。

在一些实施例中，终端可通过如下方式实现时间点的监听：通过程序插桩方式，将目标函数，挂载到各级画面处理单元对应应用程序中的目标位置，以通过目标函数，基于目标位置对各级画面处理单元对应的子应用程序运行时的时间点、及运行结束时的时间点进行监听；其中，目标位置，用于指示应用程序中对应各级画面处理单元的子应用程序的起始位置、以及指示对应最后一级画面处理单元的子应用程序的结束位置。

这里，可以在应用程序中对应各级画面处理单元的子应用程序的起始位置、以及指示对应最后一级画面处理单元的子应用程序的结束位置，通过程序插桩的方式，将目标函数(比如hook函数)挂载至应用程序中。从而通过目标函数，基于目标位置对各级画面处理单元对应的子应用程序运行时的时间点、及运行结束时的时间点进行监听。

具体的，参见图6，图6是本申请实施例提供的流水线计时器的处理流程示意图。这里，以操作系统为Android系统为例，Android系统包含四级画面处理单元，通过在各级画面处理单元的的子应用程序的起始位置、以及最后一级画面处理单元的子应用程序的结束位置插桩Hook函数，实现各级画面处理单元对应的处理时长的监听。该各级换处理单元所对应的处理时长分别为：输入采集单元对应的处理时长为T_Input、计算与渲染单元对应的处理时长为T_APP(包括UI thread->Render thread->GPU render)、画面合成单元对应的处理时长为T_SF(SurfaceFlinger)和画面显示单元的处理时长为T_DISP(Display)。

在实际应用中，在每次画面处理单元的处理时长的采集中，针对非最后一级的画面处理单元，通过目标函数，监听画面处理单元对应的子应用程序运行时的第一时间点、以及画面处理单元的下一级画面处理单元对应的子应用程序运行时的第二时间点；基于第一时间点和第二时间点的差值，确定并采集非最后一级的画面处理单元对应的处理时长；针对最后一级的画面处理单元，通过目标函数，监听画面处理单元对应的子应用程序运行时的第三时间点、以及画面处理单元对应的子应用程序运行结束时的第四时间点；基于第三时间点和第四时间点的差值，确定并采集最后一级的画面处理单元对应的处理时长。

在一些实施例中，应用程序的各级画面处理单元具有相应的初始画面处理时长；终端可通过如下方式获取应用程序的各级画面处理单元所对应的画面处理时长：获取各级画面处理单元的历史画面处理时长超过初始画面处理时长的频率；确定各级画面处理单元中、频率达到频率阈值的画面处理单元为目标画面处理单元；获取目标画面处理单元所对应的画面处理时长。

在实际应用中，终端针对各级画面处理单元，也设置有相应的初始画面处理时长，该初始画面处理时长也可以是终端所配置操作系统(比如安卓系统)默认的，比如以屏幕刷新时间间隔(即HW_VSyncTime)作为各级画面处理单元的初始画面处理时长。

在实际应用中，存在部分画面处理单元的实际处理时长超过初始画面处理时长，也存在部分画面处理单元的实际处理时长未超过初始画面处理时长，针对实际处理时长超过初始画面处理时长的画面处理单元，则需要重新调整其对应的画面处理时长，此时，则可以只获取实际处理时长超过初始画面处理时长的画面处理单元对应的画面处理时长。

具体地，可以获取各级画面处理单元的历史画面处理时长超过初始画面处理时长的频率，比如可以对各级画面处理单元输出画面帧的处理时长进行采集，多次获取各级画面处理单元的历史画面处理时长，然后确定各级画面处理单元的实际处理时长超过初始画面处理时长的次数，从而基于确定的次数与采集的次数确定各级画面处理单元的历史画面处理时长超过初始画面处理时长的频率。然后从各级画面处理单元中、确定频率达到频率阈值的画面处理单元为目标画面处理单元，从而获取该目标画面处理单元所对应的画面处理时长。如此，可以减少硬件处理资源的浪费。

在一些实施例中，终端可通过如下方式获取应用程序的各级画面处理单元所对应的画面处理时长：对应用程序输出的、处于目标时长内的多个画面帧进行卡顿时长检测，确定多个画面帧对应的卡顿总时长；基于卡顿总时长和目标时长，确定应用程序对应的卡顿分数；当卡顿分数达到卡顿分数阈值时，获取应用程序的各级画面处理单元所对应的画面处理时长。

在实际应用中，可以对终端所运行应用程序输出的画面帧进行卡顿检测，该卡顿检测可以是实时的，也可以按照预设的时间间隔进行检测，比如每隔2个小时进行一次检测等，也可以根据终端当前运行的应用程序的变化情况进行检测。当检测到终端显示的画面帧存在卡顿时，则需要调整缓存帧队列的队列长度、以及各级画面处理单元对应的处理时长。此时，则可以获取应用程序的各级画面处理单元所对应的画面处理时长，即最大处理时长。

在实际实施时，可以预先设置检测时长，即上述目标时长。对应用程序输出的、处于目标时长内的多个画面帧进行卡顿时长检测，从而确定该多个画面帧对应的卡顿总时长；然后基于卡顿总时长和目标时长，确定应用程序对应的卡顿分数，具体地，可以计算卡顿总时长和目标时长的比值，将该比值作为应用程序对应的卡顿分数，该卡顿分数可以用于描述目标时长内卡顿画面所占的比例，或者卡顿的概率等；最后当卡顿分数达到卡顿分数阈值时，则获取应用程序的各级画面处理单元所对应的画面处理时长，从而基于获取的各级画面处理单元所对应的画面处理时长，执行后续步骤102-步骤103。

在一些实施例中，终端可通过如下方式确定多个画面帧对应的卡顿总时长：获取应用程序输出各画面帧所需的实际画面处理时长、以及应用程序输出画面帧对应的标准画面处理时长；基于各画面帧所需的实际画面处理时长以及标准画面处理时长，确定各画面帧对应的卡顿时长；基于各画面帧对应的卡顿时长，确定多个画面帧对应的卡顿总时长。

这里，在计算目标时长内多个画面帧对应的卡顿总时长时，可以首先获取应用程序输出各画面帧所需的实际画面处理时长、以及应用程序输出画面帧对应的标准画面处理时长；然后基于各画面帧所需的实际画面处理时长以及标准画面处理时长，确定各画面帧对应的卡顿时长，具体的，计算各画面帧所需的实际画面处理时长以及标准画面处理时长之间的差值，将该差值作为各画面帧对应的卡顿时长；从而基于各画面帧对应的卡顿时长，确定多个画面帧对应的卡顿总时长，具体的，对各画面帧对应的卡顿时长进行求和处理，将求和得到的结果作为多个画面帧对应的卡顿总时长。

在一些实施例中，终端可将应用程序的各级画面处理单元所对应的画面处理时长，存储至区块链网络；相应的，终端可通过如下方式获取应用程序的各级画面处理单元所对应的画面处理时长：生成并发送用于获取区块链网络中各级画面处理单元所对应的画面处理时长的交易；接收区块链网络基于交易返回的各级画面处理单元所对应的画面处理时长。

这里，终端可以将应用程序的各级画面处理单元所对应的画面处理时长，存储于区块链网络中，当需要获取应用程序的各级画面处理单元所对应的画面处理时长时，可以直接从区块链网络中获取。具体地，生成用于获取区块链网络中各级画面处理单元所对应的画面处理时长的交易，并将该交易发送至区块链网络；区块链网络接收到该交易后，返回应用程序的各级画面处理单元所对应的画面处理时长至终端；终端接收区块链网络基于交易返回的各级画面处理单元所对应的画面处理时长。

步骤102：基于各级画面处理单元对应的画面处理时长和画面刷新时间间隔，确定应用程序输出目标画面帧所需的缓冲帧队列的队列长度、以及各级画面处理单元对应的目标画面处理时长。

这里，终端在获取到各级画面处理单元对应的画面处理时长、以及画面刷新时间间隔后，对终端所运行的应用程序输出目标画面帧所需的缓冲帧队列的队列长度、以及各级画面处理单元的目标画面处理时长进行计算，以确定所需的缓冲帧队列的队列长度、以及各级画面处理单元对应的目标画面处理时长。

在一些实施例中，基于各级画面处理单元对应的画面处理时长和画面刷新时间间隔，终端可通过如下方式确定应用程序输出目标画面帧所需的缓冲帧队列的队列长度、以及各级画面处理单元对应的目标画面处理时长：基于各级画面处理单元对应的画面处理时长、及画面刷新时间间隔，确定相应画面处理单元对应的目标画面处理时长；将各级画面处理单元对应的目标画面处理时长进行求和处理，得到求和结果，并基于求和结果及画面刷新时间间隔，确定应用程序输出目标画面帧所需的缓冲帧队列的队列长度。

在实际应用中，终端可基于各级画面处理单元对应的画面处理时长、及画面刷新时间间隔，通过如下公式，确定相应画面处理单元对应的目标画面处理时长：

PLUD_i＝(Floor(PLUT_i-Max/HW_VSyncTime)+1)*HW_VSyncTime；

终端可基于各级画面处理单元对应的目标画面处理时长、及画面刷新时间间隔，通过如下公式，确定应用程序输出目标画面帧所需的缓冲帧队列的队列长度：

BufferQueueLen＝Floor((PLUD₁+PLUD₂+PLUD₃+...PLUD_i)/HW_VSyncTime)；

其中，PLUT_I-Max为第i级画面处理单元内的在预设次数中的运算量测的最大处理时长，Max()为求最大值函数；PLUD_i为第i级画面处理单元对应的目标画面处理时长；Floor()为求整函数；HW_VSyncTime为画面刷新时间间隔；BufferQueuelen为缓冲帧队列的队列长度。

步骤103：基于队列长度和各级画面处理单元对应的目标画面处理时长，通过各级画面处理单元输出目标画面帧。

这里，终端在获取到应用程序输出目标画面帧所需的缓冲帧队列的队列长度、以及各级画面处理单元对应的目标画面处理时长后，基于该队列长度和各级画面处理单元对应的目标画面处理时长，通过各级画面处理单元输出应用程序的目标画面帧。

在一些实施例中，应用程序具有对应缓冲帧队列的初始队列长度、及各级画面处理单元具有相应的初始画面处理时长；终端可通过如下方式基于队列长度和各级画面处理单元对应的目标画面处理时长，通过各级画面处理单元输出目标画面帧：将初始队列长度更新为队列长度，并将各级画面处理单元对应的初始画面处理时长更新为相应的目标画面处理时长；基于更新后的初始队列长度以及各级画面处理单元对应的初始画面处理时长，通过各级画面处理单元输出目标画面帧。

在实际应用中，终端针对所运行的应用程序设置有对应缓存帧队列的初始队列长度，该初始队列长度可以是终端所配置操作系统(比如安卓系统)默认的，比如三缓冲队列长度；同时，针对各级画面处理单元，也设置有相应的初始画面处理时长，该初始画面处理时长也可以是终端所配置操作系统(比如安卓系统)默认的，比如以屏幕刷新时间间隔(即HW_VSyncTime)作为各级画面处理单元的初始画面处理时长。

基于此，终端在获取到应用程序输出目标画面帧所需的缓冲帧队列的队列长度、以及各级画面处理单元对应的目标画面处理时长后，对该初始队列长度和各级画面处理单元对应的初始画面处理时长进行更新。具体地，将初始队列长度更新为确定的队列长度，并将各级画面处理单元对应的初始画面处理时长更新为相应的目标画面处理时长。如此，终端则可以基于更新后的初始队列长度以及各级画面处理单元对应的初始画面处理时长，通过各级画面处理单元输出目标画面帧。

在一些实施例中，各级画面处理单元包括：输入采集单元、计算与渲染单元、画面合成单元以及画面显示单元；

终端可通过如下方式基于队列长度和各级画面处理单元对应的目标画面处理时长，通过各级画面处理单元输出目标画面帧：当输入采集单元检测到输入事件时，在相应的目标画面处理时长内，将输入事件发送至计算与渲染单元；当计算与渲染单元接收到输入事件并检测到第一触发信号时，在相应的目标画面处理时长内，生成与输入事件对应的画面帧图层，并将画面帧图层加入具备队列长度的缓存帧队列中；当画面合成单元检测到第二触发信号时，在相应的目标画面处理时长内，从缓存帧队列中获取目标画面帧图层，并对目标画面帧图层进行图层合成处理，得到目标画面帧，并当画面合成单元检测到第三触发信号时，将目标画面帧发送至画面显示单元；在画面显示单元对应的目标画面处理时长内，通过画面显示单元输出目标画面帧。

这里，该输入事件件包括但不限于屏幕的输入事件、终端设备旋转对应的输入事件以及通过鼠标、键盘及子柄等输入设备输入的输入事件，其中，屏幕的输入事件，包括但不限于通过屏幕传感器检测到点击屏幕、滑动屏幕等触控操作对应的输入事件，终端设备旋转对应的输入事件可以是通过角度传感器检测到终端设备发生旋转时对应的输入事件。

需要说明的是，该第一触发信息可以是应用程序垂直同步信号(即APP_VSync)，用于触发计算与渲染单元执行处理操作；第二触发信号可以是合成垂直同步信号(即SF_VSync)，用于触发画面合成单元执行处理操作，该第三触发信号可以是硬件垂直同步信号，用户触发画面合成单元将合成的画面帧发送至画面显示单元。在实际应用中，该画面帧图层可以包括生成相应画面帧对应的文本、图形、图像、表格等。在实际实施时，由于存在同时运行多个应用程序且终端屏幕中需要同时呈现该多个应用程序的画面时，这里，终端可以获取在该时刻下，所运行的每个应用程序的目标画面帧图层，从而基于获取的目标画面帧图层合成目标画面帧。

在一些实施例中，计算与渲染单元包括界面线程和渲染线程，终端可通过如下方式生成与输入事件对应的画面帧图层，包括：当计算与渲染单元检测到第一触发信号时，在相应的目标画面处理时长内，通过界面线程基于获取的画面数据生成画面绘制指令；响应于画面绘制指令，通过渲染线程，调用图形处理单元对画面数据进行渲染，生成与输入事件对应的画面帧图层。

这里，计算与渲染单元包括界面线程(即UI线程)和渲染线程，当计算与渲染单元生成与输入事件对应的画面帧图层时，通过该UI线程和渲染线程实现。具体地，当计算与渲染单元检测到第一触发信号时，比如应用程序垂直同步信号(即APP_VSync)，在计算与渲染单元对应的目标画面处理时长内，通过界面线程去获取生成画面帧图层所需的画面数据，然后基于获取的画面数据生成画面绘制指令；将画面绘制指令传递至渲染线程，响应于该画面绘制指令，通过渲染线程对画面数据进行渲染，具体地，为加快渲染速度，减少中央处理器CPU的资源占用，通过渲染线程调用图形处理单元GPU对画面数据进行渲染，从而生成与输入事件对应的画面帧图层。

在一些实施例中，终端可通过如下方式通过画面合成单元从缓存帧队列中获取目标画面帧图层：获取缓存帧队列中各画面帧图层对应的先入先出的顺序；按照先入先出的顺序，通过画面合成单元从缓存帧队列中获取目标画面帧图层。

这里，缓存帧队列遵循先入先出的处理顺序。当通过画面合成单元从缓存帧队列中获取目标画面帧图层时，画面合成单元获取缓存帧队列中各画面帧图层对应的先入先出的顺序，按照该先入先出的顺序，从缓存帧队列中获取目标画面帧图层。作为示例，缓存帧队列中按照写入顺序存储有画面帧图层Frame#1、Frame#2和Frame#3，则画面合成单元针对缓存帧队列中画面帧图层的获取顺序依次为Frame#1、Frame#2和Frame#3。

应用本申请上述实施例，通过获取各级画面处理单元对应应用程序输出画面帧所需的最大处理时长、以及画面刷新时间间隔，进而基于各级画面处理单元对应的最大处理时长和画面刷新时间间隔，确定应用程序输出目标画面帧所需的缓冲帧队列的队列长度、以及各级画面处理单元对应的目标画面处理时长，以基于确定的队列长度和各级画面处理单元对应的目标画面处理时长，输出目标画面帧；

这里，由于所需的缓冲帧队列的队列长度、以及各级画面处理单元对应的目标画面处理时长，是基于各级画面处理单元对应应用程序输出画面帧所需的最大处理时长和画面刷新时间间隔确定的，能够保证每个画面帧在设定的刷新时间间隔内输出，降低了画面卡帧现象发生的可能性，提高了应用程序画面的流畅性。

下面将说明本申请实施例在一个实际的应用场景中的示例性应用。

在实际应用中，操作系统(比如安卓系统)一般为三缓冲帧队列(即缓冲帧队列的队列长度为三缓冲帧)与四级画面处理单元(即上述各级画面处理单元)。以垂直同步为参考，在固定的时间间隔点触发各级画面处理单元，画面处理单元在进行图形渲染至屏幕显示的过程中会锁定一个缓冲帧，因此，各级画面处理单元的并发执行，需要缓冲帧队列进行配合。这里，画面处理单元的基础时间单元为HW_VSyncTime，即终端显示屏的刷新时间间隔，每级画面处理单元默认分配一个画面处理单元时间(即上述各级画面处理单元对应的画面处理时长)，比如可以以HW_VSyncTime为一个画面处理单元时间。

参见图4，图4是本申请实施例提供的三缓冲帧队列与四级画面处理单元的处理流程示意图。这里，从输入事件(比如点击事件)输入到显示屏幕画面的流程具体为：输入采集(Input)、应用程序计算与图形渲染(APP)、图像合成(Composition)和画面显示(Display)。

各画面处理单元的画面处理时长与具体的应用程序场景及系统操作相关。比如，在固定的三缓冲帧队列与四级画面处理单元下，当其中某一级画面处理单元运算不能及时完成，则该级画面处理单元会被动增加J(J＝1、2、3...)个画面处理单元时间至完成相应运算为止。但是，画面处理单元的并发执行还受限于缓冲帧队列的队列长度，而三缓冲帧队列只能允许三条四级系统流水线并发。因此，当某条画面处理单元对应的画面处理单元时间被过度延长后，由于无可用缓冲帧，以至于无法启动下一条画面处理单元，就会发生连续性卡帧，使得画面帧率下降，对用户体验造成严重影响。

基于此，本申请实施例提供一种应用程序的画面处理方法，以至少解决上述存在的问题。本申请实施例提供的应用程序的画面处理方法，通过对应用程序输出画面帧所需要执行的相关计算、图形渲染和系统操作的处理时长进行量测，并以此为依据匹配应用程序输出画面帧时，各级画面处理单元所需的处理时长，从而对缓冲帧队列的长度和画面处理单元对应的流水线处理时间进行自适应调整，以保证应用程序能在系统流水线的设定时间内完成一帧画面的输出，降低画面卡帧概率，提升画面帧率，实现应用程序画面流畅性的系统优化。

本申请实施例提供的应用程序的画面处理方法可应用于至各种智能设备，尤其针对重负载应用或者高刷新率屏幕设备，可明显提升应用程序画面流畅性。

本申请实施例提供的应用程序的画面处理方法可由画面处理单元计时器、缓冲帧队列与画面处理单元控制器实现，画面处理单元计时器、缓冲帧队列与画面处理单元控制器集成于操作系统之中。

参见图5，图5是本申请实施例提供的应用程序的画面处理方法的流程示意图。这里，从输入事件(比如点击事件)输入到显示屏幕画面的流程具体为：输入采集单元(Input)采集输入事件，并将输入事件发送至应用程序计算与图形渲染单元(APP)；应用程序计算与图形渲染单元将生成的缓冲帧加入缓冲帧队列；图像合成单元SurfaceFlinger(Composition)从缓冲帧队列中获取缓冲帧并进行画面合成；将合成得到的画面帧发送至画面显示单元(Display)进行显示。其中，通过画面处理单元计时器(PT：Pipeline Timer)对每级画面处理单元的处理时长进行测量，输出处理时长，并通过缓冲帧队列与画面处理单元控制器(BPC：BufferQueue&Pipleline Controller)基于测量得到的每级画面处理单元的处理时长，对每级画面处理单元的画面处理单元时间、以及缓冲帧队列的队列长度进行调整，从而基于调整后的每级画面处理单元的流水线处理时间、以及缓冲帧队列的队列长度进行画面的输出和显示。

第一，画面处理单元计时器(PT：Pipeline Timer)，用于对应用程序输出画面帧所需要执行的相关计算、图形渲染和系统操作中的关键函数操作进行程序插桩，实现各级画面处理单元的处理时长的测量，从而输出测量得到的各级画面处理单元的处理时长。该测量得到的各级画面处理单元的处理时长，将用于指引缓冲帧队列与画面处理单元控制器的调整策略。

以操作系统为Android系统为例，参见图6，图6是本申请实施例提供的画面处理单元计时器的处理流程示意图。这里，Android系统包含四级画面处理单元，通过在各级画面处理单元的关键函数操作插桩Hook函数(具体为Hook Timestamp)，实现各级画面处理单元对应的处理时长的测量。该各级画面处理单元所对应的处理时长分别为，输入采集耗时T_Input、应用程序计算与渲染耗时T_APP(UI thread->Render thread->GPU render)、画面合成耗时T_SF(Surface Flinger)和画面显示耗时T_DISP(Display)。

第二，由画面处理单元计时器可知应用程序输出画面所需要进行的相关计算、图形渲染和系统操作所涉及的各个画面处理单元的处理时长，比如某一级画面处理单元运算耗时频繁超出该级画面处理单元时间，此时，缓冲帧队列与画面处理单元控制器(BPC：BufferQueue&Pipleline Controller)，可用于延长该级画面处理单元的流水线处理时间，并且增大缓存帧队列的队列长度，以满运算耗时，从而保证应用程序能在一条流水线过程中完成一帧图像输出，降低画面卡顿概率，提升画面帧率。

在本申请实施例中，可通过如下公式基于测量得到的每级画面处理单元的处理时长，对每级画面处理单元的画面处理单元时间、以及缓冲帧队列的队列长度进行调整：

PLUT_i-Max＝Max(t_i-0，t_i-1，t_i-2，…t_i-k)k＝1，2，3，4…60；

PLUD_i＝(Floor(PLUT_i-Max/HW_VSyncTime)+1)*HW_VSyncTime；

BufferQueueLen＝Floor((PLUD₁+PLUD₂+PLUD₃+...PLUD_i)/HW_VSyncTime)；

其中，PLUT_I-Max为第i级画面处理单元内的60次的运算量测的最大处理时长，Max()为求最大值函数；PLUD_i为第i级画面处理单元对应的调整时长(即计算得到的目标画面处理时长)；Floor()为求整函数；HW_VSyncTime为显示屏的刷新时间间隔；BufferQueuelen为缓冲帧队列的队列长度。

比如，以三缓冲帧队列与四级画面处理单元为例，对于应用程序运算与图形渲染单元的处理耗时常常略微超过一级画面处理单元时间的情况，基于上述实施例提供的调整策略公式，控制器会为应用程序运算与图形渲染单元的处理时长由一个画面处理单元时间在增加一个画面处理单元时间，并且为缓冲帧队列的队列长度进行延长，即增加一个缓冲帧，以满足应用程序的运算与渲染单元的处理耗时，从而保证应用程序能在一个流水线过程中完成一帧图像输出，降低画面卡顿概率，提升游戏画面帧率。参见图7，图7是本申请实施例提供的四缓冲帧队列与四级画面处理单元的处理流程示意图，这里，相对于图4来说，缓冲帧队列的长度由三缓冲帧增加为四缓冲帧，应用程序运算与图形渲染单元的处理时长由一个流水线时间单元增加为2个流水线时间单元。

接下来以操作系统为Android系统为例，首先对应用程序输出画面帧所需要进行的相关计算、图形渲染和系统操作步骤进行分析，在此基础上，结合实际例子，对缓冲帧队列与画面处理单元控制器的作用和调整过程进行进一步说明。

Android系统为三缓冲帧队列与四级画面处理单元，从输入事件的输入到输出屏幕显示画面的流程具体为：输入采集单元捕获输入事件event，将输入事件发送给应用程序；应用程序在应用程序垂直同步信号(APP_VSync)到来时开始进行逻辑和渲染相关工作(包括UI thread->Render thread->GPU render)，并将缓冲帧Frame(比如Frame#1)提交给缓冲帧队列(即BuffferQueue)管理；当合成垂直同步信号(SF_VSync)到来的时候，SurfaceFlinger(对应画面合成单元Composition)以先进先出的顺序，从缓冲帧队列中取出缓冲帧，将当前获取的所有应用程序的缓冲帧进行合成，并在接下来的硬件垂直同步信号(HW_{VSyn c})到来时，将合成的画面帧发送到屏幕(即画面显示单元Display)进行显示。

以轻运算负载应用为例，Android系统的缓冲帧队列与画面处理单元的行为如图8所示，图8是本申请实施例提供的三缓冲帧队列与四级画面处理单元的处理流程示意图。这里，输入采集单元捕获输入事件event，将输入事件发送给应用程序；应用程序在应用程序垂直同步信号(APP_VSync)到来时开始进行逻辑和渲染相关工作(包括UI thread->Renderthread->GPU render)，并将缓冲帧Frame(比如Frame#1)提交给缓冲帧队列(即BuffferQueue)管理，该缓冲帧队列的队列长度为三缓冲帧；当合成垂直同步信号(SF_VSync)到来的时候，SurfaceFlinger(对应画面合成单元Composition)以先进先出的顺序，从缓冲帧队列中取出缓冲帧，将当前获取的所有应用程序的缓冲帧进行合成，并在接下来的硬件垂直同步信号(HW_VSync)到来时，将合成的画面帧发送到屏幕(即画面显示单元Display)进行显示。对于轻运算负载应用，应用程序计算与渲染运算单元的处理耗时虽然有波动，但是没有出现过载的情况(即出现超过画面处理单元时间的情况)，依然可以在一个流水线流程内完成画面输出。

以重运算负载应用为例，Android系统的缓冲帧队列与画面处理单元的行为如图9所示，图9是本申请实施例提供的三缓冲帧队列与四级画面处理单元的处理流程示意图。这里，输入采集单元捕获输入事件event，将输入事件发送给应用程序；应用程序在应用程序垂直同步信号(APP_VSync)到来时开始进行逻辑和渲染相关工作(包括UI thread->Renderthread->GPU render)，并将缓冲帧Frame(比如Frame#1)提交给缓冲帧队列(即BuffferQueue)管理，该缓冲帧队列的队列长度为四缓冲帧；当合成垂直同步信号(SF_VSync)到来的时候，SurfaceFlinger(对应画面合成单元Composition)以先进先出的顺序，从缓冲帧队列中取出缓冲帧，将当前获取的所有应用程序的缓冲帧进行合成，并在接下来的硬件垂直同步信号(HW_VSync)到来时，将合成的画面帧发送到屏幕(即画面显示单元Display)进行显示。对于重运算负载应用，应用程序计算与渲染运算单元的处理耗时较长，在一个画面处理单元时间内无法及时完成，应用程序赶不上图像合成，从而导致卡帧(Jank)出现，即在输出显示Frame#2时，出现Jank的情况，此时由于Frame#2没有在一个画面处理单元时间内完成，导致画面卡帧于Frame#1上。

基于上述实施例提供的方法，对重运算负载应用下的缓冲帧队列的队列长度与画面处理单元的处理时长进行调整，如图10所示，图10是本申请实施例提供的四缓冲帧队列与四级画面处理单元的处理流程示意图。这里，对于重运算负载应用程序，由于其应用程序计算和图形渲染单元耗时频繁超出该级画面处理单元时间，根据调整方程，给应用程序计算与渲染运算单元延长一个画面处理单元时间，并为缓冲帧队列增加一个缓冲帧，即由三缓冲帧队列增加为四缓冲帧队列。具体地通过修改Buffer的送显时间戳至一个SF_VSync后，以跳过最近的一次的SurfaceFlinger合成动作，即在最近一次的合成垂直信号SF_VSync到达时，画面合成单元SurfaceFlinger无法获取到缓冲帧(由于Buffer的送显时间戳修改为该SF_Vsync之后)，该缓冲帧在下一次合成垂直信号SF_VSync到达时，Sur faceFlinger才能获取成功并执行画面合成操作，以给应用程序计算与渲染运算单元延长一个画面处理单元时间，并为缓冲帧队列增加一个缓冲帧，以满足应用程序的运算与渲染耗时，提高系统流水线并发性，降低画面卡顿发生的概率，提升帧率。

具体地，输入采集单元捕获输入事件event，将输入事件发送给应用程序；应用程序在应用程序垂直同步信号(APP_VSync)到来时开始进行逻辑和渲染相关工作(包括UIthread->Render thread->GPU render)，并将缓冲帧Frame(比如Frame#1)提交给缓冲帧队列(即BuffferQueue)管理，该缓冲帧队列的队列长度为四缓冲帧；当合成垂直同步信号(SF_VSync)到来的时候，SurfaceFli nger(对应画面合成单元Composition)以先进先出的顺序，从缓冲帧队列中取出缓冲帧，将当前获取的所有应用程序的缓冲帧进行合成，并在接下来的硬件垂直同步信号(HW_VSync)到来时，将合成的画面帧发送到屏幕(即画面显示单元Display)进行显示。

基于上述实施例，应用程序的平均帧率AvgFPS、帧率稳定性、帧率方差VarFPS和卡帧(包括Jank和BigJank)等指标都有明显优化，手机终端(优化前后)的画面流畅性对比数据如图11所示，图11是本申请实施例提供的画面流畅性对比数据的示意图。

应用本申请上述实施例，通过对应用程序输出画面帧所需要执行的相关计算、图形渲染和系统操作的处理时长进行量测，并以此为依据匹配应用程序输出画面帧时，各级画面处理单元所需的处理时长，从而对缓冲帧队列的长度和画面处理单元对应的流水线处理时间进行自适应调整，以保证应用程序能在系统流水线的设定时间内完成一帧画面的输出，降低画面卡帧概率，提升画面帧率，实现应用程序画面流畅性的系统优化。

下面继续说明本申请实施例提供的应用程序的画面处理装置555的实施为软件模块的示例性结构，在一些实施例中，如图2所示，存储在存储器550的应用程序的画面处理装置555中的软件模块可以包括：

获取模块5551，用于获取应用程序的各级画面处理单元所对应的画面处理时长、以及所述应用程序的画面刷新时间间隔；

其中，所述画面处理时长为，相应画面处理单元对应所述应用程序输出画面帧所需的最大处理时长；

确定模块5552，用于基于各级所述画面处理单元对应的画面处理时长和所述画面刷新时间间隔，确定所述应用程序输出目标画面帧所需的缓冲帧队列的队列长度、以及各级所述画面处理单元对应的目标画面处理时长；

输出模块5553，用于基于所述队列长度和各级所述画面处理单元对应的目标画面处理时长，通过各级所述画面处理单元输出目标画面帧。

在一些实施例中，所述获取模块5551，还用于分别针对所述应用程序的各级画面处理单元执行如下处理：

对所述画面处理单元对应所述应用程序输出画面帧所需的处理时长，进行目标次数的采集；

将采集得到的所述目标次数的处理时长中的最大处理时长，作为所述画面处理单元所对应的画面处理时长。

在一些实施例中，所述获取模块5551，还用于针对所述目标次数中每次采集执行以下处理：

针对非最后一级的画面处理单元，通过目标函数，监听所述画面处理单元对应的子应用程序运行时的第一时间点、以及所述画面处理单元的下一级画面处理单元对应的子应用程序运行时的第二时间点；

基于所述第一时间点和所述第二时间点，确定并采集所述非最后一级的画面处理单元对应的处理时长；

针对最后一级的画面处理单元，通过所述目标函数，监听所述画面处理单元对应的子应用程序运行时的第三时间点、以及所述画面处理单元对应的子应用程序运行结束时的第四时间点；

基于所述第三时间点和所述第四时间点，确定并采集所述最后一级的画面处理单元对应的处理时长。

在一些实施例中，所述获取模块5551，还用于通过程序插桩方式，将所述目标函数，挂载到各级画面处理单元对应所述应用程序中的目标位置，以通过所述目标函数，基于所述目标位置对各级画面处理单元对应的子应用程序运行时的时间点、及运行结束时的时间点进行监听；

其中，所述目标位置，用于指示所述应用程序中对应各级画面处理单元的子应用程序的起始位置、以及指示对应最后一级画面处理单元的子应用程序的结束位置。

在一些实施例中，所述确定模块5552，还用于基于各级所述画面处理单元对应的画面处理时长、及所述画面刷新时间间隔，确定相应画面处理单元对应的目标画面处理时长；

将各级所述画面处理单元对应的目标画面处理时长进行求和处理，得到求和结果，并

基于所述求和结果及所述画面刷新时间间隔，确定所述应用程序输出目标画面帧所需的缓冲帧队列的队列长度。

在一些实施例中，所述应用程序具有对应缓冲帧队列的初始队列长度、及各级所述画面处理单元具有相应的初始画面处理时长；所述输出模块5553，将所述初始队列长度更新为所述队列长度，并将各级所述画面处理单元对应的初始画面处理时长更新为相应的目标画面处理时长；

基于所述更新后的初始队列长度以及各级所述画面处理单元对应的初始画面处理时长，通过各级所述画面处理单元输出目标画面帧。

在一些实施例中，所述各级画面处理单元包括：输入采集单元、计算与渲染单元、画面合成单元以及画面显示单元；所述输出模块5553，还用于当所述输入采集单元检测到输入事件时，在相应的目标画面处理时长内，将所述输入事件发送至所述计算与渲染单元；

当所述计算与渲染单元接收到所述输入事件并检测到第一触发信号时，在相应的目标画面处理时长内，生成与所述输入事件对应的画面帧图层，并将所述画面帧图层加入具备所述队列长度的缓存帧队列中；

当所述画面合成单元检测到第二触发信号时，在相应的目标画面处理时长内，从所述缓存帧队列中获取目标画面帧图层，并对所述目标画面帧图层进行图层合成处理，得到所述目标画面帧，并

当所述画面合成单元检测到第三触发信号时，将所述目标画面帧发送至所述画面显示单元；

在所述画面显示单元对应的目标画面处理时长内，通过所述画面显示单元输出所述目标画面帧。

在一些实施例中，所述计算与渲染单元包括界面线程和渲染线程，所述输出模块5553，还用于当所述计算与渲染单元检测到第一触发信号时，在相应的目标画面处理时长内，通过所述界面线程基于获取的画面数据生成画面绘制指令；

响应于所述画面绘制指令，通过所述渲染线程，调用图形处理单元对所述画面数据进行渲染，生成与所述输入事件对应的画面帧图层。

在一些实施例中，所述输出模块5553，还用于获取所述缓存帧队列中各画面帧图层对应的先入先出的顺序；

按照所述先入先出的顺序，通过所述画面合成单元从所述缓存帧队列中获取目标画面帧图层。

在一些实施例中，所述装置还包括：

存储模块，用于将所述应用程序的各级画面处理单元所对应的画面处理时长，存储至区块链网络；

所述获取应用程序的各级画面处理单元所对应的画面处理时长，包括：

生成并发送用于获取区块链网络中各级画面处理单元所对应的画面处理时长的交易；

接收所述区块链网络基于所述交易返回的各级所述画面处理单元所对应的画面处理时长。

在一些实施例中，所述应用程序的各级所述画面处理单元具有相应的初始画面处理时长；所述获取模块5551，还用于获取各级画面处理单元的历史画面处理时长超过初始画面处理时长的频率；

确定各级画面处理单元中、所述频率达到频率阈值的画面处理单元为目标画面处理单元；

获取所述目标画面处理单元所对应的画面处理时长。

在一些实施例中，所述获取模块5551，还用于对所述应用程序输出的、处于目标时长内的多个画面帧进行卡顿时长检测，确定所述多个画面帧对应的卡顿总时长；

基于所述卡顿总时长和所述目标时长，确定所述应用程序对应的卡顿分数；

当所述卡顿分数达到卡顿分数阈值时，获取应用程序的各级画面处理单元所对应的画面处理时长。

在一些实施例中，所述获取模块5551，还用于获取所述应用程序输出各所述画面帧所需的实际画面处理时长、以及所述应用程序输出画面帧对应的标准画面处理时长；

基于各所述画面帧所需的实际画面处理时长以及所述标准画面处理时长，确定各所述画面帧对应的卡顿时长；

基于各所述画面帧对应的卡顿时长，确定所述多个画面帧对应的卡顿总时长。

应用本申请上述实施例，通过获取各级画面处理单元对应应用程序输出画面帧所需的最大处理时长、以及画面刷新时间间隔，进而基于各级画面处理单元对应的最大处理时长和画面刷新时间间隔，确定应用程序输出目标画面帧所需的缓冲帧队列的队列长度、以及各级画面处理单元对应的目标画面处理时长，以基于确定的队列长度和各级画面处理单元对应的目标画面处理时长，输出目标画面帧；

这里，由于所需的缓冲帧队列的队列长度、以及各级画面处理单元对应的目标画面处理时长，是基于各级画面处理单元对应应用程序输出画面帧所需的最大处理时长和画面刷新时间间隔确定的，能够保证每个画面帧在设定的刷新时间间隔内输出，降低了画面卡帧现象发生的可能性，提高了应用程序画面的流畅性。

本申请实施例还提供一种电子设备，所述电子设备包括：

存储器，用于存储可执行指令；

处理器，用于执行所述存储器中存储的可执行指令时，实现本申请实施例提供的应用程序的画面处理方法。

本申请实施例还提供一种计算机程序产品或计算机程序，该计算机程序产品或计算机程序包括计算机指令，该计算机指令存储在计算机可读存储介质中。计算机设备的处理器从计算机可读存储介质读取该计算机指令，处理器执行该计算机指令，使得该计算机设备执行本申请实施例提供的应用程序的画面处理方法。

本申请实施例还提供一种计算机可读存储介质，存储有可执行指令，所述可执行指令被处理器执行时，实现本申请实施例提供的应用程序的画面处理方法。

在一些实施例中，计算机可读存储介质可以是FRAM、ROM、PROM、EP ROM、EEPROM、闪存、磁表面存储器、光盘、或CD-ROM等存储器；也可以是包括上述存储器之一或任意组合的各种设备。

在一些实施例中，可执行指令可以采用程序、软件、软件模块、脚本或代码的形式，按任意形式的编程语言(包括编译或解释语言，或者声明性或过程性语言)来编写，并且其可按任意形式部署，包括被部署为独立的程序或者被部署为模块、组件、子例程或者适合在计算环境中使用的其它单元。

作为示例，可执行指令可以但不一定对应于文件系统中的文件，可以可被存储在保存其它程序或数据的文件的一部分，例如，存储在超文本标记语言(HTML，Hyper TextMarkup Language)文档中的一个或多个脚本中，存储在专用于所讨论的程序的单个文件中，或者，存储在多个协同文件(例如，存储一个或多个模块、子程序或代码部分的文件)中。

作为示例，可执行指令可被部署为在一个计算设备上执行，或者在位于一个地点的多个计算设备上执行，又或者，在分布在多个地点且通过通信网络互连的多个计算设备上执行。

以上所述，仅为本申请的实施例而已，并非用于限定本申请的保护范围。凡在本申请的精神和范围之内所作的任何修改、等同替换和改进等，均包含在本申请的保护范围之内。