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

Question

添加在NSOperationQueue中创建同步NSURLConnection请求的操作（或来自线程（不是主线程）的同步请求）和从主线程发出异步请求？

这两个都不会阻塞主线程，所以UI将保持响应，但有没有比其他优势更好的优势？我知道在以后的方法，我可以跟踪请求进展等，但认为进展和其他HTTP的东西在这里并不重要。

Answer 1

将异步请求安排在运行循环中，并设置为运行循环源，仅当从网络接收到数据（如任何套接字源）时自动触发代码。

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

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

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

几年前，我创建了一个嵌入NSURLConnection异步调用和委托管理到一个很好的块API（请参阅我的github上的OHURLLoader），使它更易于使用（随意看一看）的类。我敢打赌，使用NSOperationQueue的新API使用相同的原则，仍然在runloop上执行异步请求，但允许您使用块而不必实施委托。

Answer 2

历史地位是，在异步请求中，电源消耗和电池寿命都有优势 - 大概包括旧的代理方法和新的基于块的方法。

Answer 3

它们非常相似。同步请求最大的问题是不能轻易取消。根据您的应用程序，这可能是一个问题。想象一下，你正在下载一个大文件，用户移动到另一个屏幕，所以你不再需要这些信息。在我们的例子中，我确实选择了在辅助NSThread上执行异步NSURLConnections，这对于某些应用程序来说可能是过度的。它比较复杂，但它使我们既可以取消请求，也可以解码辅助线程上的JSON/XML /图像数据，从而不影响主线程用户交互。