項(xiàng)目中 ANR 率居高不下莺戒，從統(tǒng)計(jì)上來看排在前面的有幾個(gè)都是 SharedPreference（以下簡(jiǎn)稱 SP）引起的血筑。接下來我們抽絲剝繭的來分析其產(chǎn)生原因及如何解決枚尼。
crash 堆棧信息如下枉阵。從 crash 收集平臺(tái)上來看惰匙，有幾個(gè)類似的堆棧信息技掏。唯一的區(qū)別就是 ActivityThread 的入口方法。除了 ActivityThread 的 handleSleeping方法之外项鬼，還有 handleServiceArgs哑梳、handleStopService、handleStopActivity绘盟。
ActivityThread 的這幾個(gè)方法是 Activity 或 Service 的生命周期變化的時(shí)候調(diào)用的鸠真。從堆棧信息來看悯仙，組件生命周期變化，導(dǎo)致調(diào)用 QueueWork 中的隊(duì)列處于等待狀態(tài)吠卷，等待超時(shí)則發(fā)生 ANR锡垄。那么 QueuedWork 的工作機(jī)制是什么樣的呢，我們從源碼入手來進(jìn)行分析祭隔。
SP 的 apply 到底做了什么
首先從問題的源頭開始货岭，SP 的 apply 方法。
apply 方法疾渴，首先創(chuàng)建了一個(gè) awaitCommit 的 Runnable千贯，然后加入到 QueuedWork 中，awaitCommit 中包含了一個(gè)等待鎖搞坝，需要在其它地方釋放搔谴。我們?cè)谏厦婵吹降?QueuedWork.waitToFinish() 其實(shí)就是等待這個(gè)隊(duì)列中的 awaitCommit 全部釋放。
然后通過 SharedPreferencesImpl.this.enqueueDiskWrite 創(chuàng)建了一個(gè)任務(wù)來執(zhí)行真正的 SP 持久化桩撮。
其實(shí)無論是 SP 的 commit 還是 apply 最終都會(huì)調(diào)用 enqueueDiskWrite 方法敦第，區(qū)別是 commit 方法調(diào)用傳遞的第二個(gè)參數(shù)為 null。此方法內(nèi)部也是根據(jù)第二個(gè)參數(shù)來區(qū)分 commit 和 apply 的距境，如果是 commit 則會(huì)同步的執(zhí)行 writeToFileapply則會(huì)將 writeToFile 加入到一個(gè)任務(wù)隊(duì)列中異步的執(zhí)行申尼，從這里也可以看出 commit 和 apply 的真正區(qū)別垮卓。
writeToFile 執(zhí)行完成會(huì)釋放等待鎖垫桂，之后會(huì)回調(diào)傳遞進(jìn)來的第二個(gè)參數(shù) Runnable 的 run 方法，并將 QueuedWork 中的這個(gè)等待任務(wù)移除粟按。
總結(jié)來看诬滩，SP 調(diào)用 apply 方法，會(huì)創(chuàng)建一個(gè)等待鎖放到 QueuedWork 中灭将，并將真正數(shù)據(jù)持久化封裝成一個(gè)任務(wù)放到異步隊(duì)列中執(zhí)行疼鸟，任務(wù)執(zhí)行結(jié)束會(huì)釋放鎖。Activity onStop 以及 Service 處理 onStop庙曙，onStartCommand 時(shí)空镜，執(zhí)行 QueuedWork.waitToFinish() 等待所有的等待鎖釋放。
如何解決捌朴，清空等待隊(duì)列
從上述分析來看吴攒，SP 操作僅僅把 commit 替換為 apply 不是萬能的，apply 調(diào)用次數(shù)過多容易引起 ANR砂蔽。所有此類 ANR 都是經(jīng)由 QueuedWork.waitToFinish() 觸發(fā)的洼怔，如果在調(diào)用此函數(shù)之前，將其中保存的隊(duì)列手動(dòng)清空左驾，那么是不是能解決問題呢镣隶，答案是肯定的极谊。
Activity 的 onStop，以及 Service 的 onStop 和 onStartCommand 都是通過 ActivityThread 觸發(fā)的安岂，ActivityThread 中有一個(gè) Handler 變量轻猖，我們通過 Hook 拿到此變量，給此 Handler 設(shè)置一個(gè) callback嗜闻，Handler 的 dispatchMessage 中會(huì)先處理 callback蜕依。
1.在 Callback 中調(diào)用隊(duì)列的清理工作
2.隊(duì)列清理需要反射調(diào)用 QueuedWork。
清理等待鎖會(huì)產(chǎn)生什么問題
SP 無論是 commit 還是 apply 都會(huì)產(chǎn)生 ANR琉雳，但從 Android 之初到目前 Android8.0样眠，Google 一直沒有修復(fù)此 bug，我們貿(mào)然處理會(huì)產(chǎn)生什么問題呢翠肘。Google 在 Activity 和 Service 調(diào)用 onStop 之前阻塞主線程來處理 SP檐束，我們能猜到的唯一原因是盡可能的保證數(shù)據(jù)的持久化。因?yàn)槿绻谶\(yùn)行過程中產(chǎn)生了 crash束倍，也會(huì)導(dǎo)致 SP 未持久化被丧，持久化本身是 IO 操作，也會(huì)失敗绪妹。我們清理了等待鎖隊(duì)列甥桂，會(huì)對(duì)數(shù)據(jù)持久化造成什么影響呢，下面我們通過一組實(shí)驗(yàn)來驗(yàn)證邮旷。
進(jìn)程啟動(dòng)的時(shí)候黄选，產(chǎn)生一個(gè)隨機(jī)數(shù)字。用 commit 和 apply 兩種方式來存此變量婶肩。第二次進(jìn)程啟動(dòng)办陷，獲取以兩種方式存取的值并做比較，如果相同表示 apply 持久化成功律歼，如果不相同表示 apply 持久化失敗民镜。
實(shí)驗(yàn)一：開啟等待鎖隊(duì)列的清理。
實(shí)驗(yàn)二：關(guān)閉等待鎖隊(duì)列的清理险毁。
線上同時(shí)開啟兩個(gè)實(shí)驗(yàn)制圈，在實(shí)驗(yàn)規(guī)模相同的情況下，統(tǒng)計(jì) apply 失敗率畔况。
實(shí)驗(yàn)一鲸鹦，失敗率為 1.84%。
實(shí)驗(yàn)二问窃，失敗率為為 1.79%
可見亥鬓，apply 機(jī)制本身的失敗率就比較高，清理等待鎖隊(duì)列對(duì)持久化造成的影響不大域庇。
目前頭條 app 已經(jīng)全量開啟清理等待鎖策略嵌戈，上線至今沒有發(fā)現(xiàn)此策略產(chǎn)生的用戶反饋覆积。
