zoukankan      html  css  js  c++  java
  • iOS开发:AFNetworking和ASIHTTPRequest的比较

     

     
    标签: 

    it

     

    网络请求

     

    asihttprequest

     

    afnetworking

     
                      iOS开发:AFNetworking和ASIHTTPRequest的比较
                               ASI和AFN以及底层框架的关系 
     
     

    对比
    ASI AFN
    更新状态 2012年10月份,已经停止更新 持续更新中,目前已更新至2.0版
    介绍
    ASI的直接操作对象ASIHTTPRequest,是一个实现了了NSCopying协议的NSOperation子类。
    在initialize和initWithURL:方法中初始化相关属性并配置一系列请求相关参数默认值。此外,ASIHTTPRequest还提供了一系列的实例方法用来配置请求对象。
    AFN的直接操作对象AFHTTPClient,是一个实现了NSCoding和NSCopying协议的NSObject子类。AFHTTPClient是一个封装了一系列操作方法的“工具类”,处理请求的操作类是一系列单独的,基于NSOperation封装的,AFURLConnectionOperation的子类。
    线程处理模式
    每一个请求都由构造方法初始化一个(共享)实例,通过这个实例配置参数并发起请求。ASI最初使用delegate模式回调,在iOS SDK支持Block之后也提供了注册Block的实例方法。
    ASI采取的是CFHTTP请求完成,直接回调ASIHTTPRequest的实例方法,通过储存的实例对象记录的信息完成Delegate模式或Block模式的回调。
     
    在异步请求的处理上,ASIHTTPRequest对象初始化结束后,在startAsynchronous方法中把对象加入共享操作队列。此后,包括创建CFHTTPMessageRef,也就是处理网络请求的主要对象(事实上是一个指向__CFHTTPMessage结构的指针),在内的所有操作都在ASIHTTPRequest对象所属的子线程中完成。
    AFN的示例代码中通过一个静态方法,使用dispatch_once()的方式创建AFHTTPClient的共享实例,这也是官方建议的使用方法。在创建AFHTTPClient的初始化方法中,创建了OperationQueue并设置一系列参数默认值。在getPath:parameters:success:failure方法中创建NSURLRequest,以NSURLRequest对象实例作为参数,创建一个NSOperation,并加入在初始化发方中创建的NSOperationQueue。
    以上操作都是在主线程中完成的。在NSOperation的start方法中,以此前创建的NSURLRequest对象为参数创建NSURLConnection并开启连结。
    数据处理模式 ASI在这方面显得更原始,没有针对任何数据类型做特别封装,只是预留了各种接口和工具供开发者自行扩展。 AFN针对JSON、XML、PList和Image四种数据结构封装了各自处理器,开发者可以把处理器注册到操作队列中,直接在回调方法中获得格式化以后的数据。
    同步请求
    ASI则是直接通过调用一个startSynchronous方法。
     
    AFN默认没有封装同步请求,如果开发者需要使用同步请求,则需要重写getPath:parameters:success:failure方法,对AFHTTPRequestOperation进行同步处理
    异步回调的处理 【使用AFNetworking进行网络异步请求时,block:(void(^)代码块实际返回到UI主线程中。即使在子线程中使用AFNetWorking进行网络的异步请求,block:(void(^)代码块仍然返回到UI主线程中(AF框架,它里面已经create了异步线程 )。因此无论当前处在主线程还是子线程,异步返回均返回到UI主线程中。】
    为一系列相关的请求定义一个HTTPClient,共用一个BaseURL。每次请求把URL中除BaseURL的Path部分做为参数传给HTTPClient的静态方法,并注册一个Block用于回调。
    AFN则直接使用了NSOperation的completionBlock属性。
    基于的底层开发框架
     
    CFNetwork框架
    使用CFnetwork而不是Cocoa框架NSURL有几点好处。CFNetwork更加专注于网络协议,而NSURL更加专注于数据访问,比如通过HTTP或者FTP传输数据。尽管NSURL的确也提供了一些可配置功能,可是CFNetwork提供的要多的多。另外NSURL还需要你使用Objective_c。如果做不到这点的话,还是应该使用CFNetwork
    NSURL
    【使用iOS5.0 SDK NSURLConnection:
     1、进行网络同步请求(sendSynchronousRequest)时,调用该请求接口的操作在哪个线程,同步返回的网络结果就处于哪个线程,因此通常进行网络同步请求时,为了避免阻塞UI主线程,需要在子线程中进行网络请求;
    2、进行网络异步请求(sendAsynchronousRequest)时,block:(void(^)代码块实际返回到子线程中。因此,此时如需要向UI线程发送通知,则需要跳转到主线程中发送通知dispatch_async(dispatch_get_main_queue(), ^{});】
    底层开发矿建介绍
    CFNetwork是基于Core Foundation中CFStream的一个底层高性能网络框架,它由提供基础服务的CFSocketStream,支持HTTP协议的CFHTTP,基于CFHTTP用于身份认证的CFHTTPAuthentication和支持FTP协议的CFFTP组成。
    Core Foundation框架中的CFSocket就是基于BSD Socket开发的。它几乎涵盖了BSD Socket的全部功能,更重要的是把Socket整合到事件的处理循环中。Core Founda-tion中较高层的CFStream是基于CFSocket开发的读写流支持。
    如图所示,ASI是基于CFHTTP开发的一个组件;而AFN的基础——NSURL,也是基于CFNetwork开发的,也就是说ASI相比AFN更加底层。
    性能对比 AFN请求优于ASI  
    总结 ASI更适合已经发展了一段时间的应用,或者开发资源相对丰富的团队,因为往往这些团队(或他们的应用)已经积累了一定的经验,无论是产品上还是技术上的。需求复杂度就是在这种时候高起来,而且底层订制的需求也越来越多,此时AFN就很难满足需求,需要牺牲一定的易用性,使用ASI作为网络底层控件。 AFN适合逻辑简单的应用,或者更适合开发资源尚不丰富的团队,因为AFN的易用性要比ASI好很多,而这样的应用(或团队)对底层网络控件的定制化要求也非常低。
    以上分析与对比是根据本人查资料以及测试所得,若有不正确的地方还请大家指出,谢谢!
     

    另附:iOS开发:AFNetworking、MKNetworkKit和ASIHTTPRequest比较【下图为查找的资料,尚未验证
    iOS开发:AFNetworking和ASIHTTPRequest的比较
  • 相关阅读:
    C# 实现 Snowflake算法生成唯一性Id
    kafka可视化客户端工具(Kafka Tool)的基本使用(转)
    docker 安装kafka
    Model类代码生成器
    使用docker 部署rabbitmq 镜像
    Vue 增删改查 demo
    git 提交代码到库
    Android ble蓝牙问题
    mac 配置 ssh 到git (Could not resolve hostname github.com, Failed to connect to github.com port 443 Operation timed out)
    okhttp
  • 原文地址:https://www.cnblogs.com/iosdanran/p/5025652.html
Copyright © 2011-2022 走看看