CN111861854A - 用于图形渲染的方法及装置 - Google Patents

Abstract

本申请提供了一种用于图形渲染的方法和装置等，其中，服务启动应用程序并获取所述应用程序发送的渲染指令；向所述电子设备发送所述渲染指令，所述电子设备根据所述渲染指令执行图形渲染以显示与所述应用程序相关的图像。本申请提供的技术方案能够使电子设备根据渲染指令进行图形渲染，而不是服务器进行图形渲染，从而提高画面质量，进而提升用户体验。

Description

用于图形渲染的方法及装置

技术领域

本申请涉及信息技术领域，并且更具体地，涉及一种用于图形渲染的方法及装置。

背景技术

传统模式下，手机应用程序(application，APP)运行在电子设备，电子设备要经过下载、更新等操作后才能使用APP。若APP尺寸大，就会存在下载时间长、占用电子设备存储空间大的问题，且APP功能冗余/尺寸膨胀是当前趋势，这种问题越来越不可避免。如果是游戏APP的话，安装在电子设备本地，各种游戏外挂层出不穷，难以从根本上禁绝，影响游戏公平性和体验。因此，提出了一种将电子设备中APP的逻辑运行环境与渲染环境分离，即APP运行在云侧(例如，服务器)，将渲染指令重定向到端侧(例如，电子设备)，二者分离的云手机/云游戏运行模式，也就是所谓的分离渲染(remote rendering，RR)。

基于分离渲染技术，现有技术中提出了视频流分离渲染的方案，即可以是在云侧的图形处理器(graphics processing unit，GPU)进行图形渲染生成视频流，将视频流进行编码发送至电子设备，对于电子设备而言只需要具备视频解码能力即可。但是，对于现有的视频流分离渲染的方案，由于为了降低云侧向端侧传输视频流所使用的带宽，会对云侧GPU进行图形渲染所生成的图片进行压缩，导致图片的画面质量较差，从而造成用户的体验感较差。

发明内容

本申请提供一种用于图形渲染的方法、服务器以及电子设备，电子设备通过获取的渲染指令进行图形渲染，得到与应用程序具有相同渲染效果的图像，从而提高画面质量提高用户的体验感。

第一方面，提供了一种用于图形渲染的方法，该方法应用于服务器。该方法包括：启动应用程序；获取所述应用程序发送的渲染指令；通过网络向电子设备发送所述渲染指令,所述渲染指令用于所述电子设备进行图形渲染,以便于在所述电子设备上显示与所述应用程序相关的图像，例如所述应用程序的程序画面或配置界面等等。以游戏应用为例，所述电子设备在GPU上执行所述渲染指令以在所述电子设备的显示设备上显示游戏画面等。

在本申请中，可以通过指令流方案实现分离渲染，即服务器可以获取应用程序发送(或者说生成)的渲染指令，将这些渲染指令发送至与服务器连接的电子设备，由接收到渲染指令的电子设备进行图形渲染，从而避免了视频流分离渲染的方案中服务器进行图形渲染生成适配于固定屏幕尺寸的视频流，若电子设备与服务器渲染的画面尺寸不匹配则出现图像拉伸或压缩的现象。在本申请的技术方案中，服务器可以将用于图形渲染的渲染指令流发送至电子设备，一方面可以降低服务器图形处理器(GPU)的负载，另一方面将渲染指令发送至电子设备，由电子设备在端侧根据渲染指令进行图形渲染，可以更好的适配于电子设备的屏幕尺寸，提高画面质量从而提升用户的体验感。

在一些实现方式中，所述启动应用程序可以包括：服务器响应于第一指令启动应用程序，所述第一指令可以是电子设备向服务器发送的，也可以来自其他设备，也可以是服务器自己生成的。

上述渲染指令中可以包括渲染上下文所需的渲染信息，渲染信息可以包括状态信息和数据信息，例如，数据信息可以是多个顶点数据，状态信息可以是当前渲染上下文中绑定的顶点数据。

第二方面，本申请还提供一种断点传输的方法，该方法应可以用于以上指令流分离渲染的方案中，能够达到与视频流分离渲染方案相同或更好的断点续传效果。具体的，该方法包括：服务器保存图形渲染信息，所述图形渲染信息是所述电子设备用于图形渲染所需的信息，并适时向电子设备发送该图形渲染信息，使得所述电子设备根据所述图形渲染信息执行图形渲染。具体的，在电子设备断开连接(可能是网络故障也可以能设备故障)又重新连接之后，服务器接收所述电子设备发送的第二指令，所述第二指令用于请求恢复与所述服务器的连接；响应于所述第二指令，服务器向所述电子设备发所述图形渲染信息，所述图形渲染信息用于所述电子设备执行图形渲染。

在一些实现方式中，所述图形渲染信息可以包括渲染指令本身；在另一些实现方式中，所述图形渲染信息可以包括渲染指令和/或其它信息的变形形式。

在一些实现方式中，所述服务器保存图形渲染信息是响应于所述电子设备发送的所述第二指令执行的。换句话说，服务器保存的图形渲染信息仅是所述电子设备请求恢复与所述服务器连接时(以及之后的一段时间)内的图形渲染信息，对于电子设备而言，这些信息通常就它恢复到所述应用程序运行的最新状态的信息，这样保存有针对性也可以降低存储空间占用率。在另一些实现方式中，服务器也可以随时保存图形渲染信息或根据其他规则保存图形渲染信息。

在一些实现方式中，图形渲染信息为用于电子设备恢复所述应用程序当前最新的渲染上下文的信息，当前最新的渲染上下文可以是指服务器接收第二指令时所述应用程序的渲染上下文。

例如，应用程序是跑酷游戏，跑酷游戏在服务器中运行(类似云游戏的形式)，但用于可以在自己的电子设备上玩该游戏。当电子设备与服务器断开连接后，用户无法再进入游戏界面，但是游戏仍然在服务器中运行。当电子设备向服务器发送请求恢复连接的第二指令时，服务器向电子设备发送它保存的渲染信息，以使得电子设备恢复到跑酷游戏的当前最新的游戏界面，用户可以从当前最新游戏界面开始继续玩游戏，类似于视频流方案的断点续传。

再例如，应用程序是企业微信，企业微信在服务器中运行，用户使用电子设备获取企业微信发送的消息，当电子设备与服务器断开连接后，电子设备无法再接收消息，当电子设备恢复与服务器的连接后，通过本申请提供的方法可以直接渲染并显示包含企业微信发送的最新的消息的消息界面。

对于视频流分离渲染的方案，由于视频流具有断点传输(或称断点续传)的特性，在服务器与电子设备断开连接进行重连时，服务器可以继续向电子设备发送视频流，实现断线重连。但是，对于指令流分离渲染的方案而言，由于用于图形渲染的渲染上下文之间存在依赖，所以渲染上下文不具备断点传输的特性。因此，在本申请中可以在服务器中保存图形渲染信息，当服务器接收到电子设备发送的请求恢复与服务器连接的指令后，服务器可以向电子设备发送保存的图形渲染信息，从而使得电子设备具有恢复渲染上下文所需的渲染信息，实现服务器和电子设备之间的断线重连。

在一些实现方式中，所述图形渲染信息可以保存在应用程序所运行的服务器中，也可以保存在其他的服务器或其他类型的设备中，或者图形渲染信息也可以采用分布式方式存储在多台设备上或采用远程存储方式存储在其它设备上。

在一些实现方式中，所述图形渲染信息为所述渲染指令。在本申请某些实施例中，服务器可以截取应用程序发送的渲染指令，对渲染指令进行拷贝，一份渲染指令发送至电子设备，另一份渲染指令则保存在服务器。

在一些实现方式中，所述图形渲染信息为渲染信息集合，所述渲染信息集合用于所述电子设备恢复所述应用程序的渲染上下文。在本申请某些实施例中，服务器可以对截取的渲染指令进行处理，以保存电子设备恢复应用程序渲染上下文所需的信息的最小集合，从而能够节约存储空间。

应理解，渲染信息集合可以是电子设备恢复应用程序渲染上下文所需的最小渲染信息。例如，假设渲染指令中可以包括100个顶点数据，电子设备可以根据100个顶点数据中的80个顶点数据进行图形渲染构建图形，则100个顶点数据中构建图形所需的80个顶点数据可以是最小渲染信息，若向电子设备发送81个顶点数据则存在冗余信息；若向电子设备发送79个顶点数据则电子设备无法构建图形。上述为举例说明，并不对本申请作任何限定。

在一些实现方式中，所述方法还包括：根据预配置的信息列表和所述渲染指令确定所述渲染信息集合，所述预配置的信息列表包括恢复所述电子设备与所述服务器连接所需的渲染信息。例如，预配置的信息列表包括重传次数小于预定阈值的渲染信息。

应理解，预配置的信息列表可以是渲染上下文的最小集也可以是最优集，预配置的信息列表中信息过多会造成保存数据的冗余，数据过少不足以恢复渲染上下文进行图形渲染。

可选地，预配置的信息列表可以包括在N帧(N可以设置)图形中不会重传/重置的渲染信息。例如，预配置的信息列表可以是通过分析当前占据绝大多数市场的几款引擎以及典型APP得到的，通过不断抓取场景变换时、触摸反馈时、无输入时等情况下，渲染指令及渲染上下文的变化，经过反复对比和分析得到预配置的信息列表，在该信息列表中可以包括在N帧(N可以设置)图形中不会重传/重置的数据或状态。

在本申请实施例中，可以根据获取的渲染指令以及预配置的信息列表确定电子设备恢复应用程序渲染上下文所需的最小渲染信息，即确定渲染信息集合，从而保存渲染信息集合，在电子设备重新连接到服务器时，向所述电子设备发所述渲染信息集合，以便于所述电子设备恢复断开与所述服务器连接时的图形渲染。

在本申请实施例中，为了节约断线重连所需要的等待时间，服务器可以向电子设备发送渲染信息集合，渲染信息集合可以是电子设备用于恢复应用程序渲染上下文所需的信息的最小集合。

在一些实现方式中，所述方法还包括：根据渲染顺序对所述渲染信息集合中的渲染信息进行重新排序，所述渲染顺序是指所述电子设备的渲染管线运行图形渲染时渲染信息的顺序；向所述电子设备发所述图形渲染信息，包括：向所述电子设备发送重新排序的所述渲染信息集合。

在本申请实施例中，可以对渲染信息集合中的渲染信息进行排序，即可以根据电子设备的渲染管线运行图形渲染时渲染信息的顺序对渲染信息集合进行排序，向电子设备发送重新排序的渲染信息集合，从而能够确保电子设备进行图形渲染时无需关心渲染信息的顺序，降低电子设备侧图形渲染的复杂化。

