博客园_脚印

【转】 Image Tips for Windows Phone 7

2011-12-05T09:09:00Z

引用地址： http://blog.csdn.net/huangliangjie/article/details/6710188

在开发WP7程序过程中，会遇到在UI上使用用大量的Image这种情况。你可能会以为使用Image是一个很简单的事情，不需要用一篇博客的篇幅的介绍：仅仅设置一个Uri给Image的Source属性就完成了？但是，还有其他的事情需要考虑呢。这里有许多的小细节如果你知道到的话，会对的你的程序有帮助，特别是当希望开发出的软件能够有较好的体验和较少的内存使用(移动开发这点很重要)。这些小的提示，不仅适用WP7手机开发，同样也适用SilverLight桌面程序。但是在手机开发中，把握住那些能够把一个好的程序变成一个优秀的程序性能细节是非常重要的技能。为了指出这一点，这里举出一个实现了这些小细节的示例。

JPG VS PNG

如果要在JPG和PNG之间做个选择，那为你的所有不透明的图片都使用JPG吧。Window Phone 7操作系统上的JPG解码器相比之下要比PNG解码器快很多。当然，如果你的图片需要是透明的，那PNG是你唯一的选择了。

Resource vs Content

在Visual Studio中把“Build Type”设置成“Resource”或者“Content”，图片都会编译成Window Phone XAP文件的一部分。由于他们都被打包到XAP中，起初可能你看不出他俩有什么区别，貌似都是一路货色。但当你撬开XAP的外壳(重命名为.zip文件并解压缩)：那是你可以看到所有的“Content”类型文件，却找不着“Resource”类型文件。为什么？因为“Resource”类型的文件嵌到了程序集里了(也就是dll文件里)。那么，我们为何又如此关心“Resource”文件到底是嵌到哪儿去了。这是因为你的程序的DLL包越大，你的程序启动就会越慢。但另一方面，跟图片从磁盘加载相比，嵌入DLL的图片加载会更快速。

Summary：设置成”Content“会让程序启动更快，设置成”Resource“会让程序更快的响应。

还有值得一提的就是他们有着不同的URI格式，可以参考下面的例子：

Content: <Image Source="/ImagesAsContent/smiley1.png"/>

Resource: <Image Source="..\ImagesAsResource\smiley3.png"/>

Async vs.Sync Loading of images

如果你专研过Imaging API 你会发现BitmapImage这个类，在创建一个Image的时候BitmapImage会在幕后做很多的工作。它能以两种模式加载内容：

BitmapImage.UriSource = uriSource; // loads the image via URI, asynchronously
BitmapImage.SetSource(stream); // loads the image from stream, synchronously

注意到异步加载图片并不意味着完全的off-thread。这是因为有关图片的解码是发生在UI线程上的。关于在保持UI线程响应的情况下，异步加载图片的详细信息参考David Anson的博客.

下面是一些关于同步vs异步加载的知识：

1.如果同步加载一张不正确的图片文件，将会得到一个异常。

2.如果异步加载一张不正确的图片文件，ImageFailed事件会触发。

3.如果异步加载一张正确的图片文件，ImageOpened事件会触发。

4.如果同步加载一张正确的图片文件，ImageOpened事件不会触发。

它们的不同可以通过我给出的示例代码演示（在Loading页面里）

Image Caching

这是图片比较重要的一个方面，MSDN对于它的记录也很少。在WP7 Platform中即使清空了Source属性并且把Image从visual tree中去除，Image的内存还是不会释放，其实这时你看到的是图片的缓存。这是一个预留的性能优化，是为了避免一遍又一遍的加载和解码相同的图片。WP7中在内存中开辟了一个缓冲区，我们可以利用它方便快捷的再利用图片资源。这里与浏览器的缓存类似。

虽然图片缓存对于提高性能有很大的帮助，但是有时候也会增加不必要的内存消耗。特别是还回收再利用那些不会再显示的图片。在程序的运行过程中，图片缓存会一直占用内存空间。不过也可以通过下列代码删除缓存信息：

BitmapImage bitmapImage = image.Source as BitmapImage;

bitmapImage.UriSource = null;

image.Source = null;

合理的利用上述代码可以减少内存使用。而减少内存使用在手机开发中对于性能有较大的帮助。在示例程序里，在“Caching”页面中监视了显示和清除缓存的内存使用情况，在示例中可以看到有3MB的内存差异。

BitmapCreateOptions

这是一个快速而且很有意思的部分。创建一个BitmapImage的时候，你有可能会有这样的疑问：为什么当你认为已经完成图片创建时仍不会返回图片的大小呢？这是因为CreateOptions 属性默认被设置成了“DelayCreation”，也就是说当BitmapImage被设置成一个Image的Source属性上或者是可视化树的ImageBrush上，这个对象只有在真正需要它的时候才会被创建。这里就允许在程序开始运行的时候Creating很多的BitmapImage，却不消耗任何的资源（CPU或者是内存）直到程序需要特定的图片才会真正创建它们。如果你想强制的立即执行创建操作，把CreateOptions设置成“None”即可。CreateOptions 还有一个值是“IgnoreImageCache”，这个值在很多的场景中都不是很有用，而且他还需要和设计工具结合（如Blend）。

在示例程序里，在“CreateOptions”页面中，通过Create/Show/Clear控制CreateOptions的值为DelayCreation，None并监视图片大小的变化。

Custom Decoding

在有关图像的API中都是以图片自身的分辨率解码（除了Downsampling缩减像素采样，等会儿会介绍到它）。不管怎样，这已经能满足在手机上的图片显示了。如果下载一批320X320的图片，但只以32X32那么小显示，那么还以原分辨率解码就会浪费很对的内存资源。

在 Windows Phone平台上提供给程序员们PictureDecoder的应用程序接口，能够自定义分辨率去解码图片：

image.Source = PictureDecoder.DecodeJpeg(jpgStream, 192, 256);

Note：在当前发布的API中有一个bug，图片的高度和宽度属性值被交换了。因此，得把宽度的值设定到高度上，高度同理。这个问题以后MS肯定会修复，我也是无意间发现的这个问题。

为了查看内存增长情况，在示例程序的“Custom Decoding”页面中。在两种的分辨率中监视内存使用情况。

Auto Downsampling

这是最后一个在处理WP7平台图片我们需要知道的事。background是一个特殊的元素，被限定到2048X2048。超过此大小的会被剪裁，这就意味着使用一个长宽超过2048像素的的图片，该图片不会完全显示。为了避免这种情况的发生，WP7平台会自动的降低像素是图片去适应2048X2048。这一点不同于桌面Silverlight应用，应为silverlight不存在上述限制。

在示例程序中我使用了一张3000X2102分辨率的图片，最终图片被像素缩减为1500X1051。

