android AsyncQueryHandler的分析

AsyncQueryHandler

这个类继承了Handler 实现了 ContentProvider处理相关的一些操作的异步方式

与其说这个类提供给我们一个处理ContentProvider的方法 我觉得这更给我们提供了一个处理异步的方案

若我们不用AsyncQueryHandler，直接在UI 线程调用ContentResolve去操作数据库比如查询，若你的数据库的数据很少还好，若很多，就会出现ANR了。一般解决ANR,就是开 thread去解决。让UI线程知道何时查询完毕，可以更新UI将查询的结果表现出来

首先分析一下 AsyncQueryHandler 这个类

他的基本策略如下：

　　1. 当你实例化一个AsyncQueryHandler类时（包括其子类...），它会单件构造一个新线程HandlerThread，这个线程里面会构建一个消息循环。

　　2. 获得该消息循环的指针，用它做参数实例化另一个Handler类，该类为内部类（用HandlerThread的Looper构建mWorkerThreadHandler-->WorkerHandler）。至此，就有了两个线程，各自有一个Handler来处理消息。

　　3. 当调用AsyncQueryHandler.startQuery()、startInsert()等的时候，在AsyncQueryHandler.startQuery()内部会将请求封装成一个内部的参数类，将其作为消息的参数，将此消息用mWorkerThreadHandler发送(args.handler
=
this;Message中储存了AsyncQueryHandler)。

　　4. WorkerHandler的handleMessage中调用了ContentResolver的insert、delete等方法，获得查询结果后将Cursor用AsyncQueryHandler发送。

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

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

通过上面的HandlerThread的用法可以看到我们启动新线程进行操作的代码是很冗余很繁琐的 把更多对Handler的操作暴露出来了

这样是很不利于维护和复用的（虽然有时候没有必要 这不显得比较NB嘛）

那通过这个类我们只需要实例化的时候传入ContentResolver 并实现自己的回调方法onXXXComplete 最后调用你需要的操作就可以

确实代码简洁了 想知道怎么回事去反编译android的代码去吧

那我觉得如果有什么非ContentProvider操作，却需要异步多线程执行的话，模拟一套，是个不错的选择

官方解释是一个异步帮助类(A
helper class to help make handling asynchronous

ContentResolver

queries
easier.) 。这个类的主要作用就是异步对DB数据库进行操作，加快其数据处理的速度（这个非常重要，特别是大容量的数据处理时，例如几千联系人的数据读取，按正常的处理速度会非常的慢，使用AsyncQueryHandler，这就会大大的加快速度，增加用户的良好体验）。