【Android】SharedPreferences阻塞问题深度分析

server/2024/11/15 1:15:40/

前言

Android中SharedPreferences已经广为诟病,它虽然是Android SDK中自带的数据存储API,但是因为存在设计上的缺陷,在处理大量数据时很容易导致UI线程阻塞或者ANR,Android官方最终在Jetpack库中提供了DataStore解决方案,用来替代SharedPreferences。

总结起来,SharedPreferences有以下几个缺点:

  • 在初始化SharedPreferences对象时,会将文件中所有数据都读取到内存,非常浪费内存,并且是同步操作,如果在主线程中操作就会导致页面启动慢或者卡顿问题。
  • 在调用SharedPreferences对象的edit()方法时会一直阻塞直到数据从磁盘上读取完毕。
  • 每次调用apply和commit都会将内存的数据一并同步到磁盘,影响性能。
  • 在调用Activity和Service的生命周期时,会阻塞等待SP数据写出完毕,因此导致页面出现卡顿甚至ANR。

下面来从源码的设计角度来深入分析一下这些问题存在的根源。

笔者原创,转载请注明出处:https://blog.csdn.net/devnn/article/details/138086118

本文基于Android 30源码。

SharedPreferences的初始化

一般我们会使用context的getSharedPreferences(String name, int mode)方法获取一个SharedPreferences对象,而context一般直接使用当前Activity对象。Activity虽然继承了Context但其实它是一个代理Context,真实的Context是通过attachBaseContext方法传入的,实际上就是ContextImpl。对这个不熟悉的同学可以去看看ActivityThread中Activity创建过程。

我们看看ContextImpl中getSharedPreferences方法是如何实现的。

//android.app.ContextImpl@Overridepublic SharedPreferences getSharedPreferences(File file, int mode) {SharedPreferencesImpl sp;synchronized (ContextImpl.class) {final ArrayMap<File, SharedPreferencesImpl> cache = getSharedPreferencesCacheLocked();sp = cache.get(file);if (sp == null) {checkMode(mode);if (getApplicationInfo().targetSdkVersion >= android.os.Build.VERSION_CODES.O) {if (isCredentialProtectedStorage()&& !getSystemService(UserManager.class).isUserUnlockingOrUnlocked(UserHandle.myUserId())) {throw new IllegalStateException("SharedPreferences in credential encrypted "+ "storage are not available until after user is unlocked");}}sp = new SharedPreferencesImpl(file, mode);cache.put(file, 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;}

这里从缓存中取出SharedPreferencesImpl对象,缓存没有会新建一个SharedPreferencesImpl:

//android.app.SharedPreferencesImplSharedPreferencesImpl(File file, int mode) {mFile = file;mBackupFile = makeBackupFile(file);mMode = mode;mLoaded = false;mMap = null;mThrowable = null;startLoadFromDisk();}private void startLoadFromDisk() {synchronized (mLock) {mLoaded = false;}new Thread("SharedPreferencesImpl-load") {public void run() {loadFromDisk();}}.start();}

构建SharedPreferencesImpl会在子线程中读取xml文件,同时将标记位mLoaded置为了false。

//android.app.SharedPreferencesImplprivate void loadFromDisk() {synchronized (mLock) {if (mLoaded) {return;}if (mBackupFile.exists()) {mFile.delete();mBackupFile.renameTo(mFile);}}// Debuggingif (mFile.exists() && !mFile.canRead()) {Log.w(TAG, "Attempt to read preferences file " + mFile + " without permission");}Map<String, Object> map = null;StructStat stat = null;Throwable thrown = null;try {stat = Os.stat(mFile.getPath());if (mFile.canRead()) {BufferedInputStream str = null;try {str = new BufferedInputStream(new FileInputStream(mFile), 16 * 1024);map = (Map<String, Object>) XmlUtils.readMapXml(str);} catch (Exception e) {Log.w(TAG, "Cannot read " + mFile.getAbsolutePath(), e);} finally {IoUtils.closeQuietly(str);}}} catch (ErrnoException e) {// An errno exception means the stat failed. Treat as empty/non-existing by// ignoring.} catch (Throwable t) {thrown = t;}synchronized (mLock) {mLoaded = true;mThrowable = thrown;// It's important that we always signal waiters, even if we'll make// them fail with an exception. The try-finally is pretty wide, but// better safe than sorry.try {if (thrown == null) {if (map != null) {mMap = map;mStatTimestamp = stat.st_mtim;mStatSize = stat.st_size;} else {mMap = new HashMap<>();}}// In case of a thrown exception, we retain the old map. That allows// any open editors to commit and store updates.} catch (Throwable t) {mThrowable = t;} finally {mLock.notifyAll();}}}

