前端mock数据解决方案,Alamofire-URLSession必备技能
前端mock数据解决方案,Alamofire-URLSession必备技能//用于保存后台下载的completionHandler var backgroundSessionCompletionHandler: (() -> Void)? func application(_ application: UIApplication handleEventsForBackgroundURLSession identifier: String completionHandler: @escaping () -> Void) { self.backgroundSessionCompletionHandler = completionHandler }回调系统回调,告诉系统及时更新屏幕func urlSessionDidFinishEvents(forBackgroundURLSession session: URLSession) {
lamofire是一个为iOS和macOS打造的并基于Swift的网络库.它在Apple的基础网络架构上提供了更加优雅的接口来简化繁重而常用的网络请求任务。
Alamofire提供了链式的request/response方法,JSON的传参和响应序列化,身份认证和其他特性。Alamofire的优雅之处在于它完完全全是由Swift写成的,并且没有从它的Objective-C版本-AFNetworking那继承任何特性。
因为我们的Alamofire是对苹果URLSession的封装 所以在探索Alamofire之前,我们来看看URLSession的必备基础
一、请求网络的基本格式URLSession.shared.dataTask(with: url) { (data response error) in
if error == nil {
print("请求成功\(String(describing: response))" )
}
}.resume()
- URLSession.shared提供了一个共享的单例会话对象,它为创建任务提供了一个合理的默认行为。使用共享会话仅用几行代码将URL的内容获取到内存中。
- dataTask创建一个网络会话数据任务。
- resume默认网络任务是挂起的,调用执行开始连接请求网络:三次握手...
- 请求成果或者失败都会回来闭包
- 其实闭包只是一层封装,真正来的是URLSession的代理
- 其实在这个过程中,我们省略一个重要的东西:URLSessionConfiguration
URLSessionConfiguration初始化有三种模式:
- default:默认模式,通常我们用这种模式就足够了。default模式下系统会创建一个持久化的缓存并在用户的钥匙串中存储证书
- ephemeral: 系统没有任何持久性存储,所有内容的生命周期都与session相同,当session无效时,所有内容自动释放
let configuration1 = URLSessionConfiguration.default
let configuration2 = URLSessionConfiguration.ephemeral
print("沙盒大小: \(String(describing: configuration1.urlCache?.diskCapacity))")
print("内存大小: \(String(describing: configuration1.urlCache?.memoryCapacity))")
print("沙盒大小: \(String(describing: configuration2.urlCache?.diskCapacity))")
print("内存大小: \(String(describing: configuration2.urlCache?.memoryCapacity))")
打印结果:
沙盒大小: Optional(10000000)
内存大小: Optional(512000)
沙盒大小: Optional(0)
内存大小: Optional(512000)
- background创建一个可以在后台甚至APP已经关闭的时候仍然在传输数据的会话。background模式与default模式非常相似,不过background模式会用一个独立线程来进行数据传输。background模式可以在程序挂起,退出,崩溃的情况下运行task。也可以利用标识符来恢复进。注意,后台Session一定要在创建的时候赋予一个唯一的identifier,这样在APP下次运行的时候,能够根据identifier来进行相关的区分。如果用户关闭了APP IOS 系统会关闭所有的background Session。而且,被用户强制关闭了以后,IOS系统不会主动唤醒APP,只有用户下次启动了APP,数据传输才会继续
// 初始化一个后台的模式的会话配置
let configuration = URLSessionConfiguration.background(withIdentifier: self.createID())
// 初始化session会话
let session = URLSession.init(configuration: configuration delegate: self delegateQueue: OperationQueue.main)
// 传入url开启下载
session.downloadTask(with: url).resume()
- 初始化一个后台的模式的会话配置
- 初始化session会话
- 传入url开启下载resume
- 下载进度监控
func urlSession(_ session: URLSession downloadTask: URLSessionDownloadTask didWriteData bytesWritten: Int64 totalBytesWritten: Int64 totalBytesExpectedToWrite: Int64)
- 下载完成之后就回调URLSessionDownloadDelegate代理
func urlSession(_ session: URLSession downloadTask: URLSessionDownloadTask didFinishDownloadingTo location: URL)
易错易忽略点
上面这么设置,还不能达到后台下载!还需要设置下面两步
- 开启后台下载权限
//用于保存后台下载的completionHandler
var backgroundSessionCompletionHandler: (() -> Void)?
func application(_ application: UIApplication handleEventsForBackgroundURLSession identifier: String completionHandler: @escaping () -> Void) {
self.backgroundSessionCompletionHandler = completionHandler
}
- 回调系统回调,告诉系统及时更新屏幕
func urlSessionDidFinishEvents(forBackgroundURLSession session: URLSession) {
print("后台任务下载回来")
DispatchQueue.main.async {
guard let appDelegate = UIApplication.shared.delegate as? AppDelegate let backgroundHandle = appDelegate.backgroundSessionCompletionHandler else { return }
backgroundHandle()
}
}
为什么这么处理,苹果爸爸说的算
2. 常规属性- identifier:配置对象的后台会话标识符。
- httpAdditionalHeaders:与请求一起发送的附加头文件的字典。
- networkServiceType:网络服务的类型
- allowsCellularAccess:一个布尔值,用于确定是否应通过蜂窝网络进行连接。
- timeoutIntervalForRequest:等待其他数据时使用的超时间隔。
- timeoutIntervalForResource:资源请求应该允许的最大时间量
- sharedContainerIdentifier:应该下载后台URL会话中的文件的共享容器的标识符。
- waitsForConnectivity:一个布尔值,指示会话是否应等待连接变为可用或者立即失败
- httpCookieAcceptPolicy:决定何时应该接受Cookie的策略常量
- httpShouldSetCookies:一个布尔值,用于确定请求是否应包含来自Cookie存储的Cookie
- httpCookieStorage:管理cookie存储的单一对象(共享实例)
- HTTPCookie:表示HTTP cookie的对象。它是一个不可变的对象,从包含cookie属性的字典中初始化
- tlsMaximumSupportedProtocol:在此会话中进行连接时客户端应请求的最大TLS协议版本。
- tlsMinimumSupportedProtocol:协议协商期间应该接受的最小TLS协议。
- urlCredentialStorage:提供身份验证凭据的凭证存储
- urlCache:用于向会话中的请求提供缓存响应的URL缓存
- requestCachePolicy:一个预定义常量,用于确定何时从缓存中返回响应
- sessionSendsLaunchEvents:一个布尔值,指示在传输完成时是否应该在后台继续或启动应用程序
- isDiscretionary:一个布尔值,用于确定是否可以根据系统的判断来调度后台任务以获得最佳性能
- protocolClasses:在会话中处理请求的额外协议子类的数组
- URLProtocol:一个NSURLProtocol对象处理加载协议特定的URL数据。在NSURLProtocol类本身是一个抽象类,可以为与特定URL方案的URL处理基础设施。您可以为您的应用支持的任何自定义协议或URL方案创建子类
- multipathServiceType:指定用于通过Wi-Fi和蜂窝接口传输数据的多路径TCP连接策略的服务类型
- URLSessionConfiguration.MultipathServiceType:指定多路径TCP使用的服务类型的常量
- httpMaximumConnectionsPerHost:同时连接到给定主机的最大数量。
- httpShouldUsePipelining:一个布尔值,用于确定会话是否应使用HTTP流水线
- connectionProxyDictionary:包含有关在此会话中使用的代理信息的字典
- waitsForConnectivity:一个布尔值,指示会话是否应等待连接变为可用或者立即失败
- NSURLRequestUseProtocolCachePolicy = 0 : 默认缓存策略
如果一个NSCachedURLResponse对于请求并不存在数据将会从源端获取。如果请求拥有一个缓存的响应,那么URL加载系统会检查这个响应来决定,如果它指定内容必须重新生效的话。假如内容必须重新生效,将建立一个连向源端的连接来查看内容是否发生变化。假如内容没有变化,那么响应就从本地缓存返回数据。如果内容变化了,那么数据将从源端获取 - NSURLRequestReloadIgnoringLocalCacheData = 1:URL应该加载源端数据,不使用本地缓存数据
- NSURLRequestReloadIgnoringLocalAndRemoteCacheData =4:本地缓存数据、代理和其他中介都要忽视他们的缓存,直接加载源数据
- NSURLRequestReloadIgnoringCacheData=NSURLRequestReloadIgnoringLocalCacheData
- NSURLRequestReturnCacheDataElseLoad = 2:指定已存的缓存数据应该用来响应请求,不管它的生命时长和过期时间。如果在缓存中没有已存数据来响应请求的话,数据从源端加载
- NSURLRequestReturnCacheDataDontLoad = 3:指定已存的缓存数据用来满足请求,不管生命时长和过期时间。如果在缓存中没有已存数据来响应URL加载请求的话,不去尝试从源段加载数据,此时认为加载请求失败。这个常量指定了一个类似于离线模式的行为
- NSURLRequestReloadRevalidatingCacheData = 5:指定如果已存的缓存数据被提供它的源段确认为有效则允许使用缓存数据响应请求,否则从源段加载数据。
原文作者:逻辑iOS技术号(Cooci)
公众号: