皮皮网

【完整博客源码】【菠菜源码运营版】【整站采集站源码】await 源码

来源:贞观长歌 源码 时间:2024-11-23 03:40:34

1.python协程(4):asyncio
2.Vue3之事件循环、nextTick与源码解析
3.generator 执行机制分析
4.如何将Unity的Coroutine封装到Async/Await模式中

await 源码

python协程(4):asyncio

        asyncio是官方提供的协程的类库,从python3.4开始支持该模块

        async & awiat是python3.5中引入的关键字,使用async关键字可以将一个函数定义为协程函数,使用awiat关键字可以在遇到IO的时候挂起当前协程(也就是任务),去执行其他协程。完整博客源码

        await + 可等待的对象(协程对象、Future对象、Task对象 -> IO等待)

        注意:在python3.4中是通过asyncio装饰器定义协程,在python3.8中已经移除了asyncio装饰器。

        事件循环,可以把他当做是一个while循环,这个while循环在周期性的运行并执行一些协程(任务),在特定条件下终止循环。

        loop = asyncio.get_event_loop():生成一个事件循环

        loop.run_until_complete(任务):将任务放到事件循环

        Tasks用于并发调度协程,通过asyncio.create_task(协程对象)的方式创建Task对象,这样可以让协程加入事件循环中等待被调度执行。除了使用 asyncio.create_task() 函数以外,还可以用低层级的 loop.create_task() 或 ensure_future() 函数。不建议手动实例化 Task 对象。

        本质上是将协程对象封装成task对象,并将协程立即加入事件循环,菠菜源码运营版同时追踪协程的状态。

        注意:asyncio.create_task() 函数在 Python 3.7 中被加入。在 Python 3.7 之前,可以改用 asyncio.ensure_future() 函数。

        下面结合async & awiat、事件循环和Task看一个示例

        示例一:

        *注意:python 3.7以后增加了asyncio.run(协程对象),效果等同于loop = asyncio.get_event_loop(),loop.run_until_complete(协程对象)

*

        示例二:

        注意:asyncio.wait 源码内部会对列表中的每个协程执行ensure_future从而封装为Task对象,所以在和wait配合使用时task_list的值为[func(),func()] 也是可以的。

        示例三:

Vue3之事件循环、nextTick与源码解析

       事件循环是JavaScript单线程执行的核心机制,确保了同步任务与异步任务能有序执行。同步任务按顺序执行,而异步任务则分为宏任务和微任务。宏任务包括setTimeout、setInterval、整体代码、ajax、postMessage、交互事件等,微任务则包括Promise.then、整站采集站源码catch、finally、MutationObserver、process.nextTick(Node环境下)。

       事件循环机制确保了同步任务先执行,宏任务和微任务则交替执行,形成事件循环的周期。此过程确保了JavaScript代码的流畅执行,避免了因耗时任务阻塞主线程导致的卡顿。

       在Vue3中,nextTick功能用于处理异步更新DOM问题。它允许开发者在DOM更新之前执行异步代码,确保DOM的正确渲染。有以下两种使用方式:一种是直接传入回调函数,另一种是通过async和await实现。当对数据进行操作后,如果观察到DOM没有更新,原因在于Vue3中数据响应式是同步的,而DOM更新是异步的。

       为解决此问题,可以使用nextTick将同步代码转化为异步代码,synchronized锁升级源码确保在浏览器的下一次事件循环中执行DOM更新。在Vue3源代码中,nextTick通过将同步代码包装为Promise,从而转化为异步任务来实现这一功能。

       Vue3将DOM更新设置为异步,旨在优化性能。考虑到大量数据变化时,频繁的DOM更新可能导致性能开销过大,异步更新策略降低了这种浪费,提高了应用的响应性和性能效率。

