我喜欢 ASIHTTPRequest,看到它消失我很难过。然而,ASI 的开发者是对的,ASIHTTPRequest 已经变得如此庞大和臃肿,甚至他都无法花时间将其与 iOS 和其他框架的最新功能相提并论。我继续前进,现在使用 AFNetworking。
也就是说,我必须说 AFNetworking 比 ASIHTTP 不稳定得多,对于我使用它的东西,它需要改进。
在屏幕上显示结果之前,我经常需要向 100 个 HTTP 源发出 HTTP 请求,并且我已将 AFHTTPNetworkOperation 放入操作队列中。在下载所有结果之前,我希望能够取消操作队列中的所有操作,然后关闭保存结果的视图控制器。
这并不总是有效的。
我在使用 AFNetworking 时会随机崩溃,而使用 ASIHTTPRequest 时,此操作可以完美运行。我希望我能说出 AFNetworking 的哪个特定部分正在崩溃,因为它一直在不同的点崩溃(但是,大多数情况下,调试器指向创建 NSURLConnection 对象的 NSRunLoop)。因此,AFNetworking 需要成熟才能被认为与 ASIHTTPRequest 一样完整。
此外,ASIHTTPRequests 支持客户端身份验证,这是 AFNetworking 目前缺乏的。实现它的唯一方法是继承 AFHTTPRequestOperation 并覆盖 NSURLConnection 的身份验证方法。但是,如果您开始参与 NSURLConnection,您会注意到将 NSURLConnection 放在 NSOperation 包装器中并编写完成块并不像听起来那么难,并且您会开始思考是什么阻止了您转储 3rd 方库。
ASI 使用完全不同的方法,因为它使用 CFNetworking(基于 C 的低级基础框架)使下载和文件上传成为可能,完全跳过 NSURLConnection,并且触及我们大多数 OS X 和 iOS 开发人员都不敢接触的概念。因此,您可以获得更好的文件上传和下载,甚至是网页缓存。
我更喜欢哪个?很难说。如果 AFNetworking 足够成熟,我会比 ASI 更喜欢它。在那之前,我不得不佩服 ASI,以及它成为 OS X 和 iOS 有史以来最常用的框架之一的方式。
编辑:
我认为是时候更新这个答案了,因为在这篇文章之后事情发生了一些变化。
这篇文章是前段时间写的,AFNetworking 已经够成熟了。1-2 个月前,AF 发布了一个关于 POST 操作的小更新,这是我对框架的最后一次抱怨(一个小行结束错误是 echonest 上传失败的原因,但使用 ASI 可以很好地完成)。身份验证不是 AFnetworking 的问题,因为对于复杂的身份验证方法,您可以将操作子类化并进行自己的调用,而 AFHTTPClient 使基本身份验证变得轻而易举。通过继承 AFHTTPClient,您可以在很短的时间内创建一个完整的服务消费者。
更不用说 AFNetworking 提供的绝对必要的 UIImage 添加。使用块和自定义完成块以及一些巧妙的算法,您可以很容易地制作具有异步图像下载和单元格填充的表格视图,而在 ASI 中,您必须制作操作队列以限制带宽,并注意自己取消和恢复操作队列根据表视图可见性,以及类似的东西。此类操作的开发时间已减半。
我也喜欢成功和失败的块。ASI 只有一个完成块(实际上是 NSOperation 的完成块)。您必须检查完成时是否有错误并采取相应措施。对于复杂的 Web 服务,您可能会迷失在所有的“ifs”和“else”中;在 AFNetworking 中,事情变得更加简单和直观。
ASI 在当时非常出色,但是使用 AF,您可以以一种很好的方式完全改变您处理 Web 服务的方式,并更轻松地制作可扩展的应用程序。我真的相信没有任何理由再坚持使用 ASI,除非您想针对 iOS 3 及更低版本。