Android SharedPreferences该这样优化

前言

同学,听说SharedPreference你玩的很6,不就是存储键值对嘛,工具类就可以搞定。那下面这些问题,你都回答的上来吗?

目录

1、SharedPreference有哪些隐患或风险?
2、为什么SharedPreference会造成卡顿甚至ANR?
3、如何解决sp造成的界面卡顿、掉帧问题?
4、commit和apply有什么区别?
5、apply就不会让主线程卡顿?
6、SharedPreference如何跨进程通信?

还没有看过源码的同学,强烈推荐先看一遍,不然会有各种不适症状。
Android SharedPreferences源码都不会,怎么通过面试?

SharedPreference有哪些隐患或风险?

卡顿、丢帧、甚至ANR、占用内存过高。

为什么SharedPreference会造成卡顿甚至ANR?

  • 第一次从SharedPreference获取值的时候,可能阻塞主线程,造成卡顿/丢帧。

看如下代码,我第一次从sp取数据竟然花费了11ms。这还是我的数据很少的情况下,很多时候,一个迭代了很多版本的项目存放的数据会远比我的要大,耗时也会更长。

 override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        setContentView(R.layout.activity_main)

        var startTime = System.currentTimeMillis()
        val sp: SharedPreferences = getSharedPreferences("sp", Context.MODE_PRIVATE)
        val value: String? = sp.getString("key", "")
        Log.e(TAG, "func1  :  ${System.currentTimeMillis() - startTime}")
    }

有人会说SharedPreferences 的加载是不是在子线程吗,为什么还会阻塞主线程呢?这个问题,我们要从源码中寻找答案。

public String getString(String key, @Nullable String defValue) {
        synchronized (mLock) {
            //阻塞等待加载、解析xml文件完成
            awaitLoadedLocked();
            //从内存获取
            String v = (String)mMap.get(key);
            return v != null ? v : defValue;
        }
    }

从内存获取数据之前,还调用了 awaitLoadedLocked(),下面来看看这个方法。

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 {
                //关键点,object对象的wait()来阻塞等待
                mLock.wait();
            } catch (InterruptedException unused) {
            }
        }
    }

awaitLoadedLocked()会循环等待,直到mLoaded为true,那什么时候mLoaded为true呢?答案是从磁盘加载、解析xml完成之后,具体是在SharedPreferencesImpl#loadFromDisk()方法内,这里不展开了,可以去上一篇源码分析文章看。

小结,第一次获取数据的时候会阻塞主线程,原因是主线程会等待从文件加载sp完成,这是一个耗时操作,尤其是xml中数据比较大的时候更明显;注意:只有第一次才会,后面不会,因为加载文件成功后会在内存缓存数据,下次就不需要等待了。

怎么解决?尽可能早的去完成sp对象的初始化,通常在Application是最合适的。

多次commit、apply

我见过很多这样的代码,每次写入数据都会创建一个Editor对象,调用一次commit/apply。

 val sp: SharedPreferences = getSharedPreferences("sp", Context.MODE_PRIVATE)
 sp.edit().putString("key0", "11").apply()
 sp.edit().putString("key1", "11").apply()
 sp.edit().putString("key2", "11").apply()

创建Editor对象和put方法并不怎么耗时,但是多次commit()/apply()有多耗时,您心里没数吗?不信就来看看下面这组数据。

存储方式 数据量 耗时(ms)
多次commit 20 116
多次apply 20 5
一次性commit 20 6
一次性apply 20 1

所以,请把你的代码改成这样。另外在不需要返回值的时候,请你使用apply(),官方也是这样推荐的。

        val sp: SharedPreferences = getSharedPreferences("sp", Context.MODE_PRIVATE)
        var editor = sp.edit()
        editor.putString("key0", "11")
            .putString("key1", "11")
            .putString("key2", "11")
            .apply()

我们都知道commit()是在主线程写入文件的,很可能会卡顿甚至ANR。有人会说,用apply()不就可以了吗?

模拟面试
面试官:sp的apply()会造成卡顿吗?
小A:不会卡顿,commit才会卡顿,因为apply是在子线程写入文件的。【得意😤】
面试官:你确定不会卡?
小A:我确定。
面试官:其实也可能会卡的。吧啦吧啦。。。。【得意😤】
小A:大佬,原来还可以这样,佛了。

下面就把面试官解释的这一段补充完整。
先来看一下apply方法,注释有点多,可以帮到喜欢追求细节的朋友

public void apply() {
           //修改内存缓存mMap
            final MemoryCommitResult mcr = commitToMemory();
            //等待写入文件完成的任务
            final Runnable awaitCommit = new Runnable() {
                    @Override
                    public void run() {
                        try {
                            //阻塞等待写入文件完成,否则阻塞在这
                            //利用CountDownLatch来等待任务的完成
//后面执行enqueueDiskWrite写入文件成功后会把writtenToDiskLatch多线程计数器减1, 这样的话下面的阻塞代码就可以通过了.
                            mcr.writtenToDiskLatch.await();
                        } catch (InterruptedException ignored) {
                        }
                    }
                };
            
            //QueuedWork是用来确保SharedPrefenced的写操作在Activity 销毁前执行完的一个全局队列. 
            //QueuedWork里面的队列是通过LinkedList实现的,LinkedList不仅可以做链表,也可以做队列
            //添加到全局的工作队列中
            QueuedWork.addFinisher(awaitCommit);

          //这个任务是等待磁盘写入完成,然后从队列中移除任务
            Runnable postWriteRunnable = new Runnable() {
                    @Override
                    public void run() {
                        //执行阻塞任务
                        awaitCommit.run();
                        //阻塞完成之后,从队列中移除任务
                        QueuedWork.removeFinisher(awaitCommit);
                    }
                };
            //异步执行磁盘文件写入,注意这里和commit不同的是postWriteRunnable不为空
            SharedPreferencesImpl.this.enqueueDiskWrite(mcr, postWriteRunnable);

       
            notifyListeners(mcr);
        }

关键点1:把一个带有await的runnable添加进了QueueWork类的一个队列,注意一下这个sFinishers,等会儿会用到

//把任务添加到全局的工作队列中
QueuedWork.addFinisher(awaitCommit);

public class QueuedWork {
    /** Finishers {@link #addFinisher added} and not yet {@link #removeFinisher removed} */
    private static final LinkedList<Runnable> sFinishers = new LinkedList<>();

    public static void addFinisher(Runnable finisher) {
        synchronized (sLock) {
            sFinishers.add(finisher);
        }
    }
}

关键点2:把写入文件的任务放入一个队列中,在QueuedWork内部会通过HandlerThread串行的执行。

//apply异步写入文件
SharedPreferencesImpl.this.enqueueDiskWrite(mcr, postWriteRunnable);

到这里,看上去还没有问题,在子线程写文件并不会造成UI线程卡顿,但是我们来看一下ActivityThread的handleStopActivity方法。

public void handleStopActivity(IBinder token, boolean show, int configChanges,
            PendingTransactionActions pendingActions, boolean finalStateRequest, String reason) {
      ...省略无关代码
        // Make sure any pending writes are now committed.
        if (!r.isPreHoneycomb()) {
            QueuedWork.waitToFinish();
        }
    }

//如果sdk版本<11返回false
private boolean isPreHoneycomb() {
            return activity != null && activity.getApplicationInfo().targetSdkVersion
                    < android.os.Build.VERSION_CODES.HONEYCOMB;
        }

注意,在onPause会调用handleStopActivity()方法,而且几乎都会执行QueuedWork.waitToFinish();方法。waitToFinish?看上去像是等待完成?

public static void waitToFinish() {
     
            while (true) {
                Runnable finisher;

                synchronized (sLock) {
                    //从队列取任务
                    finisher = sFinishers.poll();
                }

                if (finisher == null) {
                    break;
                }

                finisher.run();
            }
    }

这个方法很简单,循环地从sFinishers这个队列中取任务执行,直到任务为空。这个任务就是之前apply中的awaitCommit,它是用来等待写入文件的线程执行完毕的。现在试想一下,在onPause之后,如果因为你多次使用了apply,那就意味着写入任务会在这里排队,但是写入文件那里只有一个HandlerThread在串行的执行,那是不是就卡顿了?

给出几条建议:

  • 第1:不要多次apply,请合并为1次事物提交,因为I/O真的很耗时;
  • 第2:请你不要在sp存放太大的数据,比如json之类,因为文件太大初始化会很耗时,而且文件内容会一直缓存在内存中,得不到释放;
  • 第3:如果你的apply只是存储了轻量级的数据,比如true、"abc"这样的内容,请大胆的使用,没有什么性能影响;
  • 第4:如果优化了apply还出现卡顿,就用commit吧,但是需要自己进行异步处理,至于用Thread还是线程池或者其它看你自己业务。

如何解决sp造成的界面卡顿、掉帧问题?

其实上面的分析已经给出答案了,这里再总结一下。

  • 1.初始化sp放在application;
  • 2.不要频繁的commit/apply,尽量使用一次事物提交;
  • 3.优先选择用apply而不是commit,因为commit会卡UI;
  • 4.sp是轻量级的存储工具,所以请你不要存放太大的数据,不要存json等;
  • 5.单个sp文件不要太大,如果数据量很大,请把关联性比较大的,高频操作的放在单独的sp文件

commit和apply有什么区别?

  • commit()是同步且有返回值的;apply()方法是异步没有返回值的;
  • commit()在主线程写入文件,会造成UI卡顿;apply()在子线程写入文件,也有可能卡UI;

SharedPreference如何跨进程通信?

有人寄希望于在初始化sp的时候,设置flag为MODE_MULTI_PROCESS来跨进程通信,但是很遗憾,这种方式已经被废弃。

getSharedPreferences("sp", Context.MODE_MULTI_PROCESS)

* @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}.
     */
    @Deprecated
    public static final int MODE_MULTI_PROCESS = 0x0004;

如果要跨进程通信,需要在sp外面包裹一层ContentProvider,当然用mmkv性能上更佳。

感谢以下作者

Android SharedPreference源码阅读
SharedPreferences灵魂拷问之原理
https://www.jianshu.com/p/19f261f436ae
Android SharedPreferences.apply() 问题