读取xml文件完成之后获取mLock对象锁,然后将mLoaded置为true,最后将WaitSet队列中的阻塞线程唤醒。

笔者原创,转载请注明出处:https://blog.csdn.net/devnn/article/details/138086118

SharedPreferences的edit方法

//android.app.SharedPreferencesImpl@Overridepublic Editor edit() {// TODO: remove the need to call awaitLoadedLocked() when// requesting an editor.  will require some work on the// Editor, but then we should be able to do:////      context.getSharedPreferences(..).edit().putString(..).apply()//// ... all without blocking.synchronized (mLock) {awaitLoadedLocked();}return new EditorImpl();}

获取mLock的锁,这里如果子线程读取xml时未释放锁,这时就会阻塞等待,如果比子线程先获取锁,也会阻塞直到子线程读取完毕。看awaitLoadedLocked方法:

//android.app.SharedPreferencesImpl@GuardedBy("mLock")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 {mLock.wait();} catch (InterruptedException unused) {}}if (mThrowable != null) {throw new IllegalStateException(mThrowable);}}

可以看到一个while循环,当mLoaded字段为false时就会阻塞当前线程,直到被唤醒。

从以上获取SharedPreferences对象然后调用edit方法的过程,一般我们都会在onCreate中或者控件onClick中获取sp数据,因此可以得出结论:
在主线程中获取SharedPreferences.Editor,必须等待xml文件所有数据读取完毕才会进行后续操作,如果xml中数据越多,那么主线程等待的时间就会越长。

Editor.apply方法
//android.app.SharedPreferencesImplpublic void apply() {final long startTime = System.currentTimeMillis();final MemoryCommitResult mcr = commitToMemory();final Runnable awaitCommit = new Runnable() {@Overridepublic void run() {try {mcr.writtenToDiskLatch.await();} catch (InterruptedException ignored) {}if (DEBUG && mcr.wasWritten) {Log.d(TAG, mFile.getName() + ":" + mcr.memoryStateGeneration+ " applied after " + (System.currentTimeMillis() - startTime)+ " ms");}}};QueuedWork.addFinisher(awaitCommit);Runnable postWriteRunnable = new Runnable() {@Overridepublic void run() {awaitCommit.run();QueuedWork.removeFinisher(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);}

先调用commitToMemory方法将需要修改的数据封装到了MemoryCommitResult类型的对象mcr中:

