Android app被系統kill的場景，androidkill

Android app被系統kill的場景，androidkill

何時發生

當我們的app被切到後台的時候，比如用戶按下了home鍵或者切換到了別的應用，總之是我們的app不再和用戶交互了，這個時候對於我們的app來說就是什麼事情都可能發生的時候了，因為系統會認為你現在已經不是那麼重要了，而和用戶正在交互的app的優先級是最高的了，系統會想盡一切辦法保證這些app的正常運行，如果這時這些app再申請更多的資源，如內存時，當目前的系統狀況無法滿足時，系統便會拿後台app開刀，也就是很粗魯的殺掉整個app的進程，這時你也別指望onDestroy之類的callback會觸發，你唯一能指望的就是在切後台的時候onPause、onStop和onSaveInstanceState之類的方法，如果你有狀態需要保存那麼應該在這些地方處理，不要寄希望於onDestroy，它會讓你失望的，在這個地方用來釋放資源還是ok的。由於系統要殺進程，那麼緊接著的問題就是殺哪個進程，系統為此專門有個模塊叫LML（low memory killer），詳情可以參考下官方文檔，見這裡：processes-and-threads。

再次切回app的行為

比如你在離開app的時候，已經打開了3個act，分別是A，B，C，C在最頂端，也就是任務棧頂，A是你的main activity，假設在後台期間被系統殺掉進程了，後面如果用戶再次回來（通過recent tasks或者直接點擊launcher裡的app icon），這時展現在你眼前的將會是重建後的C activity，而不是正常情況下啟動的A，系統同時也恢復了當初的任務棧，也就是說棧裡的內容還是A，B，C，這時如果你按下了back鍵結束了C，那麼系統又會幫我們重建B，A在B結束的時候也是一樣的邏輯。這裡需要注意一點就是，如果是用戶自己殺掉了app，那麼再次啟動的時候回到的是A而不是C，只要記住是系統的錯導致我們被殺的話，那麼再次回到的話系統就有責任幫我們重建act。關於重建act的詳情，可以參考官方文檔recreating-activity。切回來之後雖然act是被重建了，但如果你代碼裡用了單例這樣的東西來存一些變量的值，那麼很不幸，這時所有單例中的字段全變成默認值了(0, false or null)，因為你想啊，進程都被殺死了啊，所有靜態字段等等都沒了。stackoverflow有這樣的問題，比如這個靜態變量變成null了。
目前筆者在維護的代碼裡有類似的構造，線上也確實出現了些類似的問題，著實蛋疼啊，准備改掉這種單例datakeeper的寫法，思路大體有以下幾種：

如何模擬

由於系統後台殺進程具有一定的隨機性，所以作為開發人員不可能去坐等這種情況發生，我們得有方法能很快速的復現，具體步驟如下：

參考 stackoverflow的提問。