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灵魂拷问之原理
//www.greatytc.com/p/19f261f436ae
Android SharedPreferences.apply() 问题

©著作权归作者所有,转载或内容合作请联系作者
  • 人面猴
    序言：七十年代末，一起剥皮案震惊了整个滨河市，随后出现的几起案子，更是在滨河造成了极大的恐慌，老刑警刘岩，带你破解...
    沈念sama阅读 194,911评论 5赞 460
  • 死咒
    序言：滨河连续发生了三起死亡事件，死亡现场离奇诡异，居然都是意外死亡，警方通过查阅死者的电脑和手机，发现死者居然都...
    沈念sama阅读 82,014评论 2赞 371
  • 救了他两次的神仙让他今天三更去死
    文/潘晓璐 我一进店门，熙熙楼的掌柜王于贵愁眉苦脸地迎上来，“玉大人，你说我怎么就摊上这事。” “怎么了？”我有些...
    开封第一讲书人阅读 142,129评论 0赞 320
  • 道士缉凶录：失踪的卖姜人
    文/不坏的土叔 我叫张陵，是天一观的道长。 经常有香客问我，道长，这世上最难降的妖魔是什么？ 我笑而不...
    开封第一讲书人阅读 52,283评论 1赞 264
  • 港岛之恋（遗憾婚礼）
    正文 为了忘掉前任，我火速办了婚礼，结果婚礼上，老公的妹妹穿的比我还像新娘。我一直安慰自己，他们只是感情好，可当我...
    茶点故事阅读 61,159评论 4赞 357
  • 恶毒庶女顶嫁案：这布局不是一般人想出来的
    文/花漫 我一把揭开白布。 她就那样静静地躺着，像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上，一...
    开封第一讲书人阅读 46,161评论 1赞 272
  • 城市分裂传说
    那天，我揣着相机与录音，去河边找鬼。 笑死，一个胖子当着我的面吹牛，可吹牛的内容都是我干的。 我是一名探鬼主播，决...
    沈念sama阅读 36,565评论 3赞 382
  • 双鸳鸯连环套：你想象不到人心有多黑
    文/苍兰香墨 我猛地睁开眼，长吁一口气：“原来是场噩梦啊……” “哼！你这毒妇竟也来了？” 一声冷哼从身侧响起，我...
    开封第一讲书人阅读 35,251评论 0赞 253
  • 万荣杀人案实录
    序言：老挝万荣一对情侣失踪，失踪者是张志新（化名）和其女友刘颖，没想到半个月后，有当地人在树林里发现了一具尸体，经...
    沈念sama阅读 39,531评论 1赞 292
  • 护林员之死
    正文 独居荒郊野岭守林人离奇死亡，尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 34,619评论 2赞 310
  • 白月光启示录
    正文 我和宋清朗相恋三年，在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 36,383评论 1赞 326
  • 活死人
    序言：一个原本活蹦乱跳的男人离奇死亡，死状恐怖，灵堂内的尸体忽然破棺而出，到底是诈尸还是另有隐情，我是刑警宁泽，带...
    沈念sama阅读 32,255评论 3赞 313
  • 日本核电站爆炸内幕
    正文 年R本政府宣布，位于F岛的核电站，受9级特大地震影响，放射性物质发生泄漏。R本人自食恶果不足惜，却给世界环境...
    茶点故事阅读 37,624评论 3赞 299
  • 男人毒药：我在死后第九天来索命
    文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹，春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 28,916评论 0赞 17
  • 一桩弑父案，背后竟有这般阴谋
    文/苍兰香墨 我抬头看了看天上的太阳。三九已至，却和暖如春，着一层夹袄步出监牢的瞬间，已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 30,199评论 1赞 250
  • 情欲美人皮
    我被黑心中介骗来泰国打工， 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留，地道东北人。 一个月前我还...
    沈念sama阅读 41,553评论 2赞 342
  • 代替公主和亲
    正文 我出身青楼，却偏偏与公主长得像，于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子，可洞房花烛夜当晚...
    茶点故事阅读 40,756评论 2赞 335