iOS架构设计-URL缓存(上)

概览

缓存组件应该说是每个客户端程序必备的核心组件,试想对于每个界面的访问都必须重新请求势必降低用户体验。但是如何处理客户端缓存貌似并没有统一的解决方案,多数开发者选择自行创建数据库直接将服务器端请求的JSON(或Model)缓存起来,下次请求则查询数据库检查缓存是否存在;另外还有些开发者会选择以归档文件的方式保存缓存数据,每次请求资源之前检查相应的缓存文件。事实上iOS系统自身就提供了一套缓存机制,本文将结合URL

Loading

System介绍一下如何利用系统自身缓存设计来实现一套缓存机制,使用这套缓存设计你无需自己编写内存和磁盘存储,无需自行检查缓存过期策略就能轻松实现数据缓存。

URL Loading System

URL Loading System是类和协议的集合,使用URL

Loading System

iOS系统和服务器端进行网络交互。URL作为其中的核心,能够让app和资源进行轻松的交互。为了增强URL的功能Foundation提供了丰富的类集合,能够让你根据地址加载资源、上传资源到服务器、管理cookie、控制响应缓存(这也是我们今天的重点内容)、处理证书和认证、扩展用户协议(后面也会提到相关内容)等,因此URL缓存之前熟悉URL

Loading System是必要的。下图一系列集合的关系:

本文代码一律使用Swift编写,但是鉴于很多朋友接触URL Loading System都是从Objective-C开始,所以文章中文字部分还是采用OC命名,其区别不大,主要是少了NS前缀。

NSURLProtocol

URL

Loading System默认支持http、https、ftp、file和data

协议,但是它同样也支持你注册自己的类来支持更多应用层网络协议,当然你也可以指定其他属性到URL reqeust和URL

response上。具体而言NSURLProtocl可以实现以下需求(包含但不限):

重定向网络请求(或进行域名转化、拦截等,例如:netfox)

忽略某些请求,使用本地缓存数据

自定义网络请求的返回结果 (比如:GYHttpMocking)

进行网络全局配置

NSURLProtocol类似中间人设计,将网络求细节提供给开发者,而又以一种优雅的方式暴漏出来。NSURLProtocol的定义更像是一个URL协议,尽管它继承自NSObject却不能直接使用,使用时自定义协议继承NSURLProtocol,然后在app启动时注册即可,这样一来所有请求细节开发者只需要在自己的类中控制即可(这个设计确实完美👍)。

解决DNS劫持

随着互联网的发展,运营商劫持这些年逐渐被大家所提及,常见的劫持包括HTTP劫持和DNS劫持。对于HTTP劫持更多的是篡改网络响应加入一些脚本广告之类的内容,解决这个问题只需要使用https加密请求交互内容;而对于DNS劫持则更加可恶,在DNS解析时让请求重新定向到一个非预期IP从而达到内容篡改。

解决DNS劫持普遍的做法就是将URL从域名替换成IP,这么一来访问内容并不经过运营商的Local

DNS而到达指定的服务器,因此也就避免了DNS劫持问题。当然,域名和IP的对应要通常通过服务器下发保证获取最近的资源节点(当然也可以采用一些收费的HTTPDNS服务),不过这样一来操作却不得不依赖于具体请求,而使用自定义NSURLProtocol的方式则可以彻底解决具体依赖问题,不管是使用NSURLConnection、NSURLSession、AFNetworking还是UIWebView(注意WKWebView有所不同),所有的替换操作都可以统一进行控制。

下面的demo中自定义协议MyURLProtocol实现了将域名转化成IP进行请求的过程:

import UIKit

