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

核心提示：5. 构造一个消息，将上述返回值以及其他相关内容绑定在该消息上，Android 消息机制，异步和多线程(4)，发送回主线程，6. 主线程默认的AsyncQueryHandler类的handleMessage方法(可自定义，异步和多线程其实并不复杂，只要有心，但由于都是内部类，基本没有意义...)会分析该消息

5. 构造一个消息，将上述返回值以及其他相关内容绑定在该消息上，发送回主线程。

6. 主线程默认的AsyncQueryHandler类的handleMessage方法(可自定义，但由于都是内部类，基本没有意义...)会分析该消息，并转发给对应的onXXXComplete方法。

7. 用户重写的onXXXComplete方法开始工作。

这就是它偷偷摸摸做过的事情，基本还是很好理解的。我唯一好奇的是它的线程管理方式，我猜测他是用的单件模式。第一个 AsyncQueryHandler的实例化会导致创建一个线程，从此该线程成为不死老处男，所有的ContentResolver相关的工作，都由该线程统一完成。个人觉得这种解决方式很赞。本来这个线程的生命周期就很难估量，并且，当你有一个ContentProvider的请求的时候，判断你会做更多的类似操作并不过分。就算错了，花费的也只是一个不死的线程(与进程同生死共存亡...)，换来的却是简单的生命周期管理和无数次线程生死开销的节约。同时另外一个很重要的问题，他并会涉及到单件中数据同步的问题，每个类都有各自的Handler类，彼此互不干扰，分发可以分别进行。当多个数据请求的时候，在同一个ContentResolver上进行的可能微乎其微，这就避免了堵塞。总而言之，这套解决办法和Android的整体设计算是天作之合了。

建议，如果你有什么非ContentProvider操作，却需要异步多线程执行的话，模拟一套，是个不错的策略，当然，具体情况具体分析，生搬硬套是学不好马列主义的。。。android的消息机制，异步和多线程其实并不复杂，只要有心，就能够学会。