CN116166256A

CN116166256A - 界面生成方法及电子设备

Info

Publication number: CN116166256A
Application number: CN202111410643.XA
Authority: CN
Inventors: 倪泽宇; 余先宇; 陈炳; 周越海
Original assignee: Huawei Technologies Co Ltd
Current assignee: Huawei Technologies Co Ltd
Priority date: 2021-11-25
Filing date: 2021-11-25
Publication date: 2023-05-26

Abstract

本申请公开了界面生成方法及电子设备，涉及电子技术领域。本申请实施例提供的界面生成方法，可以由一个独立的进程获取应用程序的渲染树，进而由该进程生成包含一个或多个应用程序的界面，其中，该进程通过跨进程通信如共享内存获取应用程序的渲染树，降低了渲染次数；其次，相比于UI线程和渲染线程同步渲染树，渲染树的跨进程通信不会阻塞UI线程，降低应用程序卡顿的概率，提升用户的体验。

Description

界面生成方法及电子设备

技术领域

本申请涉及电子技术领域，尤其涉及界面生成方法及电子设备。

背景技术

随着电子技术的发展，越来越多的电子设备参与到用户的日常生活中。并且，随着电子设备的屏幕的分辨率、尺寸等参数越来越高，电子设备上可以显示的内容也越来越多。

但是，电子设备在显示应用程序的界面前，需要花费计算资源、存储资源去生成应用程序的界面，增加了电子设备的功耗。并且，在电子设备的屏幕上有多个应用程序或多个窗口的情况下，电子设备需要花费更多的计算资源、存储资源去渲染以生成多个应用程序或多个窗口的界面。

发明内容

本申请实施例提供了界面生成方法及电子设备，该方法包括：由一个独立的进程获取应用程序的渲染树，进而由该进程生成包含一个或多个应用程序的界面，其中，该进程通过跨进程通信如共享内存获取应用程序的渲染树，降低了渲染次数；其次，相比于UI线程和渲染线程同步渲染树，渲染树的跨进程通信不会阻塞UI线程，降低应用程序卡顿的概率，提升用户的体验。

第一方面，本申请实施例提供的界面生成方法，应用于电子设备，包括：第一进程生成第一渲染树，该第一渲染树用于绘制第一进程的界面；该第一进程将该第一渲染树写入第一共享内存；第二进程从该第一共享内存读取该第一渲染树；该第二进程基于该第一渲染树生成第一目标界面，该第一目标界面包括该第一进程的界面。

在上述实施例中，由一个独立的进程获取一个或多个应用程序的渲染树，进而由该进程生成包括一个或多个应用程序界面的目标界面。通过共享内存将渲染树的数据从应用程序传递到该进程，数据传输速度较快，延迟较少；其次，通过共享内存传递数据不会阻塞应用程序的UI线程，降低应用程序的卡顿；最后，由于该进程可以一次生成包括多个应用程序的界面，降低了渲染次数，降低了电子设备的开销。

结合第一方面的一些实施例，在一些实施例中，该第一进程将该第一渲染树写入该第一共享内存，具体包括：该第一进程将该第一渲染树的变化量写入该第一共享内存。

在上述实施例中，仅将渲染树的变化量或渲染树的脏数据写入共享内存，降低跨进程通信的传递数据量，提升传递速度，进而避免掉帧。

结合第一方面的一些实施例，在一些实施例中，该第一共享内存被配置有第一锁，该第一锁被配置有至少两个状态，该至少两个状态包括第一状态和第二状态；在该第一锁为第一状态的情况下，该第一共享内存允许被该第一进程写入；在该第一锁为第二状态的情况下，该第一共享内存允许被该第二进程读取。

在上述实施例中，为共享内存配置一个跨进程的同步锁，避免读写冲突导致第二进程读取到错误的渲染树的数据。

结合第一方面的一些实施例，在一些实施例中，该第一共享内存被配置有第二锁、第三锁，该第二锁、该第三锁均被配置有至少两个状态，该至少两个状态包括第一状态和第二状态；在该第二锁为第一状态的情况下，该第一共享内存允许被该第一进程写入第一界面对应的渲染树；在该第二锁为第二状态的情况下，该第一共享内存允许被该第二进程读取该第一界面对应的渲染树；在该第三锁为第一状态的情况下，该第一共享内存允许被该第一进程写入第二界面对应的渲染树；在该第三锁为第二状态的情况下，该第一共享内存允许被该第二进程读取该第二界面对应的渲染树；该第一界面、该第二界面均是该第一进程的界面，该第二界面的前一帧界面是该第一界面。

在上述实施例中，通过在共享内存中配置两个或更多个锁，实现双缓冲/多缓冲机制，使得应用程序可以往共享内存中写入两帧/多帧界面对应的渲染树，避免掉帧。

结合第一方面的一些实施例，在一些实施例中，该第一共享内存包括第一部分和第二部分；该第一部分用于存储该第一界面对应的渲染树；该第二部分用于存储该第二界面对应的渲染树；该第二锁对应于该第一部分；该第三锁对应于该第二部分。

在上述实施例中，共享内存中可以被划分为两部分/更多部分，实现双缓冲/多缓冲机制，使得应用程序可以往共享内存中写入两帧/多帧界面对应的渲染树，避免掉帧。

结合第一方面的一些实施例，在一些实施例中，该第一共享内存以内存树存储该第一渲染树，该内存树为在共享内存中存储渲染树的一种数据结构；该内存树至少包括第一段数据和第二段数据，该第一段数据包括用于确定该第一进程的标识信息和该第一渲染树的标识信息，该第一段数据还包括第二段数据的起始地址；该第二段数据包括渲染树的绘制指令列表和渲染属性。

在上述实施例中，共享内存以内存树的结构存储渲染树，不需要在向共享内存中写入渲染树前对渲染树进行序列化，也不需要在从共享内存中反序列化渲染树，降低了数据传递的开销。

结合第一方面的一些实施例，在一些实施例中，该第一段数据还包括渲染节点的标识；该第一段数据还包括该渲染节点的绘制指令列表和渲染属性在该第二段数据中的起始地址。

在上述实施例中，内存树的结构还支持第二进程从共享内存中单独获取任意渲染树的渲染节点，而无需将渲染树的全部结构恢复出来，进而使得第二进程可以只获取渲染树的改变量或脏数据，降低了数据传输时延，避免掉帧。

结合第一方面的一些实施例，在一些实施例中，该第一进程生成第二渲染树，该第一渲染树对应第一界面，该第二渲染树对应第二界面；该第一进程将该第二渲染树写入第二共享内存；该第二进程从该第二共享内存读取该第二渲染树；该第一界面、该第二界面均是该第一进程的界面，该第二界面的前一帧界面是该第一界面。

在上述实施例中，也可以通过两个/多个共享内存实现双缓冲/多缓冲，进而避免掉帧。

第二方面，本申请实施例提供的界面生成方法，应用于包括第一电子设备和第二电子设备的系统，该第一电子设备和该第二电子设备之间建立有通信连接，包括：运行在该第一电子设备上的第二进程接收第一渲染树，该第一渲染树是运行在该第一电子设备上的第一进程生成的，该第一渲染树用于绘制第一进程的界面；该第二进程将该第一渲染树发送给运行在该第二电子设备上的第三进程；该第三进程基于该第一渲染树生成第一界面，该第一界面包括该第一进程的界面。

在上述实施例中，一个系统中的电子设备可以通过传递渲染树，实现界面的传递，进而实现多屏协同、投屏等功能，相比于直接传递界面，降低了传输的数据量，进而降低了多设备之间的延迟，提升了用户的体验。

结合第二方面的一些实施例，在一些实施例中，响应于用户对该第一界面的交互操作，该第三进程确定第一控件和交互事件，该第一控件为该交互操作对应的控件；该第一进程接收该第三进程发送的交互事件，该交互事件用于确定该交互操作和该第一控件。

在上述实施例中，由于渲染树中包含控件、控件的位置信息，第二电子设备可以直接确定交互事件，将交互事件返回给第一电子设备上的应用程序，而无需将交互的位置返回给第一电子设备，使得第一电子设备上的应用程序能够更快的响应该交互事件，进而提升用户的体验。

第三方面，本申请实施例提供了一种电子设备，该电子设备包括：一个或多个处理器和存储器；该存储器与该一个或多个处理器耦合，该存储器用于存储计算机程序代码，该计算机程序代码包括计算机指令，该一个或多个处理器调用该计算机指令以使得该电子设备执行：第一进程生成第一渲染树，该第一渲染树用于绘制第一进程的界面；该第一进程将该第一渲染树写入第一共享内存；第二进程从该第一共享内存读取该第一渲染树；该第二进程基于该第一渲染树生成第一目标界面，该第一目标界面包括该第一进程的界面。

结合第三方面的一些实施例，在一些实施例中，该一个或多个处理器，具体用于调用该计算机指令以使得该电子设备执行：该第一进程将该第一渲染树的变化量写入该第一共享内存。

结合第三方面的一些实施例，在一些实施例中，该第一共享内存被配置有第一锁，该第一锁被配置有至少两个状态，该至少两个状态包括第一状态和第二状态；在该第一锁为第一状态的情况下，该第一共享内存允许被该第一进程写入；在该第一锁为第二状态的情况下，该第一共享内存允许被该第二进程读取。

结合第三方面的一些实施例，在一些实施例中，该第一共享内存被配置有第二锁、第三锁，该第二锁、该第三锁均被配置有至少两个状态，该至少两个状态包括第一状态和第二状态；在该第二锁为第一状态的情况下，该第一共享内存允许被该第一进程写入第一界面对应的渲染树；在该第二锁为第二状态的情况下，该第一共享内存允许被该第二进程读取该第一界面对应的渲染树；在该第三锁为第一状态的情况下，该第一共享内存允许被该第一进程写入第二界面对应的渲染树；在该第三锁为第二状态的情况下，该第一共享内存允许被该第二进程读取该第二界面对应的渲染树；该第一界面、该第二界面均是该第一进程的界面，该第二界面的前一帧界面是该第一界面。

结合第三方面的一些实施例，在一些实施例中，该第一共享内存包括第一部分和第二部分；该第一部分用于存储该第一界面对应的渲染树；该第二部分用于存储该第二界面对应的渲染树；该第二锁对应于该第一部分；该第三锁对应于该第二部分。

结合第三方面的一些实施例，在一些实施例中，该第一共享内存以内存树存储该第一渲染树，该内存树为在共享内存中存储渲染树的一种数据结构；该内存树至少包括第一段数据和第二段数据，该第一段数据包括用于确定该第一进程的标识信息和该第一渲染树的标识信息，该第一段数据还包括第二段数据的起始地址；该第二段数据包括渲染树的绘制指令列表和渲染属性。

结合第三方面的一些实施例，在一些实施例中,该第一段数据还包括渲染节点的标识；该第一段数据还包括该渲染节点的绘制指令列表和渲染属性在该第二段数据中的起始地址。

结合第三方面的一些实施例，在一些实施例中,在一些实施例中，该一个或多个处理器，还用于调用该计算机指令以使得该电子设备执行：该第一进程生成第二渲染树，该第一渲染树对应第一界面，该第二渲染树对应第二界面；该第一进程将该第二渲染树写入第二共享内存；该第二进程从该第二共享内存读取该第二渲染树；该第一界面、该第二界面均是该第一进程的界面，该第二界面的前一帧界面是该第一界面。

第四方面，本申请实施例提供了一种芯片系统，该芯片系统应用于电子设备，该芯片系统包括一个或多个处理器，该处理器用于调用计算机指令以使得该电子设备执行如第一方面以及第一方面中任一可能的实现方式描述的方法。

第五方面，本申请实施例提供一种包含指令的计算机程序产品，当上述计算机程序产品在电子设备上运行时，使得上述电子设备执行如第一方面以及第一方面中任一可能的实现方式描述的方法。

第六方面，本申请实施例提供一种计算机可读存储介质，包括指令，当上述指令在电子设备上运行时，使得上述电子设备执行如第一方面以及第一方面中任一可能的实现方式描述的方法。

可以理解地，上述第三方面提供的电子设备、第四方面提供的芯片系统、第五方面提供的计算机程序产品和第六方面提供的计算机存储介质均用于执行本申请实施例所提供的方法。因此，其所能达到的有益效果可参考对应方法中的有益效果，此处不再赘述。

附图说明

图1A、图1B为本申请实施例提供的电子设备界面的一个示例性示意图。

图2为本申请实施例提供的应用程序生成位图的一个示例性示意图。

图3为本申请实施例提供的渲染树的一个示例性示意图。

图4为本申请实施例提供的位图作为图层参与图层合成的一个示例性示意图。

图5为本申请实施例提供的图层合成的一个示例性示意图。

图6为本申请实施例提供的SurfaceFlinge进行图层合成的另一个示例性示意图。

图7A、图7B为本申请实施例提供的图层合成的另一个示例性示意图。

图8为本申请实施例提供的界面生成方法的系统架构的一个示例性示意图。

图9为本申请实施例提供的界面生成方法的一个示例性示意图。

图10为本申请实施例提供的UniRender的架构的一个示例性示意图。

图11为本申请实施例提供的共享内存传递渲染树的一个示例性示意图。

图12A、图12B为本申请实施例提供的共享内存中渲染树的存储结构的一个示例性示意图。

图13为本申请实施例提供的UniRender的架构的一个示例性示意图。

图14为本申请实施例提供的应用程序往共享内存中写入渲染树的一个示例性示意图。

图15为本申请实施例提供的应用程序往共享内存中写入渲染树的另一个示例性示意图。

图16A-图16C为本申请实施例提供的触发离屏渲染的绘制逻辑的场景的一个示例性示意图。

图17A、图17B为本申请实施例提供的UniRender将触发离屏渲染指令前移的一个示例性示意图。

图18为本申请实施例提供的UniRender对渲染树的渲染节点属性修改的一个示例性示意图。

图19为本申请实施例提供的将多个离屏渲染指令前移处理后的渲染树合成为一个目标渲染树的一个示例性示意图。

图20为本申请实施例提供的将多个离屏渲染指令前移处理后的渲染树合成为一个目标渲染树的一个示例性示意图。

图21为本申请实施例提供的setStaticMatrix()的一个示例性示意图。

图22A-图22C为本申请实施例提供的多显示区域场景的一个示例性示意图。

图23A-图23C为本申请实施例提供的多显示区域场景的另一个示例性示意图。

图24为本申请实施例提供的界面生成方法的另一个示例性示意图。

图25为本申请实施例提供的UniRender进程分频、倍频垂直同步信号的一个示例性示意图。

图26A、图26B为本申请实施例提供的电子设备实施界面生成方法时数据流动的一个示例性示意图。

图27为本申请实施例提供的界面生成方法的另一个示例性示意图。

图28A、图28B为本申请实施例提供的渲染树合成为目标渲染树的一个示例性示意图。

图29为本申请实施例提供的电子设备的硬件结构的一个示例性示意图。

图30为本申请实施例提供的电子设备的软件结构的一个示例性示意图。

具体实施方式

本申请以下实施例中所使用的术语只是为了描述特定实施例的目的，而并非旨在作为对本申请的限制。如在本申请的说明书所使用的那样，单数表达形式“一个”、“一种”、“该”、“上述”、“该”和“这一”旨在也包括复数表达形式，除非其上下文中明确地有相反指示。还应当理解，本申请中使用的术语“和/或”是指并包含一个或多个所列出项目的任何或所有可能组合。

