正文
日常开发中,使用过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的发生,下一篇我们继续讲。