AFNetworking源码分析

简述

在iOS开发中,与直接使用苹果框架中提供的NSURLConnection或NSURLSession进行网络请求相比,使用AFNetworking会有哪些好处?当同时发起多个网络请求AFNetworking是如何实现并发的,在并发的时候,AFNetworking是如何管理线程的?苹果重构NSURLConnetion推出新的网络加载系统NSURLSession解决了什么问题或者是与NSURLConnection相比NSURLSession有好些好处?上面问题的答案会贯穿在这篇文章中(本篇文章只涉及了与操作队列,多线程相关的分析)。

不用网络框架进行网络请求

NSURLConnection的简单使用(下面的代码均只为了演示,更详细的使用方法请自行谷歌)

NSURLConnection提供了两个类方法用于发起同步或异步请求,对于异步请求来说必然是在子线程中发起,若在主线程中发起异步网络请求会造成主线程阻塞,界面无响应,这就涉及到多线程编程。但多线程编程是一门非常细致的活,要考虑很多的问题,比如线程的生命周期,多线程资源竞争,加锁,避免死锁,稍不留意就会踩到坑里。好在苹果的接口使用极其方便,你甚至不需要理解多线程就能轻松使用上多线程了,发起异步请求的接口内部已经实现了多线程相关的操作。越是高级的接口,其隐藏的细节就越多,对于开发者来说当然是很方便,但若还能对其实现有所理解那就更完美了。当子线程发起了异步请求后会阻塞以等待网络响应,那应该由谁来处理网络响应呢?苹果提供了两种方式,一种是block,提供一个处理响应的block回调。一种是代理,使用代理的话就必须实现NSURLConnectionDelegate这个协议。你只需要在有网络请求的UIViewController中调用NSURLConnection提供的类方法就可以了。但如果你的项目中有不止一个UIViewController或者有的UIViewController中都不止一个请求的话,你就需要在每一个有网络请求的UIViewController中这样写。这样写会有什么问题呢?首先会造成软件结构不清晰,没有剥离出网络层,其次没有实现网络请求统一管理,无法实现取消所有网络请求等功能,再有会出现很多重复的代码,没有让公用功能形成模块,进行复用。当然为了解决这些问题你也可以自己实现自己的网络框架。

使用NSURLConnection版本的AFNetworking

使用网络框架的好处在于可以将分散在各个视图控制器中的网络请求统一起来模块化形成网络层,降低与数据层和表现层的耦合。AFNetworking就做了这样的工作。网络上已经有很多分析基于NSURLConnection实现的AFNetworking 2.x的源代码,这里只简单说一下其实现整个流程,想要深入了解的请谷歌或查看其源代码。首先AFNetworking要解决实现接口统一和所有网络请求统一管理的问题。NSURLConnection发起有两种方式发起请求,分别是设置响应block和代理,那采用哪种方式能够实现网络请求统一管理呢?block肯定不行,因为传入响应回调block的[NSURLConnection sendAsynchronousRequest:queue:completionHandler:]方法会立即执行。那么只能使用设置响应代理这种方式了。具体实现是将网络请求继承于NSOperation,生产网络请求,然后再将这个网络请求加入操作队列里,剩下的所有与线程相关的操作都由这个操作队列去实现。越高级易容的接口就隐藏越多的实现细节,NSOperation隐藏了线程相关的所有细节,使得开发者只需关心构建什么样的操作。AFNetworking甚至隐藏了操作,操作队列的概念,使得开发者只需关心如何设置网络相关的请求参数,响应回调等,而不用再关心当多个网络请求如何进行统一管理,这些都已经由AFNetworking内部的操作队列属性完成了。那需要为每个请求创建一个线程来发起请求吗?基于NSURLConnection的AFNetworking是只创建了一条线程来发起所有请求并阻塞以等待响应。

重构推出的NSURLSession解决了NSURLConnection哪些问题

从2013年苹果发布重构后的加载系统NSURLSession,AFNetworking这个最受欢迎的网络框架也随之发布了基于NSURLSession的实现版本。这篇文章从 NSURLConnection 到 NSURLSession对NSURLSession的使用做了介绍。既然是对NSURLConnection进行的重构,那一定是解决了NSURLConnection存在的一些问题。苹果的接口以及其简单的形式呈现给开发者,尽量把复杂,容易出错的地方以简单的接口暴露出来,这使得用户能够参考文档很快上手,但这也有一些弊端,就是开发者对其中的原理不是很了解。越高级的接口越容易使用,但其隐蔽的实现细节就越多。相信在进行多线程编程的时候,很多开发者遇到过各种各样的坑,但在iOS平台上,苹果推出了GCD,NSperation等一系列接口可以让开发者完全可以只关注业务的实现,这些接口内部已经替开发者管理好了线程的创建,销毁,多线程资源竞争等需要开发者费很多精力的事情,甚至开发者不用对多线程理解透彻都能把多线程用得得心应手。NSURLConnection已经隐藏了线程相关的操作,已经给开发者减轻了很多负担。但NSURLConnectoin只隐藏了单个网络请求的线程的相关操作,并没有提供接口来解决多个网络请求时多个线程的管理问题,譬如当有多个网络请求时是否应该使用线程池来避免不停创建与销毁线程(这个可以有NSOperationQueue很好的解决)。并且NSURLConnection不是基于HTTP/2协议的,若使用NSURLConnection发起请求则每次请求都需要经过三次握手过程,可见NSURLConnection确实有很多可以优化的地方(我只发现这些)。NSURLConnection存在的无法将多个请求关联起来的问题已经很好的由AFNetworking解决了,所以推出的NSURLSession可以说是借鉴了AFNetworking的思想,并且可以从AFNetworking的源代码中很容易的看出来。基于NSURLConnection的AFNetworking需要让网络请求继承与NSOperation,然后再将该生成的网络请求加入操作队列中,但基于NSURLSessioin的AFNetworking只需要创建一个网络请求任务就可以了,原因在于,NSURLSession内部已经维护了两个操作队列,一个是处理session的相关回调,一个是处理响应相关的回调,所以说NSURLSession是借鉴了AFNetworking的继承于NSOperation和用单线程发起并等待响应的思想(这个会在后面给出证明)。

基于NSURLSession的AFNetworking的源码分析

下图是基于NSURLSession的AFNetworking的UML图(只为展示类之间的关联关系,并没有给出每个类的所有属性和方法):

AFNetworking.png

从该类图已经能够明白AFNetworking整个的工作流程。
下面进行代码分析,使用AFHTTPSessionManager进行网络请求的示例代码(具体的使用请参考AFNetworking的README文档):

AFHTTPSessionManager *manager = [AFHTTPSessionManager manager];
[manager GET:URL parameters:nil progress:nil success:^(NSURLSessionDataTask *_Nonnulltask, id _NullableresponseObject) {
  dispatch_async(dispatch_get_main_queue(), ^{
  //将子线程从网络拉取的数据用于主线程刷新视图
    });
  }failure:^(NSURLSessionDataTask*_Nullabletask,NSError*_Nonnullerror) {

}];

通过查看manager方法代码可以看到其实现最终是调用了父类AFURLSessionManager的initWithSessionConfiguration:方法,该方法代码片段如下:

self.sessionConfiguration = configuration;
self.operationQueue = [[NSOperationQueue alloc] init];
self.operationQueue.maxConcurrentOperationCount = 1;
self.session = [NSURLSession sessionWithConfiguration:self.sessionConfiguration delegate:self delegateQueue:self.operationQueue];
self.responseSerializer = [AFJSONResponseSerializer serializer];

可以看到AFNetworking对数据的解析方式默认是json解析。
这里设置的代理操作队列最大的并发操作数为1是让所有请求的发起和等待网络响应均在同一条线程中执行,而不用为每一个请求都新建一条线程,这样节约了很多资源。
在响应到达后会执行AFURLSessionManager的NSURLSessionDataDelegate协议的方法,[AFURLSessioinManager URLSession:dataTask:didReceiveData:]用于查找对应的响应代理,并将后续的数据处理如数据拼接转交给该代理。该方法的实现代码如下:

AFURLSessionManagerTaskDelegate *delegate = [self delegateForTask:dataTask];
[delegate URLSession:session dataTask:dataTask didReceiveData:data];

if (self.dataTaskDidReceiveData) {
    self.dataTaskDidReceiveData(session, dataTask, data);
}

在数据比较大时,改方法可能会多次执行。
当数据传输完成后会调用[AFURLSessioinManager URLSession:task:didCompleteWithError],该方法用于让对应的代理执行NSURLSessionTaskDelegate协议中的方法,并将该代理对象从字典中移除,源代码如下:

AFURLSessionManagerTaskDelegate *delegate = [self delegateForTask:task];

// delegate may be nil when completing a task in the background
if (delegate) {
    [delegate URLSession:session task:task didCompleteWithError:error];

    [self removeDelegateForTask:task];
}

if (self.taskDidComplete) {
    self.taskDidComplete(session, task, error);
}

随后代理执行URLSession:task:didCompleteWithError:,该方法把数据放到另一个由静态方法生成的url_session_manager_processing_queue操作队列中做数据解析,如json解析,并将解析后的数据回传到主线程或者你自己生成的操作队列里,通过通知中心将请求完成的消息传递到主线程去(后面会写一篇文章介绍通知中心的实现原理,并写一个类似的通知中心)。该方法源码片段如下:

dispatch_async(url_session_manager_processing_queue(), ^{
            NSError *serializationError = nil;
            responseObject = [manager.responseSerializer responseObjectForResponse:task.response data:[NSData dataWithData:self.mutableData] error:&serializationError];

            dispatch_group_async(manager.completionGroup ?: url_session_manager_completion_group(), manager.completionQueue ?: dispatch_get_main_queue(), ^{
                if (self.completionHandler) {
                    self.completionHandler(task.response, responseObject, serializationError);
                }
                
            dispatch_async(dispatch_get_main_queue(), ^{
                [[NSNotificationCenter defaultCenter] postNotificationName:AFNetworkingTaskDidCompleteNotification object:task userInfo:userInfo];
                });
            });
        });

整个流程可由下图表示:

流程图.png

所以NSURLSession的实现完全是借鉴了之前的AFNetworking,NSURLSession中维护了两个操作队列,一个用于处理发起请求,等待响应,一个用于处理响应到达后需要执行的回调,对数据进行操作。如果是使用AFHTTPSessionManager的manager方法,初始化session的操作队列的最大并发数为1,则与基于NSURLConnection的AFNetworking完全一样,所有请求和等待响应都在一条线程中执行,然后数据的解析在一个异步并发的操作队列中执行,当然你可以设置该操作队列的最大并发数。

总结

局限于自己的表述能力,文中可能有很多不通畅的地方,欢迎一起讨论。


欢迎关注我的简书,我会定期做一些技术分享:)

最后编辑于
©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 211,265评论 6 490
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 90,078评论 2 385
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 156,852评论 0 347
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 56,408评论 1 283
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 65,445评论 5 384
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 49,772评论 1 290
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 38,921评论 3 406
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 37,688评论 0 266
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 44,130评论 1 303
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 36,467评论 2 325
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 38,617评论 1 340
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 34,276评论 4 329
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 39,882评论 3 312
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 30,740评论 0 21
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 31,967评论 1 265
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 46,315评论 2 360
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 43,486评论 2 348

推荐阅读更多精彩内容