资源的处理方法及装置、存储介质和电子装置与流程

本发明涉及计算机领域，具体而言，涉及一种资源的处理方法及装置、存储介质和电子装置。

背景技术：

网络游戏客户端在渲染游戏画面时，需要从存储设备上，将纹理资源加载到内存中，并转化成可渲染的图像格式，并将数据传递给图形处理器(graphicsprocessingunit，简称为gpu)进行渲染。而从存储设备加载到内存的过程，往往过程很慢，需要游戏开发者对加载过程进行特定的处理和优化，否则可能会导致游戏卡顿、资源加载过慢等不好的体验。

目前，现有技术中常用的资源加载方案有：(1)同步加载，这种方式将资源加载过程放进了游戏主线程进行，使渲染程序能以最快速度得到资源数据。(2)单线程异步加载。这种方式将资源加载过程放进一个指定的线程执行，等资源加载完成后，将数据回传给渲染线程。通过这种方式，渲染线程不能马上得到资源数据，但能大幅减少该线程的计算量。

上述现有技术中的资源加载方案能较好地解决大部分情景下的资源加载问题，但也存在以下弊端：(1)同步加载方式不能在短时间内同时加载过多、过量的资源，否则加载过程堆积在游戏主线程，将会使得游戏主线程产生严重的卡顿现象，游戏体验变差。(2)单线程异步加载若遇到短时间过量的资源加载情况，虽然不会导致主线程卡顿，但是加载速度依然受限于该线程的计算能力和磁盘io速度，导致渲染程序得到资源数据的速度可能会很慢。

针对相关技术中的上述问题，目前尚未存在有效的解决方案。

技术实现要素：

本发明实施例提供了一种资源的处理方法及装置、存储介质和电子装置，以至少解决相关技术中在短时间内将大量资源加载过程放进游戏主线程中进行导致游戏主线程产生卡顿现象的问题。

根据本发明的一个实施例，提供了一种资源的处理方法，包括：将与纹理资源相关的多个任务加载到加载线程池中至少一个加载线程的任务队列中；从所述至少一个加载线程的任务队列中获取待执行任务，并加载所述待执行任务以生成图像数据。

根据本发明的一个实施例，提供了一种资源的处理装置，包括：加载模块，用于将与纹理资源相关的多个任务加载到加载线程池中至少一个加载线程的任务队列中；第一处理模块，用于从所述至少一个加载线程的任务队列中获取待执行任务，并加载所述待执行任务以生成图像数据。

根据本发明的又一个实施例，还提供了一种存储介质，所述存储介质中存储有计算机程序，其中，所述计算机程序被设置为运行时执行上述任一项方法实施例中的步骤。

根据本发明的又一个实施例，还提供了一种电子装置，包括存储器和处理器，所述存储器中存储有计算机程序，所述处理器被设置为运行所述计算机程序以执行上述任一项方法实施例中的步骤。

通过本发明，将多个任务加载到线程池中的至少一个加载线程的任务队列中，使得多个任务可以同时记载，相当于是多线程异步加载，增大了瞬时资源加载的吞吐量，但又不是由主线程进行任务加载，从而解决了在短时间内将大量资源加载过程放进游戏主线程中进行导致游戏主线程产生卡顿现象的问题。

附图说明

此处所说明的附图用来提供对本发明的进一步理解，构成本申请的一部分，本发明的示意性实施例及其说明用于解释本发明，并不构成对本发明的不当限定。在附图中：

图1是根据本发明实施例的资源的处理方法流程图；

图2是根据本发明实施例的代码示意图一；

图3是根据本发明实施例的代码示意图二；

图4是根据本发明实施例的代码示意图三；

图5是根据本发明实施例的代码示意图四；

图6是根据本发明实施例的代码示意图五；

图7是根据本发明实施例的代码示意图六；

图8是根据本发明实施例的代码示意图七；

图9是根据本发明实施例的代码示意图八；

图10是根据本发明实施例的资源的处理装置的结构框图；

图11是根据本发明实施例的资源的处理装置的可选结构框图。

具体实施方式

下文中将参考附图并结合实施例来详细说明本发明。需要说明的是，在不冲突的情况下，本申请中的实施例及实施例中的特征可以相互组合。

需要说明的是，本发明的说明书和权利要求书及上述附图中的术语“第一”、“第二”等是用于区别类似的对象，而不必用于描述特定的顺序或先后次序。

本申请的实施例提供了一种资源的处理方法，图1是根据本发明实施例的资源的处理方法流程图，如图1所示，该流程包括如下步骤：

步骤s102，将与纹理资源相关的多个任务加载到加载线程池中至少一个加载线程的任务队列中；

步骤s104，从至少一个加载线程的任务队列中获取待执行任务，并加载待执行任务以生成图像数据。

通过上述步骤s102和步骤s104，将多个任务加载到线程池中的至少一个加载线程的任务队列中，使得多个任务可以同时记载，相当于是多线程异步加载，增大了瞬时资源加载的吞吐量，但又不是由主线程进行任务加载，从而解决了在短时间内将大量资源加载过程放进游戏主线程中进行导致游戏主线程产生卡顿现象的问题。

