Go最全[Google]-再见-SharedPreferences-拥抱-Jetpack-DataStore(3)，2024年最新高级Golang面试题及答案

qq_38197819

于 2024-05-16 08:48:15 发布

阅读量938

点赞数 26

文章标签： go 学习面试

本文链接：https://blog.csdn.net/qq_38197819/article/details/138942307

版权

既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，涵盖了95%以上Go语言开发知识点，真正体系化！

由于文件比较多，这里只是将部分目录截图出来，全套包含大厂面经、学习笔记、源码讲义、实战项目、大纲路线、讲解视频，并且后续会持续更新

如果你需要这些资料，可以戳这里获取

作者：HiDhl
Google 新增加了一个新 Jetpack 的成员 DataStore，主要用来替换 SharedPreferences， DataStore 应该是开发者期待已久的库，DataStore 是基于 Flow 实现的，一种新的数据存储方案，它提供了两种实现方式：

Proto DataStore：存储类的对象（typed objects ），通过 protocol buffers 将对象序列化存储在本地，protocol buffers 现在已经应用的非常广泛，无论是微信还是阿里等等大厂都在使用，我们在部分业务场景中也用到了 protocol buffers，会在后续的文章详细分析
Preferences DataStore：以键值对的形式存储在本地和 SharedPreferences 类似，但是 DataStore 是基于 Flow 实现的，不会阻塞主线程，并且保证类型安全

Jetpack DataStore 将会分为至少 2 篇文章来分析，今天这篇文章主要来介绍 Jetpack DataStore 其中一种实现方式 Preferences DataStore，文章中的示例代码，已经上传到 GitHub 欢迎前去查看 AndroidX-Jetpack-Practice/DataStoreSimple。

GitHub 地址：https://github.com/hi-dhl/AndroidX-Jetpack-Practice

这篇文章会涉及到 Koltin flow 相关内容，如果不了解可以先去看另外一篇文章 Kotlin Flow 是什么？Channel 是什么？

通过这篇文章你将学习到以下内容：

那些年我们所经历的 SharedPreferences 坑？
为什么需要 DataStore？它为我们解决了什么问题？
如何在项目中使用 DataStore？
如何迁移 SharedPreferences 到 DataStore？
MMKV、DataStore、SharedPreferences 的不同之处?

一个新库的出现必定为我们解决了一些问题，那么 Jetpack DataStore 为我们解决什么问题呢，在分析之前，我们需要先来了解 SharedPreferences 都有那些坑。

那些年我们所经历的 SharedPreferences 坑

SharedPreference 是一个轻量级的数据存储方式，使用起来也非常方便，以键值对的形式存储在本地，初始化 SharedPreference 的时候，会将整个文件内容加载内存中，因此会带来以下问题：

通过 getXXX() 方法获取数据，可能会导致主线程阻塞
SharedPreference 不能保证类型安全
SharedPreference 加载的数据会一直留在内存中，浪费内存
apply() 方法虽然是异步的，可能会发生 ANR，在 8.0 之前和 8.0 之后实现各不相同
apply() 方法无法获取到操作成功或者失败的结果

接下来我们逐个来分析一下 SharedPreferences 带来的这些问题，在文章中 SharedPreference 简称 SP。

`getXXX()` 方法可能会导致主线程阻塞

所有 getXXX() 方法都是同步的，在主线程调用 get 方法，必须等待 SP 加载完毕，会导致主线程阻塞，下面的代码，我相信小伙伴们并不陌生。

val sp = getSharedPreferences(“ByteCode”, Context.MODE_PRIVATE) // 异步加载 SP 文件内容
sp.getString(“jetpack”, “”); // 等待 SP 加载完毕
复制代码

调用 getSharedPreferences() 方法，最终会调用 SharedPreferencesImpl#startLoadFromDisk() 方法开启一个线程异步读取数据。
frameworks/base/core/java/android/app/SharedPreferencesImpl.java

private final Object mLock = new Object();
private boolean mLoaded = false;
private void startLoadFromDisk() {
synchronized (mLock) {
mLoaded = false;
}
new Thread(“SharedPreferencesImpl-load”) {
public void run() {
loadFromDisk();
}
}.start();
}
复制代码

正如你所看到的，开启一个线程异步读取数据，当我们正在读取一个比较大的数据，还没读取完，接着调用 getXXX() 方法。

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

private void awaitLoadedLocked() {
…
while (!mLoaded) {
try {
mLock.wait();
} catch (InterruptedException unused) {
}
}
…
}
复制代码

在同步方法内调用了 wait() 方法，会一直等待 getSharedPreferences() 方法开启的线程读取完数据才能继续往下执行，如果读取几 KB 的数据还好，假设读取一个大的文件，势必会造成主线程阻塞。

SP 不能保证类型安全

调用 getXXX() 方法的时候，可能会出现 ClassCastException 异常，因为使用相同的 key 进行操作的时候，putXXX 方法可以使用不同类型的数据覆盖掉相同的 key。

val key = “jetpack”
val sp = getSharedPreferences(“ByteCode”, Context.MODE_PRIVATE) // 异步加载 SP 文件内容

sp.edit { putInt(key, 0) } // 使用 Int 类型的数据覆盖相同的 key
sp.getString(key, “”); // 使用相同的 key 读取 Sting 类型的数据
复制代码

使用 Int 类型的数据覆盖掉相同的 key，然后使用相同的 key 读取 Sting 类型的数据，编译正常，但是运行会出现以下异常。

java.lang.ClassCastException: java.lang.Integer cannot be cast to java.lang.String
复制代码

SP 加载的数据会一直留在内存中

通过 getSharedPreferences() 方法加载的数据，最后会将数据存储在静态的成员变量中。

// 调用 getSharedPreferences 方法，最后会调用 getSharedPreferencesCacheLocked 方法
public SharedPreferences getSharedPreferences(File file, int mode) {
…
final ArrayMap<File, SharedPreferencesImpl> cache = getSharedPreferencesCacheLocked();
return sp;
}

// 通过静态的 ArrayMap 缓存 SP 加载的数据
private static ArrayMap<String, ArrayMap<File, SharedPreferencesImpl>> sSharedPrefsCache;

// 将数据保存在 sSharedPrefsCache 中
private ArrayMap<File, SharedPreferencesImpl> getSharedPreferencesCacheLocked() {
…

ArrayMap<File, SharedPreferencesImpl> packagePrefs = sSharedPrefsCache.get(packageName);
if (packagePrefs == null) {
packagePrefs = new ArrayMap<>();
sSharedPrefsCache.put(packageName, packagePrefs);
}

return packagePrefs;
}
复制代码

通过静态的 ArrayMap 缓存每一个 SP 文件，而每个 SP 文件内容通过 Map 缓存键值对数据，这样数据会一直留在内存中，浪费内存。

`apply()` 方法是异步的，可能会发生 ANR

apply() 方法是异步的，为什么还会造成 ANR 呢？曾今的字节跳动就出现过这个问题，具体详情可以点击这里前去查看剖析 SharedPreference apply 引起的 ANR 问题而且 Google 也明确指出了 apply() 的问题。

[图片上传中…(image-ab9199-1602236582506-4)]

简单总结一下：apply() 方法是异步的，本身是不会有任何问题，但是当生命周期处于 handleStopService() 、 handlePauseActivity() 、 handleStopActivity() 的时候会一直等待 apply() 方法将数据保存成功，否则会一直等待，从而阻塞主线程造成 ANR，一起来分析一下为什么异步方法还会阻塞主线程，先来看看 apply() 方法的实现。
frameworks/base/core/java/android/app/SharedPreferencesImpl.java

public void apply() {
final long startTime = System.currentTimeMillis();

final MemoryCommitResult mcr = commitToMemory();
final Runnable awaitCommit = new Runnable() {
@Override
public void run() {
mcr.writtenToDiskLatch.await(); // 等待
…
}
};
// 将 awaitCommit 添加到队列 QueuedWork 中
QueuedWork.addFinisher(awaitCommit);

Runnable postWriteRunnable = new Runnable() {
@Override
public void run() {
awaitCommit.run();
QueuedWork.removeFinisher(awaitCommit);
}
};
// 8.0 之前加入到一个单线程的线程池中执行
// 8.0 之后加入 HandlerThread 中执行写入任务
SharedPreferencesImpl.this.enqueueDiskWrite(mcr, postWriteRunnable);
}
复制代码

将一个 awaitCommit 的 Runnable 任务，添加到队列 QueuedWork 中，在 awaitCommit 中会调用 await() 方法等待，在 handleStopService 、 handleStopActivity 等等生命周期会以这个作为判断条件，等待任务执行完毕
将一个 postWriteRunnable 的 Runnable 写任务，通过 enqueueDiskWrite 方法，将写入任务加入到队列中，而写入任务在一个线程中执行

注意：在 8.0 之前和 8.0 之后 enqueueDiskWrite() 方法实现逻辑各不相同

在 8.0 之前调用 enqueueDiskWrite() 方法，将写入任务加入到 单个线程的线程池 中执行，如果 apply() 多次的话，任务将会依次执行，效率很低，android-7.0.0_r34 源码如下所示。

// android-7.0.0_r34: frameworks/base/core/java/android/app/SharedPreferencesImpl.java
private void enqueueDiskWrite(final MemoryCommitResult mcr,
final Runnable postWriteRunnable) {
…
QueuedWork.singleThreadExecutor().execute(writeToDiskRunnable);
}

// android-7.0.0_r34: frameworks/base/core/java/android/app/QueuedWork.java
public static ExecutorService singleThreadExecutor() {
synchronized (QueuedWork.class) {
if (sSingleThreadExecutor == null) {
sSingleThreadExecutor = Executors.newSingleThreadExecutor();
}
return sSingleThreadExecutor;
}
}
复制代码

通过 Executors.newSingleThreadExecutor() 方法创建了一个 单个线程的线程池，因此任务是串行的，通过 apply() 方法创建的任务，都会添加到这个线程池内。

