You should look at this ASP.NET Page Life Cycle Overview and this

Page: PreInit
Control: Init
Page: Init
Page: InitComplete
Page: PreLoad
Page: Load
Control: Load
Page: LoadComplete
Page: PreRender
Control: PreRender
Page: PreRenderComplete
Page: SaveStateComplete
Page: RenderControl
Page: Render
Control: RenderControl
Control: Unload
Control: Dispose
Page: Unload
Page: Dispose

ASP.NET Application and Page Life Cycle

https://www.codeproject.com/Articles/73728/ASP-NET-Application-and-Page-Life-Cycle

Page Init

This event happens in the ASP.NET page and can be used for:

• Creating controls dynamically, in case you have controls to be created on runtime.
• Any setting initialization.
• Master pages and the settings.

In this section, we do not have access to viewstate, postedvalues and neither the controls are initialized.

Page Load

In this section, the ASP.NET controls are fully loaded and you write UI manipulation logic or any other logic over here.

This is the place where you will put any logic you want to operate on the controls. Like flourishing a combobox from the database, sorting data on a grid, etc. In this event, we get access to all controls, viewstate and their posted values.

PreRender

If you want to make final changes to the UI objects like changing tree structure or property values, before these controls are saved in to view state.

Render

If you want to add some custom HTML to the output this is the place you can.

It’s now time to send the output to the browser. If you would like to make some changes to the final HTML which is going out to the browser, you can enter your HTML logic here.

中文版的

asp.net页面事件执行顺序(轉)

Page life cycle with user control

FAQ: Sequence that events are raised for Pages, UserControls, MasterPages and HttpModules

Understanding the Page Life Cycle can be very important as you begin to build Pages with MasterPages and UserControls.

Does the Init event fire first for the Page, the MasterPage or the UserControl? 
What about the Load event?

If you make an incorrect assumption about the sequence that these
events fire, then you may end up with a page that simply doesn't behave
the way you had anticipated.

By running a simple test, we can see exactly when each event fires. 
Our test setup is composed of a Page, MasterPage, UserControl, Nested
UserControl and Button control as follows:

• The Page is tied to the MasterPage
• The UserControl is on the Page
• The Nested UserControl is on the UserControl
• The Button is on the Nested UserControl.
• Clicking the Button calls the Page.DataBind method

Each event on these controls has been set to call
Debug.WriteLine as each event is raised.  In addition to the events that
get raised for regular pages, I've also set up an HttpModule and wired
up all of those events as well. The results in the Debug output
window of running this page and Clicking the Button
are as follows:

BeginRequest - HttpModule
AuthenticateRequest - HttpModule
PostAuthenticateRequest - HttpModule
PostAuthorizeRequest - HttpModule
ResolveRequestCache - HttpModule
PostResolveRequestCache - HttpModule
PostMapRequestHandler - HttpModule
AcquireRequestState - HttpModule
PostAcquireRequestState - HttpModule
PreRequestHandlerExecute - HttpModule

PreInit - Page

Init - ChildUserControl
Init - UserControl
Init - MasterPage
Init - Page

InitComplete - Page

LoadPageStateFromPersistenceMedium - Page

ProcessPostData (first try) - Page

PreLoad - Page

Load - Page
Load - MasterPage
Load - UserControl
Load - ChildUserControl

ProcessPostData (second try) - Page

RaiseChangedEvents - Page
RaisePostBackEvent - Page

Click - Button - ChildUserControl

DataBinding - Page
    DataBinding - MasterPage
    DataBinding - UserControl
    DataBinding - ChildUserControl

LoadComplete - Page

PreRender - Page
PreRender - MasterPage
PreRender - UserControl
PreRender - ChildUserControl

PreRenderComplete - Page

SaveViewState - Page
SavePageStateToPersistenceMedium - Page
SaveStateComplete - Page

Unload - ChildUserControl
Unload - UserControl
Unload - MasterPage
Unload - Page

PostRequestHandlerExecute - HttpModule
ReleaseRequestState - HttpModule
PostReleaseRequestState - HttpModule
UpdateRequestCache - HttpModule
PostUpdateRequestCache - HttpModule
EndRequest - HttpModule
PreSendRequestHeaders - HttpModule
PreSendRequestContent - HttpModule

I hope that you will find this information useful.

Complete Lifecycle of an ASP.Net page and controls

自己做的postback和事件的顺序测试

第一次加载出页面的时候

[INFO] 2019-05-16 10:52:30.026+08:00 - OnInit fired in login page - [6]

[INFO] 2019-05-16 10:52:30.031+08:00 - Page_Init fired in login page - [6]

[INFO] 2019-05-16 10:52:30.037+08:00 - Page_Load fired in login page - [6]

点击登录按钮之后，触发了post back，先加载Init，然后是Load，最后才是按钮click事件绑定的方法

[INFO] 2019-05-16 10:54:03.763+08:00 - OnInit fired in login page - [7]

[INFO] 2019-05-16 10:54:03.764+08:00 - Page_Init fired in login page - [7]

[INFO] 2019-05-16 10:54:03.767+08:00 - Page_Load fired in login page - [7]

[INFO] 2019-05-16 10:54:03.770+08:00 - btnLogin_Click fired in login page - [7]

自己做的page和control的事件顺序测试

user control中的代码

public ChangeMyPassword()
{
Init += ChangeMyPassword_Init;
}

这个是优先注册的

private void ChangeMyPassword_Init(object sender, EventArgs e)
{

LogUtil.CreateLog(LogLevel.Message, "ChangeMyPassword_Init");
}

下面这个是被动注册的，通过autoeventwireup=true延迟绑定的。所以执行顺序在，这个在上面那个后面

protected void Page_Init(object sender, EventArgs e)
{
LogUtil.CreateLog(LogLevel.Message, "Page_Init in user control");
}

[INFO] 2019-05-16 13:30:07.330+08:00 -program /LM/W3SVC/4/ROOT/MyApplication-2-132024582037055218 started. - [1]

[INFO] 2019-05-16 13:30:11.963+08:00 - ChangeMyPassword_Init - [10]

[INFO] 2019-05-16 13:30:11.967+08:00 - Page_Init in user control - [10]

[INFO] 2019-05-16 13:30:11.994+08:00 - Page_Init in login page - [10]