以下，术语“第一”、“第二”仅用于描述目的，而不能理解为暗示或暗示相对重要性或者隐含指明所指示的技术特征的数量。由此，限定有“第一”、“第二”的特征可以明示或者隐含地包括一个或者更多个该特征，在本申请实施例的描述中，除非另有说明，“多个”的含义是两个或两个以上。

本申请以下实施例中的术语“用户界面(userinterface，UI)”，是应用程序或操作系统与用户之间进行交互和信息交换的介质接口，它实现信息的内部形式与用户可以接受形式之间的转换。用户界面是通过java、可扩展标记语言(extensible markup language，XML)等特定计算机语言编写的源代码，界面源代码在电子设备上经过解析，渲染，最终呈现为用户可以识别的内容。用户界面常用的表现形式是图形用户界面(graphic userinterface，GUI)，是指采用图形方式显示的与计算机操作相关的用户界面。它可以是在电子设备的显示屏中显示的文本、图标、按钮、菜单、选项卡、文本框、对话框、状态栏、导航栏、Widget等可视的界面元素。

为了便于理解，下面先对本申请实施例涉及的相关术语及相关概念进行介绍。本发明的实施方式部分使用的术语仅用于对本发明的具体实施例进行解释，而非旨在限定本发明。

界面作为应用程序与用户之间的交互和信息交互的介质接口，在每一次垂直同步信号到来时，电子设备需要为前台的应用程序生成该应用程序的界面。其中，垂直同步信号的频率与电子设备的屏幕的刷新率有关，例如垂直同步信号的频率与电子设备的屏幕的刷新率相同。

即每次电子设备刷新屏幕上显示的内容前，都需要为前台应用生成该应用程序的界面，以在屏幕刷新时向用户展现应用程序的新生成的界面。

电子设备在电子设备上显示的界面可以包括一个或多个应用程序的界面，即电子设备需要为一个或多个应用程序生成界面，并将界面合成，进而得到在屏幕上显示的合成后的界面。

其中，电子设备生成应用程序的界面需要应用程序自己渲染生成位图(bitmap)，将自己的位图传递给表面合成器(SurfaceFlinger)。即，应用程序作为生产者进行绘制生成位图，将该位图存入SurfaceFlinger提供的缓冲队列(BufferQueue)中；SurfaceFlinger作为消费者不断的从BufferQueue获取应用程序生成的位图。其中，位图位于应用程序生成的surface上，该surface会被填入BufferQueue中。

在SurfaceFlinger获得可见的应用程序的位图后，SurfaceFlinger与硬件合成策略模块(Hardware Composer,HWC)确定位图作为图层(layer)的图层合成的方式。其中，SurfaceFlinger可以通过窗口管理服务(WindowManagerService,WMS)确定可见的应用程序。

SurfaceFlinger可以从窗口管理服务获取作用于应用程序的窗口的离屏渲染逻辑后，如圆角、旋转、颜色变化、缩放等离屏渲染逻辑，会将应用程序的位图拷贝到离屏缓冲中进行渲染，并通过离屏渲染得到用于参与图层合成的位图。

在对应用程序的位图合成后，由SurfaceFlinger/HWC将合成后的位图(位图在SurfaceFlinger上也可以称为图层)填入帧缓冲(Frame Buffer)中传递给显示子系统(Display Subsystem,DSS)，DSS在拿到合成后的位图可以将该合成后的位图显示到屏幕上。该帧缓冲可以是在屏缓冲(on-screenbuffer)。

(1)首先，下面分别示例性的介绍(1.1)应用程序生成位图的过程、(1.2)SurfaceFlinger/HWC合成位图的过程、(1.3)离屏渲染

(1.1)应用程序生成位图的过程

如图1A所示，电子设备的屏幕上显示有应用程序1和应用程序2的界面。其中，应用程序1的界面可以称为状态栏。在图1A中，应用程序1可以是操作系统，应用程序2可以是音乐应用程序。

电子设备在显示如图1A所示的界面前，需要分别的独立的生成应用程序的位图。其中，状态栏的界面是由操作系统维护，即可以认为生成状态栏的位图的应用程序是操作系统。即，操作系统生成位图1后，将位图1传递给SurfaceFlinger；音乐应用程序生成位图2后，将位图2传递给SurfaceFlinger。位图1上承载有状态栏的图像信息；位图2上承载有音乐应用程序的图像信息。

其中，SurfaceFlinger/HWC在接收到位图1和位图2后，将位图1和位图2作为图层进行图层合成。其中，图层合成的内容可以参考(1.2)SurfaceFlinger/HWC合成位图的过程中的文字描述，此处不再赘述。

又如图1B所示，电子设备的屏幕上显示有应用程序1、应用程序2和应用程序3的界面。其中，应用程序1的界面可以称为状态栏。在图1B中，应用程序1可以是操作系统，应用程序2可以是浏览器应用程序，应用程序3可以是短信应用程序。

电子设备在显示如图1B所示的界面前，同样需要分别的独立的生成应用程序的位图。

即，操作系统生成位图3后，将位图3传递给SurfaceFlinger；短信应用程序生成位图4后，将位图4传递给SurfaceFlinger；新闻应用程序生成位图5后，将位图5传递给SurfaceFlinger。位图3上承载有状态栏的图像信息；位图4上承载有短信应用程序的图像信息；位图5上承载有新闻应用程序的图像信息。

其中，SurfaceFlinger/HWC在接收到位图3、位图4和位图5后，将位图3、位图4和位图5作为图层进行图层合成。其中，图层合成的内容可以参考(1.2)SurfaceFlinger/HWC合成位图的过程中的文字描述，此处不再赘述。

其中，应用程序生成位图的过程如下图2所示。

如图2所示，应用程序在接收到垂直同步信号(Vsync-APP)后，开始生成位图，具体的步骤包括三步，分别为：

①让视图结构(viewhierarchy)失效，主线程(UI线程，UI Thread)遍历该应用程序的视图(view)，确定并保存每个视图的绘制操作，并将视图和该视图涉及的绘制操作(Draw Operation Struct,DrawOP)录制到渲染树的渲染节点(RenderNode)的绘制指令列表(displaylist)中。

其中，视图是构成应用程序界面的基本元素，界面上的一个控件可以对应于一个或多个视图。

其中，绘制操作为一个数据结构体，用于绘制图形，例如绘制线条、绘制变宽、绘制矩形、绘制文本等。绘制操作在渲染节点会被转换为图像处理库的API调用，如OpenGL的接口调用。例如DrawLineOp是一个数据结构体，数据结构体里面包含有绘制的数据如线的长度、宽度等信息。

其中，绘制指令列表可以是一个缓冲区，该缓冲区中记录有应用程序一帧界面所包括的所有绘制操作或是所有绘制操作的标识，如地址、序号等。当应用程序有多个窗口、或者在不同的显示区域(display)上显示时，需要独立的生成多个渲染树，其中，会独立的生成多个对应不同窗口、显示区域的绘制指令列表。

在本申请实施例中，显示区域可以是一块屏幕、或者可以是虚拟屏幕(VirtualDisplay)等。虚拟屏幕可以是录屏时，电子设备用于承载屏幕上显示的内容的区域。

其中，渲染树是UI线程生成的，用于生成应用程序界面的一个数据结构体，渲染树可以包括多个渲染节点，每个渲染节点包括渲染属性和绘制指令列表。渲染树记录有生成应用程序一帧界面的所有信息。

②UI线程将渲染树传递/同步给渲染线程(Render Thread)，其中，渲染树位于应用程序对应的进程的栈(stack)中，并且在物理地址上可以不是连续分布的。

③渲染线程首先获取一个硬件画布(HardwareCanvas)，并在该硬件画布上执行渲染树中的绘制操作，进而生成位图。其中，该硬件画布位于该应用程序持有的surface中，该surface中承载有位图或者其他格式的用于保存图像信息的数据。

可以认为①为构建阶段，主要负责确定该应用程序中每个view的大小、位置、透明度等属性。例如，视图中的drawLine，构建中可以被封装成一个DrawLineOp，里面包含有绘制的数据如线的长度、宽度等，还可以包含有底层图形处理库的drawLineOP对应的接口调用，用于在渲染阶段调用底层图形库生成位图。

类似的，可以认为③为渲染阶段，主要负责遍历渲染树的渲染节点，并执行每个渲染节点的绘制操作，进而在硬件画布上生成位图，在该过程中，渲染线程通过调用底层图形处理库，如OpenGL，进而调用GPU完成渲染以生成位图。

图3为本申请实施例提供的渲染树的一个示例性示意图。

应用程序需要显示的界面由多个view嵌套组成，不同的view之间具有父子关系，所以遍历view生成的渲染树的渲染节点之间的父子关系与view的父子关系相同。即view之间的父子关系决定了不同渲染节点的之间的嵌套关系，进而渲染线程在依据渲染树生成位图时可以正确渲染出应用程序的界面。

一个view可以对应一个或多个渲染节点，根视图(DecorView)对应根渲染节点(RootRenderNode)。即渲染节点之间的嵌套关系与view的父子关系对应。其中，渲染节点中还包括有渲染属性(properties)，用与在渲染生成位图时确定被该渲染节点对应的view在surface上的位置、大小、透明度等。

例如，应用程序的界面的结构为：应用程序的PhoneWindow上承载有根视图，根视图的子视图为视图1和视图2，视图2的子视图为视图3。则应用程序的UI线程生成渲染树的结构为：与PhoneWindow对应的根渲染节点为渲染树的根节点，根渲染节点的子节点为与根视图对应的渲染节点0，渲染节点0的子节点为与视图1对应的渲染节点1和与视图2对应的渲染节点2，渲染节点2的子节点为与视图3对应的渲染节点3。

其中，view与渲染节点对应的关系是指，渲染节点中包括有对应view中的所有绘制操作。

渲染线程在收到UI线程同步的渲染树后，调用OpenGL接口在应用程序自己的surface上渲染出位图，并将surface发送给SurfaceFlinger等待合成、送显。

值得说明的是，构建阶段需要占用CPU的计算资源，渲染阶段需要占用GPU的资源。

值得说明的是，若不开启硬件加速，则应用程序通过UI线程完成构建阶段、渲染阶段的所有操作，并且不需要封装为渲染节点，在遍历应用程序的视图后以及视图的绘制操作后，向SurfaceFlinger申请一块匿名共享内存，在该内存上直接调用底层图形库生成一个位图。

值得说明的是，图2所示的内容为开启硬件加速情况下，应用程序生成位图的过程。当电子设备没有开启硬件加速的情况下，应用程序通过软件绘制生成位图。其中，软件绘制包括：

①让视图结构(viewhierarchy)失效，UI线程遍历该应用程序的视图，录制每个视图的绘制操作。②UI线程通过接口，例如Surface.lockCanvas()，获取一个用于绘制的软件画布(Canvas)，基于保存的绘制操作列表在该软件画布上进行绘制，生成位图。并且该软件画布位于应用程序生成的surface上。

其中，该应用程序持有的surface是SurfaceFlinger通过binder通信为该应用程序分配的。其中应用持有的surface的数量可以与应用当前的窗口(PhoneWindow)数量一致。

在介绍了应用程序生成位图的过程后，示例性的介绍合成位图的过程。

(1.2)SurfaceFlinger/HWC合成位图的过程

SurfaceFlinger是电子设备上的一个系统服务，用于向应用程序分配surface，并将一个或多个surface上的位图作为图层进行图层合成。HWC为电子设备中负责合成和显示的硬件抽象层(Hardware Abstraction Layer,HAL)的一个功能模块，向上层的SurfaceFlinger提供接口，向下调用底层硬件(如显示驱动，不包括GPU)的能力进行图层的合成。

如图4所示，应用程序的渲染线程在SurfaceFlinger为其分配的surface上生成位图。SurfaceFlinger以BufferQueue的机制维护一个或多个应用程序的surface，即SurfaceFlinger可以获得不同应用程序的位图。

在SurfaceFlinger获取到一个或多个应用程序的位图后，可以调用GPU将多个位图合成为一个位图(位图的合成称为图层合成)，该合成也可以称为Client合成或GLES合成。

在SurfaceFlinger获取到应用程序的位图后，可以通过HWC调用底层硬件(不包括GPU)进行合成，该合成方式也称为Device合成。

其中，Client合成需要调用GPU，Client合成可以合成多个图层，并对图层完成如线性加深等涉及逐像素处理方式的合成。

其中，Device可以合成有限数量的图层，并且不支持很多种逐像素处理方式的合成。Device合成在合成多个在屏幕上位置没有交集的图层的情况下，可以不进行图层合成，而是在显示屏幕不同位置时读取不同surface中的数据进行显示。

如图4所示，SurfaceFlinger获取到应用程序1的位图1、应用程序2的位图2、…、应用程序N的位图N后，可以对位图1和位图2进行Client合成生成位图11。其次，SurfaceFlinger将位图11和位图N通过HWC调用底层硬件进行Device合成。

Device合成会暂时保存位图11和位图N，并在电子设备的屏幕需要显示的时候，从位图11/位图N取对应的像素显示在屏幕上。例如，在图1B所示的界面中，位图11为短信应用程序和新闻应用程序合成的位图，位图N为状态栏的位图。

对于SurfaceFlinger或者HWC对应的底层硬件来说，每个位图相当于一个图层(Layer)。

图层合成方式可以由HWC对应的底层硬件确定，也可以由SurfaceFlinger确定。

例如，其一，SurfaceFlinger在获取到位图后，通过HWC将图层的集合传递给底层硬件，由底层硬件决定哪些图层进行Client合成，哪些图层进行Device合成。底层硬件会为图层列表中的图层标注合成方式，并将不同图层的合成方式返回给SurfaceFlinger，由SurfaceFlinger将标注为GPU合成的图层进行合成，并将合成的结果放入一个缓冲中。SurfaceFlinger将该缓冲与其他标注为Overlay合成方式的图层通过HWC传递给底层硬件，进而由底层硬件完成图层的合成。

又例如，其二，SurfaceFlinger会将图层合成过程中涉及窗口动画等触发离屏渲染逻辑的图层直接标记为GPU合成。其中，涉及触发离屏渲染逻辑还包括如圆角、缩放、旋转、颜色转换等HWC对应的底层硬件无法处理的逻辑。

由于应用持有的SurfaceFlinger为其分配的surface中除了包含有应用渲染线程生成的位图，还包括从窗口管理服务处获得的图层Z序等窗口控制信息。所以SurfaceFlinger可以从surface上获取图层的窗口控制信息，进而确定图层是需要GPU合成。其中，图层Z序决定图层在Z轴上的高低顺序，其中Z轴为与屏幕垂直的方向，用于计算不同图层的上下关系。

图5为本申请实施例提供的图层合成的一个示例性示意图。

如图5所示，SurfaceFlinger获取到应用程序的位图后，将每个位图作为一个图层写入到图层列表中。SurfaceFlinger将图层列表通过HWC传递给底层硬件，底层硬件根据自己的能力决定不同图层的合成方式后，将结果返回通过HWC返回给SurfaceFlinger。

