从 SharedPreferences 读取与保留对象实例

Question

情景

我有一个使用用户设置的请求列表的类。请求列表存储在 SharedPreferences 中。我面临的困境是每次需要请求列表时是保留请求列表的实例还是从 SharedPreferences 读取（这非常频繁）。

也不是说 Gson 是用来反序列化对象的。

代码如下：

public List<PrayerTimesCalculator.Time> getDefaultRequestList() {
    if (mRequestList != null) return mRequestList;
    // Try getting request list from preferences;
    Gson gson = new Gson();
    String json = mSharedPref.getString(KEY_PREF_REQUEST_LIST, null);
    Type listType = new TypeToken<List<Time>>() {
    }.getType();
    mRequestList = gson.fromJson(json, listType);
    if (mRequestList != null) return mRequestList;
    // Create default list;
    mRequestList = Arrays.asList(
           Time.DAWN,
           Time.MORNING,
           Time.AFTERNOON,
           Time.EVENING,
           Time.MID_NIGHT);
    return mRequestList;
}

目标

我担心的是，如果我保留请求列表的一个实例，并且该类有多个实例，则该类的一个实例中对请求列表的更新将不会反映在其余实例中，直到它们被重新创建。

因此，我倾向于从 SharedPreferences 中读取数据，除非有更好的方法可以在所有情况下保持更新被反对的请求列表。

问题

(1) 那么，对象的多个实例频繁地从 SharedPreferences 中读取同一个键的效率如何？ (2) 有没有更好的方法让被反对的请求列表在所有情况下都保持更新？

Answer 1

因此，您可以采取几种方法。

首先，您的对象很小 - 重新阅读 SharedPreferences 数千次几乎不会被注意到。这不像SharedPreferences 在远程驱动器上或“连接不良”。

其次，如果您不喜欢这个答案，那么您需要一个 DAO（数据访问对象）。 SharedPreferences 已经是这种形式。它提供了一种存储和检索数据的方法，您可以确信您拥有最新的可用数据。但是，如果您觉得可以改进它的优化（因为它是通用的，这是您的应用程序），那么您可以通过执行“读取”和“写入”操作的静态对象提供对数据的访问。这将保证对对象的访问是使用最新数据完成的。当然，您需要了解线程等（SharedPreferences 并不总是保证这一点）。

接下来，您可以将数据保存在数据库中并使用Cursors 或其他内置或自定义 DAO。这需要另一个级别的复杂性和大量开销，但当您的应用程序的多个组件可能需要访问数据、提供更新或需要实时监控更改时很有用，因为后台线程或其他对象可能会进行会更改的修改您的应用行为或导致 UI 更新。

最后，您可以使用更复杂的数据存储，例如内容提供程序。对于您希望/需要其他应用程序访问您的应用程序提供的数据（并且您的应用程序也可能使用数据）的情况，这确实是必需的。这是一个复杂的解决方案，实施远远超出了这个问题的范围。

但我提到它是因为您似乎有兴趣确定频繁阅读 SharedPreferences 是可以接受的。这绝对是可以接受的——否则除了它之外还有其他东西，数据库和内容提供者。