前言
通过上一篇URlSession后台下载，我们已经知道了SessionManager的作为整个Alamofire框架的核心枢纽的重要性，还有一个比较重要的是SessionManager的代理SessionDelegate，封装了URLSessionDelegate。负责对Task的回调事件提供默认实现（转发给TaskDelegate进行实际处理），并且以闭包的方式暴露给外部，让外部可以自定义实现。TaskDelegate 对URLSessionTask的回调进行实际的处理，并且执行task的完成回调用。Request就 是对URLSessionTask的封装，是暴露给上层的请求任务。
Alamofire Request
废话不多说直接来用URLSession创建一个request和利用Alamofire创建一个request的例子看看：
首先来看一个URLSession的request的用法：
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对象，是利用SessionManager的request方法，这说明了真正的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方法的内部返回的是同步创建的session，return queue.sync { session.dataTask(with: urlRequest) }.
那么这里为什么不使用DataRequest直接创建一个task，而非要task由Requestable这个结构体来创建，其实是Requestable结构体就相当于是DataRequest的秘书，其实这里DataRequest和task任务应该是一一对应的，平级关系，如果DataRequest直接创建task，更像是归属关系，而由Requestable来创建task也就是降低了DataRequest与task的耦合性，使DataRequest与task保持平级关系。
继续回到源代码，可以看到在
Requestable创建完task之后，紧接着DataRequest就创建了一个request，那么接下来来到DataRequest的init方法，然而DataRequest并没有init方法，那么就看其父类Request的init方法：
可以看到这里
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.swift中URLSessionDownloadDelegate的源码：
从标红部分可以看出，
self[downloadTask]就等同于DownloadRequest，DownloadRequest.delegate 就等同于DownloadTaskDelegate.这里把downloadTask交给了DownloadTaskDelegate.urlSession去执行，如果再跟进去源码DownloadTaskDelegate.urlSession，就会发现执行的就是具体的Download操作。
总结
在SessionManager 的 Request 方法中，表面上看是由SessionManager直接处理了request，然而实际上，是通过SessionManager的代理响应SessionDelegate，然后SessionDelegate把这个具体Request分发给了具体的DataTaskDelegate，然后DataTaskDelegate来执行具体的任务内容。之所以这么做，是因为SessionDelegate 通过的任务分发，让处理具体任务的taskdelegate 去处理对应的事务，避免了其内部逻辑混乱和代码冗余，实现任务逻辑下沉。关于Request还有很多内容的哦，后面再做补充，如有错误，还望大佬们指正。