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