具体实施方式

下面详细描述本申请的实施例，所述实施例的示例在附图中示出，其中自始至终相同或类似的标号表示相同或类似的元件或具有相同或类似功能的元件。下面通过参考附图描述的实施例是示例性的，仅用于解释本申请，而不能理解为对本申请的限制。对于以下实施例中的步骤编号，其仅为了便于阐述说明而设置，对步骤之间的顺序不做任何限定，实施例中的各步骤的执行顺序均可根据本领域技术人员的理解来进行适应性调整。

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

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

游戏引擎：指一些已经编写好的可编辑电子游戏系统或者一些交互式实时图像应用程序的核心组件。游戏引擎主要为电子游戏的开发者提供各种编写游戏程序所需的工具，其目的在于让开发者更容易、快速地做出游戏程序而无需从零开始。相关技术中，游戏引擎可以包含以下系统：渲染引擎(包括二维图像引擎或者三维图像引擎)、物理引擎、碰撞检测系统、音效、脚本引擎、电脑动画、人工智能、网络引擎以及场景管理等。

随着互联网技术的飞速发展，在工作学习之余，人们休闲娱乐的手段也越发多样化。在这其中，电子游戏是一种依托于终端设备实现的娱乐活动，因其丰富的游戏内容、多变的游戏体验而广受用户的喜爱。参照图1，图1示出了相关技术中一种电子游戏从开发到被实施的过程示意图，在该过程中，涉及的主体主要包括游戏开发者110、游戏平台120和用户130。

其中，游戏开发者110指的是电子游戏的制作者，例如可以包括制作电子游戏软件的企业、团体或者个人中的至少一个。游戏平台120指的是电子游戏的运营平台，在一些实施例中，游戏平台120可以是指操作系统，例如可以是Web Player平台、PC平台、IOS平台、Android平台等；在一些实施例中，游戏平台120也可以是指软件或者具有运行游戏功能的网页，例如可以是UPLAY、EPIC Games、暴雪游戏平台、Origin、Steam、WeGame等；在一些实施例中，游戏平台120也可以是指游戏的后台服务器，该后台服务器可以配置成独立的物理服务器，也可以配置成多个物理服务器构成的服务器集群或者分布式系统，还可以配置成提供云服务、云数据库、云计算、云存储等业务的云服务器；在一些实施例中，游戏平台120也可以是指为家用游戏机或者多功能掌上游戏机等硬件设备设计的专用系统。

用户130是电子游戏的玩家，用户130可以通过终端设备运行电子游戏。在一些实施例中，终端设备可以是家用游戏机、多功能掌上游戏机、智能手机、平板电脑、笔记本电脑或者台式计算机等的任意一种。

当一款电子游戏被游戏开发者110制作完成后，可以将该游戏的资源，例如包含游戏应用程序、环境配置、注册表等的压缩包上传到对应的游戏平台120发布，用户可以在游戏平台120上进行在线游戏，或者通过游戏平台120下载对应的游戏安装包安装到终端设备上游玩。当然，可以理解的是，游戏开发者110也可以通过游戏平台120对游戏内容进行调整，例如进行版本更新、BUG维护等工作。

对于游戏开发者110来说，由于游戏的更新迭代速度较快，而且绝大部分的游戏玩法已经固定化、模式化，例如比较典型的第一人称射击游戏(First-person shootinggame，FPS)、多人在线战术竞技游戏(Multiplayer Online Battle Arena，MOBA)等，同种类型的游戏可能有很多种，只是在设定和细节上存在一定的区别。如果开发这些游戏都从头开始编写代码，将会造成大量的重复劳动。而游戏引擎的出现良好地解决了这一问题，它是一种包括大量已编写好的可编辑电子游戏系统或者一些交互式实时图像应用程序的核心组件，可以为游戏开发者110提供各种编写电子游戏所需的工具，有助于容易、快速地做出游戏程式而不用从零开始。例如，在制作某一款第一人称射击类游戏时，游戏开发者110通过游戏引擎可以借用类似题材的游戏中的部分代码作为新游戏的基本框架，以节省大量开发时间和费用。通过游戏引擎制作出的游戏，只需要在游戏的资源包中搭载相应游戏引擎的环境配置，就能够供用户游玩，用户无需单独下载游戏引擎。相关技术中，运用比较多的游戏引擎包括Unity引擎、Creation引擎、Unreal引擎、Frostbite引擎等。随着电子游戏的画面进入3D时代后，游戏引擎的使用不但能够令游戏开发工作事半功倍，还能带来丰富的游戏画面和细节的纹理表现，很大程度上提高了电子游戏的质量。

