2024年Android最新大佬教你极简方法来处理Android SharedPreferences设计与实现，头条面试后几天有结果

最新推荐文章于 2024-09-05 00:04:53 发布

2401_84561579

最新推荐文章于 2024-09-05 00:04:53 发布

阅读量793

点赞数 19

分类专栏：程序员文章标签： android 面试学习

本文链接：https://blog.csdn.net/2401_84561579/article/details/138859455

版权

程序员专栏收录该内容

191 篇文章 0 订阅

订阅专栏

学习宝典

对我们开发者来说，一定要打好基础，随时准备战斗。不论寒冬是否到来，都要把自己的技术做精做深。虽然目前移动端的招聘量确实变少了，但中高端的职位还是很多的，这说明行业只是变得成熟规范起来了。竞争越激烈，产品质量与留存就变得更加重要，我们进入了技术赋能业务的时代。

不论遇到什么困难，都不应该成为我们放弃的理由！

很多人在刚接触这个行业的时候或者是在遇到瓶颈期的时候，总会遇到一些问题，比如学了一段时间感觉没有方向感，不知道该从那里入手去学习，对此我针对Android程序员，我这边给大家整理了一套学习宝典！包括不限于高级UI、性能优化、移动架构师、NDK、混合式开发（ReactNative+Weex）微信小程序、Flutter等全方面的Android进阶实践技术；希望能帮助到大家，也节省大家在网上搜索资料的时间来学习，也可以分享动态给身边好友一起学习！

【Android核心高级技术PDF文档，BAT大厂面试真题解析】

【算法合集】

【延伸Android必备知识点】

【Android部分高级架构视频学习资源】

网上学习资料一大堆，但如果学到的知识不成体系，遇到问题时只是浅尝辄止，不再深入研究，那么很难做到真正的技术提升。

需要这份系统化学习资料的朋友，可以戳这里获取

一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！

因此，当xml文件过大时，应该考虑根据业务，细分为若干个小的文件进行管理；但过多的小文件也会导致过多的SharedPreferences对象，不好管理且易混淆。实际开发中，开发者应根据业务的需要进行对应的平衡。

二、线程安全问题

SharedPreferences是线程安全的吗？

毫无疑问，SharedPreferences是线程安全的，但这只是对成品而言，对于我们目前的实现，显然还有一定的差距，如何保证线程安全呢？

——那，为了保证线程安全，怎么着不得加个锁吧。

加个锁？那是起步！3把锁，你还别嫌多。你得研究开发写代码时的心理，舍得往代码里吭哧吭哧加锁的开发，压根不在乎再加2把。

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把锁，对整个写操作的线程安全进行了保证。

篇幅限制，本文不对源码进行详细引申，有兴趣的读者可参考 SharedPreferencesImpl.EditorImpl 类的apply()源码。

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 操作，也会失败。

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

三、进程安全问题

1、如何保证进程安全

SharedPreferences是否进程安全呢？让我们打开SharedPreferences的源码，看一下最顶部类的注释：

/**

…
This class does not support use across multiple processes.
…

public interface SharedPreferences {

// …

}

复制代码

由此，由于没有使用跨进程的锁，SharedPreferences是进程不安全的，在跨进程频繁读写会有数据丢失的可能，这显然不符合我们的期望。

那么，如何保证SharedPreferences进程的安全呢?

实现思路很多，比如使用文件锁，保证每次只有一个进程在访问这个文件；或者对于Android开发而言，ContentProvider作为官方倡导的跨进程组件，其它进程通过定制的ContentProvider用于访问SharedPreferences，同样可以保证SharedPreferences的进程安全；等等。