在 Android 中处理 JSON 数据的最佳策略是什么？

Question

我正在尝试找出 Android 中数据缓存的最佳策略，特别是考虑到使用数据绑定库。

Android 文档似乎确实非常强调使用内置 SQLite 数据库并在内容提供者的帮助下访问它。但是，假设我的应用程序从 REST API 检索 JSON 格式的数据，使用此策略将需要以下内容：

Make HTTP request --> Parse JSON --> Insert results into DB 
--> Call content provider --> Build model from cursor --> Bind to view

这不仅看起来像是一种非常迂回的方式来做一些相对简单的事情，而且假设所有这些都发生在用户第一次打开应用程序时，结果会在屏幕上出现任何有用的东西之前等待很多很多。

为了加快速度，我可能会决定提前创建模型并让缓存在单独的线程中进行，如下所示：

Make HTTP request --> Build model from JSON --> Bind to view
                  -->(NEW THREAD) --> Insert results into DB 

一旦数据被缓存，用户下次打开应用时会发生以下情况：

Call content provider --> Build model from cursor --> Bind to view

但这当然会增加更多的复杂性，例如迫使我维护代码以从两个来源构建模型：JSON 和内容提供者返回的游标。

鉴于上述情况，我更想放弃 SQLite/ContentProvider 模型，而是执行以下操作：

Make HTTP request --> Build Model and Store JSON to file --> Bind to view

虽然这会大大减少样板文件、解析（大量可用于 JSON 解析的库）和整体复杂性，但这也意味着我无法利用内容提供程序或 SQLite 的功能。

所以问题是，我应该遵循哪种模式？有没有一种情况比另一种更好？或者有没有我不知道的更好的方法来处理这个过程？

Answer 1

Google IO app 中使用的解决方案可能会解决您的问题。他们解析远程服务器上可用的 JSON 并直接显示该内容。为了避免出现空白屏幕，他们使用引导 json 文件，其中包含服务器上可用数据的图像。所有这些信息都可以在here 获得。更具体地说：

引导数据 当用户第一次运行应用程序时，他们希望看到数据。但是，如果我们仅依靠同步机制将数据带入应用程序，那么第一次使用的用户会在等待同步发生时盯着空白屏幕，这将是一个糟糕的用户体验。

这就是 IOSched 附带预加载的“引导数据”的原因，它本质上是 JSON 数据的预加载离线快照。此数据由应用程序解析并在首次执行时保存到数据库中。

您可以在 res/raw/bootstrap.json 中找到此文件。它只是一个文本文件，其中包含服务器上 JSON 文件的组合快照。