//android.app.SharedPreferencesImpl// Returns true if any changes were madeprivate MemoryCommitResult commitToMemory() {long memoryStateGeneration;boolean keysCleared = false;List<String> keysModified = null;Set<OnSharedPreferenceChangeListener> listeners = null;Map<String, Object> mapToWriteToDisk;synchronized (SharedPreferencesImpl.this.mLock) {// We optimistically don't make a deep copy until// a memory commit comes in when we're already// writing to disk.if (mDiskWritesInFlight > 0) {// We can't modify our mMap as a currently// in-flight write owns it.  Clone it before// modifying it.// noinspection uncheckedmMap = new HashMap<String, Object>(mMap);}mapToWriteToDisk = mMap;mDiskWritesInFlight++;boolean hasListeners = mListeners.size() > 0;if (hasListeners) {keysModified = new ArrayList<String>();listeners = new HashSet<OnSharedPreferenceChangeListener>(mListeners.keySet());}synchronized (mEditorLock) {boolean changesMade = false;if (mClear) {if (!mapToWriteToDisk.isEmpty()) {changesMade = true;mapToWriteToDisk.clear();}keysCleared = true;mClear = false;}for (Map.Entry<String, Object> e : mModified.entrySet()) {String k = e.getKey();Object v = e.getValue();// "this" is the magic value for a removal mutation. In addition,// setting a value to "null" for a given key is specified to be// equivalent to calling remove on that key.if (v == this || v == null) {if (!mapToWriteToDisk.containsKey(k)) {continue;}mapToWriteToDisk.remove(k);} else {if (mapToWriteToDisk.containsKey(k)) {Object existingValue = mapToWriteToDisk.get(k);if (existingValue != null && existingValue.equals(v)) {continue;}}mapToWriteToDisk.put(k, v);}changesMade = true;if (hasListeners) {keysModified.add(k);}}mModified.clear();if (changesMade) {mCurrentMemoryStateGeneration++;}memoryStateGeneration = mCurrentMemoryStateGeneration;}}return new MemoryCommitResult(memoryStateGeneration, keysCleared, keysModified,listeners, mapToWriteToDisk);}

这个方法主要是更新之前从xml中加载到内存的mMap集合,哪些字段被修改了就更新一下。

回到apply方法。

apply方法将要修改的数据包装成mcr,然后将mcr.writtenToDiskLatch.await方法封装成了Runnable,并添加到了QueuedWork当中,这一步很关键,后面再分析。

然后又创建了一个Runnable用来执行前面这个Runnable…

然后调用SharedPreferencesImpl.this.enqueueDiskWrite(mcr, postWriteRunnable)将mcr和postWriteRunnable传给了enqueueDiskWrite方法。