class MyURLProtocol: URLProtocol{

// MARK: - URLProtocol虚方法实现

// 是否处理对应的请求

override class func canInit(with request: URLRequest) -> Bool {

if URLProtocol.property(forKey: MyURLProtocol.PropertyKey.tagKey, in: request) != nil {

return false

}

return true

}

// 返回请求,在此方法中可以修改请求

override class func canonicalRequest(for request: URLRequest) -> URLRequest {

var newRequest = request

// 例如这里域名为指定ip,实际开发中应该从服务器下方domain list

let originHost = request.url?.host

if "baidu.com" == originHost {

let originURL = request.url?.absoluteString

let newURL = originURL?.replacingOccurrences(of: originHost!, with: "61.135.169.121")

newRequest.url = URL(string: newURL!)

}

return newRequest

}

// 开始加载

override func startLoading() {

guard let newRequest = (request as NSURLRequest).mutableCopy() as? NSMutableURLRequest else { return}

URLProtocol.setProperty(true, forKey: MyURLProtocol.PropertyKey.tagKey, in: newRequest)

let sessionConfig = URLSessionConfiguration.default

let urlSession = URLSession(configuration: sessionConfig, delegate: self, delegateQueue: nil)

self.dataTask = urlSession.dataTask(with: self.request)

self.dataTask?.resume()

}

// 停止加载

override func stopLoading() {

self.dataTask?.cancel()

self.dataTask       = nil

self.receivedData   = nil

self.urlResponse    = nil

}

// 判断两个请求是否相等,相等则考虑使用缓存,此方法不是必须实现

override class func requestIsCacheEquivalent(_ a: URLRequest, to b: URLRequest) -> Bool {

return super.requestIsCacheEquivalent(a, to: b)

}

// MARK: - 私有属性

private struct MyURLProtocolKey {

var tagKey = "MyURLProtocolTagKey"

}

fileprivate var dataTask: URLSessionDataTask?

fileprivate var urlResponse: URLResponse?

fileprivate var receivedData: NSMutableData?

}

extension MyURLProtocol {

struct PropertyKey{

static var tagKey = "MyURLProtocolTagKey"

}

}

// 注意实际开发中应该尽可能处理所有self.client?.urlProtocol回传方法,以免客户端有些方法无法做出响应

extension MyURLProtocol:URLSessionTaskDelegate,URLSessionDataDelegate {

// MARK: - URLSessionDataDelegate方法

func urlSession(_ session: URLSession, dataTask: URLSessionDataTask,

didReceive response: URLResponse, completionHandler: @escaping

(URLSession.ResponseDisposition) -> Void) {

self.client?.urlProtocol(self, didReceive: response, cacheStoragePolicy: .notAllowed)

self.urlResponse = response

self.receivedData = NSMutableData()

completionHandler(.allow)

}

func urlSession(_ session: URLSession, dataTask: URLSessionDataTask, didReceive data: Data) {

self.client?.urlProtocol(self, didLoad: data as Data)

self.receivedData?.append(data as Data)

}

// URLSessionTaskDelegate

func urlSession(_ session: URLSession, task: URLSessionTask, didCompleteWithError error: Error?) {

if error != nil {

self.client?.urlProtocol(self, didFailWithError: error!)

} else {

//saveCachedResponse()

self.client?.urlProtocolDidFinishLoading(self)

}

}

}

注意使用URLSession进行网络请求时如果使用的不是默认会话(URLSession.shared)则需要在URLSessionConfiguration中指定protocolClasses自定义URLProtocol才能进行处理(即使使用URLProtocol.registerClass进行注册),URLSession.shared默认则可以响应已注册URLProtocol。

在MyURLProtocol的startLoading方法内同样发起了URL请求,如果此时使用了URLSession.shared进行网络请求则同样会造成MyURLProtocol调用,如此会引起循环调用。考虑到startLoading方法能可能是NSURLConnnection实现,安全起见在MyURLProtocol内部使用URLProtocol.setProperty(true, forKey: MyCacheURLProtocolTagKey, in: newRequest)来标记一个请求,调用前使用URLProtocol.property(forKey: MyCacheURLProtocolTagKey, in: request)判断当前请求是否已经标记,如果已经标记则视为同一请求,MyURLProtocol则不再处理,从而避免同一个请求循环调用。

如果你的网络请求使用的NSURLConnection,上面的代码需要做相应修改,但相信现在NSURLConnection使用应该越来越少了,很多第三方网络库也不支持了。

NSURLProtocol缓存

