Analysis on the process of creating a window for an android application window (activity)

In the previous article, we analyzed the creation process of the runtime Context Environment in the Android Application Window. It can be seen that each activity component has an associated contextimpl object, and it also associates with a window object to describe a specific application window. It can be seen that activity is only 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 in detail the process of creating an Android Application Window object.

From the previous introduction to the implementation framework of the android application window (activity) and the learning plan, we can see that on the phone platform, the actual type of window objects associated with the activity component is phonewindow, the latter is inherited from the window class. For the relationships between the activity, window, And phonewindow classes, see Figure 3 and figure 5 in the implementation framework of the android application window (activity) and the learning plan. To facilitate the subsequent creation of the application window of the phonewindow type, we will 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 descriptions of the classes involved in the above two figures, refer to the introduction to the implementation framework of the android application window (activity) and the learning plan, this article mainly describes the relationship between activity, window, And phonewindow classes from the creation process of the android application window.

You can also find out from the analysis of the creation process of the running Context Environment (context) of the android application window (activity, A phonewindow object associated with the activity component is created from the activity class member function attach, as shown in Figure 3:

Figure 3 creation process of the Android Application Window

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

Step 1. activity. Attach

public class Activity extends ContextThemeWrapper          implements LayoutInflater.Factory,          Window.Callback, KeyEvent.Callback,          OnCreateContextMenuListener, ComponentCallbacks {      ......         private Window mWindow;       ......        final void attach(Context context, ActivityThread aThread,              Instrumentation instr, IBinder token, int ident,              Application application, Intent intent, ActivityInfo info,              CharSequence title, Activity parent, String id,              Object lastNonConfigurationInstance,              HashMap<String,Object> lastNonConfigurationChildInstances,              Configuration config) {          ......            mWindow = PolicyManager.makeNewWindow(this);          mWindow.setCallback(this);          if (info.softInputMode != WindowManager.LayoutParams.SOFT_INPUT_STATE_UNSPECIFIED) {              mWindow.setSoftInputMode(info.softInputMode);          }          ......            mWindow.setWindowManager(null, mToken, mComponent.flattenToString());          ......          }        ......  }  

This function is defined in the file frameworks/base/CORE/Java/Android/APP/activity. java.

In the previous analysis of the creation process of the running Context Environment (context) in the Android Application Window (activity), we have analyzed the implementation of this function, here we only focus on the Code related to application window creation.

The function first calls the static member function makenewwindow of the policymanager class to create an application window of the phonewindow type and stores it in the mwindow member variable of the activity class. With the phonewindow application window, the function then calls 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 phonewindow member functions setcallback, setsoftinputmode, and setwindowmanager are inherited from the parent class window. Therefore, we will continue to analyze the static member function makenewwindow of the policymanager class, and the implementation of setcallback, setsoftinputmode, and setwindowmanager in the window class.

Step 2. policymanager. makenewwindow

public final class PolicyManager {    private static final String POLICY_IMPL_CLASS_NAME =        "com.android.internal.policy.impl.Policy";    private static final IPolicy sPolicy;    static {        // Pull in the actual implementation of the policy at run-time        try {            Class policyClass = Class.forName(POLICY_IMPL_CLASS_NAME);            sPolicy = (IPolicy)policyClass.newInstance();        } catch (ClassNotFoundException ex) {            throw new RuntimeException(                    POLICY_IMPL_CLASS_NAME + " could not be loaded", ex);        } catch (InstantiationException ex) {            throw new RuntimeException(                    POLICY_IMPL_CLASS_NAME + " could not be instantiated", ex);        } catch (IllegalAccessException ex) {            throw new RuntimeException(                    POLICY_IMPL_CLASS_NAME + " could not be instantiated", ex);        }    }    ......    // The static methods to spawn new policy-specific objects    public static Window makeNewWindow(Context context) {        return sPolicy.makeNewWindow(context);    }    ......}

This function is defined in the file frameworks/base/CORE/Java/COM/Android/Internal/policy/policymanager. java.

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

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

Step 3. Policy. makenewwindow

public class Policy implements IPolicy {    ......    public PhoneWindow makeNewWindow(Context context) {        return new PhoneWindow(context);    }     ......}

This function is defined in the file frameworks/base/policy/src/COM/Android/Internal/policy/impl/policy. java.

The makenewwindow Implementation of the Policy class member function is very simple. It only creates a phonewindow object and returns it to the caller.

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

Step 4. New phonewindow

public class PhoneWindow extends Window implements MenuBuilder.Callback {    ......    // This is the top-level view of the window, containing the window decor.    private DecorView mDecor;    // This is the view in which the window contents are placed. It is either    // mDecor itself, or a child of mDecor where the contents go.    private ViewGroup mContentParent;    ......    private LayoutInflater mLayoutInflater;    ......    public PhoneWindow(Context context) {        super(context);        mLayoutInflater = LayoutInflater.from(context);    }    ......}

This function is defined in the file frameworks/base/policy/src/COM/Android/Internal/policy/impl/phonewindow. java.

Phonewindow constructor 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 of layoutinflater to create a layoutinflater instance, and stored in the member variable mlayoutinflater. In this way, the phonewindow class can be used to create a view of the application window through the member variable mlayoutinflater, which is described by the member variable mdecor of the decorview type. The phonewindow class also has another member variable mcontentparent of viewgroup to describe a view container, which stores the View content described by the member variable mdecor, however, this container may also point to mdecor itself. In the subsequent article, we will analyze in detail the process of creating a view of the application window of the phonewindow type.

The window constructor is defined in the file frameworks/base/CORE/Java/Android/View/window. java. Its implementation is very simple, but it initializes its member variable mcontext, as shown below:

public abstract class Window {    ......    private final Context mContext;    ......    public Window(Context context) {        mContext = context;    }      ......}

We can see from the previous call process that the context parameter describes the starting activity component and stores it after the mcontext member variable of the window class, the window class can be used to access resources related to the activity component.

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

Step 5. Window. setcallback

public abstract class Window {    ......    private Callback mCallback;    ......    /**     * Set the Callback interface for this window, used to intercept key     * events and other dynamic operations in the window.     *     * @param callback The desired Callback interface.     */    public void setCallback(Callback callback) {        mCallback = callback;    }      ......}

This function is defined in the file frameworks/base/CORE/Java/Android/View/window. java.

The starting activity component sets a callback interface implemented by it to the mcallback member variable of the parent class window of a phonewindow object associated with it, in this way, when the phonewindow object receives the IO input events distributed by the system to it, such as keyboard and touch screen events, it is forwarded to the associated activity component for processing, for more information about this, see the previous analysis of the Message Processing Mechanism on the keyboard of the android application.

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

Step 6. Window. setsoftinputmode

public abstract class Window {    ......    private boolean mHasSoftInputMode = false;    ......    public void setSoftInputMode(int mode) {        final WindowManager.LayoutParams attrs = getAttributes();        if (mode != WindowManager.LayoutParams.SOFT_INPUT_STATE_UNSPECIFIED) {            attrs.softInputMode = mode;            mHasSoftInputMode = true;        } else {            mHasSoftInputMode = false;        }        if (mCallback != null) {            mCallback.onWindowAttributesChanged(attrs);        }    }    ......}

This function is defined in the file frameworks/base/CORE/Java/Android/View/window. java.

The mode parameter has six values, namely begin, soft_input_state_unchanged, soft_input_state_hidden, hidden, soft_input_state_visible, and hidden, to describe the display mode of the keyboard input area of the window. Their meanings are as follows:

1.Soft_input_state_unspecified: The display status of the keyboard input area is not specified.

2.Soft_input_state_unchanged: Do not change the display status of the keyboard input area.

3.Soft_input_state_hidden: Hide the keyboard input area when appropriate, for example, when the user is navigating to the current window.

4.Soft_input_state_always_hidden: When the window gets the focus, the keyboard input area is always hidden.

5.Soft_input_state_visible: Display the keyboard input area when appropriate, for example, when the user is navigating to the current window.

6.Soft_input_state_always_visible: When the window gets the focus, the keyboard input area is always displayed.

When the value of mode is not equal to soft_input_state_unspecified, it indicates the display mode in the input area of the specified keyboard in the current window, in this case, the member function setsoftinputmode of the window class sets the value of the member variable mhassoftinputmode to true, and saves the display mode to a windowmanager that describes the window layout attribute. the member variable softinputmode of the layoutparams object. 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 window member variable mcallback points to a window callback interface, setsoftinputmode, a member function of the window class, also calls its member function ondeskwattributeschanged to notify the activity component associated with the window. Its window layout attribute has changed.

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

Step 7. Window. setwindowmanager

public abstract class Window {    ......    private WindowManager mWindowManager;    private IBinder mAppToken;    private String mAppName;    ......    public void setWindowManager(WindowManager wm,            IBinder appToken, String appName) {        mAppToken = appToken;        mAppName = appName;        if (wm == null) {            wm = WindowManagerImpl.getDefault();        }        mWindowManager = new LocalWindowManager(wm);    }    ......}

This function is defined in the file frameworks/base/CORE/Java/Android/View/window. java.

The apptoken parameter is used to describe the activity component associated with the window being processed. It is a binder proxy object, A local binder object of the activitymanagerservice type activityrecord is referenced. A series of articles about the activation process and learning plan of the previous Android app activity show that each started Activity component has a corresponding activityrecord object on the activitymanagerservice side, describes the running status of the activity component. This binder proxy object will be saved in the mapptoken member variable of the window class, so that the window currently being processed can know what activity component is associated with it.

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

The WM parameter is used to describe a window manager. As you can see from the previous call process, the value of the passed parameter WM is equal to null. Therefore, the function first calls the static member function getdefault of the 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 will 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

public class WindowManagerImpl implements WindowManager {    ......    public static WindowManagerImpl getDefault()    {        return mWindowManager;    }     ......    private static WindowManagerImpl mWindowManager = new WindowManagerImpl();}

This function is defined in the file frameworks/base/CORE/Java/Android/View/windowmanagerimpl. java.

The implementation of the static member function getdefault of the windowmanagerimpl class is very simple. It only 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 the application window.

After this step is completed, return to Step 7, that is, the window class member function setwindowmanager. Next, use the windowmanagerimpl object obtained earlier to create a local window manager, it is a localwindowmanager object.

Step 9. New localwindowmanager

public abstract class Window {    ......    private final Context mContext;    ......    private class LocalWindowManager implements WindowManager {        LocalWindowManager(WindowManager wm) {            mWindowManager = wm;            mDefaultDisplay = mContext.getResources().getDefaultDisplay(                    mWindowManager.getDefaultDisplay());        }        ......        private final WindowManager mWindowManager;        private final Display mDefaultDisplay;    }    ......}

This function is defined in the file frameworks/base/CORE/Java/Android/View/window. java.

The constructor of the localwindowmanager class first saves a windowmanagerimpl object described by the parameter WM in its member variable mwindowmanager. In this way, the window management work will be handed over to it for processing.

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

The Display object obtained previously describes global screen properties, and some customizable screen properties may be configured for the window currently being processed. Therefore, the constructor of the localwindowmanager class needs to further adjust the screen properties described in the display object obtained above, so that it can be used in the window currently being processed. The localwindowmanager class constructor first obtains a resources object through the getresources function of the mcontext member variable of the external class window, then, call the member function getdefadisplay display of the resources object to adjust the screen properties described in the display object. The final adjusted Display object is saved in the mdefaultdisplay member variable of the localwindowmanager class.

As you can see from step 4 above, the member variable mcontext of the window class describes an activity component associated with the current window. The getresources function of the 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:

public class ContextWrapper extends Context {    Context mBase;    ......    @Override    public Resources getResources()    {        return mBase.getResources();    }    ......}

According to the analysis of the creation process of the running Context Environment (context) in the previous Android Application Window (activity), the member variable mbase of the contextwrapper class points to a contextimpl object, describes the running context of an activity component. By calling the member function getresources of the contextimpl object, you can obtain a resource object with this resource object. Through this resource object, you can access the resource information of an activity component, in this way, you can obtain the configured screen attributes.

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

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

2. Application windows of the phonewindow type are maintained by a local window manager of the localwindowmanager type.

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

4. A view object of the decorview type exists in the application window of phonewindow type. This view object is actually used to describe the UI of an activity component.

In the next article, we will continue to analyze the creation process of view objects in the application window. Stay tuned!

Lao Luo's Sina Weibo: http://weibo.com/shengyangluo. welcome to the attention!