Android消息处理机制:源码剖析Handler、Looper,并实现图片异步加载

引言

我们在做 Android 开发时,常常需要实现异步加载图片/网页/其他。事实上,要实现异步加载,就需要实现线程间通信,而在 Android 中结合使用 Handler、Looper、Message 能够让不同的线程通信,完成异步任务。虽然 Android 官方为我们提供了 AsyncTask 类来完成异步任务,但这个类存在许多问题,并不好用,而且,AsyncTask 也是通过 Handler 和 Thread 来实现异步加载的,所以学习这方面的知识是有必要的

本文讲解思路大致如下:绘制 Android 消息处理机制图 -> 源码剖析消息处理机制中的组件 -> 实现一个图片异步加载 Demo。最终 Demo 效果图如下:

Android 消息处理机制剖析

消息处理模型

我们不妨先想想,一个消息处理机制需要什么?当然是:

  • 消息源
  • 消息队列
  • 消息处理器
  • 消息管理器

其中消息管理器又将划分为三个子模块:消息获取、消息分发、消息循环。我们先不管 Android 内部将如何实现消息处理机制(因为处理机制的抽象结构肯定是一样的,只是具体实现不一样),按照我们列出来的4大模块画出一个简单的消息处理模型:

Android 消息处理组件

现在我们已经知道消息处理模型需要哪些组件了,那就去 Android SDK 里面找相应的类吧~然后我们会发现下面四个类:

  • Message 类代表消息
  • MessageQueue 类代表消息队列
  • Handler 代表消息获取、消息处理
  • Looper 代表消息循环、消息分发

可能有人会怀疑我在吹nb,在骗大家,这个时候我只能选择看源码了……为了方便大家理解,我将从 Looper 类开始分析,因为 Looper 类在消息处理机制中是个“承上启下”的功能模块。

Looper

在解析 Looper 之前,不妨先来想想为什么需要 Looper 吧。

我们在进行 Android 开发的时候,为了不阻塞主线程(UI 线程),常常需要另开一个线程完成一些操作,而这些操作有一些执行一次就完了,有一些可能需要执行几次,几十次,甚至只要程序进程存活就要不断执行该操作。而普通线程通过 start() 方法只能执行相关动作一次,为了满足多次执行的需求,于是有了 Looper。

那么我们就进入 Looper 的源码,看看 Looper 中有哪些成员吧:

public final class Looper {
    private static final String TAG = "Looper";

    static final ThreadLocal<Looper> sThreadLocal = new ThreadLocal<Looper>();
    private static Looper sMainLooper;  // guarded by Looper.class

    final MessageQueue mQueue;
    final Thread mThread;

    private Printer mLogging;
}

大家可以看到,Looper 的核心成员是一个消息队列,该Looper 对应的线程,ThreadLocal 对象,和一个主线程 Looper 的引用。我们根据 Looper 的使用流程来分析它们的作用:

要使用 Looper,就必须调用 Looper 的 prepare() 方法:

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

我们可以看到,调用 prepare 方法后会通过 ThreadLocal 的 set 方法创建一个 Looper 对象,而且一个线程只能创建一个 Looper,我们不妨看看 ThreadLocal 通过 set 方法对 Looper 对象干了啥:

    public void set(T value) {
        Thread currentThread = Thread.currentThread();
        Values values = values(currentThread);
        if (values == null) {
            values = initializeValues(currentThread);
        }
        values.put(this, value);
    }

实际操作 Looper 对象的是 values() 方法返回对象

Values values(Thread current) {
        return current.localValues;
    }

values() 方法返回的对象是一个线程的内部变量,我们再进去看看会发现:在 Thread 类内部是这样定义 localValues 的 - ThreadLocal.Values localValues。也就是说,set 方法实际完成的操作是,将 Looper 对象与线程绑定,并且该 Looper 对象只在该线程内有效,其他线程无法访问该 Looper 对象。