对于广大的用户130而言，一款电子游戏是否受欢迎，游戏体验是其最关注的部分。而游戏体验不但和游戏本身的质量有关，也和用户所使用硬件设备的性能，即电子游戏运行的硬件环境相关。如果用户所使用的硬件设备本身性能不佳，可能游戏运行的效果会受到较大的影响。例如，在游戏启动时，通常通过显示启动画面来提升用户体验，由于启动画面需要的资源很多，如图2所示，从用户操作启动游戏到启动画面显示的耗时为：加载游戏引擎的耗时加上启动游戏引擎的耗时加上游戏引擎加载场景的耗时加上游戏引擎API绘制画面的耗时，启动时间过长会产生用户卡死的感觉，用户体验不友好，降低了游戏的用户转化率。

基于此，本申请实施例提供了一种加快游戏启动速度的方法、装置及计算机设备，可以应用于手机、平板电脑、游戏机等上，例如，可以实现人机交互且具有触控功能的设备上。其中，上述触控终端包括触摸屏和处理器，该触摸屏用于呈现启动页面和接收针对启动页面的指令操作。

在本申请中，提供了一种加快游戏应用启动速度的方法及装置、计算设备和计算机可读存储介质，在下面的实施例中逐一进行详细说明。

图3示出了根据本申请一实施例的加快游戏应用启动速度的流程示意图，包括如下步骤：

步骤202：游戏启动时，加载启动画面数据；

在该步骤中，当用户启动游戏应用时，加载游戏的启动画面数据。该启动画面数据包括纹理资源，或其他能够描述画面组成的数据。

在一种具体的实施方式中，在游戏启动前，获取当前设备的系统信息。该系统信息包括但不限于设备的品牌、型号，操作系统的类型、版本号，处理器的型号等等，上述内容为本领域技术人员所熟知，在此不再赘述。

进一步的，根据获取到的当前设备的系统信息，判断当前设备是否需要采用加速启动，若需要采用则继续执行后续的游戏启动步骤。由于当前市场上设备硬件配置差别较大，对于不同的设备采用不同的启动动画渲染方式可以提高游戏启动的效率。当设备性能足够高时，利用游戏引擎加载启动界面所需要的加载耗时几乎无法感知，则无需使用原生API渲染，而且通过游戏引擎可以加载更加丰富的启动画面资源。对于性能较低的设备，则采用加速的方式，使用原生API渲染启动画面，避免出现游戏启动时的卡顿现象。

当游戏应用开发完成后，首先在各种不同的设备上进行启动测试，获得启动画面的耗时，根据耗时的长短将设备划分为高性能设备和低性能设备，并按照设备的型号作为设备性能表保存。

进一步的，为上述耗时的长短设置一时间阈值T1，T1的值由本领域技术人员根据实际情况设置，在此不做特别限定。当设备的该耗时大于T1，将该设备作为低性能设备保存，当设备的该耗时小于T1，则将该设备作为高性能设备保存。

当游戏应用正式发布后，该设备性能表既可以保存在游戏应用中，也可以保存在服务器中供游戏应用调用。

进一步的，判断当前设备是否需要采用加速启动的策略包括：判断当前设备是否属于低性能设备。在游戏启动前，获取当前设备的系统信息后，将该系统信息与设备性能表进行比较，若当前设备属于设备性能表中的低性能设备，则采用加速启动的方式，继续执行本方法中后续的游戏启动步骤；若当前设备属于设备性能表中的高性能设备，则直接使用游戏引擎进行启动画面的绘制。

进一步的，在当前设备首次启动游戏时判断当前设备是否属于低启动速率的设备。

在上述实施方式中，在游戏正式发布前，事先在不同设备上的进行启动测试，根据启动画面渲染的耗时，将设备进行划分为采用加速启动方式的低性能设备和采用游戏引擎渲染的高性能设备；当游戏发布后，在启动时可以根据不同性能的设备选择不同的启动画面渲染方式，根据当前系统情况为设备选择最合适的启动方式。

在另一种具体的实施方式中，判断当前设备是否需要采用加速启动的策略包括：判断当前设备前N次启动是否采用低速率启动，N≥2。

