Android application window (Activity) Implementation Framework brief introduction and Learning Plan

Article reprinted to CSDN community Luo Shenyang's Android tour, original address: http://blog.csdn.net/luoshengyang/article/details/8170307

We studied in the front.SurfaceflingerThe implementation principle of the service. With this foundation, from the beginning of this article, we can analyzeandroid system in java ui achieved. We know that in android The four components of the application, only components and ui related, It describes the application window, so we go through its ui implementation to analyze android system in java ui implementation. This article is mainly to activity UI Implement a brief introduction and develop a learning plan.

The UI implementation of the Activity component requires interaction with the Windowmanagerservice service and the Surfaceflinger service. From the previous Android application keyboard (KEYBOARD) Message processing mechanism analysis article can be known that the activity component after the boot is complete, A Binder object of type Windowmanagerservice is requested to create an object of type WindowState for it to describe its window state. In addition, an overview of the relationship between the Android app and the Surfaceflinger service and a Learning plan this series of articles can be known, The Android application uses a Binder object of type client to request the Surfaceflinger service to create a layer-type object for it to describe its window data.

To request the Surfaceflinger service from an Android application to create a process analysis of your surface you can also know that after the Surfaceflinger service creates an object of type layer for an Android application, it returns a type of Surfacelayer Binder object to the Android application, so that the Android application can use this Binder object to request the Surfaceflinger service to allocate the graphics buffer.

Combining the above information, we can getan interaction model of the A ctivity component with the Windowmanagerservice service and the Surfaceflinger service, as shown in 1:

Figure 1 Interaction model of the activity component with the Windowmanagerservice service and the Surfaceflinger service

In fact, the Surfacelayer object used to correlate the activity component and the Layer object is not created by the Android application requesting the Surfaceflinger service. Instead, it is created by the Windowmanagerservice service Request Surfaceflinger service. After the Windowmanagerservice service gets the Surfacelayer object, it returns a proxy object to the activity component on this side of the Android application. In this way, the activity component and the Windowmanagerservice service can manipulate the layer object on the side of the Surfaceflinger service through the same Surfacelayer object. The purpose of manipulating a layer object is to modify the UI of the activity component.

In front of the Android app with Surfaceflinger Service overview and Learning Plan and the Android system surface mechanism Surfaceflinger Service Brief introduction and learning Plan of these two series of articles, We have analyzed the implementation of the Layer class and the Surfacelayer class on this side of the Surfaceflinger service. In this series of articles, we mainly analyze the implementation of UI-related classes in the activity component on this side of Android applications, as well as the implementation of the WindowState class on the Windowmanagerservice service side.

Let's start by looking at the implementation of the activity component, 2:

Figure 2 Class diagram of the activity component

The activity class inherits from the Contextthemewrapper class, and the Contextthemewrapper class inherits from the Contextwrapper class, Finally, the Contextwrapper class inherits the context class.

From the previous Android application launch process source code Analysis It is known that the activity component during the startup process, the system will create a Contextimpl object for it to describe its running context. The Contextimpl object is first passed to the Acticity component by calling the member function attach of the Acitivity class. They are then sequentially saved in their member variable mbase by calling the member function Attachbasecontext of the parent class Contextthemewrapper and Contextwrapper. Therefore, the member variable mbase of the Contextthemewrapper and Contextwrapper classes is actually a Contextimpl object.

From the previous Android application launch process source code Analysis The article also knows that after the system has created a Contextimpl object for an activity component that is starting, The member function Setoutercontext of this Contextimpl object is also called to save the activity component that is being started in its member variable moutercontext. In this way, an activity component can access a Contextimpl object that describes its running context through its parent class Contextthemewrapper or contextwrapper member variable mbase, and A Contextimpl object can also access its host activity component through its member variable moutercontext.

The activity class also has another member variable of type WindowManager Mwindowmanager, which actually points to a Localwindowmanager object. The Localwindowmanager class is used to manage the application window, for example, to maintain the view inside the application window. The Localwindowmanager class has a member variable of type WindowManager Mwindowmanager, which actually points to a Windowmanagerimpl object. The system obtains a Windowmanagerimpl object by invoking the static member function Getdefault of the Windowmanagerimpl class, and then saves it in the member variable Mwindowmanager of the Localwindowmanager class. In this way, the Localwindowmanager class can really implement the function of managing the application window through the Windowmanagerimpl class.

From the above analysis, we also can not see how the window of an activity component is described. To figure this out, we continue to analyze another member of the activity class, variable mwindow,3, as shown:

Figure 3 Implementation of the window class

The activity class's member Variable Mwindow type is window, which is used to describe an application window. Thus, with this member variable, each activity component will have a corresponding window object, which is a corresponding application windows.

The window class has a member variable mcontext of type context. This member variable points to an Activity object. When the system creates a corresponding window object for an activity component, the context interface of the activity component is saved in the member variable mcontext of the corresponding Window object. In this way, a Window object can access the resources of the activity component it describes through its member variable mcontext.

The window class also has a member variable mcallback of type Window.callback. This member variable, like the member variable mcontext, points to the same activity object because the activity class implements the Window.callback interface. When the system creates a corresponding window object for an activity component, the The Window.callback interface implemented by this activity component is setcallback stored in the member variable mcallback of the corresponding Window object through the member function of the window class. In this way, a window object can pass some events to its corresponding activity component through its member variable Mcallback, for example, handing over the received keyboard event to the corresponding activity component for processing.

Finally, the window class also has a member variable mwindowmanager of type WindowManager. This member variable points to a Localwindowmanager object. As mentioned earlier, the activity component's member variable Mwindowmanager points to a Localwindowmanager object as well. When the system starts an activity component, A Localwindowmanager object stored in its member variable Mwindowmanager is also saved in the member variable of the corresponding Window object through the member function Setwindowmanager of the window class Mwindowmanager 。 In this way, an activity component and its corresponding window object can use the same Localwindowmanager object to manage the UI that they describe.

In fact, the activity class's member variable Mwindow points to not a Window object, but a Phonewindow object. In other words, the UI of an activity component is described using a Phonewindow object.

The activity class's member variable, Mwindow, points to a Phonewindow object that is created by calling the static member function Makenewwindow of the Policymanager class. The implementation of the Policymanager class is shown in 4:

Figure 4 Implementation of the Policymanager class

The Policymanager class has a static member variable of type Ipolicy Spolicy, which actually points to a policy object. The policy class implements the member function Makenewwindow of the Ipolicy interface, and the Policymanager class uses this member function to create a Phonewindow object for an activity component.

The Phonewindow class inherits the window class, so its objects can be saved in the member variable Mwindow of the Activity class. The implementation of the Phonewindow class is shown in 5:

Figure 5 Implementation of the Phonewindow class

The Phonewindow class has two important member variables Mdecor and mcontentparent, and their types are Decorview and ViewGroup respectively. Where the member variable Mdecor is used to describe its own window view, and the member variable mcontentparent is used to describe the view content of the parent window.

The Decorview class inherits the Framelayout class, and the Framelayout class inherits the ViewGroup class, and finally the ViewGroup class inherits the view class. The view class has a member function draw, which is used to draw the UI of the application window. The Decorview class, the Framelayout class, and the ViewGroup class all override the member function draw of the parent class, so that they can customize their own UI.

Whether the application window view described by the Decorview class requires repainting is controlled by another class viewroot. The system creates a Viewroot object for the activity component during the start of an activity component, A view (Decorview) described previously as member variable Mdecor of a Phonewindow object created by this activity component is also saved in the member variable mview of this Viewroot object. In this way, the Viewroot object can draw a acitivity component's UI by calling its member variable Mview, a Decorview member function called draw. The role of the Viewroot class is very large, and it is responsible for receiving IO input events for acitivity components in addition to the UI drawing that controls a acitivity component, such as keyboard events, This can be referred to in the previous Android application keyboard (KEYBOARD) Message processing mechanism analysis article.

The implementation of the Viewroot class is shown in 6:

Figure 6 Implementation of the Viewroot class

The Viewroot class is inherited from the handler class. From the previous Android application message processing mechanism (Looper, Handler) analysis, it is known that subclasses inheriting from the Handler class can call the parent class's member function SendMessage to send messages to the message queue of the specified thread. and to process the message in its own overridden member function Handlemessage. The Viewroot class sends messages in two situations that require a message queue for the main thread of the application process.

The first case is when the Viewroot class receives input events such as keyboards, touchscreens, etc. from the system Input manager InputManager, and it encapsulates these input events into a single message and sends them to the message queue of the main thread of the application process for further processing so that the keyboard, Input events such as touch screens can be processed in the main thread of the application process. This can be referred to in the previous Android application keyboard (KEYBOARD) Message processing mechanism analysis article.

The second case is when the Viewroot class needs to redraw the UI of an activity component associated with it, it encapsulates the action of the drawing UI into a message and is sent to the message queue of the main thread of the application process for further processing. This also ensures that the actions of the drawing UI can be performed in the main thread of the application process.

Each Viewroot object has a member variable mview of type view, which points to a Decorview object. Where does this Decorview object come from? As mentioned earlier, each activity component has a corresponding Viewroot object and a corresponding Phonewindow object, the Decorview object is the member variable Mdecor from this corresponding Phonewindow object. That is, the Viewroot object and the Phonewindow object corresponding to the same activity component are referenced by a total of one Decorview object through their member variables Mview and Mdecor respectively.

Each Viewroot object has a member variable of type Windowmanager.layoutparams mwindowattributes, which points to a Viewgroup.layoutparams object that describes the Viewroot object that corresponds to a UI layout information for the activity component.

As you can see from the above description, each activity component has a corresponding Viewroot object, a View object, and a Windowmanager.layoutparams object. The correspondence between these three objects is maintained by the Windowmanagerimpl class. Specifically, it is maintained by the three arrays described by member variables mroots, mviews, and Mparams of the Windowmanagerimpl class. For example, if an application process runs with two activity components, the size of the three arrays described by the member variables mroots, mviews, and Mparams of the Windowmanagerimpl class is equal to 2, where mroots[0], mviews [0] and mparams[0] correspond to the first activated activity component, while mroots[1], mviews[1], and mparams[1] correspond to the second initiated activity component.

Each Viewroot object has a member variable of type Msurface, which points to the surface object of a Java layer. The surface object of this Java layer mnativesurface with a C + + layer's surface object through its member variables. The surface object of this C + + layer is an instance of the surface class that we analyzed in a series of articles on the relationship between the Android app and the Surfaceflinger service and the Learning Plan. This surface class is used to describe the application window on the side of the Android application process. From the previous Android application Request Surfaceflinger Service Create surface Process analysis article to know that in the C + + layer, each surface object has a corresponding Surfacecontrol object. This corresponding Surfacecontrol object is used to set the properties of the application window, such as setting the size, location, and so on.

However, the surface object in the C + + layer that corresponds to the member variable msurface of the Viewroot class does not have a corresponding Surfacecontrol object, because the Viewroot class does not need to set the properties of the application window. All it needs to do is populate the UI data with the graphics buffer of the application window, which is just the texture of the application window that it needs to set. The texture of the application window is stored in the Java layer's surface class member variable Mcanvas is described in a canvas (canvas), which allows access to the graphics buffer of the application window through this canvas. When the Viewroot class needs to redraw the UI of its corresponding activity component, it calls its member function draw to perform the drawing operation. The member function of the Viewroot class is drawn first by obtaining a piece of canvas that holds its member variable msurface inside, and then passing this canvas to its member variable mview the member function of a View object described by draw. The member function of the view class draw gets the canvas and you can draw the texture of the application window as you like. The drawing of these textures is done through the Skia graphics library API.

So, who manages the properties of the application window? This is managed by the Windowmanagerservice service. As mentioned earlier, the activity component on this side of the Android application is created by the Windowmanagerservice service to request the Surfaceflinger service to create a Layer object as well as a Surfacelayer object. Once this Surfacelayer object is created, the Windowmanagerservice service encapsulates it in a Java layer surface object. You can then request the Surfaceflinger service to set the properties of a corresponding application window through this Java layer's surface object.

Because the Java layer's surface object implements the Parcelable interface, The Windowmanagerservice service creates a Layer object and a Surfacelayer object after requesting the Surfaceflinger service for an activity component. You can return the resulting Java layer's surface object to the activity component across processes. After the activity component gets the surface object, it uses the Surfacelayer object that is stored inside to initialize the surface object of a Java layer as described by the member variable msurface of a Viewroot object that corresponds to it.

So when does the Windowmanagerservice service create a Layer object and a Surfacelayer object for an activity component to request the Surfaceflinger service? The Viewroot class has a static member variable of type iwindowsession swindowsession, which points to actually a binder object that implements the Iwindowsession interface. This binder object is of type session and runs on the Windowmanagerservice service side. When the UI of an activity component is to be drawn for the first time, the application process it runs on will send a request to the Windowmanagerservice service through the static member variable swindowsession of the Viewroot class. After the Windowmanagerservice service receives this request, it then requests the Surfaceflinger service to create a Layer object and a Surfacelayer object for the activity component. In this way, the UI of the activity component is actually drawn on the screen.

At this point, we have completed a brief analysis of the implementation of the UI-related classes of the activity component on this side of the Android application, and then we continue to analyze the implementation of the WindowState class on the Windowmanagerservice service side.

The implementation of the WindowState class is shown in 7:

Figure 7 Implementation of the WindowState class

On the Android application side, each activity component has a corresponding WindowState object on the Windowmanagerservice service side that describes the window state of the activity component. The WindowState class has two important member variables, msession and Msurface, whose types are surfacesession and surface respectively. Next, we'll describe the role of these two member variables.

As mentioned earlier, the activity component asks the Windowmanagerservice service to create a WindowState object for it after the boot is complete. After the WindowState object is created, the Windowmanagerservice service then calls its member function attach to attach a Surfacesession object to it. The member function of the WindowState class is attach to append a Surfacesession object by calling its member variable msession a session object that is described by the members function windowaddedlocked.

The session class has a member variable msurfacesession of type surfacesession. When the member function of the WindowState class attach calls the member function of the session class windowaddedlocked to attach a Surfacesession object to a WindowState object, The latter first checks whether its member variable msurfacesession has pointed to a Surfacesession object. If it is pointed out, then the member function of the session class windowaddedlocked do nothing, otherwise, the session class member function windowaddedlocked will create a Surfacesession object, and is saved in its member variable msurfacesession.

The Surfacesession class has a member variable of type int mclient, which holds the address of a C + + layer's Surfacecomposerclient object, which is the Surfacesession object of each Java layer in C + + The layer has a corresponding Surfacecomposerclient object. When a Surfacesession object is created, the Surfacecomposerclient object associated with it is created at the same time. From the previous connection process analysis of the Android application with the Surfaceflinger service you can tell that the Surfacecomposerclient class is used to describe a connection between the Android application process and the Surfaceflinger service. That is, each UI-related android application process has a Surfacecomposerclient object.

Readers may find it strange that since surfacecomposerclient is used to describe the connection of the Android application process to the Surfaceflinger service, So why does the Windowmanagerservice service create Surfacecomposerclient objects internally? Because Windowmanagerservice needs to request the Surfaceflinger service to set the properties of the Android application window, for example, to set the application window's location, size, and so on, It will need to create a Surfacecomposerclient object for each Android application process to connect to the Surfaceflinger service so that it can communicate with the Surfaceflinger service.

From the above description we can know that in the Windowmanagerservice service, each Android application process should have a Surfacecomposerclient object. Because each Surfacecomposerclient object has a Surfacesession object associated with it, We can infer that every Android application process should have a Surfacesession object in the Windowmanagerservice service. Because the session object that each Surfacesession object belongs to is a binder local object, and its binder proxy object is stored in the static member variable swindowsession of the Viewroot class on this side of the Android application process, so We can infer that every Android application process has a corresponding session object in the Windowmanagerservice service. Together, each Android application process should have a session object, a Surfacesession object, and a Surfacecomposerclient object on the Windowmanagerservice service side. Since each Android application process can run several activity components, we can say that the activity component and the Windowservicemanager service side of the session object, The Surfacesession object and the Surfacecomposerclient object are many-to-one relationships.

After introducing the member variable msession of the WindowState class, we went on to introduce another member variable, Msurface, whose type is surface, which we've already covered on the side of the Android application process. Next we will describe its role on the Windowmanagerservice side.

As mentioned earlier, the Windowmanagerservice service creates an Surfacelayer object internally for each application window, that is, each activity component. This Surfacelayer object is in a surface object that is encapsulated into a Java layer. In the Java layer Surface class, there is a member variable msurfacecontrol of type int, which holds the address value of an Surfacecontrol object in the C + + layer, that is, on the Windowmanagerservice service side, Each Java layer surface object has a corresponding Surfacecontrol object in the C + + layer. Here we emphasize that this side of the Windowmanagerservice service is because, as mentioned earlier, on the Android application side, each activity component corresponds to the Java layer's surface object in C + + The layer is not a corresponding Surfacecontrol object, but a surface object that should have a C + + layer. The Surfacecontrol object of the C + + layer allows you to set the properties of the application window, while the surface object through the C + + layer can set the graphics buffer of the application window, which is the texture of the application window, so We can see that the properties of the application window are set by the Windowmanagerservice service, and the texture of the application window is set by the process in which it resides.

At this point, we have a brief introduction to the implementation framework of the Android application window. The classes and their interactions described above may be ambiguous and difficult to understand. It doesn't matter, then we'll use a series of articles to figure out what's going on:

1. The creation process of the running context of the Android application window, that is, the creation of the Contextimpl;

2. The creation process of the Android application window, that is, the phonewindow process;

3. The creation process of the view of the Android application window, i.e. the Decorview process;

4. The process of connection between Android application window and Windowmanagerservice service, that is, the process of windowstate creation;

5. The connection process between Android application window and Surfaceflinger service, that is, surface creation process;

6. The drawing process of the Android application window, that is, the rendering process of surface;

Learning these articles, we can grasp the implementation framework of the Android application window. Having mastered the implementation framework of the Android application window, we can further learn more about the rendering process of the Android application window. Please pay attention!

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

Android application window (Activity) Implementation Framework brief introduction and Learning Plan