一、Handler简介
我们知道,Android为了确保UI操作的线程安全,规定所有的UI操作都必须在主线程(UI线程)中执行,比如更新界面元素的显示,响应用户的点击事件等,但是有时候我们必须执行一些耗时的操作,比如网络请求或者读写文件等,当耗时操作完成后我们需要更新UI提示用户,在这种情况下,我们是不能将耗时操作直接在UI线程中执行的,因为这样会阻塞UI线程,导致UI线程无法及时更新界面元素或者响应用户,这样就会造成界面卡顿,如果阻塞时间过长,还会导致ANR,Android规定,Activity如果5秒之内无法响应用户的操作,或者BroadcastReceiver如果10秒之内还未执行完操作,就会出现ANR。也就是说,我们即不能在UI线程中执行耗时操作,又必须在UI线程中执行UI相关的操作,这样就必须让线程之间能够通信,我们开启一个子线程来执行耗时操作,在耗时操作完成后,子线程向UI线程发送一个消息通知UI线程,UI线程接受到消息后,执行相关的UI操作。在Android中,线程之间的通信采用的机制就是Handler机制,Handler能够方便的切换执行任务的线程。
二、Handler的基本用法
下面模拟开启一个子线程执行耗时任务后更新UI的操作,代码如下:
import android.os.Bundle;
import android.os.Handler;
import android.os.Message;
import android.support.v7.app.AppCompatActivity;
import android.util.Log;
import android.view.View;
import android.widget.Button;
import android.widget.TextView;
import com.liunian.androidbasic.R;
import java.lang.ref.WeakReference;
public class HandlerTestActivity extends AppCompatActivity {
public static String TAG = "HandlerTestActivity";
TextView mShowTextView;
Button mStartDownLoadButton;
private Handler mHandler;
@Override
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.activity_handler_test);
mHandler = new MyHandler(this);
mShowTextView = (TextView) findViewById(R.id.show_text);
mStartDownLoadButton = (Button) findViewById(R.id.start_download);
mStartDownLoadButton.setOnClickListener(new View.OnClickListener() {
@Override
public void onClick(View v) {
new DownloadImageThread(mHandler).start();
}
});
}
@Override
protected void onDestroy() {
super.onDestroy();
// 在Activity销毁后移除Handler中未处理完的消息,避免内存泄露或者发生引用错误
mHandler.removeMessages(DownloadImageThread.DOWNLOAD_IMAGE_FINISH);
}
// Handler类,声明为static,避免持有外部类的直接引用,防止内存泄露
private static class MyHandler extends Handler {
private WeakReference<HandlerTestActivity> activityWeakReference; // 持有外部类的弱引用
public MyHandler(HandlerTestActivity activity) {
activityWeakReference = new WeakReference<HandlerTestActivity>(activity);
}
@Override
public void handleMessage(Message msg) {
switch (msg.what) {
case DownloadImageThread.DOWNLOAD_IMAGE_FINISH: // 处理下载完成消息,更新UI
HandlerTestActivity handlerTestActivity = activityWeakReference.get();
if (handlerTestActivity != null) {
handlerTestActivity.mShowTextView.setText((String)msg.obj);
}
break;
}
}
}
// 模拟下载图片的子线程
public static class DownloadImageThread extends Thread { // 将Thread声明为static,非静态内部类或者匿名类默认持有外部类对象的引用,容易造成内存泄露
public static final int DOWNLOAD_IMAGE_FINISH = 1;
private WeakReference<Handler> handlerWeakReference;
public DownloadImageThread(Handler handler) { // 采用弱引用的方式持有Activity中Handler对象的引用,避免内存泄露
handlerWeakReference = new WeakReference<Handler>(handler);
}
@Override
public void run() {
Log.i(TAG, "子线程开始下载图片");
// 模拟下载图片
for (int i=1; i<=100; i++) {
try {
Thread.sleep(60);
Log.i(TAG, "下载进度:" + i + "%");
} catch (InterruptedException e) {
e.printStackTrace();
}
}
Log.i(TAG, "子线程下载图片完成");
// 发送消息通知UI线程下载完毕
Message message = Message.obtain();
message.what = DOWNLOAD_IMAGE_FINISH;
message.obj = "图片下载完成";
Handler handler = handlerWeakReference.get();
if (handler != null) {
handler.sendMessage(message);
}
}
}
}
上面是使用Handler更新UI的典型用法,要注意两点:
1、不要使用匿名类或者非静态内部类,因为它们默认持有外部类对象的引用,这样当Activity调用onDestory后,如果Handler中的消息还没有处理完毕(消息对象持有Handler的引用),或者Thread没有执行完毕,Activity对象就会被内部类或匿名类的对象所引用,从而导致Activity对象无法被GC回收,产生内存泄露。所以我们要采用静态内部类,用弱引用的方式持有外部类的引用,避免内存泄露。
2、在onDestroy中调用Handler的removeMessages或者removeCallbacks方法,移除Handler中未处理完的消息,避免在 onDestroy 方法中释放了一些资源,此时Handler 执行到 handlerMessage 方法,但相关资源已经被释放,从而引起异常,或者我们可以给handlerMessage加上try catch来避免空指针异常。
匿名类或者非静态内部类使用Handler造成内存泄露的引用链如下:
主线程Thread对象->主线程Looper对象->Looper对象持有的MessageQueue对象->Message对象->Handler对象->Activity(或其他外部类)对象
只有Message从消息队列取出被消耗了,引用链才会断开。
三、Hander机制
Android的消息机制主要是指Handler机制,Handler的运行需要底层的MessageQueue和Looper的支撑。MessageQueue即消息队列,它的内部存储了一组消息,以队列的形式对外提供插入和删除的操作;MessageQueue只是一个消息的存储单元,它并不会去处理消息,而Looper就填补了这个功能,其内部会以无限循环的方式去查找消息队列里面是否有消息,如果有的话就处理消息,否则就一直等待。我们在创建Handler时,必须为Handler指定Looper对象,后面该Handler发送的消息就都由Looper对象处理,如果没有指定Looper,默认使用当前线程的Looper对象,如果当前线程没有Looper对象,则创建Handler将会报错,线程默认是没有Looper的,之所以可以在UI线程中创建Handler不指定Looper,是因为UI线程在ActivityThread的入口函数中已经初始化了Looper。下面我们从源码入手,一起来分析一下Handler机制。
先来看一下Handler机制的图解:
1、创建Handler
首先,我们开启一个子线程,并且在子线程中new 一个Handler对象,如下:
new Thread(new Runnable() {
@Override
public void run() {
Handler handler = new Handler();
}
}).start();
运行程序,发现直接闪退,报错内容如下:
07-21 17:31:52.275 31302-616/? E/AndroidRuntime: FATAL EXCEPTION: Thread-1307
Process: com.liunian.androidbasic, PID: 31302
java.lang.RuntimeException: Can't create handler inside thread that has not called Looper.prepare()
at android.os.Handler.<init>(Handler.java:200)
at android.os.Handler.<init>(Handler.java:114)
at com.liunian.androidbasic.handlertest.HandlerTestActivity$2.run(HandlerTestActivity.java:37)
at java.lang.Thread.run(Thread.java:818)
提示不能在没有调用Looper.prepare()的线程中创建Handler,为什么会这样呢?打开Handler源码:
public Handler() {
this(null, false);
}
public Handler(Callback callback, boolean async) {
if (FIND_POTENTIAL_LEAKS) {
final Class<? extends Handler> 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(); // 调用Looper.myLooper(),获得当前线程的Looper对象
if (mLooper == null) { // 如果没有Looper对象则会抛出异常
throw new RuntimeException(
"Can't create handler inside thread that has not called Looper.prepare()");
}
mQueue = mLooper.mQueue; // 存储当前线程Looper的MessageQueue对象
mCallback = callback;
mAsynchronous = async;
}
很明显,通过Looper.myLooper()获得当前线程的Looper对象时,没有找到当前线程的Looper对象,所以创建Handler时就抛出了异常。Looper.myLooper()的代码:
/**
* Return the Looper object associated with the current thread. Returns
* null if the calling thread is not associated with a Looper.
*/
public static @Nullable Looper myLooper() {
return sThreadLocal.get(); // 从ThreadLocal对象中取出当前线程的Looper
}
我们继续分析Looper.prepare()的代码:
public static void prepare() {
prepare(true);
}
private static void prepare(boolean quitAllowed) {
if (sThreadLocal.get() != null) { // 如果当前线程已经有了Looper对象,再次调用prepare会抛出异常
throw new RuntimeException("Only one Looper may be created per thread");
}
sThreadLocal.set(new Looper(quitAllowed)); // 生成一个Looper对象,并与当前线程关联起来
}
可以看到,Looper.prepare()会生成一个Looper对象,通过ThreadLocal与当前线程关联起来,ThreadLocal是一个线程内部的数据存储类,通过它可以在指定的线程中存储数据,后面我们会分析它的原理,通过代码我们还可以知道,一个线程只能调用一次Looper.prepare(),多次调用会抛出异常。
2、ThreadLocal的工作原理
ThreadLocal是一个线程内部的数据存储类,通过它可以在指定的线程中存储数据,数据存储后,只有在指定线程中可以获得到存储的数据,对于其他线程来说则无法获取。一般来说,当某些数据是以线程为作用域并且不同线程有不同的数据副本时,就可以考虑采用ThreadLocal。比如对于Looper来说,它的作用域就是线程,不同的线程可以拥有0个到1个Looper对象,通过ThreadLocal,我们可以很轻松的获得当前线程的Looper对象。下面看一下ThreadLocal的用法,以Looper为例:
a、创建ThreadLocal对象
static final ThreadLocal<Looper> sThreadLocal = new ThreadLocal<Looper>();
b、设置当前线程的Looper对象
sThreadLocal.set(new Looper(quitAllowed));
c、获得当前线程的Looper对象
sThreadLocal.get()
代码非常简单,下面我们分析一下ThreadLocal的源码:
1、构造方法
public ThreadLocal() {
}
构造方法没有做任何处理
2、set方法
public void set(T value) {
Thread t = Thread.currentThread(); // 获得当前线程对象
ThreadLocalMap map = getMap(t); // 获得当前线程对应的ThreadLocalMap
if (map != null)
map.set(this, value); // 如果当前线程有ThreadLocalMap对象,则直接将数据存储在map中
else
createMap(t, value); // 如果当前线程没有ThreadLocalMap对象,则创建一个ThreadLocalMap对象并将数据存储在map中
}
通过上面的代码我们发现,ThreadLocal在存储数据时,会先获得当前线程的ThreadLocalMap对象,并且将数据存储在其中,存储是以ThreadLocal对象为key,以实际存储数据为value,不同的线程有不同的ThreadLocalMap对象,这样就确保了每个线程的数据不会相互干扰。
3、getMap方法
ThreadLocalMap getMap(Thread t) {
return t.threadLocals; // 返回线程对象中的threadLocals
}
public class Thread implements Runnable {
ThreadLocal.ThreadLocalMap threadLocals = null; // 在线程类中有声明ThreadLocalMap对象
}
从这里可以看到,getMap方法其实就是获得线程中声明的ThreadLocalMap对象,每一个线程都维护着自己的的ThreadLocalMap
4、createMap方法
void createMap(Thread t, T firstValue) {
t.threadLocals = new ThreadLocalMap(this, firstValue);
}
ThreadLocalMap(ThreadLocal firstKey, Object firstValue) { // 已ThreadLocal对象作为key,以需要存储的值作为value保存数据
table = new Entry[INITIAL_CAPACITY];
int i = firstKey.threadLocalHashCode & (INITIAL_CAPACITY - 1);
table[i] = new Entry(firstKey, firstValue);
size = 1;
setThreshold(INITIAL_CAPACITY);
}
createMap方法会创建一个ThreadLocalMap对象并且将值存储在其中
5、get方法
public T get() {
Thread t = Thread.currentThread(); // 获得当前线程
ThreadLocalMap map = getMap(t); // 获得当前线程的ThreadLocalMap对象
if (map != null) { // 从当前线程中的ThreadLocalMap对象中取出对应的值并返回
ThreadLocalMap.Entry e = map.getEntry(this);
if (e != null)
return (T)e.value;
}
return setInitialValue();
}
6、ThreadLocalMap存储数据的方式
在上面的代码中,我们知道ThreadLocal会将数据保存在当前线程的ThreadLocalMap对象中,保存时会以ThreadLocal对象作为key,以要保存的对象作为value,取出数据时,则会以ThreadLocal对象作为索引,找到当前的线程的ThreadLocalMap对象中保存的数据。
3、Looper.loop()方法
下面我们开启一个线程,在该线程下创建Looper和Handler,并且开启另外一个线程给其发送一个消息,代码如下:
private HandlerTestThread mHandlerTestThread;
private class HandlerTestThread extends Thread {
public Handler mHandler;
@Override
public void run() {
Log.i(TAG, "HandlerTestThread start"); // 线程开始
Looper.prepare();
mHandler = new Handler() {
@Override
public void handleMessage(Message msg) {
Log.i(TAG, "handlerMessage"); // 处理消息
}
};
Log.i(TAG, "HandlerTestThread end"); // 线程结束
}
}
@Override
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.activity_handler_test);
mHandlerTestThread = new HandlerTestThread();
mHandlerTestThread.start();
new Thread(new Runnable() {
@Override
public void run() {
try {
Thread.sleep(1000); // 休眠一秒在发送消息,确保HandlerTestThread线程已经启动
} catch (InterruptedException e) {
e.printStackTrace();
}
Message message = Message.obtain();
mHandlerTestThread.mHandler.sendMessage(message); // 发送一个消息
}
}).start();
}
运行程序,打印日志如下:
07-26 14:30:42.043 324-398/? I/HandlerTestActivity: HandlerTestThread start
07-26 14:30:42.043 324-398/? I/HandlerTestActivity: HandlerTestThread end
通过日志可以发现,HandlerTestThread在启动之后立马就结束了,并没有处理另外一个子线程发送过来的消息,我们可以想一下,既然HandlerTestThread要处理消息,那么其必然不能结束,并且应该处于等待状态,一旦有消息过来立马处理,我们在调用Looper.prepare()时仅仅是为当前线程创建了一个Looper对象,而要让Looper正式开始工作,还需要调用Looper.loop()方法,如下:
private class HandlerTestThread extends Thread {
public Handler mHandler;
@Override
public void run() {
Log.i(TAG, "HandlerTestThread start");
Looper.prepare();
mHandler = new Handler() {
@Override
public void handleMessage(Message msg) {
Log.i(TAG, "handlerMessage");
}
};
Looper.loop(); // 让Looper开始工作
Log.i(TAG, "HandlerTestThread end");
}
}
打印日志如下:
07-26 14:43:04.890 2841-3133/? I/HandlerTestActivity: HandlerTestThread start
07-26 14:43:05.891 2841-3133/? I/HandlerTestActivity: handlerMessage
通过日志,可以看到Handler成功处理了发送过来的消息,并且线程没有结束,这是因为Looper.loop()会构造一个循环系统,随时监控消息队列中是否有消息需要处理,如果有则立马处理,如果没有,则会阻塞线程直到有消息需要处理;除非我们调用相应的退出循环的方法,线程才能结束。
下面我们一起分析一下Looper.loop()的源码:
public static void loop() {
final Looper me = myLooper(); // 获得当前线程的Looper对象
if (me == null) {
throw new RuntimeException("No Looper; Looper.prepare() wasn't called on this thread.");
}
final MessageQueue queue = me.mQueue; // 获得消息队列
// Make sure the identity of this thread is that of the local process,
// and keep track of what that identity token actually is.
Binder.clearCallingIdentity();
final long ident = Binder.clearCallingIdentity();
// 开启循环
for (;;) {
Message msg = queue.next(); // might block从队列中获得消息,如果没有消息将会阻塞
if (msg == null) {
// No message indicates that the message queue is quitting.
return;
}
// This must be in a local variable, in case a UI event sets the logger
final Printer logging = me.mLogging;
if (logging != null) {
logging.println(">>>>> Dispatching to " + msg.target + " " +
msg.callback + ": " + msg.what); // 开始处理消息的日志打印
}
final long traceTag = me.mTraceTag;
if (traceTag != 0 && Trace.isTagEnabled(traceTag)) {
Trace.traceBegin(traceTag, msg.target.getTraceName(msg));
}
try {
msg.target.dispatchMessage(msg); // 处理消息
} finally {
if (traceTag != 0) {
Trace.traceEnd(traceTag);
}
}
if (logging != null) {
logging.println("<<<<< Finished to " + msg.target + " " + msg.callback); // 处理消息完成的日志打印
}
// Make sure that during the course of dispatching the
// identity of the thread wasn't corrupted.
final long newIdent = Binder.clearCallingIdentity();
if (ident != newIdent) {
Log.wtf(TAG, "Thread identity changed from 0x"
+ Long.toHexString(ident) + " to 0x"
+ Long.toHexString(newIdent) + " while dispatching to "
+ msg.target.getClass().getName() + " "
+ msg.callback + " what=" + msg.what);
}
msg.recycleUnchecked(); // 回收消息对象,可以利用Message.obtain()重复利用消息对象
}
}
可以看到,loop方法会构造一个循环,然后从消息队列中取出消息并处理,处理完成后回收消息对象,如果消息队列中没有消息则MessageQueue.next会阻塞线程直到有新的消息需要处理。
这里有一个注意的点,我们可以看到在调用dispatchMessage处理消息前后都会打印日志,打印对象可以自行设置,Looper提供了如下方法:
public void setMessageLogging(@Nullable Printer printer) {
mLogging = printer;
}
注意,这是一个public方法,也就是开发者也可以调用,那么我们是不是可以利用这一点来统计每一个Message的处理时间呢?获得消息处理前的系统时间和处理后的系统时间,两者相减就能知道本次消息的处理时间,这样,我们就能知道哪些消息的处理是比较耗时的操作,我们可以利用这一方式来检测UI线程的卡顿情况,主要原理就是利用Looper的Printer获得每一个消息的处理时间,如果发现某个消息处理太耗时了,那么肯定会造成主线程卡顿,卡顿检测框架BlockCanary就是这个原理,下面是它的核心代码:
class LooperMonitor implements Printer { // 自定义Looper的Printer,检测卡顿
@Override
public void println(String x) {
if (!mPrintingStarted) {
mStartTimestamp = System.currentTimeMillis(); // 记录当前时间为处理消息前时间
mStartThreadTimestamp = SystemClock.currentThreadTimeMillis();
mPrintingStarted = true;
startDump(); // 收集主线程堆栈、CPU等信息,在子线程中处理
} else {
final long endTime = System.currentTimeMillis(); // // 记录当前时间为处理消息后时间
mPrintingStarted = false;
if (isBlock(endTime)) { // 判断处理当前消息是否耗时,如果耗时则显示通知
notifyBlockEvent(endTime);
}
stopDump(); // 停止收集主线程堆栈、CPU等信息
}
}
private boolean isBlock(long endTime) {
return endTime - mStartTimestamp > mBlockThresholdMillis; // 处理消息时间是否大于某个阈值
}
// ignore other codes...
}
Looper.getMainLooper().setMessageLogging(mBlockCanaryCore.monitor); // 给主线程Looper对象设置自定义的Printer对象,mBlockCanaryCore.monitor是LooperMonitor类的对象
4、MessageQueue
顾名思义,MessageQueue的中文含义表示消息队列,它的作用是用来存储消息对象的,并且提供相应的插入、取出操作,首先我们看一下Handler的sendMessage方法:
public final boolean sendMessage(Message msg)
{
return sendMessageDelayed(msg, 0);
}
public final boolean sendMessageDelayed(Message msg, long delayMillis)
{
if (delayMillis < 0) {
delayMillis = 0;
}
return sendMessageAtTime(msg, SystemClock.uptimeMillis() + delayMillis);
}
public boolean sendMessageAtTime(Message msg, long uptimeMillis) {
MessageQueue queue = mQueue; // mQueue是创建Handler的线程的消息队列对象
if (queue == null) {
RuntimeException e = new RuntimeException(
this + " sendMessageAtTime() called with no mQueue");
Log.w("Looper", e.getMessage(), e);
return false;
}
return enqueueMessage(queue, msg, uptimeMillis); // 将消息插入到消息队列
}
private boolean enqueueMessage(MessageQueue queue, Message msg, long uptimeMillis) { // 最终都是调用这个方法插入消息
msg.target = this; // 让消息对象的target指向当前Handler对象,这里需要注意,Message就是在这里持有Handler的引用的
if (mAsynchronous) {
msg.setAsynchronous(true);
}
return queue.enqueueMessage(msg, uptimeMillis); // 将消息插入到消息队列中
}
可以看到,Handler的sendMessage方法最终都是调用了MessageQueue的enqueueMessage方法,将消息插入到消息队列中。
1、MessageQueue.enqueueMessage
boolean enqueueMessage(Message msg, long when) {
if (msg.target == null) { // 每个消息都需要有target对象,这个target就是最终处理消息的Handler对象
throw new IllegalArgumentException("Message must have a target.");
}
if (msg.isInUse()) {
throw new IllegalStateException(msg + " This message is already in use.");
}
synchronized (this) { // 加上控制锁,保证线程安全
if (mQuitting) { // 如果消息循环已经退出,将不会将消息插入到队列中
IllegalStateException e = new IllegalStateException(
msg.target + " sending message to a Handler on a dead thread");
Log.w(TAG, e.getMessage(), e);
msg.recycle();
return false;
}
msg.markInUse(); // 标记该消息对象已经插入到了消息队列中
msg.when = when;
Message p = mMessages; // 消息队列中第一个要处理的消息(优先级最高的消息),消息队列是以链表的形式存储的
boolean needWake;
if (p == null || when == 0 || when < p.when) { // 如果消息队列为空,或者当前消息的优先级大于消息队列中优先级最高的消息,则将当前消息设置为优先级最高的消息
// New head, wake up the event queue if blocked.
msg.next = p; // 指向下一个消息
mMessages = msg; // 最为优先级最高的消息
needWake = mBlocked; // 如果线程被阻塞了,则需要将其唤醒
} else {
// Inserted within the middle of the queue. Usually we don't have to wake
// up the event queue unless there is a barrier at the head of the queue
// and the message is the earliest asynchronous message in the queue.
needWake = mBlocked && p.target == null && msg.isAsynchronous();
Message prev;
for (;;) { // 找到消息队列中第一个优先级小于当前消息的消息
prev = p;
p = p.next;
if (p == null || when < p.when) {
break;
}
if (needWake && p.isAsynchronous()) {
needWake = false;
}
}
// 将消息插入按照优先级顺序插入到消息队列中
msg.next = p; // invariant: p == prev.next
prev.next = msg;
}
// We can assume mPtr != 0 because mQuitting is false.
if (needWake) { // 判断线程是否需要重新被唤醒,如果需要则将线程唤醒
nativeWake(mPtr);
}
}
return true;
}
从上面的代码中,可以看出,消息队列其实是以链表的形式来存储消息,每次插入消息时,都会判断队列中消息的优先级,并将消息插入到对应的位置,链表的优点是插入和删除数据效率高,只需要修改指针的引用关系即可。
2、MessageQueue.next()
在Looper中会调用MessageQueue.next()方法来从消息队列中取出需要处理的消息,MessageQueue.next()的源码如下:
Message next() {
// Return here if the message loop has already quit and been disposed.
// This can happen if the application tries to restart a looper after quit
// which is not supported.
final long ptr = mPtr; // 这个是和native方法交流的指针
if (ptr == 0) {
return null;
}
int pendingIdleHandlerCount = -1; // -1 only during first iteration
int nextPollTimeoutMillis = 0;
for (;;) {
if (nextPollTimeoutMillis != 0) {
Binder.flushPendingCommands();
}
nativePollOnce(ptr, nextPollTimeoutMillis); // 调用native方法阻塞线程nextPollTimeoutMillis毫秒,-1表示一直阻塞直到调用了唤醒方法
synchronized (this) {
// Try to retrieve the next message. Return if found.
final long now = SystemClock.uptimeMillis(); // 获得当前时间
Message prevMsg = null;
Message msg = mMessages; // 队列中优先级最高的消息
if (msg != null && msg.target == null) { // 如果优先级最高的消息没有处理它的目标(Handler),则表明其是一个异步消息,我们通过Handler发送的消息都是同步消息,这个在Handler的enqueueMessage方法中可以看到,这里会一直循环知道找到一个同步消息
// Stalled by a barrier. Find the next asynchronous message in the queue.
do {
prevMsg = msg;
msg = msg.next;
} while (msg != null && !msg.isAsynchronous());
}
if (msg != null) {
if (now < msg.when) { // 如果当前时间小于消息开始执行的时间,则设置阻塞时间为开始执行的时间减去当前时间
// Next message is not ready. Set a timeout to wake up when it is ready.
nextPollTimeoutMillis = (int) Math.min(msg.when - now, Integer.MAX_VALUE);
} else { // 否则从队里中取出这条消息并返回
// Got a message.
mBlocked = false; // 设置阻塞状态为非阻塞,因为马上会调用return方法结束该方法
// 从队里中移除该消息并返回
if (prevMsg != null) {
prevMsg.next = msg.next;
} else {
mMessages = msg.next;
}
msg.next = null;
if (DEBUG) Log.v(TAG, "Returning message: " + msg);
msg.markInUse();
return msg;
}
} else { // 没有消息
// No more messages.
nextPollTimeoutMillis = -1;
}
// Process the quit message now that all pending messages have been handled.
if (mQuitting) { // 如果退出了Looper循环则直接返回空
dispose();
return null;
}
// If first time idle, then get the number of idlers to run.
// Idle handles only run if the queue is empty or if the first message
// in the queue (possibly a barrier) is due to be handled in the future.
if (pendingIdleHandlerCount < 0
&& (mMessages == null || now < mMessages.when)) {
pendingIdleHandlerCount = mIdleHandlers.size();
}
if (pendingIdleHandlerCount <= 0) {
// No idle handlers to run. Loop and wait some more.
mBlocked = true;
continue;
}
if (mPendingIdleHandlers == null) {
mPendingIdleHandlers = new IdleHandler[Math.max(pendingIdleHandlerCount, 4)];
}
mPendingIdleHandlers = mIdleHandlers.toArray(mPendingIdleHandlers);
}
// Run the idle handlers.
// We only ever reach this code block during the first iteration.
for (int i = 0; i < pendingIdleHandlerCount; i++) {
final IdleHandler idler = mPendingIdleHandlers[i];
mPendingIdleHandlers[i] = null; // release the reference to the handler
boolean keep = false;
try {
keep = idler.queueIdle();
} catch (Throwable t) {
Log.wtf(TAG, "IdleHandler threw exception", t);
}
if (!keep) {
synchronized (this) {
mIdleHandlers.remove(idler);
}
}
}
// Reset the idle handler count to 0 so we do not run them again.
pendingIdleHandlerCount = 0;
// While calling an idle handler, a new message could have been delivered
// so go back and look again for a pending message without waiting.
nextPollTimeoutMillis = 0;
}
}
从上面的代码中,可以看出,Message的next()方法也是一个循环,退出循环的条件是有符合条件的消息出现,或者Looper结束了工作,在循环中,首先会找到消息队列中优先级最高的消息,如果没有消息,则会一直阻塞线程直到有新的消息加入唤醒线程才会继续工作;如果有消息,则会将消息的开始执行时间和当前时间做比较,如果消息的开始执行时间小于或者等于当前时间,说明消息应该要执行了,则会将消息从队列中移除并返回该消息,loop循环中则会执行这条消息;如果消息的开始执行时间大于当前时间,则说明还没有到达消息开始执行的时间,这个时候就会用优先级最高的消息的开始执行时间减去当前时间,然后阻塞线程对应的时间。
MessageQueue的代码就分析到这里,MessageQueue是消息的存储单元,其内部是通过链表来实现的,并且提供了插入和取出消息的方法;在插入消息时,MessageQueue会计算消息的优先级(按照开始执行的时间),优先级越高的消息越靠前,在插入消息后,如果处理消息的线程阻塞,则会唤醒处理消息的线程。在取出消息时,MessageQueue会判断消息队列中是否有消息,如果没有消息则直接阻塞线程,如果有消息,则会取出当前优先级最高的消息,然后将消息的开始执行时间和当前时间做比较,如果消息的开始执行时间小于或者等于当前时间,说明消息应该要执行了,则会将消息从队列中移除并返回该消息,loop循环中则会执行这条消息;如果消息的开始执行时间大于当前时间,则说明还没有到达消息开始执行的时间,这个时候就会用优先级最高的消息的开始执行时间减去当前时间,然后阻塞线程对应的时间。这里要注意一点,MessageQueue插入消息可以在任何线程中执行,但是取出消息则只会在执行loop循环的线程中执行。
5、消息的处理
通过对Looper.loop的代码分析,我们知道,取出消息后,Looper是调用如下代码处理消息的:
msg.target.dispatchMessage(msg); // 处理消息
而msg.target就是我们发送消息的Handler,这个在Handler的enqueueMessage中可以看到:
private boolean enqueueMessage(MessageQueue queue, Message msg, long uptimeMillis) {
msg.target = this; // 让消息的target指向当前Handler对象
if (mAsynchronous) {
msg.setAsynchronous(true);
}
return queue.enqueueMessage(msg, uptimeMillis);
}
我们继续查看Handler的dispatchMessage方法:
public void dispatchMessage(Message msg) {
if (msg.callback != null) { // 如果message设置了callback,则优先调用callback处理消息
handleCallback(msg);
} else {
if (mCallback != null) { // 如果Handler设置了callback,则会调用Handler的callback处理消息,并且根据返回状态来决定是否要执行handleMessage方法
if (mCallback.handleMessage(msg)) {
return;
}
}
handleMessage(msg); // 调用Handler的handleMessage方法处理消息
}
}
private static void handleCallback(Message message) {
message.callback.run();
}
// 定义处理消息的接口
public interface Callback {
public boolean handleMessage(Message msg);
}
可以看到,Handler在处理消息时,首先会判断当前Message对象有没有设置callback,如果有设置,这直接调用Message的callback的run方法来处理消息;如果消息没有设置callback,则首先会判断自己是否有设置Callback,如果有,则调用自身Callback的handlerMessage方法来处理消息,并且根据返回状态来觉得是否继续执行Handler的HandlerMessage方法。
Handler处理消息流程图:
我们在调用Handler的post方法来发送消息时,其实就是构造了一个带callback的Message对象,然后插入到消息队列中,代码如下:
mHandlerTestThread.mHandler.post(new Runnable() {
@Override
public void run() {
}
});
public final boolean post(Runnable r)
{
return sendMessageDelayed(getPostMessage(r), 0);
}
private static Message getPostMessage(Runnable r) {
Message m = Message.obtain();
m.callback = r; // 构造一个带callback的Message对象
return m;
}
6、退出Looper循环
通过前面的分析我们知道,在线程中调用Looper.loop()开启当前线程的循环系统后,程序将会执行一个循环,如果不调用相应的退出方法,则无法退出循环,线程也无法结束,Looper提供了quit和quitSafely方法来退出循环:
public void quit() {
mQueue.quit(false);
}
public void quitSafely() {
mQueue.quit(true);
}
可以看到,这两个方法都是调用了MessageQueue的quit方法来退出循环:
void quit(boolean safe) {
if (!mQuitAllowed) { // 表示是否能够退出循环系统,只有主线程无法退出,其他线程都可以退出
throw new IllegalStateException("Main thread not allowed to quit.");
}
synchronized (this) {
if (mQuitting) {
return;
}
mQuitting = true; // 设置退出标识位为true
if (safe) { // 如果是安全退出,则会将消息队列中能够执行的消息都执行完
removeAllFutureMessagesLocked();
} else { // 如果不是安全退出,则直接清空消息队列中的消息
removeAllMessagesLocked();
}
// We can assume mPtr != 0 because mQuitting was previously false.
nativeWake(mPtr); // 唤醒线程
}
}
private void removeAllFutureMessagesLocked() { // 执行消息队列中当前时间可以执行的消息
final long now = SystemClock.uptimeMillis(); // 获取系统当前时间
Message p = mMessages; // 消息队列中优先级最高的消息
if (p != null) {
if (p.when > now) { // 如果优先级最高的消息的开始执行时间都大于当前时间,说明消息队列中当前时间没有可以执行的消息
removeAllMessagesLocked(); // 清空消息队列
} else {
// 执行消息队列中当前时间可以执行的消息并清空消息队列
Message n;
for (;;) {
n = p.next;
if (n == null) {
return;
}
if (n.when > now) {
break;
}
p = n;
}
p.next = null;
do {
p = n;
n = p.next;
p.recycleUnchecked();
} while (n != null);
}
}
}
private void removeAllMessagesLocked() { // 清空消息队列
Message p = mMessages;
while (p != null) {
Message n = p.next;
p.recycleUnchecked();
p = n;
}
mMessages = null;
}
可以看到,quit和quitSafely的差别在于,quit会直接退出清空消息队列并退出Looper循环,而quitSafely则会先执行消息队列中当前时间可以执行的消息在退出Looper循环。
在MessageQueue的quit方法中,会将退出标识位mQuitting设置为true并唤醒线程,这个时候MessageQueue的next方法就会继续执行,而在next方法中,有如下代码:
if (mQuitting) {
dispose();
return null;
}
直接返回一个空对象,而在Looper的loop方法中,又有如下代码:
for (;;) {
Message msg = queue.next(); // might block
if (msg == null) { // 如果消息返回为空,则直接退出循环
// No message indicates that the message queue is quitting.
return;
}
...
}
可以看到,如果MessageQueue.next()方法返回的消息对象为空,则loop方法会直接退出,这样就结束了循环系统。
四、主线程的循环系统
我们在主线程中使用Handler时,并没有调用Looper.prepare()方法来替主线程构造Looper对象,为什么主线程不用构造Looper对象呢?其实,主线程也是需要构造Looper对象并开启循环的,只不过这部分代码在主线程初始化的时候系统以及帮我们处理了,打开ActivityThread的源码,找到main方法:
public static void main(String[] args) {
...
Looper.prepareMainLooper(); // 构造主线程的Looper对象
...
Looper.loop(); // 开启主线程的loop循环
...
}
可以看到,主线程在初始化的时候就已经构造了循环系统,所有我们在主线程中使用Handler不需要再次构造循环系统,ActivityThread的main方法可以看做是一个应用的入口方法,其会初始化应用信息并开启主线程Looper循环,打开Looper.prepareMainLooper的源码:
public static void prepareMainLooper() {
prepare(false); // 这里传入的值是false,表示循环无法退出
synchronized (Looper.class) {
if (sMainLooper != null) {
throw new IllegalStateException("The main Looper has already been prepared.");
}
sMainLooper = myLooper();
}
}
主线程构造Looper对象时,也是调用的prepare(boolean)方法,在普通线程中,我们构造Looper对象使用的是Looper.prepare()方法:
public static void prepare() {
prepare(true); // 普通线程构造Looper对象传入的是true,表示可以退出循环系统
}
private static void prepare(boolean quitAllowed) { // 传入true表示可以退出循环系统,false表示无法退出
if (sThreadLocal.get() != null) {
throw new RuntimeException("Only one Looper may be created per thread");
}
sThreadLocal.set(new Looper(quitAllowed));
}
通过代码可以知道,主线程构造的Looper和普通线程构造的Looper的区别在于,主线程构造的Looper无法退出,除非应用被杀掉,而普通线程的Looper可以通过调用quit()或者quitSafely方法退出循环系统。从这点也可以看出,主线程其实就是一个Looper的死循环系统,不断的处理消息队列中的消息,主线程中所有进行的操作其实都是在Looper循环中执行的。比如界面的绘制、响应用户操作、Activity的生命周期回调方法执行等等。后面我们会详细分析Activity的启动过程和View的绘制过程。
五、Handler总结
1、Handler是Android中非常重要的消息通信机制,通过它可以方便的切换任务运行的线程;
2、Handler底层离不开Looper、MessageQueue、ThreadLocal的支撑,Looper用来构造循环系统,MessageQueue用来存储消息单元,ThreadLocal用来为每个线程创建独立的数据;
3、主线程运行是基于Handler机制,通过Looper构造一个无法退出的死循环,主线程中所有的操作都需要在Looper循环中执行,通过Handler,Android的主线程可以说是基于消息驱动的模式;
4、在平时的开发中,很多地方都需要使用Handler,比如网络请求、读写比较大的文件等等,为了确保主线程不被阻塞,这些耗时操作就必须在子线程中进行,而在任务完成后需要更新界面,而由于Android的UI线程保护机制,UI相关的操作必须在主线程中完成,所有这个时候就必须使用Handler了,所以一些常见的网络框架或者需要使用到线程切换的框架,都会用到Handler。
5、在创建Handler时,尽量不要用匿名类或者非静态内部类,因为它们默认持有外部类的引用,这样容易造成内存泄露。
六、拓展问题
上面我们对Handler进行了分析,知道了Handler的工作原理以及作用,这里有几个问题需要探讨一下:
1、主线程是一个无法退出的Looper循环,那么界面绘制、事件分发、Activity生命周期回调等操作是怎样交由给loop方法处理的?
根据前面了解的Handler机制,我们可以断定界面绘制、事件分发、Activity生命周期回调等所有需要主线程执行的操作最终都必须要封装成Message通过Handler交由给主线程的Looper对象的loop方法处理,那么这一流程是怎样的呢?
我们先来分析Activity的生命周期回调是怎样交由给主线程处理的,说到这个就需要我们了解Activity的启动流程了,我们通过startActivity启动一个Activity大致经历了如下过程:
整个过程比较复杂,这里,我们只关心AMS处理完成后,通过Binder机制调用ApplicationThread的scheduleLaunchActivity之后的逻辑:
scheduleLaunchActivity是AMS通过Binder机制调用的,所有其运行在Binder线程池中
@Override
public final void scheduleLaunchActivity(Intent intent, IBinder token, int ident,
ActivityInfo info, Configuration curConfig, Configuration overrideConfig,
CompatibilityInfo compatInfo, String referrer, IVoiceInteractor voiceInteractor,
int procState, Bundle state, PersistableBundle persistentState,
List<ResultInfo> pendingResults, List<ReferrerIntent> pendingNewIntents,
boolean notResumed, boolean isForward, ProfilerInfo profilerInfo) {
...
sendMessage(H.LAUNCH_ACTIVITY, r); // 发送一个消息给主线程处理
}
private void sendMessage(int what, Object obj) {
sendMessage(what, obj, 0, 0, false);
}
private void sendMessage(int what, Object obj, int arg1, int arg2, boolean async) {
if (DEBUG_MESSAGES) Slog.v(
TAG, "SCHEDULE " + what + " " + mH.codeToString(what)
+ ": " + arg1 + " / " + obj);
Message msg = Message.obtain();
msg.what = what;
msg.obj = obj;
msg.arg1 = arg1;
msg.arg2 = arg2;
if (async) {
msg.setAsynchronous(true);
}
mH.sendMessage(msg); // 通过Handler发送一个消息
}
来看一下mH的实现:
final H mH = new H(); // 创建H对象
private class H extends Handler {
...
public void handleMessage(Message msg) {
if (DEBUG_MESSAGES) Slog.v(TAG, ">>> handling: " + codeToString(msg.what));
switch (msg.what) {
case LAUNCH_ACTIVITY: { // 处理LAUNCH_ACTIVITY消息
Trace.traceBegin(Trace.TRACE_TAG_ACTIVITY_MANAGER, "activityStart");
final ActivityClientRecord r = (ActivityClientRecord) msg.obj;
r.packageInfo = getPackageInfoNoCheck(
r.activityInfo.applicationInfo, r.compatInfo);
handleLaunchActivity(r, null, "LAUNCH_ACTIVITY"); // 启动Activity
Trace.traceEnd(Trace.TRACE_TAG_ACTIVITY_MANAGER);
} break;
...
}
}
通过之前分析Handler的代码我们知道,如果构造Handler时不传入Looper,Handler将会使用当前线程的Looper对象,这里,mH对象的构造就没有指定Looper,它作为ActivityThread的成员变量,会和ActivityThread对象一起构造,再来看一下ActivityThread的main方法:
public static void main(String[] args) {
...
Looper.prepareMainLooper(); // 为主线程创建Looper对象
...
ActivityThread thread = new ActivityThread(); // 创建ActivityThread对象
thread.attach(false, startSeq);
if (sMainThreadHandler == null) {
sMainThreadHandler = thread.getHandler();
}
...
Looper.loop(); // 开启主线程Loop循环
throw new RuntimeException("Main thread loop unexpectedly exited");
}
可以看到,ActivityThread对象的创建是在主线程Looper对象创建之后,所以mH使用的Looper也就是主线程的Looper,也就是
handleLaunchActivity(r, null, "LAUNCH_ACTIVITY"); // 启动Activity
会在主线程中处理:
private void handleLaunchActivity(ActivityClientRecord r, Intent customIntent, String reason) {
...
Activity a = performLaunchActivity(r, customIntent); // 调用performLaunchActivity处理
...
}
private Activity performLaunchActivity(ActivityClientRecord r, Intent customIntent) {
// System.out.println("##### [" + System.currentTimeMillis() + "] ActivityThread.performLaunchActivity(" + r + ")");
...
Activity activity = null;
try {
java.lang.ClassLoader cl = appContext.getClassLoader(); // 加载了apk的ClassLoader
activity = mInstrumentation.newActivity(
cl, component.getClassName(), r.intent); // 通过反射创建Activity实例
...
} catch (Exception e) {
...
}
try {
...
if (r.isPersistable()) {
mInstrumentation.callActivityOnCreate(activity, r.state, r.persistentState); // 调用Activity的onCreate方法
} else {
mInstrumentation.callActivityOnCreate(activity, r.state); // 调用Activity的onCreate方法
}
...
mActivities.put(r.token, r);
} catch (SuperNotCalledException e) {
throw e;
} catch (Exception e) {
...
}
return activity;
}
performLaunchActivity方法首先会通过反射创建Activity实例,然后调用其onCreate方法完成onCreate的生命周期回调,在Instrumentation中:
public Activity newActivity(ClassLoader cl, String className,
Intent intent)
throws InstantiationException, IllegalAccessException,
ClassNotFoundException {
String pkg = intent != null && intent.getComponent() != null
? intent.getComponent().getPackageName() : null;
return getFactory(pkg).instantiateActivity(cl, className, intent); // 创建Activity实例
}
public @NonNull Activity instantiateActivity(@NonNull ClassLoader cl, @NonNull String className,
@Nullable Intent intent)
throws InstantiationException, IllegalAccessException, ClassNotFoundException {
return (Activity) cl.loadClass(className).newInstance(); // 通过反射创建类实例对象
}
public void callActivityOnCreate(Activity activity, Bundle icicle) {
prePerformCreate(activity);
activity.performCreate(icicle); // 调用Activity的performCreate方法
postPerformCreate(activity);
}
继续看Activity的performCreate方法:
final void performCreate(Bundle icicle) {
performCreate(icicle, null);
}
final void performCreate(Bundle icicle, PersistableBundle persistentState) {
mCanEnterPictureInPicture = true;
restoreHasCurrentPermissionRequest(icicle);
if (persistentState != null) {
onCreate(icicle, persistentState); // 调用onCreate方法完成Activity创建生命周期回调
} else {
onCreate(icicle); // 调用onCreate方法完成Activity创建生命周期回调
}
writeEventLog(LOG_AM_ON_CREATE_CALLED, "performCreate");
mActivityTransitionState.readState(icicle);
mVisibleFromClient = !mWindow.getWindowStyle().getBoolean(
com.android.internal.R.styleable.Window_windowNoDisplay, false);
mFragments.dispatchActivityCreated();
mActivityTransitionState.setEnterActivityOptions(this, getActivityOptions());
}
其他的生命周期函数的调用过程和onCreate是类似的,这里就不做分析了,通过上面的分析,我们知道了Activity的生命周期函数回调确实是在主线程中调用的,其实,了解了Activity的启动流程还是很有作用的,很多插件化框架比如VirtualApk就利用了Activity的启动流程,我们知道,正常情况下我们是不能启动未在AndroidManifest文件中注册的Activity的,我们安装一个应用时,其所有在AndroidManifest文件中注册的四大组件信息都会被PMS解析并保存,在启动Activity时,AMS会对要启动的Activity做校验,看该应用是否有权限启动对应的Activity,校验过程首先就是通过PMS查找对应的Activity,如果没有找到,则抛出错误信息给应用,应用就会抛出异常。了解Activity的启动流程后,我们就可以在这个流程上做一些文章来欺骗AMS启动未安装的Activity,大概有以下几个步骤:
1、注册代理Activity
首先,我们在主应用的AndroidManifest中注册代理Activity(Activity有四种启动模式,standard、singleTop、singleTask、singleInstance,其中标准模式每次都会创建新的Activity实例、其他三种模式都有可能要复用Activity实例,所以代理Activity standard模式只需要注册一个,其他三种模式需要注册多个,以免发生混乱);
2、欺骗AMS,绕过检测
应用启动Activity和AMS交互的流程是封装在Instrumentation的execStartActivity方法中,Instrumentation对象是在ActivityThread中创建的,并且所有的Activity都持有其引用,我们只需要在Application的onCreate方法中(这个时候还没有Activity创建)替换掉ActivityThread的Instrumentation对象,那么应用中所有Activity持有的Instrumentation都是我们替换过的Instrumentation,我们自定义一个Instrumentation类,重写其execStartActivity方法,在execStartActivity方法中获得要启动的Activity的启动模式,并根据启动模式找到合适的代理Activity,然后调用intent的setClassName将启动的Activity名称替换为代理Activity名,这样AMS检查时发现代理Activity是在主Apk中注册过的,也就能校验通过;
3、hook创建Activity的方法
Activity实例的创建封装在Instrumentation的newActivity方法中,我们重写自定义的Instrumentation的newActivity方法,将传入的Class(代理Activity类)替换成插件Activity类,这样在创建Activity时就会创建插件Activity的实例,于是真正启动的就是插件Activity了。Hook方式不仅可以Hook Instrumentation,还可以Hook AMS的代理等,总之只要是在这条线欺骗过了AMS即可。
插件化还是挺复杂的,上面只是介绍了其对AMS的欺骗过程,主要需要解决以下几个问题:
- 需要加载未安装APK的代码;
- 需要解读未安装APK中的资源;
- 绕过AMS中的检查机制,启动未安装APK中的四大组件。
这里不做详细分析了。
上面我们分析了Activity的生命周期回调是在主线程中调用的,接下来分析界面绘制是如何通过Handler在主线程完成,我们知道,Activity的界面其实是交由给Window来处理的,而每一个Window都有对应着一个View和ViewRootImpl对象,其中View是控件树的根节点,界面的具体内容就是有控件树决定的,而ViewRootImpl可以看做是连接控件树和系统层(主要是WMS、Chrographer等)的桥梁,我们从Activity的setContentView开始分析:
public void setContentView(@LayoutRes int layoutResID) {
getWindow().setContentView(layoutResID); // 其实是调用Window的setContentView
initWindowDecorActionBar();
}
Activity的setContentView其实是调用它对应的Window的setContentView,这里的Window唯一实现是PhoneWindow,其主要会生成Window对应的View(DecorView),并根据系统版本和Activity主题加载不同的布局到DecorView上,不管哪种布局,都会有一个id为"com.android.internal.R.id.content"的控件,我们通过setContentView设置的布局资源就是作为这个控件的子节点,现在,控件树已经构建完毕了,如图:
控件树构建完毕后,还需要通过WindowManager的addView方法添加管理,WindowManager是一个抽象类,其实现类为WindowManagerImpl,WindowManagerImpl会调用WindowManagerGlobal的addView方法,下面看一下WindowManagerGlobal的addView方法:
public void addView(View view, ViewGroup.LayoutParams params,
Display display, Window parentWindow) {
...
ViewRootImpl root;
View panelParentView = null;
synchronized (mLock) {
...
root = new ViewRootImpl(view.getContext(), display); // 构造ViewRootImpl对象
view.setLayoutParams(wparams); // 给View设置布局参数
mViews.add(view); // 这是一个数组,里面存储着所有的窗口View
mRoots.add(root); // 这个一个数组,里面存储着所有的窗口ViewRootImpl
mParams.add(wparams); // 这个一个数组,里面存储着所有的窗口的布局参数
// do this last because it fires off messages to start doing things
try {
root.setView(view, wparams, panelParentView); // 这里调用了ViewRootImpl的setView方法,将View和ViewRootImpl关联起来
} catch (RuntimeException e) {
...
}
}
}
WindowManagerGlobal的addView主要做了下面几件事:
- 给窗口创建ViewRootImpl对象;
- 给View设置布局参数
- 将ViewRootImp、View、布局参数添加到数组中存储
- 调用ViewRootImpl的setView方法,将View和ViewRootImpl绑定到一起,并通过Binder机制调用WMS添加窗口信息
来看一下ViewRootImpl的setView的实现:
public void setView(View view, WindowManager.LayoutParams attrs, View panelParentView) {
...
requestLayout(); // 调用requestLayout方法触发控件树测量、布局、绘制
...
try {
...
res = mWindowSession.addToDisplay(mWindow, mSeq, mWindowAttributes,
getHostVisibility(), mDisplay.getDisplayId(),
mAttachInfo.mContentInsets, mAttachInfo.mStableInsets,
mAttachInfo.mOutsets, mInputChannel); // 通过Binder机制将窗口信息传递给WMS
}
}
来看看requestLayout的实现:
@Override
public void requestLayout() {
if (!mHandlingLayoutInLayoutRequest) { // 一个VSync信号时间内只需要调用一次绘制流程
checkThread(); // 检查线程是否为原始线程
mLayoutRequested = true;
scheduleTraversals(); // 通过Chrographer向系统注册下一个VSync信号到来后调用doTraversal方法,执行绘制流程
}
}
requestLayout主要做了两件事:
- 检查线程是否为原始线程,这主要是为了确保UI操作的安全性,避免多个线程同时操作UI,发生混乱;
- 通过Chrographer向系统注册下一个VSync信号到来后调用doTraversal方法,执行绘制流程
先看看checkThread方法,我们经常说的不能在子线程中进行UI操作就是这个函数限制的:
void checkThread() {
if (mThread != Thread.currentThread()) { // 判断当前线程是否等于mThread,如果不是则抛出异常
throw new CalledFromWrongThreadException(
"Only the original thread that created a view hierarchy can touch its views.");
}
}
mThread是ViewRootImpl的成员变量,是在ViewRootImpl的构造函数中赋值的:
public ViewRootImpl(Context context, Display display) {
...
mThread = Thread.currentThread();
...
}
也就是说,进行UI操作的线程必须要和创建ViewRootImpl的线程一致。那么Activity的ViewRootImpl是在什么时候创建的呢?这个其实是在ActivityThread的handleResumeActivity方法中,和handleLaunchActivity方法类似,handleResumeActivity也是AMS通过Binder机制回调的(在performLaunchActivity中也会调用),对应着Activity的Resume生命周期:
final void handleResumeActivity(IBinder token,
boolean clearHide, boolean isForward, boolean reallyResume, int seq, String reason) {
...
// TODO Push resumeArgs into the activity for consideration
r = performResumeActivity(token, clearHide, reason); // 调用Activity的onResume方法
if (r != null) {
if (r.window == null && !a.mFinished && willBeVisible) {
r.window = r.activity.getWindow();
View decor = r.window.getDecorView();
decor.setVisibility(View.INVISIBLE);
ViewManager wm = a.getWindowManager();
...
if (a.mVisibleFromClient && !a.mWindowAdded) {
a.mWindowAdded = true;
wm.addView(decor, l); // 注意这里,调用WM的addView方法添加View
}
}
}
...
}
通过源码可以看到,handleResumeActivity首先是调用了Activity的onResume方法,然后调用WindowManager的addView方法添加DecorView,之前我们分析过,WindowManager的addView方法最终会调用WindowManagerGlobal的addView方法,在这个方法中,我们会创建ViewRootImpl,并将其和View绑定,所以ViewRootImpl的创建线程应该和handleResumeActivity的调用线程一致,而前面我们分析过,handleResumeActivity是AMS调用ApplicationThread的方法后,通过Handler向主线程发送消息触发调用的,所以Activity的ViewRootImpl的是在主线程中创建的,这就解释了我们常说的只能在主线程中进行UI操作了。
再来看一下scheduleTraversals()方法,前面我们说过这个方法的作用是通过Chrographer向系统注册下一个VSync信号到来后调用doTraversal方法,源码如下:
void scheduleTraversals() {
if (!mTraversalScheduled) {
mTraversalScheduled = true;
mTraversalBarrier = mHandler.getLooper().getQueue().postSyncBarrier();
mChoreographer.postCallback(
Choreographer.CALLBACK_TRAVERSAL, mTraversalRunnable, null); // 通过Chrographer向系统注册下一个VSync信号到来后调用mTraversalRunnable
if (!mUnbufferedInputDispatch) {
scheduleConsumeBatchedInput();
}
notifyRendererOfFramePending();
pokeDrawLockIfNeeded();
}
}
主要是调用Choreographer的postCallback向系统注册监听下一个Vsync,我们知道,Android的显示是交由给SurfaceFlinger控制的,SurfaceFlinger每隔16.6ms会产生一个VSync信号,表示屏幕刷新信号,我们的应用只有向系统注册了监听下一个VSync信号,才会收到下一个VSync,Choreographer就是负责获取Vsync同步信号并控制App线程(主要是主线程绘图)完成图像绘制的类,Android界面的绘制、属性动画等都离不开Choreographer,并且我们可以利用Choreographer监控App的性能,观察App是否卡顿,大致就是通过Choreographer注册监听VSync信号,看两次回调的间隔时间是否超时,如果时,则说明发生了卡顿。这里不分析Choreographer的源码了,只说结果,mTraversalRunnable会在创建ViewRootImpl的线程中调用,来看一下mTraversalRunnable的实现:
final TraversalRunnable mTraversalRunnable = new TraversalRunnable();
final class TraversalRunnable implements Runnable {
@Override
public void run() {
doTraversal();
}
}
void doTraversal() {
if (mTraversalScheduled) {
mTraversalScheduled = false;
...
performTraversals();
...
}
}
private void performTraversals() {
...
performMeasure(childWidthMeasureSpec, childHeightMeasureSpec); // 测量流程
...
performLayout(lp, mWidth, mHeight); // 布局流程
...
performDraw(); // 绘制流程
}
最终会依次执行控件树的测量、布局、绘制三大流程,通过这一系列步骤,控件树的内容现在绘制到了窗口对应的Surface上,然后经过WMS交由给SurfaceFlinger显示。
上面我们通过源码分析了Activity的生命周期回调、UI绘制是如何交由给主线程处理的,下面我们分析另外一个问题:UI操作必须要在主线程中执行吗?
2、UI操作是必须在主线程中执行吗?
如果对上面的ViewRootImpl的分析理解了,这个问题应该是有答案了,首先,我们来看一下在子线程中进行UI操作抛出的异常信息:
android.view.ViewRootImpl$CalledFromWrongThreadException: Only the original thread that created a view hierarchy can touch its views.
at android.view.ViewRootImpl.checkThread(ViewRootImpl.java:7967)
at android.view.ViewRootImpl.requestLayout(ViewRootImpl.java:1365)
at android.view.View.requestLayout(View.java:22280)
...
这个异常大家应该都很熟悉了,意思是说只能在创建控件树的线程中操作控件,报错的位置是ViewRootImpl的checkThread方法:
void checkThread() {
if (mThread != Thread.currentThread()) {
throw new CalledFromWrongThreadException(
"Only the original thread that created a view hierarchy can touch its views.");
}
}
前面我们说到过,ViewRootImpl是在WindowManagerGlobal的addView方法中创建的,考虑一下,如果我们在子线程中调用addView,那么ViewRootImpl也会在子线程中创建,其成员变量mThread记录的就是子线程,checkThread检查的时候判断的就是当前线程是否是创建ViewRootImpl的子线程,这种情况下,在主线程中进行UI操作反而会抛出异常。上面的逻辑是我们根据源码的猜想,下面我们写一个实际的例子来验证一下,我们新建一个Demo,在子线程中通过WindowManager添加View,然后尝试在子线程中更新它看是否会抛出异常:
public class MainActivity extends AppCompatActivity {
private HandlerThread mHandlerThread;
private Handler mHandler;
private CustomView mRootView;
@Override
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.activity_main);
init();
}
private void init() {
// 打印主线程id
Log.i("liunianprint:", "main thread id:" + Thread.currentThread().getId());
// 创建子线程
mHandlerThread = new HandlerThread("");
// 启动子线程
mHandlerThread.start();
// 创建WindowHandler对象,并且传入子线程的Looper
mHandler = new WindowHandler(mHandlerThread.getLooper());
// 打印子线程id
Log.i("liunianprint:", "HandlerThread id:" + mHandlerThread.getId());
findViewById(R.id.add_window).setOnClickListener(new View.OnClickListener() {
@Override
public void onClick(View v) {
Message message = Message.obtain();
message.what = WindowHandler.ADD_WINDOW;
mHandler.sendMessage(message);
}
});
findViewById(R.id.delete_window).setOnClickListener(new View.OnClickListener() {
@Override
public void onClick(View v) {
Message message = Message.obtain();
message.what = WindowHandler.REMOVE_WINDOW;
mHandler.sendMessage(message);
}
});
findViewById(R.id.update_window_view).setOnClickListener(new View.OnClickListener() {
@Override
public void onClick(View v) {
Message message = Message.obtain();
message.what = WindowHandler.UPDATE_WINDOW;
mHandler.sendMessage(message);
}
});
}
private void updateViewFromWindow() {
if (mRootView != null) {
// 打印当前线程id
Log.i("liunianprint:", "updateViewFromWindow thread id:" + Thread.currentThread().getId());
mRootView.setText(System.currentTimeMillis() + "");
}
}
private void addWindowView() {
removeViewFromWindow();
// 打印当前线程id
Log.i("liunianprint:", "addWindowView thread id:" + Thread.currentThread().getId());
Context context = getApplicationContext();
// 通过WM添加View
WindowManager wm = (WindowManager) context.getSystemService(Context.WINDOW_SERVICE);
WindowManager.LayoutParams lp;
lp = new WindowManager.LayoutParams();
lp.width = WindowManager.LayoutParams.WRAP_CONTENT;
lp.height = WindowManager.LayoutParams.WRAP_CONTENT;
lp.type = WindowManager.LayoutParams.TYPE_APPLICATION_OVERLAY;
lp.flags = WindowManager.LayoutParams.FLAG_FULLSCREEN | WindowManager.LayoutParams.FLAG_LAYOUT_IN_SCREEN |
WindowManager.LayoutParams.FLAG_NOT_TOUCH_MODAL;
mRootView = new CustomView(context);
((CustomView) mRootView).setText("Button");
mRootView.setPadding(100, 100, 100, 100);
mRootView.setBackgroundColor(context.getResources().getColor(android.R.color.holo_blue_bright));
mRootView.setOnClickListener(new View.OnClickListener() {
@Override
public void onClick(View v) {
// 打印处理点击事件的线程id
Log.i("liunianprint:", "click thread id:" + Thread.currentThread().getId());
Toast.makeText(MainActivity.this, "Click Me!", Toast.LENGTH_SHORT).show();
}
});
wm.addView(mRootView, lp);
}
private void removeViewFromWindow() {
if (null == mRootView) {
return;
}
Log.i("liunianprint:", "removeViewFromWindow thread id:" + Thread.currentThread().getId());
Context context = getApplicationContext();
WindowManager wm = (WindowManager) context.getSystemService(Context.WINDOW_SERVICE);
if (mRootView.getParent() != null) {
wm.removeView(mRootView);
}
mRootView = null;
}
@Override
protected void onDestroy() {
mHandler.removeCallbacksAndMessages(null);
mHandlerThread.stop();
removeViewFromWindow();
super.onDestroy();
}
/**
* 定义操作Window的Handler类
*/
private class WindowHandler extends Handler {
public final static int ADD_WINDOW = 1;
public final static int REMOVE_WINDOW = 2;
public final static int UPDATE_WINDOW = 3;
public WindowHandler(Looper looper) {
super(looper);
}
@Override
public void handleMessage(Message msg) {
if (msg != null) {
switch (msg.what) {
case ADD_WINDOW:
addWindowView();
break;
case REMOVE_WINDOW:
removeViewFromWindow();
break;
case UPDATE_WINDOW:
updateViewFromWindow();
break;
}
}
}
}
}
在上面的代码中,我们将添加Window、更新Window上的View、删除Window的操作都放在子线程中执行,并且打印出线程id,运行效果如下:
可以看到,在子线程中能够通过WindowManager添加、更新、删除Window, 打印日志如下:
2019-05-08 16:19:34.561 15049-15049/? I/liunianprint:: main thread id:2
2019-05-08 16:19:34.562 15049-15049/? I/liunianprint:: HandlerThread id:4721
2019-05-08 16:19:37.241 15049-15069/com.example.myapplication I/liunianprint:: addWindowView thread id:4721
2019-05-08 16:19:37.290 15049-15069/com.example.myapplication I/liunianprint:: draw thread id:4721
2019-05-08 16:19:38.862 15049-15069/com.example.myapplication I/liunianprint:: updateViewFromWindow thread id:4721
2019-05-08 16:19:38.893 15049-15069/com.example.myapplication I/liunianprint:: draw thread id:4721
2019-05-08 16:19:38.904 15049-15069/com.example.myapplication I/liunianprint:: draw thread id:4721
2019-05-08 16:19:40.105 15049-15069/com.example.myapplication I/liunianprint:: click thread id:4721
2019-05-08 16:19:42.277 15049-15069/com.example.myapplication I/liunianprint:: removeViewFromWindow thread id:4721
从日志中我们可以看出,添加、更新、删除Window都是在子线程中进行的,并且点击事件的回调处理也是在点击事件中完成的,我们再来确定一下控件的绘制线程,我们上面添加的View是自定义的View,名称为CustomView,我重写了它的onDraw方法,在其中打印绘制线程:
public class CustomView extends AppCompatButton {
...
@Override
protected void onDraw(Canvas canvas) {
super.onDraw(canvas);
Log.i("liunianprint:", "draw thread id:" + Thread.currentThread().getId());
}
}
通过上面的日志,我们可以确定控件的绘制也是在子线程中执行的,和创建ViewRootImpl的线程保持一致,那么,假设我们现在想在主线程中更新窗口的UI,能操作成功吗?修改代码如下:
findViewById(R.id.update_window_view).setOnClickListener(new View.OnClickListener() {
@Override
public void onClick(View v) {
// Message message = Message.obtain();
// message.what = WindowHandler.UPDATE_WINDOW;
// mHandler.sendMessage(message);
updateViewFromWindow(); // 直接在主线程中更新窗口UI
}
});
点击更新按钮,直接抛出异常:
android.view.ViewRootImpl$CalledFromWrongThreadException: Only the original thread that created a view hierarchy can touch its views.
at android.view.ViewRootImpl.checkThread(ViewRootImpl.java:7967)
at android.view.ViewRootImpl.requestLayout(ViewRootImpl.java:1365)
at android.view.View.requestLayout(View.java:22280)
...
原因也很简单,不能在创建ViewRootImpl线程以外的线程进行UI操作,经过上面的分析,我们得出了结论:可以在子线程中更新UI,只要更新UI的子线程是创建ViewRootImpl的线程,我们经常说的只能在UI线程中进行UI操作,是因为Activity所对应的ViewRootImpl对象是在主线程中创建的,并且这个流程是系统定制好的,我们无法修改。