异步操作之Handler + Thread

作者: BlainPeng | 来源:发表于2016-04-10 19:51 被阅读313次

在android 开发中，说到异步操作，我们马上会想到一种实现方式：Handler+ Thread。其实也就是Android的消息机制。

为什么需要Handler？

由于android开发规范的限制，我们一般不会在主线程（或者叫UI线程）中去做一些耗时操作，否则会导致程序无法响应
即ANR。所以我们会把耗时操作放在子线程中，因子线程不能直接访问UI控件（UI的更新只能由主线程来控制），然后通
过Handler，将更新UI的操作切换到主线程中执行。

为什么不允许在子线程中访问UI？

Android的UI控件不是线程安全的，如果在多线程中并发访问可能会导致UI控件处于不可预期的状态，也许你会想到对UI控件的访问加上锁机制，但有两个缺点：

加上锁机制会让UI访问的逻辑变得复杂；
锁机制阻塞某些线程的执行，会降低UI访问的效率。

Handler是如何切换线程的？

1、Handler发送消息

在主线程中，我们一般会这样做：

private Handler handler = new Handler(){
    @Override
    public void handleMessage(Message msg) {
        //TODO
    }
};

然后，在子线程通过handler发送消息：

 Message msg = Message.obtain();
 ...
 handler.sendMessage(msg);

此时，深入Handler的源码中，可以看sendMessage方法最终会调用下面这个方法：

public boolean sendMessageAtTime(Message msg, long uptimeMillis) {
    MessageQueue queue = mQueue;
    ...
    return enqueueMessage(queue, msg, uptimeMillis);
}

此时，我们看到Handler的好哥们之一：MessageQueue

MessageQueue 消息队列，内部是一个单链表的数据结构（单链表在数据的插入和删除比较有优势）。
主要包含两个操作：插入和读取

1､插入

    boolean enqueueMessage(Message msg, long when) {
    // 首先检测消息的合法性：是否有处理它的Handler和是否已经在处理中
    if (msg.target == null) {
        throw new IllegalArgumentException("Message must have a target.");
    }
    if (msg.isInUse()) {
        throw new IllegalStateException(msg + " This message is already in use.");
    }

    synchronized (this) {
        //判断 mQuiting 是否中止
        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 {
            // 当前消息队列已经处于 Blocked 状态，且队首是一个消息屏障(和内存屏障的理
            // 念一样，这里是通过 p.target == null 来判断队首是否是消息屏障)，并且要
            // 插入的消息是所有异步消息中最早要处理的才会 needwake 激活消息队列去获取
            // 下一个消息。这样减少了同步地操作
            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､读取

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

        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) {
                // 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 {
                    // 否则这个消息就是需要处理的消息，将该消息设置为 inuse，并将队列设置为非 blocked 状态，然后返回该消息
                    // Got a message.
                    mBlocked = false;
                    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;
            }
            ...
    }
}

它是一个无限循环，如果消息队列中没有消息，那么next方法会一直阻塞在这里。当有新消息到来时，next方法会返回这条消息并将其从单链表中移除。那么这个next方法是在哪里被调用的呢？此时，我们Handler另外一个好哥们Looper闪亮登场了。

Looper的作用

它在Android的消息机制中扮演着消息循环的角色，具体来说就是它会不停地从MessageQueue中查看是否有新消息，如果有新消息就会立刻处理，否则就一直阻塞在那里。

Looper的工作原理

当我们的UI线程一启动时，通过Looper里面的prepare方法为当前线程创建一个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));
}

sThreadLocal是一个ThreadLocal对象，可以在一个线程中存储变量。可以看到，将一个Looper的实例放入了ThreadLocal，并且判断了sThreadLocal是否为null，否则抛出异常。这也就说明了Looper.prepare()方法不能被调用两次，同时也保证了一个线程中只有一个Looper实例。接下来看Looper的构造方法：

  private Looper(boolean quitAllowed) {
    mQueue = new MessageQueue(quitAllowed);
    mThread = Thread.currentThread();
}

此时，我们看到了Looper与MessageQueue联系到一起了。紧接UI Thread会调用loop方法，开启消息循环系统

    public static void loop() {
    // 方法直接返回了sThreadLocal存储的Looper实例，如果me为null则抛出异常，也就是说looper方法必须在prepare方法之后运行
    final Looper me = myLooper();
    if (me == null) {
        throw new RuntimeException("No Looper; Looper.prepare() wasn't called on this thread.");
    }
    // 拿到该looper实例中的mQueue（消息队列）
    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;
        }
        ...
        // 把消息交给msg的target的dispatchMessage方法去处理。msg的target是什么呢？其实就是handler对象
        msg.target.dispatchMessage(msg);
        
        // 释放消息占据的资源
        msg.recycleUnchecked();
    }
}

loop方法是一个死循环，唯一跳出循环的方法是MessageQueue的next方法返回了null，那什么情况下会返回null了？当Looper的quit方法被调用时，Looper就会调用MessageQueue的quit或者quitSafely方法就会通知消息队列退出，当消息队列被标记为退出状态时，它的next方法就会返回null。也就是说，Looper必须退出，否则loop方法就会无限循环下去。

loop方法调用MessageQueue的next方法来获取新消息，而next是一个阻塞操作，当没有消息时，next方法会一直阻塞在那里，这也导致loop方法一直阻塞在那里。如果MessageQueue的next方法返回了新消息，Lopper就会通过msg.target.dispatchMessage(msg)来处理这条消息，这里的msg.target是发送这条消息的Handler对象，这样Handler发送的消息最终又交给它的dispatchMessage方法来处理了。但是这里不同的是，Handler的dispatchMessage方法是在创建Handler时所使用的Looper中执行的，这样就成功地将代码逻辑切换到指定的线程中去执行了。

