日常开发中，运用过SharedPreference的同学，肯定在监控平台上看到过和SharedPreference相关的ANR，而且量应该不小。假如运用比较多或许常常用sp存一些大数据，如json等，相关的ANR常常能排到前10。下面就从源码的视点来看看，为什么SharedPreference简单发生ANR。
SharedPreference的用法，相信做过Android开发的同学都会，所以这儿就只简单介绍一下，不详细介绍了。
// 初始化一个sp
SharedPreferences sharedPreferences = context.getSharedPreferences("name_sp", MODE_PRIVATE);
// 修正key的值，有两种办法：commit和apply
sharedPreferences.edit().putBoolean("key_test", true).commit();
sharedPreferences.edit().putBoolean("key_test", true).apply();
// 读取一个key
sharedPreferences.getBoolean("key_test", false);
SharedPreference问题
SharedPreference的相关办法，除了commit外，一般的开发同学都会直接在主线程调用，认为这样不耗时。但其实，SharedPreference的许多办法都是耗时的，直接在主线程调很或许会引起ANR的问题。另外，尽管apply办法的调用不耗时，可是会引起生命周期相关的ANR问题。
下面就来从源码的视点，看一下或许引起ANR的问题所在。
getSharedPreference(String name, int mode)
@Override
public SharedPreferences getSharedPreferences(String name, int mode) {
File file;
// 与sp相关的操作，都运用ContextImpl的类锁
synchronized (ContextImpl.class) {
if (mSharedPrefsPaths == null) {
mSharedPrefsPaths = new ArrayMap<>();
}
// mSharedPrefsPaths是内存缓存的文件途径
file = mSharedPrefsPaths.get(name);
if (file == null) {
// 此处获取SharedPreferences的文件途径，或许存在耗时
file = getSharedPreferencesPath(name);
mSharedPrefsPaths.put(name, file);
}
}
return getSharedPreferences(file, mode);
}
下面看下获取文件途径的办法：getSharedPreferencesPath()，这个办法或许存在耗时。
public File getSharedPreferencesPath(String name) {
// 创立一个sp的存储文件
return makeFilename(getPreferencesDir(), name + ".xml");
}
调用getPreferencesDir()获取sharedPrefs的根途径
private File getPreferencesDir() {
// 一切和文件有关的操作，都会运用mSync锁，或许呈现与其他线程抢锁的耗时
synchronized (mSync) {
if (mPreferencesDir == null) {
mPreferencesDir = new File(getDataDir(), "shared_prefs");
}
// 这个办法，假如目录不存在，会创立目录，或许存在耗时
return ensurePrivateDirExists(mPreferencesDir);
}
}
ensurePrivateDirExists()：保证文件目录存在
private static File ensurePrivateDirExists(File file, int mode, int gid, String xattr) {
if (!file.exists()) {
final String path = file.getAbsolutePath();
try {
// 创立文件夹，会耗时
Os.mkdir(path, mode);
Os.chmod(path, mode);
} catch (ErrnoException e) {
}
return file;
}
再来看看getSharedPreferences生成SharedPreferenceImpl目标的流程。
public SharedPreferences getSharedPreferences(File file, int mode) {
SharedPreferencesImpl sp;
synchronized (ContextImpl.class) {
// 获取cache，先从cache中获取SharedPreferenceImpl
final ArrayMap<File, SharedPreferencesImpl> cache = getSharedPreferencesCacheLocked();
sp = cache.get(file);
if (sp == null) {
// 假如没有cache，则创立一个SharedPreferencesImpl，此处或许存在耗时
sp = new SharedPreferencesImpl(file, mode);
cache.put(file, sp);
return sp;
}
}
return sp;
}
先来看下cache的原理
private ArrayMap<File, SharedPreferencesImpl> getSharedPreferencesCacheLocked() {
// sSharedPrefsCache是一个静态变量，全局有效
if (sSharedPrefsCache == null) {
sSharedPrefsCache = new ArrayMap<>();
}
// key:包名，value: ArrayMap<File, SharedPreferencesImpl>
final String packageName = getPackageName();
ArrayMap<File, SharedPreferencesImpl> packagePrefs = sSharedPrefsCache.get(packageName);
if (packagePrefs == null) {
packagePrefs = new ArrayMap<>();
sSharedPrefsCache.put(packageName, packagePrefs);
}
return packagePrefs;
}
再来看看SharedPreferenceImpl的结构办法，看看SharedPreference是怎样初始化的。
SharedPreferencesImpl(File file, int mode) {
mFile = file;
mBackupFile = makeBackupFile(file);
// 设置是否load到内存的标志位为false
mLoaded = false;
startLoadFromDisk();
}
startLoadFromDisk()：敞开一个子线程，将sp中的内容读取到内存中
private void startLoadFromDisk() {
// 改mLoaded标志位时，需求获取mLock锁
synchronized (mLock) {
// load之前先设置mLoaded标志位为false
mLoaded = false;
}
// 敞开一个线程，从文件中将sp中的内容读取到内存中
new Thread("SharedPreferencesImpl-load") {
public void run() {
// 在子线程load
loadFromDisk();
}
}.start();
}
loadFromDisk：真实读取文件的当地
private void loadFromDisk() {
synchronized (mLock) {
// 假如已经load过了，直接return，不需求再从头load
if (mLoaded) {
return;
}
stat = Os.stat(mFile.getPath());
if (mFile.canRead()) {
BufferedInputStream str = null;
try {
str = new BufferedInputStream(
new FileInputStream(mFile), 16 * 1024);
// 读取xml的内容到map中
map = (Map<String, Object>) XmlUtils.readMapXml(str);
} catch (Exception e) {
Log.w(TAG, "Cannot read " + mFile.getAbsolutePath(), e);
} finally {
IoUtils.closeQuietly(str);
}
}
synchronized (mLock) {
// 设置mLoaded标志位为true，表示已经load完，通知一切在等候的线程
mLoaded = true;
mLock.notifyAll();
}
}
总结：通过上面的分析，getSharedPreferences主要的卡顿点在于，获取PreferencesDir的时分，或许存在目录没有创立的状况。假如这个时分调用了创立目录的办法，就会非常耗时。
getBoolean(String key, boolean defValue)
这个办法和一切获取key的办法一样，都或许存在耗时。
从SharedPreferencesImpl的结构办法，咱们知道会敞开一个新的线程，将内容从文件中读取到缓存的map里，这个过程咱们叫load。
public boolean getBoolean(String key, boolean defValue) {
synchronized (mLock) {
// 需求等候，直到load成功
awaitLoadedLocked();
// 从缓存中取value
Boolean v = (Boolean)mMap.get(key);
return v != null ? v : defValue;
}
}
主要耗时的办法，在awaitLoadedLocked里。
private void awaitLoadedLocked() {
// 只有当mLoaded为true时，才干跳出死循环
while (!mLoaded) {
try {
// 调用wait后，会开释mLock锁，而且进入等候池，等候load完之后的唤醒
mLock.wait();
} catch (InterruptedException unused) {
}
}
}
这个办法，调用了mLock.wait()，开释了mLock的目标锁，而且进入等候池，直到load完被唤醒。
总结：所以，getBoolean等获取key的办法，会等候，直到sp的内容从文件中copy到缓存map里。很或许存在耗时。
commit()
commit()办法，会进行同步写，一定存在耗时，不能直接在主线程调用。
public boolean commit() {
// 开始排队写
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;
}
apply()
咱们都知道apply办法是异步写，可是也或许造成ANR的问题。下面咱们来看apply办法的源码。
public void apply() {
// 先将更新写入内存缓存
final MemoryCommitResult mcr = commitToMemory();
// 创立一个awaitCommit的runnable，加入到QueuedWork中
final Runnable awaitCommit = new Runnable() {
@Override
public void run() {
try {
// 等候写入完结
mcr.writtenToDiskLatch.await();
} catch (InterruptedException ignored) {
}
}
};
// 将awaitCommit加入到QueuedWork中
QueuedWork.addFinisher(awaitCommit);
Runnable postWriteRunnable = new Runnable() {
@Override
public void run() {
awaitCommit.run();
QueuedWork.removeFinisher(awaitCommit);
}
};
// 真实履行sp耐久化操作，异步履行
SharedPreferencesImpl.this.enqueueDiskWrite(mcr, postWriteRunnable);
// 尽管还没写入文件，可是内存缓存已经更新了，而listener通常都持有相同的sharedPreference目标，所以可以运用内存缓存中的数据
notifyListeners(mcr);
}
可以看到这儿确实是在子线程进行的写入操作，可是为什么说apply也会引起ANR呢？
由于在Activity和Service的一些生命周期办法里，都会调用QueuedWork.waitToFinish()办法，这个办法会等候一切子线程写入完结，才会继续进行。主线程等子线程，很简单发生ANR问题。
public static void waitToFinish() {
Runnable toFinish;
//等候一切的使命履行完结
while ((toFinish = sPendingWorkFinishers.poll()) != null) {
toFinish.run();
}
}
Android 8.0 在这儿做了一些优化，但仍是需求等写入完结，无法完结解决ANR的问题。
总结
综上所述，SharedPreference或许在以下几种状况下发生卡顿，然后引起ANR：
- 创立
SharedPreference时，调用getPreferenceDir，或许存在创立目录的行为 -
getBoolean等办法，会等候直到SharedPreference将文件中的键值对悉数读取到缓存里，才会返回 -
commit办法直接同步写，假如不小心在主线程调用，会引起卡顿 -
apply办法尽管是在异步线程写入，可是由于Activity和Service的生命周期会等候一切SharedPreference的写入完结，所以或许引起卡顿和ANR问题
SharedPreference从规划之初，便是为了存储少数key-value对，而存在的。其自身的规划，就存在许多缺陷。在存储特别少数数据的时分，功能瓶颈还不显着。可是现在许多开发同学在运用的时分，会往里面存一些大型的JSON字符串等，导致它的缺点被显着暴露出来。建议在运用SharedPreference的时分，只用于存储少数数据，不要存大的字符串。
当然，咱们也有一些办法来一致优化SharedPreference，减少ANR的发生，下一篇咱们继续讲。
