Cocoa 回调何时给予控制？
我一直在网上搜索这个问题的答案，但无法找到答案，另一方面，我认为这是很常见的事情，因此我可能在这里遗漏了一些关键字。无论如何，问题如下：
何时将控制权交给ObjC（iPhone）中的回调函数？
在将控制权交给负责运行循环的层次结构类中的高层之后，是否会发生这种情况？它可以发生在正在执行的另一个函数调用的中间吗？
举个例子，我们以NSURLConnection为例，我们不知道或者无法预测它什么时候会调用didReceiveResponse或者其他回调方法，会不会是这样当我在另一个函数中时调用 didReceiveResponse ？ （非常怀疑这一点，但无法找到有关等待运行循环结束的回调的信息）
干杯， 卡斯帕
I've been searching around the web for an answer to this one, but was unable to find an answer, on the other side I think it's something quite common thus there is a possibility I'm missing some keywords here. Anyhow, the problem is as follows:
When is control given to a callback function in ObjC (iPhone)?
Does it happen after control is given to a high up in the hierarchy class responsible for the runloop? Can it occur in the middle of another function call being executed?
As an example, let's take the NSURLConnection, we don't know or can't predict when it's going to call didReceiveResponse or the other callback methods, can it be the case that didReceiveResponse get's called when I'm in the middle of another function? (highly doubt that but was unable to find information on callbacks wating for the end of the run loop)
Cheers,
Kaspa
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
不，在单个线程中，代码不是并行执行的。 runloop 调度所有消息的执行并按顺序分派它们。即使 NSTimers 也不能保证达到理论上的精度，因为它们必须像其他事情一样等待运行循环。
No, within a single thread, code is not executed in parallel. The runloop schedules the execution of all messages and dispatches them in sequences. Not even NSTimers are guaranteed to fire to the precision they are theoretically capable of because they have to wait for the runloop like everything else.
事实上，回调不会在函数中间被调用。您必须将控制权交还给主运行循环，以便它处理事件并调用回调。
如果您想知道到底是谁调用了您的回调，请在其中放置一个断点，然后检查堆栈跟踪。
The callbacks will not be called from in a middle of your function, indeed. You have to give back control to the main runloop for it to process events, and call your callback.
If you want to know who exactly calls your callback, put a breakpoint in it, and check the stack trace.
唯一一次在执行其他操作时调用 didReceiveReponse 的情况是，如果您在它自己的线程上启动了连接（通常在 NSOperation 中）。
这就是为什么当您在后台线程中确实有连接时，您通常使用类似 PerformSelectorInMainThread 之类的东西来更改应用程序其他部分的值 - 尽管您可以直接调整属性（如果它们未标记为非原子且不是可变集合）。
The only time the didReceiveReponse will be called while something else is executing, is if you have launched the connection on it's own thread (typically in an NSOperation).
This is why when you do have connections in a background thread, you usually use something like performSelectorInMainThread to change the value for other parts of the application - though you can adjust properties directly if they are not marked nonatomic and are not mutable collections.
默认情况下，基本上所有可可触摸类都完全在单个线程中工作，包括许多异步操作，例如后台网络调用。主要的例外是 NSOperation 和它的朋友，以及与 NSThread 相关的东西。
操作系统可以通过在运行循环调度中插入回调来实现这一点。在某些情况下，您的一个调用也会导致同一堆栈上的回调 - 例如，如果您在发生这种情况时通知其委托的对象（例如 UITextField）上调用 resignFirstResponder。
一些相关的博客文章：
By default, basically all cocoa touch classes work entirely in a single thread, including many asynchronous operations like background network calls. The main exceptions are NSOperation and friends, and things related to NSThread.
The OS can do this by inserting its callbacks in the run loop schedule. There are also a few cases when one of your calls will also result in a callback on the same stack - for example, if you call resignFirstResponder on an object that notifies its delegate when this happens, such as UITextField.
A couple relevant blog posts: