摘要：的兼容性由于是現(xiàn)代的技術(shù)，以下的古老瀏覽器是不支持的。當(dāng)然也可以手動指定文件這些瀏覽器都不能直接使用緩存，即可能會要求你重新驗證，或者直接使用服務(wù)器文件。

親，如果你還在為你沒網(wǎng)打開不網(wǎng)頁而煩惱嗎？
親，你還在為你web服務(wù)器復(fù)雜的配置項而蛋疼嗎？
不要998，manifest抱回家~
manifest自H5橫空出世以來給前端網(wǎng)頁的瀏覽帶來了翻天覆地的變化，以前我們的網(wǎng)頁必須在有網(wǎng)的前提下打開(主要還是打開HTML), 但是現(xiàn)在，我們可以offline 瀏覽。 可以算是實現(xiàn)web app的一個特技。
manifest的兼容性 IE9+. 由于是現(xiàn)代的技術(shù)，IE9以下的古老瀏覽器是不支持的。所以，manifest主要應(yīng)用是針對現(xiàn)代瀏覽器或者手機端更多一些。

瀏覽器檢測你是否使用manifest特技時，是檢測html標(biāo)簽.

當(dāng)解析你的HTML時，發(fā)現(xiàn)存在manifest文件時，則會進行如下的操作:

(from alloy team)
manifest文件可以是任意后綴比如. usable.manifest||usable.mf等，但是他的MIMEtype必須設(shè)置正確.
記住，這個時候manifest會將HTML文件也一并保存，這需要注意。

一個簡單的demo:

CACHE MANIFEST
#version 1.3
/public/static/index.css
/public/static/header.css
NETWORK:
*
FALLBACK:
/userInfo/ /404.html
#額外需要添加的緩存文件
CACHE:
images/logo1.png
images/logo2.png

基本樣式就是上述

第一行必須是指定頭即, "CACHE MANIFEST"(不能有其他的). 表示哪些文件需要緩存。如果是相對路徑則是，在manifest文件所在的目錄下。而且，不能使通配符!!!(tm 你是還不是傻). 所以一般而言只能一個一個配置.

CACHE MANIFEST
#相對于manifest文件所在的目錄
    ./index.css 

注釋: 注釋使用#+"info"
可以對緩存文件性質(zhì)進行適當(dāng)?shù)恼f明。緩存后的文件，就會被帶上Expires的頭，表示可以不經(jīng)過服務(wù)器驗證直接使用本地文件。所以，返回status Code 為 200.
另外,CACHE 定義的文件內(nèi)容，和CACHE MANIFEST 是一個效果，只是跟在CACHE MANIFEST之后，就可以省略書寫CACHE，你添加上也可以。

CACHE MANIFEST
#version 1.3
CACHE:
/favicon.ico

而且CACHE可以放在文中的任意位置，不過一般都是放開頭，或者省略.

CACHE MANIFEST

# 緩存文件
index.html
css/style.css

NETWORK:
*

# 額外的需要緩存的文件
CACHE:
images/logo1.png
images/logo2.png
images/logo3.png

這里設(shè)置不使用緩存的文件，可以使用通配符"*"等。
* 表示，除了CACHE MANIFEST定義的文件之外的文件都不能被緩存。
當(dāng)然也可以手動指定文件:

NETWORK
*
http://www.example.com/index.html
http://www.example.com/header.png
http://www.example.com/blah/blah

這些瀏覽器都不能直接使用緩存，即,可能會要求你重新驗證，或者直接使用服務(wù)器文件。

這個tag,可用可不用。 用來表示，指定文件無法加載時，使用另外的文件代替。參數(shù)有兩部分構(gòu)成，第一部分是指定資源(可能存在文件未加載),第二部分是替代資源