其实无论是NSURLConnection、NSURLSession还是UIWebView、WKWebView默认都是有缓存设计的(使用NSURLCache,后面会着重介绍),不过这要配合服务器端response header使用,对于有缓存的页面(或者API接口),当缓存过期后,默认情况下(NSURLRequestUseProtocolCachePolicy)遇到同一个请求则通常会发出一个header中包含If-Modified-Since的请求到服务器端验证,如果内容没有过期则返回一个不含有body的响应(Response code为304),客户端使用缓存数据,否则重新返回新的数据。

由于WKWebView默认有几十秒的缓存时间,在第一次缓存响应后过一段时间才会进行缓存请求检查(缓存过期后才会发送包含If-Modified-Since的请求检查)。但是这并不是说自己设计缓存就完全没有必要,第一它做不到完全的离线后阅读(尽管在一定时间内不需要检查,但是过一段时间还是需要联网检查的),第二无法做到缓存细节的控制。

下面简单利用NSURLProtocol来实现WKWebView的离线缓存功能,不过需要注意的是WKWebView默认仅仅调用NSURLProtocol的canInitWithRequest:方法,如果要真正利用NSURLProtocol进行缓存还必须使用WKBrowsingContextController的registerSchemeForCustomProtocol进行注册,不过这是个私有对象,需要使用黑魔法。下面的demo中简单实现了WKWebView的离线缓存功能,有了它之后遇到访问过的资源即使没有网络也同样可以访问。当然,示例主要用以说明缓存的原理,实际开发中还有很多问题需要思考,比如说缓存过期机制、磁盘缓存保存方式等等。

import UIKit

class MyCacheURLProtocol: URLProtocol{

// MARK: - URLProtocol虚方法实现

// 是否处理对应的请求

override class func canInit(with request: URLRequest) -> Bool {

if URLProtocol.property(forKey: MyCacheURLProtocol.PropertyKey.tagKey, in: request) != nil {

return false

}

return true

}

// 返回请求,在此方法中可以修改请求

override class func canonicalRequest(for request: URLRequest) -> URLRequest {

return request

}

// 开始加载

override func startLoading() {

func sendRequest() {

guard let newRequest = (request as NSURLRequest).mutableCopy() as? NSMutableURLRequest else { return}

URLProtocol.setProperty(true, forKey: MyCacheURLProtocol.PropertyKey.tagKey, in: newRequest)

let sessionConfig = URLSessionConfiguration.default

let urlSession = URLSession(configuration: sessionConfig, delegate: self, delegateQueue: nil)

self.dataTask = urlSession.dataTask(with: self.request)

self.dataTask?.resume()

}

if let cacheResponse = self.getResponse() {

self.client?.urlProtocol(self, didReceive: cacheResponse.response, cacheStoragePolicy: .notAllowed)

self.client?.urlProtocol(self, didLoad: cacheResponse.data)

self.client?.urlProtocolDidFinishLoading(self)

} else {

sendRequest()

}

}

// 停止加载

override func stopLoading() {

self.dataTask?.cancel()

self.dataTask       = nil

self.receivedData   = nil

self.urlResponse    = nil

}

// 判断两个请求是否相等,相等则考虑使用缓存,此方法不是必须实现

override class func requestIsCacheEquivalent(_ a: URLRequest, to b: URLRequest) -> Bool {

return super.requestIsCacheEquivalent(a, to: b)

}

// MARK: - 私有方法

fileprivate func saveResponse(_ response:URLResponse,_ data:Data) {

if let key = self.request.url?.absoluteString {

let tempDic = NSTemporaryDirectory() as NSString

let filePath = tempDic.appendingPathComponent(key.md5())

let cacheResponse = CachedURLResponse(response: response,

data: data, userInfo: nil, storagePolicy:

URLCache.StoragePolicy.notAllowed)

NSKeyedArchiver.archiveRootObject(cacheResponse, toFile: filePath)

}

}

fileprivate func getResponse() -> CachedURLResponse? {

if let key = self.request.url?.absoluteString {

let tempDic = NSTemporaryDirectory() as NSString

let filePath = tempDic.appendingPathComponent(key.md5())

if FileManager.default.fileExists(atPath: filePath) {

return NSKeyedUnarchiver.unarchiveObject(withFile: filePath) as? CachedURLResponse

}

return nil

}

return nil

}

// MARK: - 私有属性

fileprivate var dataTask: URLSessionDataTask?

fileprivate var urlResponse: URLResponse?

fileprivate var receivedData: NSMutableData?

}

