Analysis of Android Window Management

Android Window Management

 

I,Overview

In the Android system, from the design point of view, the window management system is based on the C/S mode. The entire window system is divided into two parts: the server and the client. The client is responsible for requesting to create and use Windows, and the server completes window maintenance and window display.

 

On the client side, it does not directly interact with windowmanagerservice, but directly interacts with the local object windowmanager. Then, windowmanager interacts with windowmanagerservice. For Android applications, this interaction is transparent and applications cannot perceive the existence of windowmanagerservice.

 

II,Window Definition

In the Android Application Framework, there are two types of Windows:

The first is the application window: An activity has a main window, And the pop-up dialog box also has a window. The menu is also a window. In the same activity, the main window, dialog box, and menu window are associated with the activity. The application-related window representation classes are phonewindow and window. phonewindow inherits from window and is optimized for mobile phone screens. Phonewindow is just a window encapsulation class. The core of the class is the mdecorview variable. mdecorview is a top-level view. The addition of a window is to call getdecorview () to obtain mdecorview and call windowmanager. addview () adds the view to windowmanager.

The second type is public interface windows, such as the recently run dialog box, shutdown dialog box, status bar drop-down Bar, and screen lock interface. These windows are system-level windows, which do not belong to any application and have no relationship with activity. This type of window is not encapsulated by any window class. You can directly call windowmanager. addview () to add a view to windowmanager.

During app initialization, an activity object is first formed. At this time, this activity does not belong to another window. Then, by calling the attach () function, the activity in the attach () function calls policymanager. makenewwindow () creates a new phonewindow, and then in the oncreate () lifecycle of the activity, the application usually calls setcontentview () to set the display interface of the activity. In setcontentview (), the Framework automatically generates a layout. The layout file contains elements such as the title bar and actionbar. The most important thing is that it contains the contentview of the application. This layout corresponds to the mdecorview in phonewindow. Finally, you can get the decorview through getwindow (). getdecorview () and add the decorview to windowmanager through windowmanager. addview.

Sequence Chart of adding client window in Activity

 

 

3. Window Management

The Windows Management of Android is based on the C/S mode and implemented using independent processes. Window Management Server windowmanagerservice runs in an independent process system_server. When an application needs to create a window, it requests windowmanagerservice to create a window through process communication, windowmanagerservice transmits window-related interactive messages to applications. Windows of all programs are managed on the server, and display and control of windows are processed in windowmanagerservice.

Windowmanagerservice provides the following functions:

1. add and delete windows

2. Display and hide control of Windows

3. Z-order sequential Management

4. Focus window and focus Application Management

5. Input Method window management and wallpaper Window Management

6. Transfer Animation

7. system message collection and distribution

 

The server implementation code is in/framework/base/services/Java/COM/Android/Server/Wm/. The core classes are:

Windowmanagerservice. Java

Windowstate. Java

Windowtoken. Java

Appwindowtoken. Java

Session. Java

Inputmanager. Java

Inputmonitor. Java

 

Class explanation:

Windowmanagerservice is responsible for window management;

Windowstate corresponds to the client window one by one. When the application calls windowmanager. addview (), a windowstate and one of the mappings will be added to windowmanagerservice.

Windowtoken is a handle that stores all windowstates with the same token. When an application requests windowmanagerservice to add a window, a token is provided, which identifies the owner of the window to be added. windowmanagerservice generates a windowtoken object for this token, all windowstates with the same token are associated with the same windowtoken. For example, when the input method is added to the window, a mcurrtoken is passed. When the wallpaper service is added to the window, a newconn. mtoken is passed.

Appwindowtoken is inherited from windowtoken and is used to identify an activity. The token in appwindowtoken actually points to an activity. When the activitymanagerservice notifies the application to start, a token is generated on the server to identify the activity and pass the token to the application client. When the activity of the client applies to add a window, pass the token to windowmanagerservice as the identifier. The main window, dialog box, and menu windows in the same activity are associated with the same appwindowtoken.

Session indicates an interactive session between the client and the server. Generally, different applications interact with windowmanagerservice through different sessions, but different applications in the same process interact with each other through the same session.

Inputmanager and inputmonitor are responsible for the upper-layer message distribution function.

 

Several important member variables in windowmanagerservice:

Arraylist <windowstate> mwindows

Hashmap <ibinder, windowstate> mwindowmap

Arraylist <windowtoken> mtokenlist

Arraylist <appwindowtoken> mapptokens

 

Mwindows saves all windowstates in the system;

Mwindowmap stores the ing between each windowstate and the client window. When the client application requests window operations, It queries the corresponding windowstate through mwindowmap;

Mtokenlist saves all windowtoken

Mapptokens saves all appwindowtoken

 

Main Types of Window Management Server

 

The entire process from the start of an activity to the Add window is as follows:

When activitymanagerservice receives an activity startup request, it first generates a token as the unique identifier of the activity. Then, call windowmanagerservice to add an appwindowtoken to it. This appwindowtoken encapsulates the token of the activity. Then, AMS starts the application client process and passes the token to the process to complete activity initialization in the client process. In the attach () function of the activity, the activity creates a phonewindow and passes the token to phonewindow. When the activity calls windowmanager. addview (), the token is associated with the view in windowmanager. When you actually apply to windowmanagerservice to create a window, the token is passed to windowmanagerservice. When windowmanagerservice receives a request to create a window, it queries the appwindowtoken of the token through mtokenmap. If it is null, an exception is thrown, otherwise, create a windowstate and complete initialization and adjust other data structures. In this process, the token runs through the AMS, WMS of the server, and the activity and window of the client.

 

Create a window sequence chart during activity startup

 

 

4. Interaction interfaces and data structures between the server and the client in WMS

The windowmanager object directly interacts with the application when an application request is created. Windowmanager is just an interface. When addview () is called to create a window, the windowmanagerimpl object is actually interacted. Windowmanagerimpl manages all local windows of a single application. When an application calls addview () to create a window, windowmanagerimpl generates a viewroot object that corresponds to it and saves the corresponding parameter layoutparams.

The execution process of addview () is as follows:

(1) check whether the added window has been added. repeated addition is not allowed;

(2) If the added window is of the subwindow type, find its parent window and save it in internal variables;

(3) create a new viewroot and save the corresponding view (decorview) and layoutparams;

(4) Call the setview () method of viewroot to complete real addition.

 

Viewroot is essentially a handler and implements the viewparent interface. The main functions of viewroot are:

1. Responsible for distributing message events, such as key and motion events;

2. interacts with WMS and distributes WMS interactive commands;

3. As a parent of decorview, perform draw, measure, and layout operations on decorview;

 

After steps 3rd and 4 of addview () are completed, viewroot takes over the interaction with WMS and does not need to perform any interaction. Two-way conversations between viewroot and WMS are mainly performed through the following two data structures:

Iwindowsession

Iwindow

Both data structures are standard aidl interfaces for synchronous communication between processes. Iwindowsession is responsible for one-way requests from viewroot to WMS, while iwindow is used for WMS callback viewroot. Inside the viewroot object, there is a static iwindowsession member and a non-static iwindow member. Therefore, there is only one iwindowsession object in a process, but there can be multiple iwindow objects.

The relationships between windows, windowmanager, decorview, viewroot, iwindowsession, iwindowsession, windowstate, and windowmanagerservice can be expressed as follows:

 

 

In the viewroot constructor, call getwindowsession () to initialize the static member swindowsession and non-static member mwindow. When the setview () method is called in step 2, viewroot calls swindowsession. add () method, add iwindow to WMS, WMS will generate a pair of windowstate and one of them, and save the iwindow object to windowstate as the callback interface. Then all WMS commands will directly access the iwindow interface and distribute them to viewroot in the form of messages. viewroot can complete corresponding processing or decorview operations, or report to WMS through swindowsession.

 

 

A window can be displayed in the following sequence diagram:

 

Window adding process sequence diagram

 

 

 

So far, the overall architecture of the window management system can be expressed as follows:

 

Overall Window Management System Architecture

 

 

 

V. windowstate and Surface

 

The client calls the addview () method of windowmanager to WMS to complete windowstate initialization. During this process, only the creation of a window data structure is completed, that is, until now, the client and server windows have established a relatively fixed connection relationship, and the client and server can communicate normally. WMS can operate the client windows transparently, WMS can also receive client-side window commands and adjust windowstate accordingly.

To display a windowstate on the screen, you must apply for a display cache. The management and maintenance of this display cache are implemented in the underlying graphics module. On the Java layer, there is an encapsulated object surface. After applying for a surface object, windowstate copies the data of the Surface object to the viewroot at the client end. viewroot also maintains a surface object, in fact, these two objects point to the same display cache. With the reference of this display cache, viewroot can obtain the painting canvas through lockcanvas. After the painting is completed, it will refresh the painting content to the display cache through unlockandpostcanvas. That is to say, the client and server Windows share a surface, the client is responsible for drawing the surface content, and the server is responsible for controlling the surface size and position on the screen.

Viewroot sends request commands to WMS through the relayout () interface of iwindowsession, including display and hiding of the window, layout information of the window, such as the location, and receiving WMS processing results. WMS determines the final layout of the window based on the screen size and client request layout parameters. It also returns a valid or invalid surface object based on the display hidden command of the client request. Generally, the display process of a window is as follows:

1. The client request window is displayed and layout parameters are passed;

2. WMS applies for a surface object based on layout parameters and returns it to the client;

3. The client will draw the surface and then notify WMS;

4. WMS displays the surface on the screen and adjusts the surface level accordingly;

 

Window display process sequence diagram

 

The overall concepts of activity, view, viewroot, iwindowsession, iwindow, windowstate, windowmanagerservice, and surface are as follows:

Complete Window Management System Architecture