Android窗口管理系统是非常大的一块，涉及AMS、InputManagerService、输入法管理等，这么复杂的一个系统，如果直接扎进入分析看源码可能会比较混乱，所以，本文以Toast显示原理作为切入点，希望能简单点初窥一下WMS。首先，简单看下Toast用法：
Context context = getApplicationContext();
CharSequence text = "Hello toast!";
int duration = Toast.LENGTH_SHORT;
Toast toast = Toast.makeText(context, text, duration);
toast.show();
Toast的显示原理
下面跟一下源码：
public static Toast makeText(Context context, CharSequence text, int duration) {
Toast result = new Toast(context);
LayoutInflater inflate = (LayoutInflater)
context.getSystemService(Context.LAYOUT_INFLATER_SERVICE);
View v = inflate.inflate(com.android.internal.R.layout.transient_notification, null);
TextView tv = (TextView)v.findViewById(com.android.internal.R.id.message);
tv.setText(text);
result.mNextView = v;
result.mDuration = duration;
return result;
}
可以看到makeText仅仅是新建了一个Toast实例，并为其创建了一个无主TextView，并没多少特殊逻辑。那么看下关键的show代码：
public void show() {
if (mNextView == null) {
throw new RuntimeException("setView must have been called");
}
INotificationManager service = getService();
String pkg = mContext.getPackageName();
TN tn = mTN;
tn.mNextView = mNextView;
try {
service.enqueueToast(pkg, tn, mDuration);
} catch (RemoteException e) {
}
}
这里首先通过getService获取通知管理服务，
static private INotificationManager getService() {
if (sService != null) {
return sService;
}
sService = INotificationManager.Stub.asInterface(ServiceManager.getService("notification"));
return sService;
}
之后再将Toast的显示请求发送给该服务，在发送的过程中传递一个Binder实体，提供给NotificationManagerService回调使用，不过如果看下NotificationManagerService就会发现，该类并不是Binder实体，所以本身不是服务逻辑的承载体，在NotificationManagerService中，真正的服务对象是INotificationManager.Stub，因此到Service端，真正请求的服务是INotificationManager.Stub的enqueueToast：
private final IBinder mService = new INotificationManager.Stub() {
public void enqueueToast(String pkg, ITransientNotification callback, int duration)
{
if (pkg == null || callback == null) {
Slog.e(TAG, "Not doing toast. pkg=" + pkg + " callback=" + callback);
return ;
}
final boolean isSystemToast = isCallerSystem() || ("android".equals(pkg));
if (ENABLE_BLOCKED_TOASTS && !noteNotificationOp(pkg, Binder.getCallingUid())) {
if (!isSystemToast) {
Slog.e(TAG, "Suppressing toast from package " + pkg + " by user request.");
return;
}
}
synchronized (mToastQueue) {
int callingPid = Binder.getCallingPid();
long callingId = Binder.clearCallingIdentity();
try {
ToastRecord record;
int index = indexOfToastLocked(pkg, callback);
if (index >= 0) {
record = mToastQueue.get(index);
record.update(duration);
} else {
if (!isSystemToast) {
int count = 0;
final int N = mToastQueue.size();
for (int i=0; i= MAX_PACKAGE_NOTIFICATIONS) {
Slog.e(TAG, "Package has already posted " + count
+ " toasts. Not showing more. Package=" + pkg);
return;
}
}
}
}
record = new ToastRecord(callingPid, pkg, callback, duration);
mToastQueue.add(record);
index = mToastQueue.size() - 1;
keepProcessAliveLocked(callingPid);
}
if (index == 0) {
showNextToastLocked();
}
} finally {
Binder.restoreCallingIdentity(callingId);
}
}
... }
}
从上面的synchronized (mToastQueue)可以知道，这是个支持多线程的操作的对象，其实很好立即，既然上面牵扯到插入节点的操作，那么就一定在某个地方有摘除节点的操作。接着看下showNextToastLocked，如果当前没有Toast在显示，就会执行showNextToastLocked，当然如果有正在显示的Toast，这里就只执行插入操作，其实这里有点小计俩，那就是下一个Toast的执行是依赖超时进行处理的，也就是必须等到生一个Toast超时，显示完毕，才显示下一个Toast，具体让下看：
void showNextToastLocked() {
ToastRecord record = mToastQueue.get(0);
while (record != null) {
try {
record.callback.show();
scheduleTimeoutLocked(record);
return;
} catch (RemoteException e) {
int index = mToastQueue.indexOf(record);
if (index >= 0) {
mToastQueue.remove(index);
}
keepProcessAliveLocked(record.pid);
if (mToastQueue.size() > 0) {
record = mToastQueue.get(0);
} else {
record = null;
}
}
}
}
看一下关键点1，这里虽然是while循环，但是只取到一个有效的ToastRecord就返回了，也就是队列上的后续TaskRecord要依赖其他手段来显示了。这里并没看到WindowManagerService的身影，其实View添加到窗口显示的时机都是在APP端，而不是在服务端，对这里而言，就是通过CallBack回调，前面不是传递过来一个Binder实体么，这个实体在NotificationManagerService端就是作为Proxy，以回调APP端，其实Android里面的系统服务都是采用这种处理模式APP与Service互为C/S，record.callback就是APP端TN的代理，这里简单看一下其实现：
private static class TN extends ITransientNotification.Stub {
final Runnable mShow = new Runnable() {
@Override
public void run() {
handleShow();
}
};
final Runnable mHide = new Runnable() {
@Override
public void run() {
handleHide();
mNextView = null;
}
};
private final WindowManager.LayoutParams mParams = new WindowManager.LayoutParams();
final Handler mHandler = new Handler();
int mGravity;
int mX, mY;
float mHorizontalMargin;
float mVerticalMargin;
View mView;
View mNextView;
WindowManager mWM;
TN() {
final WindowManager.LayoutParams params = mParams;
params.height = WindowManager.LayoutParams.WRAP_CONTENT;
params.width = WindowManager.LayoutParams.WRAP_CONTENT;
params.format = PixelFormat.TRANSLUCENT;
params.windowAnimations = com.android.internal.R.style.Animation_Toast;
params.type = WindowManager.LayoutParams.TYPE_TOAST;
params.setTitle("Toast");
params.flags = WindowManager.LayoutParams.FLAG_KEEP_SCREEN_ON
| WindowManager.LayoutParams.FLAG_NOT_FOCUSABLE
| WindowManager.LayoutParams.FLAG_NOT_TOUCHABLE;
}
@Override
public void show() {
if (localLOGV) Log.v(TAG, "SHOW: " + this);
mHandler.post(mShow);
}
...
public void handleShow() {
if (localLOGV) Log.v(TAG, "HANDLE SHOW: " + this + " mView=" + mView
+ " mNextView=" + mNextView);
if (mView != mNextView) {
// remove the old view if necessary
handleHide();
mView = mNextView;
Context context = mView.getContext().getApplicationContext();
String packageName = mView.getContext().getOpPackageName();
if (context == null) {
context = mView.getContext();
}
mWM = (WindowManager)context.getSystemService(Context.WINDOW_SERVICE);
// We can resolve the Gravity here by using the Locale for getting
// the layout direction
final Configuration config = mView.getContext().getResources().getConfiguration();
final int gravity = Gravity.getAbsoluteGravity(mGravity, config.getLayoutDirection());
mParams.gravity = gravity;
if ((gravity & Gravity.HORIZONTAL_GRAVITY_MASK) == Gravity.FILL_HORIZONTAL) {
mParams.horizontalWeight = 1.0f;
}
if ((gravity & Gravity.VERTICAL_GRAVITY_MASK) == Gravity.FILL_VERTICAL) {
mParams.verticalWeight = 1.0f;
}
mParams.x = mX;
mParams.y = mY;
mParams.verticalMargin = mVerticalMargin;
mParams.horizontalMargin = mHorizontalMargin;
mParams.packageName = packageName;
if (mView.getParent() != null) {
mWM.removeView(mView);
}
if (localLOGV) Log.v(TAG, "ADD! " + mView + " in " + this);
mWM.addView(mView, mParams);
trySendAccessibilityEvent();
}
}
public void handleHide() {
if (localLOGV) Log.v(TAG, "HANDLE HIDE: " + this + " mView=" + mView);
if (mView != null) {
if (mView.getParent() != null) {
mWM.removeView(mView);
}
mView = null;
}
}
}
其show函数，归根到底就是通过WindowManagerService，将View添加到Window， mWM.addView(mView, mParams);这样Toast就显示出来了。那么怎么隐藏呢？不能一个Toast总是占据屏幕吧。
Toast的隐藏原理
接着看NotificationManagerService端的showNextToastLocked函数，在callback后，会继续通过scheduleTimeoutLocked为Toast添加一个TimeOut监听，并利用该监听将过期的Toast从系统移出,看下实现：
void showNextToastLocked() {
ToastRecord record = mToastQueue.get(0);
while (record != null) {
try {
record.callback.show();
scheduleTimeoutLocked(record);
return;
} catch (RemoteException e) {
...
}
}
scheduleTimeoutLocked其实就是通过Handler添加一个延时执行的Action，
private void scheduleTimeoutLocked(ToastRecord r)
{
mHandler.removeCallbacksAndMessages(r);
Message m = Message.obtain(mHandler, MESSAGE_TIMEOUT, r);
long delay = r.duration == Toast.LENGTH_LONG ? LONG_DELAY : SHORT_DELAY;
mHandler.sendMessageDelayed(m, delay);
}
等到 Timeout的时候，Handler处理该事件，
private void handleTimeout(ToastRecord record)
{
synchronized (mToastQueue) {
int index = indexOfToastLocked(record.pkg, record.callback);
if (index >= 0) {
cancelToastLocked(index);
}
}
}
可以看到就是通过cancelToastLocked来隐藏当前显示的Toast，当然，如果队列中还有Toast要显示，就继续showNextToastLocked显示下一个，这里将显示放在cancle里完成Loop监听也挺奇葩的。
void cancelToastLocked(int index) {
ToastRecord record = mToastQueue.get(index);
try {
record.callback.hide();
} catch (RemoteException e) {
}
mToastQueue.remove(index);
keepProcessAliveLocked(record.pid);
if (mToastQueue.size() > 0) {
showNextToastLocked();
}
}
callback.hide()其实就是通过WindowManager移除当前View，
public void handleHide() {
if (mView != null) {
if (mView.getParent() != null) {
if (localLOGV) Log.v(TAG, "REMOVE! " + mView + " in " + this);
mWM.removeView(mView);
}
mView = null;
}
}
可以看到Toast的显示跟隐藏还是APP端自己处理的，就是通过WindowManager，添加或者移除View，不过这两个时机是通过NotificationManagerService进行管理的，其实就是保证Toast按照顺序一个个显示，防止Toast覆盖， 以上就是Toast的显示与有隐藏原理 ，可以看到这里并未涉及任何的Activity或者其他组件的信息，也就是说View的显示其实可以完全不必依赖Activity，那么是不是子线程也能添加显示View或者更新UI呢，答案是肯定的，有兴趣可以自己看下。
一个小问题：Toast一定要在主线程？
答案是：并不一定在主线程，但是要在Hanlder可用线程
方案一：可行
new Thread() {
@Override
public void run() {
super.run();
Looper.prepare();
Context context = getApplicationContext();
CharSequence text = "Hello toast!";
int duration = Toast.LENGTH_SHORT;
Toast toast = Toast.makeText(context, text, duration);
toast.show();
Looper.loop();
}
}.start();
方案二：出错崩溃
new Thread() {
@Override
public void run() {
super.run();
Context context = getApplicationContext();
CharSequence text = "Hello toast!";
int duration = Toast.LENGTH_SHORT;
Toast toast = Toast.makeText(context, text, duration);
toast.show();
}
}.start();
为什么方案一可以，而方案二不行，其实很简单因为方案一提供了Toast运行所需要的Looper环境，在分析Toast显示的时候，APP端是通过Handler执行的，这样做的好处是不阻塞Binder线程，因为在这个点APP端Service端。另外，如果addView的线程不是Loop线程，执行完就结束了，当然就没机会执行后续的请求，这个是由Hanlder的构造函数保证的
public Handler(Callback callback, boolean async) {
if (FIND_POTENTIAL_LEAKS) {
final Class klass = getClass();
if ((klass.isAnonymousClass() || klass.isMemberClass() || klass.isLocalClass()) &&
(klass.getModifiers() & Modifier.STATIC) == 0) {
Log.w(TAG, "The following Handler class should be static or leaks might occur: " +
klass.getCanonicalName());
}
}
mLooper = Looper.myLooper();
if (mLooper == null) {
throw new RuntimeException(
"Can't create handler inside thread that has not called Looper.prepare()");
}
mQueue = mLooper.mQueue;
mCallback = callback;
mAsynchronous = async;
}
如果Looper==null ，就会报错，而Toast对象在实例化的时候，也会为自己实例化一个Hanlder，这就是为什么说“一定要在主线程”，其实准确的说应该是 “一定要在Looper非空的线程”。
作者：看书的小蜗牛
原文链接: 从Toast显示原理初窥Android窗口管理