在一些实现方式中，服务器可以向电子设备发送全部图形渲染信息；或者，可以是服务器向电子设备发送图形渲染信息中的部分信息，然后根据电子设备的需求，例如电子设备的缓存列表，确定电子设备缺失的渲染信息，然后继续向电子设备发送该缺失的渲染信息，即实现按需发送；或者，服务器可以从一开始就根据电子设备的需求向电子设备发送缺失的渲染信息。

在一些实现方式中，所述方法还包括：接收所述电子设备发送的缓存列表，所述缓存列表是所述电子设备缓存的渲染信息的列表；向所述电子设备发所述图形渲染信息，包括：根据缓存列表向所述电子设备发送部分或全部所述图形渲染信息，发送的所述图形渲染信息为在所述缓存列表中不存在的图形渲染信息。具体的，服务器根据所述渲染指令中的一个或多个确定所述电子设备缺失的渲染信息；在所述缓存列表中查找所述缺失的渲染信息，若所述缓存列表中存在所述缺失的渲染信息，则向所述电子设备发送第三指令，所述第三指令用于指示所述电子设备从本地缓存中获取所述缺失的渲染信息；或者，若所述缓存列表中不存在所述缺失的渲染信息，则向所述电子设备发送所述缺失的渲染信息，所述渲染信息集合包括所述缺失的渲染信息。

例如，以OpenGL ES为例，服务器获取的渲染指令包括draw call，draw call又可以包括以下指令(仅示例，不限于以下指令)：glDrawArrays、glDrawElements、glDrawArraysInstanced、glDrawElementsInstanced、glDrawRangeElements、glDrawArraysIndirect、和glDrawElementsIndirect。再例如，以OpenGL ES为例，服务器获取的渲染指令包括关键指令，关键指令可以包括但不限于以下指令：glBindBuffer、glBufferData、glBufferSubData、glBindTexture、glTexImage2D、glTexSubImage2D、glTexImage3D、glTexSubImage3D、glCompressedTexImage2D、glCompressedTexSubImage2D、glCompressedTexImage3D、glCompressedTexSubImage3D。在本申请中，服务器可以获取电子设备的缓存列表，并且监测上述draw cal l指令或关键指令，根据监测的渲染指令确定电子设备缺失的渲染信息，在缓存列表中查找是否存在缺失的渲染信息，当电子设备的缓存列表中不存在缺失的渲染信息时，再向电子设备发送缺失的渲染信息，从而能够加速电子设备恢复渲染上下文的过程，缩短服务器和电子设备之间断线重连的等待时间。

在一些实现方式中，向所述电子设备发所述图形渲染信息，包括：确定指令序列，所述指令序列用于所述电子设备的图形处理器识别所述渲染信息集合；向所述电子设备发送所述指令序列、以及所述渲染信息集合。

在本申请实施例中，为了确保电子设备实现渲染上下文的恢复，先要确保电子设备能够识别渲染信息集合，进一步可以确定指令序列，指令序列用于电子设备的图形处理器识别渲染信息集合。

在一些实现方式中，可以根据渲染信息中状态信息构造不同的指令序列。例如，若状态信息为已经链接过(linked)，则构造的指令序列可以包括创建、编译、挂载等指令；若状态信息为未链接过，则构造的指令序列可以包括重新挂载指令。

第三方面，提供了一种用于图形渲染的方法，该方法应用于电子设备。该方法包括：接收服务器发送的渲染指令，所述渲染指令用于电子设备进行图形渲染；根据所述渲染指令进行图形渲染显示与所述应用程序相关的图像。相比于视频流的云应用方案，该方案服务器发送的是渲染指令，然后在电子设备侧执行图形渲染，从而显示与应用相关的界面等，有益效果可参考前述。

在一些实现方式中，所述方法还包括：向服务器发送第一指令，所述第一指令用于指示所述服务器运行应用程序。

上述渲染指令可以包括用于图形渲染的渲染上下文，渲染上下文可以是图形渲染所需的资源集合，资源集合中可以包括状态信息和数据信息，例如，数据信息可以是多个顶点数据，状态信息可以是当前渲染上下文中绑定的顶点数据。

在本申请中，可以通过指令流方案实现分离渲染，即服务器可以获取应用程序发送的渲染指令，将渲染指令发送至与服务器连接的电子设备，由接收到渲染指令的电子设备进行图形渲染，从而避免了视频流分离渲染的方案中服务器进行图形渲染生成适配于固定屏幕尺寸的视频流，若电子设备与服务器渲染的画面尺寸不匹配则出现图像拉伸或压缩的现象。在本申请的技术方案中，服务器可以将用于图形渲染的渲染指令流发送至电子设备，一方面可以降低服务器中图形处理器的负载，另一方面将渲染指令发送至电子设备，由电子设备在端侧根据渲染指令进行图形渲染，可以更好的适配于电子设备的屏幕尺寸，提高画面质量从而提升用户的体验感。

在一些实现方式中，所述方法还包括：向服务器发送第二指令，所述第二指令用于请求恢复电子设备与所述服务器的连接；接收所述服务器发送的图形渲染信息，所述图形渲染信息是所述服务器保存的所述电子设备用于图形渲染所需的信息。

需要说明的是，对于视频流分离渲染的方案，由于视频流具有断点传输的特性，在服务器与电子设备断开连接进行重连时，服务器可以继续向电子设备发送视频流，实现断线重连。但是，对于指令流分离渲染的方案而言，由于用于图形渲染的渲染上下文之间存在依赖，即渲染上下文不具备断点传输的特性。

因此，在本申请中可以在服务器中保存图形渲染信息，当服务器接收到电子设备发送的请求恢复与服务器连接的指令后，服务器可以向电子设备发送保存的图形渲染信息，从而使得电子设备具有恢复渲染上下文所需的渲染信息，实现服务器和电子设备之间的断线重连。

在一些实现方式中，所述图形渲染信息为所述渲染指令。

在本申请中，服务器可以截取应用程序发送的渲染指令，对渲染指令进行拷贝，一份渲染指令可以发送至电子设备，另一份渲染指令可以在服务器中保存。

在一些实现方式中，所述图形渲染信息为渲染信息集合，所述渲染信息集合用于所述电子设备恢复所述应用程序渲染上下文。

在本申请中，服务器可以对截取的渲染指令进行处理保存电子设备恢复应用程序渲染上下文所需的最小渲染信息，即服务器可以保存渲染信息集合，从而能够节约服务器中的存储空间。

应理解，渲染信息集合可以是电子设备用于恢复应用程序渲染上下文所需的最小渲染信息。例如，假设渲染指令中可以包括100个顶点数据，电子设备可以根据100个顶点数据中的80个进行图形渲染构建图形，则100个顶点数据中构建图形所需的80个顶点数据最小渲染信息，若向电子设备发送81个顶点数据则存在冗余信息；若向电子设备发送79个顶点数据则电子设备无法构建图形。上述为举例说明，并不对本申请作任何限定。

在一种可能的实现方式中，接收所述服务器发送的所述图形渲染信息，包括：接收所述服务器发送的渲染信息集合。

在本申请中，为了节约电子设备与服务器断线重连所需要的等待时间，服务器可以向电子设备发送渲染信息集合，渲染信息集合可以是电子设备用于恢复应用程序渲染上下文所需的最小渲染信息。

在一种可能的实现方式中，接收所述服务器发送的渲染信息集合，包括：接收重新排序的所述渲染信息集合，所述重新排序的所述渲染信息集合是根据渲染顺序对所述渲染信息集合中的渲染信息进行重新排序生成的渲染信息集合，所述渲染顺序是指所述电子设备的渲染管线运行图形渲染时渲染信息的顺序。

在本申请中，可以对渲染信息集合中的渲染信息进行排序，即可以根据电子设备的渲染管线运行图形渲染时渲染信息的顺序对渲染信息集合进行排序，向电子设备发送重新排序的渲染信息集合，从而能够确保电子设备进行图形渲染时无需关心渲染信息的顺序，降低图形渲染的复杂化。

在一些实现方式中，所述方法还包括：确定指令序列，所述指令序列用于所述电子设备的图形处理器识别所述渲染信息集合。

在本申请中，为了确保实现渲染上下文的恢复，即为了确保电子设备能够识别渲染信息集合，进一步可以确定指令序列，指令序列用于电子设备的图形处理器识别渲染信息集合。

在一些实现方式中，所述渲染信息集合中包括第一标识信息和第一渲染信息，所述第一标识信息为所述服务器用于标识所述第一渲染信息的标识信息，所述方法还包括：

确定映射关系，所述映射关系是所述第一标识信息和所述第二标识信息的对应关系，所述第二标识信息为所述电子设备用于标识所述第一渲染信息的标识信息。

例如，电子设备接收服务器发送的渲染信息集合，渲染信息集合中包括第一渲染信息，第一渲染信息中包括服务器设置的标识，例如标识为#5；电子设备的GPU根据该第一渲染信息进行图形渲染并向电子设备反馈标识，例如标识#4，则电子设备可以确定映射关系，即服务器的#5和电子设备的#4之间的对应关系。

第四方面，提供了一种用于图形渲染的方法，包括：接收电子设备发送的第四指令，所述第四指令用于指示所述电子设备与服务器断开连接；获取所述应用程序发送的渲染指令，所述渲染指令用于所述服务器进行图形渲染；接收所述电子设备发送的第二指令，所述第二指令用于请求恢复所述电子设备与所述服务器的连接；保存图形渲染信息，所述图形渲染信息用于恢复渲染上下文，所述渲染上下文为接收所述第二指令时所述应用程序的渲染上下文；根据所述图形渲染信息进行图形渲染，生成视频流；向所述电子设备发送所述视频流。。

应理解，在本申请的实施例中，服务器可以根据电子设备与服务器的连接情况进行按需渲染，即若电子设备与服务器处于连接态，则服务器的图形处理器根据渲染指令进行图形渲染生成视频流；若电子设备与服务器处于离线连接态，则服务器中的图形处理器不进行图形渲染。

在本申请中，当电子设备与服务器断开连接后，服务器可以不进行图形渲染，可以在服务器中保存图形渲染信息，当服务器接收到电子设备发送的请求恢复与服务器连接的指令后，服务器可以根据图形渲染信息进行图形渲染生成视频流，向电子设备发送视频流，使得服务器和电子设备之间实现按需图形渲染，从而能够减少服务器的负载。

在一些实现方式中，所述图形渲染信息为所述渲染指令。

在本申请中，服务器可以截取应用程序发送的渲染指令，对渲染指令进行拷贝，一份渲染指令可以发送至电子设备，另一份渲染指令可以在服务器中保存。

在一些实现方式中，所述图形渲染信息为渲染信息集合，所述图形渲染信息为对所述渲染指令进行处理得到的渲染信息集合。

