學(xué)習(xí)Android最好的途徑當(dāng)然是強(qiáng)大的官方文檔了，其中在Processes and Threads一節(jié)中對于進(jìn)程生命周期淘汰優(yōu)先級，有著詳細(xì)的介紹。就不給大家轉(zhuǎn)帖了，直接放譯文吧，如下：

Android系統(tǒng)會盡量維持進(jìn)程的存在，但畢竟資源有限，當(dāng)系統(tǒng)資源告急的時候會淘汰一部分進(jìn)程。淘汰順序的憑據(jù)就是系統(tǒng)進(jìn)程的優(yōu)先級了，優(yōu)先級越高越不容易被殺死，反之亦然。系統(tǒng)總共為進(jìn)程分了五個優(yōu)先級，如下

一、前臺進(jìn)程（進(jìn)程滿足如下任一條件即為前臺進(jìn)程）：

1. 擁有 一個執(zhí)行了onresume方法正在與用戶交互（獲得焦點(diǎn)）的Activity
2. 擁有一個service，這個Service跟正在與用戶交互的Activity進(jìn)行了綁定
3. 擁有一個Service，這個Service調(diào)用了startForeground()方法
4. 擁有一個正在執(zhí)行onCreate()、onStart()或者onDestroy()方法中的任意一個的Service
5. 擁有一個正在執(zhí)行onReceive方法的BroadcastReceiver

二、可見進(jìn)程：

1. 擁有一個執(zhí)行了onPause方法，但仍然可見的Activity
2. 擁有一個Service，這個Service跟一個可見的或前臺的Activity綁定了

三、服務(wù)進(jìn)程：

擁有一個通過startService方法啟動的Service的進(jìn)程

四、后臺進(jìn)程：

擁有一個后臺Activity（onStop方法被調(diào)用）的進(jìn)程

五、空進(jìn)程：

沒有擁有任何活動的應(yīng)用組件的進(jìn)程，也就是沒有任何Service和Activity在運(yùn)行

另外，還有一些需要補(bǔ)充的，當(dāng)一個進(jìn)程滿足多個進(jìn)程條件時，當(dāng)然是取優(yōu)先級更高的為準(zhǔn)，比如一個進(jìn)程同時滿足前臺進(jìn)程和服務(wù)進(jìn)程的條件，這個進(jìn)程就是個前臺進(jìn)程，這點(diǎn)很好理解。另外，進(jìn)程的優(yōu)先級也不是一成不變的，而且有時候會隨著一些相關(guān)的因素而發(fā)生改變；比如，某進(jìn)程A滿足前臺進(jìn)程的第二個條件，進(jìn)程A擁有一個service，這個Service跟正在與用戶交互的Activity進(jìn)行了綁定；當(dāng)這個Activity變成可見狀態(tài)了，進(jìn)程A便不再滿足前臺進(jìn)程的條件，進(jìn)而因滿足可見進(jìn)程的第二個條件，進(jìn)程A變成了可見進(jìn)程?？傊谡莆樟嘶靖拍钪?，需要細(xì)心的分析具體的情況，方能得出正確的判斷。

進(jìn)程優(yōu)先級的額外說明

1. 系統(tǒng)會賦予進(jìn)程盡可能高的優(yōu)先級. 例如一個進(jìn)程既包含已啟動的service, 也包含前臺activity, 則這個進(jìn)程會被視為前臺進(jìn)程.

2. 由于組件之間的依賴性, 進(jìn)程的優(yōu)先級有可能被提高. 假如進(jìn)程A服務(wù)于進(jìn)程B, 則進(jìn)程A的優(yōu)先級不能低于進(jìn)程B. 比如, 進(jìn)程A的ContentProvider組件正在服務(wù)于進(jìn)程B的某個組件, 或者進(jìn)程A的service組件和進(jìn)程B的某個組件綁定等, 這些情況下, 進(jìn)程A的優(yōu)先級都不會低于進(jìn)程B(如果按照優(yōu)先級規(guī)則, 進(jìn)程A的優(yōu)先級確實(shí)低于進(jìn)程B, 則系統(tǒng)會選擇提高進(jìn)程A的優(yōu)先級到和進(jìn)程B相同).

3. 由于服務(wù)進(jìn)程的優(yōu)先級高于后臺進(jìn)程, 因此如果activity需要執(zhí)行耗時操作, 最好還是啟動一個service來完成. 當(dāng)然, 在activity中啟動子線程完成耗時操作也可以, 但是這樣做的缺點(diǎn)在于, 一旦activity不再可見, activity所在的進(jìn)程成為后臺進(jìn)程, 而內(nèi)存不足時后臺進(jìn)程隨時都有可能被系統(tǒng)殺死(但是啟動service完成耗時操作會帶來數(shù)據(jù)交互的問題, 比如耗時操作需要實(shí)時更新UI控件的狀態(tài)的話, service就不是一個好的選擇). 基于同樣的考慮, 在BroadcastReceiver中也不應(yīng)該執(zhí)行耗時操作, 而應(yīng)該啟動service來完成(當(dāng)然, BroadcastReceiver的生命周期過于短暫, 也決定了不能在其中執(zhí)行耗時操作).

最新評論