Android中的Loaders机制（4）



实现Loaders

这篇文字将介绍Loader<D>类，并且介绍自定义Loader的实现。这是本系列的第三篇文章。 

一：Loaders之前世界

二：了解LoaderManager

三：实现Loaders

四：实例：AppListLoader

重中之重，如果你还没有读过前面两篇文章，我建议你在深入之前先读一读那两篇文章。先简短的总结一下这篇博客覆盖了什么内容。Loader之前的世界（第一篇）描述了Android3.0之前的数据载入方法和在UI主线程中执行的冗长的查询操作。这些UI非友好的API导致了应用响应变差。总总情况就是了解LoaderManager（第二篇）的写作动机。这篇文章介绍了LoaderManager类，并且讲到了它在异步载入数据中所扮演的角色。LoaderManager在Activity和Fragment的声明周期中管理Loaders，并且在配置变化时保持已载入的数据（译者注：避免了Activity重启导致数据重载入）。

Loader基础

Loades负责在一个单独线程中执行查询，监控数据源改变，当探测到改变时将查询到的结果集发送到注册的监听器上（通常是LoaderManager）。下面这些特性使Loaders成为AndroidSDK中强大的工具：

1. 它封装了实际的数据载入。Activity/Fragment不再需要知道如何载入数据。实际上，Activity/Fragment将该任务委托给了Loader，它在后台执行查询要求并且将结果返回给Activity/Fragment。

2. 客户端不需要知道查询如何执行。Activity/Fragment不需要担心查询如何在独立的线程中执行，Loder会自动执行这些查询操作。这种方式不仅减少了代码复杂度同事也消除了线程相关bug的潜在可能。

3. 它是为安全的事件驱动方式。Loader检测底层数据，当检测到改变时，自动执行新的载入获取最新数据。这使得使用Loader变得容易，客户端可以相信Loader将会自己自动更新它的数据。Activity/Fragment所需要做的就是初始化Loader，并且对任何反馈回来的数据进行响应。除此之外，所有其他的事情都由Loader来解决。

Loaders是一个比较高级的话题，可能需要更多时间来使用它。在下一节中，我们会从分析它的四个定义的特性来开始。

Loader由什么组成？

总共有四个特性最终决定了一个Loader的行为：