执行完 prepare() 方法之后,我们就要调用 Looper 的 loop() 方法来实现循环了:

    public static void loop() {
        final Looper me = myLooper();
        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
            Printer logging = me.mLogging;
            if (logging != null) {
                logging.println(">>>>> Dispatching to " + msg.target + " " +
                        msg.callback + ": " + msg.what);
            }

            msg.target.dispatchMessage(msg);

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

方法有点长,但实际逻辑比较简单:首先判断 prepare() 方法是否被调用,以确保 Looper 和某个线程绑定(需要注意的是:默认情况下,新建的 Looper 对象都与主线程绑定),然后获取对应线程的消息队列,之后就不断循环读取队列中的消息,如果队列中没有消息时 Loop() 方法就会结束(一般不会出现这种情况),否则将消息交给 msg.target 对象分发。

以上就是 Looper 的核心代码了,通过分析我们可以了解到 Looper 与线程的关系,以及在消息分发机制中所起的作用,如图:

Message

既然我们在分析 Looper 源码的最后提到了 Message 类,那么我们就先来看看 Message 类~那么 Message 类作为消息的载体到底存储了什么,做了什么呢?

public final class Message implements Parcelable {
    public int what;

    public int arg1; 

    public int arg2;

    public Object obj;

    public Messenger replyTo;

    public int sendingUid = -1;

    /*package*/ static final int FLAG_IN_USE = 1 << 0;

    /** If set message is asynchronous */
    /*package*/ static final int FLAG_ASYNCHRONOUS = 1 << 1;

    /** Flags to clear in the copyFrom method */
    /*package*/ static final int FLAGS_TO_CLEAR_ON_COPY_FROM = FLAG_IN_USE;

    /*package*/ int flags;

    /*package*/ long when;

    /*package*/ Bundle data;

    /*package*/ Handler target;

    /*package*/ Runnable callback;

    // sometimes we store linked lists of these things
    /*package*/ Message next;

现在我们可以知道,原来刚刚处理消息的 target 就是 Handler 类的对象啦。在 Message 类里,what 用于辨识 Message 的用途,arg1 和 arg2 用于传递一些简单的数据,obj 用于传递对象,data 用于传递复杂数据。

Message 类的方法我觉得是没啥好说的,基本上都是 get/set 方法,当然还有回收方法,例如在 Looper 的 loop() 方法中,每一次循环结束都会执行 Message 的 recycleUnchecked() 方法,将被分发 Message 对象回收。

可能有人会奇怪,消息如果没有被处理就被回收了不会发生消息丢失的情况吗?莫慌,等会我会在分析 Handler 处理消息的时候给大家解释。

Handler

我们在前面的分析中看到,真正处理消息的是 Handler 的 dispatchMessage() 方法,那么我们就从这个方法入手分析 Handler 吧:

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

在 dispatchMessage() 方法中,如果 msg 的 callback 不为 null 会调用 Handler 的 handleMessage() 方法处理消息。也就是说,只要消息的 callback 不为 null,就会调用 handleCallback() 方法,那么未处理的消息会不会回到消息队列呢?

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

看到这里有没有恍然大悟的感觉呢?刚刚我们在分析 Message 源码的时候已经知道,callback 就是 Runnable 接口的实例,也就是说,如果消息没有被处理,就会回到消息队列中啦。那么 Handler 又是怎样处理消息的呢?

    public void handleMessage(Message msg) {
    }

竟然是个空方法……不过也很正常,因为 Handler 类只需要提供抽象,具体的处理逻辑应该由开发者决定嘛。那我们分析就到此为止了吗?才没有!我们还没有剖析 Handler 能够实现异步事件处理的原因呢,回到 Handler 的源码,我们会看到下面这个代码段:

    final MessageQueue mQueue;
    final Looper mLooper;
    final Callback mCallback;
    final boolean mAsynchronous;
    IMessenger mMessenger;

我靠……Handler 里面居然拥有消息队列、Looper、异步标志位,我们回想一下刚刚分析得到过什么结论:一个 Looper 只能属于一个线程,Looper 有对应线程的消息队列。我们再来看看 Handler 的构造方法,随便挑一个吧:

    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();
        if (mLooper == null) {
            throw new RuntimeException(
                "Can‘t create handler inside thread that has not called Looper.prepare()");
        }
        mQueue = mLooper.mQueue;
        mCallback = callback;
        mAsynchronous = async;
    }

我们可以看到,Handler 内的消息队列就是 Looper 里的消息队列,也就是说 Handler 能够与任何一个线程的消息队列进行通信,并处理其中的消息,或者发送信息到其他线程的消息队列中!

异步处理 Demo

完成上面的分析以后,我们就知道在 Android 中的消息处理机制了,那么现在就来实现一个异步处理 Demo吧。Demo 非常简单,就是异步下载一张图片,并把它显示到一个 ImageView 中,代码比较多,就只给出核心代码,下面有下载地址:

public class DownloadTask implements Runnable{
…………
    private void updateMsg(Message msg){
        Bundle data = new Bundle();
        Bitmap img = downImage(url);

        data.putString("url", url);
        data.putParcelable("img", img);
        msg.setData(data);
    }

    public Bitmap downImage(String url) {
        Bitmap img = null;

        try {
            URL mUrl = new URL(url);
            HttpURLConnection conn = (HttpURLConnection) mUrl.openConnection();
            conn.setDoInput(true);
            conn.connect();

            InputStream is = conn.getInputStream();
            img = BitmapFactory.decodeStream(is);
        } catch (IOException e) {
            Log.d(TAG, "downloadImg-Exception");
        }

        return img;
    }
}

DownloadTask 类负责处理下载任务,下载开始下载任务,下载任务完成后将图片地址和图片存到 msg 里边,发送给 DownloadHandler :

public class DownloadHandler extends Handler{
……

    @Override
    public void handleMessage(Message msg) {
        String url = msg.getData().getString("url");
        Bitmap img = msg.getData().getParcelable("img");

        Log.d(TAG, url);

        loader.iLoader.update(img);
    }
}

最后通过 ILoader 接口更新外部 UI:

    public interface ILoader {
        public void update(Bitmap img);
    }
}