在 8.0 之后将写入任务加入到 LinkedList 链表中，在 HandlerThread 中执行写入任务，android-10.0.0_r14 源码如下所示。

// android-10.0.0_r14: frameworks/base/core/java/android/app/SharedPreferencesImpl.java
private void enqueueDiskWrite(final MemoryCommitResult mcr,
final Runnable postWriteRunnable) {
…
QueuedWork.queue(writeToDiskRunnable, !isFromSyncCommit);
}

// android-10.0.0_r14: frameworks/base/core/java/android/app/QueuedWork.java

private static final LinkedList sWork = new LinkedList<>();

public static void queue(Runnable work, boolean shouldDelay) {
Handler handler = getHandler(); // 获取 handlerThread.getLooper() 生成 Handler 对象
synchronized (sLock) {
sWork.add(work); // 将写入任务加入到 LinkedList 链表中

if (shouldDelay && sCanDelay) {
handler.sendEmptyMessageDelayed(QueuedWorkHandler.MSG_RUN, DELAY);
} else {
handler.sendEmptyMessage(QueuedWorkHandler.MSG_RUN);
}
}
}
复制代码

在 8.0 之后通过调用 handlerThread.getLooper() 方法生成 Handler，任务都会在 HandlerThread 中执行，所有通过 apply() 方法创建的任务，都会添加到 LinkedList 链表中。

当生命周期处于 handleStopService() 、 handlePauseActivity() 、 handleStopActivity() 的时候会调用 QueuedWork.waitToFinish() 会等待写入任务执行完毕，我们以其中 handlePauseActivity() 方法为例。

public void handlePauseActivity(IBinder token, boolean finished, boolean userLeaving,
int configChanges, PendingTransactionActions pendingActions, String reason) {
…
// 确保写任务都已经完成
QueuedWork.waitToFinish();
…
}
}
复制代码

正如你所看到的在 handlePauseActivity() 方法中，调用了 QueuedWork.waitToFinish() 方法，会等待所有的写入执行完毕，Google 在 8.0 之后对这个方法做了很大的优化，一起来看一下 8.0 之前和 8.0 之后的区别。

注意：在 8.0 之前和 8.0 之后 waitToFinish() 方法实现逻辑各不相同

在 8.0 之前 waitToFinish() 方法只做了一件事，会一直等待写入任务执行完毕，我先来看看在 android-7.0.0_r34 源码实现。
android-7.0.0_r34: frameworks/base/core/java/android/app/QueuedWork.java

private static final ConcurrentLinkedQueue sPendingWorkFinishers =
new ConcurrentLinkedQueue();

public static void waitToFinish() {
Runnable toFinish;
while ((toFinish = sPendingWorkFinishers.poll()) != null) {
toFinish.run(); // 相当于调用 mcr.writtenToDiskLatch.await() 方法
}
}
复制代码

sPendingWorkFinishers 是 ConcurrentLinkedQueue 实例，apply 方法会将写入任务添加到 sPendingWorkFinishers 队列中，在 单个线程的线程池 中执行写入任务，线程的调度并不由程序来控制，也就是说当生命周期切换的时候，任务不一定处于执行状态
toFinish.run() 方法，相当于调用 mcr.writtenToDiskLatch.await() 方法，会一直等待
waitToFinish() 方法就做了一件事，会一直等待写入任务执行完毕，其它什么都不做，当有很多写入任务，会依次执行，当文件很大时，效率很低，造成 ANR 就不奇怪了，尤其像字节跳动这种大规模的 App

在 8.0 之后 waitToFinish() 方法做了很大的优化，当生命周期切换的时候，会主动触发任务的执行，而不是一直在等着，我们来看看 android-10.0.0_r14 源码实现。
android-10.0.0_r14: frameworks/base/core/java/android/app/QueuedWork.java

private static final LinkedList sFinishers = new LinkedList<>();
public static void waitToFinish() {
…
try {
processPendingWork(); // 主动触发任务的执行
} finally {
StrictMode.setThreadPolicy(oldPolicy);
}

try {
// 等待任务执行完毕
while (true) {
Runnable finisher;

synchronized (sLock) {
finisher = sFinishers.poll(); // 从 LinkedList 中取出任务
}

if (finisher == null) { // 当 LinkedList 中没有任务时会跳出循环
break;
}

finisher.run(); // 相当于调用 mcr.writtenToDiskLatch.await()
}
}

…
}
复制代码

在 waitToFinish() 方法中会主动调用 processPendingWork() 方法触发任务的执行，在 HandlerThread 中执行写入任务。

另外还做了一个很重要的优化，当调用 apply() 方法的时候，执行磁盘写入，都是全量写入，在 8.0 之前，调用 N 次 apply() 方法，就会执行 N 次磁盘写入，在 8.0 之后，apply() 方法调用了多次，只会执行最后一次写入，通过版本号来控制的。

SharedPreferences 的另外一个缺点就是 apply() 方法无法获取到操作成功或者失败的结果，而 commit() 方法是可以接收 MemoryCommitResult 里面的一个 boolean 参数作为结果，来看一下它们的方法签名。

public void apply() { … }

public boolean commit() { … }
复制代码