CPU-Expensive (frame.contains) 是否有解决方法？

Question

我正在使用 Swift 和 SpriteKit 构建我的第一款游戏，最近我将整个游戏拆开以确定我的 CPU 问题来自哪里（在玩游戏的几分钟内，大约 80-100%）。我最近发现最昂贵的操作之一位于touchesMoved 方法中。这并不奇怪，因为它被非常频繁地调用，并且用户在整个游戏中都用手指来控制主角。但是，我惊讶地发现，特别是一条线路造成了麻烦。这是我的代码：

override func touchesMoved(_ touches: Set<UITouch>, with event: UIEvent?) {
    for touch : AnyObject in touches {
        let location = touch.location(in: self)

        let touchStartPoint:CGPoint = startingTouches[touch as! UITouch]!

        if(controlBase.frame.contains(touchStartPoint)){
            controlStick.position = location
        }
    }

}

我用 Instruments 运行了 4 个单独的测试，每个测试都用另一行。我发现没有

   if(controlBase.frame.contains(touchStartPoint)){
        controlStick.position = location
    }

当我的手指向下时，我在大约 5-10% 的 CPU 上徘徊 - 所以 touchesMoved 仍然被调用。但是，在检查if(controlBase.frame.contains(touchStartPoint)){ 时，即使括号内没有任何内容，我也会达到约 20-30% 的 CPU。

以下是 iPhone 上当前设置的屏幕截图：

这是我的 Instruments 日志的图片：最低点是我的手指从屏幕上抬起时，最高点是我的手指移动控制器时。

有没有办法解决这个问题？我正在做这个检查以确保用户虚拟操纵杆上的手柄不能离开它的底座。我只是不确定为什么这条线会如此昂贵，如果这是此检查所固有的，是否有另一种方法可以实现类似的功能。谢谢！

Answer 1

啊，好吧，我在另一个线程中为您留下了一些 cmets 后才看到这个。关于您获得的触摸事件的频率，您有点受操作系统的支配。您可以尝试限制在这些时刻占用的带宽。

这里的问题是你的节点树有多大？临时添加一些代码以通过手动遍历树来物理计算节点数可能很有用。您是否还在节点上应用缩放和旋转并使用层次结构？如果是这样，您也应该注意这一点，因为它需要更多的计算。

仍然基于您之前描述的内容，如果这真的占用了您的带宽，我会感到惊讶（假设您说您有 20 个对象）。

或者，如果您真的想要，您可以创建自己的包含。这实际上是我所做的，但其中一部分是对我如何处理我的图形有特殊需求的副产品。话虽如此，我经历了数百个对象，但没有明显的问题。请注意，我不会像您那样仔细检查 CPU 使用情况。我只关注FPS。

这段时间你的 FPS 是多少？此外，您应该在设备上运行它，并查看您的 CPU/GPU 使用情况与帧相关。 %CPU 也可能有点可疑，我觉得基于其他因素，例如您是否正在记录，甚至有时，操作系统还发生了什么。

最后尝试将您的代码移至飞船示例，并在添加更多飞船时注意效果。

添加细节

所以当我最初回答这些问题时，我很少考虑你在做什么。我仍然相信你现在不应该过度尝试优化，但是看看 SKOOP 的答案，特别是

https://github.com/MitrophD/Swift-SpriteKit-Analog-Stick

这是有趣的代码，让我更好地了解了您真正想要做什么以及如何在需要时挤出 CPU 使用率。游戏编码和优化背后的原则之一是懒惰。 “我怎样才能预先计算或做最少的工作？”

在这里，您需要对您的touchesBegin 和touchedEnd/touchesCancelled 进行一些调整。在进行触摸处理的类中添加一个名为

的成员属性

var controllerTouch : UITouch?

请注意，这是可选的，将代表控制器中的当前触摸。另请注意，如果您正在执行多点触控，则您将其定义为规则：控制器中的第一个触控是控制触控。

这带来了另一个关键点，即规则。您需要定义规则。在这里，我要说的是，活动控制器的触摸超出controllerBase 的范围是可以的（这就像将杆拉到最大）并且控制器实际上应该是一个圆圈。最后，我假设controllerBase 是静态的。

现在，这使我找到了可以最大限度减少所需工作的方法。

touchesBegin

由于这是静态的，我应该使用简单的数学方法来比较触摸的位置与到controllerBase 中心的距离。我可以这样做，因为我们说这是一个圆圈。所以我应该知道半径。因此，我的支票将类似于：

let distance = computeDistance(pt0: controllerBaseCenter, pt1: location)

// We only care about doing this if we are not currently actively tracking
if controllerTouch == nil {
    if distance < controllerBaseRadius {
        // Where touch is the current touch
        controllerTouch = touch
    }   
}

注意代码没有经过编译测试或是否有效，而是一个示例，并假设您将根据需要对其进行修复。我假设您将用正确的数学替换computeDistance 来计算距离，这是一件微不足道的事情。你的距离也需要绝对。

还有一件事要记住。由于controllerBase 是静态的，您可以预先计算并将实际中心点（controllerBaseCenter 和半径）存储在变量中。这可以保护您不必在节点上执行location 或contains，从而节省每个循环的浪费touchesStart 运行时间。

touchesEnd/touchesCancelled

在这里你将忽略controllerTouch 如果这是结束/取消的触摸。如有必要，您也可以为通知执行任何其他逻辑。

真正要处理的是

touchesMoved

所以在这里我们知道我们已经通过controllerTouch知道我们是否有一个活动控制器

override func touchesMoved(_ touches: Set<UITouch>, with event: UIEvent?) {
    for touch : AnyObject in touches {

        if touch == controllerTouch {
            // Only get location when needed (ie defer until you really need this)
            let location = touch.location(in: self)
            controlStick.position = location // You will need to adjust, see notes below to compensate for controllerBaseCenter if needed
        }
    }
}

请注意我的延迟评论。在您的原始代码中，您应该只在需要时完成 location 分配，也就是触摸在 controllerBase.frame 时。

现在，我省略了最后一件事。如何处理控制器可以移动的径向距离取决于您。例如，如果半径为 64，而我的触摸开始于距中心 60 的距离，那么如何处理？您是否将该偏移量视为中心点？如果是这种情况，您还需要跟踪第一次触摸的位置以正确调整数学。

请记住，您需要让玩家轻松不必精确。还要记住，他们不会经常低头查看控制器区域来仔细检查。

Answer 2

这是处理 Apple 框架时令人费解的方面之一。

没有好的微观例子！

许多游戏引擎和框架提供了一连串小型、实用、相关的示例，有时甚至数百个，展示了如何使用引擎功能的各个方面。

这些然后（也）用作类似单元的测试，用于引擎的每次迭代，并相应地更新。 Apple 的一些 Sprite Kit 演示代码是其原始形式。

而且社区很少。

不幸的是，你最好看看其他人在 github 上是如何做类似事情的，因为 Apple 甚至没有 Sprite Kit 的“最佳实践”文档。

这是 github 上的一个虚拟摇杆示例。

https://github.com/MitrophD/Swift-SpriteKit-Analog-Stick

这里有个有趣的问题：Dpad for sprite kit

其中条件是关于被触摸的节点的名称，而不是在.frame中搜索

//if control pad touched
    if ([node.name isEqualToString:@"controlPadNode"]) {
       ....
    }

可能是 .frame 内的搜索成本很高。它（应该）是简单的数学运算，所以我不知道为什么会这样，但是 SpriteKit 和 SceneKit 有很多奇怪的陷阱。