苹果的文档说：
在 iOS 中，不鼓励使用 POSIX 网络，因为它不会激活蜂窝无线电或按需 VPN。因此，作为一般规则，您应该将网络代码与任何常见的数据处理功能分开，并使用更高级别的 API 重写网络代码。
该文档没有提到dispatch_ioGCD 的 API，因此不清楚它们是否在 iOS 上激活了收音机。事实上，目前尚不清楚“特殊酱料”是在打开连接的代码中，还是在对其进行读写的代码中。
如果我使用 POSIX API 连接套接字并将其传递给dispatch_io_create怎么办？如果我使用 CFStream API 创建一个套接字，提取文件描述符并将其传递给dispatch_io_create? 哪些方法可以使网络在 iOS 上正常工作？两个都？两者都不？
我没有对其进行测试，但我的猜测是所有按需 VPN 和蜂窝无线电的魔法都发生在启动/设置/连接打开时间，因为这真的是唯一真正有意义的事情。因此，我希望您使用CFSocketGetNative和使用挖掘文件描述符的方法dispatch_io可以正常工作，至少直到其中一个连接断开（假设 TCP/有状态连接）。从断开的连接中恢复的 AFAICT 无论如何都不是内置CFSocket/CFNetworkStream的，所以它可能是六对一的......
我已经阅读了一些关于 iOS 的新多路径 TCP 实现的模糊新闻（听起来像是重新访问了链接绑定），目前还不清楚这是否适用于 3rd 方应用程序，但我是这样想的：要么多路径支持在协议栈中（因此被抽象为应用程序开发人员作为单个套接字/文件描述符）并且将对任何TCP 套接字上的第 3 方应用程序开发人员透明地工作，或者它依赖于一些更高级别用户级组件将多个底层连接处理/聚合为一个，并将迫使开发人员使用更高级别的 API。你已经如果您想要 VPN-on-demand 和 cell-radio 功能，则必须使用更高级别的 API 来建立连接，所以看起来这对您来说都无关紧要。
如果您的目标只是让块为异步 I/O 会话提供服务，那么似乎最安全的操作过程（鉴于这些东西在文档中似乎有点未指定）是使用基于 runloop 的 API 并进行回调调用一个块。如果你担心网络 I/O 和主 runloop 之间的交互，你总是可以使用它自己的 runloop 建立一个后台线程并在那里安排你的 I/O。从过去使用这两种 API 完成 I/O 来看，我希望 runloop 方法在性能方面在功能上等同dispatch_io于在常见情况下使用 API（即，除非您正在做一些非常高的事情，否则它不会明显变慢-吞吐量或真的很健谈。）
FWIW，如果将这个问题发布到 Apple 的开发者支持委员会，这个问题可能更有可能获得权威的回应（但也可能不会。）