前段时间由于程序出现了比较大的性能问题，视图（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带来更多的工作量，但是改善效果不理想。
等等，但是有一个原则，既要合理使用，也要理性判断，做到效果最优化。
