我目前正在使用 Grand Central Dispatch（iOS 开发）从远程服务器下载图像。
这需要从主线程调度一个新线程；然后从服务器下载图像的任务发生在侧线程上。任务完成后，我显然用图像更新了主线程视图。
我的问题是，上述方法是否真的通过打开两个 TCP 通道来提高性能（下载速度），或者我是否主要在另一个线程上执行同步操作，从而使其异步，从而不会使其更快。
根据我的观察，性能保持不变。也许这里有人可以解释“幕后”理论并将该理论应用于我上面的具体案例？
【问题讨论】：
标签： ios objective-c asynchronous grand-central-dispatch
您可能不会看到下载速度有任何性能变化，因为主要问题是下载执行速度有多快，这取决于网络。您在 iOS 应用程序中的逻辑不能阻塞主线程，因此无论如何它都需要在后台线程上运行。即使您的图像非常大，一旦下载整个图像，PNG 的解码时间也会非常快。因此，您实际上只是在等待下载完成。你也没有真正做太多，因为 iOS 已经在后台使用了 http 请求的流水线，所以到相同地址和端口的多个请求很可能会通过同一个套接字推送。真正加快速度的唯一方法是使用更高级的图形压缩，以减少要下载的数据总量。
【讨论】：
Apple 竭尽全力在操作系统级别处理此问题，并且随着时间的推移，“引擎盖下”的实现会不断优化。出于基本目的手动管理套接字和连接可能不是您需要担心的事情 - 事实上，通过进一步优化，您的努力可能会撤销。
关于 iOS 网络的一般建议是确保您使用当前推荐的适用于您的 iOS 版本的网络框架（目前为NSURLSession 和朋友），更重要的是您使用它正确。这样您就可以自动利用系统为您进行的网络优化。
如果您假设 Apple 已经代表您实施了最佳案例网络，那么您的下一个选择是确保为您的用例获取最小文件大小，并且您的数据包从您的设备传输到的物理距离最短图像服务器。
如果您有兴趣 - 有关 iOS 网络的更多详细信息 - 我建议观看 2015 年 WWDC 会议上的 Networking with NSURLSession，如果您需要说服 Apple 知道他们在做什么并正在优化网络堆栈不断肯定看Your app and Next Generation Networks。
【讨论】：