FALLBACK:
/index.html /404.html
/static/* /404.html
/images/* /NotFound.jpg

當(dāng)index.html無法加載時，使用404.html代替. 這里有個要求，兩個路徑必須使用相對路徑并且與清單文件同源。

這算是一個附加屬性吧。通常設(shè)置內(nèi)容就只有:

SETTINGS:
prefer-online

表示，在有網(wǎng)的情況下，會先訪問服務(wù)器的文件，看有沒有更新，相當(dāng)于設(shè)置了Cache-Control:max-age=0,must-revalidate; + ETag||Last-modified. 不過，比較stupid的是，只有FF(Opera 12)支持.

而在服務(wù)器端，需要對manifest文件的MIME設(shè)置正確。這里以nginx為例, 具體設(shè)置一下MIME type

type{
  image/gif                             gif;  
  image/jpeg                            jpeg jpg;  
  application/x-javascript              js;  
  }

詳情可以參考: manifest文件配置

這里以gulp為例。 可以在npm里面很容易找到gulp-manifest這個生成插件.
直接下載:

npm install gulp-manifest --save-dev

然后在gulpfile里面配置:

gulp.task("manifest", function(){
  gulp.src(["build/**"], { base: "./" })
    .pipe(manifest({
      hash: true,
      preferOnline: true,
      network: ["*"],
      fallback:["/images/* /404.html"]
      filename: "app.manifest",
      exclude: "app.manifest"  //不保存manifest，不過有沒有效果一樣
     }))
    .pipe(gulp.dest("./"));
});

接著就會在目錄下生成app.manifest文件，里面就是一些基本的文件格式了。另外如果你想查看你電腦有多少網(wǎng)頁是manifest，可以直接訪問 chrome://appcache-internals/.

manifest對于單頁應(yīng)用可謂是如魚得水，但是，到了多頁應(yīng)用的層面，他的bug真的是暴露無遺。

1.頁面保存的復(fù)雜度，
2.文件的及時更新，
3.緩存文件的設(shè)置, 
4.死都會保存HTML,
5.文件下載出錯，則這次更新緩存失敗,
6.覆蓋所有緩存頭，除了Cache-Control:no-store
7.在Android 4.4的webview里，關(guān)閉之后會丟失cache
8.IE10不能很好的支持FALLBACK部分.

所以，appCache的bug也是非常多的。
例如，長尾更新問題，當(dāng)你的頁面保持在線的時候，是無法檢測文件已經(jīng)更新，除非你reload頁面，但是用戶并不知道你已經(jīng)更新，所以這里我們需要引進js的提供的緩存檢測API.

這是前端能夠摸到緩存最真實的API。我們可以通過這個API接口獲取到我們很多想要的東西:

var appcache = window.applicationCache;
console.log(appcache.status); //檢查當(dāng)前緩存狀態(tài)
console.log(appcache.IDLE); //緩存狀態(tài)常量，下面解釋

window.applicationCache.update()  
//update方法調(diào)用時，頁面會主動與服務(wù)器通信，檢查頁面當(dāng)前的緩存是否為最新的，如不是，則下載更新后的資源

window.applicationCache.swapCache()  //updateready后，更新到最新的應(yīng)用緩存

通常結(jié)合上述兩個方法和相應(yīng)的屬性我們可以手動觸發(fā)文件的更新(前提是 manifest文件改動).

var appCache = window.applicationCache;

appCache.update(); 
//檢查更新

if (appCache.status == window.applicationCache.UPDATEREADY) { 
//如果存在更新，并且已經(jīng)下載ok,則替換瀏覽器緩存
  appCache.swapCache();  
}

但是，此時頁面并不能用上最新的文件，只是瀏覽器的緩存已經(jīng)改變，網(wǎng)頁實際內(nèi)容還是原來的內(nèi)容，還需要手動進行reload，才能進行更新文件

window.addEventListener("load", function(e) {

  window.applicationCache.addEventListener("updateready", function(e) {
    if (window.applicationCache.status == window.applicationCache.UPDATEREADY) {
      if (confirm("文件有更新，手否重新加載文件")) {
        window.location.reload();
      }
    } else {
      //如果，拒絕則不刷新網(wǎng)頁
    }
  }, false);

}, false);

相關(guān)事件有: checking,downloading,updateready,obsolete,cached,error,noupdate,progress.
對照上述的status就可以很容易知道每個事件對應(yīng)的效果是神馬。 需要說的就是:

progress: 當(dāng)瀏覽器在下載資源時，每下載成功一次，就會觸發(fā)一次
noupdate:當(dāng)瀏覽器檢查更新之后發(fā)現(xiàn)沒有資源更新的時候觸發(fā)這個事件
error: 更新出錯時會觸發(fā)，比如文件無法正常下載，manifest文件被刪除.

其實，使用manifest的時候，無外乎就是3種常用狀態(tài)

第一次訪問頁面時

再次訪問頁面時，沒有更新

再次訪問頁面時，有更新

每次，觸發(fā)的事件順序為:

上面看不懂沒關(guān)系，我們可以看看更直觀的Console的內(nèi)容。

第一次訪問頁面時

checking->downloading->progress(多次)->cache

2. 再次訪問頁面時，沒有更新

checking->noupdate

3. 再次訪問頁面時，有更新

checking->downloading->progress(多次)->updateready

其實，manifest就是為了離線應(yīng)用而生的，但是由于設(shè)計之初，沒有很好的規(guī)范，導(dǎo)致現(xiàn)在manifest的bug，真的超級多。
看到whatwg上面說的一句話，真的更加蛋疼.

This feature is in the process of being removed from the Web platform. (This is a long process that takes many years.) Using any of the offline Web application features at this time is highly discouraged. Use service workers instead.

意思就是讓你不要用manifest，應(yīng)該他遲早要被fire的，但是，這一天還有很多年，很多年。 另外一個替代方案就是使用SS，但是兼容性，真的極其差。幾乎現(xiàn)在的瀏覽器都沒有實現(xiàn)(除了布道師FF實現(xiàn)了部分). 現(xiàn)在我們真的很尷尬，不過，目前的情況而言，in my opinion, 是十分推薦使用的(也沒有其他的辦法了). 那該怎么做，才能將manifest的Bug減到最低呢？
推薦的做法是將邏輯頁面和用戶數(shù)據(jù)給分離開。 邏輯頁面使用app cache，而用戶數(shù)據(jù)可以保存在web Storage || indexDB 等瀏覽器數(shù)據(jù)庫里，動態(tài)更新data時，使用web Socket,ajax,SSE等技術(shù).