客觀看待ViewState對Asp.net程式作用和影響

前段時間由於程式出現了比較大的效能問題，視圖（View）之間的跳轉速度非常慢。通過Fiddler調試和分析，尋找到是由於在視圖(View)轉換（PostBack）過程中，用戶端給伺服器端的發送位元組數非常大，一般在30K以上，就相當於用戶端每次都要給伺服器上傳大十K的資料量，這如果是比較好的網路環境下完全是可以忽略的，但是目前的網路環境確實還達不到這樣的要求。詳細請看《無重新整理視圖跳轉的局限性》。針對這一情況，我的解決方案就是禁用頁面的ViewState，只有這樣才是最根本的解決辦法。原本還想寫一篇blog來好好批一下ViewState，當初想好的標題是“asp.net程式的效能殺手----ViewState”。現在看來，還好沒寫，要不還不被人批是“沒有真正會用 asp.net 的人”？（儘管確實還沒有真正全面認識asp.net）。

在jillzhang的blog《給頁面減減肥！》中給頁面減肥的辦法是對頁面進行壓縮。這確實是一種辦法，特別是當在硬體環境允許的條件下，可以帶來非常大的好處，一般體積都可以減小好幾倍。減小頁面體積還有一種辦法，那就是禁用ViewState，兩種方法並不是互斥的，而且我認為只有禁用ViewState後，頁面壓縮的效果才更明顯的。因為ViewState的值本身就是一些相對緊湊的字元，而HTML代碼則相對鬆散，（我也不是特別肯定這對壓縮有必然的聯絡。）。最近一直在從事頁面速度的最佳化方面的工作，所以很多平常不注意的細節，它所造成的效能影響在這時候就體現出來了。一般的頁面（伺服器控制項比較多）如果禁用ViewState後，它的體積至少會減小一半。而且這一半的資料在很多情況都是沒用的（特別是在不需要PostBack的情況下，簡直就是累贅），如果這時候再加HTML壓縮的話，那壓縮比就不止3-5倍了。有一個頁面正常的大小（禁用ViewState後）是101,730 byte ，壓縮後變成了11,182 byte。說實話我也很驚訝這樣的壓縮比。通過這裡可以看這組驚人資料。

那這一切是不是都是Asp.net的錯呢？ViewState是不是就是“萬惡之源”呢？是，也不是。為什麼呢？首先我們要正確認識ViewState存在的意義，更多的情況下MS是為我們這些新手快速入門而考慮的。正因為有了ViewState，讓我們開發B/S應用程式能夠按照我們的正常的思維邏輯來進行。而屏蔽了在PostBack時，還要去初始化一堆的頁面控制項，給這個控制項還原我們提交的請求值等等，想想這對於我們來說是多少複雜而麻煩的一項工作啊！而不是像我們現在這樣，直接在PostBack事件取我們想要的控制項的值這麼簡單。而預設情況下ViewState=true，也是在為初學者著想的，不至於讓一個初學asp.net的同學在寫postback事件時出現一些奇怪的錯誤而灰心喪氣，提高門坎。一段個人的理解可能還不能讓一些朋友看得很明白，關於ViewState的討論已經很多了，但是最重要一點就是理解頁面的執行生命週期。如果把下面這張圖啃下去後你也許就會有深刻理解了。

 （圖大占篇幅。）

談點有意義的吧？是禁還是用？決定因素有以下幾點（個人理解）：

1.你的目標應用環境。

這是最根本的，如果你的asp.net應用程式只在區域網路（Intertrant）內應用的話，那非常棒，我們完全可以忽略ViewState存在的影響。

2.頁面的性質。

如果你的頁面是一種資訊瀏覽的性質，而完全沒有PostBack事件的話。這裡的ViewState就完全是可以被消滅的。反之，如果頁面中有PostBack事件，儘管只有一個，那你如果禁用了ViewState，都有可能產生不可預期的錯誤。

3.你對ViewState和頁面事件的理解程度。

如果你很理解頁面的生命週期和執行過程，那你完全可以根據需要來設定哪些控制項需要開啟ViewState，哪些控制項可以禁用ViewState，做到按需使用，合理使用ViewState。達到效能的最佳化。

4.開發人員的勤勞程度和外在因素。

如果你很勤勞，而且你也瞭解了ViewState的原理，你可以按需使用。但是如果你很懶，而且很多外在因素（團隊其它成員的理解程度）你沒無法控制的話，那就直接禁用頁面的ViewState好了。當然前提是你必須知道如果去正確處理禁用ViewState後遺留下的問題，這些問題一般都是一些讓人難以捉摸的東西。如果你都是一一的解決了這些問題的話，那對ViewState的感情就更深了。呵呵。

可以這麼說ViewState是頁面控制項狀態的一個副本，比如一個DropDownList控制項，它在asp.net頁面上要是以select HTML tag 來展現的，而這時在ViewState中還儲存著它所有Item的副本。當我們在postback的時候為什麼能夠取到值呢？就是因為ViewState，它會在ProcessPostData(before Load)之前將這個副本還原成了DropDownList的Item了。然後在ProcessPostData方法中將表單提交的選擇項設定為DropDownList的SelectedValue。以前這一過程我們無需參與。而當我們禁用ViewState後，我們就要手動去維護DropDownList回傳情況下的Item初始化，利用Request.Params(或Request.Form)取得SelectedValue值等等，而這些工作有可能就要在Page_Load事件之前做了。

對於ViewState，有一句話說的很好，“魚與熊掌不可兼得”，歡迎討論。

補充:可能有以下一些因素讓你會選擇堅定不移的使用ViewState

1.你認為ViewState所以來的負面影響在我所能接受的範圍之內。

2.通過對ViewState的一些處理，如改變ViewState的儲存機制，壓縮ViewState等，我們能夠得到比較好的結果。

3.由於一些客戶原因，如第三控制項需要，設計需要必須使用ViewState的。

4.禁用ViewState帶來更多的工作量，但是改善效果不理想。

等等，但是有一個原則，既要合理使用，也要理性判斷，做到效果最佳化。