为什么我的 iPad 触摸事件会延迟(有时长达一秒)?

发布于 2024-11-08 20:00:58 字数 574 浏览 0 评论 0原文

我正在开发一款游戏,并且使用 CAEAGLLayer 支持的 UIView 子类来呈现游戏引擎。触摸处理是使用 -touchesBegan:withEvent: 等完成的。等人。

一切工作正常,除了极少数情况,如果快速点击屏幕上的控件之一,-touchesBegan:withEvent: 在 0.1 到 1-2 秒之间的某个时间不会被调用。这种情况发生的概率可能是二十次之一,而且只有当您首先快速点击屏幕(4-5 次)时才会出现这种情况。如果我同时按住屏幕上不同控件上的另一根手指,则似乎更有可能发生这种情况。

我认为这与我自己的代码有关,因此我对 UIApplication 进行了子类化,以便可以向 -sendEvent: 添加日志记录语句。当发生延迟触摸时,-sendEvent: 直到触摸开始后的一段时间才会被调用,因此我的 UIView 子类中的触摸处理代码不会被调用看来并没有错。

有谁知道这里发生了什么(除了 iOS 有一些不起眼的错误)?是否有某种内部“事件队列”使事件传递在填满时变得滞后?还有其他人经历过吗?

I'm working on a game, and I'm using a CAEAGLLayer backed UIView subclass to present the game engine. Touch handling is done using -touchesBegan:withEvent: et. al.

Everything works fine, except that very rarely, if one of the on-screen controls is tapped rapidly, -touchesBegan:withEvent: doesn't get called for somewhere between 0.1 and 1-2 seconds. This happens maybe one in 20 times, and only if you tap the screen rapidly (4-5 times) first. It seems to be more likely to happen if I am also holding down another finger on a different control on the screen.

Thinking that it was something to do with my own code, I subclassed UIApplication so I could add a logging statement to -sendEvent:. When the laggy touch happens, -sendEvent: doesn't get called until some period of time after the touch has started, so it the touch handling code inside my UIView subclass doesn't appear to be at fault.

Does anyone have any idea what's going on here (other than iOS having some obscure bug)? Is there some sort of internal "events queue" that makes event delivery become laggy when it fills up? Has anyone else experienced this?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

野稚 2024-11-15 20:00:58

触摸事件仅在主 UI 运行循环中调度,有时仅在主运行循环空闲一段时间时调度。因此,如果您的应用程序忙于连续处理多个先前的触摸事件而没有休息,则主 UI 运行循环可能会饱和,因此在处理完当前内容之前不会再获取任何进一步的触摸事件。

触摸事件也有时间戳。因此,您可以检查它们是否来得太快(比您的事件处理程序和生成的 UI 更新可以运行的速度快),如果您希望应用程序保持最大响应速度,则可以根据您的应用程序跳过或组合一些事件处理程序。

Touch events are only dispatched in the main UI run loop, and sometimes only when the main run loop goes idle for a bit. So if your app is busy handling several previous touch events in a row without taking a break, the main UI run loop might be saturated, and thus not get any further touch events until done with the current stuff.

Touch events also have time stamps. So you can check if they're coming too fast (faster than your event handlers and resulting UI updates can run), and skip or combine some of the event handlers, as appropriate for your app, if you want the app to stay maximally responsive.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文