Android存储之SharedPreferences源码解析

个人博客:haichenyi.com。感谢关注

1. 目录

  • 1–目录
  • 2–简介
  • 3–getSharedPreferences会不会阻塞线程,为什么?
  • 4–get操作,为什么有时候会卡顿?
  • 5–commit和apply的区别
  • 6–sp写入异常会怎么处理?
  • 7–优化sp操作

2.简介

  从工作开始,Android存储数据最常见的应该就是SharePreference,但是,你真的用懂了吗?源码你看过吗?Google对sp的定位你知道吗?是不是所有数据都应该用sp来存储呢?

  为什么现在面试关于sp非常常见呢?不就是一个get,put键值对的东西吗?commit或者apply就提交存储了,这么简单的一个东西,有啥好问的?

  腾讯的mmkv,Google的dataSorce又是什么东西呢?

  先说说sp,Google对sp的定位是轻量级存储,轻量级是什么意思呢?数据量小,数据量大肯定不建议用,但是,往往很多程序员,不管三七二十一,全都是用sp做本地持久化,导致,或多或少的性能问题,当然,不可否认sp的设计也有它的弊端。

  sp 加锁多 xml解析 全量更新 速度慢 性能差 提交数据可能会ANR

3.getSharedPreferences会不会阻塞线程,为什么?

下面从用法一步一步来讲解sp的问题

SharedPreferences sp = getSharedPreferences("haichenyi", MODE_PRIVATE);

  上面这个是获取sp,第一个问题就来了,我们都知道获取sp这里是从磁盘读取数据,就是从文件中读取数据,我们一般从文件中读取数据都是要新开线程的,这里没有新开线程,会不会阻塞主线程,为什么?带着这个问题,我们往下走。

Android存储之SharedPreferences源码解析_第1张图片
  这里调用的是base的getSharedPreferences方法,我们看这个base的类型,会发现是Context类型的,Context我们都知道,是装饰者模式,它的实现类ContextImpl,我们到这个类里面区找上面的这个方法,如下图

Android存储之SharedPreferences源码解析_第2张图片
  这个里面逻辑并不复杂,就是一个name在 api19以下的空判断,然后就是file的空判断,用的ArrayMap存储,最后就是调用的重载方法,如下图

Android存储之SharedPreferences源码解析_第3张图片
  重点就是框起来的这里了,SharedPreferences的实现类SharedPreferencesImpl,这里也是装饰者模式(到处都是)。

Android存储之SharedPreferences源码解析_第4张图片
  看到这里就知道了,它的startLoadFromDisk方法,看名字就知道是从磁盘读取数据,这里有个synchronized锁,锁对象是mLock,这个mLock比较重要。里面有一个mLoaded的Boolean类型的值,它也比较重要。下面具体读数据的逻辑,loadFromDisk是新开线程读取的。

  所以,我们回到前面的问题会不会阻塞线程?虽然,它是同步返回的sp对象,但是,具体读数据的逻辑是新开线程的,所以,不会阻塞线程。

4.get操作,为什么有时候会卡顿?

  会卡顿吗?怎么没有碰到过呢?答案是肯定的,肯定会有卡顿的情况,这是为什么呢?我们来看看它的实现:

Android存储之SharedPreferences源码解析_第5张图片
  我们来看看这个getXXX这一系列的方法,里面都有同步锁,然后,都有一个awaitLoadedLocked方法,重点就是这个方法,看名字就知道:等待加载锁。什么意思呢?我们看一下具体实现

private void awaitLoadedLocked() {
    ...
    //while循环,当mLoaded为false的时候进入while
    while (!mLoaded) {
        try {
            //wait方法
            mLock.wait();
        } catch (InterruptedException unused) {
        }
    }
    ...
}

  这里有一个while循环,判断的就是上面我们提到过的mLoaded,然后,里面就是我们上面也提到过的mLock对象,mLock.wait()方法。

  当代码执行到这里的时候,如果mLoaded是false,就会进入while循环,然后,会调用mLoack的wait方法,进入等待状态。

  那,这个mLoaded的值又是在哪里修改的呢?mLock对象是时候唤醒呢?

  我们回到上面说的,新开线程执行loadFromDisk方法

private void loadFromDisk() {
    ...
    //开始从文件读取数据
    Map 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 = (Map) 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的值
        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
                    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
            mLock.notifyAll();
        }
    }
}

  源码里面注释都写的比较清楚。mLoaded值的修改是在从磁盘中把数据读取完之后,然后,在finally里面调用notifyAll唤醒mLock。

  数据读完之后,修改boolean值,然后,在finally里面唤醒,finally是try-catch最后执行的。

  为什么会卡顿呢?我们平时用sp,是不是像下面这样用的:

//这里是直接返回对象,
//但是,它实际上数据量大的时候,是需要时间去从磁盘读数据的
SharedPreferences sp = getSharedPreferences("haichenyi", MODE_PRIVATE);
//当代码执行到这里的时候,我们虽然,拿到了sp对象,
//但是,数据可能没有读取完,上面说的boolean的值,还是false,
//就进入while循环,调用awit方法,进入等待状态
//然后,过一会从磁盘读取完数据,修改boolean值为true,在finally调用notifyAll唤醒mLock
//然后,唤醒了while循环,boolean的值这个时候是true,跳出while循环
//所以,这个卡顿的时间,就是从磁盘读取数据的时间
String s = sp.getString("xxx","aaa");

  上面代码的注释写的很清楚了吧?不用在做过多的解释了吧?

PS:它这个卡顿仅限于第一次,为什么呢?因为它从磁盘读出数据之后,把数据存到内存中了(也就是loadFromDisk方法中的mMap对象),我在那里加了注释,可以去看一下。读取数据都是从这个mMap对象返回的,也就是从内存中返回,这也是为什么从另一方面说,sp返回数据比较快的原因。它都是从内存中返回的,并不是每次都是从磁盘读数据,然后返回的。

5.commit和apply的区别

  先说结论:

类型 返回值 同步 ANR
commit 同步提交 可能会
apply 异步提交 可能会

  我们一个一个来慢慢说这个结论:

是否有返回值

  这个很简单吧?用过如果没注意,可能不知道,因为,我们平时也不用处理这些东西,我们来看一下源码就知道了。

//看到这个方法有返回值就知道了,boolean类型的返回值
public boolean commit() {
        ...
        //为什么说每次都是全量更新,就在这里,这个commitToMemory方法里面,
        //它每次都会把内存的map数据全部都更新好
        MemoryCommitResult mcr = commitToMemory();
        //然后通过这个enqueueDisk方法全部都重新写到硬盘上
        //第二个参数是null,它的注释也比较清楚
        SharedPreferencesImpl.this.enqueueDiskWrite(
            mcr, null /* sync write on this thread okay */);
        try {
            //然后,写入等待
            mcr.writtenToDiskLatch.await();
        } catch (InterruptedException e) {
            return false;
        } finally {
            ...
        }
        notifyListeners(mcr);
        //返回写入结果
        return mcr.writeToDiskResult;
    }

//这个方法没有返回值
public void apply() {
        ...
    }

  我们先说返回值的问题,上面这两个方法就是commit和apply的大致结构。所以,commit是有个boolean类型的返回值,apply是没有返回值的

是否有同步

  这个问题,上面commit的源码注释那里已经解释清楚了,它会有一个wait方法等待数据更新完,所以commit是同步的。

  我们再来看看apply方法,上面主要是说返回值的问题,所以,没有把apply的源码贴出来,下面我们来看看apply的源码

public void apply() {
    final long startTime = System.currentTimeMillis();
    final MemoryCommitResult mcr = commitToMemory();
    //重点就是这里,它这里是新建了一个runnable来执行await方法,
    //上面commit方法是直接在当前线程执行的
    final Runnable awaitCommit = new Runnable() {
        @Override
        public void run() {
            try {
                mcr.writtenToDiskLatch.await();
            } catch (InterruptedException ignored) {
            }
            ...
        }
    };
    //然后调用了QueuedWork.addFinisher,把这个runnable传了进去
    //这个QueuedWork是什么呢?下面我贴出来了这个方法,addFinisher
    QueuedWork.addFinisher(awaitCommit);
    //上面其实就是把runnable加到了一个队列当中
    
    //又新开了一个runnable执行了上面runnable的run方法,
    //这是什么意思还要我做过多的解释吗?runnable.run()
    Runnable postWriteRunnable = new Runnable() {
        @Override
        public void run() {
            awaitCommit.run();
            QueuedWork.removeFinisher(awaitCommit);
        }
    };
    //回过头看看,commit的这个方法,第二个参数是null,上面我特意做了解释的。
    //看这里,第二个参数,传的runnable
    //就是在runnable的线程里面执行
    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);
}


