Android 消息机制，异步和多线程

核心提示：B, C, D都可以来处理同一线程内的消息分发，但各自都只能处理属于自己的那一份消息，Android 消息机制，异步和多线程(2)，这抹杀了B想偷偷进入A领地，越俎代庖做一些非份之事的可能(从理论上看，因此只重写了onQueryComplete函数：queryHandler = new AsyncQueryHandle

B, C, D都可以来处理同一线程内的消息分发，但各自都只能处理属于自己的那一份消息，这抹杀了B想偷偷进入A领地，越俎代庖做一些非份之事的可能(从理论上看，B还是有可能把消息伪装的和A他们家的一样，我没有尝试挑战一下google的智商，有BT需求的自行研究^_^)。这样做，不但兼顾了灵活性，也确保了安全性，用起来也会简单，我的地盘我做主，不用当心伤及无辜，左拥右抱是一件很开心的事情。。。

很显然，消息发送者不局限于自己线程，否者只能做一些定时，延时之类的事情，岂不十分无趣。在实例化Handler的时候，Looper可以是任意线程的，只要有Handler的指针，任何线程也都可以sendMessage(这种构造方式也很有意思，你可以在A线程里面传B线程的Looper来构造 Handler，也可以在B线程里构造，这给内存管理的方法带来很大的变数...)。但有条规则肯定是不能破坏的，就是非UI线程，是不能触碰UI类的。在不同平台上有很多解决方式(如果你有多的不能再多的兴趣，可以看一下很久很久以前我写的一个，不SB不要钱)。我特意好好跟了一下android中的 AsyncQueryHandler类，来了解google官方的解决方案。

AsyncQueryHandler是Handler的子类，文档上说，如果处理ContentProvider相关的内容，不用需要自行定义一套东西，而可以简单的使用async方式。我想指代的就应该是AsyncQueryHandler类。该类是一个典型的模板类，为 ContentProvider 的增删改查提供了很好的接口，提供了一个解决架构，final了一些方法，置空了一些方法。通过派生，实例化一些方法(不是每个对 ContentProvider的处理多需要全部做增删改查，我想这也是该类默认置空一些方法而不是抽象一些方法的原因)，来达到这个目的。在内部，该类隐藏了多线程处理的细节，当你使用时，你会感觉异常便利。以query为例，你可以这么来用：

// 定义一个handler，采用的是匿名类的方式，只处理query，因此只重写了onQueryComplete函数：

queryHandler = new AsyncQueryHandler(this.getContentResolver()){ // 传入的是一个ContentResolver实例，所以必须在OnCreate后实例化该Handler类

@Override

protected void onQueryComplete(int token, Object cookie, Cursor cursor) {

// 在这里你可以获得一个cursor和你传入的附加的token和cookie。

// 该方法在当前线程下(如果传入的是默认的Looper话)，可以自由设定UI信息