6

关于这个主题有很多问题，很多建议说不要在 dispatch_async 中使用 sendSynchronousRequest，因为它会阻塞线程，并且 GCD 将产生许多新的工作线程来服务所有同步 URL 请求。

似乎没有人对 iOS 5 [NSURLConnection sendAsynchronousRequest:queue:completionHandler:] 在幕后所做的事情有明确的答案。

我读过的一篇文章指出它“可能”进行了优化，并且“可能”使用了运行循环——但肯定不会为每个请求创建一个新线程。

当我在使用 sendAsynchronousRequest:queue:completionHandler 时暂停调试器时，堆栈跟踪如下所示：

截屏

..现在看来 sendAsynchronousRequest:queue:completionHandler 实际上正在调用 sendSynchronousRequest，当我使用异步方法而不是同步方法时，我仍然创建了大量线程。

是的，使用异步调用还有其他好处，我不想在这篇文章中讨论。

我感兴趣的是性能/线程/系统使用，如果我更糟的是使用 dispatch_async 内部的同步调用而不是使用异步调用。

我也不需要关于使用 ios4 异步调用的建议，这纯粹是出于教育目的。

有没有人对此有任何有见地的答案？

谢谢

4

2 回答 2

0

正如前面的答案所述，GCD (libdispatch) 和 libblocksruntime 都是开源的。在内部，iOS/OS X 管理一个全局 pthread 池，以及您在用户代码中创建的任何特定于应用程序的池。由于 OS 线程和调度任务之间存在 1:N 映射，因此您不必（也不应该）担心线程的创建和处理。为此，GCD 任务在调用后不会在应用程序的运行循环中使用任何时间，因为它被踢到后台线程。

大多数类型的 NSURL 操作都是 I/O 绑定的；没有多少并发巫术可以掩盖这一点，但如果 Apple 自己的异步实现在后台使用其同步对应物，它可能表明它已经高度优化。与前面的答案相反，libdispatch确实在内部使用了可扩展的 I/O（kqueue在 OS X/iOS/BSD 上），如果您自己手动滚动某些东西，则必须自己处理文件描述符准备情况以产生类似的性能.

虽然可能，但投入时间的回报可能是微不足道的。坚持 Apple 的实现，不再担心线程！

于 2012-09-26T02:32:04.297 回答
0

这实际上是开源的。http://libdispatch.macosforge.org/

您不太可能比 Apple 的实现更有效地管理工作线程。在这种情况下，“异步”并不意味着选择/轮询，它只是意味着调用将立即返回。因此，实现产生线程也就不足为奇了。

于 2012-07-23T18:56:36.303 回答