Handler的原理有哪些

发布时间:2021-10-11 22:02:38 作者:iii
来源:亿速云 阅读:257

本篇内容主要讲解“Handler的原理有哪些”,感兴趣的朋友不妨来看看。本文介绍的方法操作简单快捷,实用性强。下面就让小编来带大家学习“Handler的原理有哪些”吧!

总流程

开头需要建立个handler作用的总体印象,下面画了一个总体的流程图

Handler的原理有哪些

从上面的流程图可以看出,总体上是分几个大块的

相关知识点大概涉及到这些,下面详细讲解下!

Handler的原理有哪些

使用

先来看下使用,不然源码,原理图搞了一大堆,一时想不起怎么用的,就尴尬了

使用很简单,此处仅做个展示,大家可以熟悉下

演示代码尽量简单是为了演示,关于静态内部类持有弱引用或者销毁回调中清空消息队列之类,就不在此处展示了

Handler.java
...
public void dispatchMessage(@NonNull Message msg) {
    if (msg.callback != null) {
        handleCallback(msg);
    } else {
        if (mCallback != null) {
            if (mCallback.handleMessage(msg)) {
                return;
            }
        }
        handleMessage(msg);
    }
}
...

从上面源码可知,handler的使用总的来说,分俩大类,细分三小类

收发一体

public class MainActivity extends AppCompatActivity {
    private TextView msgTv;
    private Handler mHandler = new Handler();

    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.activity_main);
        msgTv = findViewById(R.id.tv_msg);

      	//消息收发一体
        new Thread(new Runnable() {
            @Override public void run() {
                String info = "第一种方式";
                mHandler.post(new Runnable() {
                    @Override public void run() {
                        msgTv.setText(info);
                    }
                });
            }
        }).start();
    }
}

收发分开

mCallback.handleMessage(msg)

public class MainActivity extends AppCompatActivity {
    private TextView msgTv;
    private Handler mHandler = new Handler(new Handler.Callback() {
        //接收消息,刷新UI
        @Override public boolean handleMessage(@NonNull Message msg) {
            if (msg.what == 1) {
                msgTv.setText(msg.obj.toString());
            }
            //false 重写Handler类的handleMessage会被调用,  true 不会被调用
            return false;
        }
    });

    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.activity_main);
        msgTv = findViewById(R.id.tv_msg);

        //发送消息
        new Thread(new Runnable() {
            @Override public void run() {
                Message message = Message.obtain();
                message.what = 1;
                message.obj = "第二种方式 --- 1"; 
                mHandler.sendMessage(message);
            }
        }).start();
    }
}

handleMessage(msg)

public class MainActivity extends AppCompatActivity {
    private TextView msgTv;
    private Handler mHandler = new Handler() {
        //接收消息,刷新UI
        @Override public void handleMessage(@NonNull Message msg) {
            super.handleMessage(msg);
            if (msg.what == 1) {
                msgTv.setText(msg.obj.toString());
            }
        }
    };

    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.activity_main);
        msgTv = findViewById(R.id.tv_msg);

        //发送消息
        new Thread(new Runnable() {
            @Override public void run() {
                Message message = Message.obtain();
                message.what = 1;
                message.obj = "第二种方式 --- 2";
                mHandler.sendMessage(message);
            }
        }).start();
    }
}

prepare和loop

大家肯定有印象,在子线程和子线程的通信中,就必须在子线程中初始化Handler,必须这样写

new Thread(new Runnable() {
    @Override public void run() {
        Looper.prepare();
        Handler handler = new Handler();
        Looper.loop();
    }
});
ActivityThread.java
...
public static void main(String[] args) {
    ...
    //主线程Looper
    Looper.prepareMainLooper();
    ActivityThread thread = new ActivityThread();
    thread.attach(false);
    if (sMainThreadHandler == null) {
        sMainThreadHandler = thread.getHandler();
    }
    //主线程的loop开始循环
    Looper.loop();
	...
}
...

为什么要使用prepare和loop?我画了个图,先让大家有个整体印象

Handler的原理有哪些

具体看下每个步骤的源码,这里也会标定好链接,方便大家随时过去查看

Looper.java
...
 public static void prepare() {
    prepare(true);
}

private static void prepare(boolean quitAllowed) {
    if (sThreadLocal.get() != null) {
        throw new RuntimeException("Only one Looper may be created per thread");
    }
    sThreadLocal.set(new Looper(quitAllowed));
}
...
Handler.java
...
@Deprecated
public Handler() {
    this(null, false);
}

