游戏帧循环的任务处理方法、设备及存储介质与流程

1.本技术涉及引擎技术领域，尤其涉及一种游戏帧循环的任务处理方法、设备及存储介质。


背景技术：

2.游戏运行时，游戏引擎可不断按照游戏逻辑规则运行。游戏程序通过主线程运行一次完整的游戏逻辑，称为完成一次帧循环(或称主循环)。在帧循环中，部分环节可以并行执行从而提升游戏的运行速度。
3.现有技术中，游戏引擎的相关逻辑可被封装成一系列的任务，在每帧逻辑的特定步骤由主线程提交到线程池，并通过阻塞的方式同步等待任务完成，或者用非阻塞的方式查询任务是否执行完毕。这种方式无法高效地实现任务调度。因此，有待提出一种新的解决方案。


技术实现要素：

4.本技术的多个方面提供一种游戏帧循环的任务处理方法、设备及存储介质，用以提任务处理效率。
5.本技术实施例提供一种游戏帧循环的任务处理方法，所述游戏帧循环中，任一帧游戏画面的渲染逻辑被封装为多个任务；游戏引擎包括用于对所述多个任务进行调度的任务系统；所述方法包括：在游戏帧循环过程中，接收第一工作线程提交的第一任务以及所述第一任务对至少一个依赖任务的依赖关系；若所述至少一个依赖任务未执行完毕，则将所述第一任务的状态更新为等待状态；在所述至少一个依赖任务全部执行完毕时，将所述第一任务添加到就绪任务集合中；通过第二工作线程读取所述第一任务，并执行所述第一任务。
6.进一步可选地，接收第一工作线程提交的第一任务，包括：接收所述第一工作线程提交的粒子效果计算任务、骨骼动画处理任务、布料计算任务、遮挡剔除任务、视锥体剔除任务、蒙皮处理任务、静态裁剪任务或者渲染任务。
7.进一步可选地，将所述第一任务的状态更新为等待状态之后，还包括：根据所述至少一个依赖任务的数量，为所述第一任务生成等待计数；在所述至少一个依赖任务全部执行完毕时，将所述第一任务添加到就绪任务集合中，包括：在所述至少一个依赖任务依次执行完毕时，对所述等待计数进行依次递减；在所述等待计数为零时，将所述第一任务添加到就绪任务集合中。
8.进一步可选地，接收第一工作线程提交的第一任务以及所述第一任务对至少一个依赖任务的依赖关系之后，还包括：针对所述至少一个依赖任务中的任一第二任务，在所述第二任务的等待任务列表中，添加所述第一任务；在所述至少一个依赖任务依次执行完毕时，对所述等待计数进行依次递减，包括：在所述第二任务执行完成时，遍历所述第二任务的等待任务列表，确定等待所述第二任务执行完成的所述第一任务，并对所述第一任务的
等待计数进行递减。
9.进一步可选地，接收第一工作线程提交的第一任务之后，还包括：确定所述第一任务的至少一个等待任务；在所述第一任务的等待任务列表中，添加所述至少一个等待任务。
10.进一步可选地，通过第二工作线程读取所述第一任务，并执行所述第一任务，包括：从线程池中，确定未终止的线程作为所述第二工作线程，或者，激活处于空闲状态的线程作为所述第二工作线程；采用所述第二工作线程，从所述就绪任务集合中读取所述第一任务，并执行所述第一任务。
11.进一步可选地，采用所述第二工作线程，从所述就绪任务集合中读取所述第一任务，并执行所述第一任务的过程中，还包括：若需调整所述第一任务的依赖关系，采用所述第二工作线程将所述第一任务以及所述第一任务的新的依赖关系重新提交至所述任务系统。
12.进一步可选地，任务系统接收第一工作线程提交的第一任务之后，还包括：生成所述第一任务的引用计数；采用第三线程确定需提交的第三任务，所述第三任务依赖所述第一任务；在所述第一任务的引用计数不为零时，采用所述第三线程向所述任务系统提交所述第三任务以及所述第三任务对所述第一任务的依赖关系。
13.本技术实施例还提供一种电子设备，包括：存储器和处理器；所述存储器用于存储一条或多条计算机指令；所述处理器用于执行所述一条或多条计算机指令以用于：执行本技术实施例提供的方法中的步骤。
14.本技术实施例还提供一种存储有计算机程序的计算机可读存储介质，计算机程序被处理器执行时能够实现本技术实施例提供的方法中的步骤。
15.本技术实施例还提供一种计算机程序产品，包括计算机程序/指令，当计算机程序被处理器执行时，致使处理器实现本技术实施例提供的方法中的步骤。
16.本技术实施例提供的游戏帧循环的任务处理方法中，游戏引擎中的任务系统接收第一工作线程提交的第一任务以及所述第一任务对至少一个依赖任务的依赖关系后，可在该至少一个依赖任务未执行完毕时，确定第一任务为等待状态。在该至少一个依赖任务全部执行完毕时，将第一任务添加到就绪任务集合中，并通过第二工作线程读取第一任务并执行第一任务。在这种实施方式中，工作线程可通过任务系统根据任务的依赖关系挂起任务，并通过任务系统根据任务的依赖关系判断何时重新激活任务，实现了工作线程可实现任务的调度，降低了对主线程的依赖，减少了主线程与其他工作线程的交互次数并降低了主线程的阻塞情况，提升了任务的处理效率。
附图说明
17.此处所说明的附图用来提供对本技术的进一步理解，构成本技术的一部分，本技术的示意性实施例及其说明用于解释本技术，并不构成对本技术的不当限定。在附图中：
18.图1为本技术一示例性实施例提供的游戏帧循环的任务处理方法的流程示意图；
19.图2为本技术另一示例性实施例提供的任务状态更新示意图；
20.图3为本技术一示例性实施例提供的任务系统的架构示意图；
21.图4为本技术一示例性实施例提供的电子设备的结构示意图。
具体实施方式
22.为使本技术的目的、技术方案和优点更加清楚，下面将结合本技术具体实施例及相应的附图对本技术技术方案进行清楚、完整地描述。显然，所描述的实施例仅是本技术一部分实施例，而不是全部的实施例。基于本技术中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本技术保护的范围。
23.游戏运行时，游戏引擎可不断按照游戏逻辑规则运行。游戏程序通过主线程运行一次完整的游戏逻辑，称为完成一次帧循环。在帧循环中，部分环节可以并行执行从而提升游戏的运行速度。
24.现有技术中，游戏引擎的相关逻辑可被封装成一系列的任务，在每帧逻辑的特定步骤由主线程提交到对应的线程，并通过阻塞的方式同步等待任务完成，或者用非阻塞的方式查询任务是否执行完毕。当任务之间的关系较为复杂时，无法高效地实现任务调度。
25.针对上述技术问题，在本技术一些实施例中，提供了一种解决方案，以下结合附图，详细说明本技术各实施例提供的技术方案。
26.图1为本技术一示例性实施例提供的游戏帧循环的任务处理方法的流程示意图，如图1所示，该方法包括：
27.步骤101、在游戏帧循环过程中，接收第一工作线程提交的第一任务以及所述第一任务对至少一个依赖任务的依赖关系；所述第一任务为任一帧游戏画面的渲染逻辑封装得到的多个任务中的任一任务。
28.步骤102、若所述至少一个依赖任务未执行完毕，则将所述第一任务的状态更新为等待状态。
29.步骤103、在所述至少一个依赖任务全部执行完毕时，将所述第一任务添加到就绪任务集合中。
30.步骤104、通过第二工作线程读取所述第一任务，并执行所述第一任务。
31.本实施例由游戏引擎中的任务系统执行，该任务系统作为游戏引擎中的基础模块，可被游戏引擎中的其他组件调用，用于执行任务同步以及任务调度相关的逻辑。
32.在游戏运行的过程中，在主线程上运行一次完整的游戏逻辑,称为完成一次帧循环。在每一次帧循环中，游戏引擎可按照游戏逻辑规则，处理用户输入、处理定时事件、绘图等一系列操作。一次循环可视为渲染一帧游戏画面(绘图)的过程，多次循环可执行多次绘图操作，从而保持游戏进行，直至游戏结束。
33.在游戏帧循环的过程中，为并行执行任一帧游戏画面的渲染逻辑，可将任一帧游戏画面的渲染逻辑封装为多个任务。一帧游戏画面的渲染逻辑可包括多个计算步骤，将多个计算步骤对应的运行逻辑分别封装为任务后，可采用多个工作线程并行执行该任务，以提升一帧游戏画面的渲染效率。
34.在一些可选的实施例中，可按照帧循环逻辑，将任一帧游戏画面的渲染逻辑封装为粒子效果计算任务、骨骼动画处理任务、布料计算任务、遮挡剔除任务、视锥体剔除任务、蒙皮处理任务、静态裁剪任务或者渲染任务中的至少一种，本实施例不做限制。本实施例中被提交的第一任务，可以是上述任务中的任意一种任务。
35.基于本实施例提供的任务系统，任意的工作线程可提交任务以及任务的依赖关系。其中，工作线程指的是除主线程外，用于执行实际工作任务的线程。工作线程可包括子
线程，也可包括具有特定功能的线程，例如渲染线程或主线程等。接收到任务时，任务系统可根据任务的依赖关系，判断是否挂起该任务，并在任务具备执行条件时，将该任务作为就绪任务继续执行。在本实施例中，向任务系统提交任务的工作线程以及最终执行任务的工作线程，可以是同一个子线程也可以是不同的子线程。
36.在任务系统中，任务之间的依赖关系会与任务一起提交。其中，任务之间的依赖关系是指，某些任务需要等待另一些任务执行完毕之后方可执行。前者为后者的依赖任务，后者为前者的等待任务。例如，任务c为例，当任务c需要在任务a以及任务b执行完毕之后方可执行，那么任务a、任务b为任务c的依赖任务，任务c为任务a以及任务b的等待任务。
37.例如，在游戏应用场景中，游戏的每帧相关逻辑，如物体的可视性剔除、更新、渲染等任务可构成若干组有逻辑依赖关系的任务。例如，可视性剔除任务为更新任务的依赖任务，更新任务为可视性剔除任务的等待任务；更新任务为渲染任务的依赖任务，渲染任务为更新任务的等待任务。
38.在本实施例中，为便于任务调度以及管理，将任务的状态划分为多个状态：未提交状态、等待状态、就绪状态、执行中状态以及执行完毕状态。本实施例中，以任务系统接收到的第一任务为例进行示例性说明。其中，第一任务为任务系统接收到的待处理的任一任务。在本实施例中，采用“第一”对任务进行限定，仅用于方便描述和区分，对任务的接收顺序以及数量并不构成限制。
39.第一任务未被提交时，处于未提交状态。第一任务被提交到任务系统时，同时提交了第一任务的至少一个依赖任务，任务系统可判断该至少一个依赖任务是否执行完毕。若未执行完毕，则第一任务需等待其他任务执行完毕之后方可执行。在这种情况下，可任务的状态更新为等待状态。在等待状态下的任务，可视为被挂起的任务。当该至少一个依赖任务全部执行完毕时，可将第一任务添加至就绪任务集合中，此时第一任务的状态将更新为就绪状态。当处于就绪状态时，线程池中的工作线程，可从就绪任务集合中取出第一任务，并执行第一任务。
40.在本实施例中，游戏引擎中的任务系统接收第一工作线程提交的第一任务以及所述第一任务对至少一个依赖任务的依赖关系后，可在该至少一个依赖任务未执行完毕时，确定第一任务为等待状态。在该至少一个依赖任务全部执行完毕时，将第一任务添加到就绪任务集合中，并通过第二工作线程读取第一任务并执行第一任务。在这种实施方式中，工作线程可通过任务系统根据任务的依赖关系挂起任务，并通过任务系统根据任务的依赖关系判断何时重新激活任务，实现了工作线程可实现任务的调度，降低了对主线程的依赖，减少了主线程与其他工作线程的交互次数并降低了主线程的阻塞情况，提升了任务的处理效率。
41.在一些可选的实施例中，为便于对任务进行管理，任务系统可为每个任务生成等待计数。其中，等待计数，用于描述每个任务需等待执行完成的其他任务数量。该等待计数，可在任务系统接收到每个任务的依赖关系时生成。继续以第一任务为例，可选地，第一任务被提交到任务系统时，同时提交了第一任务的至少一个依赖任务。任务系统将所述第一任务的状态更新为等待状态之后，任务系统可从第一任务的依赖关系中，确定第一任务对应的至少一个依赖任务的数量，并根据该至少一个依赖任务的数量，为第一任务生成等待计数。
42.例如，任务c被提交至任务系统时，同时提交任务c的依赖关系为：任务c依赖任务a以及任务b。根据该任务依赖关系，可生成第一任务的等待计数为2。即，任务c需要在两个任务完成后方可执行。
43.确定第一任务依赖的至少一个依赖任务后，任务系统可在该至少一个依赖任务依次执行完毕时，对第一任务的等待计数进行递减。继续沿用前述例子，当任务a执行完毕时，可对任务c的等待计数减1，当任务b执行完毕时，可对任务c的等待计数减1。
44.当第一任务的等待计数为零时，任务系统可将该第一任务添加到就绪任务集合中等待执行。其中，就绪任务集合，用于存放处于就绪状态的任务，该就绪状态的任务可被分配给任一空闲的子线程进行执行。
45.在一些示例性的实施例中，任务系统除可维护每一任务的等待计数之外，还可为每一任务维护一等待任务列表。其中，该等待任务列表用于记录等待该任务完成的其他任务。当该任务完成后，可遍历改该任务的等待任务列表，并对等待任务列表中的每个任务的等待计数进行递减。
46.基于此，在一些实施例中，接收第一工作线程提交的第一任务以及第一任务对至少一个依赖任务的依赖关系之后，针对该至少一个依赖任务中的任一第二任务，在第二任务的等待任务列表中，添加第一任务。其中，第二任务用于表示第一任务的任意一个依赖任务。通过执行该步骤，任务系统可将第一任务记录在其需要等待的任一依赖任务的等待列表中。
47.相应地，任务系统在该至少一个依赖任务依次执行完毕时，对第一任务的等待计数进行递减时，可在第二任务执行完成时，遍历第二任务的等待任务列表，确定等待第二任务完成的第一任务，并对第一任务的等待计数进行递减。
48.基于沿用前述例子，任务c被提交至任务系统时，同时提交任务c的依赖关系为：任务c依赖任务a以及任务b。任务系统可在任务a的等待任务列表中添加任务c，并可在任务b的等待列表中添加任务c。当任务a执行完毕后，可在遍历任务a的等待任务列表确定任务c，并对任务c的等待计数减1；同理，当任务b执行完毕后，可在遍历任务b的等待任务列表确定任务c，并对任务c的等待计数减1。
49.在这种实施方式中，通过被依赖任务的等待任务列表以及对其他任务具有依赖性的任务的等待计数，任务系统可实现具有依赖关系的任务的调度以及执行结果的通知。
50.针对第一任务而言，在一些情况下，会存在一个或者多个依赖第一任务的其他任务，在本实施例中，将依赖第一任务的其他任务描述为第一任务的等待任务。
51.在一些示例性的实施例中，接收第一工作线程提交的第一任务之后，任务系统可确定第一任务的至少一个等待任务。其中，该至少一个等待任务中，任一等待任务与第一任务之间的依赖关系，可以由该等待任务在提交任务的同时获取到。即，对于任务a而言，当任务c提交时一并提交了任务c对任务a的依赖关系，则可确定任务c为任务a的等待任务。确定第一任务的至少一个等待任务后，可在第一任务的等待任务列表中，添加该至少一个等待任务。
52.在一些示例性的实施例中，将第一任务添加到就绪任务集合中等待执行之后，任务系统还可在第一任务执行完毕时，遍历第一任务的等待任务列表中的该至少一个等待任务，并对所述至少一个等待任务各自的等待计数进行递减。
53.例如，承接上述例子，对于任务a而言，任务a的等待任务列表中，包含任务b以及任务c。当任务a执行完毕时，任务系统可遍历任务的a的等待任务列表，对任务b的等待计数减1，并对任务c的等待计数减1。
54.在一些示例性的实施例中，通过第二工作线程读取第一任务，并执行第一任务时，任务系统可从线程池中，确定未终止的线程作为第二工作线程，或者，激活处于空闲状态的线程作为第二工作线程，并采用第二工作线程，从就绪任务集合中读取所述第一任务，并执行第一任务。
55.值得说明的是，在本实施例中，每个线程在执行任务的过程中，若需调整所述第一任务的依赖关系，则该线程可向任务系统重新提交该任务。继续以第二工作线程和第一任务为例进行说明。可选地，采用第二工作线程，从就绪任务集合中读取第一任务，并执行第一任务之后，若需根据第一任务的某一阶段的执行结果调整第一任务的依赖关系，则可采用第二工作线程将第一任务以及第一任务的依赖关系重新提交至任务系统。任务系统可根据第二工作线程提交的第一任务以及依赖关系，重新确定第一任务的状态，不再赘述。
56.还值得说明的时，在本实施例中，可为任一提交到任务池的任务设置引用计数，并通过引用计数控制任务的生命周期。引用计数，用于保存任务被引用的次数。任务系统将任一任务提交到任务池时，可将该任务的引用计数加1，当任务完全执行完毕时，将该引用计数减1。
57.当任务的引用计数为0时，可释放任务。对于任务系统的外部系统(例使用该任务的外部模块)而言，只需根据任务的引用计数决定是否释放该任务，无需考虑该任务具体处于哪一执行阶段。从而，进一步实现了任务调度与外部系统的解耦。
58.基于任务的引用计数的描述可知，对外部系统而言，无需考虑任务当前处于何种状态，当任务的引用计数不为零时，意味着该任务未被释放，进而该任务可作为被依赖的任务添加到其他任务提交时的依赖任务集合中。
59.继续以第一任务为例，任务系统接收第一工作线程提交的第一任务之后，可生成第一任务的引用计数。当存在需要提交的第三任务时，可采用第三线程确定需提交的第三任务，该第三任务依赖所述第一任务。第三线程可在第一任务的引用计数不为零时，向任务系统提交第三任务以及第三任务对第一任务的依赖关系。
60.可选地，在本实施例中，可定义类型frametask作为游戏引擎帧逻辑相关任务的基类型。frametask基类中封装了与任务调度相关的逻辑，同时提供了虚函数接口executeimpl。对于具体的引擎逻辑，可从frametask类型派生出相应的任务类型，然后将其在派生类型的executeimpl成员函数中实现。
61.frametask的生命期控制采用引用计数的方式解决。每个frametask内部包含一个refcount计数，并提供addrefcount和subrefcount来增加和减少计数。当调用subrefcount将引用计数减少到0时将实际删除该task实例。当frametask及其子类的实例在初始时计数为1，在每个任务提交时，任务系统会将它的引用计数加1，当任务完全执行完毕时再减1。
62.以下将结合图2，对本技术的上述各实施例进行进一步示例性说明。
63.如图2所示，在任务系统中，任务可包括以下几个状态：未提交状态、等待状态、就绪状态、执行中状态以及执行完毕状态。
64.其中，未提交状态是任务的初始状态，当一个任务对象新创建时就处于这个状态。
当任务执行完毕之后，外部模块可以通过重置操作将该任务重置为未提交状态，从而可以重用该任务对象处理下一个同类型任务。
65.对于一个处于未提交状态的任务，任一线程可以通过提交操作可以将其提交给任务系统。在本实施例中，frametask基类的静态成员函数中，包括submittosystem(提交至系统)函数。因此，线程可通过调submittosystem向任务系统提交任务。其中，任务的依赖关系需与任务一同提交，而不能单独设置某个任务与其他任务的依赖关系。从而，可避免了外部模块直接为一个已经在执行中的任务添加新的依赖任务，从而造成逻辑混乱。
66.在提交任务时，可首先遍历传入的当前任务的依赖任务列表，对于依赖任务列中已执行完毕的任务不做任何处理；对于依赖任务列中尚未执行完毕的任务，可将当前任务加入该任务的等待列表，并将当前任务的等待计数加1。完成遍历后，若当前任务的等待计数为0，则将当前任务的状态更新为就绪状态，并将当前任务加入到任务系统的就绪任务集合中。若当前任务的等待计数不为0，则将当前任务的状态更新为等待状态。若对于等待状态的当前任务而言，在当前任务等待的最后一个任务执行完毕后，当前任务的等待计数会减到0，此时当前任务可进入就绪状态。
67.进入就绪状态的任务会被添加到任务系统的就绪任务集合中，线程池中的各个运行着的线程可交替从就绪任务集合中取出就绪任务来执行。当有新的就绪任务产生时，任务系统可查询当前是否存在空闲的线程，若存在，则激活空闲线程来执行新的就绪任务，从而平衡负载。
68.当就绪任务被线程池中的线程取出执行时，该任务进入执行中状态。线程可调用任务对应的基类frametask的execute(执行)成员函数，execute函数内部可调用executeimpl接口，以处理任务相关逻辑。
69.其中，executeimpl接口根据具体逻辑由继承类分别实现，当其返回值为true(假)时，则确认任务实际执行完毕，线程可继续处理就绪列表中的其他任务；若返回值为false(真)，则线程需要重新将任务提交给任务系统，由任务系统根据该任务新的依赖任务决定该任务将进入就绪状态或等待状态。
70.在本实施例中，任务系统允许在任何线程上执行任务提交操作，因此，可在executeimpl函数内部返回false之前执行任务的重新提交操作。从而，可以达到在任务执行过程中根据执行的结果来调整整个任务树局部结构的目的。
71.当任务执行完毕之后，任务的状态会到达执行完毕状态，此时任务系统将释放所持有的该任务的引用计数。若外部不再持有该任务对象的引用计数，该任务对象将被销毁。当任务处于执行完毕状态时，该任务可被重置，以用于执行其他同类型的任务。
72.其中，任务系统为全局变量，系统内部包含就绪任务集合以及线程对象集合等部分。任务系统的主要接口可包括：
73.beginwork开始工作，仅程序初始化时调用。endwork结束工作，仅程序关闭时调用。commitreadytask提交一个就绪任务，由任务对象调用fetchreadytask取出一个就绪任务，由线程对象调用。
74.任务系统的结构可如图3所示，其中，线程对象封装了线程控制和任务调度的功能。在本实施例中，尽管任务系统本身是全局唯一的，但是并不存在一个全局唯一的任务调
度环节。在任务系统中，每个线程对象都可作为一个任务调度的单元。基于这种实施方式，将原本集中在一个特定线程上的阻塞分摊到其他线程上，避免了各个工作线程频繁与主线程或者一个特定的任务调度线程发生同步或互斥操作，导致某个特定的线程阻塞过多的缺陷。
75.其中，线程对象的主要接口可包括：
[0076][0077][0078]
其中，线程对象接口可由线程对象自身以及和任务系统调用。从而确保了线程的激活和挂起可按照固定的流程执行，线程对象的内部变量如激活标志则无需加锁访问，也能一定程度上提升运行效率。
[0079]
在本实施例中，基于线程池的任务调度系统，可实现异步任务调度，降低了上层逻辑模块和任务系统的耦合度，上层逻辑模块只需执行任务的创建自以及结束操作，不必直接处理线程和任务的调度。其中，线程池中的每个线程都可以提交任务，任务执行的流程中线程也可以提交其他任务，可以支持更复杂的上层逻辑。其中，线程在提交任务时，将任务本身和任务的依赖关系同时提交，任务的执行和依赖关系的处理都可在工作线程中执行，减少了与主线程与其他线程的交互次数。除此之外，任务系统还可允许每个任务在接口参数中指定其运行的线程，也可不作指定由系统自动分配运行的线程，在灵活调度任务的同时也可保证对线程局部变量的正确访问。
[0080]
需要说明的是，上述实施例所提供方法的各步骤的执行主体均可以是同一设备，或者，该方法也由不同设备作为执行主体。比如，步骤101至步骤104的执行主体可以为设备a；又比如，步骤101和102的执行主体可以为设备a，步骤103的执行主体可以为设备b；等等。
[0081]
另外，在上述实施例及附图中的描述的一些流程中，包含了按照特定顺序出现的多个操作，但是应该清楚了解，这些操作可以不按照其在本文中出现的顺序来执行或并行执行，操作的序号如101、102等，仅仅是用于区分开各个不同的操作，序号本身不代表任何的执行顺序。另外，这些流程可以包括更多或更少的操作，并且这些操作可以按顺序执行或并行执行。需要说明的是，本文中的“第一”、“第二”等描述，是用于区分不同的消息、设备、模块等，不代表先后顺序，也不限定“第一”和“第二”是不同的类型。
[0082]
图4是本技术一示例性实施例提供的电子设备的结构示意图，该电子设备适用于执行前述实施例提供的任务处理方法。电子设备中运行有游戏引擎，游戏帧循环中，任一帧游戏画面的渲染逻辑被封装为多个任务，游戏引擎包括用于对所述多个任务进行调度的任务系统。如图4所示，该电子设备包括：存储器401、处理器402以及通信组件403。
[0083]
存储器401，用于存储计算机程序，并可被配置为存储其它各种数据以支持在电子设备上的操作。这些数据的示例包括用于在电子设备上操作的任何应用程序或方法的指令，联系人数据，电话簿数据，消息，图片，视频等。
[0084]
其中，存储器401可以由任何类型的易失性或非易失性存储设备或者它们的组合实现，如静态随机存取存储器(sram)，电可擦除可编程只读存储器(eeprom)，可擦除可编程只读存储器(eprom)，可编程只读存储器(prom)，只读存储器(rom)，磁存储器，快闪存储器，磁盘或光盘。
[0085]
处理器402，与存储器401耦合，用于执行存储器401中的计算机程序，以用于：在游戏帧循环过程中，接收第一工作线程提交的第一任务以及所述第一任务对至少一个依赖任务的依赖关系；若所述至少一个依赖任务未执行完毕，则将所述第一任务的状态更新为等待状态；在所述至少一个依赖任务全部执行完毕时，将所述第一任务添加到就绪任务集合中；通过第二工作线程读取所述第一任务，并执行所述第一任务。
[0086]
进一步可选地，处理器402在接收第一工作线程提交的第一任务，包括：接收所述第一工作线程提交的粒子效果计算任务、骨骼动画处理任务、布料计算任务、遮挡剔除任务、视锥体剔除任务、蒙皮处理任务、静态裁剪任务或者渲染任务。
[0087]
进一步可选地，处理器402在将所述第一任务的状态更新为等待状态之后，还用于：根据所述至少一个依赖任务的数量，为所述第一任务生成等待计数。
[0088]
进一步可选地，处理器402在在所述至少一个依赖任务全部执行完毕时，将所述第一任务添加到就绪任务集合中时，具体用于：在所述至少一个依赖任务依次执行完毕时，对所述等待计数进行依次递减；在所述等待计数为零时，将所述第一任务添加到就绪任务集合中。
[0089]
进一步可选地，处理器402在接收第一工作线程提交的第一任务以及所述第一任务对至少一个依赖任务的依赖关系之后，还用于：针对所述至少一个依赖任务中的任一第二任务，在所述第二任务的等待任务列表中，添加所述第一任务；在所述至少一个依赖任务依次执行完毕时，对所述等待计数进行依次递减，包括：在所述第二任务执行完成时，遍历所述第二任务的等待任务列表，确定等待所述第二任务执行完成的所述第一任务，并对所述第一任务的等待计数进行递减。
[0090]
进一步可选地，处理器402在接收第一工作线程提交的第一任务之后，还用于：确定所述第一任务的至少一个等待任务；在所述第一任务的等待任务列表中，添加所述至少一个等待任务。
[0091]
进一步可选地，处理器402在通过第二工作线程读取所述第一任务，并执行所述第一任务时，具体用于：从线程池中，确定未终止的线程作为所述第二工作线程，或者，激活处于空闲状态的线程作为所述第二工作线程；采用所述第二工作线程，从所述就绪任务集合中读取所述第一任务，并执行所述第一任务。
[0092]
进一步可选地，处理器402采用所述第二工作线程，从所述就绪任务集合中读取所
述第一任务，并执行所述第一任务的过程中，还用于：若需调整所述第一任务的依赖关系，采用所述第二工作线程将所述第一任务以及所述第一任务的新的依赖关系重新提交至所述任务系统。
[0093]
进一步可选地，处理器402任务系统接收第一工作线程提交的第一任务之后，还用于：生成所述第一任务的引用计数；采用第三线程确定需提交的第三任务，所述第三任务依赖所述第一任务；在所述第一任务的引用计数不为零时，采用所述第三线程向所述任务系统提交所述第三任务以及所述第三任务对所述第一任务的依赖关系。
[0094]
进一步，如图4所示，该电子设备还包括：显示组件404、电源组件405、音频组件406等其它组件。图4中仅示意性给出部分组件，并不意味着电子设备只包括图4所示组件。
[0095]
其中，通信组件403被配置为便于通信组件所在设备和其他设备之间有线或无线方式的通信。通信组件所在设备可以接入基于通信标准的无线网络，如wifi，2g、3g、4g或5g，或它们的组合。在一个示例性实施例中，通信组件经由广播信道接收来自外部广播管理系统的广播信号或广播相关信息。在一个示例性实施例中，通信组件可基于近场通信(nfc)技术、射频识别(rfid)技术、红外数据协会(irda)技术、超宽带(uwb)技术、蓝牙(bt)技术和其他技术来实现。
[0096]
其中，显示组件404包括屏幕，其屏幕可以包括液晶显示组件(lcd)和触摸面板(tp)。若屏幕包括触摸面板，屏幕可以被实现为触摸屏，以接收来自用户的输入信号。触摸面板包括一个或多个触摸传感器以感测触摸、滑动和触摸面板上的手势。所述触摸传感器可以不仅感测触摸或滑动动作的边界，而且还检测与所述触摸或滑动操作相关的持续时间和压力。
[0097]
其中，电源组件405，为电源组件所在设备的各种组件提供电力。电源组件可以包括电源管理系统，一个或多个电源，及其他与为电源组件所在设备生成、管理和分配电力相关联的组件。
[0098]
其中，音频组件406，可被配置为输出和/或输入音频信号。例如，音频组件包括一个麦克风(mic)，当音频组件所在设备处于操作模式，如呼叫模式、记录模式和语音识别模式时，麦克风被配置为接收外部音频信号。所接收的音频信号可以被进一步存储在存储器或经由通信组件发送。在一些实施例中，音频组件还包括一个扬声器，用于输出音频信号。
[0099]
本实施例中，游戏引擎中的任务系统接收第一工作线程提交的第一任务以及所述第一任务对至少一个依赖任务的依赖关系后，可在该至少一个依赖任务未执行完毕时，确定第一任务为等待状态。在该至少一个依赖任务全部执行完毕时，将第一任务添加到就绪任务集合中，并通过第二工作线程读取第一任务并执行第一任务。在这种实施方式中，工作线程可通过任务系统根据任务的依赖关系挂起任务，并通过任务系统根据任务的依赖关系判断何时重新激活任务，实现了工作线程可实现任务的调度，降低了对主线程的依赖，减少了主线程与其他工作线程的交互次数并降低了主线程的阻塞情况，提升了任务的处理效率。
[0100]
相应地，本技术实施例还提供一种存储有计算机程序的计算机可读存储介质，计算机程序被执行时能够实现上述方法实施例中可由电子设备执行的各步骤。
[0101]
相应地，本技术实施例还提供一种计算机程序产品，包括计算机程序/指令，当计算机程序被处理器执行时，致使处理器实现本技术实施例提供的方法中的步骤。
[0102]
本领域内的技术人员应明白，本发明的实施例可提供为方法、系统、或计算机程序产品。因此，本发明可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且，本发明可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、cd-rom、光学存储器等)上实施的计算机程序产品的形式。
[0103]
本发明是参照根据本发明实施例的方法、设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。
[0104]
这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。
[0105]
这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上，使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。
[0106]
在一个典型的配置中，计算设备包括一个或多个处理器(cpu)、输入/输出接口、网络接口和内存。
[0107]
内存可能包括计算机可读介质中的非永久性存储器，随机存取存储器(ram)和/或非易失性内存等形式，如只读存储器(rom)或闪存(flash ram)。内存是计算机可读介质的示例。
[0108]
计算机可读介质包括永久性和非永久性、可移动和非可移动媒体可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其他数据。计算机的存储介质的例子包括，但不限于相变内存(pram)、静态随机存取存储器(sram)、动态随机存取存储器(dram)、其他类型的随机存取存储器(ram)、只读存储器(rom)、电可擦除可编程只读存储器(eeprom)、快闪记忆体或其他内存技术、只读光盘只读存储器(cd-rom)、数字多功能光盘(dvd)或其他光学存储、磁盒式磁带，磁盘存储或其他磁性存储设备或任何其他非传输介质，可用于存储可以被计算设备访问的信息。按照本文中的界定，计算机可读介质不包括暂存电脑可读媒体(transitory media)，如调制的数据信号和载波。
[0109]
还需要说明的是，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、商品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、商品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个
……”
限定的要素，并不排除在包括所述要素的过程、方法、商品或者设备中还存在另外的相同要素。
[0110]
以上所述仅为本技术的实施例而已，并不用于限制本技术。对于本领域技术人员来说，本技术可以有各种更改和变化。凡在本技术的精神和原理之内所作的任何修改、等同
替换、改进等，均应包含在本技术的权利要求范围之内。

