Android App Run process

Source: Android App Run process

First, Activitythread starts execution from the main () function, and calls Preparemainlooper () to create a message queue (MessageQueue) for the UI thread.

A Activitythread object is then created, and an H (Handler) object and a Applicationthread (Binder) object are created in the initialization code of the Activitythread. Where Binder is responsible for receiving IPC calls from the remote AMS, and after receiving the call, the message is sent to the message queue via handler, and the main thread of the UI asynchronously pulls the message out of the message queue and performs the appropriate actions, such as start stop pause, and so on.

The main thread of the UI then calls the Looper.loop () method into the message loop body, which continues to read and process the message from the message queue as it enters.

When Activitythread receives the AMS send start activity, the specified activity object is created, and the activity creates the Phonewindow class-->decorview class-- Create the appropriate view or ViewGroup. Once created, the activity needs to display the created interface to the screen, calling the WindowManager class, which then creates a Viewroot object that actually creates the Viewroot class and the W class, and after the Viewroot object is created, WindowManager calls the remote calling interface provided by the WMS to complete adding a window and displaying it to the screen.

Continue looking down, the Attach method instantiates a Phonewindow object through code Mwindow = Policymanager.makenewwindow (This)

Policymanager's role can be see the blogger's

policymanager role of Android

The next step is to call Phonewindow's Setcontentview method when the activity starts OnCreate call, of course, if there is a first judgment, then call the method Installdecor (), and then call Generatedecor () Create a top-level view Decorview Mdecor,decorview is a subclass of Framelayout, what does it do in method Generatelayout (Mdecor) ?

This method will do the following things: (Do not want to write, in the Qinjuning blog copy a bit, understanding AH)
1. Select a different window layout file (root view) for the window, depending on the style of the window. These window-decorated layout files specify one to store
The ViewGroup view of the activity custom layout file, typically framelayout whose ID is: android:id= "@android: Id/content".
For example, window decoration types include fullscreen (full screen), Notitlebar (excluding title bars), and so on. There are two types of selected window decorations:
①, specifying Requestfeature () specifies the window modifier, Phonewindow object calls the Getlocalfeature () method to get the value;
②, configure the corresponding property for our activity, i.e. Android:theme= "", Phonewindow object calls Getwindowstyle () method
Gets the value.
For example, the following method is used to hide the title bar: Requestwindowfeature (window.feature_no_title);
or configure XML properties for activity: Android:theme= "@android: Style/theme.notitlebar".

PS: Therefore, the Requestfeature () method must be called before setcontentview in the activity.
After determining the window style, select the layout file that corresponds to the style, which is located in frameworks/base/core/res/layout/,
Typical window layout files are:
R.layout.dialog_titile_icons r.layout.screen_title_icons
R.layout.screen_progress R.layout.dialog_custom_title
R.layout.dialog_title
R.layout.screen_title//The most commonly used activity window decorates the layout file
R.layout.screen_simple//full-screen Activity window layout file

In the end, when Activitymanagerservice is ready to resume an activity, it will call back to the activity's handleresumeactivity () method and invoke the Makevisible method of the activity. That shows the created Dectorview

Here are some summary information:

WindowManager just provides the interface, with the bridge mode, the real implementation is the Windowmanagerimpl class. The object that calls the Addiew method comes from another class Localwindowmanager, which does some simple checking and then adds it through the AddView completion window of the Windowmanagerimp class. AddView is approximately three steps in the execution of:

1. Verify that the window has been added.

2. Determine the window type if it is a child window, find its subordinate parent window

3.new a Viewrootimpl object, and finally calls the Setview method of the object.

The Setview method will eventually invoke the Iwindowsession Add method through the IPC. The session class implements the method and finally windowmanagerservice processing. The client's work is now complete.

Here is a description of the Viewrootimpl class, which is actually a handler. Naturally, part of the function is to process the message and distribute some of the user's actions to the view. It is also a bridge between view and Windowmanagerservice. You can see that it passes information to Windowmanagerservice through a session. Windowmanagerservice also sends instructions through the Iwindow interface to the Viewrootimpl,viewrootimpl to process these messages.

Two. Service-side

The AddWindow method of Windowmanagerservice mainly deals with three parts.

1. Do some verification of legality

2. Completion of window data construction

3. Some adjustments that need to be made after completing the window creation

We only look at the second part. The first is a new WindowState class that represents a window. Combined with Windowtoken and Appwindowtoken, a complete definition of the window content. A pipeline is then created to process the message input. Then call the Attach method, create content related to surface, and use it to interact with Surfaceflinger. In this way, the entire window is built. With the WindowState class to save the window properties and token to the window attribution of the identity, then can be drawn through the Surfaceflinger on the screen. It can also handle the passing of messages and windowmanagerservice through InputManager. Ensure that the window display content and user actions are consistent.

Of course, Windowmanagerservice close to 10000 lines of code to complete a lot of functionality, because this article will only understand the window management of the entire architecture, here is not a detailed explanation, there will be time later may be some more interesting content to look again:

1. Creation and deletion of Windows

2. Window display and hide control

3. Z-order Sequential Management

4. Focus Window Management

5. IME window management and Wallpaper window management

6. Toggle Animations

7. System message collection and distribution,

Next, the user begins to operate on the program interface, the KEYQ thread does not store the user message in the queueevent queue, the Inputdispatcherthread thread extracts the message one by one, and then calls the relevant function in the WMS to process the message. When the WMS discovers that the message belongs to a client window, the corresponding window W interface is called.

The W class is a binder that receives the IPC call from the WMS and passes the call message to Viewroot,viewroot and then passes the message to the UI main thread Activitythread,activitythread parses the message and handles it accordingly. In the client program, the first process of the message is Decorview, if decorview do not want to process the message, you can pass the message to its inner child view or viewgroup, if not processed, passed to Phonewindow, Finally, it is passed to the activity.

What threads are in an app?

First, we all know that the UI thread, the user interaction thread, is used to handle user messages and interface drawing;

Second, each Binder object corresponds to a thread, and in Activitythread it creates applicationthread, all of which are inherited binders, where two threads are started;

So the minimum should be 3 threads ..... The developer then customizes the child threads ..... Cond.

Android app run process (GO)