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,这就会大大的加快速度,增加用户的良好体验)。