Objective view of the role and impact of viewstate on the Asp.net Program

Some time agoProgramThe jump speed between views is very slow due to a large performance problem. Through fiddler debugging and analysis, it is found that the client sends a large number of bytes to the server during view conversion (PostBack), generally over 30 kb, it is equivalent to uploading 10 K of data to the server every time by the client. This can be ignored if it is a good network environment, however, the current network environment does not meet this requirement. For details, see limitations of refreshing a new view. In this case, my solution is to disable the viewstate of the page. This is the most fundamental solution. I also wanted to write a blog to approve viewstate. The title I thought was "viewstate, the performance killer of the Asp.net program ". Now it seems that I still haven't written it, or will it be "no real person who will use Asp.net "? (Although we have not fully understood Asp.net yet ).

In jillzhang's blog "reducing weight on the page!" To reduce the page weight, compress the page. This is indeed a solution, especially when the hardware environment permits it, which can bring great benefits. Generally, the volume can be reduced several times. Another way to reduce the page size is to disable viewstate. The two methods are not mutually exclusive, and I think the page compression effect is more obvious only after viewstate is disabled. Because the value of viewstate itself is relatively compact charactersCodeIt is relatively loose (I am not particularly certain that this has an inevitable connection with compression .). Recently, I have been engaged in page Speed Optimization, so many details that I usually don't pay attention to. The performance impact caused by this is reflected at this time. If viewstate is disabled, the page size will be reduced by at least half. In addition, this half of the data is useless in many cases (especially when PostBack is not required). If HTML compression is added at this time, the compression ratio is more than 3-5 times. There is a normal page size (after viewstate is disabled) Yes101,730Byte. After compression, it becomes11,182Byte. To be honest, I was surprised at the compression ratio. Here we can view this set of amazing data.

Is it all Asp.net's fault? Is viewstate the source of all evil? Yes, no. Why? First, we need to correctly understand the significance of viewstate. In more cases, Ms is considered for the quick start of our new users. With viewstate, we can develop B/S applications according to our normal thinking logic. While shielding the PostBack, we also need to initialize a bunch of page controls and restore the submitted request values to this control, think about how complicated and troublesome this is for us! Instead of taking the value of the control we want directly in the PostBack event as we do now. By default, viewstate = true is also intended for beginners, so that a beginner's Asp.net will not be discouraged by some strange errors when writing the PostBack event, improving the threshold. A piece of personal understanding may not make some friends quite clear. There are a lot of discussions about viewstate, but the most important thing is to understand the page execution lifecycle. You may have a deep understanding of the figure below.

(The figure occupies space .)

Is it meaningful? Is it disabled or used? The deciding factors are as follows (personal understanding ):

1. Your target application environment.

This is the most fundamental thing. If your Asp.net application is only applied in the LAN (intertrant), it would be great. We can ignore the influence of viewstate.

2. Page nature.

If your page is a type of information browsing, and there is no PostBack event at all. The viewstate can be completely wiped out. Conversely, if there is only one PostBack event on the page, if viewstate is disabled, unexpected errors may occur.

3. Your understanding of viewstate and page events.

If you understand the lifecycle and execution process of a page, you can set the controls to enable viewstate and disable viewstate as needed, so that you can use them as needed, use viewstate properly. Optimized Performance.

4. developers' diligence and external factors.

If you are hardworking and understand the principle of viewstate, you can use it as needed. However, if you are too lazy and have a lot of external factors (the understanding of other team members) that you cannot control, you can simply disable the viewstate of the page. Of course, the premise is that you must know that if you correctly handle the issues left behind by disabling viewstate, these issues are generally unpredictable. If you solve these problems one by one, the feelings for viewstate will become deeper. Haha.

In this case, viewstate is a copy of the page control status. For example, a dropdownlist control is displayed on the Asp.net page as a select HTML Tag, in this case, copies of all its items are saved in viewstate. Why can we get the value in PostBack? Because of viewstate, it will restore the copy to the dropdownlist item before processpostdata (before load. In the processpostdata method, set the selection item submitted by the form to selectedvalue of the dropdownlist. In the past, we did not need to participate in this process. When viewstate is disabled, we need to manually maintain the item initialization in the case of dropdownlist sending back, and use request. params (or request. form) to obtain the selectedvalue value, and so on, and these jobs may have to be done before the page_load event.

For viewstate, there is a good saying, "the fish and the bear's paw cannot have both." Welcome to discuss.

Additionally, you may choose to use viewstate unswervingly due to the following factors:

1. You think the negative effects of viewstate are within the scope I can accept.

2. Through some processing of viewstate, such as changing the storage mechanism of viewstate and compressing viewstate, we can get better results.

3. For some customer reasons, such as the Third control, viewstate must be used for the design.

4. Disabling viewstate results in more workload, but the improvement is not satisfactory.

But there is a principle that both rational use and rational judgment are required to achieve optimal results.