public Handler(@Nullable 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();
    if (mLooper == null) {
        throw new RuntimeException(
            "Can't create handler inside thread " + Thread.currentThread()
            + " that has not called Looper.prepare()");
    }
    mQueue = mLooper.mQueue;
    mCallback = callback;
    mAsynchronous = async;
}
...
Looper.java
...
public static @Nullable Looper myLooper() {
    return sThreadLocal.get();
}
...
Looper.java
...
public static void loop() {
    final Looper me = myLooper();
    
    ...
    
    final MessageQueue queue = me.mQueue;

   	...

    for (;;) {
        Message msg = queue.next(); // might block
        if (msg == null) {
            // No message indicates that the message queue is quitting.
            return;
        }

        ...
        
        try {
            msg.target.dispatchMessage(msg);
            if (observer != null) {
                observer.messageDispatched(token, msg);
            }
            dispatchEnd = needEndTime ? SystemClock.uptimeMillis() : 0;
        } catch (Exception exception) {
            if (observer != null) {
                observer.dispatchingThrewException(token, msg, exception);
            }
            throw exception;
        } finally {
            ThreadLocalWorkSource.restore(origWorkSource);
            if (traceTag != 0) {
                Trace.traceEnd(traceTag);
            }
        }
     
        ....

        msg.recycleUnchecked();
    }
}
...

收发消息

收发消息的操作口都在Handler里,这是我们最直观的接触的点

下方的思维导图整体做了个概括

Handler的原理有哪些

前置知识

在说发送和接受消息之前,必须要先解释下,Message中一个很重要的属性:when

when这个变量是Message中的,发送消息的时候,我们一般是不会设置这个属性的,实际上也无法设置,只有内部包才能访问写的操作;将消息加入到消息队列的时候会给发送的消息设置该属性。消息加入消息队列方法:enqueueMessage(...)

在我们使用sendMessage发送消息的时候,实际上也会调用sendMessageDelayed延时发送消息发放,不过此时传入的延时时间会默认为0,来看下延时方法:sendMessageDelayed

public final boolean sendMessageDelayed(@NonNull Message msg, long delayMillis) {
    if (delayMillis < 0) {
        delayMillis = 0;
    }
    return sendMessageAtTime(msg, SystemClock.uptimeMillis() + delayMillis);
}

这地方调用了sendMessageAtTime方法,此处!做了一个时间相加的操作:SystemClock.uptimeMillis() + delayMillis

后面会将这个时间刻赋值给when:when = SystemClock.uptimeMillis() + delayMillis

说明when代表的是开机到现在的一个时间刻,通俗的理解,when可以理解为:现实时间的某个现在或未来的时刻(实际上when是个相对时刻,相对点就是开机的时间点)

发送消息

发送消息涉及到俩个方法:post(...)和sendMessage(...)

Handler.java
...
//post
public final boolean post(@NonNull Runnable r) {
    return  sendMessageDelayed(getPostMessage(r), 0);
}

//生成Message对象
private static Message getPostMessage(Runnable r) {
    Message m = Message.obtain();
    m.callback = r;
    return m;
}

//sendMessage方法
public final boolean sendMessage(@NonNull Message msg) {
    return sendMessageDelayed(msg, 0);
}

public final boolean sendMessageDelayed(@NonNull Message msg, long delayMillis) {
    if (delayMillis < 0) {
        delayMillis = 0;
    }
    return sendMessageAtTime(msg, SystemClock.uptimeMillis() + delayMillis);
}

public boolean sendMessageAtTime(@NonNull Message msg, long uptimeMillis) {
    MessageQueue queue = mQueue;
    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);
}

