很多開發(fā)同學(xué)都會(huì)有這樣一個(gè)體會(huì)，在iOS的UIWebview中，第一次打開H5頁面的時(shí)候，特別慢，這是因?yàn)槭状未蜷_H5頁面，所有資源都要從服務(wù)器請(qǐng)求，所以很慢。二次刷新H5頁面的時(shí)候，發(fā)現(xiàn)加載速度很快，這是因?yàn)閁IWebview自身對(duì)H5做了緩存，但是退出UIWebview之后，再次進(jìn)來加載h5還是很慢，如果我們想做到一次加載之后，后面都能夠使用緩存加載，針對(duì)這個(gè)問題該如何處理呢？

UIWebview緩存主要是利用NSURLCache來實(shí)現(xiàn)內(nèi)存緩存或者本地緩存。內(nèi)存緩存的最大值是4M(410241024),本地緩存是20M。

1. NSURLCache *cache = [[NSURLCache alloc] initWithMemoryCapacity:4*1024 * 1024 diskCapacity:0 diskPath:nil];

2. [NSURLCache setSharedURLCache:cache];

其中[NSURLCache setSharedURLCache:cache]是針對(duì)當(dāng)前進(jìn)程中的所有clients做的共享緩存。由于iOS中當(dāng)前進(jìn)程中只有一個(gè)app, 所以只要是當(dāng)前app中UIWebview加載的H5頁面，都是共享這個(gè)緩存空間的。

3.在加入上述功能之后，利用charles抓包，發(fā)現(xiàn)第一次加載H5頁面時(shí)候，很多的css文件，在二次打開該頁面的時(shí)候，charles沒有抓到，這個(gè)也證明了，在將css等資源文件緩存之后，再次打開H5頁面之后，UIWebview直接從NSURLCache中獲取緩存的css等資源，不會(huì)再次發(fā)起請(qǐng)求。另外也可以在加載H5后，打印cache.currentMemoryUsage來查看對(duì)應(yīng)的內(nèi)存消耗情況，如果數(shù)字大于0，就說明緩存中已經(jīng)存儲(chǔ)H5內(nèi)容了。

以上是在內(nèi)存中緩存H5頁面，這個(gè)策略有個(gè)問題，如果用戶將進(jìn)程殺掉，再次打開H5的時(shí)候，需要重新緩存。還有另外一種緩存策略，在本地緩存H5內(nèi)容，主要是利用在NSURLCache子類中重寫- (NSCachedURLResponse *)cachedResponseForRequest:(NSURLRequest *)request方法。

另外說一下大家比較煩惱的UIWebview進(jìn)度條，用下面方法可以獲取進(jìn)度：

監(jiān)聽私有通知WebProgressEstimatedProgressKey,在回調(diào)的notification的userInfo里有一個(gè)KeyWebProgressEstimatedProgressKey對(duì)應(yīng)的value即為進(jìn)度值。

UIWebView是iOS上對(duì)WebKit的封裝，WebKit是渲染引擎，UIWebView是渲染引擎和JS引擎的組合。

WKWebView 有以下幾大主要進(jìn)步：

1.WebKit框架使用WKWebView來代替IOS的UIWebView和OSX的WebView，并且使用Nitro JavaScript引擎，這意味著所有第三方瀏覽器運(yùn)行JavaScript將會(huì)跟safari一樣快。

2.將瀏覽器內(nèi)核渲染進(jìn)程提取出 App，由系統(tǒng)進(jìn)行統(tǒng)一管理，這減少了相當(dāng)一部分的性能損失。

3.js 可以直接使用已經(jīng)事先注入 js runtime 的 js 接口給 Native 層傳值，不必再通過苦逼的 iframe 制造頁面刷新再解析自定義協(xié)議的奇怪方式。

4.支持高達(dá) 60 fps 的滾動(dòng)刷新率，內(nèi)置了手勢(shì)探測(cè)。

后語：希望大家在閱讀后順便點(diǎn)贊，以示鼓勵(lì)！堅(jiān)持是一種信仰，專注是一種態(tài)度！