Android app被系統kill的場景

什麼時候發生

當咱們的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的寫法，思路大致有如下幾種：

1. 不改現有的單例datakeeper寫法，可是增長永久存儲支持，好比寫到SP中，之後若是發現字段中沒值了，那麼就去SP中讀一發；
2. 數據經過Intent傳遞，這樣也能保證不丟失，由於系統重建act的時候，用的Intent和當時啓動act時的Intent是同樣的，因此若是你所須要的數據都是以這種方式傳遞的，那恭喜你，you are safe，你要作的只是從Intent中解析出來你須要的數據；
3. 在onSaveInstanceState中保存數據，在onCreate()/onRestoreInstanceState()中恢復數據；

 

如何模擬

因爲系統後臺殺進程具備必定的隨機性，因此做爲開發人員不可能去坐等這種狀況發生，咱們得有方法能很快速的復現，具體步驟以下：

                           模擬後臺殺進程的步驟

參考 stackoverflow的提問。