技术特征：
1.一种游戏帧循环的任务处理方法，其特征在于，所述游戏帧循环中，任一帧游戏画面的渲染逻辑被封装为多个任务；游戏引擎包括用于对所述多个任务进行调度的任务系统；所述方法包括：在游戏帧循环过程中，接收第一工作线程提交的第一任务以及所述第一任务对至少一个依赖任务的依赖关系；若所述至少一个依赖任务未执行完毕，则将所述第一任务的状态更新为等待状态；在所述至少一个依赖任务全部执行完毕时，将所述第一任务添加到就绪任务集合中；通过第二工作线程读取所述第一任务，并执行所述第一任务。2.根据权利要求1所述的方法，其特征在于，接收第一工作线程提交的第一任务，包括：接收所述第一工作线程提交的粒子效果计算任务、骨骼动画处理任务、布料计算任务、遮挡剔除任务、视锥体剔除任务、蒙皮处理任务、静态裁剪任务或者渲染任务。3.根据权利要求1所述的方法，其特征在于，将所述第一任务的状态更新为等待状态之后，还包括：根据所述至少一个依赖任务的数量，为所述第一任务生成等待计数；在所述至少一个依赖任务全部执行完毕时，将所述第一任务添加到就绪任务集合中，包括：在所述至少一个依赖任务依次执行完毕时，对所述等待计数进行依次递减；在所述等待计数为零时，将所述第一任务添加到就绪任务集合中。4.根据权利要求3所述的方法，其特征在于，接收第一工作线程提交的第一任务以及所述第一任务对至少一个依赖任务的依赖关系之后，还包括：针对所述至少一个依赖任务中的任一第二任务，在所述第二任务的等待任务列表中，添加所述第一任务；在所述至少一个依赖任务依次执行完毕时，对所述等待计数进行依次递减，包括：在所述第二任务执行完成时，遍历所述第二任务的等待任务列表，确定等待所述第二任务执行完成的所述第一任务，并对所述第一任务的等待计数进行递减。5.根据权利要求1所述的方法，其特征在于，接收第一工作线程提交的第一任务之后，还包括：确定所述第一任务的至少一个等待任务；在所述第一任务的等待任务列表中，添加所述至少一个等待任务。6.根据权利要求3所述的方法，其特征在于，通过第二工作线程读取所述第一任务，并执行所述第一任务，包括：从线程池中，确定未终止的线程作为所述第二工作线程，或者，激活处于空闲状态的线程作为所述第二工作线程；采用所述第二工作线程，从所述就绪任务集合中读取所述第一任务，并执行所述第一任务。7.根据权利要求6所述的方法，其特征在于，采用所述第二工作线程，从所述就绪任务集合中读取所述第一任务，并执行所述第一任务的过程中，还包括：若需调整所述第一任务的依赖关系，采用所述第二工作线程将所述第一任务以及所述第一任务的新的依赖关系重新提交至所述任务系统。8.根据权利要求1-7任一项所述的方法，其特征在于，任务系统接收第一工作线程提交的第一任务之后，还包括：
生成所述第一任务的引用计数；采用第三线程确定需提交的第三任务，所述第三任务依赖所述第一任务；在所述第一任务的引用计数不为零时，采用所述第三线程向所述任务系统提交所述第三任务以及所述第三任务对所述第一任务的依赖关系。9.一种电子设备，其特征在于，包括：存储器和处理器；所述存储器用于存储一条或多条计算机指令；所述处理器用于执行所述一条或多条计算机指令以用于：执行权利要求1-8任一项所述的方法中的步骤。10.一种存储有计算机程序的计算机可读存储介质，其特征在于，计算机程序被处理器执行时能够实现权利要求1-8任一项所述的方法中的步骤。11.一种计算机程序产品，包括计算机程序/指令，其特征在于，当计算机程序被处理器执行时，致使处理器实现权利要求1-8任一项所述方法中的步骤。

技术总结
本申请实施例提供一种游戏帧循环的任务处理方法、设备及存储介质。游戏引擎中的任务系统接收第一工作线程提交的第一任务以及所述第一任务对至少一个依赖任务的依赖关系后，可在该至少一个依赖任务未执行完毕时，确定第一任务为等待状态。在该至少一个依赖任务全部执行完毕时，将第一任务添加到就绪任务集合中，并通过第二工作线程读取第一任务并执行第一任务。在这种实施方式中，工作线程可通过任务系统根据任务的依赖关系挂起任务，并通过任务系统根据任务的依赖关系判断何时重新激活任务，实现了工作线程可实现任务的调度，降低了对主线程的依赖，减少了主线程与其他工作线程的交互次数并降低了主线程的阻塞情况，提升了任务的处理效率。了任务的处理效率。了任务的处理效率。


技术研发人员：胡梓楠
受保护的技术使用者：完美世界互动（北京）科技有限公司
技术研发日：2021.12.03
技术公布日：2022/3/8