在子线程中不能直接调用Toast.makeText(this,title,Toast.LENGTH_SHORT).show();需要放在主线程里面。原因我们后面会讲。因此，我将Toast放在了runOnUiThread方法中（此方法写在一个我测试的Activity里面）。
public void shotToast(final String title) {
new Thread(new Runnable() {
@Override
public void run() {
runOnUiThread(new Runnable() {
@Override
public void run() {
Toast.makeText(this,title,Toast.LENGTH_SHORT).show();
}
});
}
}).start();
}
但是这段话编译出错了。错在哪里了呢？就错在makeText的第一个参数上面。我这java基础真不扎实呀。Activity中的匿名类或者内部类中不能直接用this，因为此时this指的是这个内部类，所以要访问外部类的Activity就要用Activity.this，如果不是在内部类中，就直接用this。
我们还可以把上面的this改成getBaseContext()。点进getBaseContext()方法看到这个方法在ContextWrapper中是这样的：
/**
* @return the base context as set by the constructor or setBaseContext
*/
public Context getBaseContext() {
return mBase;
}
然后我就疑惑，mBase就一定有值吗？
看过我写的另一篇文章Context及其子类源码分析（一）会知道Activity继承自ContextThemeWrapper，ContextThemeWrapper继承自ContextWrapper。ContextWrapper持有一个抽象构件的引用，就是代码里的mBase，真正的ContextImpl的实例会在Activity实例被创建后被创建，然后通过Activity的attach方法赋给mBase。所以正常ContextImpl的实例被创建后，mBase是有值的。
上面我们讲了两个事实：
1、匿名类或内部类中用this指的是这个匿名类或内部类。
2、Activity中ContextImpl的实例被创建后会通过attach方法传入ContextWrapper。
接着，我又提出了疑问——为什么Toast不能直接在子线程中使用？唯有看源码来找答案了。点进Toast的makeText方法可以看到：
public static Toast makeText(Context context, CharSequence text, @Duration 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;
}
没发现什么特别的，不过我点进Toast的构造方法看了看：
public Toast(Context context) {
mContext = context;
//TN是什么东西？
mTN = new TN();
mTN.mY = context.getResources().getDimensionPixelSize(
com.android.internal.R.dimen.toast_y_offset);
mTN.mGravity = context.getResources().getInteger(
com.android.internal.R.integer.config_toastDefaultGravity);
}
发现一个我没见过的TN类，不过我很快就转去show方法里看源码：
public void show() {
if (mNextView == null) {
throw new RuntimeException("setView must have been called");
}
INotificationManager service = getService();
String pkg = mContext.getOpPackageName();
//又出现了TN这个类
TN tn = mTN;
tn.mNextView = mNextView;
try {
//注意这行
service.enqueueToast(pkg, tn, mDuration);
} catch (RemoteException e) {
// Empty
}
}
又出现了TN这个类，但正常情况下我们会先关注service.enqueueToast(pkg, tn, mDuration);这行代码。点进getService()看到：
static private INotificationManager getService() {
if (sService != null) {
return sService;
}
sService = INotificationManager.Stub.asInterface(ServiceManager.getService("notification"));
return sService;
}
看到Stub.asInterface，我们知道这是利用Binder进行跨进程调用了。百度上看到说INotificationManager service = getService()返回的就是NotificationManagerService，我也不知道怎么根据源码来确定是NotificationManagerService类实现了enqueueToast()方法，姑且就相信吧。功力有待加强。好惨好气。
而TN类就是遵循AIDL的实现。接着我们看看TN类。TN类内部使用Handler机制，post一个mShow和mHide：
private static class TN extends ITransientNotification.Stub {
//省略部分代码
/**
* schedule handleShow into the right thread
*/
@Override
public void show() {
if (localLOGV) Log.v(TAG, "SHOW: " + this);
//下方有mShow的代码
mHandler.post(mShow);
}
/**
* schedule handleHide into the right thread
*/
@Override
public void hide() {
if (localLOGV) Log.v(TAG, "HIDE: " + this);
mHandler.post(mHide);
}
//mShow的代码
final Runnable mShow = new Runnable() {
@Override
public void run() {
handleShow();
}
};
final Runnable mHide = new Runnable() {
@Override
public void run() {
handleHide();
// Don't do this in handleHide() because it is also invoked by handleShow()
mNextView = null;
}
};
}
快速浏览一下handleShow()方法的实现。通过WindowManager的addView方法实现Toast的添加。其中trySendAccessibilityEvent()方法会把当前的类名、应用的包名通过AccessibilityManager来做进一步的分发，以供后续的处理。代码就不贴了。
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;
mParams.removeTimeoutMilliseconds = mDuration ==
Toast.LENGTH_LONG ? LONG_DURATION_TIMEOUT : SHORT_DURATION_TIMEOUT;
if (mView.getParent() != null) {
if (localLOGV) Log.v(TAG, "REMOVE! " + mView + " in " + this);
mWM.removeView(mView);
}
if (localLOGV) Log.v(TAG, "ADD! " + mView + " in " + this);
mWM.addView(mView, mParams);
trySendAccessibilityEvent();
}
}
看到这里，我们其实可以知道为了让设备显示出Toast，TN类的show()方法一定是在哪里被调起过。我们关键要找一下到底哪里被调到。我Ctrl+F搜了一下Toast类，并没有看到show()哪里被调用，倒是发现hide()又被调用过。
于是乎我只好回过头看看NotificationManagerService类里的enqueueToast()方法,发现答案就在这个方法里面！
public void enqueueToast(String pkg, ITransientNotification callback, int duration)
{
//省略部分代码
// (1) 判断是否为系统Toast。如果当前Toast所属的进程的包名为“android”，则为系统Toast，
//否则还可以调用isCallerSystem()方法来判断。
final boolean isSystemToast = isCallerSystem() || ("android".equals(pkg));
synchronized (mToastQueue) {
int callingPid = Binder.getCallingPid();
long callingId = Binder.clearCallingIdentity();
try {
ToastRecord record;
int index = indexOfToastLocked(pkg, callback);
// If it's already in the queue, we update it in place, we don't
// move it to the end of the queue.
//如果它已经在队列中，我们更新它，而不是将它放在队列后头
if (index >= 0) {
record = mToastQueue.get(index);
record.update(duration);
} else {
// Limit the number of toasts that any given package except the android
// package can enqueue. Prevents DOS attacks and deals with leaks.
//限制toast的数量
//如果是非系统的Toast（通过应用包名进行判断），且Toast的总数大于等于50，不再把新的Toast放入队列。
//MAX_PACKAGE_NOTIFICATIONS的值为50
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)方法来设置对应的进程为前台进程，保证不被销毁。保证不会系统杀死。这也就解释了为什么当我们finish当前Activity时，Toast还可以显示，因为当前进程还在执行。
(4) index为0时，对队列头的Toast进行显示。源码如下：
keepProcessAliveLocked(callingPid);
}
// If it's at index 0, it's the current toast. It doesn't matter if it's
// new or just been updated. Call back and tell it to show itself.
// If the callback fails, this will remove it from the list, so don't
// assume that it's valid after this.
//如果index = 0，说明Toast就处于队列的头部，直接进行显示。
if (index == 0) {
//注意这里！点进去看看有没有我们要的show()方法调用！
showNextToastLocked();
}
} finally {
Binder.restoreCallingIdentity(callingId);
}
}
}
辛苦了各位，看到了这里，最后我们点进showNextToastLocked()方法看看：
void showNextToastLocked() {
ToastRecord record = mToastQueue.get(0);
while (record != null) {
if (DBG) Slog.d(TAG, "Show pkg=" + record.pkg + " callback=" + record.callback);
try {
//我在这我在这！看我看我！！！
record.callback.show();
scheduleTimeoutLocked(record);
return;
} catch (RemoteException e) {
Slog.w(TAG, "Object died trying to show notification " + record.callback
+ " in package " + record.pkg);
// remove it from the list and let the process die
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;
}
}
}
}
终于找到show()方法被调用的地方啦，差点我就放弃啦。好像网上并没有很多人分析过Toast源码，估计是司空见惯，或者说觉得太容易了吧，但我觉得多看点源码还是好的。希望能因此提高自己的阅读源码能力。
所以 ，为什么Toast不能直接在子线程中显示，要用runOnUiThread处理一下？
Handler不能在子线程里运行的，因为子线程没有创建Looper.prepare(); 所以就报错了。主线程不需要调用，是因为主线程已经默认帮你调用了。
除了runOnUiThread外，还有一种解决方案就是缺什么补什么——
new Thread(){
@Override
public void run() {
super.run();
Looper.prepare();
try {
Toast.makeText(MainActivity.this,title,Toast.LENGTH_SHORT).show();
}catch (Exception e) {
Logger.e("error",e.toString());
}
Looper.loop();
}
}.start();
最后，用一张序列图展示整个调用流程：
再文字讲两句：
如果当前Toast所属的进程的包名为“android”，则为系统Toast，否则还可以调用isCallerSystem()方法来；判断当前Toast所属进程的uid是否为SYSTEM_UID、0、PHONE_UID中的一个，如果是，则为系统Toast;如果不是，则不为系统Toast。 是否为系统Toast。系统Toast一定可以进入到系统Toast队列中，不会被黑名单阻止。系统Toast在系统Toast队列中没有数量限制，而普通pkg所发送的Toast在系统Toast队列中有数量限制。
查看将要入队的Toast是否已经在系统Toast队列中。这是通过比对pkg和callback来实现的。
将当前Toast所在进程设置为前台进程,这里的mAm=ActivityManagerNative.getDefault()，调用了setProcessForeground方法将当前pid的进程置为前台进程，保证不会系统杀死。这也就解释了为什么当我们finish当前Activity时，Toast还可以显示，因为当前进程还在执行。
参考地址：彻底理解Toast原理和解决小米MIUI系统上没法弹Toast的问题