NSURLConnection来自线程与异步请求的同步请求

Question

在NSOperationQueue中添加一个同步NSURLConnection请求的操作（或者来自线程（而不是主线程）的同步请求）和从主线程发出异步请求之间有什么区别？

两者都不会阻止主线程，因此UI将保持响应，但使用一个优于其他优势是否有任何优势？我知道在后面的方法中我可以跟踪请求进度等但是假设进度和其他HTTP内容在这里并不重要。

Answer 1

他们非常相似。同步请求的最大问题是它们不容易被取消。根据您的应用程序，这可能是一个问题。想象一下，您正在下载一个大文档，并且用户移动到另一个屏幕，因此您不再需要该信息。在我们的例子中，我实际上选择在辅助NSThread上进行异步NSURLConnections，这对某些应用程序来说可能有点过分。它更复杂，但它使我们能够取消请求并解码辅助线程上的JSON / XML /图像数据，因此它们不会影响主线程用户交互性。

Answer 2

历史地位是，在异步请求中功耗和电池寿命都有优势 - 可能包括较旧的委托方法和新的基于块的方法。

Answer 3

异步请求在运行循环上进行调度并设置为运行循环源，仅在从网络接收数据时自动触发代码（如任何套接字源）。

在NSThread上运行的同步请求独占一个线程来监视传入的数据，这通常是非常过分的。

即使已使用NSURLConnection方法异步执行cancel，也可以取消NSOperationQueue。

我打赌使用允许在+sendAsynchronousRequest:queue:completionHandler:（dispatch_source_create）上发送异步请求的新API使用引擎盖下的GCD和NSURLConnection或类似的东西，以便它的行为与在运行循环中安排NSURLConnection时的方式相同，避免使用额外的线程（观看WWDC'12视频，解释为什么线程是邪恶的并且应该最小化它们的使用），区别仅在于允许您可以在完成时使用块来通知，而不是使用委托机制。

几年前，我创建了一个类，它将NSOperationQueue异步调用和委托管理嵌入到一个很好的块API中（参见我的github上的OHURLLoader），这样可以更容易使用（随意使用看）。我敢打赌，使用{{1}}的新API使用相同的原则，仍在runloop上执行异步请求，但允许您使用块而不必实现委托。