需要说明的是，本申请实施例中的方法步骤的执行主体可以终端、服务器等。

此外，在本申请实施例中是根据处理器的核心数确定加载线程池中加载线程的数量。例如，在获取到了用于执行本申请方法步骤的设备的处理器的核心数量后，然后设置本实施例中线程池的加载线程的线程量为处理器核心数量的2倍。当然上述仅仅是举例，也可以是1.5倍或3倍等等，可以根据实际情况进行相应的设置。

在本实施例的可选实施方式中，对于本实施例步骤s104中涉及到的从至少一个加载线程的任务队列中获取待执行任务，并加载待执行任务以生成图像数据的方式，可以通过如下方式来实现：

步骤s104-11，获取当前加载线程的标识信息；

步骤s104-12，根据标识信息确定与当前加载线程对应的任务队列；

步骤s104-13，在当前加载线程对应的任务队列为非空的情况下，从当前加载线程对应的任务队列中获取待执行任务，并加载待执行任务以生成图像数据。

通过上述步骤s104-11至步骤s104-13，对于任务的加载过程，首先需要通过加载线程的标识信息确定与当前加载线程对应的任务队列，只有在任务队列为非空的情况下才会执行加载任务的操作。当然，如果任务队列为空，则让加载线程进入等待状态。

在本实施例的另一个实施方式，在步骤s104从至少一个加载线程的任务队列中获取待执行任务，并加载待执行任务以生成图像数据之后，本实施例的方法还包括：

步骤s106，将生成的图像数据输入至主线程的消费队列中；

需要说明的是，本申请中涉及到的主线程用于负责游戏画面渲染、游戏逻辑执行等相关工作的线程；而加载线程用于负责纹理资源加载任务的线程。

步骤s108，从消费队列中获取不超过预设数量的图像数据以执行纹理生成操作；

需要说明的是，上述步骤s106和步骤s108中涉及到的预设数量为主线程每帧最大能处理的图像数据数量。

可见，对于主线程只需要对基于生成的图像数据进行加载，而不会对纹理资源的多个任务进行加载；而且，由于执行纹理生成操作的图像数据的数量不会超过主线程每帧最大能处理的图像数据数量，避免了主线程的卡顿。

下面结合本实施例的可选实施例对本申请进行举例说明。

在本可选实施例中以本申请在具体应用场景中如何通过优化cocos2dx游戏引擎来实现的方式进行举例说明。

首先，修改引擎cctexturecache模块，支持基于线程池的异步加载。

修改如图2所示的这个类的部分数据结构，其中，

_loadingthreads表示线程池里的所有线程对象；

_asyncstructqueueononethread表示当前某个线程上的加载任务队列；

_asyncstructqueuemutexononethread表示某个线程的任务队列操作互斥器；

_sleepconditionononethread表示某个线程的等待条件变量；

_maxcbperframe表示主线程每帧回调时可以处理的资源量；

_iothreadnum表示当前线程池里的线程量，可以根据实际需求进行设置；

_curthreadidxtoputtask表示下一任务要分配到的线程；

接着修改texturecache::addimageasync函数，如图3所示，149～155行中，当要放入一个新任务时，判断下将要处理这个任务的线程是否已经创建，若没有，则新建一条加载线程，执行texturecache::loadimage函数，并为其创建一个任务队列。166行中，根据参数，生成任务结构。169～172行，将166行生成的任务结构放入该线程的任务队列中。174行，通过条件变量唤醒该线程。176行，修改下一个将要接收任务的线程id。

可见，通过修改这个函数，异步操作请求，将按顺序轮流地放入这些线程中得以执行。

如图4所示，接着修改texturecache::loadimage函数，在函数参数中，我们可以知道当前线程的id，即threadidx。通过这个变量，我们可以拿到该线程的任务队列，并取出第一个任务，进行io加载。若任务队列为空，则让该线程进入等待状态，等待对应的sleepcondtion条件变量发出notify事件。待io加载完成，并生成图像数据后，把图像数据放在主线程的消费队列上，等待主线程生成真正的纹理对象。

如图5所示，接下来修改texturecache::addimageasynccallback函数，由于主线程在每帧的执行时间是有限的，所以不希望主线程在每帧的回调中处理过多的图像数据，导致主线程发生卡顿。因此加入了maxcbperframe，控制每帧最大能处理的图像数据个数。如335～336行，可以通过设置maxcbperframe参数，然后本函数最多执行从图像数据队列中拿不超过maxcbperframe个数据进行纹理生成操作。

如图6所示，添加texturecache::setiothreadnum接口，设置加载线程量。

如图7所示，添加texturecache::setmaxcbperframe接口，设置主线程每帧回调量。

其次，修改脚本异步加载模块，设置线程量和回调量，并用协程封装异步加载接口。

