Android application window (activity) window object (window) creation guide

In the previous article, we analyzed the creation process of the running context environment of the Android application window. Therefore, each activity component has an associated contextimpl object, and it is also associated with a window object to describe a specific application window. From this, we can see that activity is just a highly abstract UI component, and its specific UI implementation is actually implemented by a series of other objects. In this article, we will analyze the creation process of Android application window object in detail.

From the previous article on the brief introduction of the Android application window (activity) implementation framework and the learning plan, we can know that on the phone platform, the actual type of the window object associated with the activity component is phonewindow, which is inherited from the window class. For the relationship between the three classes of activity, window and phonwwindow, please refer to figure 3 and figure 5 in the brief introduction of Android application window implementation framework and learning plan. In order to facilitate the next description of the creation process of an application window of type phonewindow, we take these two figures, as shown in Figure 1 and Figure 2 below:

Figure 1 class relationship between activity and window

Figure 2 class relationship between window and phonewindow

For the description of the classes involved in the above two figures, please refer to the brief introduction and learning plan of Android application window implementation framework. This paper mainly understands the relationship between activity, window and phonwwindow from the creation process of Android application window.

From the analysis of the creation process of the running context of the Android application window (activity), we can know that a phonewindow object associated with the activity component is created from the member function attach of the activity class, as shown in Figure 3:

Figure 3 creation process of Android application window

This process can be divided into 9 steps. Next, we will analyze each step in detail.

Step 1. Activity.attach

We have analyzed the implementation of this function in the previous article analysis of the creation process of the running context environment of Android application window (activity). Here, we only focus on the code related to the creation of application window.

Function first calls the static member function makenewwindow of policymanager class to create an application window of type phonewindow, which is saved in the member variable mwindow of activity class. With this application window of phonewindow type, the function will call its member functions setcallback, setsoftinputmode and setwindowmanager to set the window callback interface, the display mode of the soft keyboard input area and the local window manager.

The member functions setcallback, setsoftinputmode and setwindowmanager of the phonewindow class are inherited from the parent class window. Therefore, next, we will continue to analyze the static member function makenewwindow of the policymanager class and the implementation of the member functions setcallback, setsoftinputmode and setwindowmanager of the window class.

Step 2. PolicyManager.makeNewWindow

Policymanager is a window management policy class. When it is used for the first time, it will create a policy class instance and save it in the static member variable spolicy. Later, the window management policy of policymanager class is implemented through this policy class instance, for example, The static member function makenewwindow of the policymanager class creates a specific application window by calling the member function makenewwindow of the policy class instance.

Next, we will continue to analyze the implementation of makenewwindow, a member function of the policy class.

Step 3. Policy.makeNewWindow

The implementation of the member function makenewwindow of the policy class is very simple. It just creates a phonewindow object and returns it to the caller.

Next, we will continue to analyze the implementation of the constructor of the phonewindow class so that we can understand the creation process of an application window of type phonewindow.

Step 4. new PhoneWindow

The constructor of the phonewindow class is very simple. It first calls the constructor of the parent class window to perform some initialization operations, and then calls the static member function from of layoutinflator to create a layoutinflator instance and save it in the member variable mlayoutinflator. In this way, the phonewindow class can later create a view of the application window through the member variable mlayoutinflator, which is described by the member variable mdecor of type decorview. The phonewindow class also has another member variable mcontentparent of type ViewGroup, which is used to describe a view container. This container stores the contents of the view described by the member variable mdecor, but this container may also point to mdecor itself. In the following article, we will analyze in detail the creation process of the view of the application window of type phonewindow.

The constructor of window is defined in the file frameworks / base / core / Java / Android / view / window.java. Its implementation is very simple, but its member variable mcontext is initialized, as shown below:

After this step is completed, return to the previous step 1, that is, the member function attach of the activity class. Next, we will continue to call the member function setcallback inherited from the parent class window of the phonewindow object created earlier to set the window callback interface. Therefore, next, we will continue to analyze the implementation of the member function setcallback of the window class.

Step 5. Window.setCallback

The activity component being started will set a callback interface implemented by it to the member variable mcallback of the parent window of a phonewindow object associated with it. In this way, when the phonewindow object receives IO input events distributed by the system, such as keyboard and touch screen events, it will be forwarded to the activity component associated with it for processing, For this point, refer to the previous article on the analysis of message processing mechanism of Android application keyboard.

After this step is completed, return to the previous step 1, that is, the member function attach of the activity class. Next, continue to call the member function setsoftinputmode inherited from the parent class window of the previously created phonewindow object to set the display mode of the soft key disk input area of the application window. Therefore, Next, we will continue to analyze the implementation of the member function setsoftinputmode of the window class.

Step 6. Window.setSoftInputMode

The parameter mode has soft_ INPUT_ STATE_ UNSPECIFIED、SOFT_ INPUT_ STATE_ UNCHANGED、SOFT_ INPUT_ STATE_ HIDDEN、SOFT_ INPUT_ STATE_ ALWAYS_ HIDDEN、SOFT_ INPUT_ STATE_ Visible and soft_ INPUT_ STATE_ ALWAYS_ Visible has six values in total, which are used to describe the display mode of the soft keyboard input area of the window. Their meanings are as follows:

1. SOFT_ INPUT_ STATE_ Unspecified: the display status of the soft keyboard input area is not specified.

2. SOFT_ INPUT_ STATE_ Unchanged: do not change the display state of the soft keyboard input area.

3. SOFT_ INPUT_ STATE_ Hidden: hide the soft keyboard input area when appropriate, for example, when the user navigates to the current window.

4. SOFT_ INPUT_ STATE_ ALWAYS_ Hidden: always hide the soft keyboard input area when the window gets focus.

5. SOFT_ INPUT_ STATE_ Visible: displays the soft keyboard input area when appropriate, for example, when the user navigates to the current window.

6. SOFT_ INPUT_ STATE_ ALWAYS_ Visible: when the window gets focus, the soft keyboard input area is always displayed.

When the value of the parameter mode is not equal to soft_ INPUT_ STATE_ When unspecified, it means that the current window is assigned the display mode of the soft keyboard input area. At this time, the member function setsoftinputmode of window class will set the value of the member variable mhassoftinputmode to true, and save the display mode in the member variable softinputmode of a windowmanager.layoutparams object used to describe the window layout properties. Otherwise, The value of the member variable mhassoftinputmode is set to false.

After setting the display mode of the soft keyboard input area of the window, if the member variable mcallback of the window class points to a window callback interface, the member function setsoftinputmode of the window class will also call its member function onwindowattributeschaved to notify the activity component associated with the window that its window layout attribute has changed.

After this step is completed, return to the previous step 1, that is, the member function attach of the activity class. Next, continue to call the member function setwindowmanager inherited from the parent class window of the previously created phonewindow object to set the local window manager of the application window. Therefore, Next, we will continue to analyze the implementation of the member function setwindowmanager of the window class.

Step 7. Window.setWindowManager

The parameter apptoken is used to describe which activity component the currently processing window is associated with. It is a binder proxy object and references a binder local object of type activityrecord created on the activitymanagerservice side. From the previous brief introduction to the activity startup process of Android application and a series of articles on learning plan, we can know that each started activity component has a corresponding activityrecord object on the activitymanagerservice side to describe the running state of the activity component. The binder proxy object will be saved in the member variable mapptoken of the window class, so that the currently processing window can know what the activity component associated with it is.

The parameter appName is used to describe the name of the activity component associated with the currently processing window. This name will be saved in the member variable mappname of the window class.

The parameter WM is used to describe a window manager. As can be seen from the previous call process, the value of the parameter WM passed in here is equal to null. Therefore, the function will first call the static member function getdefault of windowmanagerimpl class to obtain a default window manager. With this window manager, the function then uses it to create a local window manager, that is, a localwindowmanager object, to maintain the application window currently being processed.

Next, we first analyze the implementation of the static member function getdefault of the windowmanagerimpl class, and then analyze the creation process of the local window manager, that is, the implementation of the constructor of the localwindowmanager class.

Step 8. WindowManagerImpl.getDefault

The implementation of the static member function getdefault of windowmanagerimpl class is very simple. It just returns a windowmanagerimpl object pointed to by the static member variable mwindowmanager to the caller. This windowmanagerimpl object implements the WindowManager interface. Therefore, it can be used to manage application windows.

After this step is completed, return to the previous step 7, that is, the member function setwindowmanager of the window class. Next, a windowmanagerimpl object obtained earlier will be used to create a local window manager, that is, a localwindowmanager object.

Step 9. new LocalWindowManager

The constructor of the localwindowmanager class first saves a windowmanagerimpl object described by the parameter WM in its member variable mwindowmanager, so that it can handle the window management later.

The constructor of the localwindowmanager class then obtains a display object through the member function getdefaultdisplay of a windowmanagerimpl object described by the member variable mwindowmanager to describe the system screen properties.

Since the previously obtained display object describes global screen properties, and the currently processing window may be configured with some customizable screen properties, the constructor of localwindowmanager class needs to further adjust the screen properties described by the previously obtained display object so that they can be used for the currently processing window. The constructor of the localwindowmanager class first obtains a resources object through the member function getresources of the member variable mcontext of the external class window, and then calls the member function getdefaultdisplay of the resources object to adjust the screen properties described by the previously obtained display object. The final adjusted display object is saved in the member variable mdefaultdisplay of the localwindowmanager class.

As you can see from step 4 above, the member variable mcontext of class window describes an activity component associated with the current window. The member function getresources of activity class continues from the parent class contextwrapper. It is implemented in the file frameworks / base / core / Java / Android / content / contextwrapper.java, as shown below:

So far, we have analyzed and completed the creation process of the application window object associated with an activity component. From the analysis process, we can know:

1. The type of application window object associated with an activity component is phonewindow.

2. The application window of phonewindow type is maintained through a local window manager of localwindowmanager type.

3. The local window manager with the type of localwindowmanager maintains the application window through a window manager with the type of windowmanagerimpl.

4. The application window with phonewindow type has a view object with decorview type inside, which is really used to describe the UI of an activity component.

In the next article, we will continue to analyze the creation process of view objects inside the application window. Please pay attention!