在本申请中，服务器可以保存渲染信息集合，即服务器中可以保存电子设备恢复应用程序渲染上下文的最小渲染信息，从而能够节约服务器中的存储空间。

在一些实现方式中，所述根据所述渲染指令确定图形渲染信息，包括：根据预配置的信息列表和所述渲染指令确定所述渲染信息集合，所述预配置的信息列表包括重传次数小于预定阈值的渲染信息。

应理解，预配置的信息列表可以是渲染上下文的最小集也可以是最优集，预配置的信息列表中信息过多会造成保存数据的冗余，数据过少不足以恢复渲染上下文进行图形渲染。

可选地，预配置的信息列表可以包括在N帧(N可以设置)图形中不会重传/重置的渲染信息。

例如，预配置的信息列表可以是通过分析当前占据绝大多数市场的几款引擎以及典型APP得到的，通过不断抓取场景变换时、触摸反馈时、无输入时等情况下，渲染指令及渲染上下文的变化，经过反复对比和分析得到预配置的信息列表，在该信息列表中可以包括在N帧(N可以设置)图形中不会重传/重置的数据或状态。

在本申请中，可以根据获取的渲染指令以及预配置的信息列表确定电子设备恢复应用程序渲染上下文的最小渲染信息，即确定渲染信息集合，从而在服务器中保存渲染信息集合。

在一些实现方式中，所述方法还包括：确定指令序列，所述指令序列用于所述服务器的图形处理器识别所述渲染信息集合。

在本申请中，为了确保实现渲染上下文的恢复，即为了确保服务器的图形处理器能够识别渲染信息集合进行渲染生成视频流，进一步可以确定指令序列，指令序列用于服务器的图形处理器识别渲染信息集合。

第五方面，提供一种图形渲染装置，该装置包括用于执行第一方面中所描述的方法/操作/步骤/动作所对应的模块。

上述装置可以是服务器，也可以是服务器中的用于执行图形渲染的装置(例如，芯片，或者是能够和服务器匹配使用的装置)。

上述图形渲染装置包括的模块可以是硬件电路，也可是软件，也可以是硬件电路结合软件实现。

第六方面，提供一种图形渲染装置，该装置包括用于执行第二方面中所描述的方法/操作/步骤/动作所对应的模块。

上述装置可以是服务器，也可以是服务器中的用于执行图形渲染的装置(例如，芯片，或者是能够和服务器匹配使用的装置)。

上述图形渲染装置包括的模块可以是硬件电路，也可是软件，也可以是硬件电路结合软件实现。

第七方面，提供了一种图形渲染装置，该装置包括用于执行第三方面中所描述的方法/操作/步骤/动作所对应的模块。

上述装置可以是电子设备，也可以是电子设备中的用于执行图形渲染的装置(例如，芯片，或者是能够和电子设备匹配使用的装置)。

上述图形渲染装置包括的模块可以是硬件电路，也可是软件，也可以是硬件电路结合软件实现。

第八方面，提供一种图形渲染装置，该装置包括用于执行第四方面中所描述的方法/操作/步骤/动作所对应的模块。

上述装置可以是服务器，也可以是服务器中的用于执行图形渲染的装置(例如，芯片，或者是能够和服务器匹配使用的装置)。

上述图形渲染装置包括的模块可以是硬件电路，也可是软件，也可以是硬件电路结合软件实现。

第九方面，提供了一种图形渲染装置，该装置包括处理器，该处理器用于调用存储器存储的程序代码以执行上述第一方面中的任意一种方式中的部分或全部操作。

上述装置中，存储程序代码的存储器既可以位于图形渲染装置内部(图形渲染装置除了包括处理器之外，还可以包括存储器)，也可以位于图形渲染装置外部(可以是其他设备的存储器)。

可选地，上述存储器为非易失性存储器。

当图形渲染装置包括处理器和存储器时，该处理器和存储器可以耦合在一起。

第十方面，提供了一种图形渲染装置，该装置包括处理器，该处理器用于调用存储器存储的程序代码以执行上述第二方面中的任意一种方式中的部分或全部操作。

上述装置中，存储程序代码的存储器既可以位于图形渲染装置内部(图形渲染装置除了包括处理器之外，还可以包括存储器)，也可以位于图形渲染装置外部(可以是其他设备的存储器)。

可选地，上述存储器为非易失性存储器。

当图形渲染装置包括处理器和存储器时，该处理器和存储器可以耦合在一起。

第十一方面，提供了一种图形渲染装置，该装置包括处理器，该处理器用于调用存储器存储的程序代码以执行上述第三方面中的任意一种方式中的部分或全部操作。

上述装置中，存储程序代码的存储器既可以位于图形渲染装置内部(图形渲染装置除了包括处理器之外，还可以包括存储器)，也可以位于图形渲染装置外部(可以是其他设备的存储器)。

可选地，上述存储器为非易失性存储器。

当图形渲染装置包括处理器和存储器时，该处理器和存储器可以耦合在一起。

第十二方面，提供了一种图形渲染装置，该装置包括处理器，该处理器用于调用存储器存储的程序代码以执行上述第四方面中的任意一种方式中的部分或全部操作。

上述装置中，存储程序代码的存储器既可以位于图形渲染装置内部(图形渲染装置除了包括处理器之外，还可以包括存储器)，也可以位于图形渲染装置外部(可以是其他设备的存储器)。

可选地，上述存储器为非易失性存储器。

当图形渲染装置包括处理器和存储器时，该处理器和存储器可以耦合在一起。

第十三方面，提供了一种计算机可读存储介质，计算机可读存储介质存储了程序代码，其中，程序代码包括用于执行上述任一方面所描述的方法中的部分或全部操作的指令。

可选地，上述计算机可读存储介质位于电子设备内，该电子设备可以是能够进行图形渲染的装置。

第十四方面，本申请实施例提供一种计算机程序产品，当计算机程序产品在通信装置上运行时，使得通信装置执行上述任一方面所描述的方法中的部分或全部操作。

第十五方面，提供了一种芯片，所述芯片包括处理器，所述处理器用于执行上述任一方面所描述的方法中的部分或全部操作。

第十六方面，提供了一种系统，包括前述的电子设备以及前述的服务器。

附图说明

图1是根据本申请一实施例提供的用于图形渲染的系统架构的示意图；

图2是根据本申请另一实施例提供的用于图形渲染的系统架构的示意图；

图3是本申请中电子设备根据获取的渲染指令进行图形渲染的示意性流程图；

图4是根据本申请一实施例提供的用于图形渲染的方法的示意性流程图；

图5是根据本申请另一实施例提供的用于图形渲染的方法的示意性流程图；

图6是根据本申请一实施例提供的确定状态机快照的示意性流程图；

图7是根据本申请已实施例提供的按需加载方法的示意性流程图；

图8是根据本申请一实施例提供的图形渲染装置的结构性示意图；

图9是根据本申请另一实施例提供的图形渲染装置的结构性示意图；

图10是根据本申请一实施例提供的服务器的结构性示意图；

图11是根据本申请一实施例提供的电子设备的结构性示意图。

具体实施方式

下面将结合附图，对本申请中的技术方案进行描述。

本申请实施例中用于图形渲染方法可以由电子设备来执行。该电子设备可以是移动终端(例如，智能手机)，电脑，个人数字助理，可穿戴设备，车载设备，物联网设备或者其他能够进行图形渲染处理的设备。该电子设备可以是运行安卓系统、IOS系统、windows系统以及其他系统的设备。

本申请实施例用于图形渲染的方法可以实现指令流分离渲染的方案，其中，指令流分离渲染的方案是指可以在云侧(例如，服务器)截取APP发送的渲染指令，该渲染指令用于电子设备进行图形渲染，渲染指令中可以包括渲染上下文所需的渲染信息，渲染信息可以包括状态信息和数据信息，例如，数据信息可以是多个顶点数据，状态信息可以是当前渲染上下文中绑定的顶点数据。

本申请实施例的用于图形渲染的方法可以应用于图1所示系统架构中。

如图1所示，系统架构中可以包括服务器110和电子设备120，服务器110中可以包括一个或者多个应用程序APP，服务器110中还包括拦截机，拦截机可以用于截取APP发送的渲染指令，通过网络传输控制协议(transmission control protocol，TCP)或代理agent将渲染指令重定至电子设备，电子设备接收到渲染指令后，电子设备中的渲染管线可以建立、维护渲染上下文，进行图形渲染操作。其中，拦截机可以是在服务器运行用于获取APP渲染指令的一段程序，例如，拦截机获取的渲染指令可以是OpenGL ES 2.0、OpenGL ES 3.0或者EGL。

应理解，如图1所示的指令流分离渲染的方案中，当电子设备与服务器连接时，可以在电子设备的GPU中进行图形渲染，即可以将用于图形渲染的渲染指令重定向至电子设备，从而电子设备的GPU可以根据渲染指令进行图形渲染。例如，可以根据渲染指令生成适配于电子设备的屏幕尺寸的图形，从而能够提高图形的清晰度，提升用户的体验感。

在视频流分离渲染的方案中，服务器的GPU可以获取应用程序发送的渲染指令进行图形渲染，生成视频流。由于视频流中的图像之间无状态依赖，因此电子设备与服务之间可以实现断线重连。即当电子设备与服务器之间从离线状态切换至连接状态时，电子设备可以继续获取服务器发送的视频流，实现与服务器的断线连接。但是，对于指令流分离渲染的方案，当电子设备与服务器断开连接时，电子设备无法再继续接收到服务器发送的渲染指令，由于电子设备缺失部分图形渲染所需的渲染信息且渲染信息存在状态依赖，导致电子设备无法继续进行图形渲染。为了在指令流分离渲染的方案中能够实现电子设备与服务器的断线重连，可以采用如图2所示的系统架构。

如图2所示，可以在系统架构中设置保存模块和恢复模块，其中，保存模块可以位于服务器中并且可以被任意APP使用，拦截机截取的所有渲染指令可以发送至电子设备，同时可以将渲染指令进行拷贝保存至保存模块中。此外，保存模块还可以生成快照，快照是指电子设备用于恢复渲染上下文的信息集合的副本。恢复模块可以位于服务器中，或者，也可以位于电子设备中，恢复模块用于电子设备重建渲染上下文。

下面结合图3对电子设备的具体结构进行详细的介绍。图3所示的电子设备可以是图1所示的系统架构中的电子设备110，或者，也可以是图2所示的系统架构中的电子设备140。

在一个实施例中，如图3所示，电子设备100可以包括：中央处理器(CPU)101、图形处理器(GPU)102、显示设备103和存储器104。可选地，该电子设备100还可以包括至少一个通信总线110(图3中未示出)，用于实现各个组件之间的连接通信。