///将Message加入详细队列 
private boolean enqueueMessage(@NonNull MessageQueue queue, @NonNull Message msg,
                               long uptimeMillis) {
    //设置target
    msg.target = this;
    msg.workSourceUid = ThreadLocalWorkSource.getUid();

    if (mAsynchronous) {
        //设置为异步方法
        msg.setAsynchronous(true);
    }
    return queue.enqueueMessage(msg, uptimeMillis);
}
...
MessageQueue.java
...
boolean enqueueMessage(Message msg, long when) {
   ...

    synchronized (this) {
        ...

        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;
}
...

Handler的原理有哪些

接收消息

接受消息相对而言就简单多

Handler.java
...
public void dispatchMessage(@NonNull Message msg) {
    if (msg.callback != null) {
        handleCallback(msg);
    } else {
        if (mCallback != null) {
            if (mCallback.handleMessage(msg)) {
                return;
            }
        }
        handleMessage(msg);
    }
} 
...

分发消息

消息分发是在loop()中完成的,来看看loop()这个重要的方法

Looper.java
...
public static void loop() {
    final Looper me = myLooper();
    ...
    final MessageQueue queue = me.mQueue;
   	...
    for (;;) {
        //遍历消息池,获取下一可用消息
        Message msg = queue.next(); // might block
        ...
        try {
            //分发消息
            msg.target.dispatchMessage(msg);
            ...
        } catch (Exception exception) {
            ...
        } finally {
            ...
        }
        ....
        //回收消息,进图消息池
        msg.recycleUnchecked();
    }
}
...

遍历消息

遍历消息的关键方法肯定是下面这个

来看看这个Message中的next()方法吧

MessageQueue.java
...
Message next() {
    final long ptr = mPtr;
    ...

    int pendingIdleHandlerCount = -1; // -1 only during first iteration
    int nextPollTimeoutMillis = 0;
    for (;;) {
  		...
        //阻塞,除非到了超时时间或者唤醒
        nativePollOnce(ptr, nextPollTimeoutMillis);
        synchronized (this) {
            // Try to retrieve the next message.  Return if found.
            final long now = SystemClock.uptimeMillis();
            Message prevMsg = null;
            Message msg = mMessages;
            // 这是关于同步屏障(SyncBarrier)的知识,放在同步屏障栏目讲
            if (msg != null && msg.target == null) {
                do {
                    prevMsg = msg;
                    msg = msg.next;
                } while (msg != null && !msg.isAsynchronous());
            }
            
            if (msg != null) {
                if (now < msg.when) {
                    //每个消息处理有耗时时间,之间存在一个时间间隔(when是将要执行的时间点)。
                    //如果当前时刻还没到执行时刻(when),计算时间差值,传入nativePollOnce定义唤醒阻塞的时间
                    nextPollTimeoutMillis = (int) Math.min(msg.when - now, Integer.MAX_VALUE);
                } else {
                    mBlocked = false;
                    //该操作是把异步消息单独从消息队列里面提出来,然后返回,返回之后,该异步消息就从消息队列里面剔除了
                    //mMessage仍处于未分发的同步消息位置
                    if (prevMsg != null) {
                        prevMsg.next = msg.next;
                    } else {
                        mMessages = msg.next;
                    }
                    msg.next = null;
                    if (DEBUG) Log.v(TAG, "Returning message: " + msg);
                    msg.markInUse();
                    //返回符合条件的Message
                    return msg;
                }
            } else {
                // No more messages.
                nextPollTimeoutMillis = -1;
            }

            //这是处理调用IdleHandler的操作,有几个条件
        	//1、当前消息队列为空(mMessages == null)
            //2、已经到了可以分发下一消息的时刻(now < mMessages.when)
            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);
        }

       
        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;
    }
}

总结下源码里面表达的意思

  1. next()内部是个死循环,你可能会疑惑,只是拿下一节点的消息,为啥要死循环?

  2. nativePollOnce阻塞方法:到了超时时间(nextPollTimeoutMillis)或者通过唤醒方式(nativeWake),会解除阻塞状态

  3. 如果 msg.target == null为零,会进入同步屏障状态

  4. 当前时刻和返回消息的when判定

  5. 消息返回后,会将mMessage赋值为返回消息的下一节点(只针对不涉及同步屏障的同步消息)

这里简单的画了个流程图

Handler的原理有哪些

分发消息

分发消息主要的代码是: msg.target.dispatchMessage(msg);

也就是说这是Handler类中的dispatchMessage(msg)方法

public void dispatchMessage(@NonNull Message msg) {
    if (msg.callback != null) {
        handleCallback(msg);
    } else {
        if (mCallback != null) {
            if (mCallback.handleMessage(msg)) {
                return;
            }
        }
        handleMessage(msg);
    }
}

可以看到,这里的代码,在收发消息栏目的接受消息那块已经说明过了,这里就无须重复了

消息池

msg.recycleUnchecked()是处理完成分发的消息,完成分发的消息并不会被回收掉,而是会进入消息池,等待被复用

