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 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() 问题