下载地址

时间: 2024-10-10 10:27:27

Android消息处理机制:源码剖析Handler、Looper,并实现图片异步加载的相关文章

Android -- 消息处理机制源码分析(Looper,Handler,Message)

android的消息处理有三个核心类:Looper,Handler和Message.其实还有一个Message Queue(消息队列),但是MQ被封装到Looper里面了,我们不会直接与MQ打交道,因此我没将其作为核心类.下面一一介绍: Looper Looper的字面意思是“循环者”,它被设计用来使一个普通线程变成Looper线程.所谓Looper线程就是循环工作的线程.在程序开发中(尤其是GUI开发中),我们经常会需要一个线程不断循环,一旦有新任务则执行,执行完继续等待下一个任务,这就是Lo

android7.x Launcher3源码解析(3)---workspace和allapps加载流程

Launcher系列目录: 一.android7.x Launcher3源码解析(1)-启动流程 二.android7.x Launcher3源码解析(2)-框架结构 三.android7.x Launcher3源码解析(3)-workspace和allapps加载流程 前两篇博客分别对Lancher的启动和Launcher的框架结构进行了一些分析,这一篇,将着重开始分析界面的加载流程. 1.整体流程 先上一张整体的流程图吧.(图片看不清可以下载下来看或者右击新开个页面查看图片) 先从Launc

自己动手写android图片异步加载库

