Android SharedPreferences最佳做法

Question

在我一直在构建的应用程序中，我们相当依赖于SharedPreferences，这使我思考了访问SharedPreferences时的最佳实践。例如，许多人说通过此调用可以访问它：

PreferenceManager.getDefaultSharedPreferences(Context context)

但是，这似乎很危险。如果您有依赖于SharedPreferences的大型应用程序，则可能会有密钥重复，尤其是在使用某些也依赖SharedPreferences的第三方库的情况下。在我看来，更好的使用方法是：

Context.getSharedPreferences(String name, int mode)

这样，如果您的类严重依赖于SharedPreferences，则可以创建仅由您的类使用的首选项文件。您可以使用该类的全限定名来确保该文件很可能不会被其他人复制。

同样基于此SO问题：是否应在UI线程之外完成对SharedPreferences的访问？，似乎应该从UI线程中完成对SharedPreferences的访问。

Android开发人员在其应用程序中使用SharedPreferences时，还应注意其他最佳实践吗？

Answer 1

如果您有依赖于SharedPreferences的大型应用程序，则可能会有密钥重复，尤其是在使用某些也依赖SharedPreferences的第三方库的情况下。

图书馆不应使用该特定名称SharedPreferences。默认值SharedPreferences仅应由应用程序使用。

这样，如果您的类严重依赖于SharedPreferences，则可以创建仅由您的类使用的首选项文件。

当然欢迎您这样做。在应用程序级别，我不会这样做，因为主要原因SharedPreferences是要在应用程序的各个组件之间共享它们。开发团队在管理该名称空间时应该没有问题，就像他们在管理类，程序包，资源或其他项目级内容的名称时应该没有问题一样。此外，默认设置SharedPreferences是您PreferenceActivity将使用的默认设置。

但是，回到您的库， 可重用的
库应SharedPreferences仅为其库使用一个单独的库。我不会将其基于类名，因为那样的话，您就可以远离破坏您的应用程序了。而是选择一个唯一的名称（例如，基于库名称，例如"com.commonsware.cwac.wakeful.WakefulIntentService"），但要稳定。

似乎应该从UI线程完成对SharedPreferences的访问。

理想情况下，是的。我最近发布了一个SharedPreferencesLoader有助于解决此问题的工具。

Android开发人员在其应用程序中使用SharedPreferences时，还应注意其他最佳实践吗？

不要过度依赖他们。它们存储在XML文件中，而不是事务性的。数据库应该是您的主要数据存储，尤其是对于您确实不想丢失的数据。