何時發生

當我們的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的寫法，思路大體有以下幾種：

不改現有的單例datakeeper寫法，但是增加永久存儲支持，比如寫到SP中，以后如果發現字段中沒值了，那么就去SP中讀一發；

數據通過Intent傳遞，這樣也能保證不丟失，因為系統重建act的時候，用的Intent和當時啟動act時的Intent是一樣的，所以如果你所需要的數據都是以這種方式傳遞的，那恭喜你，you are safe，你要做的只是從Intent中解析出來你需要的數據；

在onSaveInstanceState中保存數據，在onCreate()/onRestoreInstanceState()中恢復數據；

?

如何模擬

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

模擬后臺殺進程的步驟

參考?stackoverflow的提問。

轉載于:https://www.cnblogs.com/xiaoweiz/p/5324273.html

總結

以上是生活随笔為你收集整理的Android app被系统kill的场景的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。