5

苹果的文档说:

在 iOS 中,不鼓励使用 POSIX 网络,因为它不会激活蜂窝无线电或按需 VPN。因此,作为一般规则,您应该将网络代码与任何常见的数据处理功能分开,并使用更高级别的 API 重写网络代码。

该文档没有提到dispatch_ioGCD 的 API,因此不清楚它们是否在 iOS 上激活了收音机。事实上,目前尚不清楚“特殊酱料”是在打开连接的代码中,还是在对其进行读写的代码中。

如果我使用 POSIX API 连接套接字并将其传递给dispatch_io_create怎么办?如果我使用 CFStream API 创建一个套接字,提取文件描述符并将其传递给dispatch_io_create? 哪些方法可以使网络在 iOS 上正常工作?两个都?两者都不?

4

1 回答 1

3

我没有对其进行测试,但我的猜测是所有按需 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 的开发者支持委员会,这个问题可能更有可能获得权威的回应(但也可能不会。)

于 2013-10-21T12:30:06.817 回答