上一次我为该开发日志编写任何内容时，都与场景转换有关。 您可能会认为，现在考虑要在游戏中建立多少其他东西，我还有很多话要说。 在写完该日志后不久，我实际上返回并重写了SceneManager，因为我对此不满意。 我认为这可能是当前最有价值的事情，因为自从上一个日志条目以来，我对方法所做的更改在简化代码方面非常有用和强大！
使我烦恼的另一种方法是，在显示加载屏幕的情况下，我有一个布尔标志，并且需要其他场景才能在SceneManager上显式翻转is_ready状态。 这是非常危险的，因为变量没有保护。 从那以后，有两件事让我感到满意，这对代码的改进确实有所帮助：协程和自省
Godot中的协程是基本但强大的。 在我的地牢时代中，我以前已经使用过协程，但是我只是屈服于暂停处理以帮助在单个线程上分配工作。 在Godot中，可以发出任何可以发出信号的信号。 在进行过渡的情况下，可以大大简化代码。 我们可以屈服以确保过渡动画在开始加载之前先完成，并使代码比连接和断开信号侦听器干净得多。
Godot中的自省也是新SceneManager的关键。 我已经习惯了React和Vue等Web框架中的组件，这些组件上都有生命周期方法。 Godot中的节点是非常准系统，没有任何生命周期方法可用于销毁它们或准备就绪后使用。 但是，您确实具有基本的能力，可以通过简单的自省方法检查它们是否具有方法或属性。 这意味着我可以将特定的方法添加到用作场景的节点上，并为它们提供我需要的自定义生命周期方法。 现在，用于场景的Node的完整流程看起来像
通常，节点已经具有用于“就绪”和“树”状态更改的各种信号，您可以将其连接到节点脚本中，以进行后期处理。 实际上，在文档中甚至将其声明为处理诸如析构函数之类的方式。 但是，这种方法有一个缺陷：如果这些方法是协程，则没有什么可以等待。 使用新的_setup和_teardown方法，我们可以显式检查是否需要屈服并这样做。
现在，SceneManager也可以为下一个场景的_setup方法获取参数，并且由于协程，我们不再需要保持状态。 这使我们的SceneManager除了本地执行外没有其他状态，而且场景本身完全了解其异步需求。 总体而言，我们现在有了一个更加封装和安全的流程。
当然，要使它起作用，所有这些都假设您正在尊重SceneTree的暂停状态。 最大的问题是_setup是在挂载Node并准备处理之后调用的，但是我们将其视为之前发生过。 我们之所以这样想是因为树已暂停。 但是，如果场景中的节点不遵守已暂停并继续进行处理，则它们有可能在加载期间断裂。 建议您在场景的_setup期间初始化这些节点，或将它们对树状态的依赖关系解耦，以免它们破坏事物。
与我们以前的实现相比，它现在功能更强大，更简化，更安全，并且已简化为附加到SceneManager单例的单个函数。