SurfaceFlinger获取HWC返回的结果后，可以得知图层列表中每个图层的合成方式。对于标注为GPU合成的图层，SurfaceFlinger进行图层的合成，并且将合成的图层与标注为overlay合成的图层一起通过HWC传递给底层硬件，进而通过HWC对应的底层硬件进行图层的合成。

SurfaceFlinger在拿到多个surface后，可以确定多个每个surface上的位图作为图层的合成方式。SurfaceFlinger拿到多个图层后，并且确定图层的合成方式为GPU，则可以进行Client合成。其中图层的合成模式可以包括：Mode.CLEAR(显示位于Z序顶层的图层)、Mode.SRC_OVER(按照Z序依次显示各个图层)、Mode.DST_IN(显示Z序顶层的图层与该图层下层图层不交集的部分)等。

例如，如图6所示，当图层的合成模式为Mode.SRC_OVER时，SurfaceFlinger会将三个图层的内容合成，按照图层的Z序决定不同图层的上下关系，依次叠加到一个图层上。

图层1的Z序为a，图层2的Z序为a+1，图层3的Z序为a+2，SurfaceFlinger会将三个图层的内容合成后，图层1和图层2的内容被完全遮蔽，只显示有图层3的内容。

其中，完全遮蔽是指由于Z序较高的图层遮蔽，Z序较低的图层上的视图完全不会显示。

进行GPU合成的图层均会触发离屏渲染，通过离屏渲染进行图层合成。下面介绍离屏渲染的相关概念。

(1.3)离屏渲染

在SurfaceFlinger确定任意多个图层需要通过GPU进行图层合成的情况下，需要开启离屏渲染(off-screen rendering)完成图层合成。

其中，离屏渲染为SurfaceFlinger申请一块离屏缓冲(off-screenbuffer)，并在该离屏缓冲调用GPU进行图像处理。该离屏缓冲为当前屏幕缓冲区外的一块内存，并在该离屏缓冲中合成多个图层。

离屏渲染可以包括以下几个步骤：

①需要将SurfaceFlinger确定的GPU合成的图层中的位图转换为纹理(texture)上传到GPU内存(即off-screenbuffer)中或者通过共享内存映射为OpenGL的纹理，然后OpenGL绑定该纹理(绑定该纹理包括绑定上下文context)。

②依据图层对应的涉及窗口动画的指令中渲染该纹理。并将多个应用程序的纹理进行合并，其中，图层合并根据图层的合成模式进行逐像素渲染处理。

③SurfaceFlinger从GPU内存上获取该渲染后的纹理或者从共享内存中直接获取该渲染后的纹理。

很显然的，离屏渲染会导致上下文(context)的切换，而上下文的切换增加了额外的性能开销。

结合(1.1)应用程序生成位图的过程、(1.2)SurfaceFlinger/HWC合成位图的过程、(1.3)离屏渲染中的内容，下面完整的介绍位图作为图层的合成的过程。

如图7A所示，不同的应用程序的UI线程独立的生成各自的渲染树，并将渲染树传递给各自的渲染线程进行渲染以生成位图。

渲染线程首先依据渲染树中的渲染节点中的属性和绘制指令列表渲染生成位图，并将位图作为图层进行合成。在图层的合成方式为GPU合成的情况下，SurfaceFlinger通过离屏渲染将多个图层合并成一个图层。

例如，应用程序1生成渲染树1，然后基于渲染树1生成位图1，应用程序2生成渲染树2，然后基于渲染树2生成位图2。SurfaceFlinger在接收到位图1和位图2后，对位图1和位图2进行离屏渲染，生成位图5。其中，离屏渲染的过程中，首先将位图1拷贝到离屏缓冲中，基于窗口动画的信息，在离屏缓冲中将位图1变换为位图3；类似的，将位图2变换为位图4；最后，将位图3和位图4依据图层合成的模式叠加生成位图5。

如图7B所示，要实现图1B所示的界面，SurfaceFlinger在收到应用程序的位图后，首先对窗口动画位图涉及的应用程序的位图进行离屏渲染以完成变换，然后将变换后的图层拷贝到在屏缓冲中，进而用于送显。

例如，应用程序3的位图需要进行缩小，则不能应用程序3的位图不能直接拷贝到在屏缓冲上进行变换，可能会影响到的其他应用程序的位图，而是需要拷贝到离屏缓冲上单独进行变换，将变换后的结果拷贝回在屏缓冲。

很显然的，只有先对每个应用程序生成的位图进行变化，然后依据图层合成的模式进行叠加才能生成正确的界面。

其中，从应用程序的主线程生成渲染树开始，到SurfaceFlinger图层合成完成，由于调用GPU的进程一直在变化(从应用程序1到应用程序2、…、应用程序N、SurfaceFlinger)，至少需要单独启动N+1次GPU，其中N为应用程序的个数。

可以理解的是，由于不同的应用程序独立的构建、渲染自己的位图，但是图层合成时图层Z序低的图层可能被Z序高的图层完全遮蔽，不可避免的导致不同应用程序的位图的过渡绘制(Overdraw)，例如图6中三个图形重叠的部分发生了过度绘制，即图层1和图层2为过渡绘制，合成后的界面不受图层1和图层2的影响；其次，离屏渲染需要新分配离屏缓冲，切换上下文，增加电子设备的内存开销和计算开销。

(2)其次，下面介绍本申请实施例提供的界面生成方法

本申请实施例提供的界面生成方法，首先，通过UniRender进程获取一个或多个应用程序的渲染树，并将一个或多个渲染树进行重新组合生成目标渲染树；其次，UniRender进程基于目标渲染树进行渲染以直接得到承载该一个或多个应用程序界面图像信息的位图，不用进行图层的合成。

首先，本申请实施例提供的界面生成方法通过将一个或多个应用程序的目标渲染树合并为目标渲染树。在生成目标渲染树的过程中，UniRender进程确定每个图层的离屏渲染逻辑，并根据离屏渲染逻辑去增加或修改目标渲染树中对应渲染节点的属性，进而使得UniRender进程直接生成位图，不用进行离屏渲染。

其次，本申请实施例提供的界面生成方法通过将一个或多个应用程序的目标渲染树合并为目标渲染树，无需先生成多个位图作为图层进行合成。UniRender进程在根据目标渲染树进行渲染生成位图的过程中，将图层的Z序作为渲染树的Z序，可以删减不显示或者不影响显示的view对应的渲染节点，进而避免过度绘制。

最后，本申请实施例提供的界面生成方法可以使得应用程序不用生成渲染线程，而是交由UniRender进程进行统一渲染，进而有助于提升界面渲染的速度。

(2.1)本申请实施例提供的界面生成方法的系统架构

当应用程序的界面更新时，应用程序可以向UniRender进程请求垂直同步信号(Vsync-APP)，(SurfaceFlinger未在图8中示出)在SurfaceFlinger存在的情况下，应用程序可以向SurfaceFlinger请求垂直同步信号(Vsync-APP)。

其中，UniRender进程的垂直同步信号(Vsync-APP)可以来自于SurfaceFlinger或者直接来自于HWC对应的底层硬件(如屏幕)产生或者由UniRender进程开启一个定时唤醒的线程产生垂直同步信号(Vsync-APP)。在SurfaceFlinger存在的情况下，Vsync-APP可以来自于SurfaceFlinger。

在应用程序获取到垂直同步信号(Vsync-APP)后，应用程序生成渲染树并将渲染树传递给UniRender进程。

UniRender进程在接收到垂直同步信号(Vsync-UR)，将一个或多个渲染树进行合并，生成目标渲染树。然后，UniRender进程使用渲染引擎遍历执行渲染树中每个渲染节点中的绘制指令列表中的绘制操作，生成承载一个或多个渲染树图像信息的位图。其中，该位图可以位于在屏缓冲中。

其中，Vsync-UR与Vsync-APP的差为Vsync-Offset，Vsync-Offset可以由UniRender进程确定。在SurfaceFlinger存在的情况下，Vsync-Offset可以由SurfaceFlinger确定。

UniRender进程在生成位图后，将该位图通过HWC传递给显示子系统，进而送显。

在介绍了本申请界面生成方法的系统架构后，示例性的介绍本申请实施例提供的界面生成方法的方法流程。

(2.2)本申请实施例提供的界面生成方法的方法流程

下面结合图9示例性的介绍本申请实施例提供的界面生成方法。

如图9所示，本申请实施例提供的界面生成方法包括：

S901：接收到垂直同步信号后，构建生成渲染树

应用程序在界面需要更新的时候，可以向UniRender进程请求垂直同步信号(Vsync-APP)。应用程序在接收到垂直同步信号后，在UI线程中执行measure()方法、layout()方法、draw()方法。其中，UI线程在执行draw()方法中，会遍历应用程序的view，确定每个view渲染需要的绘制指令，不断记录/录制到该view对应的渲染节点的绘制指令列表中。

其中，应用程序需要显示的界面由多个view嵌套组成，与根视图(DecorView)对应的绘制指令列表中包括有根视图的子视图的绘制指令列表入口，即绘制指令列表之间的嵌套关系与view的嵌套关系相同，故渲染节点的嵌套关系与view的嵌套关系相同。其中，关于渲染树、渲染节点的相关概念的定义可以参考上文中图3对应的文字描述。

图10为本申请实施例提供的构建渲染树的一个示例性示意图。

应用程序UI线程在进行measure、layout、draw后，可以得到自己要更新的界面的多个view的父子结构，并在遍历view的过程中，确定每个view上要展示的内容以及生成该内容所需要的接口调用，如drawCircle、drawLine等等。

应用程序在将drawCircle、drawLine等绘制接口调用封装为对应的DrawOp如DrawCircleOp、DrawLineOp，并保存在绘制指令列表中。DrawLineOp为底层图形库(如OpenGL)的绘制图形的接口调用，会进一步转换为调用GPU的绘制图形的指令。

如图10所示，应用程序的界面的视图结构为：根视图，根视图的子视图为视图1和视图2，视图2的子视图为视图3。其中，视图2中包括矩形、圆形，则视图2对应的渲染节点2中绘制指令列表中的绘制操作包括：绘制矩形的操作，绘制圆形的操作等。

应用程序的UI线程在执行draw()方法时，可以从根视图开始，依据View之间的父子关系，遍历所有的view，确定每个view中的绘制操作，并将绘制操作封装为DrawOp。应用程序的UI线程在生成绘制指令列表后，会进一步的将绘制指令列表封装为渲染树。

渲染树中的渲染节点包括绘制指令列表和渲染属性，其中，渲染属性用于决定该渲染节点要渲染的view在surface中的位置、大小、透明度等属性，绘制指令列表用于决定该渲染节点要渲染的view的内容，如线条、矩形、圆形等。

该surface为应用程序申请的，应用程序自己决定该surface的大小。在SurfaceFlinger存在的情况下，该surface可以是应用程序向SurfaceFlinger申请的，在SurfaceFlinger不存在的情况下，可以是向UniRender进程申请的。其中，SurfaceFlinger可以不向该应用程序分配surface。

可选的，在本申请一些实施例中，UniRender进程可以确定每个显示区域的屏幕刷新率后，调整每个显示区域上垂直同步信号(Vsync-APP)的频率，使得在显示区域1上显示的应用程序以显示区域1的屏幕刷新率的频率生成渲染树。

值得说明的是，一个应用程序的UI线程可以生成多个渲染树，例如在多屏幕、虚拟屏、多窗口场景下等多显示区域(display)场景中，其中，多显示区域场景可以参考(2.2)多显示区域场景下的界面生成方法中的文字描述。

S902：跨进程传递渲染树

应用程序的UI线程在生成渲染树后，会将渲染树通过IPC通信传递给UniRender进程。其中，渲染树在应用程序对应的进程的栈上。对应的UniRender进程需要接收不同应用程序传递的渲染树，并确定渲染树和应用程序的对应关系。

其中，位于前台的多个应用程序向UniRender传递渲染树。若该应用程序满足一下三个条件中的任意一个，该应用程序为前台应用，该应用程序具有可见的活动(Activity)、该应用程序具有前台服务、其他前台应用程序关联到该应用。

由于不同的进程的内存是不共享的，进程之间进行数据交互需要通过进程间通信(InterProcess Communication,IPC)完成。其中，应用程序向UniRender进程传递渲染树可以通过如Binder、AIDL、共享内存、Socket等方式实现IPC通信，在此不作限定。

下面以共享内存作为IPC通信的示例，示例性的介绍跨进程传递渲染树的方式。

(a)应用程序将渲染树写入共享内存

如图11所示，首先，应用程序在每次启动时，会向UniRender进程申请共享内存。UniRender进程在接收到应用程序发起的共享内存的请求后，通过匿名共享内存(Anonymous Shared Memory,Ashmem)子系统申请一块共享内存以及与该共享内存对应的句柄。

其次，UniRender进程在向Ashmem子系统申请共享内存成功后，会收到Ashmem子系统返回的句柄用于读写物理内存。UniRender进程将句柄返回给应用程序，使得应用程序可以使用该句柄往物理内存中写入渲染树。UniRender进程可以直接从自己的进程空间中读取该物理内存，进而直接读取应用程序的渲染树。

其中，该共享内存可以是通过临时文件系统(tmpfs)在内存(RAM)中建立的虚拟文件，分别映射到不同进程的用户空间中。

其中，应用程序向UniRender进程申请共享内存，UniRender进程向Ashmem子系统申请共享内存、UniRender进程向应用程序返回申请获得的共享内存对应的句柄等跨进程通信可以通过Binder通信实现。

可以理解的是，通过共享内存等其他IPC方式，可以将存储于应用进程的栈上的渲染树传递给UniRender进程，在此不做限定。

可选的，在本申请一些实施例中，电子设备的本地的配置文件或者云端的服务器上配置有白名单，白名单中保存有应用程序的包名等其他能够唯一确定应用程序进程的标识。在应用程序属于白名单的情况下，将渲染树传递给UniRender进程；在应用程序不属于白名单的情况下，由UI线程软件绘制或者渲染线程渲染成位图后，将位图传递给UniRender做进程合成或者将位图传递给SurfaceFlinger，由SurfaceFlinger将该不属于白名单的应用程序的位图和UniRender进程生成的位图进行合成。

可选的，在本申请一些实施例中，应用程序具有多个图层的情况下，即应用程序生成多个渲染树的情况下，应用程序可以向UniRender进程申请两块共享内存，分别用于存储不同的图层，即存储不同的渲染树的数据。

可选的，在本申请一些实施例中，应用程序可以向UniRender进程申请两块共享内存，用于交错的写入渲染树。例如，即某一帧界面对应的渲染树写入第一块共享内存，则下一帧界面对应的渲染树写入第二块共享内存；再下一帧界面对应的渲染树写入第一块共享内存。进而，有助于读写冲突导致在只有一块共享内存的情况下，不能及时往共享内存中写入渲染树的数据。

(b)渲染树在共享内存的存储数据结构

为了进一步提高IPC通信的效率，在本申请实施例中，渲染树以内存树的形式保存在共享内存中。下面示例性的介绍渲染树在共享内存中的保存的数据结构形式：

其中，内存树可以由多段数据组成，不同段的数据分别存储图层信息、渲染数据等。下面以图12A、图12B所示的内容为例，示例性的介绍内存树的结构。其中，不同段的数据在共享内存中的偏移可以是固定的，也可以是不固定的、自适应的。