//android.app.SharedPreferencesImpl
private void enqueueDiskWrite(final MemoryCommitResult mcr,final Runnable postWriteRunnable) {final boolean isFromSyncCommit = (postWriteRunnable == null);final Runnable writeToDiskRunnable = new Runnable() {@Overridepublic void run() {synchronized (mWritingToDiskLock) {writeToFile(mcr, isFromSyncCommit);}synchronized (mLock) {mDiskWritesInFlight--;}if (postWriteRunnable != null) {postWriteRunnable.run();}}};// Typical #commit() path with fewer allocations, doing a write on// the current thread.if (isFromSyncCommit) {boolean wasEmpty = false;synchronized (mLock) {wasEmpty = mDiskWritesInFlight == 1;}if (wasEmpty) {writeToDiskRunnable.run();return;}}QueuedWork.queue(writeToDiskRunnable, !isFromSyncCommit);}

这个方法又创建了一个Runnable类型的writeToDiskRunnablewriteToDiskRunnable先执行写出操作再调用传进来的Runnable,然后判断是否是同步执行还是异步操作,同步执行直接在当前线程执行writeToDiskRunnable,异步的话将其丢进QueuedWork中,因为apply是异步,因此我们继承看QueuedWork.queue方法。

//android.app.QueuedWorkpublic static void queue(Runnable work, boolean shouldDelay) {Handler handler = getHandler();synchronized (sLock) {sWork.add(work);if (shouldDelay && sCanDelay) {handler.sendEmptyMessageDelayed(QueuedWorkHandler.MSG_RUN, DELAY);} else {handler.sendEmptyMessage(QueuedWorkHandler.MSG_RUN);}}}

该方法比较简单,主要是将传进来的任务放进了sWork队列中,然后发送消息将工作线程唤醒执行队列中的任务。

//android.app.QueuedWorkprivate static class QueuedWorkHandler extends Handler {static final int MSG_RUN = 1;QueuedWorkHandler(Looper looper) {super(looper);}public void handleMessage(Message msg) {if (msg.what == MSG_RUN) {processPendingWork();}}}

继续看processPendingWork做了什么。

//android.app.QueuedWork
private static void processPendingWork() {long startTime = 0;if (DEBUG) {startTime = System.currentTimeMillis();}synchronized (sProcessingWork) {LinkedList<Runnable> work;synchronized (sLock) {work = (LinkedList<Runnable>) sWork.clone();sWork.clear();// Remove all msg-s as all work will be processed nowgetHandler().removeMessages(QueuedWorkHandler.MSG_RUN);}if (work.size() > 0) {for (Runnable w : work) {w.run();}if (DEBUG) {Log.d(LOG_TAG, "processing " + work.size() + " items took " ++(System.currentTimeMillis() - startTime) + " ms");}}}}

很简单,就是将sWork克隆一份,将原来的sWork清空,for循环执行克隆队列中的任务。

到这里apply流程已经分析完毕,主要就是先更新mMap中的数据,然后放到工作线程中执行IO写出操作。

QueuedWork.waitToFinish方法

但是之前调用 QueuedWork.addFinisher(awaitCommit)是做什么的呢?看代码是要等待写出完毕操作,在哪里等待呢?

//android.app.QueuedWorkpublic static void waitToFinish() {long startTime = System.currentTimeMillis();boolean hadMessages = false;Handler handler = getHandler();synchronized (sLock) {if (handler.hasMessages(QueuedWorkHandler.MSG_RUN)) {// Delayed work will be processed at processPendingWork() belowhandler.removeMessages(QueuedWorkHandler.MSG_RUN);if (DEBUG) {hadMessages = true;Log.d(LOG_TAG, "waiting");}}// We should not delay any work as this might delay the finisherssCanDelay = false;}StrictMode.ThreadPolicy oldPolicy = StrictMode.allowThreadDiskWrites();try {processPendingWork();} finally {StrictMode.setThreadPolicy(oldPolicy);}try {while (true) {Runnable finisher;synchronized (sLock) {finisher = sFinishers.poll();}if (finisher == null) {break;}finisher.run();}} finally {sCanDelay = true;}synchronized (sLock) {long waitTime = System.currentTimeMillis() - startTime;if (waitTime > 0 || hadMessages) {mWaitTimes.add(Long.valueOf(waitTime).intValue());mNumWaits++;if (DEBUG || mNumWaits % 1024 == 0 || waitTime > MAX_WAIT_TIME_MILLIS) {mWaitTimes.log(LOG_TAG, "waited: ");}}}}

QueuedWork.waitToFinish方法即是阻塞当前线程等待apply写出任务完毕。

这个方法先是清空handler的中的消息,然后直接在当前线程执行processPendingWork方法,接着遍历之前addFinisher添加进来的任务进行执行。看这情况,相当于如果之前调用apply方法在工作线程中执行的队列任务中还有未完成的就不让它执行,并且将这些任务拿到当前线程进行执行,同时阻塞当前线程等待工作线程中任务执行完毕!

好家伙,相当于强行接管了工作线程中的后续任务,自己亲自来执行,同时等待当前工作线程正在执行的任务执行完毕。

那么QueuedWork.waitToFinish在哪里调用的呢?经过分析是在ActivityThread中执行组件生命周期函数前后:
在这里插入图片描述
这个地方是先执行Activity的onPause方法,然后如果系统小于Android 11则执行QueuedWork.waitToFinish,否则不执行QueuedWork.waitToFinish。看来现在市面上的机型基本在onStop不执行这个方法。

在这里插入图片描述
这个地方先执行Activity的onStop方法,然后如果系统大于Android 11则执行QueuedWork.waitToFinish,否则不执行QueuedWork.waitToFinish。看来现在市面上的机型基本会在onStop之后执行这个方法。

在这里插入图片描述
这个地方是先执行Service的onStartCommand方法,然后执行QueuedWork.waitToFinish

在这里插入图片描述
这个地方是先执行Service的onDetroy方法,然后执行QueuedWork.waitToFinish

经过对SP的apply方法分析可以看出,它是一个异步操作,并且会将sp文件中所有数据一并写出,如果只有一个字段更新,它也会将这些数据写出到磁盘。另外,如果页面即将要关闭,还会阻塞主线程直到sp数据写出完毕。很显然,当sp中数据量很大或者apply操作频繁调用,很容易引发主线程长时间阻塞甚至ANR。

笔者原创,转载请注明出处:https://blog.csdn.net/devnn/article/details/138086118


http://www.ppmy.cn/server/25739.html

相关文章

6.模板初阶

目录 1.泛型编程 2. 函数模板 2.1 函数模板概念 2.2函数模板格式 2.3 模板的实现 2.4函数模板的原理 2.5 函数模板的实例化 3.类模板 1.泛型编程 我们如何实现一个 交换函数呢&#xff1f; 使用函数重载虽然可以实现&#xff0c;但是有一下几个不好的地方&#xff1a; …

连锁企业如何通过OceanBase解决数据库瓶颈

本文来自OceanBase客户&#xff0c;重庆三十七度健康管理有限公司的技术负责人Rinvay的分享 背景 足疗养生对于大家来说应该并不陌生&#xff0c;自古以来便有多部古籍记载。尽管现代生活中&#xff0c;人们可能不再严格遵循节气进行泡脚&#xff0c;但在忙碌的工作间隙&#…

【设计模式】13、template 模板模式

文章目录 十三、template 模板模式13.1 ppl13.1.1 目录层级13.1.2 ppl_test.go13.1.3 ppl.go13.1.4 llm_ppl.go13.1.5 ocr_ppl.go 十三、template 模板模式 https://refactoringguru.cn/design-patterns/template-method 如果是一套标准流程, 但有多种实现, 可以用 template …

编译Qt6.5.3LTS版本(Mac/Windows)的mysql驱动(附带编译后的全部文件)

文章目录 0 背景1 编译过程2 福利参考 0 背景 因为项目要用到对MYSQL数据库操作&#xff0c;所以需要连接到MYSQL数据库。但是连接需要MYSQL驱动&#xff0c;但是Qt本身不自带MYSQL驱动&#xff0c;需要自行编译。网上有很多qt之前版本的mysql驱动&#xff0c;但是没有找到qt6…

【C语言】typedef

为一个数据类型起一个新的别名 typedef int INTEGER; INTEGER a,b; a1; b2;typedef char ARRAY20[20]; ARRAY20 a1,a2,s1,s2;typedef struct stu{char name[20];int age;char sex; }STU; STU body1,body2;typedef int (*PTR_TO_ARR)[4]; PTR_TO_ARR p1,p2;typedef int (*PTR_TO…

C++ 多态

C/C总述&#xff1a;Study C/C-CSDN博客 目录 多态概念 多态分类 多态实现 虚函数&虚函数表 虚函数的重写&#xff08;覆盖&#xff09; 多态的构成条件 虚函数重写的两个特例 协变 析构 关键字final和override&#xff08;C11&#xff09; 抽象类 纯虚函数…

设备能源数据采集新篇章

在当今这个信息化、智能化的时代&#xff0c;设备能源数据的采集已经成为企业高效运营、绿色发展的重要基石。而今天&#xff0c;我们要向大家介绍的就是一款颠覆传统、引领未来的设备能源数据采集神器——HiWoo Box网关&#xff01; 一、HiWoo Box网关&#xff1a;一站式解决…

吐槽3家知名的AI智能体

关注卢松松&#xff0c;会经常给你分享一些我的经验和观点。 我花了2天时间&#xff0c;把松松最近1年的爆款文案关键词情绪口头禅整理出来&#xff0c;4000多字的Prompt&#xff0c;都是一点点打出来的&#xff0c;再投喂到AI大模型里。使用的平台包括&#xff1a;通义千问、…