应当理解，电子设备100中的各个组件还可以通过其他连接器相耦合，其他连接器可包括各类接口、传输线或总线等。电子设备100中的各个组件还可以是以处理器101为中心的放射性连接方式。在本申请的各个实施例中，耦合是指通过相互电连接或连通，包括直接相连或通过其他设备间接相连。

中央处理器101和图形处理器102的连接方式也有多种，不局限于图3所示的方式。电子设备100中的中央处理器101和图形处理器102可以位于同一个芯片上，也可以分别为独立的芯片。

下面对中央处理器101、图形处理器102、显示设备103的作用进行简单的介绍。

中央处理器101：用于运行操作系统105和应用程序107。应用程序107可以为图形类应用程序，比如游戏、视频播放器等等。操作系统1005提供了系统图形库接口，应用程序107通过该系统图形库接口，应用程序107可以接收服务器发送的用于渲染图形或图像帧的指令流(例如，渲染指令)。操作系统105提供的驱动程序，比如图形库用户态驱动和/或图形库内核态驱动，生成图形处理器102中渲染管线能够识别的指令流以及所需的相关渲染数据。其中，系统图形库包括但不限于：嵌入式开放图形库(open graphics library forembedded system，OpenGL ES)、柯罗诺斯平台图形界面(the khronos platform graphicsinterface)或Vulkan(一个跨平台的绘图应用程序接口)等系统图形库。指令流包含一些列的指令，这些指令通常为对系统图形库接口的调用指令。

可选地，中央处理器101可以包括以下至少一种类型的处理器：应用处理器、一个或多个微处理器、数字信号处理器(digital signal processor,DSP)、微控制器(microcontroller unit，MCU)或人工智能处理器等。

中央处理器101还可进一步包括必要的硬件加速器，如专用集成电路(application specific integrated circuit，ASIC)、现场可编程门阵列(fieldprogrammable gate array，FPGA)、或者用于实现逻辑运算的集成电路。处理器101可以被耦合到一个或多个数据总线，用于在电子设备100的各个组件之间传输数据和指令。

图形处理器102：用于接收处理器101发送的图形指令流，通过渲染管线(pipeline)生成渲染目标，并通过操作系统的图层合成显示模块将渲染目标显示到显示设备103。

可选地，图形处理器102可以包括执行软件的通用图形处理器，如GPU或其他类型的专用图形处理单元等。

显示设备103：用于显示由电子设备100生成的各种图像，该图像可以为操作系统的图形用户界面(graphical user interface，GUI)或由图形处理器1002处理的图像数据(包括静止图像和视频数据)。

可选地，显示设备103可以包括任何合适类型的显示屏。例如液晶显示器(liquidcrystal display，LCD)或等离子显示器或有机发光二极管(organic light-emittingdiode，OLED)显示器等。

渲染管线是图形处理器102在渲染图形或图像帧的过程中顺序执行的一系列操作，典型的操作包括：顶点处理(vertex processing)、图元处理(primitive processing)、光栅化(rasterization)、片段处理(fragment processing)等等。

上文中介绍了本申请实施例适用的系统架构以及电子设备内部执行图形渲染的流程。下面结合附图4对本申请实施例中的用于图形渲染的方法进行详细的介绍。其中，服务器可以是图1或图2所示的服务器，电子设备可以是图1至图3中任一个所示的电子设备。

图4所示的方法包括步骤210至240，下面分别对这些步骤进行详细的描述。

210、服务器接收电子设备发送的第一指令，第一指令用于指示服务器运行应用程序。

在本申请的实施例中，服务器中可以包括一个或多个应用程序，应用程序的客户端可以安装在电子设备上。电子设备可以向服务器发送指令，启动服务器中应用程序的运行。在其他实施例中，服务器可以自行启动应用程序，不需要电子设备触发。

220、服务器获取所述应用程序发送的渲染指令，渲染指令用于电子设备进行图形渲染。

例如，可以如图1或者图2所示，服务器中的拦截机用于拦截应用程序发送的渲染指令，其中，拦截机可以是在服务器运行用于获取APP渲染指令的一段程序。

230、服务器将渲染指令发送至电子设备。

240、电子设备根据渲染指令执行渲染以显示所述应用程序。

在本申请的实施例中，服务器可以将拦截机获取的应用程序的渲染指令发送至电子设备。例如，在图1或图2所示的系统架构中，服务器可以通过TCP或代理(agent)将渲染指令发送至电子设备。

进一步地，在本申请的实施例中，服务器可以保存图形渲染信息，所述图形渲染信息是所述电子设备用于图形渲染所需的信息。其中，图形渲染信息可以是截取的应用程序发送的渲染指令，或者，图形渲染信息也可以是对截取的应用程序发送的渲染指令进行处理后得到的渲染信息集合。

例如，如图2所示，在服务器130中可以对截取的应用程序的渲染指令进行处理，一份发送至电子设备，使得电子设备根据渲染指令进行图形渲染，此外另一份可以保存至电子设备中。

例如，服务器可以对截取的渲染指令进行处理保存电子设备恢复应用程序渲染上下文所需的最小渲染信息，即服务器可以保存渲染信息集合。

应理解，渲染信息集合可以是电子设备恢复应用程序渲染上下文所需的最小渲染信息。例如，假设渲染指令中可以包括100个顶点数据，电子设备可以根据100个顶点数据中的80个顶点数据进行图形渲染构建图形，则100个顶点数据中构建图形所需的80个顶点数据可以是最小渲染信息，若向电子设备发送81个顶点数据则存在冗余信息；若向电子设备发送79个顶点数据则电子设备无法构建图形。上述为举例说明，并不对本申请作任何限定。

可选地，在本申请的实施例中，服务器可以接收所述电子设备发送的第二指令，所述第二指令用于请求恢复与所述服务器的连接；服务器可以向电子设备发所述图形渲染信息。

在本申请的实施例中，渲染信息集合可以是由服务器确定的。例如，服务器可以根据配置的信息列表(例如，图5所示的关键资源列表)和渲染指令确定渲染信息集合(例如，

图5所示的关键资源集合)，预配置的信息列表可以包括恢复所述电子设备与所述服务器连接所需的渲染信息。

例如，预配置的信息列表可以是通过分析当前占据绝大多数市场的几款引擎以及典型APP得到的，通过不断抓取场景变换时、触摸反馈时、无输入时等情况下，渲染指令及渲染上下文的变化，经过反复对比和分析得到预配置的信息列表，在该信息列表中可以包括在多帧(可定阈值)图形中不会重传/重置的数据或状态。

例如，对于同一状态信息，多帧图形的数据信息的传输过程可以是数据A-数据B-数据C-数据B-数据C，则可以看出在该多帧图形数据中数据B和数据C会进行重复的传输，则其中数据A是在多帧图形中不会重传/重置的数据信息。因此，在这种情况下，信息列表中可以包括数据A或者数据A的索引值。

应理解，预配置的信息列表可以是渲染上下文的最小集也可以是最优集，预配置的信息列表中信息过多会造成保存数据的冗余，数据过少不足以恢复渲染上下文进行图形渲染。

可选地，在本申请的实施例中服务器接收到电子设备发送的用于请求恢复与服务器连接的指令后，可以向电子设备发送服务器保存的图形渲染信息。

在一个示例中，电子设备可以接收服务器保存的渲染指令，渲染指令可以是服务器截取应用程序发送的渲染指令。

在一个示例中，为了节约断线重连所需要的等待时间，电子设备可以接收到服务器发送的渲染信息集合，渲染信息集合可以是电子设备用于恢复应用程序渲染上下文所需的最小渲染信息。

应理解，在本申请的实施例中，服务器保存的渲染指令可以是未经处理的应用程序发送的指令，或者，服务器可以进一步节约存储空间对获取的渲染指令进行处理保存得到的渲染信息集合。

在本申请的实施例中，为了确保渲染上下文的恢复，即为了确保电子设备能够识别渲染信息集合，进一步地可以确定指令序列，例如，构造指令序列，其中，指令序列用于电子设备的图形处理器识别渲染信息集合。

例如，可以在服务器中确定指令序列，当服务器向电子设备发送指令序列后，电子设备的GPU可以识别指令序列中的用于图形渲染的信息。

例如，可以在电子设备中确定指令序列。具体地，可以是服务器向电子设备发送渲染信息集合，电子设备的CPU接收渲染信息集合后，电子设备的CPU确定指令序列，将指令序列由电子设备的CPU发送至电子设备的GPU，使得电子设备的GPU根据渲染信息集合进行图形渲染。

在一个示例中，渲染信息集合中可以包括第一标识信息和第一渲染信息，第一标识信息为可以是服务器用于标识所述第一渲染信息的标识信息，电子设备可以确定映射关系，映射关系是第一标识信息和第二标识信息的对应关系，第二标识信息为电子设备用于标识第一渲染信息的标识信息。

例如，电子设备接收服务器发送的渲染信息集合，渲染信息集合中包括第一渲染信息，第一渲染信息中包括服务器设置的标识，例如标识为#5；电子设备的GPU根据该第一渲染信息进行图形渲染并向电子设备反馈标识，例如标识#4，则电子设备可以确定映射关系，即服务器的#5和电子设备的#4之间的对应关系。

在一个示例中，为了确保电子设备恢复应用程序渲染上下文时降低复杂化，服务器可以根据渲染顺序对渲染信息集合中的渲染信息进行重新排序，渲染顺序是指电子设备的渲染管线运行图形渲染时渲染信息的顺序；服务器可以向电子设备发送重新排序的所述渲染信息集合。

可选地，在本申请的实施例中，电子设备可以向服务器发送缓存列表，缓存列表中包括电子设备在本地缓存的渲染信息；进一步地，当服务器接收到电子设备发送的用于请求恢复与所述服务器的连接后，服务器可以先监测渲染指令，确定电子设备可能缺失的渲染信息。在电子设备的缓存列表中查找缺失的渲染信息，若缓存列表中存在缺失的渲染信息，则向电子设备发送第三指令，第三指令用于指示电子设备从本地缓存中获取缺失的渲染信息；或者，在电子设备的缓存列表中查找缺失的渲染信息，若缓存列表中不存在缺失的渲染信息，则向电子设备发送缺失的渲染信息。

需要说明的是，在本申请的实施例中，服务器可以先监测应用程序发送的drawcall或者关键指令，确定电子设备恢复渲染上下文所需的资源，进一步服务器会判断是否对该资源进行过恢复；若服务器确定未对该资源进行过恢复，则服务器可以在电子设备的缓存列表中进行查找，从而确定电子设备的缓存列表中是否存在该资源，当缓存列表中存在该资源时，服务器可以指示电子设备从其本地缓存中获取该资源；当缓存列表中不存在该资源时，服务器可以向电子设备发送该资源。若服务器确定对该资源进行过恢复，则服务器不执行任何操作。其中，恢复渲染上下文所需的资源也就是电子设备恢复渲染上下文所需的渲染信息，即可以是电子设备缺失的渲染信息。

