- 浏览: 26224 次
- 性别:
- 来自: 北京
最新评论
-
micallz:
绝知此事要躬行。
Git忽略文件(转载好文) -
lalakang:
提示找不到新项目的文件啊
ios如何在当前工程中添加编辑新建的FramesWork (两个ios工程联调同样适用 ) -
lalakang:
表示搞不对啊!!!
ios如何在当前工程中添加编辑新建的FramesWork (两个ios工程联调同样适用 )
在开发iOS应用过程中,如何高效的与服务端API进行数据交换,是一个常见问题。一般开发者都会选择一个第三方的网络组件作为服务,以提高开发效率和稳定性。这些组件把复杂的网络底层操作封装成友好的类和方法,并且加入异常处理等。
那么,大家最常用的组件是什么?这些组件是如何提升开发效率和稳定性的?哪一款组件适合自己,是 AFNetworking(AFN)还是 ASIHTTPRequest(ASI)?几乎每一个iOS互联网应用开发者都会面对这样的选择题,要从这两个最常用的组件里选出一个好的还真不是那么容易。
单单从两个控件版本提交的时间节点来看,AFN的第一个提交是2011年的1月1日,那个时候ASI早已是1.8+的版本了;而当AFN发布1.0版,2012年10月份的时候,ASI早早的已经停止更新了。这样看起来,AFN是ASI的继任者,似乎不存在之前提到的选择困难的问题,而事实并非如此。本文将从用法、功能、性能和原理几个方面对二者进行简单对比,看看二者之间到底存在着怎样的区别,到底应该如何选择。
1、用法对比
首先,从推荐用法上就可以看出二者设计理念上大有不同。
图1,AFN的示例代码,发起请求(出自:Posts.m)
AFN官方推荐的使用方法是,为一系列相关的请求定义一个HTTPClient,共用一个BaseURL。每次请求把URL中除BaseURL的Path部分做为参数传给HTTPClient的静态方法,并注册一个Block用于回调。
图2,ASI示例代码,发起异步请求(出自:ASIHTTPRequestTests.m)
ASI推荐使用方法就非常传统,每一个请求都由构造方法初始化一个(共享)实例,通过这个实例配置参数并发起请求。ASI最初使用delegate模式回调,在iOS SDK支持Block之后也提供了注册Block的实例方法。
以上引用的两段代码都出自各自项目的示例工程。对比两段代码可以很清楚的看出,同样是发起一个最普通的异步请求,使用AFN只需要调用一个静态方法,但代码可读性较差;而ASI的示例看起来更清晰,但需要调用多个实例方法才能完成一次请求。AFN的设计更加工程化,或者说对使用者更友好,而ASI的设计更经典,典型的OOP。
除了初级用法上的区别,二者的高级功能和对扩展的支持也颇有不同。
2、高级功能
AFN只封装了一些常用功能,满足基本需求,而直接忽略了很多扩展功能。例如:AFN默认没有封装同步请求,如果开发者需要使用同步请求,则需要重写getPath:parameters:success:failure方法,对AFHTTPRequestOperation进行同步处理;而ASI则是直接通过调用一个startSynchronous方法。
此外AFN针对JSON、XML、PList和Image四种数据结构封装了各自处理器,开发者可以把处理器注册到操作队列中,直接在回调方法中获得格式化以后的数据。在示例工程中就使用了JSON处理器:把AFJSONRequestOperation注册到操作队列里。
图3,AFN示例代码,初始化自定义的HTTPClient(出自:AFAppDotNetAPIClient.m)
而ASI在这方面显得更原始,没有针对任何数据类型做特别封装,只是预留了各种接口和工具供开发者自行扩展。ASI比AFN提供更多扩展功能还有一个原因,它把许多内部用到的功能也抽象成类和方法。例如:
ASIHTTPRequestDataCompressor和ASIHTTPRequestDataDecompressor两个类,只用于压缩本地文件,构造POST Body和解压缩返回数据,但这两个类仍然被设计为独立功能,提供了对多种数据结构进行压缩和解压缩的方法。
对比二者的高级功能和对扩展的支持后,可以看出AFN把初级功能(或者叫常用功能)做到了90分。调用方式够简单,处理器够丰富,使用者用起来可以算是轻松加愉快。但它放弃了对高级功能的支持,要满足较复杂的需求,就要大费周折了,在这方面最多只有40分。而ASI显然不满足于做好初级功能,但为了提供更丰富的可扩展接口,导致初级功能用起来也要花上一些力气。虽然ASI单独提供了支持Amazon S3和Rackspace Cloud Files的控件,但对于生在红旗下的我朝开发者来说基本没用,所以在初级功能的支持上ASI能得个70分,牺牲了初级功能的易用性,换来的是良好的扩展性,在高级功能的使用上远远好于AFN,也能得个70分。
从使用角度对比过后,基本上对这两个项目有一个整体上的认识,再深入下去看看二者的性能如何。
3、性能对比
我分别用AFN和ASI进行了测试,测试环境如下:iPhone5,联通3G信号全满,室内静止状态,请求国内双线机房独立服务器的静态文件,1~20K共20个文件,每个文件请求20次,记录从创建请求到完全下载文件的耗时,结果如下:
图4,AFN连续访问1 ~ 20K文件耗时
图5,ASI连续访问1 ~ 20K文件耗时
图4是AFN的记录图,绿色为20次请求中耗时最久的一次,蓝色为耗时最短的一次,黄色为去除最大值和最小值的18次平均值。从这个图可以看出,AFN最开始创建对象耗时近2.5秒,随后稳定下来,在3K、7K、15K和20K时出现了抖动。图5是ASI做相同测试的结果,首次创建对象近2.25秒,略优于AFN,同样在5K、11K、13K、14K和16K发生了一些抖动,但抖动幅度似乎小于AFN,可见稳定性更好一些。
下边是把二者的测试结果放在一起的对比图,可以更直观的比较二者的区别。
图6,ASI和AFN耗时最大值对比
图6的最大值对比可以更明显的看出二者的抖动对比,ASI略好一些。
图7,ASI和AFN耗时最小值对比
图7的最小值对比可以看出,在每一个大小的测试中ASI的最佳性能似乎都要优于AFN。
图8,ASI和AFN耗时平均值对比
图8是耗时平均值的对比,更能够说明问题。文件小于12K的测试中ASI的性能优势并没有非常明显,超过12K以后,ASI优势开始明显起来,每一次请求都要比AFN节约20% ~ 30%,近0.1秒。同时从这张图上还可以看出,随着下载文件变大,请求耗时并不是线形增长的,这是由于一次请求大部分时间都消耗在建立连接上,而真正接收数据只占用了极少时间,这个问题不在本篇文章的讨论范围,所以不多说,有兴趣的读者可以移步http://segmentfault.com/t/ios进一步讨论。
4、原理分析
ASI的性能似乎全面优于AFN,那下边从二者的实现原理上看一下到底是什么原因造成这种差距。ASI基于CFNetwork框架开发,而AFN基于NSURL,底层的区别是导致二者性能差距的重要原因之一。
图9,ASI和AFN以及底层框架的关系
我们知道所有网络通信的基础是Socket,一个Socket与另一个连接并传送数据。BSD Socket是一类最常见的Socket抽象接口。
Core Foundation框架中的CFSocket就是基于BSD Socket开发的。它几乎涵盖了BSD Socket的全部功能,更重要的是把Socket整合到事件的处理循环中。Core Founda-tion中较高层的CFStream是基于CFSocket开发的读写流支持。
CFNetwork是基于Core Foundation中CFStream的一个底层高性能网络框架,它由提供基础服务的CFSocketStream,支持HTTP协议的CFHTTP,基于CFHTTP用于身份认证的CFHTTPAuthentication和支持FTP协议的CFFTP组成。
正如图9所示,ASI是基于CFHTTP开发的一个组件;而AFN的基础——NSURL,也是基于CFNetwork开发的。也就是说ASI相比AFN更加底层,这就从一定程度上造成二者的性能差距。
另一个方面,虽然二者都使用NSOperation和NSOperationQueue实现但底层的区别也导致实现方式上有非常大的差别。
ASI的直接操作对象ASIHTTPRequest是NSOperation的子类,实现了NSCopying协议。在initialize和initWithURL:方法中初始化相关属性并配置一系列请求相关参数默认值。此外,ASIHTTPRequest还提供了一系列的实例方法用来配置请求对象。在异步请求的处理上,ASIHTTPRequest对象初始化结束后,在startAsynchronous方法中把对象加入共享操作队列。此后,包括创建CFHTTPMessageRef,也就是处理网络请求的主要对象(事实上是一个指向__CFHTTPMessage结构的指针),在内的所有操作都在ASIHTTPRequest对象所属的子线程中完成。
AFN的直接操作对象AFHTTPClient不同于ASI,是一个实现了NSCoding和NSCopying协议的NSObject子类。AFHTTPClient是一个封装了一系列操作方法的“工具类”,处理请求的操作类是一系列单独的,基于NSOperation封装的,AFURLConnectionOperation的子类。AFN的示例代码中通过一个静态方法,使用dispatch_once()的方式创建AFHTTPClient的共享实例,这也是官方建议的使用方法。在创建AFHTTPClient的初始化方法中,创建了OperationQueue并设置一系列参数默认值。在getPath:parameters:success:failure方法中创建NSURLRequest,以NSURLRequest对象实例作为参数,创建一个NSOperation,并加入在初始化发方中创建的NSOperationQueue。以上操作都是在主线程中完成的。在NSOperation的start方法中,以此前创建的NSURLRequest对象为参数创建NSURLConnection并开启连结。
在异步回调的处理上二者也有区别,ASI采取的是CFHTTP请求完成,直接回调ASIHTTPRequest的实例方法,通过储存的实例对象记录的信息完成Delegate模式或Block模式的回调。而AFN则直接使用了NSOperation的completionBlock属性。
这些实现方式也可以看出,ASI显得更加底层,并没有过多使用Cocoa框架中已经封装的API,而AFN则更加实用主义,逻辑简单清晰,大量使用了框架API。这一点也是造成二者性能差别的原因之一。
总结
通过以上的对比,基本可以这样评价:AFN适合逻辑简单的应用,或者更适合开发资源尚不丰富的团队,因为AFN的易用性要比ASI好很多,而这样的应用(或团队)对底层网络控件的定制化要求也非常低。ASI更适合已经发展了一段时间的应用,或者开发资源相对丰富的团队,因为往往这些团队(或他们的应用)已经积累了一定的经验,无论是产品上还是技术上的。需求复杂度就是在这种时候高起来,而且底层订制的需求也越来越多,此时AFN就很难满足需求,需要牺牲一定的易用性,使用ASI作为网络底层控件。SegmentFault开源客户端现在被设计为一款简单的阅读客户端,几乎没有定制要求,因此,目前我选择了AFN作为网络控件。
以上对ASI和AFN两款最常用的iOS底层网络控件做了初步的介绍,要更深入的了解两款控件,还需要大家继续研究各自的源码。大家遇到任何关于iOS的技术问题都可以在http://segmentfault.com/t/ios进行讨论。另外大家也可以持续关注SegmentFault的开源客户端https://github.com/gaosboy/iOSSF,与更多的开发者共同探讨iOS开发技术。
作者简介
高嘉峻(微博:@gaosboy),SegmentFault.com联合创始人,杭州iOS开发者沙龙发起人,资深iOS开发者。
那么,大家最常用的组件是什么?这些组件是如何提升开发效率和稳定性的?哪一款组件适合自己,是 AFNetworking(AFN)还是 ASIHTTPRequest(ASI)?几乎每一个iOS互联网应用开发者都会面对这样的选择题,要从这两个最常用的组件里选出一个好的还真不是那么容易。
单单从两个控件版本提交的时间节点来看,AFN的第一个提交是2011年的1月1日,那个时候ASI早已是1.8+的版本了;而当AFN发布1.0版,2012年10月份的时候,ASI早早的已经停止更新了。这样看起来,AFN是ASI的继任者,似乎不存在之前提到的选择困难的问题,而事实并非如此。本文将从用法、功能、性能和原理几个方面对二者进行简单对比,看看二者之间到底存在着怎样的区别,到底应该如何选择。
1、用法对比
首先,从推荐用法上就可以看出二者设计理念上大有不同。
图1,AFN的示例代码,发起请求(出自:Posts.m)
AFN官方推荐的使用方法是,为一系列相关的请求定义一个HTTPClient,共用一个BaseURL。每次请求把URL中除BaseURL的Path部分做为参数传给HTTPClient的静态方法,并注册一个Block用于回调。
图2,ASI示例代码,发起异步请求(出自:ASIHTTPRequestTests.m)
ASI推荐使用方法就非常传统,每一个请求都由构造方法初始化一个(共享)实例,通过这个实例配置参数并发起请求。ASI最初使用delegate模式回调,在iOS SDK支持Block之后也提供了注册Block的实例方法。
以上引用的两段代码都出自各自项目的示例工程。对比两段代码可以很清楚的看出,同样是发起一个最普通的异步请求,使用AFN只需要调用一个静态方法,但代码可读性较差;而ASI的示例看起来更清晰,但需要调用多个实例方法才能完成一次请求。AFN的设计更加工程化,或者说对使用者更友好,而ASI的设计更经典,典型的OOP。
除了初级用法上的区别,二者的高级功能和对扩展的支持也颇有不同。
2、高级功能
AFN只封装了一些常用功能,满足基本需求,而直接忽略了很多扩展功能。例如:AFN默认没有封装同步请求,如果开发者需要使用同步请求,则需要重写getPath:parameters:success:failure方法,对AFHTTPRequestOperation进行同步处理;而ASI则是直接通过调用一个startSynchronous方法。
此外AFN针对JSON、XML、PList和Image四种数据结构封装了各自处理器,开发者可以把处理器注册到操作队列中,直接在回调方法中获得格式化以后的数据。在示例工程中就使用了JSON处理器:把AFJSONRequestOperation注册到操作队列里。
图3,AFN示例代码,初始化自定义的HTTPClient(出自:AFAppDotNetAPIClient.m)
而ASI在这方面显得更原始,没有针对任何数据类型做特别封装,只是预留了各种接口和工具供开发者自行扩展。ASI比AFN提供更多扩展功能还有一个原因,它把许多内部用到的功能也抽象成类和方法。例如:
ASIHTTPRequestDataCompressor和ASIHTTPRequestDataDecompressor两个类,只用于压缩本地文件,构造POST Body和解压缩返回数据,但这两个类仍然被设计为独立功能,提供了对多种数据结构进行压缩和解压缩的方法。
对比二者的高级功能和对扩展的支持后,可以看出AFN把初级功能(或者叫常用功能)做到了90分。调用方式够简单,处理器够丰富,使用者用起来可以算是轻松加愉快。但它放弃了对高级功能的支持,要满足较复杂的需求,就要大费周折了,在这方面最多只有40分。而ASI显然不满足于做好初级功能,但为了提供更丰富的可扩展接口,导致初级功能用起来也要花上一些力气。虽然ASI单独提供了支持Amazon S3和Rackspace Cloud Files的控件,但对于生在红旗下的我朝开发者来说基本没用,所以在初级功能的支持上ASI能得个70分,牺牲了初级功能的易用性,换来的是良好的扩展性,在高级功能的使用上远远好于AFN,也能得个70分。
从使用角度对比过后,基本上对这两个项目有一个整体上的认识,再深入下去看看二者的性能如何。
3、性能对比
我分别用AFN和ASI进行了测试,测试环境如下:iPhone5,联通3G信号全满,室内静止状态,请求国内双线机房独立服务器的静态文件,1~20K共20个文件,每个文件请求20次,记录从创建请求到完全下载文件的耗时,结果如下:
图4,AFN连续访问1 ~ 20K文件耗时
图5,ASI连续访问1 ~ 20K文件耗时
图4是AFN的记录图,绿色为20次请求中耗时最久的一次,蓝色为耗时最短的一次,黄色为去除最大值和最小值的18次平均值。从这个图可以看出,AFN最开始创建对象耗时近2.5秒,随后稳定下来,在3K、7K、15K和20K时出现了抖动。图5是ASI做相同测试的结果,首次创建对象近2.25秒,略优于AFN,同样在5K、11K、13K、14K和16K发生了一些抖动,但抖动幅度似乎小于AFN,可见稳定性更好一些。
下边是把二者的测试结果放在一起的对比图,可以更直观的比较二者的区别。
图6,ASI和AFN耗时最大值对比
图6的最大值对比可以更明显的看出二者的抖动对比,ASI略好一些。
图7,ASI和AFN耗时最小值对比
图7的最小值对比可以看出,在每一个大小的测试中ASI的最佳性能似乎都要优于AFN。
图8,ASI和AFN耗时平均值对比
图8是耗时平均值的对比,更能够说明问题。文件小于12K的测试中ASI的性能优势并没有非常明显,超过12K以后,ASI优势开始明显起来,每一次请求都要比AFN节约20% ~ 30%,近0.1秒。同时从这张图上还可以看出,随着下载文件变大,请求耗时并不是线形增长的,这是由于一次请求大部分时间都消耗在建立连接上,而真正接收数据只占用了极少时间,这个问题不在本篇文章的讨论范围,所以不多说,有兴趣的读者可以移步http://segmentfault.com/t/ios进一步讨论。
4、原理分析
ASI的性能似乎全面优于AFN,那下边从二者的实现原理上看一下到底是什么原因造成这种差距。ASI基于CFNetwork框架开发,而AFN基于NSURL,底层的区别是导致二者性能差距的重要原因之一。
图9,ASI和AFN以及底层框架的关系
我们知道所有网络通信的基础是Socket,一个Socket与另一个连接并传送数据。BSD Socket是一类最常见的Socket抽象接口。
Core Foundation框架中的CFSocket就是基于BSD Socket开发的。它几乎涵盖了BSD Socket的全部功能,更重要的是把Socket整合到事件的处理循环中。Core Founda-tion中较高层的CFStream是基于CFSocket开发的读写流支持。
CFNetwork是基于Core Foundation中CFStream的一个底层高性能网络框架,它由提供基础服务的CFSocketStream,支持HTTP协议的CFHTTP,基于CFHTTP用于身份认证的CFHTTPAuthentication和支持FTP协议的CFFTP组成。
正如图9所示,ASI是基于CFHTTP开发的一个组件;而AFN的基础——NSURL,也是基于CFNetwork开发的。也就是说ASI相比AFN更加底层,这就从一定程度上造成二者的性能差距。
另一个方面,虽然二者都使用NSOperation和NSOperationQueue实现但底层的区别也导致实现方式上有非常大的差别。
ASI的直接操作对象ASIHTTPRequest是NSOperation的子类,实现了NSCopying协议。在initialize和initWithURL:方法中初始化相关属性并配置一系列请求相关参数默认值。此外,ASIHTTPRequest还提供了一系列的实例方法用来配置请求对象。在异步请求的处理上,ASIHTTPRequest对象初始化结束后,在startAsynchronous方法中把对象加入共享操作队列。此后,包括创建CFHTTPMessageRef,也就是处理网络请求的主要对象(事实上是一个指向__CFHTTPMessage结构的指针),在内的所有操作都在ASIHTTPRequest对象所属的子线程中完成。
AFN的直接操作对象AFHTTPClient不同于ASI,是一个实现了NSCoding和NSCopying协议的NSObject子类。AFHTTPClient是一个封装了一系列操作方法的“工具类”,处理请求的操作类是一系列单独的,基于NSOperation封装的,AFURLConnectionOperation的子类。AFN的示例代码中通过一个静态方法,使用dispatch_once()的方式创建AFHTTPClient的共享实例,这也是官方建议的使用方法。在创建AFHTTPClient的初始化方法中,创建了OperationQueue并设置一系列参数默认值。在getPath:parameters:success:failure方法中创建NSURLRequest,以NSURLRequest对象实例作为参数,创建一个NSOperation,并加入在初始化发方中创建的NSOperationQueue。以上操作都是在主线程中完成的。在NSOperation的start方法中,以此前创建的NSURLRequest对象为参数创建NSURLConnection并开启连结。
在异步回调的处理上二者也有区别,ASI采取的是CFHTTP请求完成,直接回调ASIHTTPRequest的实例方法,通过储存的实例对象记录的信息完成Delegate模式或Block模式的回调。而AFN则直接使用了NSOperation的completionBlock属性。
这些实现方式也可以看出,ASI显得更加底层,并没有过多使用Cocoa框架中已经封装的API,而AFN则更加实用主义,逻辑简单清晰,大量使用了框架API。这一点也是造成二者性能差别的原因之一。
总结
通过以上的对比,基本可以这样评价:AFN适合逻辑简单的应用,或者更适合开发资源尚不丰富的团队,因为AFN的易用性要比ASI好很多,而这样的应用(或团队)对底层网络控件的定制化要求也非常低。ASI更适合已经发展了一段时间的应用,或者开发资源相对丰富的团队,因为往往这些团队(或他们的应用)已经积累了一定的经验,无论是产品上还是技术上的。需求复杂度就是在这种时候高起来,而且底层订制的需求也越来越多,此时AFN就很难满足需求,需要牺牲一定的易用性,使用ASI作为网络底层控件。SegmentFault开源客户端现在被设计为一款简单的阅读客户端,几乎没有定制要求,因此,目前我选择了AFN作为网络控件。
以上对ASI和AFN两款最常用的iOS底层网络控件做了初步的介绍,要更深入的了解两款控件,还需要大家继续研究各自的源码。大家遇到任何关于iOS的技术问题都可以在http://segmentfault.com/t/ios进行讨论。另外大家也可以持续关注SegmentFault的开源客户端https://github.com/gaosboy/iOSSF,与更多的开发者共同探讨iOS开发技术。
作者简介
高嘉峻(微博:@gaosboy),SegmentFault.com联合创始人,杭州iOS开发者沙龙发起人,资深iOS开发者。
发表评论
-
xcode4.3下制作framework
2013-04-09 09:25 1984转自:xcode4.3下制作framework——(xc ... -
对比iOS中的四种数据存储
2013-04-07 16:13 1035摘自:infoq http://www.inf ... -
ios如何在当前工程中添加编辑新建的FramesWork (两个ios工程联调同样适用 )
2012-12-12 14:57 3163唐彬琪 可能很多大牛都见过FaceBook的three2 ... -
Xcode4快速Doxygen文档注释 — 简明图文教程
2012-12-03 17:28 1184转自:http://blog.chukong-inc.com/ ... -
如何让IOS应用从容地崩溃
2012-12-03 16:55 1104转自:http://blog.chukong-inc.c ... -
Git忽略文件(转载好文)
2012-11-21 11:29 1267摘自:http://cwind.iteye.com/bl ... -
iOS开发细节记录汇总
2012-11-13 14:56 10771. 模拟器网速调整: 限制时输入下面两行,根据需要修 ... -
iOS签名总结
2012-11-13 11:34 1953摘自:http://www.devdiv.com/iOS签名总 ... -
iPhone开发资源汇总
2012-11-13 14:50 2139很多ios效果,以及控件集合 http://code4app. ... -
模拟器与真机下ffmpeg的编译方法(总结版)
2012-11-13 14:51 1427模拟器与真机下ffmpeg的编译方法(总结版) 编译f ... -
开源的电子书阅读器项目
2012-11-07 14:57 1873iphone平台上开源的电子书阅读器项目: https ... -
iOS高效开发必备的10款Objective-C类库
2012-11-07 14:28 739这里列出的库等功能使开发更容易。如果你是一个iOS开发人员,在 ... -
iOS6.0框架及功能更新小结
2012-11-07 14:58 788iOS6.0框架及功能更新小结 1. Maps 替换 ... -
const、static的理解
2012-11-07 14:58 1262对于C/C++语言来讲, const就是只读的意思,只在声明中 ... -
ios控件自定义指引
2012-11-07 14:58 1105转自:http://leakswww.devdiv ...
相关推荐
本文将深入探讨三种常见的iOS第三方网络通讯库:ASIHTTPRequest、AFNetworking和MKNetworkKit,帮助开发者理解它们的特点和使用场景,以选择最适合项目需求的网络库。 首先,ASIHTTPRequest是由Sam Soffes开发的,...
【iOS开发源码系列】网络组件源代码资源目录:【】【iOS网络】AFNetworking【】【iOS网络】AFResumingDownload【】【iOS网络】apn-proxy【】【iOS网络】ASFBPostController【】【iOS网络】ASIHTTPRequest【】...
- **简介**:AFNetworking 是一个非常流行的 iOS 和 Mac 网络通信库,它基于 `NSURLConnection` 和 `NSURLSession` 构建,提供了简单易用的 API 接口。 - **特点**: - 支持 HTTP 请求的各种类型,如 GET、POST、...
24. **iOS第三方开源库**:如AFNetworking、MBProgressHUD等,熟练运用可以提高开发效率。 25. **UI自动化测试**:使用Instruments进行性能测试和UI自动化测试,确保产品质量。 具备以上技能的iOS开发者不仅能应对...
- AFNetworking与ASIHttpRequest的区别,AFNetworking更现代,支持异步请求,ASIHttpRequest已停止更新。 9. **算法与数据结构**: - 排序算法,如快速排序、归并排序等。 - 单链表逆转和排序。 - 数组操作,如...
在iOS应用开发中,网络请求是不可或缺的部分,它使得应用程序能够与服务器进行数据交互,实现诸如获取信息、上传数据等功能。在iOS的开源世界里,ASIHTTPRequest是一个广为使用的HTTP请求库,尽管它已经不再维护,但...
ASIHTTPRequest 是一个Objective-C编写的网络请求库,用于iOS和Mac OS X平台,它使得处理HTTP请求变得更加简单。这个库由Sam Soffes创建并维护,尽管现在已被更现代的解决方案如Alamofire取代,但在一些旧项目或学习...
4. **使用现代的网络库**:`ASIHTTPRequest`库已经不再维护,推荐使用`NSURLSession`或者第三方库如`Alamofire`或`AFNetworking`。 5. **使用Cell的`prepareForReuse`方法**:在Cell被复用之前,清空Cell的内容,...
ASIHTTP库是一个经典的Objective-C编写的网络请求框架,主要用于iOS和Mac OS X平台。这个库在iOS开发领域曾经非常流行,特别是在HTTP请求处理方面,它提供了简单易用的API,支持GET、POST等多种HTTP方法,同时也包含...