如图12A所示，渲染树的存储结构包括三段数据，分别为HEAD字段、MAPPING字段、NODES字段。

其中，HEAD字段中包括layerkey、rootid；MAPPING字段包括nodeid以及和nodeid对应的address；NODES字段包括currentproperties、stagingproperties、stagingdisplaylist、currentdisplaylist。

其中，layerkey为渲染树整体作为一个图层的ID；rootid为该渲染树的根节点的ID；nodeid为渲染树的除根节点外的渲染节点的ID，并且一个nodeid与一个address对应，该address为该渲染树节点中的渲染属性(renderproperties/properties)和绘制指令列表(displaylist)的起始地址；stagingproperties为应用程序写入的渲染属性、stagingdisplaylist为应用程序写入的绘制指令列表、currentproperties为UniRender进程读取的渲染属性、currentdisplaylist为UniRender进程读取的绘制指令列表。

值得说明的是，认为“stagingproperties和stagingdisplaylist”为第一组数据，“currentproperties和currentdisplaylist”为第二组数据，则在应用程序写入的数据为第一组数据，下次应用程序写入数据为第二组数据，实现双缓冲机制；类似的，UniRender进程读取的数据为第一组数据，下次读取的数据为第二组数据。

可选的，在本申请一些实施例中，共享内存中渲染树的存储结构可以如图12B所示，其中NODES字段可以只包括一组数据，即只包括渲染属性和绘制指令列表。

layerkey用于：UniRender进程在通过句柄读取共享内存中的图层数据前，可以从WMS获取需要显示应用程序以及该应用程序的需要参与图层合成的图层ID。UniRender进程将该图层ID与从共享内存中layerkey中包括的图层ID进行校验。

rootid用于：rootid作为渲染树的入口，存储有其他渲染节点的入口，UniRender进程在得到rootid后可以读取渲染树的数据，并将渲染树的嵌套结构恢复出来。

currentproperties、stagingproperties、stagingdisplaylist、currentdisplaylist用于：应用程序完成写入绘制指令列表和渲染属性后，交换currentproperties、stagingproperties的值，交换currentdisplaylist、stagingdisplaylist的值，UniRender进程从currentproperties和current displaylist中读取渲染属性和绘制指令列表。

例如，应用程序1为在前台显示的应用，应用程序1可以有多个图层，即该应用程序1在接收到垂直同步信号(Vsync-APP)后，会生成多个渲染树，如渲染树1和渲染树2。UniRender进程从WMS中确定参与图层合成的图层对应的渲染树为渲染树1。

由于layerkey和rootid的偏移固定，进而UniRender进程可以确定根节点的地址。UniRender进程在MAPPING段找到根节点在NODES端的位置，读取渲染该节点的渲染指令，如果有子节点，会有对应的DrawRenderNode指令，其中保存着子节点的id，通过哈希值找到子节点在MAPPING段的位置。例如，渲染树的渲染节点的父子关系会保存在DrawOP操作中。例如，渲染节点2的绘制指令列表中包括若干个DrawOP操作以及“Draw RenderNode3”(画渲染节点3)的操作，进而UniRender进程可以确定渲染节点3是渲染节点2的子节点。

可以理解的是，共享内存中的渲染树仍然保存有与应用程序的view相同的嵌套关系，所以，UniRender进程可以从根节点开始读取数据，进而读取到全部的渲染树的数据。

其中，通过划分currentproperties、stagingproperties、stagingdisplaylist、currentdisplaylist，保证UniRender进程读取的送显数据和应用程序写入数据的安全性，避免应用程序写入一半的数据被UniRender进程当做最新的数据读取去渲染生成应用程序的界面。其中，关于渲染树同时读写的安全性保障可以参考下文中(2.3)对在共享内存中的渲染树的读写中的文字描述，此处不在赘述。

可选的，在本申请一些实施例中，三段数据的大小可以是固定的。即，当UniRender进程向Ashmem子系统申请共享内存后，得到共享内存为大小为(a+b+c)大小的内存。其中，从起始地址(物理地址)至起始地址+a为填充HEAD字段的位置；从起始地址+a+1至起始地址+a+b为填充MAPPING字段的位置；从起始地址+a+b+1至起始地址+a+b+c为填充NODES字段的位置。

可以理解的是，三段数据的大小是固定的情况下，UniRender进程可以根据固定的偏移量确定每段数据的起始，进而可以找到Mapping段，Mapping段中保存有渲染树的渲染节点在NODES字段中的偏移，进而可以找到每个渲染节点的数据。

可选的，在本申请一些实施例中，当三段数据的大小是固定的情况下，应用程序写入的渲染节点超过b的大小，则向UniRender进程申请第二块共享内存。其中，第二块共享内存可以与第一块共享内存的格式一样，并在第二块共享内存的NODES字段继续存储渲染节点的绘制指令列表和渲染节点属性。其中，第二块共享内存的HEAD字段和/或MAPPING字段可以为空或者可以不存在。即，在本申请一些实施例中，第二块共享内存中只包括NODES字段。

(c)UniRender读取共享内存中的渲染树

(c.1)UniRender架构

如图13所示，本申请提供的UniRender可以包括四部分，分别为NodeManager、LayerManager、DisplayManager、UniRenderCore。

其中，NodeManager为UniRender进程内的节点管理模块，负责接收应用程序发送的渲染树等。其中，目标渲染树的合成可以参考步骤S903中的文字描述。

其中，LayerManager为UniRender进程内的图层管理模块，负责从窗口管理服务(Window Manager Service,WMS)同步图层信息如图层创建、销毁、属性变更等。其中，一个位图相当于一个图层。

其中，DisplayerManager为UniRender进程内的显示设备管理模块，负责从显示管理服务(Display Manager Service,DMS)同步显示设备的信息，如屏幕的大小等。

其中，UniRenderCore为UniRender进程内的渲染管理模块，负责：对每个图层建立对应的渲染节点；接收NodeManager中维护的不同应用程序对应的渲染树，从LayerManager中去除该应用程序的图层信息指令化并插入渲染节点；对DisplayManager中维护的处于激活状态的显示设备，将其所有可见的图层对应的渲染树合并；对每个显示区域遍历合并后的渲染树，UniRender为其分配的buffer上生成位图等。

(c.2)UniRender读取渲染树

UniRender进程首先从DMS和WMS中确定每个显示区域上显示的应用程序，这些应用程序即为参与图层合成的应用程序。其中，UniRender进程可以进一步结合白名单确定在UniRender进程进行图层合成的应用程序。其中，UniRender进程通过WMS可以确定每个应用程序的图层ID。

其中，由UniRender进程中的DisplayerManager负责和DMS进行通信，由UniRender进程中的LayerManager负责和WMS进行通信。

由于UniRender进程保存有与应用程序对应的共享内存的句柄，UniRender在确定参与图层合成的应用程序后，可以通过句柄确定该应用程序对应的共享内存。UniRender通过该句柄从共享内存中读取渲染树。

其中，由UniRender进程中的NodeManager负责管理共享内存的句柄，并从共享内存中读取渲染树。

UniRender进程从共享内存中读取渲染树的过程包括：

首先，UniRender进程从共享内存的起始地址处读取layerkey，校验图层ID。其中，UniRender进程从WMS确定的图层ID去比对从layerkey中确定的图层ID，当校验一致后，UniRender进程从根节点rootid开始读取渲染树。

其次，UniRender进程在找到根节点的地址后，在MAPPING段中的address字段确定根节点在NODES段的起始地址，开始读取该渲染节点的绘制指令列表和渲染属性。其中，若根节点具有子节点，则在根节点的绘制列表指令中存有子节点的入口，如DrawRenderNode指令。由于DrawRenderNode指令中包括有子节点的ID，UniRender进程通过哈希运算在MAPPING段找到对应的nodeid，进而可以确定子节点的绘制指令列表和渲染属性在NODES段的位置，并读取到子节点的绘制指令列表和渲染属性。

(d)对在共享内存中的渲染树的读写

位于共享内存中的渲染树可以被两个或更多个进程读写，为了减少、避免读写冲突导致渲染树的数据发生错误，可以通过配置进程间的同步锁来保障渲染树的读写安全。

下面结合图14、图15所示的内容示例性的介绍读写渲染树的过程。

每个应用程序保存有至少一个锁变量A，以避免应用程序和UniRender同时对共享内存进行读和写。其中，UniRender通过IPC通信获取不同应用程序上锁变量的状态(持有或者释放)。

如图14所示，①首先，当应用程序需要更新界面时，请求并接收垂直同步信号(Vsync-APP)，然后拿到本应用程序对应的共享内存的锁变量A，从根节点开始对渲染节点的属性和绘制指令列表进行计算和更新。

②其次，应用程序将更新后的渲染节点的属性和绘制指令列表写入到共享内存中NODES段的stagingproperties和stagingdisplaylist数据段中，并且发生改变的渲染节点id加入到properties_dirty队列和displaylist_dirty队列中，该队列保存在应用侧的共享内存管理类单例中。

可以理解的是，properties_dirty队列和displaylist_dirty队列中标记有改变的渲染节点，可以实现差量的更新渲染树。

可选的，在本申请一些实施例中，可以不保存properties_dirty队列和displaylist_dirty队列，实现全量的渲染树更新。

③再次，应用程序将properties_dirty队列中对应渲染节点的stagingproperties段拷贝到currentproperties段。应用程序将displaylist_dirty队列中对应渲染节点的draw_pointer与record_pointer进行交换，即将displaylist_dirty队列中对应渲染节点的stagingdisplaylist段拷贝到currentdisplaylist；或者应用程序将stagingdisplaylist段拷贝到currentdisplaylist。

可以理解的是，由于相比上一个垂直同步信号(Vsync-APP)，响应于本次垂直同步信号(Vsync-APP)，应用程序只改变了displaylist_dirty对应的渲染节点的数据，应用程序将displaylist_dirty队列中对应渲染节点的draw_pointer与record_pointer进行交换，则可以实现差量更新currentdisplaylist。

可以理解的是，应用程序将stagingdisplaylist段拷贝到currentdisplaylist，可以实现全量的更新，即将应用程序响应于该垂直同步信号(Vsync-APP)生成的渲染树的全部数据直接写入到共享内存，实现较为简单。

可选的，在本申请一些实施例中，在不保存properties_dirty队列和displaylist_dirty队列的情况下，应用程序所有渲染节点的stagingproperties段拷贝到currentproperties段、stagingdisplaylist段拷贝到currentdisplaylist段。其中，这种拷贝可以通过改变指针的位置实现。

④再次，应用程序通过IPC通信传递锁变量A已经释放的信息至UniRender进程。

⑤再次，UniRender进程持有锁变量A。

⑥最后，与③对应的，UniRender进程从共享内存中读取current displaylist、current properties，或者读取displaylist_dirty队列中对应渲染节点的stagingdisplaylist段拷贝到currentdisplaylist。

UniRender进程在读取完数据后，可以释放锁变量A，并通知应用程序锁变量A已经释放。进而在下一个垂直同步信号(Vsync-APP)到来时，持有锁变量A，进而往共享内存中写入渲染树。此时，staging数据段和current数据段的作用互换，UniRender进程最后读取stagingdisplaylist和stagingproperties段，实现“双缓冲”机制，保证界面生成的稳健性。

可选的，在本申请一些实施例中，在应用程序和UniRender进程之间存在一个锁变量的情况下，NODES字段可以只包括stagingdisplaylist和stagingproperties，或者只包括currentdisplaylist和currentproperties。其中，应用程序和UniRender进程通过锁变量实现读写安全，使得UniRender进程读取到正确的渲染树。

可选的，在本申请一些实施例中，每个应用程序可以持有更多个锁变量，例如，每个应用程序持有锁变量A和锁变量B。进而，在应用程序释放锁A后，无需等待UniRender释放锁A，持有锁变量B后，在收到下一个垂直同步信号(Vsync-APP)后，直接往共享内存中写入渲染树数据。

其中，锁变量B的持有、释放、进程间的同步与锁变量A的持有、释放、进程间的同步相同，具体的可以参考图14所示的文字描述，此处不再赘述。

如图15所示，当应用程序保存有一个锁变量A时，在接收到垂直同步信号1(Vsync-APP)后，由应用程序持有锁变量A，并在持有阶段将生成的渲染树写入共享内存中。在应用程序将渲染树写入共享内存后，释放锁变量A。UniRender在确定锁变量A被应用程序释放后，持有锁变量A，开始从共享内存中读取应用程序响应于垂直同步信号1生成的渲染树。

在UniRender进程持有锁变量A的时间内，应用程序收到垂直同步信号1后的垂直同步信号2(Vsync-APP)，由于锁变量A被UniRender进程持有，应用程序不能及时的将渲染树写入共享内存中，需要等待一段时间直到应用程序确定UniRender进程释放锁A。

但是，很显然的，在图13中内容，UniRender进程读取currentdisplaylist字段、currentproperties字段，而应用程序写入stagingdisplaylist字段、stagingproperties字段，可以通过增加锁变量的个数实现共享内存中不同字段的并发读写。

如图15所示，当应用程序保存有两个锁变量B时，在接收到垂直同步信号1(Vsync-APP)后，由应用程序持有锁变量A，并在持有阶段将生成的渲染树写入共享内存中。在应用程序将渲染树写入共享内存后，释放锁变量A。UniRender进程在确定锁变量A被应用程序释放后，持有锁变量，开始从共享内存中读取应用程序响应于垂直同步信号1生成的渲染树。

在UniRender进程持有锁变量A的时间内，应用程序收到垂直同步信号1后的垂直同步信号2(Vsync-APP)，此时持有锁变量B，应用程序可以及时的将渲染树写入共享内存中，不需要等待一段时间直到应用程序确定UniRender进程释放锁A。

对应的，UniRender进程在确定锁变量B被应用程序释放后，持有锁变量B，开始从共享内存中读取应用程序响应于垂直同步信号2生成的渲染树。

值得说明的是，应用程序持有锁变量的个数可以与共享内存中NODES字段中包括的内容有关，或者可以与Vsync-offset的值有关。

例如，认为currentdisplaylist、currentproperties为第一组、stagingdisplaylist、stagingproperties为第二组，则可以在应用程序和UniRender进程中配置两个同步锁变量，分别对应两组数据。类似的，又例如，NODES字段中包括三组数据，则可以在则可以在应用程序和UniRender中配置三个同步锁变量。

其中，一个锁变量与一组数据对应，例如，锁变量A与currentdisplaylist、currentproperties对应，则锁变量A从持有状态到释放状态的变化表示应用程序成功更新共享内存中currentdisplaylist、currentproperties的数据，currentdisplaylist、currentproperties的数据可以被UniRender进程读取；或者，锁变量A从持有状态到释放状态的变化表示UniRender进程以及从共享内存中完成对currentdisplaylist、currentproperties的数据的读取，currentdisplaylist、currentproperties的数据可以被应用程序更新。

其中，锁变量的个数可以与Vsync-offset的值有关。

即，可以与垂直同步信号(Vsync-APP)与垂直同步信号(Vsync-UR)的差值Vsync-offset有关。在Vsync-offset较大的情况下，可以不配置锁变量。在不配置锁变量的情况下，UniRender进程在接收到垂直同步信号(Vsync-UR)后，从共享内存中读取渲染树。由于Vsync-offset较大，故在UniRender进程读取渲染树的时刻，应用程序已经完整的将渲染树写入到共享内存中。

