Android Window WindowManager Finishing

Android can be directly visible on the interface including activity Toast Dialog Popuwindow ...

Android windows are divided into three types:

1. Application Windows (application window): Includes Windows created by all applications themselves, and the system is responsible for displaying the windows before applying them.

2. Sub window: For example, if you apply a custom dialog or Input Method window, the child window must be attached to an application window (setting the same token).

3. System window: System design, not attached to any application window, for example, status bar, navigation bar (Navigation bar), wallpaper (wallpaper), Caller ID window (phone), Lock screen window ( Keyguard), Information tip window (Toast), Volume adjustment window, mouse cursor, and so on.

1, window is the windows in Android, indicating the meaning of the top-level window, that is, the main window, it has two implementation classes,Phonewindow and midwindow

(1) Our general activity corresponds mainly to Phonewindow, which is often used in activity Setcontentview Such methods are also implemented in this.

Performlaunchactivity, the Activity.attach method is called to create a window, when the activity is started in the Handleresumeactivity method, The main window will be added to the WindowManager

(2) Popupwindow belongs to sub window, so must have a view to attach

(3) Custom toast: The principle of customization is also simple, that is, to add view to WindowManager and delete view, However, you need to set the style of the windowmanager.layoutparams and view so that it looks similar to the toast of the Android system.

Toasts are loaded through WindowManager call AddView. Therefore, the Hide method is naturally WindowManager call the Removeview method to remove the toast view. To summarize, through the source analysis of TN class, we know that the TN class is a callback object, and other processes call the TN class's show and hide methods to control the display and disappearance of this toast. In the toast class of the show method, we can see that the getservice is called here to get the Inotificationmanager service to determine whether the system toast.

1) If the package name of the process to which the current toast belongs is "Android", the system toast, or the Iscallersystem () method can also be called;

Determines whether the UID of the current toast belongs to a system_uid, 0, Phone_uid, or a system toast if it is not, and not a system toast. Is the system toast, through the following source reading, there are two main advantages: The system toast must be entered into the system toast queue, will not be blocked by the blacklist. The system toast has no limit in the system toast queue, and the toast sent by the ordinary Pkg has a number limit in the system toast queue.

2) See if the toast that will be queued is already in the system toast queue. This is achieved by comparison of Pkg and callback.

3) Set the current toast process to the foreground process, where Mam=activitymanagernative.getdefault (), The Setprocessforeground method is called to set the current PID process to the foreground process, ensuring that no system kills. This explains why the toast can also be displayed when we finish the current activity, because the current process is still executing.

            4)   index is 0 o'clock, the toast of the queue header is displayed
      (4) Dialog
Opening dialog in service requires a programming system window

Change dialog background transparency:

Dialog dg = new Dialog (this);

window window = Dg.getwindow ();

Windowmanager.layoutparams LP = Window.getattributes ();

Lp.alpha = 0.5f;

Window.setattributes (LP);

WindowManager:

WindowManager is primarily used to manage some of the window's status, properties, view additions, deletions, updates, window order, message collection, and processing.

An instance of WindowManager can be obtained by Context.getsystemservice (context.window_service) .

WindowManager inherits from the Viewmanager, which involves three important methods of window management, namely:

* AddView ();

* Updateviewlayout ();

* Removeview ();

There is also an important static class Layoutparams in WindowManager . It allows you to set and get some properties of the current window.

Let's take a look at the AddView () method, and in AddView, we'll use Layoutparams to get the View property of window and create a viewroot for each window. Viewroot is the bridge between the view and the WindowManager, and the real way to pass the view to WindowManager is through the Viewroot Setview () method, The Viewroot implements message passing between view and WindowManager. When you add the main window to Windowmanger, it first establishes a proxy object:

Wm= (Windowmanagerimpl) context.getsystemservice (Context.window_service)

and open the session (Iwindowsession), and then Window will connect to WindowManager through the session ,

Take a look at the Setview method:

try {

Res =swindowsession.add (Mwindow, Mwindowattributes,

Gethostvisibility (), mattachinfo.mcontentinsets);

} catch (RemoteException e) {

madded = false;

MView = null;

Mattachinfo.mrootview =null;

Unscheduletraversals ();

Throw newruntimeexception ("Adding window Failed", e);

} finally {

if (restore) {

Attrs.restore ();

}

}

In this code, Viewroot adds the window to the WindowManager through Iwindowsession. Viewroot inherited the handler, in fact, its essence is a handler, window view of the event processing, message sending, callback, etc. will be handled through Viewroot.

This completes the window to be added to the WindowManager, and by the WindowManager to manage the window view, events, message collection processing and so on.

The thread that updates the UI must be the thread that added the window

When initializing a Viewrootimpl function, the native method is called, gets to the thread object Mthread, and the SetText function calls to the Requestlayout method

(After the TextView is drawn, calling SetText will not call the Requestlayout method, and it will not be thrown exception until it is drawn out before the child thread is called SetText):

public void requestLayout() {    .....    checkThread();    .....}....void checkThread() { if (mThread != Thread.currentThread()) { throw new CalledFromWrongThreadException( "Only the original thread that created a view hierarchy can touch its views."); }}

What really appears to the user in Android is that window and View,activity's role in Android is primarily to deal with logic issues such as lifecycle management, building windows, and so on.

In Android , window management is a more important piece because he is directly responsible for presenting the content to the user and interacting with the user. Respond to user input and so on.

First of all, Viewmanager this interface, this interface mainly has the following implementation sub-interface and implementation classes, respectively: WindowManager and ViewGroup inside there are three important methods:

* AddView ();

* Updateviewlayout ();

* Removeview ();

In WindowManager, the AddView method represents a top-level view (that is, Decorview) in the main window that is added to WindowManager and a session is established. This is explained in more detail next. Let's look at window first.

Window:

Windows is a window in Android that represents the meaning of the top-level window, which is the main window, which has two implementation classes,Phonewindow and Midwindow,

Our general activity corresponds mainly to Phonewindow, which is often used in activity Setcontentview Such methods are also implemented in this.

@Override

public void Setcontentview (View view,viewgroup.layoutparams params) {

if (mcontentparent = = null) {

Installdecor ();

} else {

Mcontentparent.removeallviews ();

}

Mcontentparent.addview (view, params);

Final Callback cb = Getcallback ();

if (CB! = null) {

Cb.oncontentchanged (); Update when window class capacity changes

}

}

Each main window has a view called Decorview, which is the top view in the main window (which is actually viewgroup), with two member variables in view called Mparent, Mchildren, which are used to manage the hierarchy of the view.

And ViewGroup is the management of a group of view. As a result, all view networks are established in the ViewGroup. The final viewgroup is attached to the main window. This makes it easy to find a specific view through the Findviewbyid in the window. Event handling in view is also handled according to this path.

Let's look at two important methods in Activitythead (as far as Activitythead will be described in detail in one article):

Performlaunchactivity ();

Handleresumeactivity ();

In Performlaunchactivity, the Activity.attach method is called to create a window, when the activity is started in the Handleresumeactivity method, The main window will be added to the WindowManager

View decor =r.window.getdecorview (); Get the top view of the window

Decor.setvisibility (view.invisible);

Viewmanager wm= A.getwindowmanager (); WindowManager inherited from Viewmanager

Windowmanager.layoutparams l =r.window.getattributes ();

A.mdecor = Decor;

L.type =windowmanager.layoutparams.type_base_application;

L.softinputmode |= forwardbit;

if (a.mvisiblefromclient) {

A.mwindowadded = true;

Wm.addview (decor, L); is actually adding the top view of the main window to the Windowmangaer

}

Let's look at WindowManager again.

WindowManager:

WindowManager is primarily used to manage some of the window's status, properties, view additions, deletions, updates, window order, message collection, and processing.

An instance of WindowManager can be obtained by Context.getsystemservice (context.window_service) .

WindowManager inherits from the Viewmanager, which involves three important methods of window management, namely:

* AddView ();

* Updateviewlayout ();

* Removeview ();

There is also an important static class Layoutparams in WindowManager . It allows you to set and get some properties of the current window.

Let's take a look at the AddView () method, and in AddView, we'll use Layoutparams to get the View property of window and create a viewroot for each window.

Viewroot is the bridge between the view and the WindowManager, and the real way to pass the view to WindowManager is through the Viewroot Setview () method,

The Viewroot implements message passing between view and WindowManager. When you add the main window to Windowmanger, it first establishes a proxy object:

Wm= (Windowmanagerimpl) context.getsystemservice (Context.window_service)

and open the session (Iwindowsession), and then Window will connect to WindowManager through the session ,

Take a look at the Setview method:

try {

Res =swindowsession.add (Mwindow, Mwindowattributes,

Gethostvisibility (), mattachinfo.mcontentinsets);

} catch (RemoteException e) {

madded = false;

MView = null;

Mattachinfo.mrootview =null;

Unscheduletraversals ();

Throw newruntimeexception ("Adding window Failed", e);

} finally {

if (restore) {

Attrs.restore ();

}

}

In this code, Viewroot adds the window to the WindowManager through Iwindowsession. Viewroot inherited the handler, in fact, its essence is a handler, window view of the event processing, message sending, callback, etc. will be handled through Viewroot.

This completes the window to be added to the WindowManager, and by the WindowManager to manage the window view, events, message collection processing and so on.

Android Window WindowManager Finishing