SharedPreference引發ANR原理詳解
正文
日常開發中,使用過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的發生,下一篇我們繼續講。
以上就是SharedPreference引發ANR原理詳解的詳細內容,更多關於SharedPreference引發ANR的資料請關註WalkonNet其它相關文章!
推薦閱讀:
- Android文件存儲SharedPreferences源碼解析
- Android SharedPreferences存取操作以及封裝詳解
- Android 使用 SharedPreferences 保存少量數據的實現代碼
- Android數據存儲方式操作模式解析
- 淺談Java中GuavaCache返回Null的註意事項