The process of creating a window in Chapter 8th of "android Kernel Analysis"

This chapter mainly focuses on the loading process of the content on the internal page of the app, and does not involve the internal logic of WMS on the remote server. (For details, see chapter 14th WMS Working principles.)

First, let's review some window-related content introduced in chapter 6th:

1. For Windows managed by WMS, it refers to the view rather than the window class. The window class only provides a set of abstract APIs for window operations;
2. Each activity corresponds to a window iwindow. When WMS receives a user message, it will distribute the message to a specific window. The specific recipient is the iwindow instance viewrootimpl. w, then W forwards the specific message to the specific view, that is, WMS manages the view, but cannot directly transmit the message to the view, which must be transited through iwindow;

Window Type

The Framework defines three window types, specifically in windowmanager. in layoutparams, each type system is represented by an int type constant, which actually represents the layer Layer corresponding to the window, also known as Z-order; because the Android system is a single-window GUI system, you need to overlay the window. In this case, the window is allocated according to the size of the type variable value. A larger value indicates that the higher the position, when WMS overlays windows, the specific values of the windows are dynamically adjusted;

1. Application Window: in simple terms, it is the window loaded by activity in a common application. This is the main display window of our application developers;
   The specific value of type is between first_application_window -- first_application_window, that is, between 1 and 99;
2. Child Window: a window with a parent window belongs to the Child Window Type. Its parent window can be an application window, a system window, or a child window, such as popupwindow, optionmenu, and contextmenu;
   The specific value of type is between first_sub_window -- first_sub_window, that is, between 1000-1999;
3. System window: it can be understood as a system-level window. Its type value is the highest, that is, it is displayed at the top to make sure that the user is visible; for example, the system status bar, incoming call display, screen saver, input method, and toast. The book says that the failure of applications to create system windows should be misleading, because we often create toast windows in applications, to be accurate, some system Window applications cannot be created, because the corresponding type constants are @ hide and cannot be used externally;
   The specific value of type is between first_system_window -- first_system_window, that is, between 2000-2999;

Create an application window

Previously we mentioned that the application window is loaded by activity, so we decided to start an activity from AMS. The specific process is as follows:

1. Activitythread. applicationthread receives the AMS callback to start the IPC request of an activity and executes schedulelaunchactivity (...) Method, during which the specific request is processed asynchronously through handler;
2. In activitythread. h message processing, execute handlelaunchactivity (...), The whole activity is loaded and the page content is displayed as follows;
   1. Execute the receivmlaunchactivity (...);
      1. Execute minstrumentation. newactivity (...), Implement activity instantiation through classloader;
         Minstrumentation can be understood as the manager for managing all activities in each app (in fact, it is similar to the positioning of xxmanager, but in the Android system, manager is more used for remote interface encapsulation, here, it is completely targeted inside the local app. I guess this is the reason why the two naming rules are different.) There is only one instance, which is used to collect and monitor the overhead of all activities;
      2. Execute activity. Attach (...), Set internal variables for the constructed activity instance.
         Policymanager. makenewwindow (.) to instantiate the phonewindow, and
         Context. getsystemservice (.) gets the windowmanager instance;
      3. Execute minstrumentation. callactivityoncreate (...), Implement callback to activity. oncreate (), during which setcontentview (.) will be called, and then phonewindow. setcontentview (.) will be called (.);
         1. Execute phonewindow. installdecor () to complete decorview initialization;
         2. Run phonewindow. generatelayout (.
            Screen_title/screen_action_bar /...) layout requires a framelayout container with ID = content to store views set by users, add the view Instance obtained by inflate to the decorview instance;
         3. Execute mlayoutinflater. Inflate (...) Load the layout set in the activity. At this time, the parent of layout has been set as the dry content container in the window decoration layout;
      4. Execute minstrumentation. callactivityonstart (...), Implement
         Activity. onstart () callback;
      5. Execute minstrumentation. callactivityonpostcreate (...), Implement callback to activity. onpostcreate;
   2. Execute handleresumeactivity (...);
      1. Execute minstrumentation. callactivityonresume (...), Implement callback for activity. onresume () and onpostresume;
      2. Execute windowmanager. addview (...), Indirectly execute windowmanagerglobal.
         Addview (...), Initialize the mrootview of the viewrootimpl instance and execute
         Viewrootimpl. setview (...) Set the parent of the previously obtained decorview instance to mrootview;
         1. Assign values to important variables of mrootview instances;
         2. Execute requestlayout (); send a page re-painting asynchronous message request to ensure that the UI thread makes the window visible before responding to the window message;
         3. Execute mwindowsession. addtodisplay (...) Add and display a real WMS Notification window;
            Note: The mwindowsession variable is actually implemented through windowmanager. opensession (...) As for the lack of direct calls to WMS services, I have mentioned this in Chapter 6th application framework overview;

Create a subwindow

In fact, WMS does not care about the types of windows to be created by the client. The difference is that the windows parent-child relationship is saved on the WMS client, adjust the layer values with the same parent window based on the information;

The standard process for adding a window is to prepare the windowmanager. layoutparams object --> prepare the window content to be added View --> call windowmanager. addview ();

Typical subwindows include: popupwindow In the UI control drop-down list, alertdialog dialog box triggered by the context menu contextmenu, and menuview triggered by the option menu optionmenu;

Pay attention to the following points:

1. The default dialog is not a subwindow type. It belongs to the application window and is identical to the page processed by the activity. However, in some special scenarios, you can change its windowmanager by subclass. layoutparams. the type value changes to the subwindow type;
2. The option menu optionmenu is triggered by a physical key. The actual processing logic is completed by phonewindow, and the activity is just a simple transfer;
3. The menu object triggered by the context menu contextmenu changes with the change of the long-pressed view, while the menu object triggered by the option menu optionmenu remains in the memory, which can be used as a persistent variable in the activity;

Create a system Window

By default, only these types of system windows can be used in applications (type_toast/type_input_method/type_wallpaper/type_dream ), to create other types (for example, we can display a floating window at the top of the screen), we need to create them in androidmanifest. add the system_alert_window permission to XML. Check the permission in phonewindowmanager. checkaddpermission (.);

The addition of the toast System window is roughly the same as that of the normal window, but the windowmanager is set. layoutparams. the type value is different. To ensure that only one toast window is displayed at the same time, the notification manager icationicationmanager service is introduced, in the systemserver service process, icationmanagmanagerservice serializes the toast requests displayed on each client;

In addition, system Window Creation is generally triggered by background service instead of foreground activity. For example, when a Wi-Fi connection is found, a system window pops up to dynamically display network upload and download traffic and speed. This explains why phonestatusbar can be created in the service mentioned in chapter 9th framework startup process, because the status bar belongs to the System window;

If the above content is reproduced, please indicate the source, welcome to visit the column http://blog.csdn.net/sfdev of laotang