是否应该通过UI线程访问SharedPreferences？

Question

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

我注意到警告之一是针对getSharedPreferences()。

这是警告：

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

并给出getSharedPreferences()了在UI线程上进行的调用。

是否应该SharedPreferences真正从UI线程进行访问和更改？

Answer 1

很高兴您已经在玩它！

注意事项：（ 以懒惰的子弹形式）

如果这是您遇到的最严重的问题，则您的应用程序可能是个不错的选择。:)写操作通常比读操作慢，因此请确保使用的是SharedPreferenced $ Editor.apply（）而不是commit（）。apply（）是GB和异步的新功能（但始终安全，请小心生命周期转换）。您可以使用反射来有条件地调用GB +上的apply（）以及Froyo或更低版本上的commit（）。我将在博客文章中提供有关如何执行此操作的示例代码。
关于载入，不过…

加载后，SharedPreferences为单例并在整个进程范围内缓存。因此您希望尽早加载它，以便在需要它之前将其存储在内存中。（假设它很小，如果使用的是SharedPreferences，它应该是一个简单的XML文件，应该是这样。）您不想在以后的某个用户单击按钮时对其进行故障处理。

但是每当调用context.getSharedPreferences（…）时，都会对后台XML文件进行统计以查看其是否已更改，因此无论如何在UI事件期间都应避免这些统计信息。统计信息通常应该是快速的（并经常被缓存），但是yaffs并发性不高（并且许多Android设备都在yaffs上运行… Droid，Nexus One等），因此，如果避免使用磁盘，您可以避免陷入其他正在进行的或待处理的磁盘操作。

因此，您可能需要在onCreate（）期间加载SharedPreferences并重新使用同一实例，从而避免使用stat。

但是如果在onCreate（）期间仍然不需要使用偏好，则加载时间会不必要地拖延应用程序的启动，因此通常最好使用诸如FutureTask 子类之类的东西来启动.set的新线程。 （）FutureTask子类的值。然后，只需在需要时查找FutureTask 的成员并对其进行.get（）。我计划透明地在Honeycomb的幕后使之免费。我将尝试发布一些示例代码，以显示该领域的最佳实践。