@UnsupportedAppUsage
public static void addFinisher(Runnable finisher) {
    synchronized (sLock) {
        //等于,就是把我们的runnable给add到了sFinishers,这个sFinishers又是什么呢?
        sFinishers.add(finisher);
    }
}
//没错,它其实就是一个队列,再回到上面
private static final LinkedList sFinishers = new LinkedList<>();

  我这里的源码解释的是比较清楚的了吧?所以,apply是异步的。

是否会ANR

  说到ANR,我们先来聊一下ANR,什么是ANR?多长时间会造成ANR提示?

  ANR:Android系统是消息驱动的,每个消息都需要在一定的时间范围内处理完,如果在规定的时间内未处理完,系统就会提示ANR异常

  那么,这个时间是怎么限定的呢?

类型 Service Broadcast Activity ContentProvider
前台(单位:s) 20 10 5 10
后台(单位:s) 20*10 60 - -

  前两个都好理解,这个ANR就很难理解了,commit是同步提交,可能会ANR我可以理解,sp每次都是全量更新,commit又是在主线程提交,cpu峰值的时候,数据量大,可能就会卡住主线程,造成ANR。

  辣么,问题就来了,commit同步卡能会卡住主线程,造成ANR,apply是异步的呀?为什么apply也会造成ANR呢?是结论错了吗?

  龙儿筝给我说了一个结论:Google认为SP是数据持久化,数据的安全性要大于页面的行为,当页面离开时,会等待持久化完成。

  这个结论怎么理解呢?有一个场景,当你调用apply去更新数据,然后,紧接着下一行代码就执行了finish方法,或者跳转了下一个界面,此时会怎么样呢?

  我们先来简单聊一聊activity启动相关的问题

  简单的从AMS开始说两句吧,当zygote进程启动了系统主要的服务之后,里面就有一个AMS(ActivityManagerService),AMS通过Binder创建了ActivityThread,然后通过handler开始发消息,创建Activity,我们activity的生命周期的回调,都说是系统调用了,系统是怎么调用的呢?都是通过handler发送一个一个的消息,然后去执行对应的回调方法。

  然后,再是,我们常说的onCreate—onStart(可见,不能与用户交互)—onResume(可见,与用户交互)—activity running—onPause—onStop—onDestroy

  除了activity running,其余的每一种生命周期都对应着一个handler的message。handler的机制,在我的博文深入理解handler机制里面讲的很清楚了

  辣么,从Activity A跳转Activity B,两个activity的生命周期是怎么变化的呢?

  当A中启动B,生命周期的流程是这样的:

  1. A的onPause
  2. B的onCreate-onStart-onResume
  3. A的onStop

  扯了这么远,回到上面说的apply的问题,为什么它会ANR线程呢?

  问题就出在这个A的onStop方法里面,我们来看看这个onStop放的源码:

Android存储之SharedPreferences源码解析_第6张图片
  如上图,我们通过handler发送消息,最终定位到执行的是这一块的代码,看到我框起来的代码了吗?

// Make sure any pending writes are now committed.
//看这个注释写的,确认没有正在写入的操作,就是这个waitToFinish方法,
//这个if判断,可以看实现,只要taget小于11判断就是true,我们现在都是大于11了,所以,这里是false
//然后,前面取了一个非,所以,我们现在这里能进去
//如果要是小于11呢?看activity的onPause方法里面,你会有新发现
if (!r.isPreHoneycomb()) {
    QueuedWork.waitToFinish();
}

  上面的注释很清楚了,这个waitToFinish方法里面的逻辑是什么样的呢?大致贴一下主要的逻辑:

