项目里面用了很多async和await 这样好不好

你举例的时候,说的就是编译后多了 2 层的调用导致的开销来证明 async await 的问题,怎么不是在说调用嵌套越多性能开销越大,那我按你的逻辑,不就是 M 层调用,M 越大性能越差?
我说了半天,是在和你说,你要真注重性能,写汇编就行了,用什么 js 呢?
然后我说的核心点你没理解而已,你关注于 20% 鸡毛蒜皮的点,而没办法证明 async await 的问题。

我们当然是在争论。但是争论得有理有据。你没抓住性能的核心问题,纠结于鸡毛蒜皮的地方,这才是最大的问题。

我们纠结的点在于如何兼顾游戏性能和优雅的编码。

有开发要在技能和动作这种肯定要处理中断的业务中抱怨 async 和 await 不支持中断,而且性能差,我当然不同意这种说法。
这种在确定技术方案的时候当然要考虑调用频率,中断业务,更要兼顾游戏性能的地方,简单的把锅甩给 async/await ,反驳肯定是要反驳的。

我也在反驳啊 :joy:,因为他说无法中断,其实callback本身也无法中断,async/await要处理的,callback也是要处理的,只是用async/await很容易忽略的一点是在await后,如果在ui组件里,还得考虑ui被销毁,这点容易被忽略,实际上callback也是要处理这个问题。

我这么说吧,你 async/await 用完后出问题,这个开发用回调函数也一样出问题。他只是没用回调的方式而已,这不是是 async await 的锅。
你用生成器解决 UI 有生命周期而导致的问题。是一个解决方案,但二者特性不一样,不能比较的。

你说的没错,是这样的

Ui逻辑随便用,gameplay特别是能update解决的,慎重,主要因为不好停止

1赞

赞同你的评价。异步会遇到的问题,回调也一定会遇到,相比之下异步更方便

只是编译后的代码体量可能在不同平台不一致

我个人感觉吧,首先promise的出现就是不想代码里出现地狱式回调,还有增强代码的可读性。因为我们在阅读的时候都是从上而下,promise阅读起来就很爽啊,而且他产生的额外内存还不至于导致性能大幅度降低吧。(抛开量来谈都是耍流氓不是)。而且真正导致性能的问题还不是渲染和大量复杂的计算么。promise真的太冤了。
其二吧。。虽然说promise不能终止。。但是我可以封装起来,主动从外部去主动让他主动走catch也算是终止吧。根据参数来决定catch里执行什么逻辑也算是一种变向终止吧。

你的回复好像诗啊

我管它生成的代码和性能咋样,用得爽就行,,

如果项目中有大量async,那本身就是写法的问题吧,要做好封装吆

项目中不要直接用async,可以参考cocos tween的做法,封装一个带Node参数的async。

深有感触,一定要足够理解这个语法才适合用

为啥呀,如果有了具体会导致什么样的后果呢

好的,谢谢,不过为什么项目中不要直接用async呢

官方的tween的callback,也算有点问题,没有随着node的生命周期取消

例如请求网络数据回来慢,但展示信息的label已经销毁,如果不封装异步,这时候调用label.string = str;游戏就报错。
加载资源同理。

当然你也可以加判断提前终止,但这是牛马该干的事情吗?判断加多了代码臃肿,偶尔忘了还得背锅 :joy:

这个封装留给项目主程干吧!

如果用的是383,不建议直接使用 promise 那一套,之前原生平台测试有问题,详见 【383】await async 原生平台与网页、微信小游戏效果不一致

不确定其他版本是否有类似问题,也没有找到问题的根源,我的解决方案是用的自己封装的异步回调对象替代。

这就是个解决callback回调地狱的语法糖而已。。。 编译后都是一样的,当然可以用。 至于异常处理,那是实现的业务逻辑是否严密, 和promise async await没有任何关系

3赞

可能平常AI对话用多了 :thinking: