The "Go" Android application window (Activity) Window object (Windows) Creation Guide

In the previous article, we analyzed the creation process of the running context of the Android application window. It follows that each activity component has an associated Contextimpl object, and it also has a window object associated with it that describes a specific application window. As a result, activity is nothing more than 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 the Android application window object in detail.

From the previous Android application window (Activity) Implementation Framework brief introduction and Learning Plan article can be known that on the phone platform, the Activity component associated with the actual type of the Window object is Phonewindow, which is inherited from the window class. The relationship between activity, window, and Phonwwindow three classes can be referred to in Figure 3 and Figure 5 of the Android application window (activity) Implementation Framework brief introduction and Learning Plan article. To facilitate the next description of the process of creating an application window of type Phonewindow, we take these two diagrams, as shown in Figure 1 and figure 2 below:

Figure 1 class diagram of activity and window

Figure 2 Class diagram for window and Phonewindow

The description of the classes involved in the above two diagrams can refer to the Android application window (Activity) Implementation Framework brief introduction and Learning Plan article, this paper mainly from the Android application window creation process to understand Activity, The relationship between window and Phonwwindow three classes.

An analysis of the creation process from the runtime context of the Android application window (Activity) can be found in the article, One of the Phonewindow objects associated with the activity component is created from the member function attach of the activity class, as shown in 3:

Figure 3 The process of creating an Android application window

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

Step 1. Activity.attach

Copy CodeThe code is as follows:
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 context of the creation process of the previous Android application window (Activity), we have analyzed the implementation of this function, where we focus only on the code associated with the application window creation.

The function first calls the static member function of the Policymanager class Makenewwindow to create an application window of type Phonewindow, and is saved in the member variable Mwindow of the Activity class. With this application window of type Phonewindow, the function next 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 member functions of the Phonewindow class Setcallback, Setsoftinputmode, and Setwindowmanager are inherited from the parent class window, so Next we will continue to analyze the static member functions of the Policymanager class Makenewwindow, and the implementation of the member functions of the window class Setcallback, Setsoftinputmode, and Setwindowmanager.

Step 2. Policymanager.makenewwindow

Copy CodeThe code is as follows:
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 being loaded", ex);
} catch (Instantiationexception ex) {
throw New RuntimeException (
Policy_impl_class_name + "could not being instantiated", ex);
} catch (Illegalaccessexception ex) {
throw New RuntimeException (
Policy_impl_class_name + "could not being 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 that, when used for the first time, creates an instance of the policy class and is saved in the static member variable Spolicy. Later, the window management strategy of the Policymanager class is implemented through this policy class instance, for example, The static member function of the Policymanager class is makenewwindow to create a concrete application window by invoking the member function of the instance of the policy class Makenewwindow.

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

Step 3. Policy.makenewwindow

Copy CodeThe code is as follows:
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 implementation of the member function Makenewwindow of the policy class is simple, it simply creates a Phonewindow object and then 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 process of creating an application window of type Phonewindow.

Step 4. New Phonewindow

Copy CodeThe code is as follows:
public class Phonewindow extends Window implements Menubuilder.callback {
......

This is the top-level view of the window, containing the window decor.
Private Decorview Mdecor;

The the view in which the window contents is 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.

The constructor of the Phonewindow class is simple, it calls the constructor of the parent window first to perform some initialization, and then calls the static member function of Layoutinflater to create a Layoutinflater instance. and is saved in the member variable Mlayoutinflater. In this way, the Phonewindow class can then create a view of the application window through the member variable Mlayoutinflater, which is described using a member variable Mdecor of type Decorview. The Phonewindow class also has a member variable mcontentparent of type ViewGroup, which is used to describe a view container that holds the contents of the view described by the member variable Mdecor. But this container may also point to the Mdecor itself. In a later article, we analyze the process of creating a view of the application window of type Phonewindow in detail.

The constructor of Window is defined in file Frameworks/base/core/java/android/view/window.java, and its implementation is simple, just initializing its member variable Mcontext as follows:

Copy CodeThe code is as follows:
Public abstract class Window {
......

Private final Context Mcontext;
......

Public Window (Context context) {
Mcontext = context;
}

......
}

As you can tell from the previous call procedure, the parameter context describes the activity component that is being started, which is saved in the window class's member variable Mcontext, which allows the window class to access the resources associated with the activity component.

After this step is completed, go back to step 1, which is the Activity class member function attach, The next step is to set the window callback interface by invoking the member function Setcallback, inherited from the parent class window, from the previously created Phonewindow object, so we continue to analyze the implementation of the member function Setcallback of the window class.

Step 5. Window.setcallback

Copy CodeThe code is as follows: 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 activity component that is being started sets the callback interface that it implements to the member variable mcallback of the parent of the Phonewindow object to which it is associated. So when this Phonewindow object receives the IO input events that the system distributes to it, for example, keyboard and touch screen events, forwards to the activity component it is associated with, This can be referred to in the previous Android application keyboard (KEYBOARD) Message processing mechanism analysis article.

After this step is completed, go back to step 1, which is the Activity class member function attach, Next, you will continue to invoke the Phonewindow object that you created earlier from the parent class window to inherit from the member function Setsoftinputmode to set the application window's soft keyboard input area display mode, therefore, Next we will continue to analyze the implementation of the member function Setsoftinputmode of the window class.

Step 6. Window.setsoftinputmode

Copy CodeThe code is as follows:
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.

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 have a total of six values that describe the display mode of the soft keyboard input area of the window, and their meanings are as follows:

1. soft_input_state_unspecified: The display state 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: Hides the soft keyboard input area when appropriate, for example, when the user navigates to the current window.

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

5. soft_input_state_visible: Displays the soft keyboard input area at the appropriate time, 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_unspecified, it indicates that the current window is specified in the display mode of the soft keyboard input area. This time the member function Setsoftinputmode of the window class sets the value of the member variable Mhassoftinputmode to TRUE. This display mode is saved in the member variable softinputmode of a Windowmanager.layoutparams object that describes 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 completion window, if the member variable mcallback of the Windows class points to a window callback interface, The member function of the window class Setsoftinputmode also calls its member function onwindowattributeschanged to notify the activity component associated with the window, and its window layout properties have changed.

After this step is completed, go back to step 1, which is the Activity class member function attach, Next, you will continue to invoke the Phonewindow object that you created earlier from the parent class window inherited from the member function Setwindowmanager to set the application window of the local window manager, therefore, Next we will continue to analyze the implementation of the member function Setwindowmanager of the window class.

Step 7. Window.setwindowmanager

Copy CodeThe code is as follows:
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 parameter apptoken is used to describe which activity component is associated with the currently processing window, which is a binder agent object. A binder local object of type Activityrecord that is created on this side of Activitymanagerservice is referenced. A brief introduction to the activity initiation process from the previous Android application and a learning Plan a series of articles can be learned that each of the activated activity components on the Activitymanagerservice side, has a corresponding Activityrecord object that describes the running state of the activity component. This binder proxy object is stored in the member variable mapptoken of the window class so that the window currently being processed knows what the activity component is associated with it.

The parameter appname is used to describe the name of the activity component associated with the window currently being processed, and this name is stored in the member variable mappname of the Windows class.

The parameter wm is used to describe a window manager. From the previous call procedure you can tell that the value passed in here is equal to NULL, so the function first calls the static member function of the Windowmanagerimpl class Getdefault to get a default window manager. With this window manager, the function then uses it to create a local window manager, 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 Localwindowmanager class constructor function.

Step 8. Windowmanagerimpl.getdefault

Copy CodeThe code is as follows:
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 simple, and it simply returns a Windowmanagerimpl object pointed to by the static member variable Mwindowmanager to the caller. This Windowmanagerimpl object implements the WindowManager interface, so it can be used to manage application windows.

Once this is done, go back to step 7, the member function Setwindowmanager of the window class, and then create a local window manager using the Windowmanagerimpl object that you obtained earlier. That is, a Localwindowmanager object.

Step 9. New Localwindowmanager

Copy CodeThe code is as follows:
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 the Windowmanagerimpl object described by the parameter WM in its member variable Mwindowmanager, so that the window management work is given to it 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. Used to describe system screen properties.

Because the display object previously obtained describes the global screen properties, and the window that is currently being processed may be configured with some customizable screen properties, The constructor of the Localwindowmanager class needs to be further adjusted to the screen properties described by the previously obtained display object so that it can be used for the window currently being processed. The constructor of the Localwindowmanager class first obtains a resources object through the member function getresources of the member variable mcontext of the Outer class window. The member function of the resources object is then called Getdefaultdisplay to adjust the screen properties described by the previously obtained display object. The display object that is finally resized is saved in the member variable mdefaultdisplay of the Localwindowmanager class.

As you can see from the previous step 4, the member variable mcontext of the class window describes an activity component associated with the current window. The activity class's member function, Getresources, continues from the parent class Contextwrapper, which implements the file frameworks/base/core/java/android/content/ Contextwrapper.java, as shown in the following:

Copy CodeThe code is as follows:
public class Contextwrapper extends Context {
Context mbase;
......

@Override
Public Resources getresources ()
{
return mbase.getresources ();
}

......
}

From the creation process analysis of the run Context environment (context) of the previous Android application window (Activity), you can tell that the member variable mbase of the Contextwrapper class is pointing to a Contextimpl object, The context of the runtime used to describe an activity component. By invoking the member function of this Contextimpl object getresources, you can obtain a resource object, and through this resources object, you can access the information of the activity component, This allows you to get the screen properties that it configures.

At this point, we analyze the process of creating an application window object associated with an activity component. From the analysis process you can know:

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

2. This application window of type Phonewindow is maintained by a local window manager of type Localwindowmanager.

3. This local window manager of type Localwindowmanager is also maintained in the application window through a window manager of type Windowmanagerimpl.

4. This type of Phonewindow application window has a View object of type Decorview inside, which is the UI that is really used to describe an activity component.

In the next article, we'll continue to analyze the creation of view objects inside the application window, so stay tuned!

From:http://www.jb51.net/article/32354.htm

The "Go" Android application window (Activity) Window object (Windows) Creation Guide