AFNetworking到底作了什么
写在开头：ios
-
做为一个iOS开发，也许你不知道NSUrlRequest、不知道NSUrlConnection、也不知道NSURLSession...（说不下去了...怎么会什么都不知道...）可是你必定知道AFNetworking。git
-
大多数人习惯了只要是请求网络都用AF，可是你真的知道AF作了什么吗？为何咱们不用原生的NSURLSession而选择AFNetworking?github
-
本文将从源码的角度去分析AF的实际做用。web
或许看完这篇文章，你内心会有一个答案。编程
先从最新的AF3.x讲起吧：数组
-
首先，咱们就一块儿分析一下该框架的组成。缓存
将AF下载导入工程后，下面是其包结构，相对于2.x变得很是简单了：安全
AF代码结构图.png服务器
除去Support Files，能够看到AF分为以下5个功能模块：网络
-
网络通讯模块(AFURLSessionManager、AFHTTPSessionManger)
-
网络状态监听模块(Reachability)
-
网络通讯安全策略模块(Security)
-
网络通讯信息序列化/反序列化模块(Serialization)
-
对于iOS UIKit库的扩展(UIKit)
其核心固然是网络通讯模块NSURLSessionManager。你们都知道，AF3.x是基于NSURLSession来封装的。因此这个类围绕着NSURLSession作了一系列的封装。而其他的四个模块，均是为了配合网络通讯或对已有UIKit的一个扩展工具包。
这五个模块所对应的类的结构关系图以下所示：
AF架构图.png
其中AFHTTPSessionManager是继承于NSURLSessionManager的，咱们通常作网络请求都是用AFHTTPSessionManager，可是它自己是没有作实事的，只是把一些请求逻辑分发给父类AFURLSessionManager或者其它类去作。
首先咱们简单的写个get请求：
|
1
2
3
4
|
AFHTTPSessionManager *manager = [[AFHTTPSessionManager alloc]init];
[manager GET:@
"http://localhost"
parameters:nil progress:nil success:^(NSURLSessionDataTask * _Nonnull task, id _Nullable responseObject) {
} failure:^(NSURLSessionDataTask * _Nullable task, NSError * _Nonnull error) {
}];
|
首先咱们咱们调用了初始化方法生成了一个manager，咱们点进去看看初始化作了什么:
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
|
- (instancetype)init {
return
[self initWithBaseURL:nil];
}
- (instancetype)initWithBaseURL:(NSURL *)url {
return
[self initWithBaseURL:url sessionConfiguration:nil];
}
- (instancetype)initWithSessionConfiguration:(NSURLSessionConfiguration *)configuration {
return
[self initWithBaseURL:nil sessionConfiguration:configuration];
}
- (instancetype)initWithBaseURL:(NSURL *)url
sessionConfiguration:(NSURLSessionConfiguration *)configuration
{
self = [
super
initWithSessionConfiguration:configuration];
if
(!self) {
return
nil;
}
//对传过来的BaseUrl进行处理，截去url最后的/
if
([[url path] length] > 0 && ![[url absoluteString] hasSuffix:@
"/"
]) {
url = [url URLByAppendingPathComponent:@
""
];
}
self.baseURL = url;
self.requestSerializer = [AFHTTPRequestSerializer serializer];
self.responseSerializer = [AFJSONResponseSerializer serializer];
return
self;
}
|
-
初始化都调用到- (instancetype)initWithBaseURL:(NSURL *)url sessionConfiguration:(NSURLSessionConfiguration *)configuration方法中来了。
-
其实初始化方法都调用父类的初始化方法。父类也就是AF3.x最最核心的类AFHTTPSessionManager。几乎全部的类都是围绕着这个类在处理业务逻辑。
-
除此以外，方法中把baseURL存了起来，还生成了一个请求序列对象和一个响应序列对象。后面再细说这两个类是干什么用的。
直接来到父类AFURLSessionManager的初始化方法：
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
|
- (instancetype)init {
return
[self initWithSessionConfiguration:nil];
}
- (instancetype)initWithSessionConfiguration:(NSURLSessionConfiguration *)configuration {
self = [
super
init];
if
(!self) {
return
nil;
}
if
(!configuration) {
configuration = [NSURLSessionConfiguration defaultSessionConfiguration];
}
self.sessionConfiguration = configuration;
self.operationQueue = [[NSOperationQueue alloc] init];
//queue并发线程数设置为1
self.operationQueue.maxConcurrentOperationCount = 1;
//注意代理，代理的继承，实际上NSURLSession去判断了，你实现了哪一个方法会去调用，包括子代理的方法！
self.session = [NSURLSession sessionWithConfiguration:self.sessionConfiguration delegate:self delegateQueue:self.operationQueue];
//各类响应转码
self.responseSerializer = [AFJSONResponseSerializer serializer];
//设置默认安全策略
self.securityPolicy = [AFSecurityPolicy defaultPolicy];
#if !TARGET_OS_WATCH
self.reachabilityManager = [AFNetworkReachabilityManager sharedManager];
#endif
// 设置存储NSURL task与AFURLSessionManagerTaskDelegate的词典（重点，在AFNet中，每个task都会被匹配一个AFURLSessionManagerTaskDelegate 来作task的delegate事件处理） ===============
self.mutableTaskDelegatesKeyedByTaskIdentifier = [[NSMutableDictionary alloc] init];
// 设置AFURLSessionManagerTaskDelegate 词典的锁，确保词典在多线程访问时的线程安全
self.lock = [[NSLock alloc] init];
self.lock.name = AFURLSessionManagerLockName;
// 置空task关联的代理
[self.session getTasksWithCompletionHandler:^(NSArray *dataTasks, NSArray *uploadTasks, NSArray *downloadTasks) {
for
(NSURLSessionDataTask *task
in
dataTasks) {
[self addDelegateForDataTask:task uploadProgress:nil downloadProgress:nil completionHandler:nil];
}
for
(NSURLSessionUploadTask *uploadTask
in
uploadTasks) {
[self addDelegateForUploadTask:uploadTask progress:nil completionHandler:nil];
}
for
(NSURLSessionDownloadTask *downloadTask
in
downloadTasks) {
[self addDelegateForDownloadTask:downloadTask progress:nil destination:nil completionHandler:nil];
}
}];
return
self;
}
|
-
这个就是最终的初始化方法了，注释应该写的很清楚，惟一须要说的就是三点：
-
self.operationQueue.maxConcurrentOperationCount = 1;这个operationQueue就是咱们代理回调的queue。这里把代理回调的线程并发数设置为1了。至于这里为何要这么作，咱们先留一个坑，等咱们讲完AF2.x以后再来分析这一块。
-
第二就是咱们初始化了一些属性，其中包括self.mutableTaskDelegatesKeyedByTaskIdentifier，这个是用来让每个请求task和咱们自定义的AF代理来创建映射用的，其实AF对task的代理进行了一个封装，而且转发代理到AF自定义的代理，这是AF比较重要的一部分，接下来咱们会具体讲这一块。
-
第三就是下面这个方法：
|
1
2
|
[self.session getTasksWithCompletionHandler:^(NSArray *dataTasks, NSArray *uploadTasks, NSArray *downloadTasks) {
}];
|
首先说说这个方法是干什么用的：这个方法用来异步的获取当前session的全部未完成的task。其实讲道理来讲在初始化中调用这个方法应该里面一个task都不会有。咱们打断点去看，也确实如此，里面的数组都是空的。可是想一想也知道，AF大神不会把一段没用的代码放在这吧。因此我大胆猜想，多是当咱们重复去初始化session的时候（固然咱们实际也不会这么作），会有新的session指向旧的有未完成task的session。为了排除这种不肯定性因素，因此在初始化的时候把里面绑定的代理之类的东西都置为nil了。或许这就是防护性编程思想的一种体现吧。
初始化方法到这就所有完成了。
分割图.png
接着咱们来看看网络请求:
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
|
- (NSURLSessionDataTask *)GET:(NSString *)URLString
parameters:(id)parameters
progress:(void (^)(NSProgress * _Nonnull))downloadProgress
success:(void (^)(NSURLSessionDataTask * _Nonnull, id _Nullable))success
failure:(void (^)(NSURLSessionDataTask * _Nullable, NSError * _Nonnull))failure
{
//生成一个task
NSURLSessionDataTask *dataTask = [self dataTaskWithHTTPMethod:@
"GET"
URLString:URLString
parameters:parameters
uploadProgress:nil
downloadProgress:downloadProgress
success:success
failure:failure];
//开始网络请求
[dataTask resume];
return
dataTask;
}
|
方法走到类AFHTTPSessionManager中来，调用父类，也就是咱们整个AF3.x的核心类AFURLSessionManager的方法，生成了一个系统的NSURLSessionDataTask实例，而且开始网络请求。
咱们继续往父类里看，看看这个方法到底作了什么：
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
|
- (NSURLSessionDataTask *)dataTaskWithHTTPMethod:(NSString *)method
URLString:(NSString *)URLString
parameters:(id)parameters
uploadProgress:(nullable void (^)(NSProgress *uploadProgress)) uploadProgress
downloadProgress:(nullable void (^)(NSProgress *downloadProgress)) downloadProgress
success:(void (^)(NSURLSessionDataTask *, id))success
failure:(void (^)(NSURLSessionDataTask *, NSError *))failure
{
NSError *serializationError = nil;
//把参数，还有各类东西转化为一个request
NSMutableURLRequest *request = [self.requestSerializer requestWithMethod:method URLString:[[NSURL URLWithString:URLString relativeToURL:self.baseURL] absoluteString] parameters:parameters error:&serializationError];
if
(serializationError) {
if
(failure) {
#pragma clang diagnostic push
#pragma clang diagnostic ignored "-Wgnu"
//若是解析错误，直接返回
dispatch_async(self.completionQueue ?: dispatch_get_main_queue(), ^{
failure(nil, serializationError);
});
#pragma clang diagnostic pop
}
return
nil;
}
__block NSURLSessionDataTask *dataTask = nil;
dataTask = [self dataTaskWithRequest:request
uploadProgress:uploadProgress
downloadProgress:downloadProgress
completionHandler:^(NSURLResponse * __unused response, id responseObject, NSError *error) {
if
(error) {
if
(failure) {
failure(dataTask, error);
}
}
else
{
if
(success) {
success(dataTask, responseObject);
}
}
}];
return
dataTask;
}
|
-
这个方法作了两件事：
1.用self.requestSerializer和各类参数去获取了一个咱们最终请求网络须要的NSMutableURLRequest实例。
2.调用另一个方法dataTaskWithRequest去拿到咱们最终须要的NSURLSessionDataTask实例，而且在完成的回调里，调用咱们传过来的成功和失败的回调。
-
注意下面这个方法，咱们经常使用来 push pop搭配，来忽略一些编译器的警告：
|
1
2
3
|
#pragma clang diagnostic push
#pragma clang diagnostic ignored "-Wgnu"
#pragma clang diagnostic pop
|
这里是用来忽略：？带来的警告，具体的各类编译器警告描述，能够参考这篇：各类编译器的警告。
-
说到底这个方法仍是没有作实事，咱们继续到requestSerializer方法里去看，看看AF到底如何拼接成咱们须要的request的：
接着咱们跑到AFURLRequestSerialization类中：
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
|
- (NSMutableURLRequest *)requestWithMethod:(NSString *)method
URLString:(NSString *)URLString
parameters:(id)parameters
error:(NSError *__autoreleasing *)error
{
//断言，debug模式下，若是缺乏改参数，crash
NSParameterAssert(method);
NSParameterAssert(URLString);
NSURL *url = [NSURL URLWithString:URLString];
NSParameterAssert(url);
NSMutableURLRequest *mutableRequest = [[NSMutableURLRequest alloc] initWithURL:url];
mutableRequest.HTTPMethod = method;
//将request的各类属性循环遍历
for
(NSString *keyPath
in
AFHTTPRequestSerializerObservedKeyPaths()) {
//若是本身观察到的发生变化的属性，在这些方法里
if
([self.mutableObservedChangedKeyPaths containsObject:keyPath]) {
//把给本身设置的属性给request设置
[mutableRequest setValue:[self valueForKeyPath:keyPath] forKey:keyPath];
}
}
//将传入的parameters进行编码，并添加到request中
mutableRequest = [[self requestBySerializingRequest:mutableRequest withParameters:parameters error:error] mutableCopy];
return
mutableRequest;
}
|
-
讲一下这个方法，这个方法作了3件事：
1）设置request的请求类型，get,post,put...等
2）往request里添加一些参数设置，其中AFHTTPRequestSerializerObservedKeyPaths()是一个c函数，返回一个数组，咱们来看看这个函数:
|
1
2
3
4
5
6
7
8
9
10
11
|
static NSArray * AFHTTPRequestSerializerObservedKeyPaths() {
static NSArray *_AFHTTPRequestSerializerObservedKeyPaths = nil;
static dispatch_once_t onceToken;
// 此处须要observer的keypath为allowsCellularAccess、cachePolicy、HTTPShouldHandleCookies
// HTTPShouldUsePipelining、networkServiceType、timeoutInterval
dispatch_once(&onceToken, ^{
_AFHTTPRequestSerializerObservedKeyPaths = @[NSStringFromSelector(@selector(allowsCellularAccess)), NSStringFromSelector(@selector(cachePolicy)), NSStringFromSelector(@selector(HTTPShouldHandleCookies)), NSStringFromSelector(@selector(HTTPShouldUsePipelining)), NSStringFromSelector(@selector(networkServiceType)), NSStringFromSelector(@selector(timeoutInterval))];
});
//就是一个数组里装了不少方法的名字,
return
_AFHTTPRequestSerializerObservedKeyPaths;
}
|
其实这个函数就是封装了一些属性的名字，这些都是NSUrlRequest的属性。
再来看看self.mutableObservedChangedKeyPaths,这个是当前类的一个属性：
|
1
|
@property (readwrite, nonatomic, strong) NSMutableSet *mutableObservedChangedKeyPaths;
|
在-init方法对这个集合进行了初始化，而且对当前类的和NSUrlRequest相关的那些属性添加了KVO监听：
|
1
2
3
4
5
6
7
8
|
//每次都会重置变化
self.mutableObservedChangedKeyPaths = [NSMutableSet set];
//给这本身些方法添加观察者为本身，就是request的各类属性，set方法
for
(NSString *keyPath
in
AFHTTPRequestSerializerObservedKeyPaths()) {
if
([self respondsToSelector:NSSelectorFromString(keyPath)]) {
[self addObserver:self forKeyPath:keyPath options:NSKeyValueObservingOptionNew context:AFHTTPRequestSerializerObserverContext];
}
}
|
KVO触发的方法：
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
|
-(void)observeValueForKeyPath:(NSString *)keyPath
ofObject:(__unused id)object
change:(NSDictionary *)change
context:(void *)context
{
//当观察到这些set方法被调用了，并且不为Null就会添加到集合里，不然移除
if
(context == AFHTTPRequestSerializerObserverContext) {
if
([change[NSKeyValueChangeNewKey] isEqual:[NSNull
null
]]) {
[self.mutableObservedChangedKeyPaths removeObject:keyPath];
}
else
{
[self.mutableObservedChangedKeyPaths addObject:keyPath];
}
}
}
|
至此咱们知道self.mutableObservedChangedKeyPaths其实就是咱们本身设置的request属性值的集合。
接下来调用：
|
1
|
[mutableRequest setValue:[self valueForKeyPath:keyPath] forKey:keyPath];
|
用KVC的方式，把属性值都设置到咱们请求的request中去。
3）把须要传递的参数进行编码，而且设置到request中去：
//将传入的parameters进行编码，并添加到request中
|
1
|
mutableRequest = [[self requestBySerializingRequest:mutableRequest withParameters:parameters error:error] mutableCopy];
|
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
|
- (NSURLRequest *)requestBySerializingRequest:(NSURLRequest *)request
withParameters:(id)parameters
error:(NSError *__autoreleasing *)error
{
NSParameterAssert(request);
NSMutableURLRequest *mutableRequest = [request mutableCopy];
//从本身的head里去遍历，若是有值则设置给request的head
[self.HTTPRequestHeaders enumerateKeysAndObjectsUsingBlock:^(id field, id value, BOOL * __unused stop) {
if
(![request valueForHTTPHeaderField:field]) {
[mutableRequest setValue:value forHTTPHeaderField:field];
}
}];
//来把各类类型的参数，array dic set转化成字符串，给request
NSString *query = nil;
if
(parameters) {
//自定义的解析方式
if
(self.queryStringSerialization) {
NSError *serializationError;
query = self.queryStringSerialization(request, parameters, &serializationError);
if
(serializationError) {
if
(error) {
*error = serializationError;
}
return
nil;
}
}
else
{
//默认解析方式
switch
(self.queryStringSerializationStyle) {
case
AFHTTPRequestQueryStringDefaultStyle:
query = AFQueryStringFromParameters(parameters);
break
;
}
}
}
//最后判断该request中是否包含了GET、HEAD、DELETE（都包含在HTTPMethodsEncodingParametersInURI）。由于这几个method的quey是拼接到url后面的。而POST、PUT是把query拼接到http body中的。
if
([self.HTTPMethodsEncodingParametersInURI containsObject:[[request HTTPMethod] uppercaseString]]) {
if
(query && query.length > 0) {
mutableRequest.URL = [NSURL URLWithString:[[mutableRequest.URL absoluteString] stringByAppendingFormat:mutableRequest.URL.query ? @
"&%@"
: @
"?%@"
, query]];
}
}
else
{
//post put请求
// #2864: an empty string is a valid x-www-form-urlencoded payload
if
(!query) {
query = @
""
;
}
if
(![mutableRequest valueForHTTPHeaderField:@
"Content-Type"
]) {
[mutableRequest setValue:@
"application/x-www-form-urlencoded"
forHTTPHeaderField:@
"Content-Type"
];
}
//设置请求体
[mutableRequest setHTTPBody:[query dataUsingEncoding:self.stringEncoding]];
}
return
mutableRequest;
}
|
这个方法作了3件事：
1.从self.HTTPRequestHeaders中拿到设置的参数，赋值要请求的request里去
2.把请求网络的参数，从array dic set这些容器类型转换为字符串，具体转码方式，咱们可使用自定义的方式，也能够用AF默认的转码方式。自定义的方式没什么好说的，想怎么去解析由你本身来决定。咱们能够来看看默认的方式：
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
|
NSString * AFQueryStringFromParameters(NSDictionary *parameters) {
NSMutableArray *mutablePairs = [NSMutableArray array];
//把参数给AFQueryStringPairsFromDictionary，拿到AF的一个类型的数据就一个key，value对象，在URLEncodedStringValue拼接keyValue，一个加到数组里
for
(AFQueryStringPair *pair
in
AFQueryStringPairsFromDictionary(parameters)) {
[mutablePairs addObject:[pair URLEncodedStringValue]];
}
//拆分数组返回参数字符串
return
[mutablePairs componentsJoinedByString:@
"&"
];
}
NSArray * AFQueryStringPairsFromDictionary(NSDictionary *dictionary) {
//往下调用
return
AFQueryStringPairsFromKeyAndValue(nil, dictionary);
}
NSArray * AFQueryStringPairsFromKeyAndValue(NSString *key, id value) {
NSMutableArray *mutableQueryStringComponents = [NSMutableArray array];
// 根据须要排列的对象的description来进行升序排列，而且selector使用的是compare:
// 由于对象的description返回的是NSString，因此此处compare:使用的是NSString的compare函数
// 即@[@"foo", @"bar", @"bae"] ----> @[@"bae", @"bar",@"foo"]
NSSortDescriptor *sortDescriptor = [NSSortDescriptor sortDescriptorWithKey:@
"description"
ascending:YES selector:@selector(compare:)];
//判断vaLue是什么类型的，而后去递归调用本身，直到解析的是除了array dic set之外的元素，而后把获得的参数数组返回。
if
([value isKindOfClass:[NSDictionary class]]) {
NSDictionary *dictionary = value;
// Sort dictionary keys to ensure consistent ordering in query string, which is important when deserializing potentially ambiguous sequences, such as an array of dictionaries
//拿到
for
(id nestedKey
in
[dictionary.allKeys sortedArrayUsingDescriptors:@[ sortDescriptor ]]) {
id nestedValue = dictionary[nestedKey];
if
(nestedValue) {
[mutableQueryStringComponents addObjectsFromArray:AFQueryStringPairsFromKeyAndValue((key ? [NSString stringWithFormat:@
"%@[%@]"
, key, nestedKey] : nestedKey), nestedValue)];
}
}
}
else
if
([value isKindOfClass:[NSArray class]]) {
NSArray *array = value;
for
(id nestedValue
in
array) {
[mutableQueryStringComponents addObjectsFromArray:AFQueryStringPairsFromKeyAndValue([NSString stringWithFormat:@
"%@[]"
, key], nestedValue)];
}
}
else
if
([value isKindOfClass:[NSSet class]]) {
NSSet *set = value;
for
(id obj
in
[set sortedArrayUsingDescriptors:@[ sortDescriptor ]]) {
[mutableQueryStringComponents addObjectsFromArray:AFQueryStringPairsFromKeyAndValue(key, obj)];
}
}
else
{
[mutableQueryStringComponents addObject:[[AFQueryStringPair alloc] initWithField:key value:value]];
}
return
mutableQueryStringComponents;
}
|
-
转码主要是以上三个函数，配合着注释应该也很好理解：主要是在递归调用AFQueryStringPairsFromKeyAndValue。判断vaLue是什么类型的，而后去递归调用本身，直到解析的是除了array dic set之外的元素，而后把获得的参数数组返回。
-
其中有个AFQueryStringPair对象，其只有两个属性和两个方法：
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
|
@property (readwrite, nonatomic, strong) id field;
@property (readwrite, nonatomic, strong) id value;
- (instancetype)initWithField:(id)field value:(id)value {
self = [
super
init];
if
(!self) {
return
nil;
}
self.field = field;
self.value = value;
return
self;
}
- (NSString *)URLEncodedStringValue {
if
(!self.value || [self.value isEqual:[NSNull
null
]]) {
return
AFPercentEscapedStringFromString([self.field description]);
}
else
{
return
[NSString stringWithFormat:@
"%@=%@"
, AFPercentEscapedStringFromString([self.field description]), AFPercentEscapedStringFromString([self.value description])];
}
}
|
方法很简单，如今咱们也很容易理解这整个转码过程了，咱们举个例子梳理下，就是如下这3步：
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
|
@{
@
"name"
: @
"bang"
,
@
"phone"
: @{@
"mobile"
: @
"xx"
, @
"home"
: @
"xx"
},
@
"families"
: @[@
"father"
, @
"mother"
],
@
"nums"
: [NSSet setWithObjects:@
"1"
, @
"2"
, nil]
}
->
@[
field: @
"name"
, value: @
"bang"
,
field: @
"phone[mobile]"
, value: @
"xx"
,
field: @
"phone[home]"
, value: @
"xx"
,
field: @
"families[]"
, value: @
"father"
,
field: @
"families[]"
, value: @
"mother"
,
field: @
"nums"
, value: @
"1"
,
field: @
"nums"
, value: @
"2"
,
]
->
name=bang&phone[mobile]=xx&phone[home]=xx&families[]=father&families[]=mother&nums=1&num=2
|
至此，咱们原来的容器类型的参数，就这样变成字符串类型了。
紧接着这个方法还根据该request中请求类型，来判断参数字符串应该如何设置到request中去。若是是GET、HEAD、DELETE，则把参数quey是拼接到url后面的。而POST、PUT是把query拼接到http body中的:
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
|
if
([self.HTTPMethodsEncodingParametersInURI containsObject:[[request HTTPMethod] uppercaseString]]) {
if
(query && query.length > 0) {
mutableRequest.URL = [NSURL URLWithString:[[mutableRequest.URL absoluteString] stringByAppendingFormat:mutableRequest.URL.query ? @
"&%@"
: @
"?%@"
, query]];
}
}
else
{
//post put请求
// #2864: an empty string is a valid x-www-form-urlencoded payload
if
(!query) {
query = @
""
;
}
if
(![mutableRequest valueForHTTPHeaderField:@
"Content-Type"
]) {
[mutableRequest setValue:@
"application/x-www-form-urlencoded"
forHTTPHeaderField:@
"Content-Type"
];
}
//设置请求体
[mutableRequest setHTTPBody:[query dataUsingEncoding:self.stringEncoding]];
}
|
至此，咱们生成了一个request。
分割图.png
咱们再回到AFHTTPSessionManager类中来,回到这个方法：
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
|
- (NSURLSessionDataTask *)dataTaskWithHTTPMethod:(NSString *)method
URLString:(NSString *)URLString
parameters:(id)parameters
uploadProgress:(nullable void (^)(NSProgress *uploadProgress)) uploadProgress
downloadProgress:(nullable void (^)(NSProgress *downloadProgress)) downloadProgress
success:(void (^)(NSURLSessionDataTask *, id))success
failure:(void (^)(NSURLSessionDataTask *, NSError *))failure
{
NSError *serializationError = nil;
//把参数，还有各类东西转化为一个request
NSMutableURLRequest *request = [self.requestSerializer requestWithMethod:method URLString:[[NSURL URLWithString:URLString relativeToURL:self.baseURL] absoluteString] parameters:parameters error:&serializationError];
if
(serializationError) {
if
(failure) {
#pragma clang diagnostic push
#pragma clang diagnostic ignored "-Wgnu"
//若是解析错误，直接返回
dispatch_async(self.completionQueue ?: dispatch_get_main_queue(), ^{
failure(nil, serializationError);
});
#pragma clang diagnostic pop
}
return
nil;
}
__block NSURLSessionDataTask *dataTask = nil;
dataTask = [self dataTaskWithRequest:request
uploadProgress:uploadProgress
downloadProgress:downloadProgress
completionHandler:^(NSURLResponse * __unused response, id responseObject, NSError *error) {
if
(error) {
if
(failure) {
failure(dataTask, error);
}
}
else
{
if
(success) {
success(dataTask, responseObject);
}
}
}];
return
dataTask;
}
|
绕了一圈咱们又回来了。。
-
咱们继续往下看：当解析错误，咱们直接调用传进来的fauler的Block失败返回了，这里有一个self.completionQueue,这个是咱们自定义的，这个是一个GCD的Queue若是设置了那么从这个Queue中回调结果，不然从主队列回调。
-
实际上这个Queue仍是挺有用的，以前还用到过。咱们公司有本身的一套数据加解密的解析模式，因此咱们回调回来的数据并不想是主线程，咱们能够设置这个Queue,在分线程进行解析数据，而后本身再调回到主线程去刷新UI。
言归正传，咱们接着调用了父类的生成task的方法，而且执行了一个成功和失败的回调，咱们接着去父类AFURLSessionManger里看（总算到咱们的核心类了..）：
|
1
2
3
4
5
6
7
8
9
10
11
12
13
|
- (NSURLSessionDataTask *)dataTaskWithRequest:(NSURLRequest *)request
uploadProgress:(nullable void (^)(NSProgress *uploadProgress)) uploadProgressBlock
downloadProgress:(nullable void (^)(NSProgress *downloadProgress)) downloadProgressBlock
completionHandler:(nullable void (^)(NSURLResponse *response, id _Nullable responseObject, NSError * _Nullable error))completionHandler {
__block NSURLSessionDataTask *dataTask = nil;
//第一件事，建立NSURLSessionDataTask，里面适配了Ios8如下taskIdentifiers，函数建立task对象。
//其实现应该是由于iOS 8.0如下版本中会并发地建立多个task对象，而同步有没有作好，致使taskIdentifiers 不惟一…这边作了一个串行处理
url_session_manager_create_task_safely(^{
dataTask = [self.session dataTaskWithRequest:request];
});
[self addDelegateForDataTask:dataTask uploadProgress:uploadProgressBlock downloadProgress:downloadProgressBlock completionHandler:completionHandler];
return
dataTask;
}
|
-
咱们注意到这个方法很是简单，就调用了一个url_session_manager_create_task_safely()函数，传了一个Block进去，Block里就是iOS原生生成dataTask的方法。此外，还调用了一个addDelegateForDataTask的方法。
-
咱们到这先到这个函数里去看看：
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
|
static void url_session_manager_create_task_safely(dispatch_block_t block) {
if
(NSFoundationVersionNumber < NSFoundationVersionNumber_With_Fixed_5871104061079552_bug) {
// Fix of bug
// Open Radar:http://openradar.appspot.com/radar?id=5871104061079552 (status: Fixed in iOS8)
// Issue about:https://github.com/AFNetworking/AFNetworking/issues/2093
//理解下，第一为何用sync，由于是想要主线程等在这，等执行完，在返回，由于必须执行完dataTask才有数据，传值才有意义。
//第二，为何要用串行队列，由于这块是为了防止ios8如下内部的dataTaskWithRequest是并发建立的，
//这样会致使taskIdentifiers这个属性值不惟一，由于后续要用taskIdentifiers来做为Key对应delegate。
dispatch_sync(url_session_manager_creation_queue(), block);
}
else
{
block();
}
}
static dispatch_queue_t url_session_manager_creation_queue() {
static dispatch_queue_t af_url_session_manager_creation_queue;
static dispatch_once_t onceToken;
//保证了即便是在多线程的环境下，也不会建立其余队列
dispatch_once(&onceToken, ^{
af_url_session_manager_creation_queue = dispatch_queue_create(
"com.alamofire.networking.session.manager.creation"
, DISPATCH_QUEUE_SERIAL);
});
return
af_url_session_manager_creation_queue;
}
|
-
方法很是简单，关键是理解这么作的目的：为何咱们不直接去调用
|
1
|
dataTask = [self.session dataTaskWithRequest:request];
|
非要绕这么一圈，咱们点进去bug日志里看看，原来这是为了适配iOS8的如下，建立session的时候，偶发的状况会出现session的属性taskIdentifier这个值不惟一，而这个taskIdentifier是咱们后面来映射delegate的key,因此它必须是惟一的。
-
具体缘由应该是NSURLSession内部去生成task的时候是用多线程并发去执行的。想通了这一点，咱们就很好解决了，咱们只须要在iOS8如下同步串行的去生成task就能够防止这一问题发生（若是仍是不理解同步串行的缘由，能够看看注释）。
-
题外话：不少同窗都会抱怨为何sync我历来用不到，看，有用到的地方了吧，不少东西不是没用，而只是你想不到怎么用。
咱们接着看到：
|
1
|
[self addDelegateForDataTask:dataTask uploadProgress:uploadProgressBlock downloadProgress:downloadProgressBlock completionHandler:completionHandler];
|
调用到：
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
|
- (void)addDelegateForDataTask:(NSURLSessionDataTask *)dataTask
uploadProgress:(nullable void (^)(NSProgress *uploadProgress)) uploadProgressBlock
downloadProgress:(nullable void (^)(NSProgress *downloadProgress)) downloadProgressBlock
completionHandler:(void (^)(NSURLResponse *response, id responseObject, NSError *error))completionHandler
{
AFURLSessionManagerTaskDelegate *delegate = [[AFURLSessionManagerTaskDelegate alloc] init];
// AFURLSessionManagerTaskDelegate与AFURLSessionManager创建相互关系
delegate.manager = self;
delegate.completionHandler = completionHandler;
//这个taskDescriptionForSessionTasks用来发送开始和挂起通知的时候会用到,就是用这个值来Post通知，来二者对应
dataTask.taskDescription = self.taskDescriptionForSessionTasks;
// ***** 将AF delegate对象与 dataTask创建关系
[self setDelegate:delegate forTask:dataTask];
// 设置AF delegate的上传进度，下载进度块。
delegate.uploadProgressBlock = uploadProgressBlock;
delegate.downloadProgressBlock = downloadProgressBlock;
}
|
总结一下:
1）这个方法，生成了一个AFURLSessionManagerTaskDelegate,这个其实就是AF的自定义代理。咱们请求传来的参数，都赋值给这个AF的代理了。
2）delegate.manager = self;代理把AFURLSessionManager这个类做为属性了,咱们能够看到：
|
1
|
@property (nonatomic, weak) AFURLSessionManager *manager;
|
这个属性是弱引用的，因此不会存在循环引用的问题。
3）咱们调用了[self setDelegate:delegate forTask:dataTask];
咱们进去看看这个方法作了什么：
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
|
- (void)setDelegate:(AFURLSessionManagerTaskDelegate *)delegate
forTask:(NSURLSessionTask *)task
{
//断言，若是没有这个参数，debug下crash在这
NSParameterAssert(task);
NSParameterAssert(delegate);
//加锁保证字典线程安全
[self.lock lock];
// 将AF delegate放入以taskIdentifier标记的词典中（同一个NSURLSession中的taskIdentifier是惟一的）
self.mutableTaskDelegatesKeyedByTaskIdentifier[@(task.taskIdentifier)] = delegate;
// 为AF delegate 设置task 的progress监听
[delegate setupProgressForTask:task];
//添加task开始和暂停的通知
[self addNotificationObserverForTask:task];
[self.lock unlock];
}
|
-
这个方法主要就是把AF代理和task创建映射，存在了一个咱们事先声明好的字典里。
-
而要加锁的缘由是由于自己咱们这个字典属性是mutable的，是线程不安全的。而咱们对这些方法的调用，确实是会在复杂的多线程环境中，后面会仔细提到线程问题。
-
还有个[delegate setupProgressForTask:task];咱们到方法里去看看：
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
|
- (void)setupProgressForTask:(NSURLSessionTask *)task {
__weak __typeof__(task) weakTask = task;
//拿到上传下载指望的数据大小
self.uploadProgress.totalUnitCount = task.countOfBytesExpectedToSend;
self.downloadProgress.totalUnitCount = task.countOfBytesExpectedToReceive;
//将上传与下载进度和 任务绑定在一块儿，直接cancel suspend resume进度条，能够cancel...任务
[self.uploadProgress setCancellable:YES];
[self.uploadProgress setCancellationHandler:^{
__typeof__(weakTask) strongTask = weakTask;
[strongTask cancel];
}];
[self.uploadProgress setPausable:YES];
[self.uploadProgress setPausingHandler:^{
__typeof__(weakTask) strongTask = weakTask;
[strongTask suspend];
}];
if
([self.uploadProgress respondsToSelector:@selector(setResumingHandler:)]) {
[self.uploadProgress setResumingHandler:^{
__typeof__(weakTask) strongTask = weakTask;
[strongTask resume];
}];
}
[self.downloadProgress setCancellable:YES];
[self.downloadProgress setCancellationHandler:^{
__typeof__(weakTask) strongTask = weakTask;
[strongTask cancel];
}];
[self.downloadProgress setPausable:YES];
[self.downloadProgress setPausingHandler:^{
__typeof__(weakTask) strongTask = weakTask;
[strongTask suspend];
}];
if
([self.downloadProgress respondsToSelector:@selector(setResumingHandler:)]) {
[self.downloadProgress setResumingHandler:^{
__typeof__(weakTask) strongTask = weakTask;
[strongTask resume];
}];
}
//观察task的这些属性
[task addObserver:self
forKeyPath:NSStringFromSelector(@selector(countOfBytesReceived))
options:NSKeyValueObservingOptionNew
context:NULL];
[task addObserver:self
forKeyPath:NSStringFromSelector(@selector(countOfBytesExpectedToReceive))
options:NSKeyValueObservingOptionNew
context:NULL];
[task addObserver:self
forKeyPath:NSStringFromSelector(@selector(countOfBytesSent))
options:NSKeyValueObservingOptionNew
context:NULL];
[task addObserver:self
forKeyPath:NSStringFromSelector(@selector(countOfBytesExpectedToSend))
options:NSKeyValueObservingOptionNew
context:NULL];
//观察progress这两个属性
[self.downloadProgress addObserver:self
forKeyPath:NSStringFromSelector(@selector(fractionCompleted))
options:NSKeyValueObservingOptionNew
context:NULL];
[self.uploadProgress addObserver:self
forKeyPath:NSStringFromSelector(@selector(fractionCompleted))
options:NSKeyValueObservingOptionNew
context:NULL];
}
|
这个方法也很是简单，主要作了如下几件事：
1）设置 downloadProgress与uploadProgress的一些属性，而且把二者和task的任务状态绑定在了一块儿。注意这二者都是NSProgress的实例对象，（这里可能又一群小伙伴楞在这了，这是个什么...）简单来讲，这就是iOS7引进的一个用来管理进度的类，能够开始，暂停，取消，完整的对应了task的各类状态，当progress进行各类操做的时候，task也会引起对应操做。
2）给task和progress的各个属及添加KVO监听，至于监听了干什么用，咱们接着往下看：
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
|
- (void)observeValueForKeyPath:(NSString *)keyPath ofObject:(id)object change:(NSDictionary *)change context:(void *)context {
//是task
if
([object isKindOfClass:[NSURLSessionTask class]] || [object isKindOfClass:[NSURLSessionDownloadTask class]]) {
//给进度条赋新值
if
([keyPath isEqualToString:NSStringFromSelector(@selector(countOfBytesReceived))]) {
self.downloadProgress.completedUnitCount = [change[NSKeyValueChangeNewKey] longLongValue];
}
else
if
([keyPath isEqualToString:NSStringFromSelector(@selector(countOfBytesExpectedToReceive))]) {
self.downloadProgress.totalUnitCount = [change[NSKeyValueChangeNewKey] longLongValue];
}
else
if
([keyPath isEqualToString:NSStringFromSelector(@selector(countOfBytesSent))]) {
self.uploadProgress.completedUnitCount = [change[NSKeyValueChangeNewKey] longLongValue];
}
else
if
([keyPath isEqualToString:NSStringFromSelector(@selector(countOfBytesExpectedToSend))]) {
self.uploadProgress.totalUnitCount = [change[NSKeyValueChangeNewKey] longLongValue];
}
}
//上面的赋新值会触发这两个，调用block回调，用户拿到进度
else
if
([object isEqual:self.downloadProgress]) {
if
(self.downloadProgressBlock) {
self.downloadProgressBlock(object);
}
}
else
if
([object isEqual:self.uploadProgress]) {
if
(self.uploadProgressBlock) {
self.uploadProgressBlock(object);
}
}
}
|
-
方法很是简单直观，主要就是若是task触发KVO,则给progress进度赋值，应为赋值了，因此会触发progress的KVO，也会调用到这里，而后去执行咱们传进来的downloadProgressBlock和uploadProgressBlock。主要的做用就是为了让进度实时的传递。
-
主要是观摩一下大神的写代码的结构，这个解耦的编程思想，不愧是大神...
-
还有一点须要注意：咱们以前的setProgress和这个KVO监听，都是在咱们AF自定义的delegate内的，是有一个task就会有一个delegate的。因此说咱们是每一个task都会去监听这些属性，分别在各自的AF代理内。看到这，可能有些小伙伴会有点乱，不要紧。等整个讲完以后咱们还会详细的去讲捋一捋manager、task、还有AF自定义代理三者以前的对应关系。
到这里咱们整个对task的处理就完成了。
分割图.png
接着task就开始请求网络了，还记得咱们初始化方法中：
|
1
|
self.session = [NSURLSession sessionWithConfiguration:self.sessionConfiguration delegate:self delegateQueue:self.operationQueue];
|
咱们把AFUrlSessionManager做为了全部的task的delegate。当咱们请求网络的时候，这些代理开始调用了：
NSUrlSession的代理.png
AFUrlSessionManager一共实现了如上图所示这么一大堆NSUrlSession相关的代理。（小伙伴们的顺序可能不同，楼主根据代理隶属从新排序了一下）
而只转发了其中3条到AF自定义的delegate中：
AF自定义delegate.png
这就是咱们一开始说的，AFUrlSessionManager对这一大堆代理作了一些公共的处理，而转发到AF自定义代理的3条，则负责把每一个task对应的数据回调出去。
又有小伙伴问了，咱们设置的这个代理不是NSURLSessionDelegate吗？怎么能响应NSUrlSession这么多代理呢？咱们点到类的声明文件中去看看：
|
1
|
@protocol NSURLSessionDelegate @protocol NSURLSessionTaskDelegate @protocol NSURLSessionDataDelegate @protocol NSURLSessionDownloadDelegate @protocol NSURLSessionStreamDelegate
|
-
咱们能够看到这些代理都是继承关系，而在NSURLSession实现中，只要设置了这个代理，它会去判断这些全部的代理，是否respondsToSelector这些代理中的方法，若是响应了就会去调用。
-
而AF还重写了respondsToSelector方法:
|
1
2
3
4
5
6
7
8
9
10
11
12
13
|
- (BOOL)respondsToSelector:(SEL)selector {
//复写了selector的方法，这几个方法是在本类有实现的，可是若是外面的Block没赋值的话，则返回NO，至关于没有实现！
if
(selector == @selector(URLSession:task:willPerformHTTPRedirection:newRequest:completionHandler:)) {
return
self.taskWillPerformHTTPRedirection != nil;
}
else
if
(selector == @selector(URLSession:dataTask:didReceiveResponse:completionHandler:)) {
return
self.dataTaskDidReceiveResponse != nil;
}
else
if
(selector == @selector(URLSession:dataTask:willCacheResponse:completionHandler:)) {
return
self.dataTaskWillCacheResponse != nil;
}
else
if
(selector == @selector(URLSessionDidFinishEventsForBackgroundURLSession:)) {
return
self.didFinishEventsForBackgroundURLSession != nil;
}
return
[[self class] instancesRespondToSelector:selector];
}
|
这样若是没实现这些咱们自定义的Block也不会去回调这些代理。由于自己某些代理，只执行了这些自定义的Block，若是Block都没有赋值，那咱们调用代理也没有任何意义。
讲到这，咱们顺便看看AFUrlSessionManager的一些自定义Block：
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
|
@property (readwrite, nonatomic, copy) AFURLSessionDidBecomeInvalidBlock sessionDidBecomeInvalid;
@property (readwrite, nonatomic, copy) AFURLSessionDidReceiveAuthenticationChallengeBlock sessionDidReceiveAuthenticationChallenge;
@property (readwrite, nonatomic, copy) AFURLSessionDidFinishEventsForBackgroundURLSessionBlock didFinishEventsForBackgroundURLSession;
@property (readwrite, nonatomic, copy) AFURLSessionTaskWillPerformHTTPRedirectionBlock taskWillPerformHTTPRedirection;
@property (readwrite, nonatomic, copy) AFURLSessionTaskDidReceiveAuthenticationChallengeBlock taskDidReceiveAuthenticationChallenge;
@property (readwrite, nonatomic, copy) AFURLSessionTaskNeedNewBodyStreamBlock taskNeedNewBodyStream;
@property (readwrite, nonatomic, copy) AFURLSessionTaskDidSendBodyDataBlock taskDidSendBodyData;
@property (readwrite, nonatomic, copy) AFURLSessionTaskDidCompleteBlock taskDidComplete;
@property (readwrite, nonatomic, copy) AFURLSessionDataTaskDidReceiveResponseBlock dataTaskDidReceiveResponse;
@property (readwrite, nonatomic, copy) AFURLSessionDataTaskDidBecomeDownloadTaskBlock dataTaskDidBecomeDownloadTask;
@property (readwrite, nonatomic, copy) AFURLSessionDataTaskDidReceiveDataBlock dataTaskDidReceiveData;
@property (readwrite, nonatomic, copy) AFURLSessionDataTaskWillCacheResponseBlock dataTaskWillCacheResponse;
@property (readwrite, nonatomic, copy) AFURLSessionDownloadTaskDidFinishDownloadingBlock downloadTaskDidFinishDownloading;
@property (readwrite, nonatomic, copy) AFURLSessionDownloadTaskDidWriteDataBlock downloadTaskDidWriteData;
@property (readwrite, nonatomic, copy) AFURLSessionDownloadTaskDidResumeBlock downloadTaskDidResume;
|
各自对应的还有一堆这样的set方法：
|
1
2
3
|
- (void)setSessionDidBecomeInvalidBlock:(void (^)(NSURLSession *session, NSError *error))block {
self.sessionDidBecomeInvalid = block;
}
|
方法都是同样的，就不重复粘贴占篇幅了。
主要谈谈这个设计思路
-
做者用@property把这个些Block属性在.m文件中声明,而后复写了set方法。
-
而后在.h中去声明这些set方法：
|
1
|
- (void)setSessionDidBecomeInvalidBlock:(nullable void (^)(NSURLSession *session, NSError *error))block;
|
为何要绕这么一大圈呢？原来这是为了咱们这些用户使用起来方便，调用set方法去设置这些Block，能很清晰的看到Block的各个参数与返回值。大神的精髓的编程思想无处不体现...
接下来咱们就讲讲这些代理方法作了什么（按照顺序来）：
NSURLSessionDelegate
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
|
//当前这个session已经失效时，该代理方法被调用。
/*
若是你使用finishTasksAndInvalidate函数使该session失效，
那么session首先会先完成最后一个task，而后再调用URLSession:didBecomeInvalidWithError:代理方法，
若是你调用invalidateAndCancel方法来使session失效，那么该session会当即调用上面的代理方法。
*/
- (void)URLSession:(NSURLSession *)session
didBecomeInvalidWithError:(NSError *)error
{
if
(self.sessionDidBecomeInvalid) {
self.sessionDidBecomeInvalid(session, error);
}
[[NSNotificationCenter defaultCenter] postNotificationName:AFURLSessionDidInvalidateNotification object:session];
}
|
-
方法调用时机注释写的很清楚，就调用了一下咱们自定义的Block,还发了一个失效的通知，至于这个通知有什么用。很抱歉，AF没用它作任何事，只是发了...目的是用户本身能够利用这个通知作什么事吧。
-
其实AF大部分通知都是如此。固然，还有一部分通知AF仍是有本身用到的，包括配合对UIKit的一些扩展来使用，后面咱们会有单独篇幅展开讲讲这些UIKit的扩展类的实现。
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
|
//二、https认证
- (void)URLSession:(NSURLSession *)session
didReceiveChallenge:(NSURLAuthenticationChallenge *)challenge
completionHandler:(void (^)(NSURLSessionAuthChallengeDisposition disposition, NSURLCredential *credential))completionHandler
{
//挑战处理类型为 默认
/*
NSURLSessionAuthChallengePerformDefaultHandling：默认方式处理
NSURLSessionAuthChallengeUseCredential：使用指定的证书
NSURLSessionAuthChallengeCancelAuthenticationChallenge：取消挑战
*/
NSURLSessionAuthChallengeDisposition disposition = NSURLSessionAuthChallengePerformDefaultHandling;
__block NSURLCredential *credential = nil;
// sessionDidReceiveAuthenticationChallenge是自定义方法，用来如何应对服务器端的认证挑战
if
(self.sessionDidReceiveAuthenticationChallenge) {
disposition = self.sessionDidReceiveAuthenticationChallenge(session, challenge, &credential);
}
else
{
// 此处服务器要求客户端的接收认证挑战方法是NSURLAuthenticationMethodServerTrust
// 也就是说服务器端须要客户端返回一个根据认证挑战的保护空间提供的信任（即challenge.protectionSpace.serverTrust）产生的挑战证书。
// 而这个证书就须要使用credentialForTrust:来建立一个NSURLCredential对象
if
([challenge.protectionSpace.authenticationMethod isEqualToString:NSURLAuthenticationMethodServerTrust]) {
// 基于客户端的安全策略来决定是否信任该服务器，不信任的话，也就不必响应挑战
if
([self.securityPolicy evaluateServerTrust:challenge.protectionSpace.serverTrust forDomain:challenge.protectionSpace.host]) {
// 建立挑战证书（注：挑战方式为UseCredential和PerformDefaultHandling都须要新建挑战证书）
credential = [NSURLCredential credentialForTrust:challenge.protectionSpace.serverTrust];
// 肯定挑战的方式
if
(credential) {
//证书挑战
disposition = NSURLSessionAuthChallengeUseCredential;
}
else
{
//默认挑战 惟一区别，下面少了这一步！
disposition = NSURLSessionAuthChallengePerformDefaultHandling;
}
}
else
{
//取消挑战
disposition = NSURLSessionAuthChallengeCancelAuthenticationChallenge;
}
}
else
{
//默认挑战方式
disposition = NSURLSessionAuthChallengePerformDefaultHandling;
}
}
//完成挑战
if
(completionHandler) {
completionHandler(disposition, credential);
}
}
|
-
函数做用：
web服务器接收到客户端请求时，有时候须要先验证客户端是否为正经常使用户，再决定是够返回真实数据。这种状况称之为服务端要求客户端接收挑战（NSURLAuthenticationChallenge challenge）。接收到挑战后，客户端要根据服务端传来的challenge来生成completionHandler所需的NSURLSessionAuthChallengeDisposition disposition和NSURLCredential credential（disposition指定应对这个挑战的方法，而credential是客户端生成的挑战证书，注意只有challenge中认证方法为NSURLAuthenticationMethodServerTrust的时候，才须要生成挑战证书）。最后调用completionHandler回应服务器端的挑战。
-
函数讨论：
该代理方法会在下面两种状况调用：
当服务器端要求客户端提供证书时或者进行NTLM认证（Windows NT LAN Manager，微软提出的WindowsNT挑战/响应验证机制）时，此方法容许你的app提供正确的挑战证书。
当某个session使用SSL/TLS协议，第一次和服务器端创建链接的时候，服务器会发送给iOS客户端一个证书，此方法容许你的app验证服务期端的证书链（certificate keychain）
注：若是你没有实现该方法，该session会调用其NSURLSessionTaskDelegate的代理方法URLSession:task:didReceiveChallenge:completionHandler: 。
这里，我把官方文档对这个方法的描述翻译了一下。
总结一下，这个方法其实就是作https认证的。看看上面的注释，大概能看明白这个方法作认证的步骤，咱们仍是若是有自定义的作认证的Block，则调用咱们自定义的，不然去执行默认的认证步骤，最后调用完成认证：
|
1
2
3
4
5
6
7
8
9
10
11
12
13
|
//完成挑战
if
(completionHandler) {
completionHandler(disposition, credential);
}
继续往下：
//三、 当session中全部已经入队的消息被发送出去后，会调用该代理方法。
- (void)URLSessionDidFinishEventsForBackgroundURLSession:(NSURLSession *)session {
if
(self.didFinishEventsForBackgroundURLSession) {
dispatch_async(dispatch_get_main_queue(), ^{
self.didFinishEventsForBackgroundURLSession(session);
});
}
}
|
官方文档翻译：
函数讨论：
-
在iOS中，当一个后台传输任务完成或者后台传输时须要证书，而此时你的app正在后台挂起，那么你的app在后台会自动从新启动运行，而且这个app的UIApplicationDelegate会发送一个application:handleEventsForBackgroundURLSession:completionHandler:消息。该消息包含了对应后台的session的identifier，并且这个消息会致使你的app启动。你的app随后应该先存储completion handler，而后再使用相同的identifier建立一个background configuration，并根据这个background configuration建立一个新的session。这个新建立的session会自动与后台任务从新关联在一块儿。
-
当你的app获取了一个URLSessionDidFinishEventsForBackgroundURLSession:消息，这就意味着以前这个session中已经入队的全部消息都转发出去了，这时候再调用先前存取的completion handler是安全的，或者由于内部更新而致使调用completion handler也是安全的。
NSURLSessionTaskDelegate
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
|
//被服务器重定向的时候调用
- (void)URLSession:(NSURLSession *)session
task:(NSURLSessionTask *)task
willPerformHTTPRedirection:(NSHTTPURLResponse *)response
newRequest:(NSURLRequest *)request
completionHandler:(void (^)(NSURLRequest *))completionHandler
{
NSURLRequest *redirectRequest = request;
// step1. 看是否有对应的user block 有的话转发出去，经过这4个参数，返回一个NSURLRequest类型参数，request转发、网络重定向.
if
(self.taskWillPerformHTTPRedirection) {
//用本身自定义的一个重定向的block实现，返回一个新的request。
redirectRequest = self.taskWillPerformHTTPRedirection(session, task, response, request);
}
if
(completionHandler) {
// step2. 用request从新请求
completionHandler(redirectRequest);
}
}
|
-
一开始我觉得这个方法是相似NSURLProtocol，能够在请求时本身主动的去重定向request，后来发现不是，这个方法是在服务器去重定向的时候，才会被调用。为此我写了段简单的PHP测了测：
证明确实如此，当咱们服务器重定向的时候，代理就被调用了，咱们能够去从新定义这个重定向的request。
-
关于这个代理还有一些须要注意的地方：
此方法只会在default session或者ephemeral session中调用，而在background session中，session task会自动重定向。
这里指的模式是咱们一开始Init的模式：
|
1
2
3
4
|
if
(!configuration) {
configuration = [NSURLSessionConfiguration defaultSessionConfiguration];
}
self.sessionConfiguration = configuration;
|
这个模式总共分为3种：
对于NSURLSession对象的初始化须要使用NSURLSessionConfiguration，而NSURLSessionConfiguration有三个类工厂方法：
+defaultSessionConfiguration 返回一个标准的 configuration，这个配置实际上与 NSURLConnection 的网络堆栈（networking stack）是同样的，具备相同的共享 NSHTTPCookieStorage，共享 NSURLCache 和共享NSURLCredentialStorage。
+ephemeralSessionConfiguration 返回一个预设配置，这个配置中不会对缓存，Cookie 和证书进行持久性的存储。这对于实现像秘密浏览这种功能来讲是很理想的。
+backgroundSessionConfiguration:(NSString *)identifier 的独特之处在于，它会建立一个后台 session。后台 session 不一样于常规的，普通的 session，它甚至能够在应用程序挂起，退出或者崩溃的状况下运行上传和下载任务。初始化时指定的标识符，被用于向任何可能在进程外恢复后台传输的守护进程（daemon）提供上下文。
继续往下:
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
|
//https认证
- (void)URLSession:(NSURLSession *)session
task:(NSURLSessionTask *)task
didReceiveChallenge:(NSURLAuthenticationChallenge *)challenge
completionHandler:(void (^)(NSURLSessionAuthChallengeDisposition disposition, NSURLCredential *credential))completionHandler
{
NSURLSessionAuthChallengeDisposition disposition = NSURLSessionAuthChallengePerformDefaultHandling;
__block NSURLCredential *credential = nil;
if
(self.taskDidReceiveAuthenticationChallenge) {
disposition = self.taskDidReceiveAuthenticationChallenge(session, task, challenge, &credential);
}
else
{
if
([challenge.protectionSpace.authenticationMethod isEqualToString:NSURLAuthenticationMethodServerTrust]) {
if
([self.securityPolicy evaluateServerTrust:challenge.protectionSpace.serverTrust forDomain:challenge.protectionSpace.host]) {
disposition = NSURLSessionAuthChallengeUseCredential;
credential = [NSURLCredential credentialForTrust:challenge.protectionSpace.serverTrust];
}
else
{
disposition = NSURLSessionAuthChallengeCancelAuthenticationChallenge;
}
}
else
{
disposition = NSURLSessionAuthChallengePerformDefaultHandling;
}
}
if
(completionHandler) {
completionHandler(disposition, credential);
}
}
|
-
鉴于篇幅，就不去贴官方文档的翻译了，大概总结一下：
以前咱们也有一个https认证，功能同样，执行的内容也彻底同样。
-
相对于它，惟一的区别只是多了一个参数task,而后调用咱们自定义的Block会多回传这个task做为参数，这样咱们就能够根据每一个task去自定义咱们须要的https认证方式。
继续啊
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
|
//当一个session task须要发送一个新的request body stream到服务器端的时候，调用该代理方法。
- (void)URLSession:(NSURLSession *)session
task:(NSURLSessionTask *)task
needNewBodyStream:(void (^)(NSInputStream *bodyStream))completionHandler
{
NSInputStream *inputStream = nil;
//有自定义的taskNeedNewBodyStream,用自定义的，否则用task里原始的stream
if
(self.taskNeedNewBodyStream) {
inputStream = self.taskNeedNewBodyStream(session, task);
}
else
if
(task.originalRequest.HTTPBodyStream && [task.originalRequest.HTTPBodyStream conformsToProtocol:@protocol(NSCopying)]) {
inputStream = [task.originalRequest.HTTPBodyStream copy];
}
if
(completionHandler) {
completionHandler(inputStream);
}
}
|
-
该代理方法会在下面两种状况被调用：
-
若是task是由uploadTaskWithStreamedRequest:建立的，那么提供初始的request body stream时候会调用该代理方法。
-
由于认证挑战或者其余可恢复的服务器错误，而致使须要客户端从新发送一个含有body stream的request，这时候会调用该代理。
实现没什么好说的，下一个吧：
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
|
/*
//周期性地通知代理发送到服务器端数据的进度。
*/
- (void)URLSession:(NSURLSession *)session
task:(NSURLSessionTask *)task
didSendBodyData:(int64_t)bytesSent
totalBytesSent:(int64_t)totalBytesSent
totalBytesExpectedToSend:(int64_t)totalBytesExpectedToSend
{
// 若是totalUnitCount获取失败，就使用HTTP header中的Content-Length做为totalUnitCount
int64_t totalUnitCount = totalBytesExpectedToSend;
if
(totalUnitCount == NSURLSessionTransferSizeUnknown) {
NSString *contentLength = [task.originalRequest valueForHTTPHeaderField:@
"Content-Length"
];
if
(contentLength) {
totalUnitCount = (int64_t) [contentLength longLongValue];
}
}
if
(self.taskDidSendBodyData) {
self.taskDidSendBodyData(session, task, bytesSent, totalBytesSent, totalUnitCount);
}
}
|
-
就是每次发送数据给服务器，会回调这个方法，通知已经发送了多少，总共要发送多少。
-
代理方法里也就是仅仅调用了咱们自定义的Block而已。
未完总结：
-
其实写了这么多，尚未讲到真正重要的地方，可是由于已经接近简书最大篇幅，因此只能先在这里结个尾了。
-
若是能看到这里，说明你是个很是有耐心，很是好学，很是nice的iOS开发。楼主为你点个赞。那么相信你也不吝啬手指动一动，给本文点个喜欢...顺便关注一下楼主...毕竟写了这么多...也很辛苦...咳咳，我不当心说出心声了么？
转载：http://www.jianshu.com/p/856f0e26279d
- 1. AFNetworking到底作了什么？
- 2. new操做符到底作了什么？
- 3. JS中new 到底作了什么？
- 4. new 操做符到底作了什么？
- 5. Array.prototype.slice.call(arguments) 到底作了什么？
- 6. sqlsession中的opensession到底作了什么
- 7. YOLOv4，它到底作了什么？
- 8. volatile关键字到底作了什么？
- 9. 用nodejs到底作什么？
- 10. Python到底能作什么？
- 更多相关文章...
- • Hibernate是什么 - Hibernate教程
- • MyBatis是什么 - MyBatis教程
- • 为了进字节跳动，我精选了29道Java经典算法题，带详细讲解
- • 三篇文章了解 TiDB 技术内幕——说存储
-
每一个你不满意的现在，都有一个你没有努力的曾经。