Message.java
...
void recycleUnchecked() {
    // Mark the message as in use while it remains in the recycled object pool.
    // Clear out all other details.
    flags = FLAG_IN_USE;
    what = 0;
    arg1 = 0;
    arg2 = 0;
    obj = null;
    replyTo = null;
    sendingUid = UID_NONE;
    workSourceUid = UID_NONE;
    when = 0;
    target = null;
    callback = null;
    data = null;

    synchronized (sPoolSync) {
        if (sPoolSize < MAX_POOL_SIZE) {
            next = sPool;
            sPool = this;
            sPoolSize++;
        }
    }
}

来看下消息池回收消息图示

Handler的原理有哪些

既然有将已使用的消息回收到消息池的操作,那肯定有获取消息池里面消息的方法了

Message.java
...
public static Message obtain() {
    synchronized (sPoolSync) {
        if (sPool != null) {
            Message m = sPool;
            sPool = m.next;
            m.next = null;
            m.flags = 0; // clear in-use flag
            sPoolSize--;
            return m;
        }
    }
    return new Message();
}

来看下从消息池取一个消息的图示

Handler的原理有哪些

IdleHandler

在MessageQueue类中的next方法里,可以发现有关于对IdleHandler的处理,大家可千万别以为它是什么Handler特殊形式之类,这玩意就是一个interface,里面抽象了一个方法,结构非常的简单

MessageQueue.java
...
Message next() {
    final long ptr = mPtr;
    ...

    int pendingIdleHandlerCount = -1; // -1 only during first iteration
    int nextPollTimeoutMillis = 0;
    for (;;) {
  		...
        //阻塞,除非到了超时时间或者唤醒
        nativePollOnce(ptr, nextPollTimeoutMillis);
        synchronized (this) {
            // Try to retrieve the next message.  Return if found.
            final long now = SystemClock.uptimeMillis();
            Message prevMsg = null;
            Message msg = mMessages;
			...
            //这是处理调用IdleHandler的操作,有几个条件
        	//1、当前消息队列为空(mMessages == null)
            //2、未到到了可以分发下一消息的时刻(now < mMessages.when)
			//3、pendingIdleHandlerCount < 0表明:只会在此for循环里执行一次处理IdleHandler操作
            if (pendingIdleHandlerCount < 0
                && (mMessages == null || now < mMessages.when)) {
                pendingIdleHandlerCount = mIdleHandlers.size();
            }
            if (pendingIdleHandlerCount <= 0) {
                mBlocked = true;
                continue;
            }

            if (mPendingIdleHandlers == null) {
                mPendingIdleHandlers = new IdleHandler[Math.max(pendingIdleHandlerCount, 4)];
            }
            mPendingIdleHandlers = mIdleHandlers.toArray(mPendingIdleHandlers);
        }

       
        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);
                }
            }
        }

        pendingIdleHandlerCount = 0;
        nextPollTimeoutMillis = 0;
    }
}

实际上从上面的代码里面,可以分析出很多信息

IdleHandler相关信息

总结

同步屏障

来到最复杂的模块了

在理解同步屏障的概念前,我们需要先搞懂几个前置知识

前置知识

同步和异步消息

什么是同步消息?什么是异步消息?

public boolean isAsynchronous() {
    return (flags & FLAG_ASYNCHRONOUS) != 0;
}
msg.setAsynchronous(true);

public void setAsynchronous(boolean async) {
    if (async) {
        flags |= FLAG_ASYNCHRONOUS;
    } else {
        flags &= ~FLAG_ASYNCHRONOUS;
    }
}
Message msg = Message.obtain();
//设置异步消息标记
msg.setAsynchronous(true);

默认消息类型

我们正常情况下,很少会使用setAsynchronous方法的,那么在不使用该方法的时候,消息的默认类型是什么呢?

private boolean enqueueMessage(@NonNull MessageQueue queue, @NonNull Message msg,long uptimeMillis) {
    msg.target = this;
    msg.workSourceUid = ThreadLocalWorkSource.getUid();

    if (mAsynchronous) {
        msg.setAsynchronous(true);
    }
    return queue.enqueueMessage(msg, uptimeMillis);
}
public Handler(@Nullable 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();
    if (mLooper == null) {
        throw new RuntimeException(
            "Can't create handler inside thread " + Thread.currentThread()
            + " that has not called Looper.prepare()");
    }
    mQueue = mLooper.mQueue;
    mCallback = callback;
    mAsynchronous = async;
}