extension MyCacheURLProtocol {

struct PropertyKey{

static var tagKey = "MyURLProtocolTagKey"

}

}

// 注意实际开发中应该尽可能处理所有self.client?.urlProtocol回传方法,以免客户端有些方法无法做出响应

extension MyCacheURLProtocol:URLSessionTaskDelegate,URLSessionDataDelegate {

// MARK: - URLSessionDataDelegate方法

func urlSession(_ session: URLSession, dataTask: URLSessionDataTask,

didReceive response: URLResponse, completionHandler: @escaping

(URLSession.ResponseDisposition) -> Void) {

self.client?.urlProtocol(self, didReceive: response, cacheStoragePolicy: .notAllowed)

self.urlResponse = response

self.receivedData = NSMutableData()

completionHandler(.allow)

}

func urlSession(_ session: URLSession, dataTask: URLSessionDataTask, didReceive data: Data) {

self.client?.urlProtocol(self, didLoad: data as Data)

self.receivedData?.append(data as Data)

}

// URLSessionTaskDelegate

func urlSession(_ session: URLSession, task: URLSessionTask, didCompleteWithError error: Error?) {

if error != nil {

self.client?.urlProtocol(self, didFailWithError: error!)

} else {

self.client?.urlProtocolDidFinishLoading(self)

//save cache

if self.urlResponse != nil && self.receivedData != nil {

self.saveResponse(self.urlResponse!, self.receivedData?.copy() as! Data)

}

}

}

}

NSURLCache

事实上无论是NSURLConnection、URLSession还是UIWebView、WKWebView默认都是包含缓存的(注意WKWebView的缓存配置是从iOS

9.0开始提供的,但是其实iOS

8.0中也同样包含缓存设计,只是没有提供缓存配置接口)。对于多数开发者而言缓存设计考虑更多的是磁盘缓存(如果需要做内存缓存建议使用NSCache,提供了缓存过高自动移除功能

or

YYCache),而磁盘缓存设计大致可以分为API访问返回的JSON缓存(通过NSURLConnection或者NSURLSession请求标准的JSON数据)和客户端web页面缓存(UIWebView、WKWebView)。

NSURLConnection和UIWebView来说,默认都会使用NSURLCache,通常在应用启动中会进行NSURLCache配置,当然即使不进行配置也是有默认配置的。但二者并不是今天介绍的重点,我们重点关注NSURLSession和WKWebView。对于NSURLSession而言默认仍然会使用全局的NSURLCache(可以在启动时自己初始化,例如

URLCache.shared = URLCache(memoryCapacity: 5*1024*1024, diskCapacity: 20*1024*1024, diskPath: nil))

但是相比于默认NSURLConnection而言NSURLSession更加灵活,因为每个URLSessionConfiguration都可以指定独立的URLCache,默认情况下是使用一个私有内存缓存,如果设置为nil则不再使用缓存。而且还可以通过URLSessionConfiguration的requestCachePolicy属性指定缓存策略。

缓存策略CachePolicy

useProtocolCachePolicy:默认缓存策略,对于特定URL使用网络协议中实现的缓存策略。

reloadIgnoringLocalCacheData(或者reloadIgnoringCacheData):不使用缓存,直接请求原始数据。

returnCacheDataElseLoad:无论缓存是否过期,有缓存则使用缓存,否则重新请求原始数据。

returnCacheDataDontLoad:无论缓存是否过期,有缓存则使用缓存,否则视为失败,不会重新请求原始数据。

其实对于多数开发者而言,第二种根本不缓存,其他两种也存在着很大的使用风险,所以默认缓存策略才是我们最关心的,它使用网络协议中实现的缓存策略,那我们就应该首先弄清网络协议中的缓存策略是如何来控制的(注意:无论是NSURLConnection还是NSURLSession都支持多种协议,这里重点关注HTTP、HTTPS)。

HTTP的请求和响应使用headers来进行元数据交换,例如MIME、Encoding,当然也包括缓存执行,下面会着重介绍相关缓存配置。

请求头信息 Request cache headers

