我刚刚开始使用SpriteKit，这个问题几乎立刻就出现了。如果我有一个视图控制器，其视图是SKView，在其上推动另一个视图控制器（例如，暂停菜单或结束游戏菜单），然后使用SKView展开回视图控制器需要相当长的时间，根据我对4S和5的经验，约一秒半。
您可以使用默认的Hello World模板对此进行测试。我将其设置为导航视图的根控制器，并在导航栏中粘贴一个按钮以触发推送到新视图控制器的segue。第二个视图控制器包含一个触发展开segue的按钮。当按下按钮时，它会保持突出显示大约一秒半，然后最终发生segue，这对用户来说非常不利。
我已经浏览了SpriteKit文档并没有注意到有关正确使用segue的任何内容，这只是一个错误，还是在SKView上推送新视图被认为是不好的做法？相反，我应该使用SKNodes / SKScenes来呈现我的暂停和结束游戏菜单，从而始终将SKView保留在屏幕上吗？
答案 0 :(得分：5)
我遇到了类似的问题，发现this很有帮助。我打算使用多个UIViewControllers导航到我的游戏的不同部分，如菜单屏幕，屏幕上的游戏等，但它很慢。在重构我的应用程序以使用其视图为SKView类型的单个UIViewController，并为我想要的每个屏幕创建一个新场景后，它开始正常工作。起初我认为这将是一个痛苦，因为控制器最终会变得无法管理，但发现大多数逻辑都封装在每个SKScene中，并且控制器仅用于呈现新场景。
另外，您应该注意从SKScene向SKView添加UIKit控件是可以接受的。这是我正在做的，以避免每次我需要UIScrollView，UIButton或任何其他UIKit控件时重新发明轮。当然，在转换时，您必须删除不想在场景之间共享的UIKit内容。
答案 1 :(得分：0)
在显示菜单故事板时，SKView（或场景）是否可能解除分配？这可以解释返回现场时的延迟。在自定义视图/场景子类的相应dealloc消息中设置断点，或使用Instruments在显示菜单时检查实时对象中的视图和场景。
另一种可能性是纹理从内存中移除然后必须重新加载。 Sprite Kit中可能存在自动化，很难说。
尝试更改故事板的连接方式，例如在精灵工具包视图之前有一个“主菜单”故事板。有趣的是看你是否会像回到它一样（反复）进入视图。
FWIW我只对SK和故事板进行了一些测试，但没有注意到这样的延迟。