阅读 70

Alamofire学习 -- Request

前言

通过上一篇URlSession后台下载,我们已经知道了SessionManager的作为整个Alamofire框架的核心枢纽的重要性🔐,还有一个比较重要的是SessionManager的代理SessionDelegate,封装了URLSessionDelegate。负责对Task的回调事件提供默认实现(转发给TaskDelegate进行实际处理),并且以闭包的方式暴露给外部,让外部可以自定义实现。TaskDelegateURLSessionTask的回调进行实际的处理,并且执行task的完成回调用。Request就 是对URLSessionTask的封装,是暴露给上层的请求任务。

Alamofire Request

废话不多说直接来用URLSession创建一个request和利用Alamofire创建一个request的例子🌰看看:

首先来看一个URLSessionrequest的用法:

guard let url = URL(string: "https://www.douban.com/j/app/radio/channels") else {  
    return;  
}  
let dataTask = URLSession.shared.dataTask(with: url) { (data, response, error) in  
    guard let data = data else{  
        return;  
    }  
    do{  
        let json = try JSONSerialization.jsonObject(with: data, options: .allowFragments)  
        print(json)  
    }catch let error{  
        print(error)  
    }  
};  
dataTask.resume()  
复制代码

再来看一个基础的Alamofire.request用法:

Alamofire.request("https://www.douban.com/j/app/radio/channels").responseJSON { (response) in  
    if let JSONString = response.result.value {  
        print("JSONString: \(JSONString)")  
    }  
}  
复制代码

有没有觉得,如果使用系统的API,我们不得不先创建URL,然后建立dataTask,并且resume,接着在callback里去解析JSON。由于Swift是一种强类型的语言,我们不得不进行大量的逻辑判断和try-catch🤦‍♂️。而Alamofire把这些步骤简化成了一个静态的方法调用,并且用链式的方式来处理异步的Response解析。由于是链式的,我们也可以用链式的方式实现更多的逻辑。

那么在Alamofire.request的内部具体做了什么“骚”操作呢🤔?没办法🤷‍♀️️,想要看到内部实现,就要看到这里的源码,那么就来吧...

根据Alamofire.request的这个方法,我们来到Alamofire.swift看到这个request方法:

可以看到这个方法里的几个参数都有默认值,所有我们可以直接传入一个Url参数,这个方法返回一个DataRequest对象,是利用SessionManagerrequest方法,这说明了真正的request应该是由SessionManager发起的,下面再来看一下SessionManager.default.request方法内部实现了什么❓

在这个方法中创建了一个URLRequest对象,并把传入的参数传入到这个URLRequest对象中,并调用了request方法,并且把上面创建的URLRequest对象进行编码之后作为参数传入到这个request方法,

这里是插入一个小插曲,这个参数编码到底是如何操作的,也就是这个encoding.encode()方法具体实现了什么?

这里先取出请求方法的类型,然后根据不同的类型对参数进行不同的编码,由前面的代码我们知道在encode()这个方法传入了参数parameters,而在这里处理这个parameters的是query(parameters),那么接着来看这个query方法的具体实现:

来到这里把传入的参数根据key进行排序,然后遍历排序的结果,然后利用queryComponents方法将所有的参数(key,value)不断的递归, 返回一个元素为元组的数组,然后将这个数组进行map映射,将key=value并且拼接&符号,至此就完成了参数的拼接,

📣然后我们在回到encode方法中,根据请求方法的不同,

  • 如果请求方法是.get, .head, .delete类型,需要urlComponents.percentEncodedQuery进行百分号编码,并且利用query(parameters)把参数直接拼接到URL后面。
  • 如果是其他类型的请求方法,例如.post,需要设置请求头application/x-www-form-urlencoded; charset=utf-8", forHTTPHeaderField: "Content-Type,然后利用query(parameters)拼接参数,将参数转换为二进制并赋值到urlRequest.httpBody请求体中。