public static void waitToFinish() {
    ...
    try {
        //while循环
        while (true) {
            Runnable finisher;
            synchronized (sLock) {
              //从sFinishers队列中取出runnable
                finisher = sFinishers.poll();
            }
            if (finisher == null) {
                //空(队列中没有数据了)就中止while循环
                break;
            }
            //执行runnable
            finisher.run();
        }
    } finally {
        sCanDelay = true;
    }
    ...
}

  我们想想之前apply方法里面,是不是新建的runnable,然后,把这个runnable是不是添加到sFinishers队列中去了?

  所以,整个逻辑就是

  1. 你在Activity A中apply之后(假设数据量大),立马跳转Activity B
  2. 当Activity B正常启动完,走完它自己的onResume方法,执行了Activity A的onStop方法
  3. 执行的时候发现,QueueWork里面还有提交正在执行,就会等待它执行完,就会阻塞当前线程

6.sp写入异常会怎么处理?

  在代码执行getSharedPreferences的时候,你会发现,磁盘上会多一个同名文件,扩展名不一样,扩展名是 点bak,这个文件是备份文件。写入成功就会删除这个文件,写入失败,下次就会用这个备份文件。

  我们再来找一下源码你会发现:

static File makeBackupFile(File prefsFile) {
    return new File(prefsFile.getPath() + ".bak");
}

  这个方法在哪调用的呢?在SharedPreferencesImpl的构造方法里面

SharedPreferencesImpl(File file, int mode) {
    mFile = file;
    //就是这个变量
    mBackupFile = makeBackupFile(file);
    ...
}

  我们再来看看这个写入方法,你会发现,在写入完成之后,会把这个文件删除

private void writeToFile(MemoryCommitResult mcr, boolean isFromSyncCommit) {
    ...
    // Attempt to write the file, delete the backup and return true as atomically as
    // possible.  If any exception occurs, delete the new file; next time we will restore
    // from the backup.
    try {
        FileOutputStream str = createFileOutputStream(mFile);
        if (DEBUG) {
            outputStreamCreateTime = System.currentTimeMillis();
        }
        if (str == null) {
            mcr.setDiskWriteResult(false, false);
            return;
        }
        XmlUtils.writeMapXml(mcr.mapToWriteToDisk, str);
        writeTime = System.currentTimeMillis();
        FileUtils.sync(str);
        fsyncTime = System.currentTimeMillis();
        str.close();
        ContextImpl.setFilePermissionsFromMode(mFile.getPath(), mMode, 0);
        if (DEBUG) {
            setPermTime = System.currentTimeMillis();
        }
        try {
            final StructStat stat = Os.stat(mFile.getPath());
            synchronized (mLock) {
                mStatTimestamp = stat.st_mtim;
                mStatSize = stat.st_size;
            }
        } catch (ErrnoException e) {
            // Do nothing
        }
        if (DEBUG) {
            fstatTime = System.currentTimeMillis();
        }
        // Writing was successful, delete the backup file if there is one.
        //就是这里,写入操作在前面,如果前面没有异常,那就正常写完了,自然就会走到这里
        //如果前面异常,自然就不会走到这里
        mBackupFile.delete();
    ...
}

7.优化sp操作

  1. sp获取的时候,会新开线程去读取数据,我们可以提前读取sp,不要每次到用的时候,再去读取。
  2. sp每次提交都是全量更新,不要每次修改了就直接提交,可以多修改几次之后,一起提交
  3. sp是轻量级存储,数据量大,不要存sp
  4. sp的内容不要太多,sp内容过多,读取的时候会非常慢,可以适当的拆分sp的内容,分多个sp存储,但是也不要太多

  但是,这些优化操作,都是基于sp原有的性能做的优化操作,不能从根本上解决问题。

  sp的源码就说完了,为什么Google更新了十多版本之后的sp,最终还是放弃维护了?而是新出推出了Jetpack的组件之一DataStore这是人性的扭曲还是道德的沦丧,我们且听下回分解。

  下一篇来聊聊MMKV,它是怎么从根本上解决问题的。

你可能感兴趣的:(源码解析,Android,android,SP,源码解析)