Android core analysis (13)-android GWES-android Window Management

Document directory

• 2.2 focus path
• 2.3 viewroot, Window Manager Proxy

Android GWES-android Window Management 1 basic architecture principle

Windows Management for Android is in C/S mode. Windows in Android indicates top-level windows and other top-level windows. Decorview is the top-level view of the window. This view is called the main view. decorview will attach it to the main window of the activity by default. The primary view is added to windowmanager, and WM uses windowstate to correspond to the primary view.

After a main window is created for the activity, when adding the main window to windowmanager, you must first create a windowmanager proxy object, open a session (implementing the iwindowsession aidl Interface), and maintain the session. Activity will establish a connection with windowmanager through this session. This session is the basis of the C/S system, and the client adds the window to window manager through windowsession.

A complete window concept spans the view, viewroot, and windowmanager service. The relationships between windows, decorview, view, iwindow, isession, and windowstate are as follows:

The Client Activity establishes a dialogue with windowmanager through the session, while windowmanager accesses the client through the iwindow interface, passing messages to the client, and passing messages to the onxxx processing function through the message distribution channel.

Later, we will analyze them through the client and WM service respectively.

2 client

I agree that the concept of window in Android is not very important. The window class is only used in phonewindow and midwindow. Phonewindow only processes a specific public event related to mobile phone functions. Therefore, phonewindow is not an abstract concept in Android, it is a special window concept related to the mobile phone system, such as the default Operation Processing of keys and the issuance of key sounds.

2.1 View

View is a really important concept in activity. The following is Google's official definition of view:

This class represents the basic building block for user interface components. A view occupies a rectangular area on the screen and is responsible for drawing and event handling. view is the base class for <em> widgets </em>, which are used to create Interactive UI components (buttons, text fields, etc .). the {@ link android. view. viewgroup} subclass is the base class for <em> layouts </em>, which are invisible containers that hold other views (or other viewgroups) and define their layout properties.

I do not translate the view, but it seems that it is not very good to translate the view into a view. In Android, the view has a wide extension than the view. The view contains user interaction and display. The view only represents static display in the text. View comprehension should begin with the easiest understanding. We have used an editor. In Android, this editor is a view. This editor needs to display text and receive users' keyboard input and mouse selection. However, there are multiple editors on the screen, you need to manage how to manage and how to switch the focus editor.

Client composition: (window, view, viewroot, windowmanager proxy)

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 adds the main window to windowmanager. Of course, it does not add the main window itself, but the decorview of the main window to windowmanager.

The abstract concept of true windows exists in windowstate in view, viewroot, and windowmanger. In order to describe the concept conveniently, I specifically propose the concept of the main view, which is top-level view of the window. the main view and view are right. highlight that the main view is attatch to the main window. The general view is stored in the main view. The main window is actually the top level window mentioned by Android.

The concepts we mentioned: View, groupview, decorview, and viewroot all exist on the client side. Only windowstate exists on the Window Manager Service side.

Decorview is actually a viewgroup. In terms of dependency, for the main window, decorview is the top-level view. view is not the focus of attention. What is important is how we need to know the relationship between distribution paths. The view member variable mparent is used to manage the view parent relationship. Viewgroup, as its name implies, is a group of views, so a focus management and a subview node array are built in viewgroup. In this way, the view direct relationship network in Android is built through the mparent of view and the mchildren of viewgroup.

2.2 focus path

The so-called foucpath is the route passed by our keyevent. Generally, in the main loop, the keyevent is transmitted to the focus view through the focus record relationship of the view. For example, view22 is the focus. We can find the final path from the top view through the mfcous relationship chain, that is, the focus path.

2.3 viewroot, Window Manager Proxy

The core of viewroot and window manager is iwindowsession and iwindow. Viewroot adds a window to window manager through iwindowsession. Iwindow is the channel for window manager to send messages to client viewroot. Use the aidl interface for inter-process communication.

Viewroot is actually a handler. viewroot establishes a bridge between the main view and windowsmanger. Viewroot is essentially a handler. We know that the basic function of handler is to process callback and send messages.

Activity obtains windowmanagerimpl using getsystemservice and creates a windowmanagerimpl instance, that is, the proxy of the Window Manager Service:

WM = (windowmanagerimpl) Context. getsystemservice (context. window_service); Call WM. addview to add a window to wmservice.

What kind of management framework is established in this process on the client and how is this session? In the window manager proxy, the corresponding relationship tables of view, layout, and viewroot are created. Constructing a viewroot will open a session and use iwindowsession to establish the session context.

4 Window Manager Service

This research on the window manager service is limited to the focuswindow and message system. The other sections will be discussed in the following special sections.

The window managed by window manager is the top-level window of the application. Here I refer to the window concept as the main window. Why is the main window managed on the Service side? Why not put it on the client side? The main window is put together for management to calculate the Z-order sequence and display the window of the application based on the application status. I think Android designers must consider the following first when designing the window system:

• Window Z-order management
• Calculation of the activity window and notification of changes
• Window owner (which application belongs)
• Input Method management

Window service basically implements the following functions :,

(1) maintenance functions of Z-ordered

(2) Input Method management

(3) addwindow/removewindow

(4) layerout

(5) token management, apptoken

(6) Activity window management (focuswindow)

(7) activity Application Management (focusapp)

(8) Transfer Animation

(9) system message collection thread

(11) system message distribution thread

The window object on the server is called windowstate. 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>.

Windowstate has a member variable called mclient to record the client's iwindow instance. Through the iwindow interface instance, the service can access the client's information, saying that iwindow is a service that connects to the view bridge.

(1) how to calculate the focuswindow activity window?

The basic principle is to find the foreground application (fousactivity) and find the main window that belongs to the fousactivity (apptoken) in the Z-order. This window is the calculated focus window.

(2) Why should we propose the token concept?

When an application needs to manage its own window, how to identify the window as an activity is proposed by the andoid designer. Description of apptoken: <token: ibinder, allwindows>. Use the token to find allwindows that belongs to the token. Use token to display and hide all windows of the application.

(3) system message Collection and Processing

We will focus on the system message collection mode and distribution mode in the service. The Service uses keyq as a dedicated message queue.

• Keyevent
• Touchevent
• Trackballevent

The system has two threads:

The keyq thread uses the navite function readevent to poll the device and place the read results in the keyq queue.

The system dispatcher is waiting on the keyq message queue. Once a message is obtained from the message queue, it is transmitted to the client through the distribution function through mclient.