Android進程管理

轉載地址:http://android.tgbus.com/android/tutorial/200812/172711.sHtml

　　除了Activity Lifecycle以外，android還有一個Process Lifecycle的說明：

　　在內存不足的時候，android是會主動清理門戶的，那它又是如何判斷哪個process是可以清掉的呢?文檔中也提到了它的重要性排序：

　　1. 最容易被清掉的是empty process，空進程是指那些沒有Activity與之綁定，也沒有任何應用程序組件(如Services或者IntentReceiver)與之綁定的進程，也就是說在這個process中沒有任何activity或者service之類的東西，它們僅僅是作為一個cache，在啟動新的 Activity時可以提高速度。它們是會被優先清掉的。因此建議，我們的後台操作，最好是作成Service的形式，也就是說應該在Activity中啟動一個Service去執行這些操作。

　　2.接下來就是background activity了，也就是被stop掉了那些activity所處的process，那些不可見的Activity被清掉的確是安全的，系統維持著一個 LRU列表，多個處於background的activity都在這裡面，系統可以根據LRU列表判斷哪些activity是可以被清掉的，以及其中哪一個應該是最先被清掉。不過，文檔中提到在這個已被清掉的Activity又被重新創建的時候，它的onCreate會被調用，參數就是onFreeze時的那個Bundle。不過這裡有一點不明白的是，難道這個Activity被killed時，android會幫它保留著這個Bundle嗎?

　　3.然後就輪到service process了，這是一個與Service綁定的進程，由startService方法啟動。雖然它們不為用戶所見，但一般是在處理一些長時間的操作(例如MP3的播放)，系統會保護它，除非真的沒有內存可用了。

　　4.接著又輪到那些visible activity了，或者說visible process。前面也談到這個情況，被Paused的Activity也是有可能會被系統清掉，不過相對來說，它已經是處於一個比較安全的位置了。

　　5.最安全應該就是那個foreground activity了，不到迫不得已它是不會被清掉的。這種process不僅包括resume之後的activity，也包括那些onReceiveIntent之後的IntentReceiver實例。

　　在Android Application的生命周期的討論中，文檔也提到了一些需要注意的事項：因為Android應用程序的生存期並不是由應用本身直接控制的，而是由 android系統平台進行管理的，所以，對於我們開發者而言，需要了解不同的組件Activity、Service和IntentReceiver的生命，切記的是：如果組件的選擇不當，很有可能系統會殺掉一個正在進行重要工作的進程。

　　下一步要了解的應該是Intent和它的IntentReceiver了，改天繼續。