阿不

潜水

  博客园 :: 首页 :: 博问 :: 闪存 :: 新随笔 :: 联系 :: 订阅 订阅 :: 管理 ::

前段时间由于程序出现了比较大的性能问题,视图(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的讨论已经很多了,但是最重要一点就是理解页面的执行生命周期。如果把下面这张图啃下去后你也许就会有深刻理解了。

 ASP.NET+Page+Life+Cycle(图大占篇幅。)

谈点有意义的吧?是禁还是用?决定因素有以下几点(个人理解):

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带来更多的工作量,但是改善效果不理想。

等等,但是有一个原则,既要合理使用,也要理性判断,做到效果最优化。

posted on 2006-09-29 15:35  阿不  阅读(9084)  评论(30编辑  收藏  举报