Introduction to the android Window management framework

Window management is a core part of Android. It manages the creation and destruction of windows, layout and size, control of focus, and so on.

Windows can be divided into two categories:

One is the application window, which is a window created by a specific application, which can also subdivide the parent window and the child window. Windows typically correspond to an activity.

One is the system window, such as the status bar, which is created directly by the system through the WindowManager, regardless of the activity.

Here, the concept of the window can actually be said to be composed of three parts, part is used to describe the window information, represented by the WindowState object. A WindowState object corresponds to a window that has the information it needs to draw the window. But really to draw the window requires another part of the content surface to complete, and eventually through the Surfaceflinger to complete the drawing. There is also a part of the processing of the message, windowmanagerservice the window information passed to InputManager, so that Inputdispatcher can be based on the status of the current window message processing.

Let's look at the overall schema and then look at the creation of the two windows. WindowManager, like many other Android services, uses C/s architecture. Where Windowmanagerservice runs in the system_server process, as a server, the client interacts with it through an IPC call.

We use the full application window to create the process to understand this structure and the entire process. We're not going to tangle with some of the minutiae of the code, by looking at the whole and the important things.

I. Client part

At the client, when the application is started, Activitythread invokes the Performlaunchactivity method, instantiates an activity, invokes the Attach method, and transmits many parameter information related to the activity. One of the more important things is a IBinder object token, this token becomes the identification of the activity, Windowmanagerservice can obtain the activity's current running state through this token. In WindowManager, a Windowtoken object is generated through the token, a parent window corresponds to a windowtoken, and all its child windows with the same token are grouped into a windowtoken. That is, if the token are the same, they will all be in one window. There is also a class Appwindowtoken to identify the window, inherited from Windowtoken, which is generated by the token of the activity, and corresponds to activity one by one. By token, you can find the correspondence between the activity and the window.

Looking further down, the attach method instantiates a Phonewindow object via code Mwindow = Policymanager.makenewwindow (this), but the object is more abstract. The Setcontentview method is invoked when the activity begins OnCreate calls. Will go to the previous Phonewindow object corresponding to the Decorview, and finally through the layers of window decoration (status bar, etc.) after the call activity Makevisible method, in the method through the Addiew method to complete the window Add.

WindowManager only provides the interface, uses the bridge pattern, 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. The AddView is about three steps to execute:

1. Verify that the window has been added.

2. Determine the window type if it is a child window, locate the parent window that it is attached to

3.new a Viewrootimpl object that 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 this method, and finally gives the 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 the messages through the message.

See more highlights of this column: http://www.bianceng.cnhttp://www.bianceng.cn/OS/extra/