Android SharedPreferences 应用程序上下文与活动上下文
声明：本页面是StackOverFlow热门问题的中英对照翻译，遵循CC BY-SA 4.0协议，如果您需要使用它，必须同样遵循CC BY-SA许可，注明原文地址和作者信息，同时你必须将它归于原作者（不是我）：StackOverFlow
原文地址: http://stackoverflow.com/questions/11567134/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me):
StackOverFlow
SharedPreferences application context vs activity context
提问by d1rk
I am using several SharedPreferences to store data in my app. Some preferences are used in a lot of activites.
我正在使用多个 SharedPreferences 在我的应用程序中存储数据。许多活动中都使用了一些首选项。
I know that the SharedPreferences are internally backed by a map for fast read-access and written to sdcard when settings are changed.
我知道 SharedPreferences 在内部由地图支持，以便快速读取访问并在更改设置时写入 SD 卡。
I wonder which way is better if a sharedpreference is accessed by a lot of activies:
我想知道如果很多活动都访问共享首选项，哪种方式更好：
- Instantiate it in every activity using the activity context.
- Instantiate it in every activity, but using the application context.
- Put it in e.g. the Application class and instantiate it only once there, similar to a singleton.
- 使用活动上下文在每个活动中实例化它。
- 在每个活动中实例化它，但使用应用程序上下文。
- 把它放在例如 Application 类中并且只在那里实例化一次，类似于单例。
If I use 1. solution is there a sharedpreference object for every activity? And will the sharedpreference's internal map get destroyed when the activity is destroyed?
如果我使用 1. 解决方案是否每个活动都有一个共享偏好对象？当活动被销毁时，共享首选项的内部映射会被销毁吗？
If I use 2. solution will there be only one instance although I call getSharedPreferences in every activity? And will the internal map be in memory as long as the application is alive?
如果我使用 2. 解决方案，尽管我在每个活动中都调用了 getSharedPreferences，但是否只有一个实例？只要应用程序还活着，内部映射就会在内存中吗？
Hopefully someone knows how Android handles it internally.
希望有人知道 Android 如何在内部处理它。
回答by Vit Khudenko
It is worth reviewing the sourcesthat show that a Contextinstance (be it an Activityor an Applicationinstance) share the same static map HashMap<String, SharedPreferencesImpl>.
这是值得检讨的来源是表明一个Context实例（无论是一个Activity或一个Application实例）共享同一个静态地图HashMap<String, SharedPreferencesImpl>。
So whenever you request an instance of SharedPreferencesby the same name via Context.getSharedPreferences(name, mode)you get the same instance since it first checks if the map already contains SharedPreferencesinstance for a key (which is the passed name). Once SharedPreferencesinstance is loaded it will not be loaded again, but taken from the map instead.
因此，每当您SharedPreferences通过相同名称请求实例时，Context.getSharedPreferences(name, mode)您都会获得相同的实例，因为它首先检查映射是否已包含SharedPreferences键的实例（即传递的名称）。一旦SharedPreferences实例加载它不会再次加载，但是从地图上，而不是采取。
So it actually does not matter which way you go, the important thing is to use the same name in order to get the same prefs from different parts of the application. However creating a single "access point" for the prefs could be a plus. So it could be a singleton wrapper over the prefs instantiated in Application.onCreate().
所以实际上走哪条路并不重要，重要的是使用相同的名称以便从应用程序的不同部分获得相同的首选项。但是，为首选项创建单个“访问点”可能是一个加分项。所以它可能是在Application.onCreate().
回答by David Wasser
SharedPreferencesare managed internally by Android as singletons. You can get as many instances as you want using:
SharedPreferences由 Android 在内部作为单例进行管理。您可以使用以下方法获取任意数量的实例：
context.getSharedPreferences(name, mode);
as long as you use the same name, you'll always get the same instance. Therefore there are no concurrency problems.
只要您使用相同的名称，您将始终获得相同的实例。因此不存在并发问题。
回答by AAnkit
I will prefer using a singletonclass for preference, initialize preference once by application context. create getter and setter(get/put) methods to add, update and delete data.
我更喜欢使用单例类作为偏好， 通过应用程序上下文初始化偏好一次。创建 getter 和 setter(get/put) 方法来添加、更新和删除数据。
This way it will create instance once and can be more readable,reusable.
这样，它将创建一次实例，并且可以更具可读性和可重用性。