2、Handler处理消息

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

哈哈，终于看到我们熟悉的handleMessage方法了。

1､检查Message的callback是否为null，不为null就通过handleCallback来处理消息。Message的callback是一个Runnable对象，实际上就是Handler的post方法所传递的Runnable参数（post一系列方法最终是通过send的一系列方法来实现的）

private static void handleCallback(Message message) {
    message.callback.run();
}

我们有时直接用Handler的post方法来处理异步操作：

mHandler.post(new Runnable()  
    {  
        @Override  
        public void run()  
        {   
            //UI操作 
            //虽然这里可以直接写更新UI的代码，但这个Runnable并没有创建什么线程，而只是发送了一条消息，
        }  
    });

紧接着继续深入post方法源码的实现：

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

// 可以看到，在getPostMessage中，得到了一个Message对象，然后将我们创建的Runable对象作为callback属性，赋值给了此message.
private static Message getPostMessage(Runnable r) {
    Message m = Message.obtain();
    m.callback = r;
    return m;
}

最终也会调用到enqueueMessage方法，执行与上面分析的逻辑。

2、或者检查mCallback是否为null，不为null就调用mCallback的handleMessage方法来处理消息。

/**
 * Callback interface you can use when instantiating a Handler to avoid
 * having to implement your own subclass of Handler.
 * Callback可以用来创建一个Handler的实例但并不需要派生Handler的子类。
 *
 * @param msg A {@link android.os.Message Message} object
 * @return True if no further handling is desired
 */
public interface Callback {
    public boolean handleMessage(Message msg);
}

在日常开发中，创建Handler最常见的方式就是我们上面提到的，而Callback给我们提供了另外一种使用Handler的方式，当我们不想派生子类时，就可以通过Callback来实现。

3､最后就是执行我们重写的handleMessage方法了。到这里整个异步操作就执行完成了。这也是整个android消息机制实现的原理。

内存泄漏

内存泄漏是如何产生的？

上方提到的创建Handler的方式，在Eclipse当中会报Warning，提示会出现Memory Leak，面试的时候也经常会被问到，那么Handler是如何造成内存泄漏的了？首先看两个测试：

public class OutterClass {

    private int outValue = 7;
    private String name = "OuterClass";

    class InnerClass {
        public void printOutterField() {
            System.out.println(outValue + ":" + name);
        }
    }

}


public class MyClass {
    public static void main(String[] args){

        OutterClass outer = new OutterClass();
        OutterClass.InnerClass inner = outer.new InnerClass();
        inner.printOutterField();
    }
}

此时我们通时javap -c OutterClass来查看其字节码情况

QQ20160410-0@2x.png

这个access$000和access$100是谁访问的？并且请注意其返回值，一个是String，一个是int, 继续看内部类的字节码

jvaptest.jpg

看红色线部分，可知access$000和access$100是在printOutterField方法内调用的，并且注意这个东西：this$0，这个是什么？其实就是内部类持有外部类的引用。所以我们回到Handler上，如若按照文章刚开始那种方式创建Handler，那么Handler就持有Activity的引用。那Handler是在哪里持有Activity的引用的呢？还记得上面我们分析过的loop方法，它内部是一个无限循环去从MessageQueue中获取Message，然后通过msg.target.dispatchMessage(msg)方法来处理消息，而这个msg.target就是一个handler，上文已详细分析过了。所以，当Activity被销毁且被GC回收的时候，一看到Activity仍然被一个对象所持有，就不会回收这个Activity，此时就造成内存泄漏了。

如何避免内存泄漏了？

还是回到上面那个测试例子。我们可以这样做：

public class OutterClass {

    private static int outValue = 7;
    private static String name = "OuterClass";

    static class InnerClass {
        public void printOutterField() {
            System.out.println(outValue + ":" + name);
        }
    }

}

public class MyClass {
    public static void main(String[] args){
        OutterClass.InnerClass inner = new OutterClass.InnerClass();
        inner.printOutterField();
    }
}

我们再看一下内部类的情况：

javatest2.jpg

此时我们再也看不到内部类对外部类的持用引用了：this$0。似乎问题得到解决了，我们创建Handler直接把它变成static不就ok了，但我若在Handler类部使用Activity的属性时，难道全部变成static的？
我们可以用下面的方式来解决：

private  TextView tv;
private static class MyHandler extends Handler
{
    private final WeakReference<MainActivity> mActivity;
    public MyHandler(MainActivity mainActivity)
    {
        this.mActivity=new WeakReference<MainActivity>(mainActivity);
    }
    @Override
    public void handleMessage(Message msg) {

        MainActivity activity=mActivity.get();
        if (activity!= null)
        {
            activity.tv.setText("123");
        }
    }

}

private MyHandler myHandler=new MyHandler(MainActivity.this);

private static final Runnable sRunnable = new Runnable() {
  @Override
  public void run() { /* ... */ }
};

在gc时，一旦发现了只具有弱引用的对象，不管当前内存空间足够与否，都会回收它的内存。不过，由于垃圾回收器是一个优先级很低的线程，因此不一定会很快发现那些只具有弱引用的对象。

参考资料：

Android开发艺术探索

http://www.cnblogs.com/punkisnotdead/p/4943260.html

http://blog.csdn.net/kesalin/article/details/37765707

异步操作之Handler + Thread

为什么需要Handler？

为什么不允许在子线程中访问UI？

Handler是如何切换线程的？

1、Handler发送消息

2、Handler处理消息

内存泄漏

相关文章

网友评论

延伸阅读

深度阅读

栏目导航

热点阅读

Android知识