浅谈Android Handler消息机制

我就是我 2022-10-22 13:54 237阅读 0赞

***Handler简介***

Handler机制在安卓开发中很常应用到，Handler机制也可以称为异步消息机制，包括Handler，Message，Looper以及MessageQueue，主线程不能做耗时操作，如果要更新UI必需要子线程去通知主线程去更新。

*  Handler：消息机制的处理者，在子线程中调用sendMessage方法发送对应的Message，然后经过一系列的辗转后最终消息会被传递到Handler的handlerMessage方法中被处理，即在创建Handler时重写handleMessage方法中处理对应的Message消息即可；
 *  Message：消息是指在线程之前传递的消息，它可以内部携带一些必要的信息，主要用于在不同线程之间的数据交换；
 *  MessageQueue： MessageQueue就是消息队列的意思,它只要用于存放所有通过Handler发送过来的消息。这些消息会一直存放于消息队列当中，等待被处理。每个线程中只会有一个MessageQueue对象；
 *  Looper：Looper是每一个线程中的消息管家，当调用Looper的Loop()方法之后，就会进入到一个无限循环之中，每当有消息插入到MessageQueue中，Looper就会从中取出对应的消息交给对应的Handler处理，记住，每个线程只有一个对应的Looper；

***Handler的工作流程***

首先在UI线程中创建一个Handler对象，然后重写对应的handlerMessage方法，在handlerMessage方法中我们可以通过参数msg来编写接受消息后UI线程的处理逻辑，然后我们创建一个子线程，在子线程需要更新UI界面的时候，新建一个Message对象，并把需要传递的消息记录在Message对象里面，然后通过前面的Handler的sendMessage方法把这个Message发送出去，之后这个消息就会进入到MessageQueue，此时MessageQueue的管家Looper就会不停的从MessageQueue中取出对应的消息，然后把消息传递给相应的Handler去处理。

说到这里，很多人就会纳闷，上面不是说每个线程需要对应一个Looper嘛，那为什么主线程没有对应的Looper却可以处理消息呢？其实在用户启动一个应用的时候，Android首先会开启一个主线程（也就是我们说的UI线程），进行事件分发，然后每个程序都会有一个程序的对应入口，Android的程序入口如下:

public static void main(String[] args){
        
        ...
        //初始化Looper
        Looper.prepareMainLooper(); 
        //实例化一个ActivityThread
        ActivityThread thread = new ActivityThread();
        //这个方法最后就是为了发送出创建Application的消息
        thread.attach(false);
        //主线程进入无限循环状态，等待接收消息
        Looper.loop();
        ...
    }

其实Android在进入应用的时候就已经初始化了一个Looper，这个Looper会持续到应用的关闭才会退出，如果需要更新UI，那么只需要创建一个子线程然后发送对应的消息给UI线程，UI线程接收到消息之后做对应的更新操作即可；

那么我们如何判断当前线程是主线程还是子线程呢？可以通过下列三种方法进行判断

public boolean isMainThread() {
        
        return Looper.getMainLooper() == Looper.myLooper();
    }

public boolean isMainThread() {
        
        return Looper.getMainLooper().getThread() == Thread.currentThread();
    }

public boolean isMainThread() {
        
        return Looper.getMainLooper().getThread().getId() == Thread.currentThread().getId();
    }

看到这里，许多小伙伴就会发现一个问题，上面说过，Looper会一直卡在一个死循环的状态，等待消息的进来，那么，为什么Looper不会阻塞主线程呢？为什么不会导致ANR呢？先来看看Loop（）方法：

while (true) {
        
           //取出消息队列的消息，可能会阻塞
           Message msg = queue.next(); // might block
           //解析消息，分发消息
           msg.target.dispatchMessage(msg);
           ...
        }

显而易见，如果Main方法中没有Looper进行循环，那么主线程一运行完毕就会退出，那为什么不会导致ANR呢？原因是因为我们知道Android是由事件驱动的，Looper.loop()方法会不断的去接收事件、处理事件，当用户每点击触摸或者说Activity的生命周期都是运行在Looper.loop()的控制之下，如果它停止了运行，那所对应的应用也会随之停止。

何为ANR？ANR（Application Not Responding）也就是"应用无响应"，通常一下两种情景会导致应用发生ANR：

1.  5s内无法响应用户输入事件(例如键盘输入, 触摸屏幕等).
2.  BroadcastReceiver在10s内无法结束.

造成以上两种情况的首要原因就是在主线程(UI线程)里面做了太多的阻塞耗时操作, 例如文件读写, 数据库读写, 网络查询等等.换种说法说，就是当前的事件没有机会得到处理，或者当前的事件正在处理，但是没有及时完成，主线程Looper从消息队列读取消息，当读完MessageQueue里面的所有消息时，主线程会进入阻塞状态，等待下一条消息的到来，子线程会往消息队列发送消息，然后主线程会被唤醒，主线程被唤醒只是为了读取消息，当消息读取完毕，再次睡眠。因此loop的循环并不会对CPU性能有过多的消耗。总得来说，Looper.loop()可能会引起主线程的阻塞，但只要它的消息循环没有被阻塞，能一直处理事件就不会产生ANR。可见，Looper的死循环和应用ANR是两个不同的概念。