public Handler(@NonNull Looper looper, @Nullable Callback callback, boolean async) {
    mLooper = looper;
    mQueue = looper.mQueue;
    mCallback = callback;
    mAsynchronous = async;
}
public Handler() {
    this(null, false);
}

public Handler(@NonNull Looper looper) {
    this(looper, null, false);
}

public Handler(@NonNull Looper looper, @Nullable Callback callback) {
    this(looper, callback, false);
}

生成同步屏障消息

在next方法中发现,target为null的消息被称为同步屏障消息,那他为啥叫同步屏障消息呢?

MessageQueue.java
...
@UnsupportedAppUsage
@TestApi
public int postSyncBarrier() {
    return postSyncBarrier(SystemClock.uptimeMillis());
}
    
private int postSyncBarrier(long when) {
    // Enqueue a new sync barrier token.
    // We don't need to wake the queue because the purpose of a barrier is to stall it.
    synchronized (this) {
        final int token = mNextBarrierToken++;
        final Message msg = Message.obtain();
        msg.markInUse();
        msg.when = when;
        msg.arg1 = token;

        Message prev = null;
        Message p = mMessages;
        if (when != 0) {
            while (p != null && p.when <= when) {
                prev = p;
                p = p.next;
            }
        }
        if (prev != null) { // invariant: p == prev.next
            msg.next = p;
            prev.next = msg;
        } else {
            msg.next = p;
            mMessages = msg;
        }
        return token;
    }
}

总结下:

同步屏障消息插入消息队列的规律,和上面正常发送消息插入基本是一致的;如果消息队列有延时消息,延时消息的时刻大于目前的时刻,同步消息会在这些延时消息之前。

OK,同步屏障消息插入,基本可以理解为:正常的非延时消息插入消息队列!

Handler的原理有哪些

同步屏障流程

MessageQueue.java
...
Message next() {
    final long ptr = mPtr;
    ...

    int pendingIdleHandlerCount = -1; // -1 only during first iteration
    int nextPollTimeoutMillis = 0;
    for (;;) {
  		...
        //阻塞,除非到了超时时间或者唤醒
        nativePollOnce(ptr, nextPollTimeoutMillis);
        synchronized (this) {
            // Try to retrieve the next message.  Return if found.
            final long now = SystemClock.uptimeMillis();
            Message prevMsg = null;
            Message msg = mMessages;
            // 这是关于同步屏障(SyncBarrier)的逻辑块
            if (msg != null && msg.target == null) {
                do {
                    prevMsg = msg;
                    msg = msg.next;
                } while (msg != null && !msg.isAsynchronous());
            }
            
            if (msg != null) {
                if (now < msg.when) {
                    //每个消息处理有耗时时间,之间存在一个时间间隔(when是将要执行的时间点)。
                    //如果当前时刻还没到执行时刻(when),计算时间差值,传入nativePollOnce定义唤醒阻塞的时间
                    nextPollTimeoutMillis = (int) Math.min(msg.when - now, Integer.MAX_VALUE);
                } else {
                    mBlocked = false;
                    //该操作是把异步消息单独从消息队列里面提出来,然后返回,返回之后,该异步消息就从消息队列里面剔除了
                    //mMessage仍处于未分发的同步消息位置
                    if (prevMsg != null) {
                        prevMsg.next = msg.next;
                    } else {
                        mMessages = msg.next;
                    }
                    msg.next = null;
                    if (DEBUG) Log.v(TAG, "Returning message: " + msg);
                    msg.markInUse();
                    //返回符合条件的Message
                    return msg;
                }
            } else {
                // No more messages.
                nextPollTimeoutMillis = -1;
            }
            ...
        }
        ...
    }
}

去掉大量我们无需关注的代码,发现这也没啥嘛,就是一堆if eles for之类的,来分析分析

  1. Message msg = mMessages:这步赋值是非常重要的,表示即使我们对msg一顿操作,mMessage还是保留消息队列头结点消息的位置

  2. msg.target == null:遇到同步屏障消息

    1. 首先是一个while循环,内部逻辑,不断将msg节点的位置后移

    2. 结束while的俩个条件

  3. 分析下,俩个放行条件产生的不同影响

    1. 消息队列不含异步消息

    2. 消息队列含有异步消息