S903：传递应用程序的窗口控制信息和显示区域信息

UniRender进程中的LayerManager从窗口管理服务获取一个或多个应用程序的窗口控制信息，进而结合步骤S802中获取的该一个或多个应用程序的图层，确定任意一个应用程序的图层上是否存在触发离屏渲染的绘制逻辑。

UniRender进程还可以获取不同应用程序的图层之间的Z序。其中，Z序为不同图层之间的Z轴的上下顺序。

UniRender进程中的DisplayerManager从显示管理服务获取显示区域信息，显示区域信息包括显示设备的大小。UniRender进程基于显示区域信息确定分配的surface的大小，该surface用于承载UniRender基于目标渲染树生成的位图。其中，UniRender进程基于目标渲染树生成位图可以参考步骤S905中的文字描述，此处不再赘述。

其中，涉及离屏渲染的指令包括如圆角、缩放、旋转、颜色转换等指令；离屏渲染的定义可以参考上文中(1.3)离屏渲染中的文字描述，此处不再赘述。

下面示例性的介绍圆角、缩放、旋转、颜色转换等涉及触发离屏渲染的绘制逻辑。

响应于用户的交互，如全面屏的手势(如从底部向上滑动至屏幕中央)或者点击底部导航栏的多任务控件，电子设备显示多任务界面如图16A所示。

其中，图库应用程序生成的位图与屏幕大小相同，而在如图16A所示的多任务界面中图库应用程序的界面是被缩放、圆角处理后的界面。

如图16B所示，在小窗模式下，电子设备的界面上显示有多个应用程序的视图。其中，部分应用程序的界面位于悬浮窗中。

例如，电子设备的界面上显示有新闻应用程序和短信应用程序的界面，其中，短信应用程序的界面位于渲染悬浮窗中。

其中，短信应用程序生成的位图与屏幕大小相同，而在如图16B所示的小窗模式中，短信应用程序的界面是被缩放、圆角处理后的界面。

如图16C所示，响应于用户在桌面应用程序点击阅读应用程序的图标，电子设备启动阅读应用程序。在阅读应用程序的启动过程中，阅读应用程序的主界面(Main Activity对应的界面)或启动窗口(startingwindow)不断放大。

其中，阅读应用程序的主界面或启动窗口对应的位图为屏幕大小，通过调整缩放比例进而实现不断放大的效果。其次，阅读应用程序的主界面或启动窗口对应的位图为被圆角处理后的位图，进而显示在电子设备的界面上。

可以理解的是，在图16A-图16C所示的场景以及其他更多的场景中，需要通过圆角、缩放、旋转、颜色转换，进而生成更符合用户视觉习惯的界面，提高用户体验。

值得说明的是，在图16A-图16C所示的场景以及其他更多的场景中，UniRender进程从窗口管理服务接收每个应用程序的图层的窗口控制信息，进而确定每个应用程序的图层是否需要进行圆角、缩放、旋转、颜色转换。

可选的，在本申请一些实施例中，UniRender进程可以先从窗口管理服务获取一个或多个应用程序的窗口控制信息，再获取到该一个或多个应用程序的渲染树，即步骤S902与步骤S903的发生时序可以互换。

S904：基于获得的渲染树以及窗口控制信息和显示区域信息生成目标渲染树

首先，UniRender进程接收到一个或多个应用程序生成的渲染树后，响应与接收到垂直同步信号以及窗口控制信息后，从窗口控制信息中确定每个应用程序的图层是否存在触发离屏渲染的逻辑。

其中，在应用程序显示在本地电子设备的显示区域上的情况下，窗口控制信息可以来自于本地的窗口管理服务；在应用程序显示在其他电子设备的显示区域上的情况下，窗口控制信息可以来自于对端电子设备的窗口管理服务。

若UniRender进程确定任一个应用程序的图层存在触发离屏渲染的逻辑，则将UniRender进程将触发离屏渲染的逻辑转化为离屏渲染指令，并将离屏渲染指令转换到对应的渲染树的渲染节点的属性上。为了方便描述，UniRender进程将触发离屏渲染的逻辑转化为离屏渲染指令，并将离屏渲染指令转换到对应的渲染树的渲染节点的属性上这一过程可以简称为离屏渲染指令的前移。

然后，UniRender进程对一个或多个渲染树的触发离屏渲染指令进行前移后，对每个显示区域(display)，将每个显示区域的可见的图层对应的渲染树进行合并，生成目标渲染树。即，目标渲染树的数量可以与显示区域的数量有关。

其中，UniRender进程可以在接收到垂直同步信号(Vsync-UR)后，开始从共享内存中读取渲染树，并在获取到多个渲染树后进行离屏渲染指令的前移以及渲染树的合成。或者，UniRender进程可以在持有锁变量，开始从共享内存中读取渲染树，并在接收到垂直同步信号(Vsync-UR)，开始进行离屏渲染指令的前移以及渲染树的合成。

下面分别的介绍触发离屏渲染指令前移的过程以及生成目标渲染树的过程。

(a)触发离屏渲染的指令前移的过程

首先，UniRender进程在获取到每个应用程序图层的窗口控制信息，判断是否有图层的窗口控制信息中包含有触发离屏渲染的绘制逻辑。在UniRender进程确定一个显示区域的所有应用程序的图层的窗口控制信息均不包含有触发离屏渲染的绘制逻辑的情况下，可以直接将一个或多个渲染树合成为目标渲染树；在UniRender进程确定一个显示区域的任一个应用程序的图层的窗口控制信息均包含有触发离屏渲染的绘制逻辑的情况下，首先将触发离屏渲染的指令前移，然后将多个渲染树的合成为目标渲染树。

触发离屏渲染指令前移的过程：

UniRender进程首先从窗口控制信息中确定触发离屏渲染的绘制逻辑，并将触发离屏渲染的绘制逻辑转化为可以配置到渲染节点的渲染属性中的指令(或称为绘制逻辑指令化)。UniRender进程在确定图层和渲染树的绑定关系后，将离屏渲染指令更新到对应的渲染节点的渲染属性中。

其中，当渲染节点的渲染属性存在对应的缩放属性(scale)、圆角属性(roundrect)、颜色转换属性(colortransform)、旋转属性(transform)等，则将触发离屏渲染的指令中的缩放指令、圆角指令、颜色转换指令、旋转指令中的参数赋值给渲染节点的属性中的缩放属性、圆角属性、颜色转换属性、旋转属性；当渲染节点的渲染属性不存在对应的缩放属性、圆角属性、颜色转换属性、旋转属性等，则将为渲染节点增加缩放属性、圆角属性、颜色转换属性、旋转属性等，并将触发离屏渲染的指令中的缩放指令、圆角指令、颜色转换指令、旋转指令中的参数赋值给渲染节点的属性中的缩放属性、圆角属性、颜色转换属性、旋转属性等。

如图17A所示，在应用程序1和应用程序2的UI线程分别独立的生成渲染树并且独立的将渲染树通过IPC通信传递给UniRender进程后，UniRender进程从窗口管理服务确定各个应用程序的图层的触发离屏渲染的指令。其中，应用程序1生成的渲染树为渲染树1，应用程序2生成的渲染树为渲染树2。

UniRender独立的更新不同渲染树中的渲染节点的属性。即，UniRender进程更新渲染树1的渲染节点的属性，UniRender更新渲染树2中渲染节点的属性。

触发离屏渲染的指令作用于整个图层，则UniRender进程将离屏渲染的指令中的参数赋值给图层对应的渲染树的根节点上，或者直接赋值给渲染树的所有渲染节点上。

其中，在UniRender进程将离屏渲染的指令中的参数赋值给图层对应的渲染树的根节点的情况下，UniRender进程在基于渲染树生成位图时，会自动将该渲染节点的这些属性配置到该根节点的子节点的渲染属性上。

例如，渲染节点1的子节点为渲染节点2，则当渲染节点1的渲染属性被配置有旋转属性(transform)后，UniRender进程在生成渲染树时，会将相同的旋转属性(transform)配置给RenderNode2的渲染属性。

如图17B所示，在没有进行离屏渲染指令的前移前，SurfaceFlinger接收到应用程序生成的渲染树对应的位图后，需要基于窗口控制信息对不同应用程序的位图进行不同的处理，进而完成图层合成。

在对应用程序的渲染树进行离屏渲染指令的前移后，UniRender进程将离屏渲染的指令中的参数赋值到渲染树的渲染属性中，使得在基于渲染树生成位图的过程中，直接在画布上绘制出变换后的位图。由于不需要对不同应用程序的位图进行不同的处理，可以在一个在屏缓冲上序的绘制不同应用程序的位图。

其中，UniRender进程将离屏渲染的指令中的参数赋值到渲染树的渲染属性如图18所示。

如图18所示，UniRender进程对渲染树的根节点的属性修改，增加指令以实现增加渲染节点的属性。其中，缩放属性对应的指令为setScale()、圆角属性的指令对应的指令outline.setRoundRect()、颜色转换属性对应的指令为setColorFilter()、旋转属性对应的指令为setLeftTopRightBottom()等。

其中，在后文的步骤S905中，UniRender进程在基于渲染树生成位图时，会依据渲染属性，再根据渲染属性修改绘制指令列表中绘制操作，进而生成缩放、圆角、颜色转换、旋转后的位图。具体的可以参考步骤S905中的文字描述，此处不再赘述。

可选的，在本申请一些实施例中，渲染树的根节点的属性中的指令还可以包括指令setStaticMatrix()等。由于应用程序UI线程是基于向SurfaceFlinger申请的surface生成渲染树，故为了在步骤S905中UniRender基于渲染树生成位图时变换参考系，故在触发离屏渲染的指令前移的过程中，在渲染树的根节点中配置指令setStaticMatrix()。其中，指令setStaticMatrix()的具体内容可以参考下文中步骤S905中的文字描述，此处不再赘述。

(b)生成目标渲染树的过程

UniRender进程在对所有的渲染树进行离屏渲染指令前移处理后，得到一个或多个处理后的渲染树。

在处理后的渲染树的数量为一个的情况下，则该处理后的渲染树为目标渲染树；在处理后的渲染树的数量大于一个的情况下，对多个处理后的渲染树进行合成，合成为一个目标渲染树。

如图19所示，UniRender进程可以新建一个根渲染节点，如图19中的新根渲染节点，并将多个应用程序的处理后的渲染树作为根渲染节点的子节点。即，根渲染节点可以保存有不同的应用程序的处理后的渲染树的父子关系，可以使得UniRender进程从根渲染节点遍历目标渲染树找到不同的应用程序的处理后的渲染树。

UniRender进程可以先根据窗口管理服务确定不同应用程序对应的图层的Z序，即确定应用程序的图层之间的上下遮蔽关系。进而，在生成目标渲染树的过程中，将完全被遮蔽的view对应的渲染节点删除，进而降低在步骤S905中生成位图过程中的计算量，提高位图的生成速度。

例如，如图20所示，应用程序1生成的渲染树对应的图层为图层1，应用程序2生成的渲染树对应的图层为图层2。其中，图层1的Z序高于图层2的Z序。其中，图层1对应的渲染树为根渲染节点1、渲染节点1、渲染节点2、渲染节点3，渲染节点1和渲染节点2是根渲染节点1的子渲染节点，渲染节点3是渲染节点2的子渲染节点；图层2对应的渲染树为根渲染节点2、渲染节点4、渲染节点5、渲染节点6，渲染节点4和渲染节点5是新根渲染节点的子渲染节点，渲染节点6是渲染节点5的子渲染节点。

UniRender进程可以遍历的图层1对应的渲染树的渲染子节点以及图层2对应的渲染树的子节点，确定每个渲染节点对应的view在(UniRender进程分配的surface)surface中的位置，并结合图层1的图层Z序，图层2的Z序，确定被完全遮蔽的view，以及该被完全遮蔽view的渲染节点。

例如，UniRender可以确定图层2的对应的渲染树中的渲染节点6对应的view完全被遮蔽，进而将渲染节点6节点删除。

UniRender进程在删除被完全遮蔽的view对应的渲染节点后，可以按照如图18所示的内容将所有的触发离屏渲染指令前移处理后的渲染树合并为目标渲染树。

可选的，在本申请一些实施例中，UniRender还可以遍历渲染节点，从DrawOP绘制操作的粒度去优化目标渲染树的参数。例如，删除掉不影响界面的DrawOP绘制操作，其中不影响可以是DrawOP绘制操作绘制的图形不在界面上显示；又例如，对于不同应用程序，修改DrawOP操作在绘制节点中的位置，使得相同类型的DrawOP绘制操作可以一起执行，比如将应用程序1的渲染节点2的DrawOP绘制操作修改到应用程序2的渲染节点1的绘制指令列表中，在此不作限定。

可选的，在本申请一些实施例中，也可以按照如图18所示的内容将多个触发离屏渲染指令前移处理后的渲染树合并为一个渲染树后，再确定被完全遮蔽的view进而删除被完全遮蔽的view对应的渲染节点，生成目标渲染树。

可选的，在本申请一些实施例中，对于部分遮蔽的view，也可以通过clip指令剪裁该view对应的渲染节点。其中，剪裁可以在合成目标渲染树前，也可以在合成目标渲染树后。

可选的，在本申请一些实施例中，在步骤S904后，在步骤S905前，UniRender进程生成目标渲染树后对RenderNode的绘制指令列表中进行解封装得到一系列DrawOP，进而将目标渲染树作为整体进行DrawOP操作进行次批次(Batch)和合并(Merge)，在步骤S805中得到使用更少计算量就可以生成位图的目标渲染树。

可以理解的是，在图16A、图16B所示的场景以及其他场景中，通过合并多个渲染树并且对合并后的渲染树进行优化，可以避免或者减少过渡绘制，进而提高步骤S905中生成位图的速度，节约电子设备的功耗，提升用户的体验。

值得说明的是，UniRender进程还可以在生成目标渲染树的过程中，对目标渲染树的其他参数进行优化，在此不作限定。

S905：基于目标渲染树生成位图

在获得目标渲染树后，UniRender进程为目标渲染树分配一个surface，UniRender进程基于目标渲染树在该surface上生成位图，该位图对应一个或多个应用程序的合成的界面。

其中，当电子设备具有多个显示区域时，该surface可以与其中一个显示区域绑定，该surface可以与该surface绑定的显示区域的大小相同。

UniRender进程在该surface中基于目标渲染树生成位图，包括：

其一，UniRender进程从根节点开始遍历目标渲染树，其可以按照多种方式遍历该根节点的子节点。

UniRender进程可以按照图层的Z序遍历该根节点下的不同图层。UniRender进程可以按照Z序由高至低的顺序遍历不同图层，或者可以按照Z序由低至高的顺序遍历不同图层。

例如，在图20所示的目标渲染树中，图层1的Z序高于图层2的Z序，则UniRender进程可以先遍历图层1对应的渲染树，即先遍历由根渲染节点1、渲染节点1、渲染节点2、渲染节点3组成的渲染树，再遍历由根渲染节点2、渲染节点4、渲染节点5组成的渲染树。类似的，UniRender进程可以先遍历图层2对应的渲染树，再遍历图层1对应的渲染树。

