await或者异步回调用多了，得加isValid判断，搞得整个人都提心掉胆的

Creator 3.x
#21

怎么解决的，能展开说说不

#22

这是我同事的东西，我不方便讲，等他看到了这个帖子，愿意分享他会来分享的

#23

是的 封装+传入生命周期对象,在触发成功或者失败的地方判断生命对象是否isvaild就行了

#24

好用 爱用
image

#25

好用，爱用，实际上要判断isValid的地方并不多
image
image

#26

搞一个基类，onDestroy 里面统一处理 :rofl:

#27

不用 isValid 的机制，一种可能是更复杂的游戏框架层机制。

比如 await 执行后，通知界面，基本上是用的消息通知节点。而节点要通过组件注册消息来处理。
这样节点能否处理 等价于 界面是否还有注册该消息的处理函数。
于是问题核心在于，节点在不可用的时候会同步注销该处理函数。

这是一整套的游戏框架层机制。不如 isValid 封装一层来得简单。

#28

咋说得用回调就不用加isValid一样 :joy:

#29

image
image873×422 11.8 KB

这种有更好的写法吗

#30

话说各位大佬有什么好方法查await的调用堆栈哦

#31

可以试试可选链操作符

#32

在异步期间就不应该让isvaild的状态改变，在回调中再判断isvaild属于补丁行为

#33

所以我都是提前加载，用的时候直接get资源

#34

想法很好，但基本不可能。
举个例子就知道了，排行榜你异步拉取用户头像，拉取后填充。你总不能因为网络问题，说，用户你等我拉完头像再关闭排行榜界面🥲

或者收到内存警告，的时候等异步完成才能释放？游戏一定会有中断机制。

1赞
#35

网络项目应该分层设计，就不应该在cocos组件死等网络返回

#36

和你分几层没关系，网络回调你有链路要调用到设置头像这个步骤。核心问题在于回来的时候，你的头像 Sprit 已经不可用。
所以，要么框架层把这个链路断开了，就不用判断 isValid。要么就一定要判断 Valid

#37

面试的时候没有人问你们观察者模式的应用问题？

#38

我本来纳闷，await跟isValid有什么关系。看了评论才明白，是怕异步完成时节点失效？

#39

订阅式（比如on/off）的不需要判断isValid吧？
但得记得调用off，当然了，也可以监听ccObject状态自动断开

#40

类似的东西我也设计过，我之前是封装代码块执行，参数传递在这个代码块需要判断isValid的对象。如果对象失效则不继续下个代码块执行。但是这种方案写起来其他人不容易理解也不顺手例如传递变量，也就没继续使用了，不知道他是不是类似的