Android 並發編程：（一）基礎知識 —— 1.2 程式的啟動和終結

標籤：android   style   blog   http   color   java   os   io   

本章節所有內容皆為原創，如需轉載，請註明出處。

http://blog.csdn.net/manoel/article/details/38471825

Android是一個多使用者，多任務的系統。

允許多個app在同一時刻執行，在多個程式之間切換並不會有明顯的延遲。

多任務是由Linux核心負責處理的，而程式的運行基於Linux進程。

Linux進程

Linux為每一個使用者指派一個唯一的使用者ID（User ID），用於區分不同的User。

因為許可權的原因，每一個使用者只能訪問私人資源，沒有使用者（除了Root使用者，即超級管理員。我們這裡不考慮這個使用者。）可以訪問其他使用者的私人資源。因而，“沙箱”就用來獨立這些使用者。

在Android中，每一個應用都有一個唯一的使用者ID，也就是說，Android中的App對應著Linux中的使用者，並且App之間不能互訪資源。

Android為每一個進程都添加了一個Dalvik虛擬機器，也就是每一個app都對應一個Dalvik虛擬機器。

展示了Linux進程，Dalvik虛擬機器和App之間的關係。

預設地，App和進程有一對一的關係。

但如果有需要的話，一個App可以在幾個進程中運行，或者幾個App在同一個進程中運行。

生命週期

App的生命週期被封裝在它自己的Linux進程中，從Java的視角來說，就是android.app.Application類。

當Dalvik調用Application的onCreate()方法時，Applicationg對象就被產生了。理想情況下，Dalvik調用Application的onTerminate()的時候，app就停止了。

但切記，不能依靠這個去判斷一個Application對象被銷毀了！

因為潛在的Linux進程或許已經被Kill掉了，這個時候Dalvik還沒有調用onTerminate()。

總之，Application對象是在一個進程中第一個被執行個體化的對象，也是最後一個被銷毀的。

App啟動

當一個App的任何一個組件被啟用的時候，這個App就被開啟了。

任何組件都是App的入口。還記得嗎，組件包括：Activity，BroadcastReceiver，Service和ContentProvider。

當第一個組件被啟用的時候，這個App的Linux進程就被啟用了，除非這個Linux進程已經處於運行狀態。

App開啟的過程總結如下：

1. 開啟Linux進程.
2. 建立Dalvik虛擬機器.
3. 建立Application執行個體.
4. 建立App的入口組件.

建立一個新的Linux進程和Dalvik虛擬機器並不是一個瞬時的操作。這個過程會降低效能，並且對使用者體驗稍有影響。

因此，Linux系統通過在啟動（系統啟動）的時候開啟一個特別的Zygote進程去縮短App的啟動時間。

這是怎麼回事呢。Zygote包括了所有預先載入的核心庫，新的App進程就是從這個Zygote進程孵化出來的，但是App進程並不會複製那些預先載入的核心庫，而是共用Zygote的核心庫。

就是這樣，縮短了App的啟動時間。

App終結

在App啟動的時候，Linux進程被建立，當系統需要回收資源的時候Linux進程終結。為了保證使用者每次進入App時不會重複上面的流程。如果不是真的到了資源缺的地步，Dalvik是不會銷毀這個App的所有資源的。因此，儘管一個App的所有組件都被銷毀了，這個App也不會自動終結。

當系統處於資源緊缺的時候，Dalvik負責決定哪一個進程要被Kill掉。那到底是基於什麼去決定是哪一個進程呢？

基於App的可見度和它的組件運行情況，系統對進程進行分級處理。也就是說，低層級進程在進階別進程之前被Kill掉。

下面是進程的各個層級：

Foreground

App在前台有可見的組件，或者有一個Service與其他進程中的某個可見的Activity處於綁定狀態，或者BroadcastReceiver正在運行。

Visible

App有一個部分可見的組件。

Service

Service處於運行狀態，但是並沒有和一個可見的組件綁定。

Background

不可見的Activity。

Empty

沒有活躍組件的進程。空進程之所以存在，就是為了改善App的啟動次數，但是它們也會第一個被Kill掉。

參考資料http://developer.android.com/guide/components/processes-and-threads.html#Lifecycle