.NET/ASP.NET 4.5 Bundle元件（捆綁、縮小靜態檔案）

王清培發表於2013-09-09

閱讀目錄：

1.開篇介紹
2.System.Web.Optimization 元件
3.System.Web.Optimization 元件基本原理
4.擴充套件自定義型別靜態檔案

1】開篇介紹

這篇文章將簡單的分析一下有關靜態檔案捆綁的ASP.NET元件System.Web.Optimization的執行原理及基本的快取問題；

在我們的專案裡面充斥著很多靜態檔案，為了追求模組化、外掛化很多靜態檔案都被設計成模組的方式或者被分解，在需要的時候在通過組合的方式在UI層上使用；這就帶來一個問題，檔案多了會影響瀏覽器載入頁面的速度，而且由於瀏覽器的併發限制，對於並行的請求不是無限制的，所以捆綁靜態檔案的功能就產生；其實在以前，IIS還沒有整合管道模型的時候我們只能通過動態資源的方式進行輸出，也就是我們經常在*aspx頁面裡看見很多*.axd結尾的請求，當然多數情況下是配合ASP.NETAJAX用來輸出動態JS、HTMDOM、CSS用的；

最新的IIS已經很好的整合了ASP.NET管道模型，也就是說我們完全可以通過ASP.NET本身的擴充套件來控制所有經過IIS的請求，包括靜態檔案，所以讓捆綁靜態檔案成為了可能；

下面我們將分析一下System.Web.Optimization元件的基本執行原理，它是如何動態載入的，如何控制快取的；

2】System.Web.Optimization 元件

每當我們新建一個ASP.NETMVC4站點的時候都會在～/App_Start目錄下有一個BundleConfig.cs的啟動檔案，當然建立其他的ASP.NET4.0及4.0以上的專案也會有；

我第一次看見這個檔案實在讓我困惑，所以我打算簡單的分析一下，知道其基本原理；

程式碼是一個靜態方法，然後傳入一個BundleCollection集合物件，其實就是Bundle物件的集合，然後通過向集合內部註冊多個Bundle；每個Bundle對應著多個靜態檔案，可以想象成就是鍵值對集合；通過後面的Include方法包含N多個靜態檔案，這裡的靜態檔案路徑可以是符合特定規則的字串，由它內部去計算；

這是註冊階段，然後就是使用階段，使用階段很簡單隻要我們通過我們註冊的Key字串就能直接引用這些靜態檔案列表；

我們只要關注Styles.Render、Scripts.Render兩個方法，這兩個方法是想頁面注入之前在後臺配置的靜態檔案列表；這樣我們在客戶端看見的就是被捆綁過後的檔案集合了；

檔案的連線地址已經是被捆綁過後的地址了，這個地址就是我們在之前註冊的時候用的key，後面它需要這個key去獲取value 靜態檔案列表；要想你的捆綁起效果需要在註冊的時候加上一段：BundleTable.EnableOptimizations = true;程式碼，意思是說開啟捆綁，如果不開啟捆綁則預設在除錯環境裡將不起效果，因為System.Web.Optimization使用了預設捆綁策略，如果是在Debug模式下，將不啟用捆綁，如果你人為的設定了將覆蓋預設設定；

使用就是這些，下面我們需要搞懂它是如何執行的，要了解一下它的基本原理；

3】System.Web.Optimization 元件基本原理

既然IIS整合了管道模型，那麼我們肯定是能找到對應的HttpModule的，為了節省時間我就不去下載原始碼了，我們直接用反編譯工具看一下；

這就是Bundle的HttpModule，它只用來處理
Bundle的連線地址，雖然它在HTTP的管道中；找到它就好順藤摸瓜了，但是奇怪的是我在Web.config裡沒有發現它的配置資訊，奇怪了，難道它還跑去系統檔案改，當然是不可能的；所以我一時還想不起能有什麼辦法動態註冊，提起動態註冊突然有了思路，好像有一個Assembly級別的特性用來註冊Application_Start啟動時候的前置程式碼，會在Application啟動之前執行，來看一下；

果然藏著這裡呢，它註冊了一個PreApplicationStartCode靜態類，使用Start方法啟動；