进一步的，在当前设备非首次启动游戏时，读取设备前N次启动时渲染启动动画的耗时数据，并计算该N次耗时数据的平均值T，若T大于一时间阈值T2，则判断该设备为低性能设备，采用加速启动的方式，继续执行本方法中后续的游戏启动步骤；若T小于一时间阈值T2，则判断该设备为高性能设备，直接使用游戏引擎进行启动画面的绘制。上述N和T2的值均由本领域技术人员根据实际情况设置，在此不做特别限定。

进一步的，在设备每次启动游戏时，记录启动时间，在设备每次结束启动画面的渲染时，记录结束时间，用于计算设备每次进入游戏时渲染启动画面的耗时，将计算得到的耗时数据保存在本地的数组中。

在该实施方式中，在游戏启动时，统计游戏启动画面的历史耗时数据，并根据该历史耗时数据为设备选择相应的启动方式。通过该实施方式，实现了根据设备的真实使用情况动态地调整游戏的启动画面渲染方式。在目前的设备中，尤其是在Android设备中，随着设备的使用，安装的应用和垃圾数据越来越多，设备的运行速度会越来越慢，即使是一台高性能的设备也会出现加载游戏引擎时间过长的情况发生，通过本实施方式中的方式，可以在此种情况发生时为该设备选择加速启动的方式，调用系统原生渲染API绘制启动画面，避免卡顿现象的出现。

步骤204：使用当前系统原生渲染API绘制加载后的启动画面数据，完成启动画面的渲染。

在该步骤中，系统原生渲染API包括但不限于Android系统中的Canvas，Windows系统中的DirectX等等，该技术为本领域技术人员所熟知，在此不在赘述。

在一种具体的实施方式中，如图4所示，在使用系统原生渲染API绘制加载后的启动画面数据之前，判断加载启动画面数据阶段是否超时，若超时，则使用游戏引擎直接进行启动画面的绘制。

在另一种具体的实施方式中，如图5所示，判断使用系统原生渲染API绘制阶段是否出现异常，若出现异常，则使用游戏引擎进行启动画面的绘制。

在另一种具体的实施方式中，在游戏启动时开始计时，若在时间阈值T3内启动画面的渲染仍未结束，则直接进入游戏引擎的加载，使用游戏引擎进行启动画面的绘制。T3的值由本领域技术人员根据实际情况设置，在此不做特别限定。

在上述实施方式中，为游戏的加速启动方式设置了完备的容错机制，在判断出加载启动画面数据或调用系统原生渲染API出现异常时，说明当前情况已无法达成加速渲染，直接使用游戏引擎的启动渲染流程，以确保游戏正常启动。

步骤206：在游戏启动时，同步进行游戏引擎的启动和初始化。

如图3所示，在游戏启动时加载启动画面数据，此时，同步进行游戏引擎的启动和初始化。本方法利用加载启动画面数据和系统原生渲染API渲染启动画面与游戏引擎的启动和初始化同步并行进行，节省了游戏启动需要耗费的时间，当启动画面渲染完成时，若游戏引擎的启动和初始化也已经完成，可以直接进入游戏。当利用系统原生渲染API渲染失败时，也可以利用已经加载完成或即将加载完成的游戏引擎来进行启动画面的渲染，进一步提高了启动画面渲染的效率。

通过本申请的实施例，在游戏启动后，初始化引擎前，使用当前系统的原生渲染API绘制启动画面，由于原生渲染API绘制的效率很高，解决了等待引擎启动时的画面空白期。在本申请实施例的方法中，从用户操作启动游戏，到第一个画面显示出的耗时为加载启动画面数据的耗时加上原生API渲染耗时，在处理流程上更加精简，而且使用的启动画面数据比游戏引擎中场景所依赖的资源要小得多，使用效率更高的系统原生渲染API能够极大的降低渲染耗时。最后本申请的实施例还采取了不同的启动策略，根据设备的系统情况，使用情况等等为设备选择不同的启动方式，提高了游戏应用的启动效率，提高了用户体验。

与上述方法实施例相对应，本申请还提供了一种加快游戏应用启动速度的装置实施例，图6示出了本申请一个实施例的一种加快游戏应用启动速度的装置的结构示意图。如图6所示，该装置包括：

加载单元，用于在游戏启动时加载启动画面数据；

渲染单元，用于使用当前系统原生渲染API绘制加载后的启动画面数据，完成启动画面的渲染；

初始化单元，用于在游戏启动时，同步启动和初始化游戏引擎。

可选的，该装置还包括：

计时单元，用于在游戏启动时开始计时，若在时间阈值T内启动画面的渲染仍未结束，则直接使用游戏引擎进行启动画面的绘制。