应理解，电子设备在本地缓存的渲染信息可以包括数据信息且不包括状态信息，也就是说，电子设备在本地缓存的渲染信息可以是用于图形渲染的数据信息。

例如，以OpenGL ES为例，draw call可以包括但不限于以下指令：

glDrawArrays、glDrawElements、glDrawArraysInstanced、glDrawElementsInstanced、glDrawRangeElements、glDrawArraysIndirect、glDrawElementsIndirect。

例如，以OpenGL ES为例，关键指令可以包括但不限于以下指令：

glBindBuffer、glBufferData、glBufferSubData、glBindTexture、glTexImage2D、glTexSubImage2D、glTexImage3D、glTexSubImage3D、glCompressedTexImage2D、glCompressedTexSubImage2D、glCompressedTexImage3D、glCompressedTexSubImage3D。

在本申请中，可以通过指令流方案实现分离渲染，即服务器可以获取应用程序发送的渲染指令，将渲染指令发送至与服务器连接的电子设备，由接收到渲染指令的电子设备进行图形渲染，从而避免了视频流分离渲染的方案中服务器进行图形渲染生成适配于固定屏幕尺寸的视频流，若电子设备与服务器渲染的画面尺寸不匹配则出现图像拉伸或压缩的现象。在本申请的技术方案中，服务器可以将用于图形渲染的渲染指令流发送至电子设备，一方面可以降低服务器中图形处理器的负载，另一方面将渲染指令发送至电子设备，由电子设备在端侧根据渲染指令进行图形渲染，可以更好的适配于电子设备的屏幕尺寸，提高画面质量从而提升用户的体验感。

本申请还提供了一种用于图形渲染的方法，该方法可以使得视频流分离渲染的方案实现按需渲染，即服务器可以根据电子设备与服务器的连接情况进行按需渲染，即若电子设备与服务器处于连接态，则服务器的图形处理器可以根据渲染指令进行图形渲染生成视频流；若电子设备与服务器中处于离线状态，则服务器中的图形处理器不进行图形渲染。

在一个示例中，本申请提出了一种用于图形渲染的方法，包括：服务器接收电子设备发送的第四指令，所述第四指令用于指示所述电子设备与服务器断开连接；服务器获取所述应用程序发送的渲染指令，所述渲染指令用于所述服务器的图形处理器进行图形渲染生成视频流；服务器根据所述渲染指令确定图形渲染信息，所述图形渲染信息是所述服务器生成视频流所需的渲染信息；服务器保存所述图形渲染信息。

需要说明的是，上述本申请的实施例也适用于视频流分离渲染的方案，对于视频流分离渲染的方案与指令流分离渲染的方案存在的差异在于，指令流分离渲染的方案将保存的图形渲染信息发送至电子设备，电子设备根据图形渲染信息进行图形渲染；而对于视频流分离渲染的方案，可以将保存的图形渲染信息发送至服务器的图形处理器中，由服务器的图形处理器根据图形渲染指令进行图形渲染生成视频流，向电子设备发送视频流。上述实施例中，保存图形渲染信息以及恢复渲染上下文的过程同样适用于视频流分离渲染的方案，此处不再赘述。

可选地，在本申请的实施例中，当服务器接收到电子设备发送的第二指令，所述第二指令用于请求恢复所述电子设备与所述服务器的连接；服务器根据所述图形渲染信息进行图形渲染，生成视频流；服务器向所述电子设备发送所述视频流。

在本申请中，当电子设备与服务器断开连接后，服务器可以不进行图形渲染，可以在服务器中保存图形渲染信息，图形渲染信息可以是服务器用于图形渲染所需的信息，当服务器接收到电子设备发送的请求恢复与服务器连接后，服务器可以根据图形渲染信息进行图形渲染，生成视频流，向电子设备发送视频流，使得服务器和电子设备之间实现按需渲染，进一步能够减轻服务器GPU的压力，从而在视频流分离渲染的方案中服务器运行的实例密度得到显著提升。

在一个示例中，图形渲染信息可以是渲染指令，即服务器中保存的渲染信息可以是获取的应用程序发送的渲染指令。

在一个示例中，图形渲染信息可以是渲染信息集合，渲染信息集合用于所述电子设备恢复所述应用程序渲染上下文。

可选地，在本申请的实施例中，所述根据所述渲染指令确定图形渲染信息，包括：根据预配置的信息列表和所述渲染指令确定所述渲染信息集合，所述预配置的信息列表包括恢复所述电子设备与所述应用程序连接所需的渲染信息。

可选地，在本申请的实施例中，服务器还可以确定指令序列，所述指令序列用于所述服务器的图形处理器识别所述渲染信息集合。

例如，服务器的中央处理器确定指令序列，指令序列用于服务器的图形处理器能够识别渲染信息集合，从而使得服务器的图形处理器根据渲染信息集合进行图形渲染生成视频流。

图5是本申请实施例提供的一种用于图形渲染的方法的示意性流程图。图5所示的方法可以包括步骤301至310，下面分别对步骤301至310进行详细描述。其中，端侧/渲染端可以是图1至图4中所示的任意一个电子设备，APP、状态机保存模块、状态机可以位于服务器中，状态机恢复模块可以位于电子设备或服务器。应理解，在本申请中状态机可以是渲染上下文。

步骤301：端侧/渲染端首次连接。即可以是端侧/渲染端与服务器中的APP首次连接。

步骤301：端侧/渲染端可以向APP发送启动指令。

例如，可以是图4中的第一指令。

步骤303：云侧更新和维护状态机。

需要说明的是，云侧更新和维护状态机可以是服务器根据接收到APP发送的渲染指令，使用相应的数据结构对图形渲染所必须的数据和状态进行实时保存和更新。

步骤304：进行远程渲染，即可以是将APP发送的渲染指令发送至电子设备，电子设备根据获取的渲染指令进行图形的渲染。

步骤305：状态机保存模块接收到端侧/渲染端发送的请求状态机恢复/重建的指令。

其中，请求状态机恢复/重建的指令可以是上述实施例中的第二指令，第二指令用于请求恢复电子设备与服务器的连接。

在本申请中，云侧接收到端侧发送的请求状态机恢复/重建触发命令或其它触发命令后，根据预设的关键资源列表提取状态机中的关键资源；进一步地，可以对提取出的关键资源，根据资源依赖关系(可以是上述实施例中的渲染顺序)进行资源重排，并生成快照。其中，快照可以是某一时刻关键资源集合的副本。

图6是本申请实施例提供的服务器生成快照的示意性图。图6中包括步骤410至440，下面分别对步骤410至440进行详细描述。

步骤410：获取关键资源列表和状态机。

其中，渲染上下文所需的资源即渲染信息，资源是由数据信息和状态信息组成，以android分离渲染为例(也可以适用于IOS)，又可把资源可以分为EGL层和OpenGL ES层，其中OpenGL ES资源又由以下部分组成：

OpenGL ES状态信息可以包括但不限于以下内容：

1、各种全局状态的绑定，如buffer与target的绑定，当前各类参数的设置等；

2、顶点属性指针的设定；

3、所有Texture、EGLImage、Sampler的绑定；

4、Framebuffer object、RenderBuffer object的绑定；

5、Program和Shader的绑定及其当前状态；

6、vertex Attribute顶点属性和uniform变量的设定。

这些绑定关系(即状态)对应的数据，可以包括但不限于以下内容：

1、buffer data；

2、sampler data；

3、Texture data；

4、FrameBuffer/RenderBuffer data；

5、shader string data。

在本申请的实施例中，关键资源列表可以是预配置的信息列表，可以通过分析各游戏引擎在不同情形下的渲染指令序列，抽象出关键资源列表，关键资源列表可以是渲染上下文的最小集也是最优集，其中，关键资源列表中信息过多会让快照膨胀，关键资源列表中过少会不足以恢复渲染上下文，因此对其的抽象与定义至关重要。

对关键资源列表的抽象可以是个静态的过程，即对关键资源列表的获取可能无法通过特定的API或方法从当前服务器的CPU或GPU中获得。可以通过分析当前占据绝大多数市场的几款引擎以及典型APP，不断抓取场景变换时、触摸反馈时、无输入时等情况下，渲染指令及渲染上下文资源的变化，经过反复对比和分析，得出关键资源列表包括在多帧(预设阈值)中不会重传/重置的数据或状态。

例如，确定关键资源列表可以包括但不限于以下步骤：

步骤1：对引擎进行分类，确定抓取不同场景的渲染指令；

步骤2：确定某一场景，设置预设帧数，如100帧；

步骤3：确定预设帧数量的图像中重传次数较少的渲染信息；

步骤4：在不同的场景下，重复执行上述步骤1至步骤3，最终不同场景下获取的传次数较少的渲染信息的并集被确定为关键资源列表。

除以上步骤之外，关键资源列表还可以结合触摸反馈、无输入等其他情况下渲染信息传输情况来获得。

应理解，在本申请的实施例中，关键资源列表也可以是基于人工智能(artificialintelligence，AI)技术得到的，其中，AI可以是利用数字计算机或者数字计算机控制的机器模拟、延伸和扩展人的智能，感知环境、获取知识并使用知识获得最佳结果的理论、方法、技术及应用系统。例如，关键资源列表可以是基于神经网络算法，或者，计算机算法模型得到的。上述为举例说明，并不对关键资源列表的来源方式进行任何限定。

为了提高效率，关键资源列表通常是线下获取的，但是如果有效率很高的获取方式，关键资源列表也可以通过该方式在线上实时获取，本申请对此不做限定。

在一个示例中，关键资源可以包括但不限于以下资源：

1、少数或者仅在某个场景第一次切换进入才会更新的全局状态；

2、会调用sub指令进行更新的所有指令对应的数据，即上述五类数据中的buffer和texture数据，但不包含绝大多数纹理属性的设置状态；

3、program/shader string的所有资源和当前状态，包含compiled状态、attached状态、uniform设置变量以及少数不会频繁更新的vertex Attribute顶点属性；

4、frame buffer/render buffer object的attach点状态(绑定)及其对应的数据，但不包含glreadbuffer/gldrawbuffers所设置的参数；

对于大部分全局状态的设置，以及program对应的attributes顶点属性指针设置等信息，都会在每个draw call中不断进行更新，因此这部分状态或数据显然可以属于非关键资源，无需恢复，可以在后续的draw call中获取。

在本申请中，状态机可以实现完整的EGL/OpenGL ES标准，将拦截所有APP发送的渲染指令进行调用，渲染指令所包含资源可能分属不同Context，判别当前渲染指令所属OpenGL ES版本后分发到相应的Context，然后再根据该渲染指令包含的资源类型，最终分发到不同的Object Resource中，每种Object Resource可以由很多个Object Resource实例组成。

