Android SharedPreferences的设计与实现

最新推荐文章于 2024-08-09 22:40:08 发布

赵小龙_同学

最新推荐文章于 2024-08-09 22:40:08 发布

阅读量355

点赞数

分类专栏：日常记录

本文链接：https://blog.csdn.net/forward222/article/details/109176552

版权

日常记录专栏收录该内容

27 篇文章 1 订阅

订阅专栏

反思｜官方也无力回天？Android SharedPreferences的设计与实现 https://juejin.im/post/6884505736836022280

当SharedPreferences对象第一次通过Context.getSharedPreferences()进行初始化时，对xml文件进行一次读取，并将文件内所有内容（即所有的键值对）缓到内存的一个Map中，这样，接下来所有的读操作，只需要从这个Map中取就可以了。虽然节省了I/O的操作，但另一个视角分析，当xml中数据量过大时，这种 内存缓存机制 是否会产生 高内存占用 的风险？

xml中数据是如何更新的？读者可以简单理解为 全量更新 ——通过上文，我们知道xml文件中的数据会缓存到内存的mMap中，每次在调用editor.putXXX()时，实际上会将新的数据存入在mMap，当调用commit()或apply()时，最终会将mMap的所有数据全量更新到xml文件里。

由此可见，xml中数据量的大小，的确会对 写操作 的成本有一定的影响，因此，设计者更建议将 不同业务模块的数据分文件存储 ，即根据业务将数据存放在不同的xml文件中。

1、保证复杂流程代码的可读性

为了保证SharedPreferences是线程安全的，Google的设计者一共使用了3把锁：

final class SharedPreferencesImpl implements SharedPreferences {
  // 1、使用注释标记锁的顺序
  // Lock ordering rules:
  //  - acquire SharedPreferencesImpl.mLock before EditorImpl.mLock
  //  - acquire mWritingToDiskLock before EditorImpl.mLock

  // 2、通过注解标记持有的是哪把锁
  @GuardedBy("mLock")
  private Map<String, Object> mMap;

  @GuardedBy("mWritingToDiskLock")
  private long mDiskStateGeneration;

  public final class EditorImpl implements Editor {
    @GuardedBy("mEditorLock")
    private final Map<String, Object> mModified = new HashMap<>();
  }
}

对于这样复杂的类而言，如何提高代码的可读性？SharedPreferencesImpl做了一个很好的示范：通过注释明确写明加锁的顺序，并为被加锁的成员使用@GuardedBy注解。

对于简单的 读操作 而言，我们知道其原理是读取内存中mMap的值并返回，那么为了保证线程安全，只需要加一把锁保证mMap的线程安全即可：

public String getString(String key, @Nullable String defValue) {
    synchronized (mLock) {
        String v = (String)mMap.get(key);
        return v != null ? v : defValue;
    }
}

2、保证写操作的线程安全

对于写操作而言，每次putXXX()并不能立即更新在mMap中，这是理所当然的，如果开发者没有调用apply()方法，那么这些数据的更新理所当然应该被抛弃掉，但是如果直接更新在mMap中，那么数据就难以恢复。

因此，Editor本身也应该持有一个mEditorMap对象，用于存储数据的更新；只有当调用apply()时，才尝试将mEditorMap与mMap进行合并，以达到数据更新的目的。

因此，这里我们还需要另外一把锁保证mEditorMap的线程安全，笔者认为，不和mMap公用同一把锁的原因是，在apply()被调用之前，getXXX和putXXX理应是没有冲突的。

代码实现参考如下：

public final class EditorImpl implements Editor {
  @Override
  public Editor putString(String key, String value) {
      synchronized (mEditorLock) {
          mEditorMap.put(key, value);
          return this;
      }
  }
}

而当真正需要执行apply()进行写操作时，mEditorMap与mMap进行合并，这时必须通过2把锁保证mEditorMap与mMap的线程安全，保证mMap最终能够更新成功，最终向对应的xml文件中进行更新。

文件的更新理所当然也需要加一把锁：

// SharedPreferencesImpl.EditorImpl.enqueueDiskWrite()
synchronized (mWritingToDiskLock) {
    writeToFile(mcr, isFromSyncCommit);
}

最终，我们一共通过使用了3把锁，对整个写操作的线程安全进行了保证。

3、摆脱不掉的ANR

apply()方法设计的初衷是为了规避主线程的I/O操作导致ANR问题的产生，那么，ANR的问题真得到了有效的解决吗？

并没有，在 字节跳动技术团队 的这篇文章中，明确说明了线上环境中，相当一部分的ANR统计都来自于SharedPreference，由此可见，apply()并没有完全规避掉这个问题，那么导致ANR的原因又是什么呢。

经过我们的优化，SharedPreferences的确是线程安全的，apply()的内部实现也的确将I/O操作交给了子线程，可以说其本身是没有问题的，而其原因归根到底则是Android的另外一个机制。

在apply()方法中，首先会创建一个等待锁，根据源码版本的不同，最终更新文件的任务会交给QueuedWork.singleThreadExecutor()单个线程或者HandlerThread去执行，当文件更新完毕后会释放锁。

但当Activity.onStop()以及Service处理onStop等相关方法时，则会执行 QueuedWork.waitToFinish()等待所有的等待锁释放，因此如果SharedPreferences一直没有完成更新任务，有可能会导致卡在主线程，最终超时导致ANR。

什么情况下SharedPreferences会一直没有完成任务呢？比如太频繁无节制的apply()，导致任务过多，这也侧面说明了SPUtils.putXXX()这种粗暴的设计的弊端。

Google为何这么设计呢？字节跳动技术团队的这篇文章中做出了如下猜测：

无论是 commit 还是 apply 都会产生 ANR，但从 Android 之初到目前 Android8.0，Google 一直没有修复此 bug，我们贸然处理会产生什么问题呢。Google 在 Activity 和 Service 调用 onStop 之前阻塞主线程来处理 SP，我们能猜到的唯一原因是尽可能的保证数据的持久化。因为如果在运行过程中产生了 crash，也会导致 SP 未持久化，持久化本身是 IO 操作，也会失败。

如此看来，导致这种缺陷的原因，其设计也的确是有自身的考量的，好在这篇文章末尾也提出了一个折衷的解决方案，有兴趣的读者可以了解一下，本文不赘述。