运行循环实际上是如何工作的
本月早些时候，我问了这个问题 '什么是 runloop？' 阅读答案后并做了经过一些尝试，我让它发挥作用，但我仍然不完全理解它。如果运行循环只是与线程关联的循环，并且它不会在幕后生成另一个线程，那么我的线程（主线程以保持简单）中的任何其他代码如何执行而不会被“阻止”/不运行因为它在某个地方造成无限循环？
这是第一个问题。然后到我的第二个。
如果我在处理完这个之后得到了一些正确的信息，但没有完全理解它，那么运行循环是一个循环，您在其中附加“标志”，通知运行循环当到达标志所在的点时，它“停止”并且执行此时附加的任何处理程序？然后它继续运行到队列中的下一个。
因此，在这种情况下，没有事件被放置在连接中的 que 中，但是当涉及到事件时，它会采取与点击 1 并在它再次运行到连接之前执行它，依此类推。还是我对这个概念的理解还不够深入？
Earlier this month I asked this question 'What is a runloop?' After reading the answers and did some tries I got it to work, but still I do not understand it completely. If a runloop is just an loop that is associated with an thread and it don't spawn another thread behind the scenes how can any of the other code in my thread(mainthread to keep it simple) execute without getting "blocked"/not run because it somewhere make an infinite loop?
That was question number one. Then over to my second.
If I got something right about this after having worked with this, but not completely understood it a runloop is a loop where you attach 'flags' that notify the runloop that when it comes to the point where the flag is, it "stops" and execute whatever handler that is attached at that point? Then afterwards it keep running to the next in que.
So in this case no events is placed in que in connections, but when it comes to events it take whatever action associated with tap 1 and execute it before it runs to connections again and so on. Or am I as far as I can be from understanding the concept?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
“有点像。”
您读过 这个特定文档？
它对运行循环的架构和操作进行了相当深入的研究——相当彻底的深入。
"Sort of."
Have you read this particular documentation?
It goes into considerable depth -- quite thorough depth -- into the architecture and operation of run loops.
如果运行循环分派耗时过长或永远循环的方法，那么它将会被阻塞。
这就是为什么 iPhone 应用程序想要执行不适合 UI 运行循环的 1 个“tick”的所有操作（例如在某些动画帧速率或 UI 响应速率），并为任何其他事件处理程序留出空间的原因需要在同一个“tick”中完成，要么异步分解，要么分派到另一个线程执行。
否则，在控制权返回到运行循环之前，内容将被阻塞。
A run loop will get blocked if it dispatches a method that takes too long or that loops forever.
That's the reason why an iPhone app will want to do everything which won't fit into 1 "tick" of the UI run loop (say at some animation frame rate or UI response rate), and with room to spare for any other event handlers that need to be done in that same "tick", either broken up asynchronously, on dispatched to another thread for execution.
Otherwise stuff will get blocked until control is returned to the run loop.