本发明涉及数据处理技术领域，具体涉及一种数据处理方法、装置、存储介质及计算机设备。
背景技术：
目前，市面上存在为用户的生活、工作及娱乐等方面，提供各种便利服务的应用程序，用户可以直接从应用商店查询并下载应用程序，也可以通过浏览器登录网页应用程序，使用应用程序提供的便利服务，非常方便。其中，网页应用程序是指以云计算机为基础的在线应用程序，不需要下载安装，直接借助云端服务器运行，避免了在终端设备运行网页应用程序，对终端设备空间资源的占用，提高了运行流畅性及可靠性。
以游戏场景为例，随着云游戏技术的普及，越来越多的游戏玩家选择云游戏，相对于传统的单机游戏和网络游戏，在云游戏的运行模式下，所有游戏不在玩家的终端设备运行，而是在云端服务器运行，玩家通过浏览器体验各式各样的游戏，非常方便，且用户还能够在不同终端设备得到一样的游戏体验。
在游戏的实际应用中，是通过流式数据在服务端和客户端之间传输，保证云游戏的正常运行，具体由游戏服务器将渲染指令数据压缩成一个压缩文件，再将压缩文件通过网络发送给客户端。然而，服务端与客户端之间传输的流式数据往往会包括多种类型数据，现有这种直接压缩后传输的方式，数据压缩效率往往比较低，且消耗的网络流量也比较大，甚至会影响游戏的运行流畅性。
技术实现要素：
有鉴于此，本发明实施例提供一种数据处理方法、装置、存储介质及计算机设备，通过对截获的渲染指令数据进行分组，并在多层数据处理通道，单独对分组后的数据进行数据压缩处理，将得到的多个压缩文件发送至客户端，提高了数据压缩效率，降低了传输数据消耗的网络流量。
为实现上述目的，本发明实施例提供如下技术方案：
本发明实施例提供了一种数据处理方法，所述方法包括：
截获应用进程运行期间调用的渲染指令数据；
对所述渲染指令数据进行分组，得到多个待压缩数据组，一个待压缩数据组包括所述渲染指令数据包含的至少一类数据；
使用多层数据处理通道，对相应待压缩数据组包含的数据进行压缩处理，得到多个压缩文件；
将所述多个压缩文件发送至客户端。
本发明实施例还提供了另一种数据处理方法，所述方法包括：
接收应用服务器发送的多个压缩文件，所述多个压缩文件是由应用进程运行期间调用的渲染指令数据分组并压缩处理后得到的；
对所述多个压缩文件进行解压处理，得到多个解压数据组，一个解压数据组包括所述渲染指令数据包含的至少一类数据；
对所述多个解压数据组包含的数据进行组合，得到所述渲染指令数据；
利用所述渲染指令数据，渲染相应的应用图形界面。
本发明实施例还提供了一种数据处理装置，所述装置包括：
截获模块，用于截获应用进程运行期间调用的渲染指令数据；
分组模块，用于对所述渲染指令数据进行分组，得到多个待压缩数据组，一个待压缩数据组包括所述渲染指令数据包含的至少一类数据；
数据压缩模块，用于使用多层数据处理通道，对相应待压缩数据组包含的数据进行压缩处理，得到多个压缩文件；
数据发送模块，用于将所述多个压缩文件发送至客户端。
本发明实施例提供了另一种数据处理装置，所述装置包括
压缩文件接收模块，用于接收应用服务器发送的多个压缩文件，所述多个压缩文件是由应用进程运行期间调用的渲染指令数据分组并压缩处理后得到的；
数据解压模块，用于对所述多个压缩文件进行解压处理，得到多个解压数据组，一个解压数据组包括所述渲染指令数据包含的至少一类数据；
数据组合模块，用于对所述多个解压数据组包含的数据进行组合，得到所述渲染指令数据；
渲染模块，用于利用所述渲染指令数据，渲染相应的应用图形界面。
本发明实施例还提供了一种存储介质，其上存储有计算机程序，其特征在于，所述计算机程序被处理器执行时，实现如上所述的数据处理方法的各个步骤。
本发明实施例还提供了一种计算机设备，所述计算机设备包括：
通信接口；
存储器，用于存储实现如上所述的数据处理方法的程序；
处理器，用于加载并执行实现以下步骤的程序：
截获应用进程运行期间调用的渲染指令数据；
对所述渲染指令数据进行分组，得到多个待压缩数据组，一个待压缩数据组包括所述渲染指令数据包含的至少一类数据；
使用多层数据处理通道，对相应待压缩数据组包含的数据进行压缩处理，得到多个压缩文件；
将所述多个压缩文件发送至客户端。
基于上述技术方案，本实施例提供的数据处理方法、装置、存储介质及计算机设备，在截获应用进程运行期间调用的渲染指令数据后，应用服务器并未直接对其进行压缩处理，而是对其进行分组，得到多个待压缩数据组，使用多层数据处理通道，对相应待压缩数据组包含的数据进行压缩，得到多个压缩文件，再通过网络发送至用户侧的客户端，以使客户端渲染相应应用图形界面。可见，本实施例这种对数据分组压缩处理方式，与现有技术直接对截获的所有渲染指令数据进行压缩的方式相比，提高了数据压缩效率，且降低了传输压缩数据所需的网络流量，保证了应用运行的流畅性。
附图说明
为了更清楚地说明本发明实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本发明的实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据提供的附图获得其他的附图。
图1为本发明实施例提供的实现数据处理方法的系统结构图；
图2为本发明实施例提供的一种数据处理方法的流程示意图；
图3为本发明实施例提供的另一种数据处理方法的流程示意图；
图4为本发明实施例提供的一种数据处理方法的应用场景的流程示意图；
图5为本发明实施例提供的另一种数据处理方法的流程示意图；
图6为本发明实施例提供的又一种数据处理方法的流程示意图；
图7a为本发明实施例提供的一种各指令数据的数据量图表；
图7b为本发明实施例提供的一种各指令数据对应的压缩文件的数据量图表；
图8为本发明实施例提供的又一种数据处理方法的流程示意图；
图9为本发明实施例提供的一种指令数据的分组压缩处理方法的流程示意图；
图10为本发明实施例提供的又一种数据处理方法的流程示意图；
图11为本发明实施例提供的另一种数据处理方法的时序示意图；
图12为本发明实施例提供的一种数据处理装置的结构示意图；
图13为本发明实施例提供的另一种数据处理装置的结构示意图；
图14为本发明实施例提供的另一种数据处理装置的结构示意图；
图15为本发明实施例提供的又一种数据处理装置的结构示意图；
图16为本发明实施例提供的一种计算机设备的硬件结构示意图。
具体实施方式
本发明的发明人研究发现：对于如云游戏这种以云计算为基础的在线应用程序，是由于在运行模式下，应用服务器直接对截获的渲染指令数据，采用统一数据压缩算法进行处理，将得到一个压缩文件传输给用户侧客户端。其中，渲染指令数据除了指令编码、参数，通常还会包括变换矩阵数据、纹理数据、顶点数据、索引数据等多种类型的数据，而这些数据之间的差异往往比较明显，而现有数据处理方法并未考虑该渲染指令数据的具体数据组成、各类数据之间的差异，直接对差异明显的多种数据进行压缩，导致压缩效率很低，还降低了数据压缩算法性能。
基于上述分析，发明人提出对渲染指令数据包含的各类数据进行分组，将相同类型或相似数据作为一个待压缩数据组，单独对其进行压缩，以达到提高压缩效率和算法性能的目的。
下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。
图1示出了实现本实施例提供的数据处理方法的系统结构图，该系统可以包括：应用服务器10及客户端20，其中：
应用服务器10可以是运行的云服务器上的应用客户端，由于本实施例提供的数据处理方法可以适用于基于云计算的应用场景，将由应用服务器执行应用的主要逻辑运行，将与用户交互有关的应用图形界面，经过网络传送给用户侧的客户端输出。
以游戏为例，该应用服务器10具体可以是运行在云游戏服务器上的游戏客户端，即云游戏的云端，用户玩该游戏时，游戏的主要逻辑是在云端的游戏客户端上运行，不需要在本地下载游戏程序，本实施例对云游戏的应用场景不再详述。
客户端20可以运行在用户侧，即应用的用户端，其可以运行在用户侧的终端设备、个人电脑、电视机顶盒等设备上，用来输出应用图形界面，并将用户通过如鼠标、键盘等输入设备输入的操作指令，通过网络发送至云端的相应应用服务器20。
仍以游戏为例，用户无需在终端设备下载、安装大容量的游戏程序，免除了软件系统和设备性能升级限制等问题，只需要足够的带宽及一台具有视频流解码能力的设备，就能够体验不同平台下的游戏，用户能够直接使用上述终端设备，进入游戏平台，选择要玩的游戏图标，输入游戏登录账号，即可与服务侧的游戏服务器(如上述应用服务器10，也可以称为游戏客户端)建立通信连接，以获取游戏服务器传输的渲染指令数据，来渲染游戏图形界面，并显示在用户面前，以便用户继续后续操作。
其中，在游戏场景下，上述系统还可以包括会话服务器30和多媒体服务器40和，会话服务器可以负责管理与客户端之间的连接，在应用服务器运行相关的游戏过程中，多媒体服务器可以用来存储模型、视频及音频等多媒体数据，且游戏相关的数据通常以流的形式，通过网络传输到客户端。当然，在其他应用的应用场景下，也可以包括上述会话服务器30和多媒体服务器40，但并不局限于此，本实施例在此不再详述。
参照图1，本实施例提出了数据处理方法，如图2所示的该数据处理方法的一种流程图，该方法可以应用上文描述的系统，主要从云端的应用服务器的角度进行描述，具体可以包括以下步骤：
步骤S101，截获应用进程运行期间调用的渲染指令数据；
以应用为云游戏为例进行说明，用户使用终端设备(如手机、平板电脑等)、电视机等，进入应用平台，并启动该应用平台上的某游戏后，该游戏对应的应用服务器将会创建相应的游戏进程运行该游戏，以使得用户能够操作该游戏。
在本实施例中，采用基于图形流的数据传输系统，保证用户正常使用应用及更新应用界面的实时性，即将应用运行产生的渲染指令迁移到客户端执行，无需传输大量视频流数据，提高用户使用应用的实时性。在该数据传输系统下，支持应用环境的图形库可以位于用户侧的客户端中，为了可靠实现对图形库中所需渲染数据的调用，在应用进程运行应用过程中，可以监听其对渲染指令的调用，并监听到该调用事件时，及时截获该渲染指令对应的渲染指令数据。
其中，渲染指令数据可以包括如指令编码、参数等指令类数据，如纹理数据、模型数据(如顶点数据；声音数据；人物、背景、地形等可视对象的相关数据)等资源类数据。在实际应用中，模型数据中的顶点数据可以是一系列三维点及点与点之间的邻接关系组成得到，但并不局限于此；纹理数据可以包括场景中的背景及人物等模型的贴图，本实施例对图形流数据包含的数据类型及内容不做限定。
在用户对应用实际操作过程中，随着用户输入操作的改变，应用进程产生的渲染指令数据可以相应变化，具体可以是渲染指令数据的全部内容都相应改变，也可以是渲染指令数据中的部分数据随着时间的变化而不断改变，本实施例对不同时刻截获的渲染指令数据的变化情况不作限定。
需要说明，本实施例截获的渲染指令数据可以是一帧数据，也就是说，本实施例可以截获应用服务器调用的每个单帧数据，具体可以采用Hook技术实现数据拦截，即利用注入的Hook函数，拦截应用服务器调用的渲染指令数据，使得应用服务器不能执行该渲染指令数据，实现当前应用界面的数据渲染，但并不局限于这种截获手段。
步骤S102，对渲染指令数据进行分组，得到多个待压缩数据组；
如上述分析，本实施例截获的渲染指令数据可以包括指令类数据及资源类数据，这两类数据的内容并不相同，可以按照能够区别这两类数据的内容，对渲染指令数据进行分类分组，以使得到的每一个待压缩数据组均包括渲染指令数据包含的至少一类数据。
基于此，本实施例可以提取渲染指令数据包含的资源数据及指令数据，之后，分别对资源数据和指令数据的内容进行分组，由对资源数据的分组，得到至少一个第一待压缩数据组；由对指令数据的分组，得到至少一个第二待压缩数据组，本实施例对这两类数据的分组方式不作限定，可以参照但并不局限于下文相应实施例的描述。
步骤S103，使用多层数据处理通道，对相应待压缩数据组包含的数据进行压缩，得到多个压缩文件；
可选的，本实施例在首次对截获的渲染指令数据进行分组，得到多个待压缩数据组后，可以针对每一个待压缩数据组，创建一线程，作为该待压缩数据组的数据处理通道，用来对该待压缩数据组包含的数据进行压缩，待该应用进程结束运行时，再删除这些数据处理通道，不需要每次分组都创建，当然，在每次截获渲染指令数据分组后，可以根据实际分组情况，来调整数据处理通道的数量，如删除多余的数据处理通道，若此处存在的数据处理通道不够，也可以创建相应数量的新的数据处理通道等等。本实施例对创建线程的具体实现过程不作详述，且各数据处理通道的创建方式并不局限于这种线程创建方式。
而且，在本实施例实际应用中，使用数据处理通道对数据进行压缩过程中，本实施例对这多层数据处理通道对数据的具体压缩处理过程不做限定，可以依次触发各层数据处理通道对相应待压缩数据组包含的数据进行压缩，也可以在时间上叠加触发各层数据处理通道对相应待压缩数据组包含的数据进行压缩，比如经过一定时间间隔后，触发下一层数据处理通道对相应待压缩数据组包含的数据进行压缩等等，甚至还可以触发各层数据处理通道，同时对相应待压缩数据组包含的数据进行压缩，即并行进行数据压缩等等，相对于与传统方法对截获的所有数据进行统一压缩，这几种处理方式都提高了整体数据压缩效率。
其中，对于各层数据处理通道对数据的压缩处理过程，可以采用不同的数据压缩方式，实现对相应待压缩数据组包含的数据进行压缩，即在多线程并行处理过程中，可以基于实际处理的数据特点，选用合适的数据压缩方式进行数据压缩处理，这相对于与传统方法及上述其他可选处理方式，能够更大程度地提高数据压缩效率。
尤其是在应用服务器包含多核处理器的情况下，能够充分利用多核处理器的优势，由多个处理器并行对各层数据处理通道中的数据进行压缩处理，不仅提高了数据压缩效率，且创建一个数据处理通道的传统压缩处理方式相比，提高了多核处理器的数据处理性能。
需要说明，在多核处理器的数据处理方案中，并不局限于对多层数据处理通道对应数据进行并行处理，也可以利用多核处理器，按照上文描述的其他方式进行处理，在此不再一一详述。
在本实施例中，可以对各层数据处理通道的数据进行压缩处理，具体可以采用数据压缩算法实现，不同数据压缩算法对应的数据压缩方式往往是不同的。在实际应用中，数据压缩算法可以分为有损压缩和无损压缩两大类，有损压缩主要是一些量化算法，为了保证客户端呈现应用场景的可靠性及清晰度等，本实施例通常可以选择无损压缩算法，其主要是一些编码算法，如子带编码、差分编码、哈夫曼编码等压缩算法等等压缩方式，实现对数据的压缩处理，本实施例对各层数据处理通道采用的数据压缩方式不做限定。
可选的，本实施例也可以按照通用数据压缩方式，使用各层数据处理通道，对相应待压缩数据组包含的数据进行压缩，但对该通用数据压缩方式的获取方式及包含的内容不做限定。
进一步地，为了提高数据压缩效率和算法性能，本实施例也可以针对各待压缩数据组，设置专用数据压缩方式进行数据压缩，相对于上述可选实施例采用通用待压缩数据的数据压缩方式，进一步提高了数据压缩效率及算法性能。
以游戏应用为例，对于渲染游戏场景得到的骨骼动画类、粒子特效类等渲染指令数据，可以针对不同类型数据的特显，分别设置专用数据压缩算法进行压缩处理。本实施例对如何确定各类型数据的专用数据压缩算法的方法，及各专用数据压缩算法的内容不作限定。
步骤S104，将多个压缩文件发送至客户端。
通常情况下，应用服务器与客户端之间的数据传输，可以是通过TCP(Transmission Control Protocol 传输控制协议)协议进行的socket(即网络通信连接的端口号，通常实现的是双向数据通信)通信传输，但并不局限于此。
本实施例实际应用中，该客户端可以是运行在用户侧的客户端，即应用的用户端，用来展示相应应用图形界面。对于多层数据处理通道输出的多个压缩文件，本实施例可以将这多个压缩文件合并，得到待发送数据，之后，通过应用进程使用的通信网络，将待发送数据发送至用户侧的客户端，以完成相应应用图形界面的渲染，保证应用操作与显示的实时性。
可选的，客户端接收到多个压缩文件后，可以按照上述压缩处理的逆向处理方法，先对压缩文件进行解压处理，再将解压得到的多组数据进行组合，获取渲染指令数据，此时，可以利用渲染指令数据，渲染相应的应用图形界面，以使用户侧客户端输出该应用图形界面，方便用户据此进行后续操作，本实施例对客户端接收到压缩文件后的处理过程不作限定。
综上所述，参照图3所示的应用场景流程示意图，在截获应用进程运行期间调用的渲染指令数据后，应用服务器并未直接对其进行压缩处理，而是对其进行分组，得到多个待压缩数据组，从而使用多层数据处理通道，对相应待压缩数据组包含的数据进行压缩处理，得到多个压缩文件，再通过网络发送至用户侧的客户端，以使客户端渲染相应应用图形界面。可见，本实施例这种数据处理方式，与现有技术使用一个数据处理通道，对截获的所有渲染指令数据进行压缩处理的方式相比，提高了数据压缩效率，且降低了传输压缩数据所需的网络流量。
为了进一步提高数据压缩效率，本申请提供了一可选实施例，如图3所示的流程示意图，该方法仍然从应用服务器角度进行描述，具体可以包括以下步骤：
步骤S201，截获应用进程运行期间调用的渲染指令数据；
在实际应用中，可以通过调用API(Application Programming Interface，应用程序编程接口)的方式，获取图形库中图形信息，来进行应用图形界面的渲染，因此，本实施例可以通过监听应用服务器的应用进程对API的调用，及时截获调用API对应的渲染指令数据，即在应用进程运行期间调用渲染指令(如通过调用API实现)时，及时截获该渲染指令对应的渲染指令数据，本实施例对该渲染指令数据包含的内容及其拦截方式不作限定。
可选的，若应用进程通过API方式，来调用渲染指令数据，那么，本实施例可以采用API Hook技术实现步骤S201，即通过API Hook，改变API的原有功能，如修改API函数的入口点，该改变它的地址指向新的自定义的函数，基于此，在本实施例中，通过截获渲染指令数据，经压缩发送至用户侧客户端，由客户端代替应用服务器实现数据渲染，输出应用图形界面，具体实现过程本实施例不作详述。
步骤S202，对该渲染指令数据进行相似性分组，得到多个待压缩数据组；
其中，每一待压缩数据组包含的待压缩数据的相似度大于第一阈值，也就是说，在本实施例实际应用中，可以通过计算各个渲染指令数据之间的相似度，将相似度小于第一阈值的渲染指令数据作为一组，从而得到多个待压缩数据组，但并不局限于这种实现方法，且本实施例对第一阈值的数值不作限定，通常不会很大。
在本实施例中，截获的渲染指令数据可以是单帧数据，具体可以包括各种指令数据及资源数据，本实施例可以利用相似度性算法(如距离度量方法、相似度度量方法等)，实现对截获的渲染指令数据的分类分组，本实施例在此不再一一详述。
可选的，本实施例也可以截获多帧渲染指令数据后，按照上述方式对每一帧渲染指令数据进行分组处理，再将相应待压缩数据组进行合并，之后，再进行后续压缩处理，并局限于单帧渲染指令数据的压缩处理，由于多帧渲染指令数据的分组与压缩过程，与单帧渲染指令数据的分组与压缩过程类似，本实施例不再对多帧渲染指令数据的分组与压缩过程进行赘述。
步骤S203，获取各待压缩数据组包含的数据对应的数据压缩方式；
可选的，本实施例各层数据处理通道处理的数据特征往往不同，因此，可以在首次对渲染指令数据分组并创建多层数据处理通道时，基于需要处理的数据的特征，来区分各层数据处理通道，比如设置各层数据处理通道的标识等，由该标识区别各层数据处理通道，本实施例对该标识的内容不作限定。
在创建多层数据处理通道之后，本实施例可以针对各层数据处理通道对应组的数据内容，确定各层数据处理通道进行数据压缩所使用的数据压缩方式，即设定各层数据处理通道对应的专用数据压缩方式，对接收到的数据进行数据压缩处理，以提高数据压缩效率及算法性能。基于此，本实施例可以通过对各待压缩数据组包含的数据进行特征分析，基于分析结果，获取各待压缩数据组对应的数据压缩方式，并将各数据压缩方式与相应层数据处理通道关联，这样，在后续得到多个待压缩数据组后，使用数据处理通道进行处理时，可以直接采用该数据处理通道关联的数据压缩方式，对相应数据进行压缩处理，具体实现方式不做限定。
需要说明，针对各层数据处理通道设置的数据压缩方式，可以完全不同，也可以部分相同，具体可以根据相应待压缩数据组包含的数据的特征分析结果确定，本实施例不做一一详述。
当然，本实施例对各组数据进行压缩处理，也可以采用通用数据压缩方式实现，并不局限于上文描述的专用数据压缩方式，该通用数据压缩方式通常是对单帧渲染指令数据确定的，可以基于关键帧和帧间差异分析确定，本实施例在此不作详述。作为本申请另一可选实施例，上述多层数据处理通道可以是在首次对渲染指令数据分组后构建，也可以是在应用进程初始化时，通过对该应用进程可能会调用的渲染指令数据进行分组，构建相应数量的数据处理通道，但并不局限于这种方式。
基于此，在实际应用中，对截获的每一帧渲染指令数据进行分组后，本实施例也可以基于各待压缩数据组包含的数据的特点，获取对应的数据压缩方式，此时，也可以预先设置对应不同数据特点的多种数据压缩方式，完成数据分组后，可以直接从预设的多个数据压缩方式中选择，但步骤S203的实现方式并不局限于本文描述的方式。
步骤S204，同时触发多层数据处理通道，按照各待压缩数据组对应的数据压缩方式，对该待压缩数据组包含的数据进行压缩；
在本实施例中，由于创建了多层数据处理通道，为了最大可能提高数据压缩效率，可以触发多层数据处理通道并行控制的方式，即使用多层数据处理通道，同时对相应待压缩数据组包含的数据进行压缩处理，相对于传统创建一层数据处理通道，对截获的所有渲染指令数据进行压缩处理的方式，本实施例这种多层数据处理通道并行对各组数据进行压缩处理的方式，极大缩短了数据压缩时间，提高了数据压缩效率。
可以理解的是，对多层数据处理通道的触发方式并不局限于本实施例描述的这种并行处理方式，也可以按照一定时间间隔依次触发等等，具体可以参照上文实施例相应部分的描述。
而且，使用各层数据处理通道进行压缩处理时，可以针对相应数据特征，选用专用数据压缩方式，对该层数据处理通道接收到的数据进行压缩处理，相对于通用数据压缩方式，进一步提高了数据压缩效率，且提高了数据压缩算法性能，本实施例对各层数据处理通道对应的数据压缩方式的内容不作限定。
经测试验证，仅仅将渲染指令数据中的纹理数据，顶点索引数据、变换矩阵分别建立多层数据处理通道，分开进行数据压缩处理后进行网络传输，相对于传统直接对所有渲染指令数据进行压缩后进行网络传输，就会降低10％～20％的网络流量，更何况，如上述实施例描述，本实施例还可以对渲染指令数据中的其他类型的数据，建立相应的数据处理通道进行单独压缩，能够更大程度地降低网络流量。所以说，本实施例上述数据处理方式，在提高数据压缩效率同时，极大降低了所消耗的网络流量。
步骤S205，对多层数据处理通道输出的多个压缩文件进行合并，得到待发送数据；
本实施例可以将这多个压缩文件作为一个整体进行传输，对多个压缩文件的合并方式不作限定。
步骤S206，按照网络传输层通信协议，将待发送数据发送至客户端。
在实际应用中，往往是用户使用终端设备进入应用平台，选择应用启动，与服务侧的应用服务器建立通信连接，即建立用户侧的客户端与服务侧的应用服务器之间的通信通道，以使应用服务器运行的应用进程，通过该通信通道实现与客户端的数据交互，以使客户端展示应用图形界面，方便用户在该应用图形界面上进行操作。
其中，客户端与应用服务器之间的通信通道，通常是利用互联网形成的通道，即应用服务器中应用进程所使用的通信网络，以保证应用进程将待发送数据，准确发送至用户启动的客户端，使得该客户端能够输出相应的应用图形界面。
可选的，客户端接收到应用服务器发送的多个压缩文件后，可以利用各压缩文件对应的数据压缩算法，对相应压缩文件进行解压处理，得到多个解压数据组，之后，通过对多个解压数据组包含的数据进行组合，得到应用服务器截获的渲染指令数据，即实现了将应用服务器中应用进程调用的渲染指令数据发送至客户端，由客户端进行后续渲染操作，即基于渲染指令数据，实现相应应用图形界面的渲染，保证用户使用基于云计算的应用的实时性。
基于上段分析可知，本实施例中的数据压缩算法，不仅能够实现对各待压缩数据组包含的数据的压缩处理，还可以对压缩文件进行解压处理，即数据压缩算法可以同时具有数据压缩及解压功能，两者实现过程往往是相反的，本实施例在此不做详述。
当然，本实施例也可以利用独立的数据解压算法，实现对压缩文件的解压处理，此时，该数据解压算法与相应数据压缩算法的处理过程相匹配，保证数据解压算法能够对相应格式的压缩文件进行解压处理。本实施例对数据压缩和数据解压实现方式不做限定。
综上所述，在本实施例中，参照图4所示的应用场景流程示意图，在截获应用进程调用的渲染指令数据之后，将其分成多个待压缩数据组，并使用创建的多层数据处理通道，同时对各层数据处理通道接收到的数据，按照合适的数据压缩方式进行压缩处理，即并行进行数据压缩处理，提高了数据处理效率及算法性能，降低了传输压缩文件消耗的网络流量。
作为本申请另一可选实施例，关于对截获的渲染指令数据的分组方式，并不局限于上述实施例描述的相似性分组方式，还可以根据调用API的输入数据的特征进行分类，从而实现渲染指令数据的分组，参照图5所示的数据处理方法的另一流程示意图，该方法具体可以包括：
步骤S301，截获应用进程运行期间调用的渲染指令数据；
步骤S302，提取该渲染指令数据包含的资源数据及指令数据；
在本实施例实际应用中，应用进程可以采用调用API的方式，调用渲染指令数据，进而，可以通过对API的输入数据特征进行分类，大的分类可以将其分为资源数据和指令数据，还可以对这两大类数据进行细化，具体分类方法及分类结果不做限定。
步骤S303，将资源数据作为一个待压缩数据组，得到第一待压缩数据组；
参照图6所示的流程示意图，本实施例从截获的渲染指令数据中提取出资源数据后，可以将资源数据直接分为一组，记为第一待压缩数据组，后续直接对所有资源数据进行统一压缩处理。
可选的，在实际应用中，资源数据通常包括纹理数据、各种模型数据等，本实施例也可以按照资源数据包含的数据类型，对资源数据进行细化分组，具体分组方式不做限定。
进一步，上述可选实施例提出的对资源数据的细化分组，可以是在资源数据的数据量达到一定阈值时再执行，也就是说，从截获的渲染指令数据中提取出资源数据后，可以先统计资源数据的数据量，当该数据量达到预设阈值，可以按照资源数据具有的数据类型，对提取的资源数据进行分组，得到多个第一待压缩数据组；若统计得到的数据量未达到预设阈值，可以直接将提取的所有资源数据作为一个待压缩数据组，可以不再对资源数据细化分类，从而减少待压缩数据组的数量，进而减少创建的数据处理通道。
需要说明，在执行步骤S303之前，并不局限于上文描述的统计资源数据的数据量这一种方式，确定是否对提取的资源数据细化分组。
步骤S304，按照指令数据包含的调用接口类型，创建相应的第二待压缩数据组；
在实际应用中，调用不同指令使用的API往往是不同，因此，参照图6，本实施例可以根据指令API类型，实现对提取的指令数据的分组，如将相同指令接口数据(即相同类型指令API及其参数信息)构成一个待压缩数据组。可见，步骤S304中的调用接口类型可以是指令API类型。
可选的，本实施例可以针对每一个调用接口类型，创建一个第二待压缩数据组，这样，指令数据包含多少种调用接口，就可以创建相同数量的第二待压缩数据组，但并不局限于这种对指令数据的分组方式。
步骤S305，将各类调用接口分别对应的指令数据，存放到相应的第二待压缩数据组；
结合上述分析，各类调用指令对应的指令数据可以包括指令API及其参数信息，如上文描述，每个第二压缩数据组可以包括至少一个指令API，本实施例对指令数据具体包含的内容不作限定。
步骤S306，针对各待压缩数据组，分别创建相应的数据处理通道；
在实际应用中，对于创建的每一个第一待压缩数据组和每一个第二待压缩数据组，可以生成对应的线程进行数据处理，本实施例对线程创建的具体实现方法不作详述。
需要说明，在应用进程的初始化阶段，或者说，首次截获渲染指令数据并分组后，可以按照本实施例描述的方式，实现多层数据处理通道的创建，待应用进程再次截获渲染指令数据并分组后，不需要再创建数据处理通道，可以直接利用已创建的数据处理通道，实现数据压缩处理。由此可以理解的是，上述步骤S301～步骤S305可以应用到应用进程每次截获渲染指令数据后的分组，步骤S306可以在应用进程首次截获渲染指令数据并分组后执行，再次进行截获并分组操作后，可以不再执行步骤S306。
步骤S307，基于各待压缩数据组包含的数据内容分析结果，获取相应的数据压缩方式；
按照上文描述的数据分组方式，各待压缩数据组包含的数据特征往往不同，本实施例可以根据各待压缩数据组包含的数据内容的分析结果，选择使该组数据压缩效率最高的数据压缩算法，作为该组数据的专用数据压缩算法，即该组数据对应的数据处理通道对应的数据压缩算法。
需要说明，本实施例对如何选择各待压缩数据组相应的数据压缩算法的方式不作限定，且各待压缩数据组相应的数据压缩算法可以完全不同，也可以部分组对应的数据压缩算法类型相同，通常情况下，即便各组选择的数据压缩算法的类型相同，也可以根据各组数据特征，调整数据压缩算法的配置参数，即根据数据特征，优化数据压缩算法，以提高数据压缩效率和算法性能，本实施不再一一详述。
步骤S308，将得到的各待压缩数据组对应的数据压缩方式，与相应的数据处理通道关联；
也就是说，将针对同一待压缩数据组，得到的数据压缩算法和数据处理通道关联，以便将待压缩数据组包含的数据发送至相应数据处理通道后，直接触发适合该待压缩数据组包含的数据的数据压缩算法，即该数据处理通道关联的数据压缩算法，对接收到的数据进行数据压缩处理。
需要说明，关于数据处理通道与数据压缩方式的关联实现方法，并不局限于本实施例上文描述的方式。
步骤S309，使用创建的多层数据处理通道，按照各自关联的数据压缩方式，对相应待压缩数据组包含的数据进行压缩；
可见，本实施例可以采用多线程并行运行的方式，触发多层数据处理通道关联的数据压缩方式，对各自调用的数据进行处理，相对于传统方法中直接对截获的所有渲染指令数据进行统一压缩处理的方式相比，多层数据处理通道采用适合相应待压缩数据组的数据压缩方式，进行数据压缩处理，提高了数据压缩效率，降低了传输数据所消耗的网络流量。
作为本申请另一可选实施例，在本实施例提出的数据分组方式下，也可以按照通用数据压缩方式，触发多层数据处理通道并行进行数据压缩处理，同样也能够提高数据压缩效率，并不局限于本实施例描述的这种设置专用数据压缩算法进行压缩的方案。
步骤S310，对多层数据处理通道输出的多个压缩文件进行合并，得到待发送数据；
步骤S311，按照网络传输层通信协议，将待发送数据发送至客户端。
本实施例中，步骤S310和步骤S311的实现方法，可以参照上述实施例步骤S206和步骤S207的描述。
综上所述，参照图6，在截获应用进程运行期间调用的渲染指令数据后，本实施例考虑到一帧数据内的具体数据组成和数据差异，将提取其包含的资源数据和指令数据，将资源数据作为一组数据即第一待压缩数据组的数据，同时根据调用接口类型，对提取的指令数据进行分组，之后，利用各组数据对应的数据压缩方式，使用独立的数据处理通道，对各待压缩数据组包含的数据进行处理，相对于现有技术直接利用一种数据压缩算法，对截获的所有渲染指令数据进行压缩的处理方式，极大提高了数据压缩效率和算法性能，降低了网络流量，且多层数据处理通道并行工作的方式，能够显著提高多核处理器的性能。
可选的，在应用进程运行过程中，随着时间的变化，截获的各帧渲染指令数据包含的数据类型，及各类型数据的数据量往往是不断变化的，尤其是渲染指令数据包含的各指令数据，参照图7a所示的某一种应用的某应用场景中，渲染指令数据包含的各指令数据的数据量变化示意图，图7a中的横坐标可以表示帧数，即第几帧渲染指令数据，纵坐标可以表示数据量大小，单位可以是byte。
其中，图7a中每个序号对应的曲线，表示渲染指令数据中的一类型数据的数据量，如序号为①的曲线可以表示FrameTotal这类数据的数据量，可以记为FrameTotal Size；序号为③的曲线可以表示IDirect3DDevice9::SetRenderState这一类型的数据，可以记为IDirect3DDevice9::SetRenderState_Size，本实施例在此不再一一列举。需要说明，图7a并未示出各类数据的名称，且截获的渲染指令数据包含的各类指令数据的数据量变化，并不局限于图7a所示的方式。
在实际应用中，按照上述可选实施例描述的分组处理方式，直接将各类型指令数据分别作为一组数据，再对得到的各第二待压缩数据组包含的数据进行压缩处理，可以得到如图7b所示的压缩文件的数据量图表，但并不局限于此。
由图7b所示的各类型指令数据对应的压缩文件的数据量关系可知，绝大部分类型的指令数据压缩后的数据量都很小，只有几个类型指令数据压缩后的数据量相对比较大，因此，本实施例可以根据各类指令数据压缩后的数据量，对分组和数据处理通道进行调整。
具体的，本实施例可以将指令数据中占比例较少的指令接口数据，合并构成一个第二待压缩数据组，对主要的几个指令接口数据分组，得到相应组数的第二待压缩数据组。因此，参照图8所示的数据处理方法的流程示意图，从渲染指令数据提取的指令数据，并按照上述可选实施例描述的方式分组后，还可以采用以下步骤描述的方式，调整指令数据的分组，但并不局限于本实施例描述的这种分组调整方式，具体调整方法可以包括：
步骤S401，获取各第二待压缩数据组包含数据的数据量；
本实施例可以在按照上述步骤S304和步骤S305的方式，得到多个第二待压缩数据组后，统计各待压缩数据组包含数据的数据量，具体统计方式不作限定。
步骤S402，统计数据量小于第一阈值的第二待压缩数据组；
其中，第一阈值可以是决定是否将该待压缩数据组与其他待压缩数据组合并的数据量的临界值，具体可以通过统计各第二待压缩数据组包含数据的数据量确定，也可以根据多次统计结果确定，本实施例对该第一阈值的具体数值不作限定。
本实施例可以将得到的各第二待压缩数据组包含数据的数据量与第一阈值进行比较，以确定各第二待压缩数据组中，数据量小于第一阈值的第二待压缩数据组，即获取需要合并的包含数据较少的第二待压缩数据组。
步骤S403，对统计得到的第二待压缩数据组包含的数据进行合并，得到新的第二待压缩数据组。
可见，本实施例将包含数据较少的第二待压缩数据组进行合并，从而减少由指令数据分组得到的第二待压缩数据组的组数，进而减少需要创建的处理第二待压缩数据组包含的数据的数据处理通道的数量，避免了数据分组数量过多，对客户端解压及数据组合处理带来的麻烦。
需要说明，关于对得到的各第二待压缩数据组的调整方式，并不局限于本实施例描述的这种基于数据量进行合并的方式。
作为另一可选实施例，上述对指令数据的分组调整方法，可以如上述实施例描述在完成指令数据的初步分组，即得到多个第二待压缩数据组后执行，也可以在得到多个第二待压缩数据组之前，在对指令数据进行分析过程中完成，具体可以获取对应每一个调用接口类型的指令数据的数据量，按照上述方式，不再针对每一个调用接口类型，创建第二待压缩数据组，而是根据得到的数据量统计结果，获取数据量大于第一阈值的几个调用接口类型对应的指令数据，针对这些数据创建相应数量的第二待压缩数据组，并将这些数据存放至相应的第二待压缩数据组，并剩余其他指令数据合并成一组，构成一个第二待压缩数据组，之后，针对得到的每一个第二待压缩数据组，创建相应的数据处理通道，后续处理过程可以参照上述实施例相应部分的描述，本实施例在此不再赘述。
可见，在对指令数据分组时，本实施例可以不用针对每一种调用接口，创建相应的第二待压缩数据组，可以对占据主要数据的几个调用指令建立分组，其他调用接口合并使用一个分组，以减少分组以及数据处理通道的数量，
以调用接口为API为例，参照图9，按照上述描述对指令数据的分组方式，得到的每一个第二待压缩数据组可以包括多个API对应的数据，图9仅以APIn来表示相应API对应的数据，n为正整数，将针对每一个第二待压缩数据组，创建的数据处理通道记为channel，如图9所示的channel1、channel2、channel3、…、channeln等等。
如上述分析，为了提高各数据处理通道对应的数据的压缩效率及算法性能，本实施例可以对得到的各第二待压缩数据组的数据进行差异分析，如分析各第二待压缩数据组的数据组成及数据特点等，来确定使对该组数据的压缩效率最大的数据压缩方式，之后，在各自的数据处理通道中，利用各自数据压缩算法对相应组的数据进行压缩。
其中，按照上述可选实施例描述的方式，对数据量较少的几类调用接口对应的数据合并后，可以采用通用数据压缩方式，对合并得到的第二待压缩数据组的数据进行压缩处理，对于包含数据量较多的第二待压缩数据组，可以采用上述方式进行差异分析，得到的相应的专用数据压缩方式，但并不局限于这种压缩处理方案。
需要说明，本实施例对各组数据的差异分析时采用的数据压缩方式，以及各组对应的数据压缩方式的内容不作限定，可以根据相应组数据的组成和特点确定，以优化数据压缩效率。
参照图10，本实施例还可以另一种数据处理方法的流程示意图，该方法主要从用户侧的客户端角度描述，客户端接收到应用服务器发送的压缩文件后的处理过程，可以包括但并不局限于下文描述的步骤：
步骤S501，接收应用服务器发送的多个压缩文件；
结合上述从应用服务器角度描述的各实施例提供的数据处理方法，应用服务器通过多层数据处理通道对分组数据进行压缩处理，得到多个压缩文件后，可以将这多个压缩文件合并后，通过网络发送至客户端。
因此，步骤S501具体可以是通过网络接收多个压缩文件，且该多个压缩文件可以是合并后的一个文件，也可以是多个文件，本实施例对多个压缩文件的网络传输方式及形式不作限定。
步骤S502，对多个压缩文件进行解压处理，得到多个解压数据组；
结合上述描述，每一个解压数据组可以包括上述渲染指令数据包含的至少一类数据。
可选的，本实施例中的数据压缩算法可以同时具有数据压缩和解压缩功能，因此，在应用服务器中，利用数据压缩方式1，对某层数据处理通道接收到的数据进行压缩处理，在客户端侧解压该层数据处理通道输出的压缩文件时，可以采用与数据压缩过程相匹配的解压方式，实现对压缩文件的解压，如利用相应数据压缩方式1的解压功能，实现对该压缩文件的解压处理。
当然，本实施例也可以采用支持所得压缩文件格式的解压算法，实现对接收到的压缩文件的解压，并不局限于特定的解压算法，即本实施例对压缩文件的解压方式不作限定。
步骤S503，对多个解压数据组包含的数据进行组合，得到渲染指令数据；
本实施例可以根据上述实施例描述的对截获的渲染指令数据的分组方式，将该分组方式的逆向处理方式，作为多个解压数据组的组合方式，实现对多个解压数据组包含的数据的组合，以还原应用服务器截获的渲染指令数据。
可见，应用服务器对截获的渲染指令数据的分组方式不同，此时，客户端对得到的多个解压数据组包含的数据的组合方式也会相应改变，本实施例在此不再一一详述。
步骤S504，利用该渲染指令数据，渲染相应应用图形界面。
本实施例对如何利用渲染指令数据，渲染应用图形界面的实现方法不作限定。
综上所述，本实施例将对应用图形界面的渲染过程转移到客户端执行，应用服务器通过网络向客户端发送的渲染指令数据，不再是一个压缩文件，而是对该渲染指令数据分组并压缩得到的多个压缩文件，提高了应用服务器对渲染指令数据的压缩效率，降低了传输该渲染指令数据消耗的网络流量。客户端接收到多个压缩文件后，可以按照应用服务器对截获的渲染指令数据处理方式的逆向过程，对多个压缩文件进行解压并组合，以准确得到该渲染指令数据，并据此渲染相应的应用图形界面，提高了客户端输出应用进程运行相应的应用图形界面的实时性。
需要说明在上述各实施例中，可以每次截获渲染指令数据，按照上述各实施例描述的方式，对其包含的数据进行分组后，创建数量的多层数据处理通道，待将由该渲染指令数据得到的压缩文件发送至客户端后，结束该数据处理通道，即关闭线程；下次截获渲染指令数据后，仍可以按照上述实施例描述的方式进行数据处理。
当然，本实施例也可以在截获多帧渲染指令数据，并按照上述方式对各帧渲染指令数据分组后，将相同类型或相似数据的待压缩数据组进行合并，之后，根据此时待压缩数据组的数量，创建相同数据的数据处理通道，其他处理步骤可以参照上述实施例相应部分的描述。
结合上述各实施例描述的数据处理方法，本申请在此以应用为云游戏为例，来说明用户进入任意一款云游戏进行操作过程中，如何利用本申请提供的数据处理方法，来保证用户对云游戏的正常使用。参照图11所示的流程示意图，在云游戏系统中包括游戏进程、截获模块、数据分类模块、帧间数据差异处理模块、数据压缩/解压模块，其中，这些模块通常包括服务端和用户端对应的功能，通常情况下，同一种模块在服务端和用户端执行的功能是相反的，具体可以参照下文描述。需要说明，图1是以各待压缩数据组包含的数据，采用通用数据压缩算法进行压缩的为例进行说明，而利用专用数据压缩算法，对相应待压缩数据组包含的数据进行压缩的处理过程类似，本实施例在此不再详述。
参照图11，用户通过终端设备进入云游戏平台，从当前界面选择某一种云游戏(记为游戏A)点击，将进入该游戏A的登录界面，此时，用户可以输入登录游戏A的账号和密码，建立与该游戏A对应的游戏服务器(其实际上是云游戏服务器中游戏A客户端)的通信连接，从而使用户进入游戏A操作界面玩游戏。
而对于游戏A对应的游戏服务器来说，其验证用户A输入的账号和密码正确后，可以创建相应的游戏进程，以使游戏A能够在该游戏进程中运行，保证用户能够正常玩游戏A。在该过程中，服务侧的游戏进程运行过程中，往往会对游戏过程进行录制，以使用户侧的客户端能够根据录制的数据进行应用图形界面渲染。
在上述过程中，游戏服务器可以截获游戏进程调用的录制指令，得到相应的渲染指令数据，之后，由数据分类模块利用渲染指令数据包含的各种数据的特征，对该渲染指令数据进行分组，得到多个待压缩数据组，此时可以使用创建的相应数量的多个线程分别对各组待压缩数据组包含的数据进行压缩。
其中，在截获模块得到分组结果后，可以获取各待压缩数据组包含的关键帧数据，以使帧间数据差异处理模块对相邻帧的关键帧数据进行差异分析，得到各组数据通用的数据压缩方式，从而使用多个线程，利用该通用数据压缩方式，对相应待压缩数据组包含的数据进行压缩处理，得到相应的压缩文件。
之后，可以合并得到的多个压缩文件，并将合并后的压缩文件通过网络发送至终端设备的客户端，以使该客户端对接收到的压缩文件进行解压，得到多个解压数据组，再由帧间数据差异处理模块获取各解压数据组包含的关键帧数据，以使数据分类模块利用数据特征(其可以包括关键帧数据及其他参数)，对多个解压数据组包含的数据进行组合，从而还原游戏服务器截获的渲染指令数据，进而得到相应的录制指令，使得客户端回放录制指令，即利用渲染指令数据，渲染得到相应的游戏界面，并输出的客户端显示界面，以使用户侧客户端展示游戏界面与游戏进程运行的游戏保持一致。
其中，对于各线程接收到的数据，本实施例也可以利用专用的数据压缩算法进行压缩处理，以进一步提高数据压缩效率。本实施例对各待压缩数据组对应的专用数据压缩算法的获取方式不作限定，在利用这种方式实现的数据处理方法中，其他处理步骤与图11所示的其他步骤类似，本实施例不再详述。
综上，用户使用基于图形流的云游戏(即基于图形流数据传输方式实现的云游戏)过程中，游戏服务器通过对渲染指令数据进行组成分析和特征提取，得到多个数据特征集，由每个数据特征集构成一个待压缩数据组，即将渲染指令数据分成多组数据，使用独立的线程，对相应待压缩数据组包含的数据进行压缩处理，极大提高了数据压缩效率，降低了传输数据消耗的网络流量；且这种多线程并行处理的方式，显著提高了多核处理器的性能。
参照图12，为本实施例提供的一种数据处理装置的结构示意图，该装置可以应用于服务侧的应用服务器，具体可以包括：
截获模块110，用于截获应用进程运行期间调用的渲染指令数据；
分组模块120，用于对所述渲染指令数据进行分组，得到多个待压缩数据组，一个待压缩数据组包括所述渲染指令数据包含的至少一类数据；
数据压缩模块130，用于使用多层数据处理通道，对相应待压缩数据组包含的数据进行压缩处理，得到多个压缩文件；
在本实施例中，该装置还可以包括：
数据处理通道创建模块，用于在首次对截获的所述渲染指令数据进行分组，得到多个待压缩数据组后，创建与所述多个待压缩数据组分别对应的多层数据处理通道；
数据处理通道删除模块，用于当所述应用进程结束运行，删除所述多层数据处理通道。
需要说明，关于本实施例多层数据处理通道的创建方式，并不局限于本实施例描述的方式。
可选的，在本实施例实际应用中，数据压缩模块130具体可以用于同时触发各层数据处理通道，对相应待压缩数据组包含的数据进行压缩，得到多个压缩文件，以提高数据压缩效率，降低传输数据消耗网络流量。
当然，数据压缩模块130也可以依次触发或间隔预设时间触发各层数据处理通道，对相应待压缩数据组包含的数据进行压缩，得到多个压缩文件。
作为另一可选实施例，上述数据处理模块还可以用于使用多层数据处理通道，按照不同的数据压缩方式，对相应待压缩数据组包含的数据进行压缩处理，得到多个压缩文件，所述数据压缩方式基于相应待压缩数据组包含的数据确定。
数据发送模块140，用于将所述多个压缩文件发送至客户端。
可选的，该数据发送模块140可以包括：
数据合并单元，用于将所述多个数据处理通道得到相应压缩文件进行合并，得到待发送数据；
数据传输单元，用于按照网络传输层通信协议，将所述待发送数据发送至客户端。
综上，本实施例截获渲染指令数据后，并未直接对其进行压缩处理，而是将其包含的数据分成多个待压缩数据组，再分别对各待压缩数据组包含的数据进行压缩，得到多个压缩文件，提高了整体数据压缩效率，降低了传输数据消耗网络流量，进而提高了应用运行的流畅性。
可选的，上述分组模块120可以包括：
相似性分组单元，用于对所述渲染指令数据包含的各类数据进行相似性分组，得到多个待压缩数据组；
其中，每一待压缩数据组包含的各类数据的相似度大于第一阈值。
作为另一可选实施例，如图13所示，该分组模块120可以包括
提取单元121，用于提取所述渲染指令数据包含的资源数据及指令数据；
第一分组单元122，用于对所述资源数据进行分组，得到至少一个第一待压缩数据组；
第二分组单元123，对所述指令数据进行分组，得到至少一个第二待压缩数据组。
其中，如图13所示，该第二分组单元123可以包括：
创建子单元1231，用于按照所述指令数据包含的调用接口类型，创建相应的第二待压缩数据组；
数据存放子单元1232，用于将各类调用接口分别对应的指令数据，存放到相应的第二待压缩数据组。
需要说明，对于上述分组120模块对渲染指令数据包含的数据的分组方式，并不局限于上文实施例列举的实现方式。
可选的，在上述实施例的基础上，装置还可以包括：
数据量获取模块，用于获取各第二待压缩数据组包含数据的数据量；
数据量统计模块，用于统计所述数据量小于第一阈值的第二待压缩数据组；
数据合并模块，用于将统计得到的各第二待压缩数据组包含的数据合并，得到新的第二待压缩数据组。
可选的，如图14所示，本实施例提供的装置还可以包括：
数据分析模块150，用于对各待压缩数据组包含的数据进行分析；
数据压缩算法获取模块160，用于根据分析结果，获取各待压缩数据组对应的数据压缩方式；
数据压缩算法关联模块170，用于将各待压缩数据组对应的数据压缩方式，与相应层数据处理通道关联。
可见，在本实施例实际应用中，使用多层数据处理通道，对相应待压缩数据组包含的数据进行压缩时，可以采用通用数据压缩方式实现，也可以按照上述方式，采用各待压缩数据组对应的专用数据压缩方式实现，实施例对具体数据压缩过程不作限定。
且，需要说明，本实施例对如何确定通用数据压缩算法及各专用数据压缩算法的方式不作限定。
如图15所示，为本实施例提供的另一种数据处理装置的结构示意图，该装置可以应用于用户侧的客户端，具体可以包括：
数据分析模块210，用于对各待压缩数据组包含的数据进行分析；
数据压缩算法获取模块220，用于根据分析结果，获取各待压缩数据组对应的数据压缩算法；
数据压缩算法关联模块230，用于将各待压缩数据组对应的数据压缩算法，分别与相应层数据处理通道关联。
在本实施例实际应用中，对客户端接收到的多个压缩文件的解压方式，及解压得到的多个解压数据组包含的数据组合方式，均不作限定，可以采用上文描述的渲染指令数据的分组和压缩处理方式的逆向处理方式实现，但并不局限于此，本实施例在此不做详述。
需要说明，上述各实施例提供的数据处理装置包含的各模块或单元，可以是实现相应功能的程序模块。
参照图16，本实施例还提供了一种计算机设备的硬件结构示意图，该计算机设备可以是云端的应用服务器，具体可以包括但并不局限于：通信接口310、存储器320及处理器330。
在本实施例中，该通信接口310、存储器320及处理器330的数量可以是为至少一个，且通信接口310、存储器320及处理器330可以通过通信总线实现相互间的通信。
可选的，通信接口310可以为通信模块的接口，如GSM模块的接口等等，本实施例对该通信接口310的类型不做限定。
处理器330可以是一个中央处理器CPU，或者是特定集成电路ASIC(Application Specific Integrated Circuit)，或者是被配置成实施本发明实施例的一个或多个集成电路。
存储器320可能包含高速RAM存储器，也可能还包括非易失性存储器(non-volatile memory)，例如至少一个磁盘存储器。
其中，存储器320可以用于存储实现如上所述的数据处理方法的程序，处理器320可以加载并执行该程序，实现以下步骤：
截获应用进程运行期间调用的渲染指令数据；
对所述渲染指令数据进行分组，得到多个待压缩数据组，一个待压缩数据组包括所述渲染指令数据包含的至少一类数据；
使用多层数据处理通道，对相应待压缩数据组包含的数据进行压缩处理，得到多个压缩文件；
将所述多个压缩文件发送至客户端。
本施例还提供了一种存储介质，其上存储有计算机程序，该计算机程序被处理器执行时，实现如上述实施例的描述的数据处理方法的各个步骤，具体实现过程本实施例不作赘述。
本施例还提供了另一种存储介质，该存储介质可以记录有实现上述应用于客户端的数据处理方法的程序，以使客户端的处理器调用该程序，实现应用于客户端的数据处理方法的各步骤。本说明书中各个实施例采用递进的方式描述，每个实施例重点说明的都是与其他实施例的不同之处，各个实施例之间相同相似部分互相参见即可。对于实施例公开的装置、计算机设备而言，由于其与实施例公开的方法相对应，所以描述的比较简单，相关之处参见方法部分说明即可。
专业人员还可以进一步意识到，结合本文中所公开的实施例描述的各示例的单元及算法步骤，能够以电子硬件、计算机软件或者二者的结合来实现，为了清楚地说明硬件和软件的可互换性，在上述说明中已经按照功能一般性地描述了各示例的组成及步骤。这些功能究竟以硬件还是软件方式来执行，取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本发明的范围。
结合本文中所公开的实施例描述的方法或算法的步骤可以直接用硬件、处理器执行的软件模块，或者二者的结合来实施。软件模块可以置于随机存储器(RAM)、内存、只读存储器(ROM)、电可编程ROM、电可擦除可编程ROM、寄存器、硬盘、可移动磁盘、CD-ROM、或技术领域内所公知的任意其它形式的存储介质中。
对所公开的实施例的上述说明，使本领域专业技术人员能够实现或使用本发明。对这些实施例的多种修改对本领域的专业技术人员来说将是显而易见的，本文中所定义的一般原理可以在不脱离本发明的核心思想或范围的情况下，在其它实施例中实现。因此，本发明将不会被限制于本文所示的这些实施例，而是要符合与本文所公开的原理和新颖特点相一致的最宽的范围。