页面生命周期的来龙去脉(详细)

by谭小龙

客户端浏览器到服务器->经过Http.sys(内存模块)->iis 中的w3svc服务(这个服务寄宿在svchost这个进程里面的)(要么返回静态页面,要么交给inetinfo.exe(映射关系表,看当前请求交给谁来处理,获得处理对象程序之后,返回给W3SVC服务))->然后根据从映射表中的对应关系把请求交给具体的工作进程:W3WP.exe.这个在iis 3 iis 5.5 iis6都是这个).但是工作进程有多个,比如说每个网站都是一个进程.所以在这里采取的是进程池的技术.,,请求走到这里会通过启动W3WP.exe这个工作进程中一个应用程序扩展模块,叫做aspnet_isapi.exe.这个模块就是具体负责处理动态网页的一个外部dll ,但是微软特别牛的地方,这个应用程序扩展模块的映射关系,可以手动加载,也就是说,你完全可以写一个.txl后缀,交给一个txlprocessWork.dll的应用程序扩展模块来处理->接着说aspnet_isapi.dll会把请求分发.分发给托管的运行时,这个时候,整个请求才会进入到托管的环境.->在环境中,第一个会到达的是ISAPIRuntime,细致的说是会到达ISAPIRuntime.的PR方法.也就是ProcessRquest方法,并且在这个方法中传进去一个参数,这个参数是一个ecb句柄 ,通过ecb句柄,把请求的报文传递到了托管的环境.而在这个方法的内部,通过ecb句柄,创建一个HttpworkRequest对象->然后将这个HttpworkRequest对象作为参数交给了HttpRuntime的PR方法,在HttpRuntime方法的内部,通过HttpworkRequest对象创建一个HttpContext上下文对象.这个对象包含了请求和响应,已经session,application这些东西,都可以通过HttpContext拿到->然后(将HttpContext对象交给HttpApplication来处理.HttpApplication是)通过一个HttpApplicationFactory获取一个HttpApplication的对象,这里走的是一个对象池的技术,这里也显示出了微软的博大精深,就是它会先看池中有没有HttpApplicaton对象,如果有,就直接返回这个对象,如果没有就把Global编译成的文件,反射出一个实例来.放到这里.进行维护下面操作的运作.->下面就是HttpApplicaton进行维护管道的执行.接下来的所有工作都交给了HttpApplication来负责.他会一共开十九个事件(msdn上是说有二十二个步骤十九个事件,但事实上不止二十二个步骤,关于这种说法,在博客园上到处可见 ),其中第七个事件和第八个事件之间根据当前请求创建了IHttpHandler接口的实例不管你是页面还是一般处理程序,都能对应操作.但是是根据你请求的地址,你请求的是谁,就创建谁的实例,第十一和是十二个事件之间就执行了页面的对象pr方法或者是一般处理程序的pr方法.如果是一般处理程序的pr方法很简单,就是由我们程序员用代码控制.如果是指向的页面,就是指的页面的生命周期.但是这是一个非常大的一个圆型的步骤(过程).执行完了这些步骤之后,在此回到十一和十二事件之间来,继续往下走.后续的所有事件都执行完毕之后.当前请求结束.然后把HttpContext响应的内容响应给客户端.而管道流动的.永远都是HttpContext上下文对象.什么叫流动啊.就是在这十九事件之间传递的这个上下文对象.从另外一个方面来看,也就是微软对请求做了一个过滤处理..

那么显然十一和十二个事件中间的处理的那个非常复杂的步骤,就是核心.执行的时候,第一步就是创建一个页面控件树.也就是执行了FrameworkInitialize()方法这个方法的内部就是帮我们去创建_BuildControlTree()方法.他内部就有this._BuildControlTree(this)的方法调用.创建控件树.这是页面生命周期的第一步.也就是说page这个类的pr方法里的第一步就是创建控件树.第二步确定是否是回发.也就是确定是否是IsPostback ProcessRequestMain才是最主要的方法

.这十九个就是整个页面的生存周期.(这个讲起来都对为身程序员感到自豪.因为微软整个设计行云流水太精妙了. 所以说程序员真心聪明. )