值得说明的是，在UniRender进程按照Z序由高至低遍历图层的情况下，UniRender进程在执行绘制指令列表中的绘制操作时，在图层合成为上下遮蔽关系的情况下，可以只在没有被绘制的地方进行绘制，可以减少过度绘制。

值得说明的是，在UniRender进程按照Z序由低至高遍历图层的情况下，UniRender进程依次执行不同图层对应的渲染树中的绘制指令列表中的绘制操作，生成位图。

其二，UniRender进程依据渲染属性修改绘制指令列表中的绘制操作，执行绘制操作，进而生成位图。

UniRender进程在遍历到每个渲染节点时，首先读取渲染节点的渲染属性。在渲染属性中存在缩放属性、圆角属性、颜色转换属性、旋转属性等的情况下，UniRender进程依据这些属性修改绘制指令列表中绘制操作的参数，然后执行修改后的绘制指令列表中的绘制操作。在渲染属性中不存在缩放属性、圆角属性、颜色转换属性、旋转属性等的情况下，UniRender直接执行绘制指令列表中的绘制操作。

下面示例性的介绍UniRender进程依据渲染属性修改绘制指令列表中绘制操作的参数的方法。

例如，渲染节点的渲染属性中包括setscale(0.5)，其中，setscale(0.5)表示缩小至原来的0.5倍，绘制指令列表中包括drawCircle(x0，y0，5)。则UniRender进程在执行绘制操作drawCircle(x0，y0，5)，会将该绘制操作转变为drawCircle(x0，y0，2.5)。其中，drawCircle()中第一个参数为圆心在X轴的坐标，第二个参数为圆心在Y轴的坐标、第三个参数为圆的半径。

考虑到应用程序UI线程生成的绘制指令列表可以与应用程序自己申请的surface大小有关，在本申请实施例中，UniRender进程在遍历渲染树节点时在渲染节点的属性中配置setStaticMatrix()，变换绘制、渲染的参考坐标系。

其中，UniRender进程可以通过WMS确定每个应用程序生成绘制指令列表时参考坐标系或参考surface的大小，进而确定setStaticMatrix()的参数。

UniRender进程在确定应用程序生成绘制指令列表参照的surface坐标系后，根据UniRender进程持有surface的坐标系，确定坐标变换矩阵Transformation。

其中，scale_x为沿x轴方向的缩放、skew_x为沿x轴方向的扭曲/倾斜、translate_x为沿x轴方向的平移；scale_y为沿y轴方向的缩放、skew_y为沿y轴方向的扭曲/倾斜、translate_y沿y轴方向的平移。

UniRender进程在执行setStaticMatrix()指令后，会计算得出坐标变换矩阵Transformation，并将变换矩阵作用于绘制指令列表中的每一条绘制操作。如图21所示，当应用程序UI线程生成的渲染树时参考的坐标系不是UniRender进程持有的surface上的坐标系，UniRender进程通过setStaticMatrix()指令确定坐标变换矩阵Transformation，并在基于绘制指令列表往surface上绘制界面时变换参考坐标系，将界面正确的绘制出来。

上文主要介绍了单显示区域场景下，电子设备实施本申请实施例提供的界面生成方法的具体流程。下面主要介绍多显示区域场景下，电子设备实施本申请实施例提供的界面生成方法的具体流程。

(2.3)多显示区域场景下的界面生成方法

首先，示例性的介绍多显示区域的场景。

(a)多显示区域场景

在本申请实施例中，显示区域(display)可以是一块屏幕、或者可以是虚拟屏幕(VirtualDisplay)等。虚拟屏幕可以是录屏时，电子设备用于承载屏幕上显示的内容的区域。

在电子设备上配置有多个屏幕的情况下，每一块屏幕是一个显示区域。如图22A所示，电子设备的主屏幕作为显示区域1显示桌面应用程序，电子设备的副屏幕作为显示区域2显示音乐应用程序。

在电子设备的屏幕可以有多种状态的情形，每一种状态下的屏幕可以是一个或多个显示区域。如图22B所示，在电子设备的屏幕为折叠状态的情况下，每一部分屏幕可以是一个显示区域；在电子设备的屏幕为展开状态的情况下，左半部分屏幕和右半部分屏幕可以分别是一个显示区域。

如图22C所示，在录屏功能开启的情况下，电子设备的屏幕是一个显示区域，承载录屏内容的虚拟屏是一个显示区域。其中，两个显示区域上显示的内容可以相同。

如图23A所示，电子设备1将屏幕上显示的内容共享到电子设备2的屏幕上，在该情况下，对于电子设备1来说，电子设备1的屏幕为显示区域1，电子设备2的屏幕为显示区域2。在电子设备2的屏幕上显示的内容包括有电子设备1屏幕上的内容。

如图23B所示，电子设备1将屏幕上显示的内容投屏到电子设备2的屏幕上，在该情况下，对于电子设备1来说，电子设备1的屏幕为显示区域1，电子设备2的屏幕为显示区域2。与图23A所示内容不同的是，电子设备2的屏幕上显示的内容只有电子设备1屏幕上的内容。

如图23C所示，电子设备1将屏幕上显示的内容投屏到电子设备2的屏幕上，在该情况下，对于电子设备1来说，电子设备1的屏幕为显示区域1，电子设备2的屏幕为显示区域2。与图23A、图23B所示内容不同的是，电子设备2的屏幕上显示的内容为电子设备1屏幕上的部分内容。

值得说明的是，在多显示区域场景下，并且在多电子设备的情况下，如电子设备1上有显示区域1和电子设备2上有显示区域2，显示区域2上可以只显示电子设备1屏幕上显示的内容；或者，显示区域2上可以显示部分或全部的电子设备1屏幕上显示的内容和原本电子设备2屏幕显示的内容的叠加等。

(b)单设备多显示区域场景下的界面生成方法

如图24所示，在单设备多显示区域场景下的界面生成方法包括：

S2401：接收到垂直信号后，构建生成渲染树

具体的内容可以参考图9中步骤S901中对应的文字描述，此处不再赘述。

S2402：跨进程传递渲染树

具体的内容可以参考图9中步骤S902中对应的文字描述，此处不再赘述。

可选的，在本申请一些实施例中，可以是DisplayRender子进程直接和对应的应用程序之间通过IPC通信获取渲染树。其中，UniRender进程会确定DisplayRender子进程和应用程序的对应关系。

可选的，在本申请一些实施例中，可以是所有的DisplayRender子进程和所有的应用程序之间存在有一块有多个共享内存中组成的共享内存集合，每个DisplayRender子进程持有该多个共享内存的句柄。

其中，DisplayRender子进程的概念可以参考步骤S2404中对应的文字描述，此处不再赘述。

S2403:传递应用程序的窗口控制信息和显示区域信息

具体的内容可以参考图9中步骤S903中对应的文字描述，此处不再赘述。

S2404：分配渲染树

UniRender进程可以创建与显示区域数量相等的子进程DisplayRender(图24中为DisplayRender1至DisplayRenderN)，并将显示区域上显示的应用程序的渲染树传递给DisplayRender。

例如，应用程序1、应用程序2在显示区域1上显示，显示区域1与子进程DisplayRender1对应；应用程序3、应用程序4在显示区域2上显示，显示区域2与子进程DisplayRender2对应。则，UniRender进程将应用程序1的渲染树和应用程序2的渲染树传递给子进程DisplayRender1，将应用程序3的渲染树和应用程序4的渲染树传递给子进程DisplayRender2。

其中，DisplayRender1和DisplayRender2可以从UniRender进程获取对应应用程序的共享内存的句柄，进而获得对应应用程序的渲染树。或者，通过Binder等其他IPC通信方式从UniRender进程中获取应用程序的渲染树，在此不做限定。

可选的，在本申请一些实施例中，UniRender进程可以先将多个应用程序的渲染树合成为目标渲染树后，将目标渲染树传递给对应的DisplayRender子进程。其中，目标渲染树的传递可以通过共享内存、Binder等多种IPC通信方式实现，在此不做限定。

可选的，在本申请一些实施例中，UniRender进程可以对渲染树进行离屏渲染指令的前移处理后再传递给对应的DisplayRender子进程，也可以将对应显示区域上的应用程序的窗口控制信息和渲染树传递给对应的DisplayRender子进程，由DisplayRender子进程对渲染树进行离屏渲染指令的前移处理并将多个渲染树合成为目标渲染树。

可选的，在本申请一些实施例中，DisplayRender子进程可以配置两个线程，如I/O线程和渲染线程，I/O线程负责接收渲染树，渲染线程负责生成目标渲染树，并基于目标渲染树生成位图。

可以理解的是，UniRender进程通过创建多个DisplayRender子进程，可以将垂直同步信号(Vsync-UR)进行分频和倍频，并将分频和倍频后垂直同步信号(Vsync-UR)传递给不同的DisplayRender子进程，的进而使得不同的DisplayRender子进程以不同的频率生成位图以匹配不同显示区域的刷新率。

如图25所示，在不同的DisplayRender子进程对应的显示区域的刷新率不同的情况下，UniRender可以将垂直同步信号(Vsync-UR)进行分频或倍频，进而转发到不同的DisplayRender子进程。

例如，显示区域1的刷新率为60Hz，显示区域2的刷新率为30Hz，并且显示区域1对应的DisplayRender子进程为DisplayRender1，显示区域2对应的DisplayRender子进程为DisplayRender2。则，UniRender进程在接收到60Hz的垂直同步信号(Vsync)后，或者UniRender进程在产生60Hz的垂直同步信号(Vsync)后，进行分频，产生30Hz的垂直同步信号(Vsync-UR)和60Hz的垂直同步信号(Vsync-UR)，将60Hz的垂直同步信号(Vsync-UR)传递给DisplayRender1子进程，并将30Hz的垂直同步信号(Vsync-UR)传递给DisplayRender2子进程。

可以理解的是，通过对垂直同步信号(Vsync-UR)进行分频或倍频，可以使得DisplayUniRender进程接收渲染树或目标渲染树的频率、生成位图的频率与显示区域的刷新频率一致。

其中，在接收到垂直同步信号(Vsync-UR)后，DisplayRender子进程可以开始读取渲染树、生成目标渲染树、生成位图。

值得说明的是，UniRender进程接收显示管理服务发来的显示区域信息，确定每个显示区域的连接状态，进而根据显示区域的连接状态，可以创建、销毁每个显示区域对应的DisplayRender进程。

其中，UniRender的架构、共享内存等概念的内容可以参考步骤S904中的文字描述，此处不再赘述。

S2405：基于获得的渲染树以及窗口控制信息、显示区域信息生成目标渲染树

DisplayRender子进程将一个或多个目标渲染树合成为目标渲染树，并在应用程序的图层涉及离屏渲染逻辑的情况下，对该应用程序的渲染树进行离屏渲染指令的前移。

值得说明的是，DisplayRender子进程可以从UniRender进程处获取显示区域上的窗口控制信息和显示区域信息。

可选的，在本申请一些实施例中，UniRender进程可以将一个或多个渲染树合成为目标渲染树后再传递给DisplayRender子进程。

其中，生成目标渲染树的过程、离屏渲染指令的前移等概念的内容可以参考步骤S904中的文字描述，此处不在赘述。

S2406：基于目标渲染树生成位图

DisplayRender子进程在生成目标渲染树后，基于目标渲染树生成位图。DisplayRender子进程在生成位图后，将承载位图的surface传递给UniRender进程，由UniRender进程将surface的内容通过DSS送显到各个显示区域上。

其中，基于目标渲染树生成位图的过程可以参考步骤S905中的文字描述，此处不在赘述。

由于底层图形库的调用依赖于上下文，不同的DisplayRender子进程对应于不同的上下文，进而可以并行的为不同显示区域生成位图。

可以理解的是，UniRender进程进行通过创建与显示区域一一对应的DisplayRender子进程，可以并行的为每个显示区域生成位图，在多显示区域场景下，可以提升界面的生成速度，降低卡顿，提升用户的体验。

下面结合图26A、图26B所示的内容，示例性的介绍电子设备实施界面生成方法时，数据的流动过程。

如图26A所示，电子设备上存在两块显示区域，分别为显示区域1和显示区域2。其中，显示区域1上显示有应用程序1和应用程序3的内容；显示区域2上显示有应用程序2、应用程序3、应用程序4的内容。

UniRender进程创建与显示区域1对应的DisplayRender1子进程和显示区域2对应的DisplayRender2子进程。UniRender进程在接收到应用程序1的渲染树1、应用程序2的渲染树2、应用程序3的渲染树3、应用程序4的渲染树4后，将渲染树1和渲染树3传递给DisplayRender1子进程，将渲染树2、渲染树3和渲染树4传递给DisplayRender2子进程。UniRender进程将相关的窗口控制信息和显示区域信息传递给DisplayRender子进程。

DisplayRender1子进程和DisplayRender2子进程分别独立的基于目标渲染树生成位图。DisplayRender1子进程会基于显示区域1显示区域信息生成surface1，DisplayRender1子进程会基于显示区域2的显示区域信息生成surface2。其中，surface1用于承载DisplayRender1子进程生成的位图1；surface2用于承载DisplayRender1子进程生成的位图2。其中，surface1的大小可以与显示区域1的大小有关，surface2的大小可以与显示区域2的大小有关。

在本申请实施例中，应用程序在不同显示区域上显示的内容可以相同也可以不同。在应用程序在不同显示区域上显示的内容相同的情况下，应用程序生成的一个渲染树会被分配到多个DisplayRender子进程；在应用程序在不同显示区域上显示的内容不相同的情况下，应用程序会生成多个不同的渲染树，对应的分配给多个DisplayRender子进程。

例如，在图26B所示的内容中，由于显示区域1和显示区域2的尺寸(如分辨率)不同，应用程序3会在显示区域1和显示区域2上显示的界面不同(例如布局结构不同，但是内容相同)，故应用程序会生成对应不同显示区域的渲染树，分别为渲染树31和渲染树32。其中，渲染树31会传递到DisplayRender1子进程、渲染树32会传递到DisplayRender2子进程。

其中，任意一个DisplayRender子进程可以配置两个线程，如I/O线程和渲染线程，I/O线程负责接收渲染树，渲染线程负责生成目标渲染树，并基于目标渲染树生成位图。

(c)多设备多显示区域场景下的界面生成方法

如图23A-图23C的场景所示，电子设备可以通过投屏、多屏协同等方式将屏幕上的内容部分或全部的显示在对端电子设备的屏幕上。

在多设备多显示区域场景下，本地电子设备与对端电子设备建立连接后，可以将对端电子设备的屏幕作为显示区域2，并将要在显示区域2上显示的应用程序的渲染树传递给对端电子设备。对端电子设备在接收到本地电子设备的渲染树后，将在显示区域2上显示的所有应用程序的渲染树合成为目标渲染树，进而生成位图并送显。

或者，本地电子设备也可以将在显示区域2上显示的应用程序的界面发送给对端电子设备。

如图27所示，本申请实施例提供的界面生成方法包括：

S2701：建立连接

电子设备1和电子设备2通过蓝牙、Wi-Fi、HiLink等多种方式建立通信连接。电子设备1将电子设备2的屏幕作为显示区域2，其中，电子设备1自己的屏幕作为显示区域1。