事实上，关于图片还有很多值得细细研究的，这里只是起一个抛砖引玉的作用，希望能和大家一起探讨这个问题。谢谢你能阅读这篇文章，希望能对你有所帮助。

能力有限，如果有错误的地方请指正。

本文链接

windows phone 应用程序退出代码

2011-11-09T14:44:00Z

引用相应的DLL即可

new Microsoft.Xna.Framework.Game().Exit();

当时看到这个本以为只有xna编程有效，其实对于SL也同样有效

本文链接

Windows Phone 页面切换

2011-11-09T14:40:00Z

最近做一个webbrowser的项目，经常需要在含有webbrowser控件的页面中弹出一些其他页面，不如弹出一个含有google 地图的层.

因为这个webborowser里面的内容我们无法保存（dom结构能保存，bom结构就没办法了），所以又不能导航到含有google地图的页面中，

以前我总是把需要弹出的这个层做成一个Usercontrol然后添加到root控件中，把原本的内容用一个panle装起来，并且将Visibility设置成 System.Windows.Visibility.Collapsed。

今天突发奇想，每个应用程序都有唯一的一个PhoneApplicationFrame

页面只不过是他的content，我们是不是只需要更换PhoneApplicationFrame 的content属性就好了呢，于是做了以下测试：

Global.Page =this; //用一个全局的变量保存需要返回的页面

((PhoneApplicationFrame)Application.Current.RootVisual).Content = new Page1();//新页面

在Page1中调用下面的这行代码就能回来

((PhoneApplicationFrame)Application.Current.RootVisual).Content = Global.Page;

不知道大家是否还有更好的方法？请赐教。

本文链接

Windows Phone的网络连接策略（转）

2011-10-31T01:41:00Z

原文链接：http://www.cnblogs.com/procoder/archive/2011/10/28/WIndows-Phone-Idle-Mode.html

Windows Phone的网络连接策略

前言

在微薄中“有人”（我记得是谁，^_^）问起Windows Phone在锁屏下是否继续链接WiFi，引起了很多WP微博控在讨论，其实我本来不关心这个问题的，因为这个是不可控的，但是讨论的人太多了，因此我想聊聊我对Windows Phone的网络连接策略的想法。

问题定义

这个问题可以简单的重新定义为Windows Phone在空闲（idle）情况下，是否进行网络链接。到底使用哪种链接方式，是由Windows Phone的策略所决定的，这种策略基本上是考虑电池使用量和链接成本（$$$$$$$）等因素。

多任务之梦

如果有人觉得Windows Phone是单任务，在锁屏的时候会把所有app杀死了，那么他/她可能给水军给忽悠了，Windows Phone从第一天开始就是一个多任务操作系统，所以在锁屏情况下继续保持网络链接，继续完成后台任务是可能的。但微软一般不这样做，而且限制app开发者这样做，这些都是为了提供更好的用户体验。

到底链接or断开？

我的答案是yes and no，呵呵。在Windows Phone锁屏的情况下，到底继续保持链接还是断开链接，不能简单的回答，因为这个操作是根据策略来决定的。这些策略的目的都是为了提供更好的用户体验，这种策略简单可以参考下面的公式：

任务类型 + 电源状态 = 是否断开链接

根据之前重新定义，公式可以替换为：

任务类型 + 电源状态 + 可用网络链接媒体（WiFi/3G） = 是否进行网络链接

也就是说在不同的情况下，Windows Phone会相应的保持或者断开链接。这也是现代智能手机系统（WP， Android，iOS）最最基本的功能了。现代的智能手机系统一般都由系统来进行电源管理和网络连接管理。请注意我把“系统”两个字重点加粗了，因为非现代智能手机系统可能是把主动权交给了应用（app）来管理的（当然最终操作系统保留了最高决定权），例如以前的Windows Mobile是由应用来决定打开和关闭网络连接，打开3G还是WiFi，试问一个app开发者怎么要肩负着OS开发者的责任，需要考虑的情况也太多了。再例如Symbian的app在启动是会提示“是否打开网络连接，到底打开3G还是WiFi”，把链接责任推给了用户。这些老系统都极大破坏了用户体验。

-------------------------貌似合理的跑题-------------------------------------------------------------------------------------

下面举一个Agile的例子，讨论一下用户到底要什么：

最为一个非技术用户，如果我想看微薄，那么打开微薄app就可以看。

这里的非技术用户根本就不关心手机的链接状态，关心的是是否能查看和发微薄。

这里用户故事有以下的附加条款（acceptance criteria）：

1.如果能接触（这里没有使用链接，其实也是这个意思，connect）到微薄后台服务，直接打开app，显示默认页，例如“@我的”
2.如果不能接触到微薄后台服务，而且没有缓存，提示用户没网络链接，请稍候再试。
3.如果不能接触到微薄后台服务，而且有缓存，提示用户只能看缓存。

这个用户故事有个特点是，不由用户来决定，而是预定动作，强迫用户选择或接受，但是假装很尊重用户的样子。回到Jobs那句话，给用户最好的选择就是不给他选择。

-------------------------跑回到主题上------------------------------------------------------------------------------------

由此可以知道关心这种问题的都不是“非技术用户”，对，我就是说你，0_^。其实Windows Phone已经把管理网络链接的主动权收起来，统一由系统进行管理，作为app开发者不一定要把这个问题查根问底也能写出很优秀的程序，但是如果真的想知道，我下面尽力探讨一下。

什么时候Windows Phone在空闲状态会进行网络链接

上面讲到网络链接的策略，因此我们开发的app符合这些策略，就会在空闲状态下也进行网络链接。我尽力列出所有可能出现的情况：

ApplicationIdleDetectionMode设置为disabled

Windows Phone的app可以通过修改PhoneApplicationService的ApplicationIdleDetectionMode强制app在锁屏的时候不会被墓碑化（注意Mango发布后这个功能有时候是鸡肋了），这种程序一般是导航程序，音乐播放程序（mango后有替代方案，会在后面讲述），也就是手机锁屏，app还是继续运行，程序可以继续做一些网络request，这样WiFi链接就会保持（如果有WiFi链接的话）。但是根据微软的文档，在程序锁屏情况下应该停止/关闭很多操作，例如Timer，动画（animations ），重力加速计（accelerometer ），地理定位服务（Location Service ），FM收音机，同时断开网络链接等等。但是注意我这里使用了应该，没有说必须，因此app还是可以继续做网络请求的。

Background Audio

使用AudioPlayerAgent（后台音频播放）的app在锁屏的时候也可以继续播放，如果音频的url指定为网络的url，那么为了能正常播放，Windows Phone继续保持WiFi链接如果WiFi可用的话。

Background File Transfers

如果app使用了BackgroundTransferService（后台传输服务），那么程序会在特定情况下保持链接，继续下载，如果文件小于20M，Windows Phone会继续使用3G下载，如果文件100M以下，那么Windows Phone会继续使用WiFi下载文件，如果文件大于100M，必须外接电源和联通WiFi的情况下Windows Phone才会启动下载。

Background Agents

如果app使用了ScheduledTask（定时任务），那么程序在每隔一段时间会启动执行一下，可能有两种不同的任务如下

PeriodicTask （周期性任务）会每隔30分钟执行一次，每次只能执行25秒。
ResourceIntensiveTask （耗资源的任务）每隔10分钟执行一次，但是需要连接上外接电源。

其中两种任务在执行过程都可以链接网络，请求网络资源的。

Schedule Tile

如果app使用了ShellTileSchedule（信息块更新任务），那么程序每隔一段时间可以更新Live Tile，如果Tile的图片在网络上，会启动网络链接。

Tile Notification

官方没有说明推送任务的实现细节，从系统角度看一般实现方法可能如下：

1.通过sms触发手机去请求。
2.手机定时pull（拉）信息。

不管哪种方法，手机最终都是需要通过网络链接来取得推送服务的信息，因此也可能使用到网络链接。

总结

不管哪种方法，微软试图做的是提供良好的用户体验（包括电源消耗，反映速度，通信资费等等），因此作为app开发者，我们要做的是在现有的限制条件下，提供更好的用户体验，没必要为了数据长链接而破坏用户体验。

有任何问题，请留言，或者微博我 @林永坚jake 谢谢！

本文链接

XML Schema

2011-04-07T09:52:00Z

Restrictions for Datatypes
对数据类型的约束

Constraint 约束	Description 说明
enumeration	Defines a list of acceptable values 定义了一系列的有效值
fractionDigits	Specifies the maximum number of decimal places allowed. Must be equal to or greater than zero 指定了允许的小数位数的最多位数。必须大于等于0
length	Specifies the exact number of characters or list items allowed. Must be equal to or greater than zero 指定了允许的字符或列表项的个数。必须大于等于0
maxExclusive	Specifies the upper bounds for numeric values (the value must be less than this value) 指定了数值的上限（数值要比这个值小）
maxInclusive	Specifies the upper bounds for numeric values (the value must be less than or equal to this value) 指定了数值上限（数值必须小于等于这个值）
maxLength	Specifies the maximum number of characters or list items allowed. Must be equal to or greater than zero 指定了所允许的字符或列表项的最多个数。必须大于等于0
minExclusive	Specifies the lower bounds for numeric values (the value must be greater than this value) 指定了数值的下限（数值要比这个值小）
minInclusive	Specifies the lower bounds for numeric values (the value must be greater than or equal to this value) 指定了数值的下限（数值必须大于等于这个值）
minLength	Specifies the minimum number of characters or list items allowed. Must be equal to or greater than zero 指定了所允许的字符或列表的最少个数。必须等于大于0个
pattern	Defines the exact sequence of characters that are acceptable 定义了符合要求的字符的确切排列顺序
totalDigits	Specifies the exact number of digits allowed. Must be greater than zero 指定了所允许的字符的确切个数。必须大于0
whiteSpace	Specifies how white space (line feeds, tabs, spaces, and carriage returns) is handled 指定了空白该怎样被处理（换行符，制表符，空格符和回车符）

String Data Types
字符串数据类型

Note that all of the data types below derive from the String data type (except for string itself)!
要注意下面所有的数据类型都是从字符串数据类型里派生出来的（除了字符串本身）

Name
名称 Description
解释

ENTITIES

ENTITY

ID A string that represents the ID attribute in XML (only used with schema attributes)
象征XML的ID属性的字符串（只用在schema属性里）

IDREF A string that represents the IDREF attribute in XML (only used with schema attributes)
象征XML里的IDREF属性的字符串（只能和schema属性一起使用）

IDREFS

language A string that contains a valid language id
含有正确的语言ID的字符串

Name A string that contains a valid XML name
含有一个有效的XML名称的字符串

NCName

NMTOKEN A string that represents the NMTOKEN attribute in XML (only used with schema attributes)
象征XML里的NMTOKEN属性的字符串（只能和schema属性一起使用）

NMTOKENS

normalizedString A string that does not contain line feeds, carriage returns, or tabs
不含有换行符，回车符或制表符的字符串

QName

string A string
一个字符串

token A string that does not contain line feeds, carriage returns, tabs, leading or trailing spaces, or multiple spaces
不含有换行符，回车符，制表符，头尾空格，或重复空格的字符串

本文链接

Name 名称	Description 解释
ENTITIES
ENTITY
ID	A string that represents the ID attribute in XML (only used with schema attributes) 象征XML的ID属性的字符串（只用在schema属性里）
IDREF	A string that represents the IDREF attribute in XML (only used with schema attributes) 象征XML里的IDREF属性的字符串（只能和schema属性一起使用）
IDREFS
language	A string that contains a valid language id 含有正确的语言ID的字符串
Name	A string that contains a valid XML name 含有一个有效的XML名称的字符串
NCName
NMTOKEN	A string that represents the NMTOKEN attribute in XML (only used with schema attributes) 象征XML里的NMTOKEN属性的字符串（只能和schema属性一起使用）
NMTOKENS
normalizedString	A string that does not contain line feeds, carriage returns, or tabs 不含有换行符，回车符或制表符的字符串
QName
string	A string 一个字符串
token	A string that does not contain line feeds, carriage returns, tabs, leading or trailing spaces, or multiple spaces 不含有换行符，回车符，制表符，头尾空格，或重复空格的字符串

Init,Load,PreRender事件执行顺序

2011-02-23T01:07:00Z

转自：http://www.cnblogs.com/csjackie/archive/2008/11/08/1329599.html

Init,Load,PreRender事件执行顺序:

Init,Load,PreRender事件执行顺序:

Init,Load,PreRender事件执行顺序:
1）控件的Init事件
2）控件所在页面的Init事件
3）控件所在页面的Load事件
4）控件的Load事件
5）控件所在页面的PreRender事件
6）控件的PreRender事件

规律：
1）Init事件从最里面的控件（包括用户控件及普通控件）向最外面的控件（页面）引发，Load及PreRender等其他事件从最外面的控件向最里面的控件引发；
2）控件之间相同事件的执行顺序依控件在页面的位置按从左到右，从上到下的先后顺序执行。

注意：
1）切记用户控件也被视为页面中的一个控件；
2）把用户控件作为单独的一个特殊页面来看，它本身及其所包含的控件同样遵守相同的规律；
3）有时在客户端程序（如javascript）中会用到客户端body对像的onload事件，注意这个客户端事件是最后执行，即在服务器端所有事件执行完后才执行。

本文链接

javascript 继承

2011-01-28T14:44:00Z

javascript中继承不像c#中 class B：A

javascript 中继承通过设置

function super{

Id:"myid",

myMethod:funciton(){

alert("call myMethod!");

}

function sub{

}

//sub继承super

sub.prototype =new super();

var A= new sub();

此时 A就包含属性ID 和方法 myMethod（）

本文链接

深入浅出理解索引结构（转）

2010-09-10T02:49:00Z

深入浅出理解索引结构

原文：http://www.cnblogs.com/fanrsh/archive/2006/06/27/436618.html

主题: 转：（一）

作者: freedk (书生)

正文内容:

（一）深入浅出理解索引结构

实际上，您可以把索引理解为一种特殊的目录。微软的SQL SERVER提供了两种索引：聚集索引（clustered index，也称聚类索引、簇集索引）和非聚集索引（nonclustered index，也称非聚类索引、非簇集索引）。下面，我们举例来说明一下聚集索引和非聚集索引的区别：

其实，我们的汉语字典的正文本身就是一个聚集索引。比如，我们要查“安”字，就会很自然地翻开字典的前几页，因为“安”的拼音是“an”，而按照拼音排序汉字的字典是以英文字母“a”开头并以“z”结尾的，那么“安”字就自然地排在字典的前部。如果您翻完了所有以“a”开头的部分仍然找不到这个字，那么就说明您的字典中没有这个字；同样的，如果查“张”字，那您也会将您的字典翻到最后部分，因为“张”的拼音是“zhang”。也就是说，字典的正文部分本身就是一个目录，您不需要再去查其他目录来找到您需要找的内容。

我们把这种正文内容本身就是一种按照一定规则排列的目录称为“聚集索引”。

如果您认识某个字，您可以快速地从自动中查到这个字。但您也可能会遇到您不认识的字，不知道它的发音，这时候，您就不能按照刚才的方法找到您要查的字，而需要去根据“偏旁部首”查到您要找的字，然后根据这个字后的页码直接翻到某页来找到您要找的字。但您结合“部首目录”和“检字表”而查到的字的排序并不是真正的正文的排序方法，比如您查“张”字，我们可以看到在查部首之后的检字表中“张”的页码是672页，检字表中“张”的上面是“驰”字，但页码却是63页，“张”的下面是“弩”字，页面是390页。很显然，这些字并不是真正的分别位于“张”字的上下方，现在您看到的连续的“驰、张、弩”三字实际上就是他们在非聚集索引中的排序，是字典正文中的字在非聚集索引中的映射。我们可以通过这种方式来找到您所需要的字，但它需要两个过程，先找到目录中的结果，然后再翻到您所需要的页码。

我们把这种目录纯粹是目录，正文纯粹是正文的排序方式称为“非聚集索引”。

通过以上例子，我们可以理解到什么是“聚集索引”和“非聚集索引”。

进一步引申一下，我们可以很容易的理解：每个表只能有一个聚集索引，因为目录只能按照一种方法进行排序。

（二）何时使用聚集索引或非聚集索引

下面的表总结了何时使用聚集索引或非聚集索引（很重要）。

动作描述

使用聚集索引

使用非聚集索引

列经常被分组排序

应

返回某范围内的数据

应

不应

一个或极少不同值

不应

小数目的不同值

应

不应

大数目的不同值

不应

应

频繁更新的列

不应

应

外键列

应

主键列

应

频繁修改索引列

不应

应

事实上，我们可以通过前面聚集索引和非聚集索引的定义的例子来理解上表。如：返回某范围内的数据一项。比如您的某个表有一个时间列，恰好您把聚合索引建立在了该列，这时您查询2004年1月1日至2004年10月1日之间的全部数据时，这个速度就将是很快的，因为您的这本字典正文是按日期进行排序的，聚类索引只需要找到要检索的所有数据中的开头和结尾数据即可；而不像非聚集索引，必须先查到目录中查到每一项数据对应的页码，然后再根据页码查到具体内容。

（三）结合实际，谈索引使用的误区

理论的目的是应用。虽然我们刚才列出了何时应使用聚集索引或非聚集索引，但在实践中以上规则却很容易被忽视或不能根据实际情况进行综合分析。下面我们将根据在实践中遇到的实际问题来谈一下索引使用的误区，以便于大家掌握索引建立的方法。

1、主键就是聚集索引

这种想法笔者认为是极端错误的，是对聚集索引的一种浪费。虽然SQL SERVER默认是在主键上建立聚集索引的。

通常，我们会在每个表中都建立一个ID列，以区分每条数据，并且这个ID列是自动增大的，步长一般为1。我们的这个办公自动化的实例中的列Gid就是如此。此时，如果我们将这个列设为主键，SQL SERVER会将此列默认为聚集索引。这样做有好处，就是可以让您的数据在数据库中按照ID进行物理排序，但笔者认为这样做意义不大。

显而易见，聚集索引的优势是很明显的，而每个表中只能有一个聚集索引的规则，这使得聚集索引变得更加珍贵。

从我们前面谈到的聚集索引的定义我们可以看出，使用聚集索引的最大好处就是能够根据查询要求，迅速缩小查询范围，避免全表扫描。在实际应用中，因为ID号是自动生成的，我们并不知道每条记录的ID号，所以我们很难在实践中用ID号来进行查询。这就使让ID号这个主键作为聚集索引成为一种资源浪费。其次，让每个ID号都不同的字段作为聚集索引也不符合“大数目的不同值情况下不应建立聚合索引”规则；当然，这种情况只是针对用户经常修改记录内容，特别是索引项的时候会负作用，但对于查询速度并没有影响。

在办公自动化系统中，无论是系统首页显示的需要用户签收的文件、会议还是用户进行文件查询等任何情况下进行数据查询都离不开字段的是“日期”还有用户本身的“用户名”。

通常，办公自动化的首页会显示每个用户尚未签收的文件或会议。虽然我们的where语句可以仅仅限制当前用户尚未签收的情况，但如果您的系统已建立了很长时间，并且数据量很大，那么，每次每个用户打开首页的时候都进行一次全表扫描，这样做意义是不大的，绝大多数的用户1个月前的文件都已经浏览过了，这样做只能徒增数据库的开销而已。事实上，我们完全可以让用户打开系统首页时，数据库仅仅查询这个用户近3个月来未阅览的文件，通过“日期”这个字段来限制表扫描，提高查询速度。如果您的办公自动化系统已经建立的2年，那么您的首页显示速度理论上将是原来速度8倍，甚至更快。

在这里之所以提到“理论上”三字，是因为如果您的聚集索引还是盲目地建在ID这个主键上时，您的查询速度是没有这么高的，即使您在“日期”这个字段上建立的索引（非聚合索引）。下面我们就来看一下在1000万条数据量的情况下各种查询的速度表现（3个月内的数据为25万条）：

（1）仅在主键上建立聚集索引，并且不划分时间段：

Select gid,fariqi,neibuyonghu,title from tgongwen 用时：128470毫秒（即：128秒）

（2）在主键上建立聚集索引，在fariq上建立非聚集索引：

select gid,fariqi,neibuyonghu,title from Tgongwen where fariqi> dateadd(day,-90,getdate()) 用时：53763毫秒（54秒）

（3）将聚合索引建立在日期列（fariqi）上：

select gid,fariqi,neibuyonghu,title from Tgongwen where fariqi> dateadd(day,-90,getdate()) 用时：2423毫秒（2秒）

虽然每条语句提取出来的都是25万条数据，各种情况的差异却是巨大的，特别是将聚集索引建立在日期列时的差异。事实上，如果您的数据库真的有1000万容量的话，把主键建立在ID列上，就像以上的第1、2种情况，在网页上的表现就是超时，根本就无法显示。这也是我摒弃ID列作为聚集索引的一个最重要的因素。

得出以上速度的方法是：在各个select语句前加：declare @d datetime set @d=getdate()

并在select语句后加：

select [语句执行花费时间(毫秒)]=datediff(ms,@d,getdate())

2、只要建立索引就能显著提高查询速度

事实上，我们可以发现上面的例子中，第2、3条语句完全相同，且建立索引的字段也相同；不同的仅是前者在fariqi字段上建立的是非聚合索引，后者在此字段上建立的是聚合索引，但查询速度却有着天壤之别。所以，并非是在任何字段上简单地建立索引就能提高查询速度。

从建表的语句中，我们可以看到这个有着1000万数据的表中fariqi字段有5003个不同记录。在此字段上建立聚合索引是再合适不过了。在现实中，我们每天都会发几个文件，这几个文件的发文日期就相同，这完全符合建立聚集索引要求的：“既不能绝大多数都相同，又不能只有极少数相同”的规则。由此看来，我们建立“适当”的聚合索引对于我们提高查询速度是非常重要的。

3、把所有需要提高查询速度的字段都加进聚集索引，以提高查询速度

上面已经谈到：在进行数据查询时都离不开字段的是“日期”还有用户本身的“用户名”。既然这两个字段都是如此的重要，我们可以把他们合并起来，建立一个复合索引（compound index）。

很多人认为只要把任何字段加进聚集索引，就能提高查询速度，也有人感到迷惑：如果把复合的聚集索引字段分开查询，那么查询速度会减慢吗？带着这个问题，我们来看一下以下的查询速度（结果集都是25万条数据）：（日期列fariqi首先排在复合聚集索引的起始列，用户名neibuyonghu排在后列）

（1）select gid,fariqi,neibuyonghu,title from Tgongwen where fariqi>'2004-5-5' 查询速度：2513毫秒

（2）select gid,fariqi,neibuyonghu,title from Tgongwen where fariqi>'2004-5-5' and neibuyonghu='办公室' 查询速度：2516毫秒

（3）select gid,fariqi,neibuyonghu,title from Tgongwen where neibuyonghu='办公室' 查询速度：60280毫秒

从以上试验中，我们可以看到如果仅用聚集索引的起始列作为查询条件和同时用到复合聚集索引的全部列的查询速度是几乎一样的，甚至比用上全部的复合索引列还要略快（在查询结果集数目一样的情况下）；而如果仅用复合聚集索引的非起始列作为查询条件的话，这个索引是不起任何作用的。当然，语句1、2的查询速度一样是因为查询的条目数一样，如果复合索引的所有列都用上，而且查询结果少的话，这样就会形成“索引覆盖”，因而性能可以达到最优。同时，请记住：无论您是否经常使用聚合索引的其他列，但其前导列一定要是使用最频繁的列。

（四）其他书上没有的索引使用经验总结

1、用聚合索引比用不是聚合索引的主键速度快

下面是实例语句：（都是提取25万条数据）

select gid,fariqi,neibuyonghu,reader,title from Tgongwen where fariqi='2004-9-16' 使用时间：3326毫秒

select gid,fariqi,neibuyonghu,reader,title from Tgongwen where gid<=250000 使用时间：4470毫秒

这里，用聚合索引比用不是聚合索引的主键速度快了近1/4。

2、用聚合索引比用一般的主键作order by时速度快，特别是在小数据量情况下

select gid,fariqi,neibuyonghu,reader,title from Tgongwen order by fariqi 用时：12936

select gid,fariqi,neibuyonghu,reader,title from Tgongwen order by gid 用时：18843

这里，用聚合索引比用一般的主键作order by时，速度快了3/10。事实上，如果数据量很小的话，用聚集索引作为排序列要比使用非聚集索引速度快得明显的多；而数据量如果很大的话，如10万以上，则二者的速度差别不明显。

3、使用聚合索引内的时间段，搜索时间会按数据占整个数据表的百分比成比例减少，而无论聚合索引使用了多少个

select gid,fariqi,neibuyonghu,reader,title from Tgongwen where fariqi>'2004-1-1' 用时：6343毫秒（提取100万条）

select gid,fariqi,neibuyonghu,reader,title from Tgongwen where fariqi>'2004-6-6' 用时：3170毫秒（提取50万条）

select gid,fariqi,neibuyonghu,reader,title from Tgongwen where fariqi='2004-9-16'

用时：3326毫秒（和上句的结果一模一样。如果采集的数量一样，那么用大于号和等于号是一样的）

select gid,fariqi,neibuyonghu,reader,title from Tgongwen where fariqi>'2004-1-1' and fariqi<'2004-6-6' 用时：3280毫秒

4 、日期列不会因为有分秒的输入而减慢查询速度

下面的例子中，共有100万条数据，2004年1月1日以后的数据有50万条，但只有两个不同的日期，日期精确到日；之前有数据50万条，有5000个不同的日期，日期精确到秒。

select gid,fariqi,neibuyonghu,reader,title from Tgongwen where fariqi>'2004-1-1' order by fariqi 用时：6390毫秒

select gid,fariqi,neibuyonghu,reader,title from Tgongwen where fariqi<'2004-1-1' order by fariqi 用时：6453毫秒

（五）其他注意事项

“水可载舟，亦可覆舟”，索引也一样。索引有助于提高检索性能，但过多或不当的索引也会导致系统低效。因为用户在表中每加进一个索引，数据库就要做更多的工作。过多的索引甚至会导致索引碎片。

所以说，我们要建立一个“适当”的索引体系，特别是对聚合索引的创建，更应精益求精，以使您的数据库能得到高性能的发挥。

当然，在实践中，作为一个尽职的数据库管理员，您还要多测试一些方案，找出哪种方案效率最高、最为有效。

二、改善SQL语句

很多人不知道SQL语句在SQL SERVER中是如何执行的，他们担心自己所写的SQL语句会被SQL SERVER误解。比如：

select * from table1 where name='zhangsan' and tID > 10000 和执行: select * from table1 where tID > 10000 and name='zhangsan'

一些人不知道以上两条语句的执行效率是否一样，因为如果简单的从语句先后上看，这两个语句的确是不一样，如果tID是一个聚合索引，那么后一句仅仅从表的10000条以后的记录中查找就行了；而前一句则要先从全表中查找看有几个name='zhangsan'的，而后再根据限制条件条件tID>10000来提出查询结果。

事实上，这样的担心是不必要的。SQL SERVER中有一个“查询分析优化器”，它可以计算出where子句中的搜索条件并确定哪个索引能缩小表扫描的搜索空间，也就是说，它能实现自动优化。

虽然查询优化器可以根据where子句自动的进行查询优化，但大家仍然有必要了解一下“查询优化器”的工作原理，如非这样，有时查询优化器就会不按照您的本意进行快速查询。

在查询分析阶段，查询优化器查看查询的每个阶段并决定限制需要扫描的数据量是否有用。如果一个阶段可以被用作一个扫描参数（SARG），那么就称之为可优化的，并且可以利用索引快速获得所需数据。

SARG的定义：用于限制搜索的一个操作，因为它通常是指一个特定的匹配，一个值得范围内的匹配或者两个以上条件的AND连接。形式如下：

列名操作符 <常数或变量>或<常数或变量> 操作符列名

列名可以出现在操作符的一边，而常数或变量出现在操作符的另一边。如：

Name=’张三’

价格>5000

5000<价格

Name=’张三’ and 价格>5000

如果一个表达式不能满足SARG的形式，那它就无法限制搜索的范围了，也就是SQL SERVER必须对每一行都判断它是否满足WHERE子句中的所有条件。所以一个索引对于不满足SARG形式的表达式来说是无用的。

介绍完SARG后，我们来总结一下使用SARG以及在实践中遇到的和某些资料上结论不同的经验：

1、Like语句是否属于SARG取决于所使用的通配符的类型

如：name like ‘张%’ ，这就属于SARG

而：name like ‘%张’ ,就不属于SARG。

原因是通配符%在字符串的开通使得索引无法使用。

2、or 会引起全表扫描

Name=’张三’ and 价格>5000 符号SARG，而：Name=’张三’ or 价格>5000 则不符合SARG。使用or会引起全表扫描。

3、非操作符、函数引起的不满足SARG形式的语句

不满足SARG形式的语句最典型的情况就是包括非操作符的语句，如：NOT、!=、<>、!<、!>、NOT EXISTS、NOT IN、NOT LIKE等，另外还有函数。下面就是几个不满足SARG形式的例子：

ABS(价格)<5000

Name like ‘%三’

有些表达式，如：

WHERE 价格*2>5000

SQL SERVER也会认为是SARG，SQL SERVER会将此式转化为：

WHERE 价格>2500/2

但我们不推荐这样使用，因为有时SQL SERVER不能保证这种转化与原始表达式是完全等价的。

4、IN 的作用相当与OR

语句：

Select * from table1 where tid in (2,3)和Select * from table1 where tid=2 or tid=3

是一样的，都会引起全表扫描，如果tid上有索引，其索引也会失效。

5、尽量少用NOT

6、exists 和 in 的执行效率是一样的

很多资料上都显示说，exists要比in的执行效率要高，同时应尽可能的用not exists来代替not in。但事实上，我试验了一下，发现二者无论是前面带不带not，二者之间的执行效率都是一样的。因为涉及子查询，我们试验这次用SQL SERVER自带的pubs数据库。运行前我们可以把SQL SERVER的statistics I/O状态打开。

（1） select title,price from titles where title_id in (select title_id from sales where qty>30)

（2）该句的执行结果为：

表 'sales'。扫描计数 18，逻辑读 56 次，物理读 0 次，预读 0 次。

表 'titles'。扫描计数 1，逻辑读 2 次，物理读 0 次，预读 0 次。

（2）select title,price from titles where exists (select * from sales where sales.title_id=titles.title_id and qty>30)

第二句的执行结果为：

表 'sales'。扫描计数 18，逻辑读 56 次，物理读 0 次，预读 0 次。

表 'titles'。扫描计数 1，逻辑读 2 次，物理读 0 次，预读 0 次。

我们从此可以看到用exists和用in的执行效率是一样的。

7、用函数charindex()和前面加通配符%的LIKE执行效率一样

前面，我们谈到，如果在LIKE前面加上通配符%，那么将会引起全表扫描，所以其执行效率是低下的。但有的资料介绍说，用函数charindex()来代替LIKE速度会有大的提升，经我试验，发现这种说明也是错误的：

select gid,title,fariqi,reader from tgongwen where charindex('刑侦支队',reader)>0 and fariqi>'2004-5-5'

用时：7秒，另外：扫描计数 4，逻辑读 7155 次，物理读 0 次，预读 0 次。

select gid,title,fariqi,reader from tgongwen where reader like '%' + '刑侦支队' + '%' and fariqi>'2004-5-5'

用时：7秒，另外：扫描计数 4，逻辑读 7155 次，物理读 0 次，预读 0 次。

8、union并不绝对比or的执行效率高

我们前面已经谈到了在where子句中使用or会引起全表扫描，一般的，我所见过的资料都是推荐这里用union来代替or。事实证明，这种说法对于大部分都是适用的。

select gid,fariqi,neibuyonghu,reader,title from Tgongwen where fariqi='2004-9-16' or gid>9990000

用时：68秒。扫描计数 1，逻辑读 404008 次，物理读 283 次，预读 392163 次。

select gid,fariqi,neibuyonghu,reader,title from Tgongwen where fariqi='2004-9-16'

union

select gid,fariqi,neibuyonghu,reader,title from Tgongwen where gid>9990000

用时：9秒。扫描计数 8，逻辑读 67489 次，物理读 216 次，预读 7499 次。

看来，用union在通常情况下比用or的效率要高的多。

但经过试验，笔者发现如果or两边的查询列是一样的话，那么用union则反倒和用or的执行速度差很多，虽然这里union扫描的是索引，而or扫描的是全表。

select gid,fariqi,neibuyonghu,reader,title from Tgongwen where fariqi='2004-9-16' or fariqi='2004-2-5'

用时：6423毫秒。扫描计数 2，逻辑读 14726 次，物理读 1 次，预读 7176 次。

select gid,fariqi,neibuyonghu,reader,title from Tgongwen where fariqi='2004-9-16'

union

select gid,fariqi,neibuyonghu,reader,title from Tgongwen where fariqi='2004-2-5'

用时：11640毫秒。扫描计数 8，逻辑读 14806 次，物理读 108 次，预读 1144 次。

9、字段提取要按照“需多少、提多少”的原则，避免“select *”

我们来做一个试验：

select top 10000 gid,fariqi,reader,title from tgongwen order by gid desc 用时：4673毫秒

select top 10000 gid,fariqi,title from tgongwen order by gid desc 用时：1376毫秒

select top 10000 gid,fariqi from tgongwen order by gid desc 用时：80毫秒

由此看来，我们每少提取一个字段，数据的提取速度就会有相应的提升。提升的速度还要看您舍弃的字段的大小来判断。

10、count(*)不比count(字段)慢

某些资料上说：用*会统计所有列，显然要比一个世界的列名效率低。这种说法其实是没有根据的。我们来看：

select count(*) from Tgongwen 用时：1500毫秒

select count(gid) from Tgongwen 用时：1483毫秒

select count(fariqi) from Tgongwen 用时：3140毫秒

select count(title) from Tgongwen 用时：52050毫秒

从以上可以看出，如果用count(*)和用count(主键)的速度是相当的，而count(*)却比其他任何除主键以外的字段汇总速度要快，而且字段越长，汇总的速度就越慢。我想，如果用count(*)， SQL SERVER可能会自动查找最小字段来汇总的。当然，如果您直接写count(主键)将会来的更直接些。

11、order by按聚集索引列排序效率最高

我们来看：（gid是主键，fariqi是聚合索引列）

select top 10000 gid,fariqi,reader,title from tgongwen

用时：196 毫秒。扫描计数 1，逻辑读 289 次，物理读 1 次，预读 1527 次。

select top 10000 gid,fariqi,reader,title from tgongwen order by gid asc

用时：4720毫秒。扫描计数 1，逻辑读 41956 次，物理读 0 次，预读 1287 次。

select top 10000 gid,fariqi,reader,title from tgongwen order by gid desc

用时：4736毫秒。扫描计数 1，逻辑读 55350 次，物理读 10 次，预读 775 次。

select top 10000 gid,fariqi,reader,title from tgongwen order by fariqi asc

用时：173毫秒。扫描计数 1，逻辑读 290 次，物理读 0 次，预读 0 次。

select top 10000 gid,fariqi,reader,title from tgongwen order by fariqi desc

用时：156毫秒。扫描计数 1，逻辑读 289 次，物理读 0 次，预读 0 次。

从以上我们可以看出，不排序的速度以及逻辑读次数都是和“order by 聚集索引列” 的速度是相当的，但这些都比“order by 非聚集索引列”的查询速度是快得多的。

同时，按照某个字段进行排序的时候，无论是正序还是倒序，速度是基本相当的。

本文链接

如何建立索引

2010-09-10T02:18:00Z

为了给一个表建立索引，启动任务栏SQL Sever程序组中的ISQL/w程序。进入查询窗口后，输入下面的语句：

CREATE INDEX mycolumn_index ON mytable (myclumn)

这个语句建立了一个名为mycolumn_index的索引。你可以给一个索引起任何名字，但你应该在索引名中包含所索引的字段名，这对你将来弄清楚建立该索引的意图是有帮助的。

注意

在本书中你执行任何SQL语句，都会收到如下的信息：

This command did not return data,and it did not return any rows

这说明该语句执行成功了。

索引mycolumn_index对表mytable的mycolumn字段进行。这是个非聚簇索引，也是个非唯一索引。（这是一个索引的缺省属性）

如果你需要改变一个索引的类型，你必须删除原来的索引并重建一个。建立了一个索引后，你可以用下面的SQL语句删除它：

DROP INDEX mytable.mycolumn_index

注意在DROP INDEX 语句中你要包含表的名字。在这个例子中，你删除的索引是mycolumn_index，它是表mytable的索引。

要建立一个聚簇索引，可以使用关键字CLUSTERED。）记住一个表只能有一个聚簇索引。（这里有一个如何对一个表建立聚簇索引的例子：

CREATE CLUSTERED INDEX mycolumn_clust_index ON mytable(mycolumn)

如果表中有重复的记录，当你试图用这个语句建立索引时，会出现错误。但是有重复记录的表也可以建立索引；你只要使用关键字ALLOW_DUP_ROW把这一点告诉SQL Sever即可：

CREATE CLUSTERED INDEX mycolumn_cindex ON mytable(mycolumn)

WITH ALLOW_DUP_ROW

这个语句建立了一个允许重复记录的聚簇索引。你应该尽量避免在一个表中出现重复记录，但是，如果已经出现了，你可以使用这种方法。

要对一个表建立唯一索引，可以使用关键字UNIQUE。对聚簇索引和非聚簇索引都可以使用这个关键字。这里有一个例子：

CREATE UNIQUE COUSTERED INDEX myclumn_cindex ON mytable(mycolumn)

这是你将经常使用的索引建立语句。无论何时，只要可以，你应该尽量对一个对一个表建立唯一聚簇索引来增强查询操作。

最后，要建立一个对多个字段的索引──复合索引──在索引建立语句中同时包含多个字段名。下面的例子对firstname和lastname两个字段建立索引：

CREATE INDEX name_index ON username(firstname,lastname)

这个例子对两个字段建立了单个索引。在一个复合索引中，你最多可以对16个字段进行索引。

用事务管理器建立索引

用事务管理器建立索引比用SQL语句容易的多。使用事务管理器，你可以看到已经建立的索引的列表，并可以通过图形界面选择索引选项。

使用事务管理器你可以用两种方式建立索引：使用Manage Tables窗口或使用Manage Indexes窗口。

要用Manage Tables 窗口建立一个新索引，单击按钮Advanced Options(它看起来象一个前面有一加号的表)。这样就打开了Advanced Options对话框。这个对话框有一部分标名为Primary Key
要建立一个新索引，从下拉列表中选择你想对之建立索引的字段名。如果你想建立一个对多字段的索引，你可以选择多个字段名。你还可以选择索引是聚簇的还是非聚簇的。在保存表信息后，索引会自动被建立。在Manage Tables窗口中的字段名旁边，会出现一把钥匙。

你已经为你的表建立了“主索引”。主索引必须对不包含空值的字段建立。另外，主索引强制一个字段成为唯一值字段。

要建立没有这些限制的索引，你需要使用Manage Indexes窗口。从菜单中选择Manage|Indexes，打开Manage Indexes 窗口。在Manage Indexes 窗口中，你可以通过下拉框选择表和特定的索引。（见图11.2）。要建立一个新索引，从Index下拉框中选择New Index.，然后就可以选择要对之建立索引的字段。单击按钮Add，把字段加人到索引中。
你可以为你的索引选择许多不同的选项。例如，你可以选择该索引是聚簇的还是非聚簇的。你还可以指定该索引为唯一索引。设计好索引后，单击按钮Build，建立该索引。

注意

唯一索引是指该字段不能有重复的值，而不是只能建立这一个索引。

本文链接

ASP.NET Web Form 的“连续”和“有状态”假象（转）

2010-09-07T09:02:00Z

原文 http://www.cnblogs.com/sgsoft/articles/62691.html

从根本上说，ASP.NET 并没有改变 Web 页的本质：每次请求 ASP.NET 页时，服务器就会加载一个 ASP.NET 页，并在请求完成时卸载该页。页及其包含的服务器控件负责执行请求并将 HTML 呈现给客户端。

ASP.NET 的设计者们，从实际访问者的角度重新考虑了这一过程：访问者打开一个页面，点击一个按钮，看到新的画面……这一切似乎都是连续的。

这种连续性假象是由 ASP.NET 页框架、页及其控件实现的。回发后，控件的行为必须看起来是从上次 Web 请求结束的地方开始的。另一方面，对于 Web Form 中的 TextBox，ASP.NET 也让它们具有了状态，可以知道上一个 loop 和这一个 loop 之间的 TextBox 值的变化；如果变化，可能会触发 TextBox 的 TextChanged 事件。这同样是 ASP.NET 特意实现的一个假象。

ASP.NET 服务器控件的生命周期一般如下：

1. 初始化 - Init 事件 (OnInit 方法)

2. 加载视图状态 - LoadViewState 方法

3. 处理回发数据 - LoadPostData 方法
对实现 IPostBackDataHandler 接口的控件，即可以自动加载回发数据的控件，如 TextBox, DropDownList 等。

4. 加载 - Load 事件 (OnLoad 方法)

5. 发送回发更改通知 - RaisePostDataChangedEvent 方法
对实现 IPostBackDataHandler 接口的控件，即可以自动加载回发数据的控件。
在第 3 步中加载回发数据，如果回发前后数据发生更改，则在这一步触发相应的服务端事件。

6. 处理回发事件 - RaisePostBackEvent 方法
对实现 IPostBackEventHandler 接口的控件，即能引起回发的控件，如 Button, LinkButton, Calendar 等

7. 预呈现 - PreRender 事件 (OnPreRender 方法)

8. 保存视图状态 - SaveViewState 方法

9. 呈现 - Render 方法

10. 处置 - Dispose 方法

11. 卸载 - UnLoad 事件 (OnUnLoad 方法)

Web Form 的基类 System.Web.UI.Page 从 System.Web.UI.Control 继承，它也是一种特殊的 Control。

ASP.NET 是怎样实现状态的？

ASP.NET 使用了 ViewState 视图状态，如果你查看 Web Form 产生的 HTML 代码，可以看到一个名为 __ViewState 的隐藏字段，ASP.NET 将状态信息以 Hash 的方式存储在这里。通过它，可以在下一次回发时知道回发前各控件的状态。

比如：一个 TextBox，回发前 Text 属性有值“hello”，访问者填写了新的值“world”，当这个页面回发到服务器端，服务端代码就可以得知 TextBox 的 Text 属性值发生了改变，TextChanged 事件就被触发了。从生命周期来看，LoadViewState 这一步加载了 TextBox 的原状态，LoadPostData 这一步从 Request.Form 集合中取得了 TextBox 的当前值，过了 Load，在 RaisePostDataChangedEvent 这一步触发 TextBox 的 TextChanged 事件，SaveViewState 将当前值存入 ViewState 作为下一次回发的原状态。

ASP.NET 是怎样实现连续性假象的？

对开发者而言，以往对于一个提交按钮的点击回发，或者说 HTML form 提交的处理往往是在另一个页面中处理，将 form 的 target 指向该页面。（当然在一个页面中也是可以完成的，但大部分人习惯于两个页面）

在 ASP.NET 中，这一过程被处理成和 Windows 程序类似的过程，Button 的点击、form 被提交这个事件被 ASP.NET “包装”成一个服务器事件，也就是 Button 的 Click 事件。从生命周期来看，Button 控件被加载的流程如下：LoadPostData 这一步可以从 Request.Form 集合中找到 Button 的 name 值（只有被点击的 Button 会在 Request.Form 集合中生成一个 name-value 对）；过了 Load，在 RaisePostBackEvent 这一步，将触发 Button 的 Click 事件。

我们再分析特别的情况：Button 在 HTML 中是可以引起 form 的提交的，也就是可以引起页面回发；但其他的，如 LinkButton (对应于 HTML 的 A 元素)，DropDownList (对应于 HTML 的 SELECT)等，则并不会自动引起回发。这种情况下，ASP.NET 使用了又一个技巧来保证这一假象继续成立：打开含有 LinkButton 的一个 ASP.NET 生成的 HTML 页面代码，可以找到两个隐藏字段，一个叫 __EVENTTARGET，一个叫 __EVENTARGUMENT，再往下找到一段脚本：

function __doPostBack(eventTarget, eventArgument) {
  var theform;
  if (window.navigator.appName.toLowerCase().indexOf("netscape") > -1) {
   theform = document.forms["Form1"];
  }
  else {
   theform = document.Form1;
  }
  theform.__EVENTTARGET.value = eventTarget.split("$").join(":");
  theform.__EVENTARGUMENT.value = eventArgument;
  theform.submit();
 }

再看看 LinkButton 生成的代码：

<A id=LinkButton1 href="javascript:__doPostBack('LinkButton1','')">LinkButton</A>

如果你做过网页中的客户端脚本的话，应该知道，当点击这个“LinkButton”时，实际上是通过客户端脚本将它的名字和若干参数（比如 Calendar 需要传递一些参数，LinkButton 没有传参数的必要）设置到两个隐藏字段中，并在脚本中提交了表单。

继续看服务段的流程：LoadPostData 会看到这两个隐藏字段中的值，但并不马上解析；依然是过了 Load，在 RaisePostBackEvent 这一步解析这两个字段中的值，触发相应控件的事件。

我们最后分析一下 CheckBox 或者 DropDownList 之类的 AutoPostBack 属性：如果 AutoPostBack 为 true，则在向客户端输出时，加入上面的 __doPostBack 式的回发；如为 false，则不加入这样的立即回发脚本，而是等待有其他可以引起回发的控件（比如 Button, LinkButton 等）回发后，在 RaisePostDataChanged 中触发 CheckBox 的 CheckedChanged 事件，DropDownList 的 SelectedIndexChanged 事件；在 RaisePostBackEvent 时继续分析其他引起回发的事件。

微软把复杂的 Web 模型简化成一个传统 Windows 程序员易于接受的模型，大大降低了 Web 开发的门槛。但尽管如此，微软无法改变 Web 的“无状态”、“断续”的实质，所以不要将所有 Windows 程序开发的经验都一古脑运用到 Web 开发当中。了解了其内在机理，有助于 Windows 程序员避免这些“武断”的错误。

本文链接

博客园_脚印

【转】 Image Tips for Windows Phone 7

windows phone 应用程序退出代码

Windows Phone 页面切换

Windows Phone的网络连接策略（转）

XML Schema

Init,Load,PreRender事件执行顺序

javascript 继承

深入浅出理解索引结构（转）

如何建立索引

ASP.NET Web Form 的“连续”和“有状态”假象 （转）

ASP.NET Web Form 的“连续”和“有状态”假象（转）