在服务器中可以截获APP发送的渲染指令，一份正常发往电子设备中，一份重定向到服务器的状态机中，对渲染上下文资源和状态的修改，如执行资源创建，删除，绑定关系维护等操作，都会同步到Context的各ObjectResource中，确保服务器中的状态机完备，状态迁移能够持续进行。

需要说明的是，服务器中可以维护一个状态机，它存在的目的是能持续接收从APP拦截得来的渲染指令，并能更新到相应的数据结构中，在电子设备请求状态机恢复时，通过关键资源列表，从状态机中抽取出关键资源集合。

步骤420：关键资源集合，即服务器根据步骤410中关键资源列表和状态机确定关键资源集合。

应理解的是，关键资源列表可以是预配置的信息列表。在端侧请求状态机恢复时，服务器可以通过关键资源列表从状态机中抽取出关键资源集合。

步骤430：资源重排。

在本申请中，由于不同种类的资源存在之间依赖关系，因此可以重排相互依赖的资源，确保恢复渲染上下文时无需关心资源依赖关系而令恢复时指令构造复杂化。其中，依赖关系可以是渲染顺序，渲染顺序是指电子设备的渲染管线运行图形渲染时渲染信息的顺序。

例如，全局资源的保存须在各类Object Data之后进行；纹理/Images的资源保存须在FrameBuffer之前进行等。资源的保存顺序(以Android状态机保存为例)可以按照以下顺序：EGL层资源-ObjectResource<Buffer>-ObjectResource<VertexArray>-ObjectResource<Texture>-ObjectResource<Sampler>-ObjectResource<Program/Shader>-ObjectResource<RenderBuffer>-ObjectResource<FrameBuffer>-全局状态。

步骤440：确定状态机快照。

在本申请中可以根据资源重排确定关键资源(数据+状态)，生成状态机快照，可以持久化也可以选择常驻云侧内存。

通过图6所示的服务器生成快照的示意性图之后，可以执行图5所示的用于图形渲染的方法的示意性流程图中的步骤306，发送状态机快照。其中，状态机快照可以是图4所示的实施例中的重新排序的所述渲染信息集合。

步骤307：触发渲染上下文重建操作。

应理解，渲染上下文的重建操作可以在电子设备中执行，也可以在服务器中执行。

下面以渲染上下文的重建操作在电子设备中执行举例说明。

在上述步骤430中，服务器可以根据渲染顺序对关键资源集合进行重排，故渲染上下文的重建即渲染上下文恢复时，可以无需关注资源顺序问题而造成资源恢复失败的问题。需要根据当前每类资源状态，产生不同的指令序列即可，即需要根据当前每类资源状态构造电子设备的GPU能够识别的指令序列，以Program/Shader相关资源的恢复为例进行说明：

上述代码可以是构造指令序列的伪代码，其中，每种Object Resource都由很多个Object Resource实例组成，每种Object Resource都维护着一个map，如Program/ShaderObjectResource的map<serverHandle,program>，用于保存该类Object Resource的实例标识和实例本身的映射，对于每个实例在状态机保存动作触发时，都会处于一种确定的状态。

对Program/Shader ObjectResource，遍历ObjectResource<Program/Shader>，无论当前实例所处状态如何，都要将该标识作为参数，构造指令发往端侧，这会触发端侧建立一个端侧资源标识与云侧资源标识的映射map<serverHandle,clientHandle>，他们标识的是同样的数据，在状态机恢复完成后，用于操作端侧资源。

需要说明的是，渲染上下文的重建过程可以是指将云侧保存的渲染上下文中的数据和状态进行拆解后，根据当前每种资源的状态，按照GPU API的标准及一定的规则和顺序，构造出符合GPU pipeline(渲染管线)架构的指令序列发送给端侧的渲染线程(RenderThread)执行图形渲染，这个过程会将指令序列中包含的资源重新加载至端侧的GPU中，相应地，端侧的GPU也会重新生成一个用于操作该资源的标识。渲染上下文重建的过程中会对所有重新加载进端侧的GPU的资源重新标识，若想在重建出的渲染上下文中接着进行图形渲染，就需要“识别”这些“新的”资源，因此需要一个资源映射机制，即云侧的渲染上下文资源标识与渲染端上下文资源标识之间的映射关系。

例如，电子设备可以确定资源映射，即云侧构造的渲染指令中包含资源及该资源的标识号，端侧在恢复时执行该指令，也会在端侧生成一个对该资源的标识，并将其与云侧发送过来的资源标识建立一个映射关系map<serverHandle,clientHandle>。渲染上下文恢复完成，进入正常渲染阶段时，云侧通过其对该资源的标识来操作该资源，端侧则可以通过资源映射后端侧标识代替云侧标识后再进行图形渲染操作，即端侧可以访问云侧任意的数据或状态。

建立端侧和云侧之间资源标识的映射后，可以读取快照资源中该实例所处的状态，因为需要状态机保存操作触发前那一刻的渲染上下文，所以可以根据状态确定不同的指令序列。如当前program实例已经链接过(linked)，就要对挂载点上的shaders实例进行创建、编译、挂载，然后设置少数不会频繁更新的vertex Attribute顶点属性，然后使用该program实例(通过实例标识来使用)，对关键资源中的uniform变量进行设置；而若当前program实例是未链接过，那就只需要将program实例挂载点上的shaders重新挂载即可。上述为举例说明，并不对本申请作任何限定。

需要说明的是，上述以ObjectResource<Program/Shader>进行举例说明，对于其他种类的ObjectResource，均可以采用类似于ObjectResource<Program/Shader>根据状态机保存操作触发前保存的每个实例的状态进行定制化的指令序列构造。

图7是本申请实施例提供的加速恢复渲染上下文的方法的示意性流程图。图7中包括步骤501至512，下面分别对步骤501至511进行详细描述。

需要说明的是，在本申请的实施例中，端侧可以是图1至图4所示的任意一个电子设备，云侧可以是图1、图2以及图3所示的任意一个服务器。

步骤501：资源按需加载模式触发。

需要说明的是，按需加载模式可以在构造指令序列即状态机恢复模块运转初期便生效，云侧可以监测端侧的draw call或关键指令，只加载/恢复当前帧或关键指令的强依赖资源而延后加载其他资源。另外，可以是端侧渲染上下文恢复/重建完成后，继续渲染的同时可以根据按需恢复/资源缓存加速算法运行，云侧可以持续监测draw call或关键指令，持续为后续的当前帧或关键指令的强依赖资源加载服务。

步骤502：获取端侧缓存资源列表。

例如，端侧中可以缓存在状态机中占比较大的纹理资源和顶点资源(75％～99.7％)，将这两部分资源缓存在端侧，当恢复渲染上下文时可以直接从端侧的缓存数据库中读取并加载到端侧的GPU中，可显著降低渲染上下文恢复过程中网络的数据传输量，从而可以降低恢复渲染上下文所需等待的时间。

步骤503：构造指令序列，即上述实施例中的确定指令序列。

例如，渲染上下文的重建过程可以是指将云侧保存的渲染上下文中的数据和状态进行拆解后，根据当前每种资源的状态，按照GPU API的标准及一定的规则和顺序，构造出符合端侧的GPU pipeline(渲染管线)架构的指令序列。

步骤504：渲染上下文恢复主要流程完成。

其中，渲染上下文恢复主要流程完成可以对应于图5所示的步骤305至步骤309。

步骤505：按需加载一直运行，持续监测电子设备的draw call/关键指令。

以OpenGL ES为例，draw call可以包括但不限于以下指令：

glDrawArrays、glDrawElements、glDrawArraysInstanced、glDrawElementsInstanced、glDrawRangeElements、glDrawArraysIndirect、glDrawElementsIndirect。

以OpenGL ES为例，关键指令可以包括但不限于以下指令：

glBindBuffer、glBufferData、glBufferSubData、glBindTexture、glTexImage2D、glTexSubImage2D、glTexImage3D、glTexSubImage3D、glCompressedTexImage2D、glCompressedTexSubImage2D、glCompressedTexImage3D、glCompressedTexSubImage3D。

步骤506：确定获取的渲染指令中是否包含监测的draw call/关键指令。

应理解，根据监测的draw call/关键指令可以确定端侧恢复渲染上下文所需的纹理资源或者顶点资源，而在步骤502中端侧可以将部分纹理资源和顶点资源缓存在端侧。因此，若端侧的渲染指令中包含draw call/关键指令，则执行步骤507；若端侧的渲染指令中不包含draw call/关键指令，则执行步骤508，游戏正常渲染模式运行，其中，游戏正常渲染模式可以是指令拦截，一份发往状态机模块，一份发往端侧与未触发状态机恢复流程前相同。

也就是说，端侧触发了状态机恢复流程后，则云侧可以运行在按需加载模式下，即对draw call和关键指令持续监测，若云侧拦截的渲染指令包含draw call和关键指令，则会触发缓存资源查找，即监测draw call/关键指令指示的资源中的部分或者全部可能存在于电子设备的本地缓存中，因此可以在电子设备的缓存列表中进行查找。反之不会，只会进入游戏正常渲染模式。

步骤507：云侧获取draw call/关键指令指示的所有资源标识。

步骤508：在端侧发送的缓存资源列表中查找资源标识。

例如，缓存资源查找可以是从按需加载模式触发时从端侧获取的其缓存的所有资源列表(资源的sha256sum值与资源的映射)中，查找draw call和关键指令指示的资源，计算出该资源的sha256sum值，作为key去资源列表中查找，如果能在端侧缓存的资源列表中查找成功，说明端侧已经缓存了该资源，云侧直接将该资源的sha256sum值发送给端侧并告知端侧从缓存数据库中加载该资源到GPU中即可。否则，云侧可以通过网络发送该资源到端侧。

步骤509：触发端侧从其本地缓存中加载渲染信息。

步骤510：根据资源标识在获取的状态机快照中获取标识对应的资源。

步骤511：将资源通过网络发送至端侧。

在本申请的实施例中，根据上述按需加载的方式可以加速渲染上下文的恢复速度，即可以根据电子设备中缓存的渲染信息以及根据恢复当前帧图形相关的渲染信息，从而减少活肤渲染上下文所需的等待时间。

应理解，上述举例说明是为了帮助本领域技术人员理解本申请实施例，而非要将本申请实施例限于所例示的具体数值或具体场景。本领域技术人员根据所给出的上述举例说明，显然可以进行各种等价的修改或变化，这样的修改或变化也落入本申请实施例的范围内。

上文结合图1至图7，详细描述了本申请实施例提供的用于图形渲染的方法，下面将结合图8至图，详细描述本申请的装置实施例。应理解，本申请实施例中的图形渲染装置可以执行前述本申请实施例的各种方法，即以下各种产品的具体工作过程，可以参考前述方法实施例中的对应过程。

