是否应该使用Loaders访问Web服务？

Question

根据我的理解，Loader框架适用于访问ContentProvider / SQLite数据库中本地存储的数据。我们有CursorLoader类可以很好地处理这个用例。

但我想知道使用Loader框架编写扩展Loader / AsyncTaskLoader以访问远程Web服务（例如REST Web服务）的类是否切实可行？我一直认为这个框架对于这个用例来说有点过于僵化和混乱（缺乏适当的文档）。我更喜欢使用AsyncTasks / Services以更常规的方式处理REST调用。但最近我发现了一些使用AsyncTaskLoaders的文章，并开始怀疑。

那么为什么有人会使用Loaders访问Web服务？我在这里看到的唯一优势是装载机自动保留其结果。之后没有Cursor可以管理。

Answer 1

实际上，您可能希望使用 Volley 等网络库。这有一些很好的功能，如请求批处理和图像缓存。尽管如此，为了论证，我们可以比较Service，Loader和AsyncTask。

如果您希望在更改活动或后台应用程序时允许加载继续，则可以使用服务。或者，如果要导出服务，以便多个应用程序可以使用它。否则，请使用Loader或AsyncTaskLoader。

与AsyncTasks相比，加载器具有一些优势。

• 他们不太可能在Activity完成后通过执行代码导致崩溃，因为他们知道android生命周期。
• 该设计不鼓励引用View或活动。这减少了在活动结束后强制活动停留在内存中的可能性。
• 监视数据源的更改并在发生更改时触发回调
• 他们内置了缓存，在旋转后很有用。对于Cursor s，CursorLoader会自动重新连接到正确的位置以加载最后一个Cursor

然而，它们也有缺点

• API比AsyncTask 非常麻烦。特别是如果您关心与旧版Android的兼容性
• 您已经在onSaveInstanceState（）中存储了UI状态，因此使用Loader会导致您以多种方式保存状态。阅读和理解这可能会令人困惑。特别是如果你最终将保留的碎片混合到混合物中。
• Loader缓存加载的结果，而不是实际需要的UI状态

我假设您只是从Web服务中读取而不是编写。如果您正在对Web服务执行更新，并且需要查看服务的响应，那么这会改变一些事情。如果在轮换期间收到响应，则使用AsyncTask可能会阻止您获得响应。

Answer 2

有些情况下，Loader适用于Web服务：当您的服务器可以将推送通知发送回客户端以通知数据已更改时。