在 Android 中，多數情況下每個程式都是在各自獨立的 Linux 程序中執行的。當一個程式或其某些部分被請求時，它的程序就“出生”了；當這個程式沒有必要再執行下去且系統需要回收這個程序的記憶體用於其他程式時，這個 程序就“死亡”了。可以看出，Android 程式的生命週期是由系統控制而非程式自身直接控制。這和我們編寫桌面應用程式時的思維有一些不同，一個桌面應用程式的程序也是在其他程序或使用者請求時被創 建，但是往往是在程式自身收到關閉請求後執行一個特定的動作（比如從 main 函式中 return）而導致程序結束的。要想做好某種型別的程式或者某種平臺下的程式的開發，最關鍵的就是要弄清楚這種型別的程式或整個平臺下的程式的一般工作 模式並熟記在心。在 Android 中，程式的生命週期控制就是屬於這個範疇——我的個人理解:)

在 Android 系統中，當某個 activity呼叫 startActivity(myIntent) 時，系統會在所有已經安裝的程式中尋找其 intent filter 和 myIntent 最匹配的一個 activity，啟動這個程序，並把這個 intent 通知給這個 activity。這就是一個程式的“生”。比如我們在 Home application 中選擇 “Web browser”，系統會根據這個 intent 找到並啟動 Web browser 程式，顯示 Web browser 的一個 activity 供我們瀏覽網頁（這個啟動過程有點類似我們在在個人電腦上雙擊桌面上的一個圖示，啟動某個應用程式）。在 Android 中，所有的應用程式“生來就是平等的”，所以不光 Android 的核心程式甚至第三方程式也可以發出一個 intent 來啟動另外一個程式中的一個 activity。Android 的這種設計非常有利於“程式部件”的重用。

  一個 Android 程式的程序是何時被系統結束的呢？通俗地說，一個即將被系統關閉的程式是系統在記憶體不足（low memory）時，根據“重要性層次”選出來的“犧牲品”。一個程序的重要性是根據其中執行的部件和部件的狀態決定的。各種程序按照重要性從高到低排列如 下：
  1. 前臺程序。這樣的程序擁有一個在螢幕上顯示並和使用者互動的 activity 或者它的一個IntentReciver 正在執行。這樣的程式重要性最高，只有在系統記憶體非常低，萬不得已時才會被結束。
  2. 可見程序。在螢幕上顯示，但是不在前臺的程式。比如一個前臺程序以對話方塊的形式顯示在該程序前面。這樣的程序也很重要，它們只有在系統沒有足夠記憶體執行所有前臺程序時，才會被結束。
  3. 服務程序。這樣的程序在後臺持續執行，比如後臺音樂播放、後臺資料上傳下載等。這樣的程序對使用者來說一般很有用，所以只有當系統沒有足夠記憶體來維持所有的前臺和可見程序時，才會被結束。
  4. 後臺程序。這樣的程式擁有一個使用者不可見的 activity。這樣的程式在系統記憶體不足時，按照 

LRU 的順序被結束。
  5. 空程序。這樣的程序不包含任何活動的程式部件。系統可能隨時關閉這類程序。
 

從某種意義上講，垃圾收集機制把程式設計師從“記憶體管理噩夢”中解放出來，而 Android 的程序生命週期管理機制把使用者從“任務管理噩夢”中解放出來。我見過一些 Nokia S60 使用者和 Windows Mobile 使用者要麼因為長期不關閉多餘的應用程式而導致系統變慢，要麼因為不時檢視應用程式列表而影響使用體驗。Android 使用 Java 作為應用程式 API，並且結合其獨特的生命週期管理機制同時為開發者和使用者提供最大程度的便利。

Activity lifecycle

Activity有三種基本狀態：

1. Active：處於螢幕前景（當前task的棧頂Activity處於Active狀態），同一時刻只能有一個Activity處於Active狀態；
2. Paused狀態：處於背景畫面畫面狀態，失去了焦點，但依然是活動狀態；
3. stopped：不可見，但依然保持所有的狀態和記憶體資訊。

可以呼叫finish()結束處理Paused或者stopped狀態的Activity。

各種狀態之間通過下列的函式呼叫轉換：

void onCreate(Bundle savedInstanceState)
void onStart()
void onRestart()
void onResume()
void onPause()
void onStop()
void onDestroy()

Activity的生命週期可以分為三組：

• The entire lifetime of an activity happens between the first call tothrough to a single final call to .

• The visible lifetime of an activity happens between a call to until a corresponding call to .

• The foreground lifetime of an activity happens between a call to until a corresponding call to.

儲存Activity狀態

To capture that state before the activity is killed, you can implement an  method for the activity. Android calls this method before making the activity vulnerable to being destroyed — that is, before onPause() is called. It passes the method a  object where you can record the dynamic state of the activity as name-value pairs. When the activity is again started, the Bundle is passed both to onCreate() and to a method that's called after onStart(),, so that either or both of them can recreate the captured state.

Unlike onPause() and the other methods discussed earlier, onSaveInstanceState()and onRestoreInstanceState()are not lifecycle methods. They are not always called. Because onSaveInstanceState() is not always called, you should use it only to record the transient state of the activity, not to store persistent data.Use onPause() for that purpose instead.

啟動另一個Activity的過程

The current activity's onPause() method is called. Next, the starting activity's onCreate(), onStart(), and onResume() methods are called in sequence. Then, if the starting activity is no longer visible on screen, its onStop() method is called.

service生命週期

A service can be used in two ways:

• It can be started and allowed to run until someone stops it or it stops itself. In this mode, it's started by calling and stopped by calling . It can stop itself by calling or . Only one stopService() call is needed to stop the service, no matter how many times startService() was called.

• It can be operated programmatically using an interface that it defines and exports. Clients establish a connection to the Service object and use that connection to call into the service. The connection is established by calling, and is closed by calling . Multiple clients can bind to the same service. If the service has not already been launched, bindService() can optionally launch it.

相關的方法：

void onCreate()
void onStart(Intent intent)
void onDestroy()

The onCreate() and onDestroy() methods are called for all services, whether they're started by or . However, onStart() is called only for services started bystartService().

If a service permits others to bind to it, there are additional callback methods for it to implement:

IBinder onBind(Intent intent)
boolean onUnbind(Intent intent)
void onRebind(Intent intent)

Broadcast receiver lifecycle

只有一個方法：void onReceive(Context curContext, Intent broadcastMsg)

A process with an active broadcast receiver is protected from being killed. But a process with only inactive components can be killed by the system at any time, when the memory it consumes is needed by other processes.

This presents a problem when the response to a broadcast message is time consuming and, therefore, something that should be done in a separate thread, away from the main thread where other components of the user interface run. IfonReceive() spawns the thread and then returns, the entire process, including the new thread, is judged to be inactive (unless other application components are active in the process), putting it in jeopardy of being killed. The solution to this problem is for onReceive() to start a service and let the service do the job, so the system knows that there is still active work being done in the process.

程序的生命週期

Android根據其重要性在記憶體不足的時候移去重要性最低的程序。重要性由高到低為：

1. 前臺程序
2. 可見程序
3. 服務程序
4. 後臺程序
5. 空程序

注意：Because a process running a service is ranked higher than one with background activities, an activity that initiates a long-running operation might do well to start a service for that operation, rather than simply spawn a thread — particularly if the operation will likely outlast the activity. 比如播放MP3的時候就要啟動一個service。