文字写了一大堆,我也是尽可能详细描述,同步屏障逻辑代码块会产生的影响,整个图,加深下印象!

Handler的原理有哪些

同步屏障作用

那么这个同步屏障有什么作用呢?

有个急需的问题,就是什么地方用到了postSyncBarrier(long when)方法,这个方法对外是不暴露的,只有内部包能够调用

搜索了整个源码包,发现只有几个地方使用了它,剔除测试类,MessageQueue类,有作用的就是:ViewRootImpl类和Device类

Device类

ViewRootImpl类

该栏目的分析,必须引用一个非常重要的结论,给出该结论的文章:源码分析_Android UI何时刷新_Choreographer

我们这边已经有了前辈给出的结论,我们知道了界面刷新(requestLayout或者invalidate)的过程一定会触发scheduleTraversals()方法,这说明会添加同步屏障消息,那肯定有移除同步屏障消息的步骤,这个步骤很有可能存在doTraversal()方法中,来看下这个方法

void doTraversal() {
    if (mTraversalScheduled) {
        mTraversalScheduled = false;
        mHandler.getLooper().getQueue().removeSyncBarrier(mTraversalBarrier);

        if (mProfile) {
            Debug.startMethodTracing("ViewAncestor");
        }

        performTraversals();

        if (mProfile) {
            Debug.stopMethodTracing();
            mProfile = false;
        }
    }
}

总结

调用View的requestLayout或者invalidate时,最终都会执行scheduleTraversals(),此时会在主线程消息队列中插入一个同步屏障消息(停止所有同步消息分发),会将mTraversalRunnable添加到mCallbackQueues中,并注册接收Vsync的监听,当接受到Vsync通知后,会发送一个异步消息,触发遍历执行mCallbackQueues的方法,这会执行我们添加的回调mTraversalRunnable,从而执行doTraversal(),此时会移除主线程消息队列中同步屏障消息,最后执行绘制操作

调用requestLayout或者invalidate时,会在主线程消息队列中插入一个同步屏障消息,同时注册接收Vsync的监听;当接受到Vsync通知,会发送一个异步消息,执行真正的绘制事件:此时会移除消息队列中的同步屏障消息,然后才会执行绘制操作

Handler的原理有哪些

总结

消息插入对比

Vsync

Handler的原理有哪些

总结

相关总结

同步消息和异步消息使用建议

在正常的情况,肯定不建议使用异步消息,此处假设一个场景:因为某种需求,你发送了大量的异步消息,由于消息进入消息队列的特殊性,系统发送的异步消息,也只能乖乖的排在你的异步消息后面,假设你的异步消息占据了大量的时间片,甚至占用了几帧,导致系统UI刷新的异步消息无法被及时执行,此时很有可能发生掉帧

当然,如果你能看明白这个同步屏障栏目所写的东西,相信什么时候设置消息为异步,心中肯定有数

考点

上面源码基本就分析到这边了,咱们看看能根据这些知识点,能提一些什么问题呢?

一个小知识

我逛一些论坛的时候,发现有人:对Handler怎么在主线程和子线程进行数据交互的原理,感到迷惑。

1、先来个自己想的问题:Handler中主线程的消息队列是否有数量上限?为什么?

这问题整的有点鸡贼,可能会让你想到,是否有上限这方面?而不是直接想到到上限数量是多少?

解答:Handler主线程的消息队列肯定是有上限的,每个线程只能实例化一个Looper实例(上面讲了,Looper.prepare只能使用一次),不然会抛异常,消息队列是存在Looper()中的,且仅维护一个消息队列

重点:每个线程只能实例化一次Looper()实例、消息队列存在Looper中

拓展:MessageQueue类,其实都是在维护mMessage,只需要维护这个头结点,就能维护整个消息链表

2、Handler中有Loop死循环,为什么没有卡死?为什么没有发生ANR?

先说下ANR:5秒内无法响应屏幕触摸事件或键盘输入事件;广播的onReceive()函数时10秒没有处理完成;前台服务20秒内,后台服务在200秒内没有执行完毕;ContentProvider的publish在10s内没进行完。所以大致上Loop死循环和ANR联系不大,问了个正确的废话,所以触发事件后,耗时操作还是要放在子线程处理,handler将数据通讯到主线程,进行相关处理。

线程实质上是一段可运行的代码片,运行完之后,线程就会自动销毁。当然,我们肯定不希望主线程被over,所以整一个死循环让线程保活。

