[Android deep learning] Android Window Management Mechanism

When learning the windowmanager interface, I learned that this interface is very important because it can directly interact with the window manager. What exactly is this window manager?

By searching for information, I know that window manager is actually a service ). It is globally unique in the system and is independent from Android applications. All Android applications share a separate C ++ service. (For this "separate C ++ service", we recommend that you first look at the introduction of the android concept space and sevicemanager)

 

1. Basic architecture principle

To understand this service, we must first have an understanding of the basic architecture principles of Android.

Android is based on the C/S mode. In our deep-rooted idea, the C/S architecture means that the client and the server directly exchange data through the binder, open the binder to write data, read data through the binder, and the communication can be completed. For example:

 

 

However, in the concept of Android, binder is a very low-level concept and a binder communication mechanism provided by the Linux kernel. The above layer does not see the binder at all, but the objects of activity and a service are directly called through methods to obtain the service.

This is an external feature provided by Android: In Android, to complete an operation, you need to request a competent service object to complete the action, you don't need to know how the communication works and where the service is located. Therefore, the andoid IPC (inter-process communication) is essentially an Object Request proxy architecture (the Object Request proxy architecture: CORBA ). That is to say, it not only solves the problem of inter-process communication, but also is an architecture that puts forward a design concept.

 

Since the essence of Android IPC is CORBA, let's analyze it.

【CORBA]

A standard object-oriented application system specification developed by OMG, or the CORBA architecture is an object management organization (OMG) to address the distributed processing environment (DCE, A solution proposed by connecting hardware and software systems.

CORBA defines a series of APIS, communication protocols, and object/service information models used to allow heterogeneous applications to operate on each other. These applications are written in different programming languages, run on different platforms. Therefore, CORBA provides platform and location transparency for clearly defined objects, which are the basis of distributed computing platforms.

The Cobra standard consists of three levels: Object Request proxy, public object service, and public facilities. ORB (Object Request proxy) is the core at the bottom layer ).

Orb specifies the definition (Interface) and language ing of distributed objects to achieve communication and interoperability between objects. It is a "Soft Bus" in the distributed object system "; many public services are defined on ORB and can provide various services, such as concurrent services, name services, transaction services, and security services; the upper-level public facilities define a component framework to provide services that can be directly used by business objects and define the agreed rules required for effective collaboration between business objects.

[Orb]

Orb is a medium component that establishes customer/Server contact between objects. With orb, the customer can call the server's objects or applications in the objects. The called objects do not need to be on the same machine. Orb is responsible for communication, And Orb will return results after the call object is complete. The customer object can ignore the location of the server object, implement the specific technology it uses and work on the hardware platform, and even do not have to care about the Server Object's service-independent interface information, this greatly simplifies the work of the customer program. Since it is so convenient, ORB needs to provide communication between applications on different machines, data conversion, and seamless connection between multi-object systems.

The essence of CORBA is shown in the form of an image as follows:

There are multiple proxies on the server:

 

After analyzing the basic theoretical architecture of CORBA, let's take a look at it.Android object proxy Structure:

 

In the structure diagram, we can clearly understand that the android IPC contains the following concepts:

• Contextobject)

The device context contains context information about the operation that is not passed as a parameter in the client, environment, or request. The application developer uses the operations defined on the contextobject interface to create and operate the context.

• Android Proxy: this refers to the proxy object of the server on the client.
• Binder: The binder communication mechanism (underlying) provided by the Linux Kernel)
• Aidl: remote interface in Android

The external feature space of Android does not need to know where the service is located, as long as the request is completed through the proxy object.

 

 

2. Window Management Overview

After learning about the basic architecture of Android, let's go back to window management.

The window management of Android is based on the C/S mode, the client is the application, and the server is the Window Manager service. For example:

 

After the activity creates a main window and adds the main window to window manager, it first establishes a proxy object for Window Manager and opens a session (Session: Session; implements the iwindowsession aidl interface ), and maintain the session (the activity will establish a connection with Window Manager through this session, which is the basis of the C/S system ). The client adds the window to the window manager through this session.

A complete window concept includes view, viewroot, Window Manager Service, window, decor view, iwindow, isession, and windowstate. The relationships between them are as follows:

 

The activity at the client end establishes a dialogue with the Window Manager Service through the iwindowsession, while the Window Manager Service accesses the client through the iwindow interface to transmit messages to the client end. In the message distribution channel, transmits a message to a specific message processing function. (User input and other operations are first sent to the window management service, which is sent to the activity window and then delivered to the focus step by step ).

 

 

3. Client

 

Client composition:

Window, view, viewroot, Window Manager Proxy

 

View:

View includes interaction and display in Android.

When executing mlaunchactivity, activity. Attach () is used to create a phonewindow main window. The establishment of this main window is not a key point. When handleresumeactivity really wants to start an activity, it will add the main window to the window manager. Of course, it is not the main window itself, but the decorview of the main window.

Decorview: it is actually a viewgroup. In terms of dependency, for the main window, decorview is the top-level view. For example:

 

The view member variable mparent is used to manage the view parent relationship. In viewgroup, focus management and subview node arrays are built. In this way, the view direct relationship network in Android is built through the mparent of view and the mchildren of viewgroup. For example:

 

 

 

Focus path

The so-called foucpath is the route passed by our keyevent. Generally, our keyevent is in the main loop, and the main view is transmitted to the focus view through the focus record relationship of the view. For example, view22 is the focus, and the top-level view finds the final path through the relationship chain of mfoucs, that is, the foucs path. As shown in the red line:

 

 

 

Viewroot

• Viewroot is actually a handler. The main view of viewroot communicates with windowsmanager.
• Viewroot is essentially a handler. We know that the basic function of handler is to process callback and send messages.

Viewroot adds a window to window manager through iwindowsession aidl, while iwindow aidl is the channel for window manager to send messages to client viewroot.

 

 

 

Window Manager Proxy

When the activity uses getsystemservice to obtain windowmanagerimpl, it creates a windowmanagerimpl instance, which is the proxy of the Window Manager service.

WM = (windowmanagerimpl) Context. getsystemservice (context. window_service );

And call WM. addview to add the window to wmservice.

In this process, what kind of management framework does the client establish and how does one perform this session?

In the Window Manager Proxy, a corresponding table with views, layout, and viewroot scattered is created. Constructing a viewroot will open a session and use the iwindowsession resume session context. For example:

 

 

 

4. server ---- Window Manager Service

Window Manager Service Management window is the top-level window of the application, which is called the main window. Why should the main window be managed by service? In fact, it is managed together to calculate the Z-order sequence and display/hide the Application Window Based on the application status.

A mwindow array is maintained in service. This mwindow is the Z-order array of window. Mwindowmap is used to record <client: binder, windowstate Object>.

The window object on the server is called windowstate. Windowstate has a member variable called mclient to record the client iwindow instance. Through the iwindow interface instance, the service can access the client information and transmit messages to the client. So iwindow is a bridge between service and view.

 

Http://blog.sina.com.cn/s/blog_4b3c1f950100qe9m.html

Transferred from: