一個Hybrid APP，如何做離線緩存策略?也可以簡單來說，你的APP只是一個殼，里面真正加載的內容是H5，如果優(yōu)化加載內容的速度?

先了解一下NSURLProtocol

從面意思看它是一個協(xié)議，但是它其實是一個類，而且繼承自NSObject。它的作用是處理特定URL協(xié)議的加載。它本身是一個抽象類，提供了使用特性URL方案處理URL的基礎結構。你可以自己創(chuàng)建NSURLProtocol的子類，來讓自己的應用支持自定義的協(xié)議或者URL方案。

應用程序永遠不需要直接實例化一個NSURLProtocol子類。當一個下載開始的時候，系統(tǒng)創(chuàng)建一個合適的protoco對象來響應URL請求。你要做的就是自己定義一個你自己的protocol，然后在APP啟動的時候調用registerClass:，讓系統(tǒng)知道你的協(xié)議。

這里需要注意：你不能在watchOS 2以及更高版本中自定義URL scheme和協(xié)議。

為了支持特定的自定義請求，你***定義NSURLRequest 或者NSMutableURLRequest。讓自定義的這些對象來實現(xiàn)請求，這里需要使用NSURLProtocol的propertyForKey:inRequest:和setProperty:forKey:inRequest，然后你可以自定義NSURLResponse類來模擬返回信息。

接下來就開始對UIWebView進行離線緩存處理。

UIWebView的離線緩存處理

首先，我們需要自定義一個NSURLProtocol的子類，并且在AppDelegate.m的

- (BOOL)application:(UIApplication *)application didFinishLaunchingWithOptions:(NSDictionary *)launchOptions { 
    [NSURLProtocol registerClass:[ZGURLProtocol class]]; 
    return YES; 
} 

注冊。接下來的所有操作就都是在我們自定義的ZGURLProtocol中操作了。先看一下registerClass的作用：

嘗試注冊一個NSURLProtocol的子類，使其對 URL Loading System 可見。這里的URL Loading System就是一組類和協(xié)議，允許你的應用程序訪問由URL產生的內容，比如請求、接收內容和Cache等。當URL Load System開始加載一個請求的時候，每個注冊的協(xié)議類都被依次去調用，以確定是否可以用指定的請求去初始化它。首先被調用的方法是：

+ (BOOL)canInitWithRequest:(NSURLRequest *)request; 

在該方法里面進行緩存過濾，比如你想只緩存js，那么判斷request的path的后綴，如果是js，就返回YES，否則返回NO。

如果返回YES，那么就相當于該請求被自定義的URLProtocol來處理，這里不能保證所有的注冊的NSURLProtocol都能被處理到。如果你定義了多個NSProtocol子類，這些子類將會以相反的順序調用。也就是說如果你是這樣寫的：

[NSURLProtocol registerClass:[ZGURLProtocol class]];  
[NSURLProtocol registerClass:[ZProtocol class]]; 

那么***執(zhí)行的是ZProtocol，如果參initWithRequest:返回的為YES，則請求由ZProtocol進行處理，且不會再走ZGURLProtocol。如果ZProtocol的initWithRequest:返回的為NO，則請求繼續(xù)向下傳遞由其他的NSURLProtocol子類處理。

一旦返回YES，那么請求將會由自己寫的子類處理，首先會調用：

+ (NSURLRequest *)canonicalRequestForRequest:(NSURLRequest *)request 

這個是一個抽象的方法，子類必須對其實現(xiàn)。通常情況下，我們一般都是直接返回request，但是這里你也可以直接修改此request，包括header，hosts等。可以對指定request進行重定向操作。

在這里，我們只是將現(xiàn)有的request進行返回即可。

緊接著，便會開始請求：

- (void)startLoading; 

該方法的作用就是開始請求protocol指定的請求。該方法也是protocol子類必須實現(xiàn)的方法。在這里所做的操作就是：

先判斷是否有緩存數(shù)據(jù)，如果有，則自己創(chuàng)建NSURLResponse，然后將緩存數(shù)據(jù)放入，并進行client的一些操作，然后返回;如果沒有緩存數(shù)據(jù)，則新建一個NSURLConnection，然后發(fā)送請求。

先說一下有緩存的情況下：

if (model.data && model.MIMEType) { 
        NSURLResponse *response = [[NSURLResponse alloc] initWithURL:self.request.URL MIMEType:model.MIMEType expectedContentLength:model.data.length textEncodingName:nil]; 
        [self.client URLProtocol:self didReceiveResponse:response cacheStoragePolicy:NSURLCacheStorageAllowed]; 
        [self.client URLProtocol:self didLoadData:model.data]; 
        [self.client URLProtocolDidFinishLoading:self]; 
        return; 
    } 

