android Window Management Service Windowmanagerservice Brief introduction and Learning Plan

In the previous series, we analyzed the implementation framework of the Android application window from an individual perspective. In fact, if we look at the overall point of view, the implementation of the Android application window is more complex, because they are of different types and roles, and they affect each other. In an Android system, managing all windows in the system is the responsibility of the Window Management Service Windowmanagerservice. In this article, we will briefly describe the functions of windowmanagerservice and develop a learning plan.

We know that in Android, only one activity window is active at the same time, but for the Windowmanagerservice service, that doesn't mean it needs to manage only one activity window at a time, for example, During the switching process of the two activity windows, the front and back two activity windows are actually visible. Even when only one activity window is visible, the Windowmanagerservice service still needs to manage multiple windows at the same time, because the visible activity window may also be set up with the wallpaper window (wallpaper WINODW) either pops up the Subwindow (sub window), and the status bar may appear, as well as the Input Method window (Input method Windows), as shown in 1.

Figure 1 Location structure of the Activity window and its child windows, Wallpaper window, IME window, and status bar

Therefore, the Windowmanagerservice service is not allowed to assume that at the same time it only needs to manage a window, which needs to be determined by the position and size of each window on the screen to determine which Windows need to be displayed and where to display them, which is actually to calculate the visible area of each window.

The process analysis of rendering the application UI from the Surfaceflinger service in front of the Android surface mechanism shows that the Surfaceflinger service calculates the visibility of each window when rendering the UI of the entire screen, so The Windowmanagerservice service simply tells the Surfaceflinger service the location and size of the various Windows it manages, which can help it figure out the visible areas of each window. Note here that the window position mentioned here includes the position of the window in the X, y, and Z axes.

The Windowmanagerservice service roughly controls which Windows need to be displayed and where they are to be shown, in the following ways:

1. Each activity window is equal to the size of the screen, so as long as you set a different z-axis position for each activity window, you can then make it visible on the topmost, the active activity window.

2. The z-axis position of each subwindow is larger than its parent window, but smaller than the parent window, at which time the Activity window and its popup child windows can be displayed simultaneously.

3. For a non-full-screen activity window, it leaves an area above the screen to display the status bar. The area that is left out is called the decorative area (decoration) for the screen, and for the Activity window, the content Inset.

4. The Input Method window appears only when needed, and it also appears in the decorative area of the screen or in the content side of the Activity window.

5. For the wallpaper window, it appears below the activity window that needs the wallpaper, which requires the activity window to be translucent so that it can be displayed together with the wallpaper window behind it.

6. Two Activity window in the process of switching, in fact, the previous window shows the exit animation and then a window shows the process of starting animation, and in the animation display process, the window size will have a change process, so that the size of the front and back two activity window is no longer equal to the size of the screen, As a result, they may be in a state of visibility at the same time. In fact, the switching process of the activity window is quite complex, as the activity window that is about to be displayed may also be set up with a startup window (starting Windows). An activity window with a startup window set will not be displayed until its startup window is displayed.

From the above six points, it can be seen that the position of the window in the X, Y and Z axes and the size of the calculation is very important, they together determine whether a window is overall visible, or partially visible, or the whole is not visible. In the Android system, the Windowmanagerservice service calculates the position and size of a window by a policy class that implements the Windowmanagerpolicy interface. For example, on the phone platform, this strategy class is phonewindowmanager. The advantage of this is that different policy classes are implemented for different platforms to achieve different window control modes.

As you can see from the above description, the Windowmanagerservice service, in addition to interacting with the application process that the Activity window is running in, You also need to interact with the Surfaceflinger Service and the Window management policy class Phonewindowmanager, as shown in 2.

Figure 2 Diagram of Windowmanagerservice Service with Activity window, Surfaceflinger service, Phonewindowmanager policy

In a series of articles in the previous Android application window (Activity) Implementation Framework brief introduction and Learning Plan, we have analyzed the interaction between the application process and the Windowmanagerservice service, so in this series of articles, We will primarily analyze the implementation of the Windowmanagerservice service and its interaction with Surfaceflinger services, Phonewindowmanager policy classes.

In general, the implementation of the Windowmanagerservice service is quite complex, for example, the core member function of the Windowmanagerservice class The Performlayoutandplacesurfaceslockedinner code has a 1200+ line, which is more frightening than the core member function Performtraversals of the 600-line code Viewroot class. However, the complexity of the Windowmanagerservice service implementation is expected, after all, that it manages the UI of all windows of the entire system, whereas in any system, the window management subsystem is extremely complex. Based on the above reasons, the use of a head-to-head approach to the analysis of Windowmanagerservice service implementation is Ishing, so this series of articles will be Windowmanagerservice services to split, and then break each other, This is the idea of divide and conquer in the algorithm is consistent.

Specifically, we will analyze the implementation of the Windowmanagerservice service in several scenarios:

1. Calculation of window size and position (x-axis and y-axis).

2. How the window is organized.

3. The adjustment process of the Input Method window.

4. The adjustment process of the wallpaper window.

5. The calculation and adjustment process of the z-axis position of the window.

6. The display process of the Activity window's Startup window.

7. The Activity window switching process.

8. Animate the Activity window to display the process.

Again, because the implementation of the Windowmanagerservice service is too complex, the above eight scenarios may not be enough to illustrate the implementation of the Windowmanagerservice service. If this happens, we will make the appropriate adjustments during the analysis. Believing in the divide-and-conquer analysis of the implementation of Windowmanagerservice services, we can have a deep understanding of the UI architecture of the Android system! Stay tuned for the next article!

Lao Luo's Sina Weibo: Http://weibo.com/shengyangluo, welcome attention!

android Window Management Service Windowmanagerservice Brief introduction and Learning Plan