Analysis of the android window management framework

Window Management is a core content of Android. It manages window creation and destruction, layout and size, and focus control.

Windows can be divided into two types:

One is the application window, that is, the window created by a specific application. In fact, the parent window and child window can be subdivided. A window usually corresponds to an activity.

One is the system window, such as the status bar, which is directly created by the system through windowmanager and has nothing to do with activity.

Here, the concept of a window is actually composed of three parts, one of which is used to describe the window information, represented by the windowstate object. A windowstate object corresponds to a window, which has the information required to draw the window. However, to draw a window, another part of surface is required. surfaceflinger is used to complete the drawing. Another part is message processing. windowmanagerservice transmits window information to inputmanager so that inputdispatcher can process messages based on the status of the current window.

Let's first look at the overall architecture diagram, and then look at the creation of these two windows. Like many other android services, windowmanager uses a C/S architecture. Windowmanagerservice runs in the system_server process and acts as the server. The client calls it through IPC to interact with it.

We use the complete application window creation process to understand this structure and the entire process. We don't need to tangle with the details of the Code, rather than sticking a bunch of code. We can look at the overall and important things.

I. Client

On the client, when the application is started, activitythread will call the initialize mlaunchactivity method to instantiate an activity, call the attach method at the same time, and pass a lot of activity-related parameter information. One of the most important items is an ibinder object token, which becomes the identifier of the activity. windowmanagerservice can use this token to obtain the current running status of the activity. In windowmanager, A windowtoken object is generated through the token. A parent window corresponds to a windowtoken, and all its subwindows with the same token are returned to a windowtoken. That is, if the token is the same, they will all be in a window. There is also an appwindowtoken class used to identify the window, inherited from the windowtoken, which is generated by the token passed by the activity and corresponds to the activity one by one. With Token, you can find the correspondence between activity and window.

The attach method will instantiate a phonewindow object through code mwindow = policymanager. makenewwindow (this), but this object is still abstract. The setcontentview method is called when oncreate is called in the activity. The decorview corresponding to the previous phonewindow object will be obtained, And the makevisible method of activity will be called after layer-by-layer window modification (Status Bar, etc.), and the window will be added through the addiew method in the method.

Windowmanager only provides interfaces and uses the bridge mode. The actual implementation is the windowmanagerimpl class. The object that calls the addiew method comes from localwindowmanager of another class. It performs some simple checks and adds the window through addview of the windowmanagerimp class. Addview is executed in three steps:

1. Check whether the window has been added.

2. Determine the window type. If the window is a child window, find its parent window.

3. Create a viewrootimpl object and call the setview method of the object.

The setview method will eventually call the add method of iwindowsession through IPC. The session class implements this method and finally processes it to windowmanagerservice. The client is now complete.

The viewrootimpl class is actually a handler. Naturally, some of its functions are to process messages and distribute some user operations to the view. It is also a bridge between view and windowmanagerservice. It can be seen that it passes information to windowmanagerservice through a session. Windowmanagerservice also uses the iwindow interface to send commands to viewrootimpl in the form of messages to process these messages.

Ii. Server

The addwindow method of windowmanagerservice mainly handles three parts.

1. Perform some legitimacy verification

2. Build window data

3. Make some adjustments after creating the window.

Let's take a look at the second part. First, a new windowstate class is created, which indicates a window. Combined with windowtoken and appwindowtoken, a complete window content is defined. Create an MPS queue to process the message input. Then call the attach method to create surface-related content for interaction with surfaceflinger. In this way, the entire window is set up. With the windowstate class saving window properties and the token identification of window ownership, you can then draw on the screen through surfaceflinger. Later, inputmanager can also process the transmission between messages and windowmanagerservice. Ensure that the content displayed in the window is consistent with the user operations.

Of course, the windowmanagerservice code close to 10000 lines has completed many functions, because this article will only understand the entire architecture of window management, which is not described here, in the future, we may take a look at some interesting content:

1. Create and delete windows

2. Display and hide control of Windows

3. Z-order sequential Management

4. Focus Window Management

5. Input Method window management and wallpaper Window Management

6. Switch the animation

7. system message collection and distribution

Now, let's take a look at the structural diagram. It should be clear.