图8是本申请实施例的图形渲染装置600的示意性框图。应理解，装置600能够执行图4至图7的方法中的各个步骤，为了避免重复，此处不再详述。该图形渲染装置600可以是服务器，或者，图形渲染装置600可以是配置于服务器中的芯片。

在一个示例中，图形渲染装置600包括：处理单元610和收发单元620。其中，处理单元610用于启动应用程序；获取所述应用程序发送的渲染指令；收发单元620用于向所述电子设备发送所述渲染指令，所述渲染指令用于所述电子设备执行图形渲染以显示与所述应用程序相关的图像。

需要说明的是，图8所示的图形渲染装置600可以是图1或者图2所示的服务器，其中，收发单元620可以实现图1或者图2所示的服务器通信接口的相应功能。处理单元可以对应于实现图1所示的拦截机中的相应功能，或者，处理单元610还可以对应于实现图2所示的拦截机、保存模块以及恢复模块所对应的功能；收发单元620可以对应于图1或者图2中实现TCP/代理的功能。

可选地，在一种可能的实现方式中，所述处理单元610还用于：保存图形渲染信息，所述图形渲染信息是所述电子设备用于图形渲染所需的信息。

可选地，在一种可能的实现方式中，所述收发单元620还用于接收所述电子设备发送的第二指令，所述第二指令用于请求恢复与所述服务器的连接；响应于所述第二指令，向所述电子设备发送所述图形渲染信息，所述图形渲染信息用于所述电子设备恢复渲染上下文，所述渲染上下文为接收所述第二指令时所述应用程序的渲染上下文。

可选地，在一种可能的实现方式中，所述图形渲染信息为所述渲染指令。

可选地，在一种可能的实现方式中，所述图形渲染信息为渲染信息集合，所述图形渲染信息为对所述渲染指令进行处理得到的渲染信息集合。

可选地，在一种可能的实现方式中，所述处理单元610还用于：

根据预配置的信息列表和所述渲染指令确定所述渲染信息集合，所述预配置的信息列表包括重传次数小于预定阈值的渲染信息。

可选地，在一种可能的实现方式中，所述处理单元610还用于：

根据渲染顺序对所述渲染信息集合中的渲染信息进行重新排序，所述渲染顺序是指所述电子设备的渲染管线运行图形渲染时渲染信息的顺序；

所述收发单元620具体用于：

向所述电子设备发送重新排序的所述渲染信息集合。

可选地，在一种可能的实现方式中，所述收发单元620还用于：

接收所述电子设备发送的缓存列表，所述缓存列表是所述电子设备缓存的渲染信息的列表；

处理单元610还用于：

根据缓存列表向所述电子设备发送部分或全部所述图形渲染信息，发送的所述图形渲染信息为在所述缓存列表中不存在的图形渲染信息。

可选地，在一种可能的实现方式中，所述处理单元610还用于：

确定指令序列，所述指令序列用于所述电子设备的图形处理器识别所述渲染信息集合；

所述收发单元620具体用于：

向所述电子设备发送所述指令序列和所述渲染信息集合。

在一个示例中，图形渲染装置600包括：处理单元610和收发单元620。其中，收发单元620，用于接收电子设备发送的第四指令，所述第四指令用于指示所述电子设备与服务器断开连接；处理单元610，用于接收所述电子设备发送的第二指令，所述第二指令用于请求恢复所述电子设备与所述服务器的连接；保存图形渲染信息，所述图形渲染信息用于恢复渲染上下文，所述渲染上下文为接收所述第二指令时所述应用程序的渲染上下文；根据所述图形渲染信息进行图形渲染，生成视频流；收发单元620，还用于向所述电子设备发送所述视频流。

需要说明的是，图8所示的图形渲染装置600可以是图1或者图2所示的服务器，其中，收发单元620可以实现服务器通信接口的相应功能。处理单元610可以对应于实现图1所示的拦截机中的相应功能，或者，处理单元610还可以对应于实现图2所示的拦截机、保存模块以及恢复模块所对应的功能；收发单元620可以对应于图1或者图2中实现TCP/代理的功能。

可选地，在一种可能的实现方式中，所述图形渲染信息为所述渲染指令。

可选地，在一种可能的实现方式中，所述图形渲染信息为对所述渲染指令进行处理得到的渲染信息集合。

可选地，在一种可能的实现方式中，所述处理单元610还用于：根据预配置的信息列表和所述渲染指令确定所述渲染信息集合，所述预配置的信息列表包括重传次数小于预定阈值的渲染信息。

可选地，在一种可能的实现方式中，所述处理单元610还用于：确定指令序列，所述指令序列用于所述服务器的图形处理器识别所述渲染信息集合。

应理解，这里的图形渲染装置600以功能单元的形式体现。这里的术语“单元”可以通过软件和/或硬件形式实现，对此不作具体限定。例如，“单元”可以是实现上述功能的软件程序、硬件电路或二者结合。所述硬件电路可能包括应用特有集成电路(applicationspecific integrated circuit，ASIC)、电子电路、用于执行一个或多个软件或固件程序的处理器(例如共享处理器、专有处理器或组处理器等)和存储器、合并逻辑电路和/或其它支持所描述的功能的合适组件。

因此，在本申请的实施例中描述的各示例的单元，能够以电子硬件、或者计算机软件和电子硬件的结合来实现。这些功能究竟以硬件还是软件方式来执行，取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本申请的范围。

图9是本申请实施例的图形渲染装置700的示意性框图。应理解，装置700能够执行图4至图7的方法中的各个步骤，为了避免重复，此处不再详述。该图形渲染装置700可以是电子设备，或者，图形渲染装置700可以是配置于电子设备中的芯片。图形渲染装置700包括：收发单元710和处理单元720。其中，收发单元710，用于接收所述服务器发送的渲染指令，所述渲染指令用于电子设备进行图形渲染；处理单元7720，用于根据所述渲染指令进行图形渲染。

可选地，在一种可能的实现方式中，收发单元710还用于向服务器发送第二指令，所述第二指令用于请求恢复所述电子设备与所述服务器的连接；接收所述服务器发送的图形渲染信息；处理单元720还用于根据所述图形渲染信息恢复渲染上下文，所述渲染上下文为发送所述第二指令时所述应用程序的渲染上下文。

可选地，在一种可能的实现方式中，所述图形渲染信息为所述渲染指令。

可选地，在一种可能的实现方式中，所述图形渲染信息所述图形渲染信息为对所述渲染指令进行处理得到的渲染信息集合。

可选地，在一种可能的实现方式中，所述处理单元720，还用于确定指令序列，所述指令序列用于所述电子设备的图形处理器识别所述渲染信息集合。

可选地，在一种可能的实现方式中，所述渲染信息集合中包括第一标识信息和第一渲染信息，所述第一标识信息为所述服务器用于标识所述第一渲染信息的标识信息，所述处理单元720，还用于确定映射关系，所述映射关系是所述第一标识信息和所述第二标识信息的对应关系，所述第二标识信息为所述电子设备用于标识所述第一渲染信息的标识信息。

应理解，这里的图形渲染装置700以功能单元的形式体现。这里的术语“单元”可以通过软件和/或硬件形式实现，对此不作具体限定。例如，“单元”可以是实现上述功能的软件程序、硬件电路或二者结合。所述硬件电路可能包括应用特有集成电路(applicationspecific integrated circuit，ASIC)、电子电路、用于执行一个或多个软件或固件程序的处理器(例如共享处理器、专有处理器或组处理器等)和存储器、合并逻辑电路和/或其它支持所描述的功能的合适组件。

因此，在本申请的实施例中描述的各示例的单元，能够以电子硬件、或者计算机软件和电子硬件的结合来实现。这些功能究竟以硬件还是软件方式来执行，取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本申请的范围。

图10示出了本申请一个实施例提供的服务器800的示意性框图。该服务器800包括处理器820、存储器860、通信接口840和总线850。其中，处理器820、存储器860、通信接口840通过总线850进行通信，也可以通过无线传输等其他手段实现通信。该存储器860用于存储指令，该处理器820用于执行该存储器860存储的指令。该存储器860存储程序代码811，且处理器820可以调用存储器860中存储的程序代码811执行图4至图7所示的用于图形渲染的方法。

例如，处理器820可以用于执行上述图4中的220中获取应用程序发送的渲染指令；或者，可以执行图6所示的确定状态机快照的流程。

该存储器860可以包括只读存储器和随机存取存储器，并向处理器820提供指令和数据。存储器860还可以包括非易失性随机存取存储器。该存储器860可以是易失性存储器或非易失性存储器，或可包括易失性和非易失性存储器两者。其中，非易失性存储器可以是只读存储器(read-only memory，ROM)、可编程只读存储器(programmable ROM，PROM)、可擦除可编程只读存储器(erasable PROM，EPROM)、电可擦除可编程只读存储器(electricallyEPROM，EEPROM)或闪存。易失性存储器可以是随机存取存储器(random access memory，RAM)，其用作外部高速缓存。通过示例性但不是限制性说明，许多形式的RAM可用，例如静态随机存取存储器(static RAM，SRAM)、动态随机存取存储器(DRAM)、同步动态随机存取存储器(synchronous DRAM，SDRAM)、双倍数据速率同步动态随机存取存储器(double datadate SDRAM，DDR SDRAM)、增强型同步动态随机存取存储器(enhanced SDRAM，ESDRAM)、同步连接动态随机存取存储器(synchlink DRAM，SLDRAM)和直接内存总线随机存取存储器(direct rambus RAM，DR RAM)。

该总线850除包括数据总线之外，还可以包括电源总线、控制总线和状态信号总线等。但是为了清楚说明起见，在图8中将各种总线都标为总线850。

如图10所示的服务器800，其中，处理器820可以执行图8所示的处理单元610对应的步骤/功能，通信接口840可以执行图8所示的收发单元620对应的步骤/功能。

应理解，图10所示的服务器800能够实现图4至图7所示方法实施例中设备执行的各个过程。服务器800中的各个模块的操作和/或功能，分别为了实现上述方法实施例中设备的相应流程。具体可参见上述方法实施例中的描述，为避免重复，此处适当省略详细描述。

图11是本申请实施例的电子设备900的结构示意图。该电子设备900可以但不限于是膝上型计算机、台式计算机、移动电话、智能手机、平板电脑、多媒体播放器、电子阅读器、智能车载设备、智能家电、人工智能设备、穿戴式设备、物联网设备、或虚拟现实/增强现实/混合现实设备等。

应理解，上文中图9所示的装置700的具体结构可以如图11所示。

图11中的电子设备900包括通信模块910、传感器920、用户输入模块930、输出模块940、处理器950、存储器970以及电源980。其中，处理器950可以包括一个或者多个CPU。