主要的东西了解完了，那我们就说点与Handler相关的知识点

***如何实现线程之间切换？***

那么Handler是如何实现线程之间的切换的呢？

例如现在有A、B两个线程，在A线程中有创建了Handler，然后在B线程中调用Handler发送一个Message，通过上面的分析我们可以知道，当在A线程中创建Handler的时候，同时创建了MessageQueue与Looper，Looper在A线程中调用Loop进入一个无限的for循环从MessageQueue中取消息并处理，当B线程调用Handler发送一个Message的时候，会通过msg.target.dispatchMessage(msg);将Message插入到Handler对应的MessageQueue中，Looper发现有Message插入到MessageQueue中，便取出Message执行相应的逻辑，因为Looper.loop()是在A线程中启动的，所以则回到了A线程，从而实现了线程间的切换。

***为什么一个线程只能有一个Looper？***  
以下源码保证了一个线程只有一个Looper

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？***  
可以在子线程中创建Handler，我们需要调用Looper.perpare和Looper.loop方法，或者通过获取主线程的looper来创建Handler，就是在创建Handler的时候把主线程的Handler传进去可以了，eg：Handler handler = new Handler（MainLooper）；

***Handler内存泄漏问题及解决方案***  
内部类持有外部类的引用导致了内存泄漏，如果Activity退出的时候，MessageQueue中还有一个Message没有执行，这个Message持有了Handler的引用，而Handler持有了Activity的引用，导致Activity无法被回收，导致内存泄漏。使用static关键字修饰，在onDestory的时候将消息清除，或者使用弱引用来进行处理，在垃圾回收器线程扫描它所管辖的内存区域的过程中，一旦发现了只具有弱引用的对象，不管当前内存空间足够与否，都会回收它的内存，因此可以解决内存泄漏的问题。

***Handler的sendMessage和post的区别***  
首先来看一段sendMessage和post的代码：

**1. sendMessage的用法：**

private TextView mTextView;
    private String content = "";
    
    
    Handler mHandler = new Handler() {
        
        public void handleMessage(Message msg) {
        
            if (msg.what == 0) {
        
                //sendMessage方法更新UI的操作必须在handler的handleMessage回调中完成
                mTextView.setText(content);
            }
        }
    };
    
    @Override
    protected void onCreate(Bundle savedInstanceState) {
        
        super.onCreate(savedInstanceState);
        setContentView(R.layout.activity_main);
        new Thread(new Runnable() {
        
            @Override
            public void run() {
        
                content = "sendMessage更新UI";
                //sendMessage方法解决UI更新发送消息给handler（主线程中的handler）
                mHandler.sendEmptyMessage(0);
            }
        }).start();

**2. post的用法：**

private TextView mTextView;
    private String content = "";
    //实例化Handler
    private Handler mHandler = new Handler();
    @Override
    protected void onCreate(Bundle savedInstanceState) {
        
        super.onCreate(savedInstanceState);
        setContentView(R.layout.activity_main);
        //这里调用了post方法
         mHandler.post(new Runnable() {
        
                @Override
                public void run() {
        
                    mTextView.setText(content);
                }
            });
        }
    }).start();

public final boolean post(Runnable r){
        
       return  sendMessageDelayed(getPostMessage(r), 0);
    }
    
    
    public final boolean sendMessage(Message msg){
        
       return sendMessageDelayed(msg, 0);
    }

可见，两个方法都是通过调用sendMessageDelayed方法实现的，所以可以知道它们的底层逻辑是一致的。  
但是，post方法的底层调用sendMessageDelayed的时候，却是通过getPostMessage（r）来将Runnable对象来转为Message，post的方法最终会进入到sendMessageAtTime这个方法里面：

public boolean sendMessageAtTime(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);
    }

所以可以知道，handler.post和handler.sendMessage本质上是没有区别的，都是发送一个消息到消息队列中，只不过post使用方式更简单。附上消息出队列的代码：

/**
         * Handle system messages here.
         */
        public void dispatchMessage(Message msg) {
        
             //如果是post.callback不为空，直接进入handleCallback
            if (msg.callback != null) {
        
                handleCallback(msg);
            } else {
        
                if (mCallback != null) {
        
                    if (mCallback.handleMessage(msg)) {
        
                        return;
                    }
                }
                handleMessage(msg);
            }
        }
    
        //直接run并不会启动新线程，所以这就是post的runnable里面可以直接更新UI的原因
       private static void handleCallback(Message message) {
        
        message.callback.run();

暂时就先写到这啦，如有问题，欢迎指出！