這段程式碼很簡單，先判斷有沒有執行過註冊，如果沒有就執行動態註冊，這個動態註冊元件是.NETFramework自帶的，在Microsoft.Web.Infrastructure裡面只不過屬於平臺相關的，跟ASP.NET沒有直接關係，我們可以用Microsoft.Web.Infrastructure來開發自己的WEB元件；這裡有一個疑問，為什麼靜態方法也要加判斷呢，不是隻會執行一次嗎，因為靜態方法的執行是不受控制的，所以如果不加判斷很有可能會註冊多次，出於嚴謹考慮還是加上；

現在基本上我們已經找到源頭了，服務端這裡我們先放一下，對於客戶端的疑問很多，它既然幫我們捆綁了，那麼快取是如何處理的，也就是說它的輸出快取有沒有設定，如果設定了不是有問題；

【客戶端快取相關】

為了很好的瞭解請求之間的資訊，我們用Fiddler監聽一下；

我們看見它的Cache部分是用了If-Modified-Since來表示本地的檔案的最後一次修改，這樣是為了能夠讓伺服器去驗證檔案是否改動，如果沒有改動伺服器的響應狀態碼為304，說明Bundle在輸出的時候並沒有設定對這個檔案進行客戶端強制快取，我們通過Pragma: no-cache頭也能看出來了；

那麼我們得出結論，所有Bundle出來的檔案都不可能直接快取在瀏覽器中，每次都會帶上Cache段If-Modified-Since去驗證伺服器的檔案版本；剛好這裡我們可以跟動態輸出的靜態檔案地址的後面的引數對上了；

比如：

/Content/css?v=ZPnWVRT3c0yyrVDPmI-xkJuhBdJfQsL3A0K5C9WTOk01

這個連結後面的v引數是表示當前Bundle後虛擬檔案的版本，如果我們在伺服器上把檔案修改了之後那麼這個檔案的If-Modified-Since驗證就失敗了，會生成新的版本號作為連線的引數；我們來看一下，心裡踏實；

我加了一個width:auto的style，那麼這個時候我重新整理客戶端應該是不會再有304出現了；

顯然/Content/css?v=doYFOk3BdOYWDIRbQ7juV6eQdlJAu6RtC0G13El7X041 檔案的版本變了，那麼Response也不應該是304了；

如果靜態檔案的版本號發生改變，根本就不會帶上 If-Modified-Since，這個是用在每次進行進行Post是用來驗證的；其實意思就是說如果沒有IIS整合模式那麼捆綁檔案的方式只能改變靜態檔案的檔名；

4】擴充套件自定義型別靜態檔案

Bundle物件是所有需要捆綁檔案的基類，如果我們需要擴充套件一些靜態檔案，如一些特定領域的靜態檔案，我們可以直接繼承這個類；

【XML檔案的快取】

擴充套件XML檔案很簡單，我們只需要繼承一下Bundle物件，所有關於動態生成URL都有專門的物件處理，我們來看下程式碼；

 1 public class XmlBundle : Bundle
 2    {
 3        public XmlBundle(string path) : base(path) { }
 4    }
 5    public static class XmlBundleRender
 6    {
 7        public static IHtmlString Render(string path)
 8        {
 9            BundleResolver bundle = new BundleResolver(BundleTable.Bundles);
10            return new HtmlString(
11                string.Format(@"<link href=""{0}""  rel=""stylesheet""/>", bundle.GetBundleUrl(path)));
12        }
13    }

View Code

首先我們需要一個繼承自Bundle物件的XmlBundle，用來表示我們所有將要傳輸的XML檔案捆綁容器，然後我們需要一個靜態方法用來註冊捆綁後的URL；

這個URL的生成有專門的BundleResolver物件來完成，我們只需要傳入所有的BundleCollection物件，我這裡為了能在瀏覽器中測試所以寫了一段stylesheet型別的link；這樣我們就能直接在我們需要的地方直接使用了，我在index檢視中引用：@MvcApplication4.Seed.XmlBundleRender.Render("~/custom/xml");是不是很簡單，這樣我們就能對所有想控制捆綁的檔案進行捆綁，只需要繼承加簡單的靜態方法輔助；

我們來看一下我們的XML檔案是否具有所有快取特性；