应该使用 Loaders 来访问 Web 服务吗？

Posted 2023-04-14

【中文标题】应该使用 Loaders 来访问 Web 服务吗？

【英文标题】：Should Loaders be used to access web services?

【发布时间】：2013-05-06 19:39:11

【问题描述】：

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

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

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

【问题讨论】：

你能分享你所指的教程吗？

给你：neilgoodman.net/2011/12/26/…

【参考方案1】：

实际上，您可能希望使用像 Volley 这样的网络库。这有一些不错的功能，例如请求批处理和图像缓存。尽管如此，为了争论，让我们比较Service、Loaders 和AsyncTask。

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

Loader 比 AsyncTasks 有一些优势。

它们不太可能通过在 Activity 完成后执行代码而导致崩溃，因为它们知道 android 生命周期。 该设计不鼓励引用Views 或活动。这减少了强制 Activity 在完成后留在内存中的可能性。 监控数据源的变化并在发生变化时触发回调 它们内置了缓存，可以在旋转后使用。对于Cursors，CursorLoader 会在正确位置自动重新连接到最后加载的光标

但是，它们也有缺点

API 比AsyncTask

极其繁琐

。特别是如果您关心与旧版 Android 的兼容性 您已经在 onSaveInstanceState() 中存储 UI 状态，因此使用 Loader 会导致您以多种方式保存状态。这可能会让人难以阅读和理解。特别是如果您最终将保留的片段混合到混合物中。 Loader 缓存加载的结果，而不是您实际需要的 UI 状态

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

【参考方案2】：

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