Android SharedPreference 源码分析(一)
2017-12-09 17:39
405 查看
1. 前言
众所周知,SharedPreferences是Android平台上一个轻量级的存储类,用来保存应用的一些常用配置,比如Activity状态,Activity暂停时,将此activity的状态保存到SharedPereferences中;当Activity重载,系统回调方法onSaveInstanceState时,再从SharedPreferences中将值取出。2.基本概念
SharedPreferences提供了常规的Long、Int、String等类型数据的保存/获取接口,并以xml方式保存在data/data/you.package.name/shared_prefs/目录下的文件。SharedPreferences数据的操作模式
Context.MODE_PRIVATE:为默认操作模式,代表该文件是私有数据,只能被应用本身访问,在该模式下,写入的内容会覆盖原文件的内容
Context.MODE_APPEND:模式会检查文件是否存在,存在就往文件追加内容,否则就创建新文件.
Context.MODE_WORLD_READABLE和Context.MODE_WORLD_WRITEABLE用来控制其他应用是否有权限读写该文件.
MODE_WORLD_READABLE:表示当前文件可以被其他应用读取.
MODE_WORLD_WRITEABLE:表示当前文件可以被其他应用写入
特别注意:出于安全性的考虑,MODE_WORLD_READABLE 和 MODE_WORLD_WRITEABLE 在Android 4.2版本中已经被弃用。
MODE_MULTI_PROCESS:跨进程模式
3.提出问题
1).SharedPreferences真的支持多进程吗?可能有些人会觉得很奇怪,上面不是写了MODE_MULTI_PROCESS模式,明确说明就是跨进程模式,为什么还问是否真的支持多进程。为了找到答案,我们来阅读MODE_MULTI_PROCESS的注释。
/** * SharedPreference loading flag: when set, the file on disk will * be checked for modification even if the shared preferences * instance is already loaded in this process. This behavior is * sometimes desired in cases where the application has multiple * processes, all writing to the same SharedPreferences file. * Generally there are better forms of communication between * processes, though. * * <p>This was the legacy (but undocumented) behavior in and * before Gingerbread (Android 2.3) and this flag is implied when * targetting such releases. For applications targetting SDK * versions <em>greater than</em> Android 2.3, this flag must be * explicitly set if desired. * * @see #getSharedPreferences * * @deprecated MODE_MULTI_PROCESS does not work reliably in * some versions of Android, and furthermore does not provide any * mechanism for reconciling concurrent modifications across * processes. Applications should not attempt to use it. Instead, * they should use an explicit cross-process data management * approach such as {@link android.content.ContentProvider ContentProvider}. */
很尴尬,英文看不懂?google翻译一下。
/ ** * SharedPreference加载标志:设置时,磁盘上的文件将 *即使共享首选项,也要检查修改 *实例已经在这个过程中加载。这是行为 *有时需要在应用程序有多个的情况下 *进程,全部写入相同的SharedPreferences文件。 *一般来说有更好的交流形式 *进程,虽然。 * *这是在和遗传(但没有记录)的行为 *之前的姜饼(Android 2.3)和这个标志是隐含的时候 *瞄准这样的发布。针对SDK的应用程序 *版本<em>大于</ em> Android 2.3,这个标志必须是 *如果需要显式设置。 * *参见#getSharedPreferences * * @deprecated MODE_MULTI_PROCESS不能可靠的工作 *某些版本的Android,而且不提供任何 *协调跨越并发修改的机制 *进程。应用程序不应该尝试使用它。代替, *他们应该使用明确的跨进程数据管理 *方法,如{@link android.content.ContentProvider ContentProvider}。 * /
很明显MODE_MULTI_PROCESS是不可靠的,google推荐使用ContentProvider实现跨进程数据管理,如何使用,这个在下一篇介绍。
2).上面说到SharedPreference是以xml文件存在本地,那么读取/保存文件是不是损耗性能,需不需要每个app自己做内存缓存,还有保存数据大小是否有限制,频繁读取有没有注意点,带着这些问题我们看看SharedPreference底层是如何实现的。
4.源码分析
1)先上图,让大家直观的了解下SharedPreference相关的类以及相关关系。2)一般使用SharedPreference的时候,都是如下调用:
SharedPreferences sp = context.getSharedPreferences(SP_NAME, Context.MODE_MULTI_PROCESS);
那么,我们就看下getSharedPreferences(String name, int mode)方法,打开Context类可以看到该方法是个抽象方法,具体实现在子类中,打开Context的实现类ContextImpl,可以看到getSharedPreferences(String name, int mode)源码如下所示:
@Override public SharedPreferences getSharedPreferences(String name, int mode) { SharedPreferencesImpl sp; synchronized (ContextImpl.class) { if (sSharedPrefs == null) { sSharedPrefs = new ArrayMap<String, ArrayMap<String, SharedPreferencesImpl>>(); } final String packageName = getPackageName(); ArrayMap<String, SharedPreferencesImpl> packagePrefs = sSharedPrefs.get(packageName); if (packagePrefs == null) { packagePrefs = new ArrayMap<String, SharedPreferencesImpl>(); sSharedPrefs.put(packageName, packagePrefs); } // At least one application in the world actually passes in a null // name. This happened to work because when we generated the file name // we would stringify it to "null.xml". Nice. if (mPackageInfo.getApplicationInfo().targetSdkVersion < Build.VERSION_CODES.KITKAT) { if (name == null) { name = "null"; } } sp = packagePrefs.get(name); if (sp == null) { File prefsFile = getSharedPrefsFile(name); sp = new SharedPreferencesImpl(prefsFile, mode); packagePrefs.put(name, sp); return sp; } } if ((mode & Context.MODE_MULTI_PROCESS) != 0 || getApplicationInfo().targetSdkVersion < android.os.Build.VERSION_CODES.HONEYCOMB) { // If somebody else (some other process) changed the prefs // file behind our back, we reload it. This has been the // historical (if undocumented) behavior. sp.startReloadIfChangedUnexpectedly(); } return sp; }
从5-14行可以看出,先根据应用包名,从本地map中取到该应用的所有sp文件,在根据传进来的name,获取需要读取的sp文件。
从27-32行可以看出,第一次先拿到sp文件,然后初始化出SharedPreferencesImpl实现类,在SharedPreferencesImpl的构造方法中从本地读取了该name的sp文件,后面会分析。
从34-41行看出,如果是MODE_MULTI_PROCESS模式或者版本小于11,会调用sp.startReloadIfChangedUnexpectedly()方法,该方法从磁盘把文件重新读取到内存,源码如下:
void startReloadIfChangedUnexpectedly() { synchronized (this) { // TODO: wait for any pending writes to disk? if (!hasFileChangedUnexpectedly()) { return; } startLoadFromDisk(); } }
刚刚说到SharedPreferencesImpl的构造方法中从本地读取了该name的sp文件,源码如下所示:
SharedPreferencesImpl(File file, int mode) { mFile = file; mBackupFile = makeBackupFile(file); mMode = mode; mLoaded = false; mMap = null; startLoadFromDisk(); }
private void startLoadFromDisk() { synchronized (this) { mLoaded = false; } new Thread("SharedPreferencesImpl-load") { public void run() { synchronized (SharedPreferencesImpl.this) { loadFromDiskLocked(); } } }.start(); }
private void loadFromDiskLocked() { if (mLoaded) { return; } if (mBackupFile.exists()) { mFile.delete(); mBackupFile.renameTo(mFile); } // Debugging if (mFile.exists() && !mFile.canRead()) { Log.w(TAG, "Attempt to read preferences file " + mFile + " without permission"); } Map map = null; StructStat stat = null; try { stat = Os.stat(mFile.getPath()); if (mFile.canRead()) { BufferedInputStream str = null; try { str = new BufferedInputStream( new FileInputStream(mFile), 16*1024); map = XmlUtils.readMapXml(str); } catch (XmlPullParserException e) { Log.w(TAG, "getSharedPreferences", e); } catch (FileNotFoundException e) { Log.w(TAG, "getSharedPreferences", e); } catch (IOException e) { Log.w(TAG, "getSharedPreferences", e); } finally { IoUtils.closeQuietly(str); } } } catch (ErrnoException e) { } mLoaded = true; if (map != null) { mMap = map; mStatTimestamp = stat.st_mtime; mStatSize = stat.st_size; } else { mMap = new HashMap<String, Object>(); } notifyAll(); }
从上面代码可以看出,从sp文件读出数据后,会赋值给mMap对象,该对象通过键值对保存sp文件,实现二级缓存的目的是为了提高读取效率,所以app应用中就不需要单独再自己做缓存。既然数据都保存在内存缓存mMap中,这样也就说明sp文件不适合存储大数据,会十分浪费内存。
下面再看下,如何保存数据,我们一般使用两种方法:apply(),commit()
public void apply() { final MemoryCommitResult mcr = commitToMemory(); final Runnable awaitCommit = new Runnable() { public void run() { try { mcr.writtenToDiskLatch.await(); } catch (InterruptedException ignored) { } } }; QueuedWork.add(awaitCommit); Runnable postWriteRunnable = new Runnable() { public void run() { awaitCommit.run(); QueuedWork.remove(awaitCommit); } }; SharedPreferencesImpl.this.enqueueDiskWrite(mcr, postWriteRunnable); // Okay to notify the listeners before it's hit disk // because the listeners should always get the same // SharedPreferences instance back, which has the // changes reflected in memory. notifyListeners(mcr); }
第二行可以看出,先保存到内存,通过第十二行,可以看出,通过异步线程保存sp文件到磁盘。
public boolean commit() { MemoryCommitResult mcr = commitToMemory(); SharedPreferencesImpl.this.enqueueDiskWrite( mcr, null /* sync write on this thread okay */); try { mcr.writtenToDiskLatch.await(); } catch (InterruptedException e) { return false; } notifyListeners(mcr); return mcr.writeToDiskResult; }
通过commit的源码可以看出,该保存到内存跟磁盘是同步保存,所以,如果频繁保存数据的话,apply肯定要高效,优先推荐使用apply。
看完保存数据,下面我们来看如何读取数据,拿getString来做示例:
@Nullable public String getString(String key, @Nullable String defValue) { synchronized (this) { awaitLoadedLocked(); String v = (String)mMap.get(key); return v != null ? v : defValue; } }
private void awaitLoadedLocked() { if (!mLoaded) { // Raise an explicit StrictMode onReadFromDisk for this // thread, since the real read will be in a different // thread and otherwise ignored by StrictMode. BlockGuard.getThreadPolicy().onReadFromDisk(); } while (!mLoaded) { try { wait(); } catch (InterruptedException unused) { } } }
可以看到数据是从mMap中读取,也就是从内存缓存中取,这样省去io操作,提高性能。
里面还有一个boolean变量mLoaded,该变量默认为false,这样会一直阻塞住读取,在什么地方设置为true的呢,从mLoaded的字面可以猜到是加载,那应该是从本地磁盘读成功赋值为true,我们看下源码:
private void loadFromDiskLocked() { if (mLoaded) { return; } if (mBackupFile.exists()) { mFile.delete(); mBackupFile.renameTo(mFile); } // Debugging if (mFile.exists() && !mFile.canRead()) { Log.w(TAG, "Attempt to read preferences file " + mFile + " without permission"); } Map map = null; StructStat stat = null; try { stat = Os.stat(mFile.getPath()); if (mFile.canRead()) { BufferedInputStream str = null; try { str = new BufferedInputStream( new FileInputStream(mFile), 16*1024); map = XmlUtils.readMapXml(str); } catch (XmlPullParserException e) { Log.w(TAG, "getSharedPreferences", e); } catch (FileNotFoundException e) { Log.w(TAG, "getSharedPreferences", e); } catch (IOException e) { Log.w(TAG, "getSharedPreferences", e); } finally { IoUtils.closeQuietly(str); } } } catch (ErrnoException e) { } mLoaded = true; if (map != null) { mMap = map; mStatTimestamp = stat.st_mtime; mStatSize = stat.st_size; } else { mMap = new HashMap<String, Object>(); } notifyAll(); }
很明显,最后读取成功后,mLoaded 被赋值为true,而loadFromDiskLocked这个方法是在SharedPreferencesImpl的构造方法中就调用,所以为了不造成阻塞,我们可以提前创建出SharedPreferences对象,而不是在使用的时候再去创建。
如有错误欢迎指出来,一起学习。
交流讨论群
群号:469890293
相关文章推荐
- Android 自定义 View 之 onLayout 源码分析
- Android4.2.2 Gallery2源码分析(10)——Activity于View的结合
- Android 4.0 Launcher2源码分析——Workspace切换AllApps流程
- Android 5.1 Contacts源码分析(四):Contacts模块ListView Adapter结构
- Android LayoutInflater源码分析及使用(二)
- Android服务查询完整过程源码分析
- Android的Message Pool是什么——源码角度分析
- Android IPC 通讯机制源码分析【下】
- Android的LinearLayout源码分析
- 深入理解init_1----init分析(基于Android 2.2,源码来自Google)
- android-魔法泡泡动画分析(附源码)
- Android 4.0 Launcher2源码分析——导入eclipse进行调试
- android开源框架学习---EventBus---源码分析
- AndroidPN的学习研究(三)源码流程分析
- Android 消息机制的源码分析
- Android 4.0 拨号盘界面的分析(源码)
- Android-vold源码分析之卸载SD卡
- android smack源码分析——接收消息以及如何解析消息
- Android电话拨打流程源码分析