电子设备2上的UniRender进程在确定电子设备1和电子设备2建立连接后，或者，收到显示管理服务和窗口管理服务的投屏、多屏协同等请求后，可以申请开辟一个堆内存用于存储电子设备1发送来的用于渲染生成位图的数据，如渲染树。

S2702：确定在显示区域2上显示的应用程序

电子设备1上的窗口管理服务和显示管理服务确定要在显示区域2上显示的应用程序，并将该结果传递给电子设备1上的UniRender1进程。然后，电子设备1的UniRender1进程通过IPC通信获取在显示区域2上显示的应用程序的渲染树。

其中，UniRender1进程通过IPC通信获取到应用程序的渲染树可以参考上文中步骤S902中的文字描述，此处不在赘述。

S2703：发送显示区域2上显示的应用程序的渲染树

电子设备1的UniRender1进程将显示区域2上显示的应用程序的渲染树发送到电子设备2上。

UniRender1可以确定共享内存的起始地址和共享内存的大小，通过步骤S2701的通信连接，将渲染树传递给电子设备2的UniRender2进程的已经开辟好的堆内存上。

其中，堆内存的上数据的存储结构可以与UniRender1上共享内存中数据的存储结构一致。堆内存上数据的存储结构和堆内存的读写安全可以参考步骤S902中的文字描述，此处不在赘述。

可以理解的是，电子设备1将渲染树发送给电子设备2，可以降低电子设备1和电子设备2数据传输量，进而降低时延，提高界面的生成速度。

S2704：将在显示区域2上显示的应用程序的渲染树合成为目标渲染树

电子设备2的UniRender2进程在收到垂直同步信号(Vsync-UR2)后，将在显示区域2上显示的应用程序的渲染树合成为目标渲染树，并在该过程中可以完成离屏渲染指令的前移。

其中，电子设备2可以将电子设备1发送的渲染树和电子设备2本地的渲染树进行合成目标渲染树。

如图28A所示，电子设备1上运行有应用程序1和应用程序2，应用程序1生成的渲染树为渲染树1，应用程序2生成的渲染树为渲染树2。电子设备2上运行有应用程序3，应用程序3生成的渲染树为渲染树3。

电子设备1上的UniRender1进程确定应用程序2的界面要显示在显示区域2上，则将渲染树2发送给电子设备2的UniRender2进程。

UniRender1进程分别对渲染树1和渲染树2进行离屏渲染指令的前移，并合成为目标渲染树1，生成位图1。UniRender2进程分别对渲染树2和渲染树3进行离屏渲染指令的前移，并合成为目标渲染树2，生成位图2。

值得说明的是，UniRender1进程向UniRender2进程发送渲染树2的数据，可以发送全部的渲染树2的数据，或者发送差量的渲染树2的数据。其中，全部的渲染树2的数据可以是共享内存中的current properties、current displaylist或staging displaylist、staging properties；差量的渲染树2的数据可以是properties_dirty队列和displaylist_dirty队列中的渲染树2的渲染节点的绘制指令列表和渲染属性。

如图28B所示，电子设备1上运行有应用程序1、应用程序2和应用程序3，应用程序1生成的渲染树为渲染树1，应用程序2生成的渲染树为渲染树2，应用程序2生成的渲染树为渲染树3。电子设备2上运行有应用程序4，应用程序4生成的渲染树为渲染树4。

电子设备1上的UniRender1进程确定应用程序2、应用程序3的界面要显示在显示区域2上，则将渲染树2、渲染树3发送给电子设备2的UniRender2进程或者将渲染树2和渲染树3合成为目标渲染树2后，将目标渲染树2发送到电子设备2的UniRender2进程。

UniRender1进程分别对渲染树1、渲染树2、渲染树3进行离屏渲染指令的前移，并合成为目标渲染树1，生成位图1；UniRender1进程分别对渲染树2、离屏渲染指令的前移，并合成为目标渲染树2。

可选的，在本申请一些实施例中，UniRender1进程可以创建多个子进程DisplayRender，分别接收、处理来自于不同应用程序的渲染树。即，在图28B所示的内容中，UniRender1进程可以创建两个子进程DisplayRender，分别为DisplayRender1和DisplayRender2。DisplayRender1子进程接收渲染树1、渲染树2、渲染树3，并合成为目标渲染树1；DisplayRender2子进程接收渲染树2、渲染树3，合成为目标渲染树2，并将目标渲染树2发送到UniRender2进程。

UniRender2进程分别对渲染树2和渲染树3进行离屏渲染指令的前移，并合成为目标渲染树2，生成位图2。

值得说明的是，UniRender1进程响应于电子设备1上的垂直同步信号(Vsync-UR1)，从共享内存中获取一个或多个应用程序的渲染树，开始生成目标渲染树。UniRender2响应于电子设备2上的垂直同步信号(Vsync-UR2)，从堆内存和/或共享内存中获取一个或多个应用程序的渲染树，开始生成目标渲染树。

可选的，在本申请一些实施例中，在电子设备1上的垂直同步信号(Vsync-UR1)和电子设备2上的垂直同步信号(Vsync-UR2)的频率不一致的情况下，电子设备1上的UniRender可以通过分频、倍频的方式调整垂直同步信号(Vsync-UR1)的频率与Vsync-UR2相同；或者电子设备2上的UniRender2可可以通过分频、倍频的方式调整垂直同步信号(Vsync-UR2)的频率与垂直同步信号(Vsync-UR1)相同。

可选的，在本申请一些实施例中，电子设备1的可以配置有多个频率的垂直同步信号(Vsync-UR1)。例如，在图28A、图28B所示的场景中，电子设备1上原本的垂直同步信号(Vsync-UR)频率为60Hz，电子设备2上原本的垂直同步信号(Vsync-UR2)频率为90Hz。在电子设备1确定要将应用程序2的界面显示在电子设备2上后，电子设备1的UniRender进程可以生成分别为60Hz、90Hz的垂直同步信号(Vsync-UR1)频率，使得应用程序2以90Hz的频率生成渲染树。进而UniRender1进程可以以90Hz的频率将渲染树传递给UniRender2进程。其中，应用程序1可以仍然以60Hz的频率生成渲染树。

其中，在任意电子设备上，UniRender接收或生成的垂直同步信号(Vsync-UR)可以与应用程序接收的垂直同步信号(Vsync-APP)相同。

S2705：基于目标渲染树生成位图。

具体的内容可以参考步骤S905中的文字描述，此处不再赘述。

可选的，在本申请一些实施例中，电子设备1的UniRender1进程可以先将一个或多个在显示区域2上的渲染树合成为目标渲染树后，基于目标渲染树生成位图，将位图传递给电子设备2的UniRender2进程。

值得说明的是，在电子设备2显示有电子设备1上应用程序1的界面的情况下，用户在电子设备2上通过点击等其他交互方式点击应用程序1的界面，电子设备2可以将用户点击的操作在应用程序1的界面中的位置发送给电子设备1上的应用程序1，使得应用程序1可以正确响应用户的交互。或者，由于电子设备2上应用程序1的界面是由电子设备2上的UniRender2进程基于渲染树生成的，而渲染树中包含有view的位置信息，进而电子设备2可以确定用户点击的view，将view点击事件直接发送给电子设备1上的应用程序1，使得应用程序1可以正确响应用户的交互。

(3)最后，介绍本申请实施例提供的电子设备的硬件架构和软件架构。

下面以电子设备为例对实施例进行具体说明。应该理解的是，电子设备可以具有比图中所示的更多的或者更少的部件，可以组合两个或多个的部件，或者可以具有不同的部件配置。图中所示出的各种部件可以在包括一个或多个信号处理和/或专用集成电路在内的硬件、软件、或硬件和软件的组合中实现。

电子设备可以包括：处理器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等。

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

处理器110可以包括一个或多个处理单元，例如：处理器110可以包括应用处理器(application processor，AP)，调制解调处理器，图形处理器(graphics processingunit，GPU)，图像信号处理器(image signal processor，ISP)，控制器，存储器，视频编解码器，数字信号处理器(digital signal processor，DSP)，基带处理器，和/或神经网络处理器(neural-network processing unit，NPU)等。其中，不同的处理单元可以是独立的器件，也可以集成在一个或多个处理器中。

其中，控制器可以是电子设备的神经中枢和指挥中心。控制器可以根据指令操作码和时序信号，产生操作控制信号，完成取指令和执行指令的控制。

处理器110中还可以设置存储器，用于存储指令和数据。在一些实施例中，处理器110中的存储器为高速缓冲存储器。该存储器可以保存处理器110刚用过或循环使用的指令或数据。如果处理器110需要再次使用该指令或数据，可从所述存储器中直接调用。避免了重复存取，减少了处理器110的等待时间，因而提高了系统的效率。

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

I2C接口是一种双向同步串行总线，包括一根串行数据线(serial data line，SDA)和一根串行时钟线(derail clock line，SCL)。在一些实施例中，处理器110可以包含多组I2C总线。处理器110可以通过不同的I2C总线接口分别耦合触摸传感器180K，充电器，闪光灯，摄像头193等。例如：处理器110可以通过I2C接口耦合触摸传感器180K，使处理器110与触摸传感器180K通过I2C总线接口通信，实现电子设备的触摸功能。

I2S接口可以用于音频通信。PCM接口也可以用于音频通信，将模拟信号抽样，量化和编码。UART接口是一种通用串行数据总线，用于异步通信。

MIPI接口可以被用于连接处理器110与显示屏194，摄像头193等外围器件。MIPI接口包括摄像头串行接口(camera serial interface，CSI)，显示屏串行接口(displayserial interface，DSI)等。在一些实施例中，处理器110和摄像头193通过CSI接口通信，实现电子设备的拍摄功能。处理器110和显示屏194通过DSI接口通信，实现电子设备的显示功能。GPIO接口可以通过软件配置。GPIO接口可以被配置为控制信号，也可被配置为数据信号。在一些实施例中，GPIO接口可以用于连接处理器110与摄像头193，显示屏194，无线通信模块160，音频模块170，传感器模块180等。GPIO接口还可以被配置为I2C接口，I2S接口，UART接口，MIPI接口等。SIM接口可以被用于与SIM卡接口195通信，实现传送数据到SIM卡或读取SIM卡中数据的功能。USB接口130是符合USB标准规范的接口，具体可以是Mini USB接口，Micro USB接口，USB Type C接口等。

可以理解的是，本发明实施例示意的各模块间的接口连接关系，只是示意性说明，并不构成对电子设备的结构限定。在本申请另一些实施例中，电子设备也可以采用上述实施例中不同的接口连接方式，或多种接口连接方式的组合。

充电管理模块140用于从充电器接收充电输入。电源管理模块141用于连接电池142，充电管理模块140与处理器110。

电子设备的无线通信功能可以通过天线1，天线2，移动通信模块150，无线通信模块160，调制解调处理器以及基带处理器等实现。天线1和天线2用于发射和接收电磁波信号。电子设备中的每个天线可用于覆盖单个或多个通信频带。不同的天线还可以复用，以提高天线的利用率。移动通信模块150可以提供应用在电子设备上的包括2G/3G/4G/5G等无线通信的解决方案。移动通信模块150可以包括至少一个滤波器，开关，功率放大器，低噪声放大器(low noise amplifier，LNA)等。移动通信模块150可以由天线1接收电磁波，并对接收的电磁波进行滤波，放大等处理，传送至调制解调处理器进行解调。移动通信模块150还可以对经调制解调处理器调制后的信号放大，经天线1转为电磁波辐射出去。在一些实施例中，移动通信模块150的至少部分功能模块可以被设置于处理器110中。在一些实施例中，移动通信模块150的至少部分功能模块可以与处理器110的至少部分模块被设置在同一个器件中。

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

无线通信模块160可以提供应用在电子设备上的包括无线局域网(wirelesslocal area networks，WLAN)(如无线保真(wireless fidelity，Wi-Fi)网络)，蓝牙(bluetooth，BT)，全球导航卫星系统(global navigation satellite system，GNSS)，调频(frequency modulation，FM)，近距离无线通信技术(near field communication，NFC)，红外技术(infrared，IR)等无线通信的解决方案。无线通信模块160可以是集成至少一个通信处理模块的一个或多个器件。无线通信模块160经由天线2接收电磁波，将电磁波信号调频以及滤波处理，将处理后的信号发送到处理器110。无线通信模块160还可以从处理器110接收待发送的信号，对其进行调频，放大，经天线2转为电磁波辐射出去。

在一些实施例中，电子设备的天线1和移动通信模块150耦合，天线2和无线通信模块160耦合，使得电子设备可以通过无线通信技术与网络以及其他设备通信。所述无线通信技术可以包括全球移动通讯系统(global system for mobile communications，GSM)，通用分组无线服务(general packet radio service，GPRS)，码分多址接入(code divisionmultiple access，CDMA)，宽带码分多址(wideband code division multiple access，WCDMA)，时分码分多址(time-division code division multiple access，TD-SCDMA)，长期演进(long term evolution，LTE)，BT，GNSS，WLAN，NFC，FM，和/或IR技术等。所述GNSS可以包括全球卫星定位系统(global positioning system，GPS)，全球导航卫星系统(globalnavigation satellite system，GLONASS)，北斗卫星导航系统(beidou navigationsatellite system，BDS)，准天顶卫星系统(quasi-zenith satellite system，QZSS)和/或星基增强系统(satellite based augmentation systems，SBAS)。

电子设备通过GPU，显示屏194，以及应用处理器等实现显示功能。GPU为图像处理的微处理器，连接显示屏194和应用处理器。GPU用于执行数学和几何计算，用于图形渲染。处理器110可包括一个或多个GPU，其执行程序指令以生成或改变显示信息。

显示屏194用于显示图像，视频等。显示屏194包括显示面板。显示面板可以采用液晶显示屏(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)等。在一些实施例中，电子设备可以包括1个或N个显示屏194，N为大于1的正整数。

电子设备可以通过ISP，摄像头193，视频编解码器，GPU，显示屏194以及应用处理器等实现拍摄功能，进而获取到实时的视频数据。

ISP用于处理摄像头193反馈的数据。例如，拍照时，打开快门，光线通过镜头被传递到摄像头感光元件上，光信号转换为电信号，摄像头感光元件将所述电信号传递给ISP处理，转化为肉眼可见的图像。ISP还可以对图像的噪点，亮度，进行算法优化。ISP还可以对拍摄场景的曝光，色温等参数优化。在一些实施例中，ISP可以设置在摄像头193中。

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

数字信号处理器用于处理数字信号，除了可以处理数字图像信号，还可以处理其他数字信号。例如，当电子设备在频点选择时，数字信号处理器用于对频点能量进行傅里叶变换等。

视频编解码器用于对数字视频压缩或解压缩。电子设备可以支持一种或多种视频编解码器。这样，电子设备可以播放或录制多种编码格式的视频，例如：动态图像专家组(moving picture experts group，MPEG)1，MPEG2，MPEG3，MPEG4等。

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

内部存储器121可以包括一个或多个随机存取存储器(random access memory，RAM)和一个或多个非易失性存储器(non-volatile memory，NVM)。

