1.UE4源码剖析——异步与并行 中篇 之 Thread
2.源代码与伪代码的源码区别
3.Async、Await 从源码层面解析其工作原理

UE4源码剖析——异步与并行 中篇 之 Thread

       我们知道UE中的源码异步框架分为TaskGraph与Thread两种，上篇教程我们学习了TaskGraph，源码它擅长处理有依赖关系的源码短任务；本篇教程我们将学习Thread，它与TaskGraph相反，源码它更擅长于处理长任务。源码分期首付源码而下一篇文章，源码我们则会承接Thread，源码去学习一下引擎中一些重要的源码线程。

       Thread擅长处理长任务，源码从长任务生命周期这个层面来看，源码我们可以先把长任务分为两类：常驻型长任务与非常驻型长任务。源码

       常驻型长任务侧重于并行，源码通常用于监听式服务，源码例如网络传输，源码使用单独的线程对网络进行监听，每当有网络数据包到达时，源码计算补码线程接收并处理后，不会立即结束，而是重置部分状态，继续监听，等待下一轮数据包。

       非常驻型长任务侧重于异步，通常用于数据处理，例如主线程为了提高性能，避免卡顿，会将一些重负载的运算任务分发给分线程处理，可能分批给多条分线程，主线程继续运行其他逻辑。任务处理完成后，将结果返回给主线程，分线程可销毁。

       接下来，Centertrack源码分析我们通过两个例子学习Thread的使用。

       计算由N到M（N和M为大数字）所有数字的和。使用Thread异步调用，将计算操作交由分线程执行，计算完成后再通知主线程结果，代码实现如下：

       逻辑分为两部分：启动分线程计算数字和，使用Async函数，参数为EAsyncExecution::Thread，创建新线程执行。学习Async函数用法，该函数返回TFuture对象，代表未来状态，当前无法获取结果，但在未来某个时刻状态变为Ready，此时可通过TFuture获取结果。

       主线程注册回调，ospf源码解析等待分线程计算完成，使用TFuture的Then函数，完成时触发注册的回调，也可使用Wait系列函数等待计算完成。

       接下来学习常驻型任务使用。

       定义玩家血量上限点，当前点，当血量未满时，每0.2秒恢复1点血量。代码实现分为创建生命治疗仪FRunnable对象、重写Run函数、创建FRunnableThread线程、测试恢复功能和释放线程资源。

       生命治疗仪创建与测试完整代码如下，可验证生命恢复功能和暂停与恢复。

       UE4中的exe劫持源码FRunnable与FRunnableThread提供创建常驻型任务所需接口。无论是常驻型还是非常驻型，底层实现相同，都是使用FRunnableThread线程。

       FRunnableThread线程结构包含标识符、逻辑功能、效率与性能、辅助调试字段。线程创建与生命周期分为创建FRunnable类对象、创建FRunnableThread对象两步，通过FRunnable的生命周期管理实现线程运行与停止。

       UE4线程管理流程包括继承并创建FRunnable类对象、创建FRunnableThread对象，生命治疗仪线程创建代码。

       UE4中的几种异步方式底层使用线程实现，学习了线程类型、创建、生命周期、销毁方法，为下篇学习引擎特殊线程打下基础。

源代码与伪代码的区别

       伪代码：只是一种描述算法结构的语言，只是用来说明一些问题，伪代码并不能执行。如大学课程《数据结构》。比如要描述一个流程，你可以这么写伪代码：

       if 登陆成功 then

       跳转页面

       else 出错

       这一段看像是程序，实际上只有人能看懂，真正要编程语言来实现上面的功能，你就不能那么写。

       源代码：是用汇编、C、C++等编写好但还没编译成机器可执行的代码。

Async、Await 从源码层面解析其工作原理

       深入理解 Async 和 Await 的工作原理，往往需要从源码层面进行剖析。使用 Babel 进行转换后，可以清晰地发现 Async 和 Await 实际上借助了 switch-case 和 promise，实现对流程的控制。以一个使用 Async 和 Await 的函数为例，我们仅关注核心部分代码。

       经过 Babel 转换后的 name 函数，可以被拆分为三个主要部分：await 部分、return 部分以及 async 流程控制的结束部分（即 case "end"）。这个拆分使得流程控制变得更为直观。在流程控制中，每一步执行后，都会等待合适的时机进入下一次执行。

       这个“合适的时机”并非由 Async 内部决定，而是由执行的内容决定。例如，在发送异步请求后，只有在请求返回后才会进入下一个 case。

       为了实现流程控制，需要借助 regenerator-runtime 这个 generator、Async 函数的运行时。它负责将 name 函数进行包装，并添加流程控制所需的信息。如 _context，以及用于流程控制的关键 helper，如 _asyncToGenerator 和 asyncGeneratorStep。通过这些辅助工具，再在 regenerator-runtime 的基础上进行一层包装，最终得到一个可以执行的函数。这个函数实际执行时，会调用封装后的函数。

       在封装后的函数中，async1、async2 等实际上是在执行最终的封装函数内部的调用。这里的第三步是 Async 函数的核心机制。在 Promise.resolve(value).then(_next) 中，value 是每个分段最后的 case 返回的值。如果 value 是一个 Promise，那么在它 resolved 后，会将其.then添加到微任务队列。如果 value 不是一个 Promise，则直接添加，因为.then是一个微任务，当执行到它时，会调用_next，从而开始执行下一个 case。

       经过转换后的代码展示了封装后的函数内容，最终执行的是封装后的函数，因此说 async1、async2 执行实际上是执行封装后的函数。在封装后的函数内部，会调用 async1、async2。