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

Question

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

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

Answer 1

They are very similar. The biggest problem with synchronous requests is that they can't easily be cancelled. Depending on your application, that could be a problem. Imagine you are downloading a big document and the user moves to another screen so you no longer need that information. In our case, I actually chose doing asynchronous NSURLConnections on a secondary NSThread, which may be overkill for some apps. It is more complicated, but it gives us the ability to both cancel requests and to decode the JSON/XML/image data on secondary threads so they don't impact main thread user interactivity.

Answer 2

历史上的立场是，异步请求在功耗和电池寿命方面具有优势——大概包括旧的委托方法和新的基于块的方法。

Answer 3

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

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

NSURLConnection即使它已经异步执行，您也可以使用该cancel方法取消它。

NSOperationQueue我敢打赌，使用允许在( )上发送异步请求的新 API+sendAsynchronousRequest:queue:completionHandler:使用 GCD 和dispatch_source_create，或类似的东西，因此它的行为与在运行循环上调度时的行为相同NSURLConnection，避免使用额外的线程（观看 WWDC'12 视频，其中解释了为什么线程是邪恶的并且应该尽量减少它们的使用），不同之处仅在于允许您使用在完成时通知块而不是使用委托机制。

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