If-Modified-Since:与响应头Last-Modified相对应,其值为最后一次响应头中的Last-Modified。

If-None-Match:与响应头Etag相对应,其值为最后一次响应头中的Etag。

响应头信息 Response cache headers

Last-Modified:资源最近修改时间

Etag:(Entity tag缩写)是请求资源的标识符,主要用于动态生成、没有Last-Modified值的资源。

Cache-Control:缓存控制,只有包含此设置可能使用默认缓存策略。可能包含如下选项:

max-age:缓存时间(单位:秒)。

public:可以被任何区缓存,包括中间经过的代理服务器也可以缓存。通常不会被使用,因为 max-age已经表示此响应可以缓存。

private:只能被当前客户端缓存,中间代理无法进行缓存。

no-cache:必须与服务器端确认响应是否发生了变化,如果没有变化则可以使用缓存,否则使用新请求的响应。

no-store:禁止使用缓存

Vary:决定如何决定请求是否可以使用缓存,通常用于缓存key唯一值确定因素,同一个资源不同的Vary设置会被作为两个缓存资源(注意,NSURLCache会忽略Vary请求缓存)。

注意:Expires是HTTP

1.0标准缓存控制,不建议使用,请使用Cache-Control:max-age代替,类似的还有Pragma:no-cache和Cache-Control:no-cache。此外,Request

cache headers中也是可以包含Cache-Control的,例如如果设置为no-cache则说明此次请求不要使用缓存数据作为响应。

默认缓存策略下当客户端发起一个请求时首先会检查本地是否包含缓存,如果有缓存则继续检查缓存是否过期(通过Cache-Control:max-age或者Expires),如果没有过期则直接使用缓存数据。如果缓存过期了,则发起一个请求给服务器端,此时服务器端对比资源Last-Modified或者Etags(二者都存在的情况下下如果有一个不同则认为缓存已过期),如果不同则返回新数据,否则返回304

Not

Modified继续使用缓存数据(客户端可以再使用"max-age"秒缓存数据)。在这个过程中可以发现,客户端发送不发送请求主要看max-age是否过期,而过期后是否继续访问则需要重新发起请求,服务器端根据情况通知客户端是否可以继续使用缓存(这个过程是必须请求的,只是返回结果可能是200或者304)。

清楚了默认网络协议缓存相关的设置之后,要使用默认缓存就很简单了,通常对于NSURLSession你不做任何设置,只要服务器端响应头部加上Cache-Control:max-age:xxx就可以使用缓存了。下面Demo3中演示了如何使用使用NSURLSession通过max-age进行为期60s的缓存,运行会发现在第一次请求之后60s内不会进行再次请求,60s后才会发起第二次请求。

let config = URLSessionConfiguration.default

// urlCache默认使用私有内存缓存

// config.urlCache = URLCache(memoryCapacity: 5*1024*1024, diskCapacity: 20*1024*1024, diskPath: nil)

// config.requestCachePolicy = .useProtocolCachePolicy

let urlSession = URLSession(configuration: config)

if let url = URL(string: "http://myapi.applinzi.com/url-cache/default-cache.php") {

let dataTask = urlSession.dataTask(with: url, completionHandler: { (data, response, error) in

if let tempError = error {

debugPrint(tempError)

} else {

guard let tempData = data else { return }

let responseText = String(data: tempData, encoding: String.Encoding.utf8)

debugPrint(responseText ?? "no text")

}

})

dataTask.resume()

}

服务器端default-cache.php内容如下:


$time=time();

$interval=60;

header('Last-Modified: '.gmdate('r',$time));

header('Expires: '.gmdate('r',($time+$interval)));

header('Cache-Control: max-age='.$interval);

header('Content-type: text/json');

$arr = array('a'=>1,'b'=>2);

echo json_encode($arr);

?>

对应的请求和相应头信息如下,服务器端设置缓存60s:

当然,配合服务器端使用缓存是一种不错的方案,自然官方设计时也是希望尽可能使用默认缓存策略。但是有些时候服务器端出于其他原因考虑,或者说或客户端需要自定义缓存策略时还是有必要进行手动缓存管理的。比如说如果服务器端根本没有设置缓存过期时间或者服务器端根本无法获知用户何时清理缓存、何时使用缓存这些具体逻辑等都需要服务器端自行制定缓存策略。有不少朋友选择自建数据库直接缓存JSON模型(通常是NSArray或者NSDictionary)或者缓存成归档文件等,其实使用NSURLCache默认的缓存策略依然可行,只是需要使用相关的代理方法、控制缓存逻辑:

对于NSURLConnnection而言可以通过

- (NSCachedURLResponse *)connection:(NSURLConnection *)connection willCacheResponse:(NSCachedURLResponse *)cachedResponse

进行二次缓存设置,如果此方法返回nil则不进行缓存,默认不实现这个代理则会走默认缓存策略。而URLSessionDataDelegate也有一个类似的方法是

func

urlSession(_ session: URLSession, dataTask: URLSessionDataTask,

willCacheResponse proposedResponse: CachedURLResponse,

completionHandler: @escaping (CachedURLResponse?) -> Swift.Void)

它的使用和NSURLConnection是类似的,不同的是

dataTask(with url: URL, completionHandler: @escaping (Data?, URLResponse?, Error?) -> Swift.Void)

等一系列带有completionHandler的方法并不会走代理方法,所以这种情况下

func

urlSession(_ session: URLSession, dataTask: URLSessionDataTask,

willCacheResponse proposedResponse: CachedURLResponse,

completionHandler: @escaping (CachedURLResponse?) -> Swift.Void)

也是无法使用的,使用时需要特别注意。

事实上无论URLSession走缓存相关的代理,还是通过completionHandler进行回调,默认都会使用NSURLCache进行缓存,无需做任何工作。例如Demo3中的示例2、3都都打印出了默认的缓存信息,不过如果服务器端不进行缓存设置的话(header中设置Cache-Control),默认情况下NSURLSession是不会使用缓存数据的。如果将缓存策略设置为优先考虑缓存使用(例如使用:.returnCacheDataElseLoad),则可以看到下次请求不会再发送请求,Demo3中的示例4演示了这一情况。不过一旦如此设置之后以后想要更新缓存就变得艰难了,因为只要不清空缓存或超过缓存限制,缓存数据就一直存在,而且在应用中随时换切换缓存策略成本也并不低。因此,要合理利用系统默认缓存的出发点还是应该着眼在默认的基于网络协议的缓存设置,因为使用这个缓存策略基本已经很完美了。

不过这样一来缓存的控制逻辑就上升为解决缓存问题的重点,比如说一个API接口设计多数情况下可以缓存,但是一旦用户修改了部分信息则希望及时更新使用最新数据,但是缓存不过期服务器端即使很了解客户端设计也无法做到强制更新缓存,因此客户端就不得不自行控制缓存。那么能不能强制NSURLCache使用网络协议缓存策略呢,其实也是可以的,对于服务器端没有添加cache

headers控制的响应只需要添加上响应的缓存控制即可。Demo3的示例5说明了这一点。

import UIKit