图11所示的电子设备可以执行本申请实施例的用于图形渲染方法的各个步骤，具体地，处理器950中的一个或者多个CPU可以执行本申请实施例的同于图形渲染方法的各个步骤。

下面对图11中的电子设备900的各个模块进行详细的介绍。应理解的是，图11所示的模块仅是举例说明，具体实现中电子设备900可以包含更多或更少的模块。

通信模块910可以包括至少一个能使该电子设备与其他电子设备之间进行通信的模块。例如，通信模块910可以包括有线网络接口、广播接收模块、移动通信模块、无线因特网模块、局域通信模块和位置(或定位)信息模块等其中的一个或多个。本实施例不限定通信代别，例如可以是2G、3G、4G、5G或随着技术发展出现的其它通信代别。

例如，通信模块910能够从游戏服务器端实时获取用于渲染游戏画面所需的渲染指令。

传感器920可以感知用户的一些操作，传感器920可以包括距离传感器，触摸传感器等等。传感器920可以感知用户触摸屏幕或者靠近屏幕等操作。

例如，传感器920能够感知用户在游戏界面的一些操作。

用户输入模块930，用于接收输入的数字信息、字符信息或接触式触摸操作/非接触式手势，以及接收与系统的用户设置以及功能控制有关的信号输入等。用户输入模块930包括触控面板和/或其他输入设备。例如，用户可以通过用户输入模块3030对游戏进行控制。

输出模块940包括显示面板，用于显示由用户输入的信息、提供给用户的信息或系统的各种菜单界面等。

可选的，可以采用液晶显示器(liquid crystal display，LCD)或有机发光二极管(organic light-emitting diode,OLED)等形式来配置显示面板。在其他一些实施例中，触控面板可覆盖显示面板上，形成触摸显示屏。

另外，输出模块940还可以包括视频输出模块、告警器以及触觉模块等。该视频输出模块可以显示图形渲染后的游戏画面。

电源980可以在处理器950的控制下接收外部电力和内部电力，并且提供整个电子设备各个模块运行时需要的电力。

处理器950可以包括一个或者多个CPU，处理器950还可以包括一个或者多个GPU。

当处理器950包括多个CPU时，该多个CPU可以集成在同一块芯片上，也可以分别集成在不同的芯片上。

当处理器950包括多个GPU时，该多个GPU既可以集成在同一块芯片上，也可以分别集成在不同的芯片上。

当处理器950既包括CPU又包括GPU时，CPU和GPU可以集成在同一块芯片上。

例如，当图11所示的电子设备为智能手机时，智能手机的处理器内部一般与图像处理相关的是一个CPU和一个GPU。这里的CPU和GPU均可以包含多个核。

存储器970可以存储计算机程序，该计算机程序包括操作系统程序972和应用程序971等。其中，典型的操作系统如微软公司的Windows，苹果公司的MacOS等用于台式机或笔记本的系统，又如谷歌公司开发的基于

的安卓

系统等用于移动终端的系统。

存储器970可以是以下类型中的一种或多种：闪速(flash)存储器、硬盘类型存储器、微型多媒体卡型存储器、卡式存储器(例如SD或XD存储器)、随机存取存储器(randomaccess memory,RAM)、静态随机存取存储器(static RAM,SRAM)、只读存储器(read onlymemory,ROM)、电可擦除可编程只读存储器(electrically erasable programmable read-only memory，EEPROM)、可编程只读存储器(programmable ROM,PROM)、磁存储器、磁盘或光盘。在其他一些实施例中，存储器970也可以是因特网上的网络存储设备，系统可以对在因特网上的存储器970执行更新或读取等操作。

例如，上述存储器970可以存储一种计算机程序(该计算机程序是本申请实施例的用于图形渲染方法对应的程序)，当处理器950执行该计算机程序时，处理器950能够执行本申请实施例的用于图形渲染的方法。

存储器970还存储有除计算机程序之外的其他数据973，例如，存储器970可以存储本申请的图形渲染方法处理过程中的数据。

图11中各个模块的连接关系仅为一种示例，本申请任意实施例提供的电子设备也可以应用在其它连接方式的电子设备中，例如所有模块通过总线连接。

本领域普通技术人员可以意识到，结合本文中所公开的实施例描述的各示例的单元及算法步骤，能够以电子硬件、或者计算机软件和电子硬件的结合来实现。这些功能究竟以硬件还是软件方式来执行，取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本申请的范围。

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

应理解，在本申请实施例中，术语“第一”、“第二”、“第三”等仅仅是为了指代对象，并不表示相应对象间的先后次序。

应理解，在本申请实施例中，术语“和/或”仅仅是一种描述关联对象的关联关系，表示可以存在三种关系。例如，A和/或B，可以表示：单独存在A，同时存在A和B，单独存在B这三种情况。另外，本文中字符“/”，一般表示前后关联对象是一种“或”的关系。

本领域普通技术人员可以意识到，结合本文中所公开的实施例描述的各示例的单元及算法步骤，能够以电子硬件、或者计算机软件和电子硬件的结合来实现。这些功能究竟以硬件还是软件方式来执行，取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本申请的范围。

所属领域的技术人员可以清楚地了解到，为描述的方便和简洁，上述描述的系统、装置和单元的具体工作过程，可以参考前述方法实施例中的对应过程，在此不再赘述。

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

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

另外，在本申请各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。

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

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

Claims (23)

1.一种用于图形渲染的方法，其特征在于，包括：

启动应用程序；

获取所述应用程序发送的渲染指令；

向所述电子设备发送所述渲染指令，所述渲染指令用于所述电子设备执行图形渲染以显示与所述应用程序相关的图像。

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

保存图形渲染信息，所述图形渲染信息是所述电子设备用于图形渲染所需的信息。

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

接收所述电子设备发送的第二指令，所述第二指令用于请求恢复与所述服务器的连接；

响应于所述第二指令，向所述电子设备发送所述图形渲染信息，所述图形渲染信息用于所述电子设备恢复渲染上下文，所述渲染上下文为接收所述第二指令时所述应用程序的渲染上下文。

4.如权利要求2或3所述的方法，其特征在于，所述图形渲染信息为所述渲染指令。

5.如权利要求2或3所述的方法，其特征在于，所述图形渲染信息为对所述渲染指令进行处理得到的渲染信息集合。

6.如权利要求5所述的方法，其特征在于，所述方法还包括：

根据预配置的信息列表和所述渲染指令确定所述渲染信息集合，所述预配置的信息列表包括重传次数小于预定阈值的渲染信息。

7.如权利要求5或6所述的方法，其特征在于，所述方法还包括：

根据渲染顺序对所述渲染信息集合中的渲染信息进行重新排序，所述渲染顺序是指所述电子设备的渲染管线运行图形渲染时渲染信息的顺序；

向所述电子设备发所述图形渲染信息，包括：

向所述电子设备发送重新排序的所述渲染信息集合。

8.如权利要求3至7中任一项所述的方法，其特征在于，所述方法还包括：

接收所述电子设备发送的缓存列表，所述缓存列表为所述电子设备缓存的渲染信息的列表；

向所述电子设备发送所述图形渲染信息，包括：

根据所述缓存列表向所述电子设备发送部分或全部所述图形渲染信息，发送的所述图形渲染信息为在所述缓存列表中不存在的图形渲染信息。

9.根据权利要求5至7中任一项所述的方法，其特征在于，向所述电子设备发送所述图形渲染信息，包括：

确定指令序列，所述指令序列用于所述电子设备的图形处理器识别所述渲染信息集合；

向所述电子设备发送所述指令序列和所述渲染信息集合。

10.一种用于图形渲染的方法，其特征在于，包括：

接收服务器发送的渲染指令，所述渲染指令用于电子设备进行图形渲染；

根据所述渲染指令进行图形渲染显示与所述应用程序相关的图像。

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

向服务器发送第二指令，所述第二指令用于请求恢复所述电子设备与所述服务器的连接；

接收所述服务器发送的图形渲染信息；

根据所述图形渲染信息恢复渲染上下文，所述渲染上下文为发送所述第二指令时所述应用程序的渲染上下文。

12.如权利要求10或11所述的方法，其特征在于，所述图形渲染信息为所述渲染指令。

13.如权利要求10或11所述的方法，其特征在于，所述图形渲染信息所述图形渲染信息为对所述渲染指令进行处理得到的渲染信息集合。

14.如权利要求13所述的方法，其特征在于，所述方法还包括：

确定指令序列，所述指令序列用于所述电子设备的图形处理器识别所述渲染信息集合。

15.如权利要求13或14所述的方法，其特征在于，所述渲染信息集合中包括第一标识信息和第一渲染信息，所述第一标识信息为所述服务器用于标识所述第一渲染信息的标识信息，所述方法还包括：

确定映射关系，所述映射关系是所述第一标识信息和所述第二标识信息的对应关系，所述第二标识信息为所述电子设备用于标识所述第一渲染信息的标识信息。

16.一种用于图形渲染的方法，其特征在于，包括：

接收电子设备发送的第四指令，所述第四指令用于指示所述电子设备与服务器断开连接；

获取所述应用程序发送的渲染指令，所述渲染指令用于所述服务器进行图形渲染；

接收所述电子设备发送的第二指令，所述第二指令用于请求恢复所述电子设备与所述服务器的连接；

保存图形渲染信息，所述图形渲染信息用于恢复渲染上下文，所述渲染上下文为接收所述第二指令时所述应用程序的渲染上下文；

根据所述图形渲染信息进行图形渲染，生成视频流；

向所述电子设备发送所述视频流。

17.如权利要求16所述的方法，其特征在于，所述图形渲染信息为所述渲染指令。

18.如权利要求16所述的方法，其特征在于，所述图形渲染信息为对所述渲染指令进行处理得到的渲染信息集合。

19.如权利要求18所述的方法，其特征在于，所述方法还包括：

根据预配置的信息列表和所述渲染指令确定所述渲染信息集合，所述预配置的信息列表包括重传次数小于预定阈值的渲染信息。

20.根据权利要求18或19所述的方法，其特征在于，所述方法还包括：

确定指令序列，所述指令序列用于所述服务器的图形处理器识别所述渲染信息集合。

21.一种图形渲染装置，其特征在于，包括存储器和处理器，所述存储器用于存储计算机程序，所述处理器用于从所述存储器中调用并运行所述计算机程序，以执行如权利要求1至9中任一项所述的方法。

22.一种图形渲染装置，其特征在于，包括存储器和处理器，所述存储器用于存储计算机程序，所述处理器用于从所述存储器中调用并运行所述计算机程序，以执行如权利要求10至15中任一项所述的方法。

23.一种图形渲染装置，其特征在于，包括存储器和处理器，所述存储器用于存储计算机程序，所述处理器用于从所述存储器中调用并运行所述计算机程序，以执行如权利要求16至20中任一项所述的方法。

Images