可选地，加载单元还包括：

获取单元，用于在游戏启动前，获取当前设备的系统信息；

判断单元，用于根据所述系统信息判断当前设备是否采用加速启动，若采用则继续执行后续的游戏启动步骤，若不采用加速启动方式启动，则使用游戏引擎进行启动画面的绘制。

可选地，加载单元还包括：

超时判断单元，用于判断加载启动画面数据阶段是否超时，若超时，则使用游戏引擎进行启动画面的绘制。

可选地，渲染单元还包括：

异常判断单元，用于判断系统原生渲染API绘制阶段是否出现异常，若出现异常，则使用游戏引擎进行启动画面的绘制。

可选地，判断单元还包括：

判断子单元A，用于判断当前设备是否属于低启动速率的设备；

判断子单元B，用于判断当前设备前N次启动是否采用低速率启动。

可选地，判断子单元A，在当前设备首次启动游戏时判断当前设备是否属于低启动速率的设备。

可选地，判断子单元B，在当前设备非首次启动游戏时判断当前设备前N次启动是否采用低速率启动。

上述为本实施例的一种加快游戏应用启动速度装置的示意性方案。需要说明的是，该加快游戏应用启动速度装置的技术方案与上述的加快游戏应用启动速度方法的技术方案属于同一构思，加快游戏应用启动速度装置的技术方案未详细描述的细节内容，均可以参见上述加快游戏应用启动速度方法的技术方案的描述。

本申请一实施例中还提供一种计算设备，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机指令，所述处理器执行所述指令时实现所述的加快游戏应用启动速度方法的步骤。

上述为本实施例的一种计算设备的示意性方案。需要说明的是，该计算设备的技术方案与上述的加快游戏应用启动速度方法的技术方案属于同一构思，计算设备的技术方案未详细描述的细节内容，均可以参见上述加快游戏应用启动速度方法的技术方案的描述。

本申请一实施例还提供一种计算机可读存储介质，其存储有计算机指令，该指令被处理器执行时实现如前所述加快游戏应用启动速度方法的步骤。

上述为本实施例的一种计算机可读存储介质的示意性方案。需要说明的是，该存储介质的技术方案与上述的加快游戏应用启动速度方法的技术方案属于同一构思，存储介质的技术方案未详细描述的细节内容，均可以参见上述加快游戏应用启动速度方法的技术方案的描述。

上述对本申请特定实施例进行了描述。其它实施例在所附权利要求书的范围内。在一些情况下，在权利要求书中记载的动作或步骤可以按照不同于实施例中的顺序来执行并且仍然可以实现期望的结果。另外，在附图中描绘的过程不一定要求示出的特定顺序或者连续顺序才能实现期望的结果。在某些实施方式中，多任务处理和并行处理也是可以的或者可能是有利的。

所述计算机指令包括计算机程序代码，所述计算机程序代码可以为源代码形式、对象代码形式、可执行文件或某些中间形式等。所述计算机可读介质可以包括：能够携带所述计算机程序代码的任何实体或装置、记录介质、U盘、移动硬盘、磁碟、光盘、计算机存储器、只读存储器(ROM，Read-Only Memory)、随机存取存储器(RAM，Random Access Memory)、电载波信号、电信信号以及软件分发介质等。需要说明的是，所述计算机可读介质包含的内容可以根据司法管辖区内立法和专利实践的要求进行适当的增减，例如在某些司法管辖区，根据立法和专利实践，计算机可读介质不包括电载波信号和电信信号。

需要说明的是，对于前述的各方法实施例，为了简便描述，故将其都表述为一系列的动作组合，但是本领域技术人员应该知悉，本申请并不受所描述的动作顺序的限制，因为依据本申请，某些步骤可以采用其它顺序或者同时进行。其次，本领域技术人员也应该知悉，说明书中所描述的实施例均属于优选实施例，所涉及的动作和模块并不一定都是本申请所必须的。

在上述实施例中，对各个实施例的描述都各有侧重，某个实施例中没有详述的部分，可以参见其它实施例的相关描述。

以上公开的本申请优选实施例只是用于帮助阐述本申请。可选实施例并没有详尽叙述所有的细节，也不限制该发明仅为所述的具体实施方式。显然，根据本申请的内容，可作很多的修改和变化。本申请选取并具体描述这些实施例，是为了更好地解释本申请的原理和实际应用，从而使所属技术领域技术人员能很好地理解和利用本申请。本申请仅受权利要求书及其全部范围和等效物的限制。