class DemoViewController3: UIViewController {

override func viewDidLoad() {

super.viewDidLoad()

}

@IBAction func requestWithServerCache1() {

let config = URLSessionConfiguration.default

// urlCache默认使用私有内存缓存

// config.urlCache = URLCache(memoryCapacity: 5*1024*1024, diskCapacity: 20*1024*1024, diskPath: nil)

// config.requestCachePolicy = .useProtocolCachePolicy

let urlSession = URLSession(configuration: config)

if let url = URL(string: "http://myapi.applinzi.com/url-cache/default-cache.php") {

let dataTask = urlSession.dataTask(with: url, completionHandler: { (data, response, error) in

if let tempError = error {

debugPrint(tempError)

} else {

guard let tempData = data else { return }

let responseText = String(data: tempData, encoding: String.Encoding.utf8)

debugPrint(responseText ?? "no text")

}

})

dataTask.resume()

}

}

@IBAction func requestWithoutServerCache2() {

let config = URLSessionConfiguration.default

let urlSession = URLSession(configuration: config, delegate: self.delegate, delegateQueue: nil)

if let url = URL(string: "http://myapi.applinzi.com/url-cache/no-cache.php") {

let dataTask = urlSession.dataTask(with: url)

dataTask.resume()

}

}

@IBAction func requestWithoutServerCache3() {

let config = URLSessionConfiguration.default

let urlSession = URLSession(configuration: config, delegate: self, delegateQueue: nil)

if let url = URL(string: "http://myapi.applinzi.com/url-cache/no-cache.php") {

let urlRequest = URLRequest(url: url)

let dataTask = urlSession.dataTask(with: urlRequest, completionHandler: { (data, response, error) in

if let tempError = error {

debugPrint(tempError)

} else {

guard let tempData = data else { return }

let responseText = String(data: tempData, encoding: String.Encoding.utf8)

let cacheResponse = URLCache.shared.cachedResponse(for: urlRequest)

debugPrint(cacheResponse)

debugPrint(responseText ?? "no text")

}

})

dataTask.resume()

}

}

@IBAction func requestWithoutServerCache4() {

let config = URLSessionConfiguration.default

// 使用缓存数据

config.requestCachePolicy = .returnCacheDataDontLoad

let urlSession = URLSession(configuration: config, delegate: self, delegateQueue: nil)

if let url = URL(string: "http://myapi.applinzi.com/url-cache/no-cache.php") {

let urlRequest = URLRequest(url: url)

let dataTask = urlSession.dataTask(with: urlRequest, completionHandler: { (data, response, error) in

if let tempError = error {

debugPrint(tempError)

} else {

guard let tempData = data else { return }

let responseText = String(data: tempData, encoding: String.Encoding.utf8)

let cacheResponse = URLCache.shared.cachedResponse(for: urlRequest)

debugPrint(cacheResponse)

debugPrint(responseText ?? "no text")

}

})

dataTask.resume()

}

}

@IBAction func requestWithoutServerCache5() {

let config = URLSessionConfiguration.default

let urlSession = URLSession(configuration: config, delegate: self, delegateQueue: nil)

if let url = URL(string: "http://myapi.applinzi.com/url-cache/no-cache.php") {

let dataTask = urlSession.dataTask(with: url)

dataTask.resume()

}

}

private var delegate =  DemoViewController3Delegate()

}

extension DemoViewController3:URLSessionDelegate, URLSessionDataDelegate {

func urlSession(_ session: URLSession, dataTask: URLSessionDataTask, didReceive data: Data) {

let responseText = String(data: data, encoding: String.Encoding.utf8)

debugPrint(responseText ?? "no text")

}

public func urlSession(_ session: URLSession, dataTask:

URLSessionDataTask, willCacheResponse proposedResponse:

CachedURLResponse, completionHandler: @escaping (CachedURLResponse?)

-> Swift.Void) {

if let httpResponse = proposedResponse.response as? HTTPURLResponse {

if httpResponse.allHeaderFields["Cache-Control"] == nil {

let newHeaders = (httpResponse.allHeaderFields as NSDictionary).mutableCopy() as? NSDictionary

newHeaders?.setValue("max-age=60", forKey: "Cache-Control")

let newResponse = HTTPURLResponse(url: httpResponse.url!,

statusCode: httpResponse.statusCode, httpVersion: "HTTP/1.1",

headerFields: newHeaders as? [String : String])

let newCacheResponse = CachedURLResponse(response: newResponse!, data: proposedResponse.data)

completionHandler(newCacheResponse)

return

}

}

completionHandler(proposedResponse)

}

}

// for requestWithoutServerCache2

class DemoViewController3Delegate:NSObject,URLSessionDelegate, URLSessionDataDelegate {

func urlSession(_ session: URLSession, dataTask: URLSessionDataTask, didReceive data: Data) {

let responseText = String(data: data, encoding: String.Encoding.utf8)

debugPrint(responseText ?? "no text")

}

public func urlSession(_ session: URLSession, dataTask:

URLSessionDataTask, willCacheResponse proposedResponse:

CachedURLResponse, completionHandler: @escaping (CachedURLResponse?)

-> Swift.Void) {

completionHandler(proposedResponse)

debugPrint(proposedResponse)

}

}

原文地址:iOS架构设计-URL缓存(上) 


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

推荐阅读更多精彩内容