为什么没被卡死:在事件分发里面分析了,在获取消息的next()方法中,如果没有消息,会触发nativePollOnce方法进入线程休眠状态,释放CPU资源,MessageQueue中有个原生方法nativeWake方法,可以解除nativePollOnce的休眠状态,ok,咱们在这俩个方法的基础上来给出答案

3、为什么不建议在子线程中更新UI?

多线程操作,在UI的绘制方法表示这不安全,不稳定。

假设一种场景:我会需要对一个圆进行改变,A线程将圆增大俩倍,B改变圆颜色。A线程增加了圆三分之一体积的时候,B线程此时,读取了圆此时的数据,进行改变颜色的操作;最后的结果,可能会导致,大小颜色都不对。。。

4、可以让自己发送的消息优先被执行吗?原理是什么?

这个问题,我感觉只能说:在有同步屏障的情况下是可以的。

同步屏障作用:在含有同步屏障的消息队列,会及时的屏蔽消息队列中所有同步消息的分发,放行异步消息的分发。

在含有同步屏障的情况,我可以将自己的消息设置为异步消息,可以起到优先被执行的效果。

5、子线程和子线程使用Handler进行通信,存在什么弊端?

子线程和子线程使用Handler通信,某个接受消息的子线程肯定使用实例化handler,肯定会有Looper操作,Looper.loop()内部含有一个死循环,会导致线程的代码块无法被执行完,该线程始终存在。

如果在完成通信操作,我们一般可以使用: mHandler.getLooper().quit() 来结束分发操作

6、Handler中的阻塞唤醒机制?

这个阻塞唤醒机制是基于 Linux 的 I/O 多路复用机制 epoll 实现的,它可以同时监控多个文件描述符,当某个文件描述符就绪时,会通知对应程序进行读/写操作.

MessageQueue 创建时会调用到 nativeInit,创建新的 epoll 描述符,然后进行一些初始化并监听相应的文件描述符,调用了epoll_wait方法后,会进入阻塞状态;nativeWake触发对操作符的 write 方法,监听该操作符被回调,结束阻塞状态

详细请查看:同步屏障?阻塞唤醒?和我一起重读 Handler 源码

7、什么是IdleHandler?什么条件下触发IdleHandler?

IdleHandler的本质就是接口,为了在消息分发空闲的时候,能处理一些事情而设计出来的

具体条件:消息队列为空的时候、发送延时消息的时候

8、消息处理完后,是直接销毁吗?还是被回收?如果被回收,有最大容量吗?

Handler存在消息池的概念,处理完的消息会被重置数据,采用头插法进入消息池,取的话也直接取头结点,这样会节省时间

消息池最大容量为50,达到最大容量后,不再接受消息进入

9、不当的使用Handler,为什么会出现内存泄漏?怎么解决?

先说明下,Looper对象在主线程中,整个生命周期都是存在的,MessageQueue是在Looper对象中,也就是消息队列也是存在在整个主线程中;我们知道Message是需要持有Handler实例的,Handler又是和Activity存在强引用关系

存在某种场景:我们关闭当前Activity的时候,当前Activity发送的Message,在消息队列还未被处理,Looper间接持有当前activity引用,因为俩者直接是强引用,无法断开,会导致当前Activity无法被回收

思路:断开俩者之间的引用、处理完分发的消息,消息被处理后,之间的引用会被重置断开

解决:使用静态内部类弱引Activity、清空消息队列

最后

写这篇文章加上思维导图,也大概整了十三来张图,我真的尽力了!

Handler的原理有哪些

到此,相信大家对“Handler的原理有哪些”有了更深的了解,不妨来实际操作一番吧!这里是亿速云网站,更多相关内容可以进入相关频道进行查询,关注我们,继续学习!

推荐阅读:
  1. Android Handler 消息机制原理解析
  2. Handler原理是什么

免责声明:本站发布的内容(图片、视频和文字)以原创、转载和分享为主,文章观点不代表本网站立场,如果涉及侵权请联系站长邮箱:is@yisu.com进行举报,并提供相关证据,一经查实,将立刻删除涉嫌侵权内容。

handler

上一篇:不同语言的内存管理有哪些

下一篇:如何制定性能测试

相关阅读

您好,登录后才能下订单哦!

密码登录
登录注册
其他方式登录
点击 登录注册 即表示同意《亿速云用户服务条款》