generator 执行机制分析

       本文以下面代码为例,分析 generator 执行机制相关的源码,版本为 V8 7.7.1。

       首先,当 let iterator = test() 开始执行时,V8 调用 Runtime_CreateJSGeneratorObject,创建一个生成器对象。此函数逻辑是创建 JSGeneratorObject 的实例,设置相关属性后返回生成器对象 generator。此时生成器对象 generator 被保存在累加器中。在字节码 SuspendGenerator 的openresty worker源码实现处理函数中,该函数暂停当前函数的执行,并多次调用 StoreObjectField 来保存生成器函数当前运行的状态。最后返回累加器中的值,即生成器对象 generator。因此,生成器函数在执行到“第一次暂停”的位置时,处于暂停状态。

       在有了生成器对象后,可以调用其 next 方法让生成器函数继续执行。当 JavaScript 代码继续执行 iterator.next() 时,生成器对象的 next 方法被调用。生成器函数恢复执行需要 CPU 的寄存器操作。在笔者的 Mac 下,调用链路为GeneratorBuiltinsAssembler::GeneratorPrototypeResume-> CodeFactory::ResumeGenerator-> Builtins::Generate_ResumeGeneratorTrampoline。之后,调用 X 汇编,使生成器函数在暂停处恢复执行。此过程通过 Builtins::Generate_ResumeGeneratorTrampoline 函数完成,函数通过将未来要返回的地址压栈,并跳转到生成器函数 test 暂停的地方,继续执行。

       生成器函数从暂停处继续执行后,字节码一行一行往下执行,直到遇到下一个 SuspendGenerator,即“第二次暂停”。这是由 yield 带来的。yield 被 V8 编译成 SuspendGenerator 和 ResumeGenerator 两条字节码,分别表示保存状态暂停和恢复状态继续执行。

       async/await 与 generator 的关系分析:async/await 和 generator 都有暂停当前函数执行并从暂停处恢复执行的能力。await 和 yield 对应的字节码都是 SuspendGenerator 和 ResumeGenerator。生成器函数暂停时,需要调用生成器对象的 next 方法来从暂停处恢复执行。async 函数依赖 Promise 和 microtask,当 V8 在执行 microtask 队列时,已经暂停的 async 函数恢复执行。async 函数通过 Generator 和 Promise 获得保存状态暂停和恢复状态执行的能力,以及自我驱动向下继续执行的能力,从而避免调用 next 方法。

       JavaScript 中的函数类型较为复杂。虽然在 JavaScript 中,1 和 0.1 都是 number,但在 V8 中它们是不同的类型,内存表示和 CPU 运算指令也有所不同。因此,即使在 JavaScript 中 typeof 都返回 function 的 test、test1、test2,在 V8 中是不同的类型。日常开发中,当一个组件/方法需要一个函数做为参数时,需要确保正确传递 ES6 之前的函数、async 函数或生成器函数,以避免运行时错误。

       原生 generator 与 babel 转译的区别:在日常开发中,生成器/async 函数会被 babel 转译成类似下面的代码。这段代码中,test 函数被多次调用,但由于闭包保存了函数执行的状态,每次调用 test 都是新的 test。这种实现非常巧妙,但与 V8 中生成器函数的原理有较大区别。Babel 转译的代码无法生成字节码 SuspendGenerator 和 ResumeGenerator。

       总结:生成器函数被调用时,开始执行并返回生成器对象后暂停。调用 iterator.next() 后,生成器函数从第一次暂停的位置恢复执行,遇到 yield(SuspendGenerator)后第二次暂停。

如何将Unity的Coroutine封装到Async/Await模式中

       在探索Unity Coroutine返回值处理的解决方案时,发现原有的方法显得勉强,尤其是在事件处理器嵌套于多层 Coroutine 中时,逻辑变得复杂难懂。于是,我继续在网络上寻求前人经验,发现了一种更优雅的解决方案 - Async/Await模式。

       Async/Await模式是目前成熟的异步编程方法,其价值不在于提升程序运行速度,而是使代码结构符合人类日常习惯。通过了解此模式,我们能够实现代码的简洁清晰,如同派遣赵子龙跑快递并等待回信。网上已有开发者对Coroutine和IEnumerator进行了扩展,使其可以轻松封装到Async/Await模式中。

       游戏蛮牛多年前就有过相关项目的中文翻译,通过阅读原文,发现已有代码示例展示了如何将Unity中的常见协程转换为可await的等待。感兴趣者可以克隆GitHub上的源代码深入研究。项目的核心在于实现CustomAwaiter。

       为了实现最简单版本的UnityWebRequestResourceLoader资源加载类,首先需要创建一个Awaiter类,需引用System.Runtime.CompilerServices库,并实现INotifyCompletion接口的OnCompleted方法以及GetAwaiter、IsCompleted、GetResult、Complete方法和属性。业务逻辑类中,将业务逻辑分为两部分:传统Unity协程方法和Awaiter返回值的方法。通过这种方式,主程序可以使用await语法调用。

       主程序挂载在场景中的GameObject上,采用await xxx()的写法,使得代码结构更为清晰。对于自定义Async/Await封装Unity协程的过程,其关键在于实现CustomAwaiter和合理安排业务逻辑。在测试中,使用Thread.Sleep模拟耗时任务导致卡顿,这在Unity中可能因单线程导致。调整为WaitForSeconds后,问题得到解决。

       通过这个过程,我们能够实现Unity Coroutine的封装到Async/Await模式,使代码逻辑更符合人类习惯,提升代码可读性和维护性。未来,可进一步研究svermeulen的开源项目,利用SynchronizationContext将耗时任务转至其他线程,优化性能。