Window represents the concept of a window. Window is an abstract class, and its concrete implementation is PhoneWindow. Creating a Window requires WindowManager to complete it. WindowManager is the entrance to the outside world to access Window. The specific implementation of Window is located in WindowManagerService. The interaction between WindowManager and WindowManagerService is an IPC process. In Android, all views are presented through Window. Whether it is Activity, Dialog, or Toast, their views are actually attached to the Window. Therefore, Window is the direct manager of the actual View. The click event is passed by Window to DecorView, and then passed by DecorView to our View. Even the Activity setting view method setContentView is completed through Window at the bottom.
Window and WindowManager
The process of adding a Window, the key code is:
(mFLoatingButton,mLayoutParams);
There are two flags and type parameters in it.
The Flags parameter has three Window properties
- FLAG_NOT_FOCUSABLE. It means that Window does not need to obtain focus, nor does it need to receive various input events. The event will be directly passed to the lower layer of Window with focus.
- FLAG_NOT_TOUCH_MODAL. In this mode, the system will pass the click event outside the current Window area to the underlying Window. The click event inside the current Window area will be handled by itself. This mark is very important. Generally speaking, this mark needs to be turned on, otherwise other Window will not be able to receive click events.
- FLAG_SHOW_WHEN_LOCKED. Turn on this mode to let the Window be displayed on the lock screen interface.
The Type parameter indicates the type of Window. There are three types, namely Application Window, Sub Window and System Window. The application class Window corresponds to an Activity. The child Window cannot exist alone. It needs to be attached to a specific parent Window. For example, the common Dialog is a child Window. The system Window needs to declare permissions in the Window that can be created, such as Toast and the system status bar, these are system Window.
Window is hierarchical, each Window has a corresponding z-ordered, and the large hierarchy will cover the Window with a small hierarchy. Among the three types of Window, the hierarchy range of the application class Window is 1-99, the hierarchy range of the sub-Window is 1000-1999, and the hierarchy range of the system Window is 2000-2999, and the Type parameters corresponding to these hierarchy ranges. If you want the Window to be located at the top level of all Windows, then you can use a larger level. Obviously, the system Window level is the largest, and there are many values at the system level.
The functions provided by WindowManager are very simple. There are three commonly used methods, namely adding View, updating View and deleting View. These three methods are defined in ViewManager, and WindowManager inherits ViewManager.
Window's internal mechanism
Window is an abstract concept. Each Window corresponds to a View and a ViewRootImpl. Window and View are connected through ViewRootImpl, which means that View is the entity that exists in Window. In actual use, Window cannot be accessed directly. Access to Window must be through WindowManager.
Window addition process
The process of adding Window needs to be implemented through the addView of WindowManager. WindowManager is an interface, and its real implementation is the WindowManagerImpl class.
@Override
public void addView(View view, params){
(view,params,mDisplay,mParentWindow);
}
@Override
public void updateViewLayout(View view, params){
(view,params);
}
@Override
public void removeView(View view){
(view,false);
}
It can be seen that WindowManagerImpl does not directly implement the three major operations of Window, but is left to WindowManagerGlobal for processing. WindowManagerGlobal provides its own instances to the outside in the form of a factory. The addView method of WindowManagerGlobal is mainly divided into the following steps:
- Check whether the parameters are legal. If it is a sub-Window, then you need to adjust some layout parameters.
- Create ViewRootImpl and add View to the list
- Update the interface and complete the Window addition process through ViewRootImpl
Window deletion process
The Window deletion process is the same as the addition process. It is first implemented through WindowManagerImpl and then further through WindowManagerGlobal. It uses an internal implementation of dispatchDetachedFromWindow method. This method mainly does four things:
Garbage recycling related tasks, such as clearing data and messages, removing callbacks
Delete Window via Session's remove method
Call the dispatchDetachedFromWindow method of the View, and internally call the View's onDetachedFromWindow() and onDetachedFromWindowInternal()
Call the doRemoveView method of WindowManagerGlobal to refresh data
Window update process
The main purpose is to use the updateViewLayout method. First, it needs to update the LayoutParams of the View and replace the old LayoutParams, and then update the LayoutParams in ViewRootImpl. This step is achieved through the setLayoutParams method of ViewRootImpl. In ViewRootImpl, the view will be re-layouted through the scheduleTraversals method, including measurement, layout, and redrawing.
Window creation process
View is the view rendering method in Android, but View cannot exist alone. It must be attached to the abstract concept of Window, so there is Window where there is a view.
Activity's Window creation process
How to create it requires understanding the Activity startup process, which is quite complicated, but it is ultimately completed by perfromLaunchActivity() in ActivityThred. Inside this method, an instance object of the Activity will be created through a class loader and its attachment method is called to its associated series of context environment variables that depend on during the operation.
In the Activity attach method, the system will create the Window object to which the Activity belongs and set a callback interface. The creation of the Window object is implemented through the PolicyManager's makeNewWindow method. As can be seen from the implementation of the Activity setContentView, the Activity will hand over the specific implementation to the Window, and the specific implementation of the Window is PhoneWindow, so you only need to look at the related logic of PhoneWindow, and the following steps are roughly the following:
- If there is no DecorView, then create it. DecorView is a FrameLayout, the top view of Activity, and generally its internals contain title bars and internal bars.
- Add View to the mContentParent of DecorView.
- The onContentChanged method of the callback Activity notifies the Activity view that has changed. Activity's onContentChanged is an empty implementation.
After the above three steps, the DecorView has been created and initialized, and the layout file of the Activity has been successfully added to the mContentParent of the DecorView. However, at this time, the DecorView has not been officially added to the Window by the WindowManager. The real call to the view is in the Activity's onResume method, and then the Activity's makeVisible() will be called. It is in the makeVisible method that the DecorView truly completes the two processes of adding and displaying.
Dialog's Window creation process
The creation process of Dialog's Window is similar to Activity, with the following steps:
- Create Window. It is also done through the makeNewWindow method of PolicyManager.
- Initialize the DecorView and add the Dialog's view to the DecorView.
- Add the DecorView to the Window and display it. In the Dialog show method, the DecorView will be added to the Window through the WindowManager.
There is one special feature of ordinary Dialogs, that is, they must use Activity Context. If they use Application Context, an error will be reported.
Toast's Window creation process
Toast and Dialog are different, and their working process is slightly more complicated. First of all, Toast is also implemented based on Window, but because Toast has a timed cancellation function, the system uses Handler. There are two types of IPC processes within Toast. The first is Toast accesses the NotificationManagerService, and the second is NotificationManagerService callbacks the TN interface of Toast.
Toast belongs to the system Window. There are two ways to specify the internal view. One is the system default style, and the other is to specify a custom View through the setView method. No matter what, they correspond to a view type internal member mNextView of Toast. Toast provides show and cancel for display and hide Toast, respectively, and their internals are an IPC process.
The above is the Window and WindowManager in Android introduced to you by the editor. I hope it will be helpful to you. If you have any questions, please leave me a message and the editor will reply to you in time. Thank you very much for your support for my website!