尊重他人劳动成果,转载请说明出处:http://blog.csdn.net/bingospunky/article/details/44344085 接触android有半年了,关于图片异步加载,一直只用别人的框架,虽然特别方便,但是始终未见识到图片异步加载的庐山真面目.最近比较悠闲,研究一些高大上的东西.在这篇文章总结一下我对图片异步加载的一些学习心得. 图片加载最重要的无非就是内存和线程.大家都知道关于内存溢出一般的解决方案就是LruCache,在我的这个demo里我只要使用SoftRefe

自己动手写android图片异步加载库(二)

在<自己动手写android图片异步加载库>系列的第一篇文章中,主要是学习了使用ReferenceQueue来实现一个内存缓存.在这篇文章中主要是介绍在下载很多图片是怎么控制线程和队列.在这版代码里,加入信号量和队列,可以控制下载任务的顺序.可以控制暂停和结束. 代码A:ImageLoader.java /** * 图片加载工具类 * * @author qingtian * @blog http://blog.csdn.net/bingoSpunky */ @SuppressLint(&qu

Android图片异步加载之Android-Universal-Image-Loader

将近一个月没有更新博客了,由于这段时间以来准备毕业论文等各种事务缠身,一直没有时间和精力沉下来继续学习和整理一些东西.最近刚刚恢复到正轨,正好这两天看了下Android上关于图片异步加载的开源项目,就顺便整理记录下来,作为这一个多月来博客的重新开火做饭吧.从今天起我会陆续恢复博客的更新,也希望大家继续支持. 今天要介绍的是Github上一个使用非常广泛的图片异步加载库Android-Universal-Image-Loader,该项目的功能十分强大,可以说是我见过的目前功能最全.性能最优的图片异

Android图片异步加载之Android-Universal-Image-Loader(转)

今天要介绍的是Github上一个使用非常广泛的图片异步加载库Android-Universal-Image-Loader,该项目的功能十分强大,可以说是我见过的目前功能最全.性能最优的图片异步加载解决方案.做Android的同学都知道,Android加载大量图片时,由于系统分配给图片加载的内存大小有限,所以,如果加载图片量非常大的话容易报OOM异常,关于这个异常已经有不少解决方案了,我就不赘述.下面就简要介绍下这个开源项目的主要功能和使用: 一.功能概要 多线程图片加载: 灵活更改ImageLo

Android图片异步加载

原:http://www.cnblogs.com/angeldevil/archive/2012/09/16/2687174.html 相关:https://github.com/nostra13/Android-Universal-Image-Loader 开发Android程序,一般情况下都会有两个操作,图片的异步加载与缓存,而图片的异步加载大都是从网络读取图片(还有生成本地图片缩略图等操作),为了减少网络操作,加快图片加载速度就需要对图片进行缓存,所以网上的好多图片异步加载方法都是与图片的

Android新浪微博客户端(七)——ListView中的图片异步加载、缓存

原文出自:方杰|http://fangjie.sinaapp.com/?p=193转载请注明出处 最终效果演示:http://fangjie.sinaapp.com/?page_id=54该项目代码已经放到github:https://github.com/JayFang1993/SinaWeibo 一.ListView的图片异步加载 我们都知道对每一个Weibo Item都有用户头像,而且每一条微博还可能带有图片.如果在加载列表的同时加载图片,这样有几个缺点,第一很费事,界面卡住,用户体验很不

Android ListView 图片异步加载和图片内存缓存

开发Android应用经常需要处理图片的加载问题.因为图片一般都是存放在服务器端,需要联网去加载,而这又是一个比较耗时的过程,所以Android中都是通过开启一个异步线程去加载.为了增加用户体验,给用户省流量,一般把加载完的图片先缓存下来,下次加载的时候就不需要再联网去服务器端加载.图片缓存一般分为一级缓存(即内存缓存)和二级缓存(即磁盘缓存).这里只讲一级缓存. 内存缓存就是把加载完的图片先放在手机内存中,等下次加载的时候再从内存中取出来. 优点是速度快,缺点是不能长久保存,用户退出应用程序之