随机存取存储器可以包括静态随机存储器(static random-access memory，SRAM)、动态随机存储器(dynamic random access memory，DRAM)、同步动态随机存储器(synchronous dynamic random access memory,SDRAM)、双倍资料率同步动态随机存取存储器(double data rate synchronous dynamic random access memory,DDR SDRAM，例如第五代DDR SDRAM一般称为DDR5 SDRAM)等；

非易失性存储器可以包括磁盘存储器件、快闪存储器(flash memory)。

在本申请实施例中，非实时的视频可以位于非易失性存储器中。

快闪存储器按照运作原理划分可以包括NOR FLASH、NAND FLASH、3D NAND FLASH等，按照存储单元电位阶数划分可以包括单阶存储单元(single-level cell,SLC)、多阶存储单元(multi-level cell,MLC)、三阶储存单元(triple-level cell,TLC)、四阶储存单元(quad-level cell,QLC)等，按照存储规范划分可以包括通用闪存存储(英文：universalflash storage，UFS)、嵌入式多媒体存储卡(embedded multi media Card，eMMC)等。

随机存取存储器可以由处理器110直接进行读写，可以用于存储操作系统或其他正在运行中的程序的可执行程序(例如机器指令)，还可以用于存储用户及应用程序的数据等。

非易失性存储器也可以存储可执行程序和存储用户及应用程序的数据等，可以提前加载到随机存取存储器中，用于处理器110直接进行读写。

外部存储器接口120可以用于连接外部的非易失性存储器，实现扩展电子设备的存储能力。外部的非易失性存储器通过外部存储器接口120与处理器110通信，实现数据存储功能。例如将音乐，视频等文件保存在外部的非易失性存储器中。

电子设备可以通过音频模块170，扬声器170A，受话器170B，麦克风170C，耳机接口170D，以及应用处理器等实现音频功能。例如音乐播放，录音等。

音频模块170用于将数字音频信息转换成模拟音频信号输出，也用于将模拟音频输入转换为数字音频信号。扬声器170A，也称“喇叭”，用于将音频电信号转换为声音信号。受话器170B，也称“听筒”，用于将音频电信号转换成声音信号。麦克风170C，也称“话筒”，“传声器”，用于将声音信号转换为电信号。

耳机接口170D用于连接有线耳机。耳机接口170D可以是USB接口130，也可以是3.5mm的开放移动电子设备平台(open mobile terminal platform，OMTP)标准接口，美国蜂窝电信工业协会(cellular telecommunications industry association of the USA，CTIA)标准接口。

压力传感器180A用于感受压力信号，可以将压力信号转换成电信号。在一些实施例中，压力传感器180A可以设置于显示屏194。陀螺仪传感器180B可以用于确定电子设备的运动姿态。气压传感器180C用于测量气压。磁传感器180D包括霍尔传感器。加速度传感器180E可检测电子设备在各个方向上(一般为三轴)加速度的大小。距离传感器180F，用于测量距离。接近光传感器180G可以包括例如发光二极管(LED)和光检测器，例如光电二极管。环境光传感器180L用于感知环境光亮度。指纹传感器180H用于采集指纹。电子设备可以利用采集的指纹特性实现指纹解锁，访问应用锁，指纹拍照，指纹接听来电等。温度传感器180J用于检测温度。

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

按键190包括开机键，音量键等。按键190可以是机械按键。也可以是触摸式按键。电子设备可以接收按键输入，产生与电子设备的用户设置以及功能控制有关的键信号输入。马达191可以产生振动提示。指示器192可以是指示灯，可以用于指示充电状态，电量变化，也可以用于指示消息，未接来电，通知等。SIM卡接口195用于连接SIM卡。电子设备通过SIM卡和网络交互，实现通话以及数据通信等功能。

分层架构将软件分成若干个层，每一层都有清晰的角色和分工。层与层之间通过软件接口通信。在一些实施例中，将系统分为四层，从上至下分别为应用程序层，应用程序框架层，系统库，以及内核层。

应用程序层可以包括一系列应用程序包。如图20所示，应用程序包可以包括相机，图库，日历，通话，地图，导航，WLAN，蓝牙，音乐，视频，短信息等应用程序(也可以称为应用)。

应用程序框架层为应用程序层的应用程序提供应用编程接口(applicationprogramming interface，API)和编程框架。应用程序框架层包括一些预先定义的函数。

如图30所示，应用程序框架层可以包括窗口管理服务，显示管理服务，内容提供器，视图系统，电话管理器，资源管理器，通知管理器，本地Profile管理助手(LocalProfile Assistant，LPA)等。

窗口管理服务负责窗口的启动、添加、删除等，可以确定窗口上显示的应用程序以及确定应用程序的图层的创建、销毁、属性变更等，判断是否有状态栏，锁定屏幕，截取屏幕等。

显示管理服务可以获取显示区域的数量、大小，以及负责显示区域的启动、添加、删除等。

内容提供器用来存放和获取数据，并使这些数据可以被应用程序访问。所述数据可以包括视频，图像，音频，拨打和接听的电话，浏览历史和书签，电话簿等。

电话管理器用于提供电子设备的通信功能。例如通话状态的管理(包括接通，挂断等)。

资源管理器为应用程序提供各种资源，比如本地化字符串，图标，图片，布局文件，视频文件等等。

通知管理器使应用程序可以在状态栏中显示通知信息，可以用于传达告知类型的消息，可以短暂停留后自动消失，无需用户交互。比如通知管理器被用于告知下载完成，消息提醒等。通知管理器还可以是以图表或者滚动条文本形式出现在系统顶部状态栏的通知，例如后台运行的应用程序的通知，还可以是以对话界面形式出现在屏幕上的通知。例如在状态栏提示文本信息，发出提示音，电子设备振动，指示灯闪烁等。

视图系统包括可视控件，例如显示文字的控件，显示图片的控件等。视图系统可用于构建应用程序。显示界面可以由一个或多个视图组成的。例如，包括短信通知图标的显示界面，可以包括显示文字的视图以及显示图片的视图。

视图系统还包括UniRender，UniRender可以接收一个或多个应用程序的渲染树。UniRender可以通过窗口管理服务同步图层信息如图层创建、销毁、属性变更等。UniRender可以从显示管理服务同步显示区域的信息，如屏幕的大小等。

可选的，在本申请一些实施例中，视图系统还包括SurfaceFlinger。在配置有白名单的电子设备上，当应用程序不属于白名单的情况下，该应用程序的UI线程生成渲染树后，由该应用程序的渲染线程生位图后，交由SurfaceFlinger进行图层的合成。

可选的，在本申请一些实施例中，在显示区域上显示的有在白名单内的应用程序和不在白名单内的应用程序的情况下，白名单内得应用程序的位图生成由UniRender负责，UniRender生成位图后，将该位图传递给SurfaceFlinger，SurfaceFlinger再将该位图和其他不在白名单内的应用程序进行图层合成，生成用于送显的位图。

运行时包括核心库和虚拟机。运行时负责操作系统的调度和管理。

核心库包含两部分：一部分是java语言需要调用的功能函数，另一部分是核心库。

应用程序层和应用程序框架层运行在虚拟机中。虚拟机将应用程序层和应用程序框架层的java文件执行为二进制文件。虚拟机用于执行对象生命周期的管理，堆栈管理，线程管理，安全和异常的管理，以及垃圾回收等功能。

系统库可以包括多个功能模块。例如：表面管理器(surface manager)，媒体库(Media Libraries)，图形处理库，其中，图形处理库包括:三维图形处理库(例如：OpenGLES)，二维图形引擎(例如：SGL)等。

表面管理器用于对显示子系统进行管理，并且为多个应用程序提供了二维(2-Dimensional，2D)和三维(3-Dimensional，3D)图层的融合。

媒体库支持多种常用的音频，视频格式回放和录制，以及静态图像文件等。媒体库可以支持多种音视频编码格式，例如：MPEG4，H.264，MP3，AAC，AMR，JPG，PNG等。

三维图形处理库用于实现3D图形绘图，图像渲染，图层合成，和图层处理等。2D图形引擎是2D绘图的绘图引擎。

内核层是硬件和软件之间的层。内核层至少包含显示驱动，摄像头驱动，音频驱动，传感器驱动，虚拟卡驱动。

在本申请实施例中，应用程序层的一个或多个应用程序将各自UI线程生产的渲染树传递到视图系统的UniRender进程中。UniRender进程从窗口管理服务和显示管理服务获取窗口控制信息和显示区域信息，进而将在一个显示区域上的应用程序的渲染树合成为目标渲染树。UniRender进程在生成目标渲染树后，调用图层处理库，执行目标渲染树中的绘制指令列表中的DrawOP操作，进而生成位图。UniRender将生成的位图传递给显示驱动用于送显。

上述实施例中所用，根据上下文，术语“当…时”可以被解释为意思是“如果…”或“在…后”或“响应于确定…”或“响应于检测到…”。类似地，根据上下文，短语“在确定…时”或“如果检测到(所陈述的条件或事件)”可以被解释为意思是“如果确定…”或“响应于确定…”或“在检测到(所陈述的条件或事件)时”或“响应于检测到(所陈述的条件或事件)”。

在上述实施例中，可以全部或部分地通过软件、硬件、固件或者其任意组合来实现。当使用软件实现时，可以全部或部分地以计算机程序产品的形式实现。该计算机程序产品包括一个或多个计算机指令。在计算机上加载和执行该计算机程序指令时，全部或部分地产生按照本申请实施例该的流程或功能。该计算机可以是通用计算机、专用计算机、计算机网络、或者其他可编程装置。该计算机指令可以存储在计算机可读存储介质中，或者从一个计算机可读存储介质向另一个计算机可读存储介质传输，例如，该计算机指令可以从一个网站站点、计算机、服务器或数据中心通过有线(例如同轴电缆、光纤、数字用户线)或无线(例如红外、无线、微波等)方式向另一个网站站点、计算机、服务器或数据中心进行传输。该计算机可读存储介质可以是计算机能够存取的任何可用介质或者是包含一个或多个可用介质集成的服务器、数据中心等数据存储设备。该可用介质可以是磁性介质，(例如，软盘、硬盘、磁带)、光介质(例如DVD)、或者半导体介质(例如固态硬盘)等。

本领域普通技术人员可以理解实现上述实施例方法中的全部或部分流程，该流程可以由计算机程序来指令相关的硬件完成，该程序可存储于计算机可读取存储介质中，该程序在执行时，可包括如上述各方法实施例的流程。而前述的存储介质包括：ROM或随机存储记忆体RAM、磁碟或者光盘等各种可存储程序代码的介质。

Claims

1.一种界面生成方法，应用于电子设备，其特征在于，包括：

第一进程生成第一渲染树，所述第一渲染树用于绘制第一进程的界面；

所述第一进程将所述第一渲染树写入第一共享内存；

第二进程从所述第一共享内存读取所述第一渲染树；

所述第二进程基于所述第一渲染树生成第一目标界面，所述第一目标界面包括所述第一进程的界面，所述第一进程和所述第二进程为不同的进程。

2.根据权利要求1中任一项所述的方法，其特征在于，所述第一进程将所述第一渲染树写入所述第一共享内存，具体包括：

所述第一进程将所述第一渲染树的变化量写入所述第一共享内存。

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

所述第一共享内存被配置有第一锁，所述第一锁被配置有至少两个状态，所述至少两个状态包括第一状态和第二状态；

在所述第一锁为第一状态的情况下，所述第一共享内存允许被所述第一进程写入；

在所述第一锁为第二状态的情况下，所述第一共享内存允许被所述第二进程读取。

4.根据权利要求1或2所述的方法，其特征在于，

所述第一共享内存被配置有第二锁、第三锁，所述第二锁、所述第三锁均被配置有至少两个状态，所述至少两个状态包括第一状态和第二状态；

在所述第二锁为第一状态的情况下，所述第一共享内存允许被所述第一进程写入第一界面对应的渲染树；

在所述第二锁为第二状态的情况下，所述第一共享内存允许被所述第二进程读取所述第一界面对应的渲染树；

在所述第三锁为第一状态的情况下，所述第一共享内存允许被所述第一进程写入第二界面对应的渲染树；

在所述第三锁为第二状态的情况下，所述第一共享内存允许被所述第二进程读取所述第二界面对应的渲染树；

所述第一界面、所述第二界面均是所述第一进程的界面，所述第二界面的前一帧界面是所述第一界面。

5.根据权利要求4所述的方法，其特征在于，

所述第一共享内存包括第一部分和第二部分；

所述第一部分用于存储所述第一界面对应的渲染树；

所述第二部分用于存储所述第二界面对应的渲染树；

所述第二锁对应于所述第一部分；所述第三锁对应于所述第二部分。

6.根据权利要求1-5中任一项所述的方法，其特征在于，

所述第一共享内存以内存树存储所述第一渲染树，所述内存树为在共享内存中存储渲染树的一种数据结构；

所述内存树至少包括第一段数据和第二段数据，所述第一段数据包括用于确定所述第一进程的标识信息和所述第一渲染树的标识信息，所述第一段数据还包括第二段数据的起始地址；

所述第二段数据包括渲染树的绘制指令列表和渲染属性。

7.根据权利要求6所述的方法，其特征在于，

所述第一段数据还包括渲染节点的标识；

所述第一段数据还包括所述渲染节点的绘制指令列表和渲染属性在所述第二段数据中的起始地址。

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

所述第一进程生成第二渲染树，所述第一渲染树对应第三界面，所述第二渲染树对应第四界面；

所述第一进程将所述第二渲染树写入第二共享内存；

所述第二进程从所述第二共享内存读取所述第二渲染树；

所述第三界面、所述第四界面均是所述第一进程的界面，所述第三界面的前一帧界面是所述第四界面。

9.一种界面生成方法，应用于包括第一电子设备和第二电子设备的系统，所述第一电子设备和所述第二电子设备之间建立有通信连接，其特征在于，包括：

运行在所述第一电子设备上的第二进程接收第一渲染树，所述第一渲染树是运行在所述第一电子设备上的第一进程生成的，所述第一渲染树用于绘制第一进程的界面；

所述第二进程将所述第一渲染树发送给运行在所述第二电子设备上的第三进程；

所述第三进程基于所述第一渲染树生成第一界面，所述第一界面包括所述第一进程的界面。

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

响应于用户对所述第一界面的交互操作，所述第三进程确定第一控件和交互事件，所述第一控件为所述交互操作对应的控件；

所述第一进程接收所述第三进程发送的交互事件，所述交互事件用于确定所述交互操作和所述第一控件。

11.一种电子设备，其特征在于，所述电子设备包括：一个或多个处理器和存储器；

所述存储器与所述一个或多个处理器耦合，所述存储器用于存储计算机程序代码，所述计算机程序代码包括计算机指令，所述一个或多个处理器调用所述计算机指令以使得所述电子设备执行如权利要求1-8中任一项所述的方法。

12.一种芯片系统，所述芯片系统应用于电子设备，所述芯片系统包括一个或多个处理器，所述处理器用于调用计算机指令以使得所述电子设备执行如权利要求1-8中任一项所述的方法。

13.一种计算机可读存储介质，包括指令，其特征在于，当所述指令在电子设备上运行时，使得所述电子设备执行如权利要求1-8中任一项所述的方法。

14.一种计算机程序产品，包括计算机可读指令，所述计算机可读指令当被一个或多个处理器执行时实现如权利要求1-8中任一项所述的方法。