那么接下来回到request的流程再来看看这个request(encodedURLRequest)方法内部实现了什么❓

在这里先拿到传入的已经编码过后的URLRequest,这里的DataRequest是继承于Request的一个子类,用来管理URLSessionDataTask,而这里DataRequest.Requestable,难道是调用了一个Requestable方法?我们跟进去这个Requestable看一下:

可以看到这个Requestable是一个结构体,也就是说在当前这个DataRequest类里面嵌套了一个结构体,但是可以看到这个结构体内部并没有urlRequest这个方法,那它怎么会调用urlRequest方法呢?

我们来看这句代码let urlRequest: URLRequest,可以看到在这个结构体的内部有个urlRequest属性,而且默认初始化。✍️那么这句DataRequest.Requestable(urlRequest: )实际上就是创建了一个类型为Requestable的而且包含创建task方法的结构体对象,在这个task方法的内部返回的是同步创建的sessionreturn queue.sync { session.dataTask(with: urlRequest) }.

🗣🗣🗣那么这里为什么不使用DataRequest直接创建一个task,而非要taskRequestable这个结构体来创建,其实是Requestable结构体就相当于是DataRequest的秘书,其实这里DataRequesttask任务应该是一一对应的,平级关系,如果DataRequest直接创建task,更像是归属关系,而由Requestable来创建task也就是降低了DataRequesttask的耦合性,使DataRequesttask保持平级关系。

继续回到源代码,可以看到在Requestable创建完task之后,紧接着DataRequest就创建了一个request,那么接下来来到DataRequestinit方法,然而DataRequest并没有init方法,那么就看其父类Requestinit方法:

可以看到这里requestTask很明显是个枚举类型,

而这个requestTask调用了一个关联方法.data(let originalTask, let task),而这个.data 即是DataRequest初始化方法中传入的.data(originalTask, task),这里会根据传入的方法的不同的类型来把task交给不同的TaskDelegate.

再一次回到request流程的源码🤷‍♂️🤷‍♂️🤷‍♂️ ,这里一句很重要的代码 delegate[task] = request,这里是做了一个绑定操作,(有点类似于字典和数组),当前这个delegate由源码可知public let delegate: SessionDelegate是一个SessionDelegate就是SessionDelegate通过task可以读取到request。方便在 SessionDelegate 下发任务的时候,通过task直接检索,方便直接获取到request ,然后调用request.resume()任务启动.

直接通过SessionDelegate实现代理, 为什么这里还要有一个DataTaskDelegate, 真是费劲呢。

首先,要明白要SessionDelegate是所有 Session 的代理遵循者,任何的代理都会来到这里响应,而DataTaskDelegate 是具体任务的实现者,这里面所有方法都是由 SessionDelegate 下发响应的。(一个下发任务,一个具体干活)

下面给我一首歌的时间🎤🎤🎤来看一下SessionDelegate.swiftURLSessionDownloadDelegate的源码🌰:

从标红部分可以看出,self[downloadTask]就等同于DownloadRequestDownloadRequest.delegate 就等同于DownloadTaskDelegate.这里把downloadTask交给了DownloadTaskDelegate.urlSession去执行,如果再跟进去源码DownloadTaskDelegate.urlSession,就会发现执行的就是具体的Download操作。

总结

SessionManagerRequest 方法中,表面上看是由SessionManager直接处理了request,然而实际上,是通过SessionManager的代理响应SessionDelegate,然后SessionDelegate把这个具体Request分发给了具体的DataTaskDelegate,然后DataTaskDelegate来执行具体的任务内容。之所以这么做,是因为SessionDelegate 通过的任务分发,让处理具体任务的taskdelegate 去处理对应的事务,避免了其内部逻辑混乱和代码冗余,实现任务逻辑下沉。关于Request还有很多内容的哦,后面再做补充,如有错误,还望大佬们指正。

关注下面的标签,发现更多相似文章
评论