android - 是否应该在 UI 线程外访问 SharedPreferences？

Question

随着 Gingerbread 的发布，我一直在尝试一些新的 API，其中之一是 StrictMode .

我注意到其中一个警告是针对 getSharedPreferences()。

这是警告:

StrictMode policy violation; ~duration=1949 ms: android.os.StrictMode$StrictModeDiskReadViolation: policy=23 violation=2

它是为在 UI 线程上进行的 getSharedPreferences() 调用而提供的。

SharedPreferences 真的应该在 UI 线程之外进行访问和更改吗？

Answer 1

很高兴你已经在玩它了!

注意事项:(以惰性子弹形式)

• 如果这是您遇到的最严重的问题，那么您的应用可能处于一个好位置。 :) 但是，写入通常比读取慢，因此请确保您使用的是 SharedPreferenced$Editor.apply() 而不是 commit()。 apply() 在 GB 和 async 中是新的(但总是安全的，小心生命周期转换)。您可以使用反射有条件地调用 GB+ 上的 apply() 和 Froyo 或更低版本上的 commit()。我将写一篇博文，其中包含如何执行此操作的示例代码。

关于加载，不过...

• 一旦加载，SharedPreferences 就是单例并且在进程范围内缓存。因此，您希望尽早加载它，以便在需要之前将其保存在内存中。 (假设它很小，如果你使用 SharedPreferences，它应该是一个简单的 XML 文件......)你不想在将来某个用户点击按钮时出错。

• 但是每当您调用 context.getSharedPreferences(...) 时，都会统计支持 XML 文件以查看它是否已更改，因此无论如何您都希望在 UI 事件期间避免这些统计信息。统计数据通常应该很快(并且经常被缓存)，但是 yaffs 没有太多的并发方式(很多 Android 设备在 yaffs 上运行...... Droid、Nexus One 等)所以如果你避免使用磁盘，您可以避免卡在其他进行中或挂起的磁盘操作之后。

• 因此您可能希望在 onCreate() 期间加载 SharedPreferences 并重复使用同一个实例，避免使用统计数据。

• 但是如果你在 onCreate() 期间无论如何都不需要你的偏好，那么加载时间会不必要地拖延你的应用程序的启动，所以通常最好有类似 FutureTask 子类的东西来启动.set() FutureTask 子类的值的新线程。然后只需在需要时查找 FutureTask 的成员并 .get() 即可。我计划在 Honeycomb 的幕后透明地免费提供这个功能。我会尝试发布一些示例代码展示了该领域的最佳实践。

查看 Android 开发者博客，了解 future 几周内有关 StrictMode 相关主题的帖子。