(model是緩存數(shù)據(jù))有緩存的情況下,直接使用緩存的數(shù)據(jù)和MIME類型，然后構建NSURLResponse，然后通過協(xié)議client調用代理方法。這里的client是一個protocol，如下：

@protocol NSURLProtocolClient <NSObject>  
- (void)URLProtocol:(NSURLProtocol *)protocol wasRedirectedToRequest:(NSURLRequest *)request redirectResponse:(NSURLResponse *)redirectResponse; 
- (void)URLProtocol:(NSURLProtocol *)protocol cachedResponseIsValid:(NSCachedURLResponse *)cachedResponse;  
- (void)URLProtocol:(NSURLProtocol *)protocol didReceiveResponse:(NSURLResponse *)response cacheStoragePolicy:(NSURLCacheStoragePolicy)policy; 
- (void)URLProtocol:(NSURLProtocol *)protocol didLoadData:(NSData *)data;  
- (void)URLProtocolDidFinishLoading:(NSURLProtocol *)protocol;  
- (void)URLProtocol:(NSURLProtocol *)protocol didFailWithError:(NSError *)error;  
- (void)URLProtocol:(NSURLProtocol *)protocol didReceiveAuthenticationChallenge:(NSURLAuthenticationChallenge *)challenge;  
- (void)URLProtocol:(NSURLProtocol *)protocol didCancelAuthenticationChallenge:(NSURLAuthenticationChallenge *)challenge;  
@end 

該協(xié)議提供了NSURLProtocol子類與URL Loading System進行溝通的接口。一個APP一定不要去實現(xiàn)這個協(xié)議。有緩存的情況下調用回調方法，然后進行處理。

在沒有緩存的情況下：

實例化一個connection，然后發(fā)起請求。在我們收到response的時候：

- (void)connection:(NSURLConnection *)connection didReceiveResponse:(NSURLResponse *)response { 
    self.responseData = [[NSMutableData alloc] init]; 
    self.responseMIMEType = response.MIMEType; 
    [self.client URLProtocol:self didReceiveResponse:response cacheStoragePolicy:NSURLCacheStorageNotAllowed]; 
} 

緊接著就是接收數(shù)據(jù)：

- (void)connection:(NSURLConnection *)connection didReceiveData:(NSData *)data { 
    [self.responseData appendData:data]; 
    [self.client URLProtocol:self didLoadData:data]; 
} 

接收完數(shù)據(jù)之后便調用了：

- (void)connectionDidFinishLoading:(NSURLConnection *)connection { 
    ZGCacheModel *model = [ZGCacheModel new]; 
    model.data = self.responseData; 
    model.MIMEType = self.responseMIMEType; 
    [self setMiType:model.MIMEType withKey:[self.request.URL path]];//userdefault存儲MIMEtype 
     
     
    [[ZGUIWebViewCache sharedWebViewCache] setCacheWithKey:self.request.URL.absoluteString value:model]; 
   
    [self.client URLProtocolDidFinishLoading:self]; 
} 

這個方法是結束家在之后的調用，我們需要在這里將請求過來的數(shù)據(jù)進行緩存。這樣我們本地就有了指定URL的返回數(shù)據(jù)。

這里還有一個重要的東西沒有介紹，那就是

[NSURLProtocol propertyForKey:ZGURLProtocolKey inRequest:request]  
[NSURLProtocol setProperty:@YES forKey:ZGURLProtocolKey inRequest:mutableRequest]; 

這里的

+ (void)setProperty:(id)value forKey:(NSString *)key inRequest:(NSMutableURLRequest *)request; 

作用是在指定的請求中設置與特定的鍵值相關聯(lián)。防止多次調用一個request。

這樣，我們就完成了UIWebView的離線緩存。在這里我封裝了一個 ZGUIWebViewCache 。感興趣的可以看一下。

WKWebView的離線緩存處理

WKWebView離線緩存和UIWebView緩存類似，只不過使用WKWebView除了一開始調用一下NSURLProtocol的canInitWithRequest：方法之后，之后的請求似乎就和NSURLProtocol完全無關了，網(wǎng)上都說WKWebView的請求是在獨立的進程里，所以不走NSURLProtocol。這里是通過NSURLProtocol+WKWebView類進行處理的，詳情可參見： ZGWKWebViewCache 。

剩下的處理過程就和UIWebView緩存處理類似了。

以上便是對網(wǎng)頁離線緩存的實現(xiàn)。