如图8所示，在脚本异步加载模块中，上面的框中的代码，设置了主线程每帧的最大回调量，在下面的框中的代码，先获取了本设备的cpu数量，然后设置了一个2倍于cpu数量的线程量，用于执行异步加载操作。

如图9所示，通过lua语言提供的协程功能，封装好异步加载接口。使得可以通过同步形式的代码编写异步逻辑。

通过以上的实施方式的描述，本领域的技术人员可以清楚地了解到根据上述实施例的方法可借助软件加必需的通用硬件平台的方式来实现，当然也可以通过硬件，但很多情况下前者是更佳的实施方式。基于这样的理解，本发明的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质(如rom/ram、磁碟、光盘)中，包括若干指令用以使得一台终端设备(可以是手机，计算机，服务器，或者网络设备等)执行本发明各个实施例所述的方法。

在本申请的实施例中还提供了一种资源的处理装置，该装置用于实现上述实施例及优选实施方式，已经进行过说明的不再赘述。如以下所使用的，术语“模块”可以实现预定功能的软件和/或硬件的组合。尽管以下实施例所描述的装置较佳地以软件来实现，但是硬件，或者软件和硬件的组合的实现也是可能并被构想的。

图10是根据本发明实施例的资源的处理装置的结构框图，如图10所示，该装置包括：加载模块22，用于将与纹理资源相关的多个任务加载到加载线程池中至少一个加载线程的任务队列中；第一处理模块24，与加载模块22耦合连接，用于从至少一个加载线程的任务队列中获取待执行任务，并加载待执行任务以生成图像数据。

可选地，第一处理模块包括：获取单元，用于获取当前加载线程的标识信息；确定单元，用于根据标识信息确定与当前加载线程对应的任务队列；处理单元，用于在当前加载线程对应的任务队列为非空的情况下，从当前加载线程对应的任务队列中获取待执行任务，并加载待执行任务以生成图像数据。

图11是根据本发明实施例的资源的处理装置的可选结构框图，如图11所示，该装置还包括：输入模块32，与第一处理模块24耦合连接，用于在从至少一个加载线程的任务队列中获取待执行任务，并加载待执行任务以生成图像数据之后，将生成的图像数据输入至主线程的消费队列中；第二处理模块34，与输入模块32耦合连接，用于从消费队列中获取不超过预设数量的图像数据以执行纹理生成操作。

需要说明的是，上述各个模块是可以通过软件或硬件来实现的，对于后者，可以通过以下方式实现，但不限于此：上述模块均位于同一处理器中；或者，上述各个模块以任意组合的形式分别位于不同的处理器中。

本申请的实施例还提供了一种存储介质，该存储介质中存储有计算机程序，其中，该计算机程序被设置为运行时执行上述任一项方法实施例中的步骤。

可选地，在本实施例中，上述存储介质可以被设置为存储用于执行以下步骤的计算机程序：

s1，将与纹理资源相关的多个任务加载到加载线程池中至少一个加载线程的任务队列中；

s2，从至少一个加载线程的任务队列中获取待执行任务，并加载待执行任务以生成图像数据。

可选地，在本实施例中，上述存储介质可以包括但不限于：u盘、只读存储器(read-onlymemory，简称为rom)、随机存取存储器(randomaccessmemory，简称为ram)、移动硬盘、磁碟或者光盘等各种可以存储计算机程序的介质。

本申请的实施例还提供了一种电子装置，包括存储器和处理器，该存储器中存储有计算机程序，该处理器被设置为运行计算机程序以执行上述任一项方法实施例中的步骤。

可选地，上述电子装置还可以包括传输设备以及输入输出设备，其中，该传输设备和上述处理器连接，该输入输出设备和上述处理器连接。

可选地，在本实施例中，上述处理器可以被设置为通过计算机程序执行以下步骤：

s1，将与纹理资源相关的多个任务加载到加载线程池中至少一个加载线程的任务队列中；

s2，从至少一个加载线程的任务队列中获取待执行任务，并加载待执行任务以生成图像数据。

可选地，本实施例中的具体示例可以参考上述实施例及可选实施方式中所描述的示例，本实施例在此不再赘述。

显然，本领域的技术人员应该明白，上述的本发明的各模块或各步骤可以用通用的计算装置来实现，它们可以集中在单个的计算装置上，或者分布在多个计算装置所组成的网络上，可选地，它们可以用计算装置可执行的程序代码来实现，从而，可以将它们存储在存储装置中由计算装置来执行，并且在某些情况下，可以以不同于此处的顺序执行所示出或描述的步骤，或者将它们分别制作成各个集成电路模块，或者将它们中的多个模块或步骤制作成单个集成电路模块来实现。这样，本发明不限制于任何特定的硬件和软件结合。

以上所述仅为本发明的优选实施例而已，并不用于限制本发明，对于本领域的技术人员来说，本发明可以有各种更改和变化。凡在本发明的原则之内，所作的任何修改、等同替换、改进等，均应包含在本发明的保护范围之内。