AFNetworking缺少哪些主要的ASIHTTPRequest功能?

Jos*_*phH 93 iphone asihttprequest ipad ios afnetworking

由于最近停止了ASIHTTPRequest的工作,似乎注意力转向AFNetworking.

但是,我还没有找到两个库的功能的良好比较,所以我不知道如果/当我切换时我可能会失去什么.

到目前为止我发现的主要差异是:

  1. AFNetworking的代码大小要小得多(这很好)
  2. AFNetworking正在迅速改进(因此可能尚未成熟,可能还没有稳定的API?)
  3. 两者似乎都有缓存,虽然我已经看到提示,因为AFNetworking使用NSURLConnection它不会缓存超过50K的对象
  4. ASIHTTPRequest对手动和自动(PAC)http代理有很好的支持; 我无法找到有关AFNetworking对代理服务器支持程度的任何信息
  5. AFNetworking需要iOS 4+,而ASIHTTPRequest可以直接使用iOS 2(对我来说这不是一个问题,但对某些人来说这是一个问题)
  6. AFNetworking(还)没有内置的持久缓存,但是有一个持久缓存,它有一个挂起的拉取请求:https://github.com/gowalla/AFNetworking/pull/25

有没有人看到两个图书馆的任何良好比较或从一个图书馆转换到另一个图书馆的任何记录经验?

cso*_*iou 59

我喜欢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包装器中并编写完成块并不是听起来那么难,您将开始考虑是什么让您无法转储第三方库.

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服务的方式,并且可以更轻松地创建可伸缩的应用程序.我真的相信没有任何理由坚持使用ASI,除非您想要针对iOS 3及更低版本.

  • 稳定性问题仍然是个问题吗? (3认同)

Jef*_*eff 17

刚刚完成我正在使用AFNetworking而不是ASI的项目.在以前的项目中使用过ASI; 这在过去是一个很好的帮助.

以下是您应该了解的AFNetworking缺失的内容(截至今天):

  • 没有

ASI 正在消失.立即使用AF.它很小,很有效,并且会继续得到支持.它的组织也更加逻辑,特别是对于API客户端.对于经常使用的特殊情况,例如在表视图中异步加载图像,它有许多很棒的类.

  • 正如@iwat在问题中提到的那样,AFNetworking缺少强大的缓存.这个问题很有意思和相关,所以"没有"是错误的答案.除此之外,我完全同意你的观点. (9认同)