android進程管理機制

① android後台進程保活方案

思想： 使用 Linux 中的 fork 機制創建 Native 進程，在 Native 進程中監控主進程的存活，當主進程掛掉後，在 Native 進程中立即對主進程進行拉活。

原理： 在 Android 中所有進程和系統組件的生命周期受 ActivityManagerService 的統一管理。Android5.0以下通過 Linux 的 fork 機制創建的進程為純 Linux 進程，其生命周期不受 Android 的管理。

該方案主要適用於 Android5.0 以下版本手機。

該方案不受 forceclose 影響，被強制停止的應用依然可以被拉活，在 Android5.0 以下版本拉活效果非常好。
詳情

對於 Android5.0 以上手機，系統雖然會將native進程內的所有進程都殺死，這里其實就是系統「依次」殺死進程時間與拉活邏輯執行時間賽跑的問題，如果可以跑的比系統邏輯快，依然可以有效拉起。在 某些 Android 5.0 以上機型有效。
詳情

https://github.com/Marswin/MarsDaemon

作者5.0以下系統用一個java進程和一個fork出來的純native進程雙管道互鎖監聽對方的狀態，無論哪個被殺後都拉起第三個進程，第三個進程來拉活常駐進程，實現拉活。
5.0以上同一進程組的進程會被同時殺死，所以5.0以上使用雙java進程在native層互鎖文件實現監聽，但任務管理器會在短時間內殺死所有進程，只能用反射提前初始化pacel，在進程被殺的時候和系統搶那幾十毫秒的時間發送一個拉活的廣播。用4個文件來讓兩個進程實現互鎖來做監聽，但實際效果很一般，測試了幾個5.0以上的國產機型都不行，效果是根本監聽不到進程被殺，目測原因是當任務管理器查殺進程的時候將所有的進程都掛起了，隨後全部殺掉，並在一段時間內禁止進程啟動。

PersistedJobService.java

BootReceiver.java靜態注冊BroadcastReceiver

注冊，開機，網路切換、拍照、拍視頻時候，利用系統產生的廣播也能喚醒app，不過Android N已經將這三種廣播取消了

常用的拉活許可權

BackgroundService.java
WakeLock

作為前台應用運行，提高應用存活幾率

service被關掉後自動啟動

START_STICKY
如果系統在onStartCommand返回後被銷毀，系統將會重新創建服務並依次調用onCreate和onStartCommand（注意：根據測試Android2.3.3以下版本只會調用onCreate根本不會調用onStartCommand，Android4.0可以辦到），這種相當於服務又重新啟動恢復到之前的狀態了）。

START_NOT_STICKY
如果系統在onStartCommand返回後被銷毀，如果返回該值，則在執行完onStartCommand方法後如果Service被殺掉系統將不會重啟該服務。

START_REDELIVER_INTENT
START_STICKY的兼容版本，不同的是其不保證服務被殺後一定能重啟。

service注冊，許可權設置為高優先順序

KeepAliveService.java
注冊，在新的獨立進程內啟動，適用5.0以下的原生系統，5.0以上同樣會被殺死

他的局限性在於：
第一，用戶會在系統設置的賬戶列表裡面看到一個不認識的賬戶；
第二，同步的事件間隔是有限制的，最短1分鍾，見源碼，如果小雨60秒，置為60秒。而且各種國產機怎麼改的源碼我們未可知，是不是都能用仍然未可知；
第三，很致命，某些手機比如note3需要手動設置賬戶，你如何騙你的用戶給你手動設置賬戶完了之後不卸載你；
第四，也很致命，必須聯網！google提供這個組件是讓你同步賬戶信息，不聯網你同步個鬼，我們要保活，可以不聯網不做事，但是不能不聯網就死

集成三方推送平台sdk，友盟極光等

② Android 守護進程的實現方式

在我們進行應用開發時，會遇到上級的各種需求，其中有一條 剛需： 後台保活 ，更有甚者：

我要我們的應用永遠活在用戶的手機後台不被殺死 —— 這都 TM 的扯淡

除了系統級別的應用能持續運行，所有三方程序都有被殺死的那一天！當然 QQ/微信/陌陌 等會好一些，因為他們已經深入設備的 心 ；
我們能做的只是通過各種手段盡量讓我們的程序在後台運行的時間長一些，或者在被幹掉的時候，能夠重新站起來，而且這個也不是每次都有效的，也是不能在所有的設備的上都有效的；要做到後台進程保活，我們需要做到兩方便：

要實現實現上邊所說，通過下邊幾點來實現，首先我們需要了解下進程的優先順序劃分：

Process Importance 記錄在 ActivityManager.java 類中:

了解進程優先順序之後，我們還需要知道一個進程回收機制的東西；這里參考 AngelDevil 在博客園上的一篇文章:

Android 的 Low Memory Killer 基於 Linux 的 OOM 機制，在 Linux 中，內存是以頁面為單位分配的，當申請頁面分配時如果內存不足會通過以下流程選擇bad進程來殺掉從而釋放內存：

在 Low Memory Killer 中通過進程的 oom_adj 與佔用內存的大小決定要殺死的進程， oom_adj 越小越不容易被殺死；
Low Memory Killer Driver 在用戶空間指定了一組內存臨界值及與之一一對應的一組 oom_adj 值，當系統剩餘內存位於內存臨界值中的一個范圍內時，如果一個進程的 oom_adj 值大於或等於這個臨界值對應的 oom_adj 值就會被殺掉。

下邊是表示 Process State (即老版本里的 OOM_ADJ )數值對照表，數值越大，重要性越低，在新版SDK中已經在 android 層去除了小於0的進程狀態

Process State （即老版本的 OOM_ADJ ）與 Process Importance 對應關系，這個方法也是在 ActivityManager.java 類中，有了這個關系，就知道可以知道我們的應用處於哪個級別，對於我們後邊優化有個很好地參考

一般情況下，設備端進程被幹掉有一下幾種情況

由以上分析，我們可以可以總結出，如果想提高我們應用後台運行時間，就需要提高當前應用進程優先順序，來減少被殺死的概率

分析了那麼多，現在對Android自身後台進程管理，以及進程的回收也有了一個大致的了解，後邊我們要做的就是想盡一切辦法去提高應用進程優先順序，降低進程被殺的概率；或者是在被殺死後能夠重新啟動後台守護進程

第一種方式就是利用系統漏洞，使用 startForeground() 將當前進程偽裝成前台進程，將進程優先順序提高到最高(這里所說的最高是服務所能達到的最高，即1);

這種方式在 7.x 之前都是很好用的，QQ、微信、IReader、Keep 等好多應用都是用的這種方式實現；因為在7.x 以後的設備上，這種偽裝前台進程的方式也會顯示出來通知欄提醒，這個是取消不掉的，雖然 Google 現在還沒有對這種方式加以限制，不過這個已經能夠被用戶感知到了，這種方式估計也用不了多久了

下邊看下實現方式，這邊這個 VMDaemonService 就是一個守護進程服務，其中在服務的 onStartCommand() 方法中調用 startForeground() 將服務進程設置為前台進程，當運行在 API18 以下的設備是可以直接設置，API18 以上需要實現一個內部的 Service ，這個內部類實現和外部類同樣的操作，然後結束自己；當這個服務啟動後就會創建一個定時器去發送廣播，當我們的核心服務被幹掉後，就由另外的廣播接收器去接收我們守護進程發出的廣播，然後喚醒我們的核心服務；

當我們啟動這個守護進程的時候，就可以使用以下 adb 命令查看當前程序的進程情況（需要 adb shell 進去設備），
為了等下區分進程優先順序，我啟動了一個普通的後台進程，兩外兩個一個是我們啟動的守護進程，一個是當前程序的核心進程，可以看到除了後台進程外，另外兩個進程都帶有 isForeground=true 的屬性：

然後我們可以用下邊的命令查看 ProcessID

有了 ProcessID 之後，我們可以根據這個 ProcessID 獲取到當前進程的優先順序狀態 Process State ，對應 Linux 層的 oom_adj
可以看到當前核心進程的級別為 0 ，因為這個表示當前程序運行在前台 UI 界面，守護進程級別為 1 ，因為我們利用漏洞設置成了前台進程，雖然不可見，但是他的級別也是比較高的，僅次於前台 UI 進程，然後普通後台進程級別為 4 ；當我們退到後台時，可以看到核心進程的級別變為 1 了，這就是因為我們利用 startForeground() 將進程設置成前台進程的原因，這樣就降低了進程被系統回收的概率了；

可以看到這種方式確實能夠提高進程優先順序，但是在一些國產的設備上還是會被殺死的，比我我測試的時候小米點擊清空最近運行的應用進程就別幹掉了；當把應用加入到設備白名單里就不會被殺死了，微信就是這樣，人家直接裝上之後就已經在白名單里了，我們要做的就是在用戶使用中引導他們將我們的程序設置進白名單，將守護進程和白名單結合起來，這樣才能保證我們的應用持續或者

Android系統在5.x以上版本提供了一個 JobSchele 介面，系統會根據自己實現定時去調用改介面傳遞的進程去實現一些操作，而且這個介面在被強制停止後依然能夠正常的啟動；不過在一些國產設備上可能無效，比如小米；
下邊是 JobServcie 的實現：

我們要做的就是在需要的時候調用 JobSchele 的 schele 來啟動任務；剩下的就不需要關心了， JobSchele 會幫我們做好，下邊就是我這邊實現的啟動任務的方法：

在實現 Service 類時，將 onStartCommand() 返回值設置為 START_STICKY ，利用系統機制在 Service 掛掉後自動拉活；不過這種方式只適合比較原生一些的系統，像小米，華為等這些定製化比較高的第三方廠商，他們都已經把這些給限制掉了；

這種方式在以下兩種情況無效：

事事沒有絕對，萬物總有一些漏洞，就算上邊的那些方式不可用了，後邊肯定還會出現其他的方式；我們不能保證我們的應用不死，但我們可以提高存活率；

其實最好的方式還是把程序做好，讓程序本身深入人心，別人喜歡你了，就算你被幹掉了，他們也會主動的把你拉起來，然後把你加入他們的白名單，然後我們的目的就實現了不是 😁 ~

③ android中handler和service的區別是什麼

任務、進程和線程
關於Android中的組件和應用，之前涉及，大都是靜態的概念。而當一個應用運行起來，就難免會需要關心進程、線程這樣的概念。在Android中，組件的動態運行，有一個最與眾不同的概念，就是Task，翻譯成任務，應該還是比較順理成章的。
Task的介入，最主要的作用，是將組件之間的連接，從進程概念的細節中剝離出來，可以以一種不同模型的東西進行配置，在很多時候，能夠簡化上層開發人員的理解難度，幫助大家更好的進行開發和配置。

任務
在SDK中關於Task（guide/topics/fundamentals.html#acttask），有一個很好的比方，說，Task就相當於應用（application）的概念。在開發人員眼中，開發一個Android程序，是做一個個獨門獨戶的組件，但對於一般用戶而言，它們感知到的，只是一個運行起來的整體應用，這個整體背後，就是Task。
Task，簡單的說，就是一組以棧的模式聚集在一起的Activity組件集合。它們有潛在的前後驅關聯，新加入的Activity組件，位於棧頂，並僅有在棧頂的Activity，才會有機會與用戶進行交互。而當棧頂的 Activity完成使命退出的時候，Task會將其退棧，並讓下一個將跑到棧頂的Activity來於用戶面對面，直至棧中再無更多 Activity，Task結束。

事件 Task棧
點開Email應用，進入收件箱（Activity A） A
選中一封郵件，點擊查看詳情（Activity B） AB
點擊回復，開始寫新郵件（Activity C） ABC
寫了幾行字，點擊選擇聯系人，進入選擇聯系人界面（Activity D） ABCD
選擇好了聯系人，繼續寫郵件 ABC
寫好郵件，發送完成，回到原始郵件 AB
點擊返回，回到收件箱 A
退出Email程序 null

如上表所示，是一個實例。從用戶從進入郵箱開始，到回復完成，退出應用整個過程的Task棧變化。這是一個標準的棧模式，對於大部分的狀況，這樣的Task 模型，足以應付，但是，涉及到實際的性能、開銷等問題，就會變得殘酷許多。比如，啟動一個瀏覽器，在Android中是一個比較沉重的過程，它需要做很多初始化的工作，並且會有不小的內存開銷。但與此同時，用瀏覽器打開一些內容，又是一般應用都會有的一個需求。設想一下，如果同時有十個運行著的應用（就會對應著是多個Task），都需要啟動瀏覽器，這將是一個多麼殘酷的場面，十個Task棧都堆積著很雷同的瀏覽器Activity，是多麼華麗的一種浪費啊。於是你會有這樣一種設想，瀏覽器Activity，可不可以作為一個單獨的Task而存在，不管是來自那個Task的請求，瀏覽器的Task，都不會歸並過去。這樣，雖然瀏覽器Activity本身需要維系的狀態更多了，但整體的開銷將大大的減少，這種舍小家為大家的行為，還是很值得歌頌的。
如此值得歌頌的行為，Android當然會舉雙手支持的。在Android中，每一個Activity的Task模式，都是可以由Activity提供方（通過配置文件...）和Activity使用方（通過Intent中的flag信息...）進行配置和選擇。當然，使用方對Activity的控制力，是限定在提供方允許的范疇內進行，提供方明令禁止的模式，使用方是不能夠越界使用的。
在SDK中（guide/topics/fundamentals.html#acttask），將兩者實現Task模式配置的方式，寫的非常清晰了，我再很絮叨挑選一些來解釋一下（完整可配置項，一定要看SDK，下面只是其中常用的若干項...）。提供方對組件的配置，是通過配置文件（Manifest）<activity>項來進行的，而調用方，則是通過Intent對象的flag進行抉擇的。相對於標準的Task棧的模式，配置的主要方向有兩個：一則是破壞已有棧的進出規則，或樣式；另一則是開辟新Task棧完成本應在同一Task棧中完成的任務。
對於應用開發人員而言，<activity>中的launchMode屬性，是需要經常打交道的。它有四種模式："standard", "singleTop", "singleTask", "singleInstance"。
standard模式，是默認的也是標準的Task模式，在沒有其他因素的影響下，使用此模式的Activity，會構造一個Activity的實例，加入到調用者的Task棧中去，對於使用頻度一般開銷一般什麼都一般的Activity而言，standard模式無疑是最合適的，因為它邏輯簡單條理清晰，所以是默認的選擇。
而singleTop模式，基本上於standard一致，僅在請求的Activity正好位於棧頂時，有所區別。此時，配置成singleTop的Activity，不再會構造新的實例加入到Task棧中，而是將新來的Intent發送到棧頂Activity中，棧頂的Activity可以通過重載onNewIntent來處理新的Intent（當然，也可以無視...）。這個模式，降低了位於棧頂時的一些重復開銷，更避免了一些奇異的行為（想像一下，如果在棧頂連續幾個都是同樣的Activity，再一級級退出的時候，這是怎麼樣的用戶體驗...），很適合一些會有更新的列表Activity展示。一個活生生的實例是，在 Android默認提供的應用中，瀏覽器（Browser）的書簽Activity（BrowserBookmarkPage），就用的是singleTop。
singleTop模式，雖然破壞了原有棧的邏輯（復用了棧頂，而沒有構造新元素進棧...），但並未開辟專屬的Task。而singleTask，和singleInstance，則都採取的另闢Task的蹊徑。標志為singleTask的Activity，最多僅有一個實例存在，並且，位於以它為根的Task中。所有對該Activity的請求，都會跳到該Activity的Task中展開進行。singleTask，很象概念中的單件模式，所有的修改都是基於一個實例，這通常用在構造成本很大，但切換成本較小的Activity中。在Android源碼提供的應用中，該模式被廣泛的採用，最典型的例子，還是瀏覽器應用的主Activity（名為Browser...），它是展示當前tab，當前頁面內容的窗口。它的構造成本大，但頁面的切換還是較快的，於 singleTask相配，還是挺天作之合的。
相比之下，singleInstance顯得更為極端一些。在大部分時候singleInstance與singleTask完全一致，唯一的不同在於，singleInstance的Activity，是它所在棧中僅有的一個Activity，如果涉及到的其他Activity，都移交到其他Task中進行。這使得singleInstance的Activity，像一座孤島，徹底的黑盒，它不關注請求來自何方，也不計較後續由誰執行。在Android默認的各個應用中，很少有這樣的Activity，在我個人的工程實踐中，曾嘗試在有道詞典的快速取詞Activity中採用過，是因為我覺得快速取詞入口足夠方便（從notification中點選進入），並且會在各個場合使用，應該做得完全獨立。
除了launchMode可以用來調配Task，<activity>的另一屬性taskAffinity，也是常常被使用。taskAffinity，是一種物以類聚的思想，它傾向於將taskAffinity屬性相同的Activity，扔進同一個Task中。不過，它的約束力，較之launchMode而言，弱了許多。只有當<activity>中的allowTaskReparen ting設置為true，抑或是調用方將Intent的flag添加FLAG_ACTIVITY_NEW_TASK屬性時才會生效。如果有機會用到Android的Notification機制就能夠知道，每一個由notification進行觸發的Activity，都必須是一個設成FLAG_ACTIVITY_NEW_TASK的Intent來調用。這時候，開發者很可能需要妥善配置taskAffinity屬性，使得調用起來的Activity，能夠找到組織，在同一taskAffinity的Task中進行運行。

進程
在大多數其他平台的開發中，每個開發人員對自己應用的進程模型都有非常清晰的了解。比如，一個控制台程序，你可以想見它從main函數開始啟動一個進程，到 main函數結束，進程執行完成退出；在UI程序中，往往是有一個消息循環在跑，當接受到Exit消息後，退出消息循環結束進程。在該程序運行過程中，啟動了什麼進程，和第三方進程進行通信等等操作，每個開發者都是心如明鏡一本帳算得清清楚楚。進程邊界，在這里，猶如國界一般，每一次穿越都會留下深深的印跡。
在Android程序中，開發人員可以直接感知的，往往是Task而已。倍感清晰的，是組件邊界，而進程邊界變得難以琢磨，甚至有了進程託管一說。Android中不但剝奪了手工鍛造內存權力，連手工處置進程的權責，也毫不猶豫的獨佔了。
當然，Android隱藏進程細節，並不是刻意為之，而是自然而然水到渠成的。如果，我們把傳統的應用稱為面向進程的開發，那麼，在Android中，我們做得就是面向組件的開發。從前面的內容可以知道，Android組件間的跳轉和通信，都是在第三方介入的前提下進行，正由於這種介入，使得兩個組件一般不會直接發生聯系（於Service的通信，是不需要第三方介入的，因此Android把它全部假設成為穿越進程邊界，統一基於RPC來通信，這樣，也是為了掩蓋進程細節...），其中是否穿越進程邊界也就變得不重要。因此，如果這時候，還需要開發者關注進程，就會變得很奇怪，很費解，乾脆，Android將所有的進程一並託管去了，上層無須知道進程的生死和通信細節。
在Android的底層，進程構造了底部的一個運行池，不僅僅是Task中的各個Activity組件，其他三大組件Service、Content Provider、Broadcast Receiver，都是寄宿在底層某個進程中，進行運轉。在這里，進程更像一個資源池（概念形如線程池，上層要用的時候取一個出來就好，而不關注具體取了哪一個...），只是為了承載各個組件的運行，而各個組件直接的邏輯關系，它們並不關心。但我們可以想像，為了保證整體性，在默認情況下，Android肯定傾向於將同一Task、同一應用的各個組件扔進同一個進程內，但是當然，出於效率考慮，Android也是允許開發者進行配置。
在Android中，整體的<application>（將影響其中各個組件...）和底下各個組件，都可以設置<process>屬性，相同<process>屬性的組件將扔到同一個進程中運行。最常見的使用場景，是通過配置<application>的process屬性，將不同的相關應用，塞進一個進程，使得它們可以同生共死。還有就是將經常和某個Service組件進行通信的組件，放入同一個進程，因為與Service通信是個密集操作，走的是RPC，開銷不小，通過配置，可以變成進程內的直接引用，消耗頗小。
除了通過<process>屬性，不同的組件還有一些特殊的配置項，以Content Provider為例（通過<provider>項進行配置...）。<provider>項有一個mutiprocess的屬性，默認值為false，這意味著Content Provider，僅會在提供該組件的應用所在進程構造一個實例，第三方想使用就需要經由RPC傳輸數據。這種模式，對於構造開銷大，數據傳輸開銷小的場合是非常適用的，並且可能提高緩存的效果。但是，如果是數據傳輸很大，抑或是希望在此提高傳輸的效率，就需要將mutiprocess設置成true，這樣，Content Provider就會在每一個調用它的進程中構造一個實例，避免進程通信的開銷。
既然，是Android系統幫助開發人員託管了進程，那麼就需要有一整套紛繁的演算法去執行回收邏輯。Android中各個進程的生死，和運行在其中的各個組件有著密切的聯系，進程們依照其上組件的特點，被排入一個優先順序體系，在需要回收時，從低優先順序到高優先順序回收。Android進程共分為五類優先順序，分別是：Foreground Process, Visible Process, Service Process, Background Process, Empty Process。顧名思義不難看出，這說明，越和用戶操作緊密相連的，越是正與用戶交互的，優先順序越高，越難被回收。具體詳情，參見：guide/topics/fundamentals.html#proclife。
有了優先順序，還需要有良好的回收時機。回收太早，緩存命中概率低可能引起不斷的創造進程銷毀進程，池的優勢盪然無存；回收的太晚，整體開銷大，系統運行效率降低，好端端的法拉利可能被糟蹋成一枚QQ老爺車。Android的進程回收，最重要的是考量內存開銷，以及電量等其他資源狀況，此外每個進程承載的組件數量、單個應用開辟的進程數量等數量指標，也是作為衡量的一個重要標識。另外，一些運行時的時間開銷，也被嚴格監控，啟動慢的進程會很被強行kill掉。Android會定時檢查上述參數，也會在一些很可能發生進程回收的時間點，比如某個組件執行完成後，來做回收的嘗試。
從用戶體驗角度來看，Android的進程機制，會有很可喜的一面，有的程序啟動速度很慢，但是在資源充沛的前提下，你反復的退出再使用，則啟動變得極其快速（進程沒死，只是從後台弄到了前台），這就是拜進程託管所賜的。當然，可喜的另一面就是可悲了，Android的託管演算法，還時不時的展現其幼稚的一面，明明用戶已經明顯感覺到操作系統運行速度下降了，打開任務管理器一看，一票應用還生龍活虎的跳躍著，必須要手動幫助它們終結生命找到墳墓，這使得任務管理器基本成為Android的裝機必備軟體。
從開發角度上來看，Android這套進程機制，解放了開發者的手腳。開發人員不需要處心積慮的構造一個後台進程偷偷默默監聽某個時間，並嘗試用各種各樣的守護手段，把自己的進程鍛造的猶如不死鳥一輝一般，進程生死的問題，已經原理了普通開發人員需要管理的范疇內。但同時，於GC和人肉內存管理的爭議一樣，所有開發人員都不相信演算法能比自己做得效率更高更出色。但我一直堅信一點，所有效率的優勢都會隨著演算法的不斷改良硬體的不斷提升而消失殆盡，只有開發模式的簡潔不會隨時間而有任何變化。

組件生命周期
任何架構上的變化，都會引起上層開發模式的變化，Android的進程模型，雖然使開發者不再需要密切關注進程的創建和銷毀的時機，但仍然需要關注這些時間點對組件的影響。比如，你可能需要在進程銷毀之前，將寫到內存上的內容，持久化到硬碟上，這就需要關注進程退出前發生的一些事件。
在Android中，把握這些時間點，就必須了解組件生命周期（Components Lifecycles）。所謂組件的生命在周期，就是在組件在前後台切換、被用戶創建退出、被系統回收等等事件發生的時候，會有一些事件通知到對應組件上，開發人員可以選擇性的處理這些事件在對應的時間點上來完成一些附加工作。
除Content Provider，其他組件都會有生命周期的概念，都需要依照這個模型定時定點處理一些狀況，全部內容參見：guide/topics/fundamentals.html#lcycles。在這里，擒賊先擒王，還是拿Activity出來作楷模。

繼續偷圖，來自SDK。一個自然的Activity生命旅途，從onCreate開始，到onDestroy消亡。但月有陰晴圓缺組件有禍福旦夕，在系統需要的時候且組件位於後台時，所在的進程隨時可能為國捐軀被回收，這就使得知道切入後台這個事情也變得很重要。
當組件進入棧頂，與用戶開始交互，會調用onResume函數，類似，當退出棧頂，會有onPause函數被呼喚。onResume和onPause可以處理很多事情，最常規的，就是做一些文件或設置項的讀寫工作。因為，在該組件不再前台運行的時候，可能別的組件會需要讀寫同樣一份文件和設置，如果不再onResume做刷新工作，用的可能就是一份臟數據了（當然，具體情況，還需要具體分析，如果文件不會被多頭讀寫，可以放到onCreate裡面去做讀工作）。
除了前述切入後台會被其他組件騷擾的問題，另外，死無定因也是件很可怕的事情。在Android中，組件都有兩種常見的死法，一種是自然消亡，比如，棧元素ABC，變成AB了，C組件就自然消亡了。這種死發輕如鴻毛，不需要額外關心。但另一種情況，就是被系統回收，那是死的重如泰山，為國捐軀嘛。
但這種捐軀的死法，對用戶來說，比較費解。想像一下，一款游戲，不能存檔，你一直玩啊玩，三天三夜沒合眼，這時候你mm打來電話鼓勵一下，你精神抖擻的准備再接再厲，卻發現你的游戲進程，在切入後台之後，被系統回收了，一夜回到解放前三天努力成為一場泡影，你會不會想殺做游戲的人，會不會會不會會不會，一定會嘛。這時候，如果沒有Activity生命周期這碼事，游戲程序員一定是被冤死的，成了Android的替罪羊。但是，Android的組件是有生命周期的， 如果真的發生這樣情況，不要猶豫，去殺開發的程序員吧。
為了逃生，程序員們有一塊免死金牌，那就是Android的state機制。所謂state，就是開發人員將一些當前運行的狀態信息存放在一個Bundle對象裡面，這是一個可序列化鍵值對集合。如果該Activity組件所處的進程需要回收，Android核心會將其上Activity組件的Bundle對象持久化到磁碟上，當用戶回到該Activity時候，系統會重新構造該組件，並將持久化到磁碟上的Bundle對象恢復。有了這樣的持久化的狀態信息，開發人員可以很好的區分具體死法，並有機會的使得死而復生的Activity恢復到死前狀態。開發者應該做的，是通過onSaveInstanceState函數把需要維系的狀態信息（在默認的狀態下，系統控制項都會自己保存相關的狀態信息，比如TextView，會保存當前的Text信息，這都不需要開發人員擔心...），寫入到Bundle對象，然後在onRestoreInstanceState函數中讀取並恢復相關信息（onCreate，onStart，也都可以處理...）。

線程
讀取數據，後台處理，這些猥瑣的伙計，自然少不了線程的參與。在Android核心的調度層面，是不屑於考量線程的，它關注的只有進程，每一個組件的構造和處理，都是在進程的主線程上做的，這樣可以保證邏輯的足夠簡單。多線程，往往都是開發人員需要做的。
Android的線程，也是通過派生Java的Thread對象，實現Run方法來實現的。但當用戶需要跑一個具有消息循環的線程的時候，Android有更好的支持，來自於Handler和Looper。Handler做的是消息的傳送和分發，派生其handleMessage函數，可以處理各種收到的消息，和win開發無異。Looper的任務，則是構造循環，等候退出或其他消息的來臨。在Looper的SDK頁面，有一個消息循環線程實現的標准範例，當然，更為標準的方式也許是構造一個HandlerThread線程，將它的Looper傳遞給Handler。
在Android中，Content Provider的使用，往往和線程掛鉤，誰讓它和數據相關呢。在前面提到過，Content Provider為了保持更多的靈活性，本身只提供了同步調用的介面，而由於非同步對Content Provider進行增刪改查是一個常做操作，Android通過AsyncQueryHandler對象，提供了非同步介面。這是一個Handler的子類，開發人員可以調用startXXX方法發起操作，通過派生onXXXComplete方法，等待執行完畢後的回調，從而完成整個非同步調用的流程，十分的簡約明了。

實現
整個任務、進程管理的核心實現，盡在ActivityManagerService中。上一篇說到，Intent解析，就是這個ActivityManagerService來負責的，其實，它是一個很名不副實的類，因為雖然名為Activity的Manager Service，但它管轄的范圍，不只是Activity，還有其他三類組件，和它們所在的進程。
在ActivityManagerService中，有兩類數據結構最為醒目，一個是ArrayList，另一個是HashMap。 ActivityManagerService有大量的ArrayList，每一個組件，會有多個ArrayList來分狀態存放。調度工作，往往就是從一個ArrayList裡面拿出來，找個方法調一調，然後扔到另一個ArrayList裡面去，當這個組件沒對應的ArrayList放著的時候，說明它離死不遠了。HashMap，是因為有組件是需要用名字或Intent信息做定位的，比如Content Provider，它的查找，都是依據Uri，有了HashMap，一切都順理成章了。
ActivityManagerService用一些名曰xxxRecord的數據結構，來表達各個存活的組件。於是就有了，HistoryRecord（保存Activity信息的，之所以叫History，是相對Task棧而言的...），ServiceRecord，BroadcastRecord，ContentProviderRecord，TaskRecord，ProcessRecord，等等。
值得注意的，是TaskRecord，我們一直再說，Task棧這樣的概念，其實，真實的底層，並不會在TaskRecord中，維系一個Activity 的棧。在ActivityManagerService中，各個任務的Activity，都以HistoryRecord的形式，集中存放在一個 ArrayList中，每個HistoryRecord，會存放它所在TaskRecord的引用。當有一個Activity，執行完成，從概念上的 Task棧中退出，Android是通過從當前HistoryRecord位置往前掃描同一個TaskRecord的HistoryRecord來完成的。這個設計，使得上層很多看上去邏輯很復雜的Task體系，在實現變得很統一而簡明，值得稱道。
ProcessRecord，是整個進程託管實現的核心，它存放有運行在這個進程上，所有組件的信息，根據這些信息，系統有一整套的演算法來決議如何處置這個進程，如果對回收演算法感興趣，可以從ActivityManagerService的trimApplications函數入手來看。
對於開發者來說，去了解這部分實現，主要是可以幫助理解整個進程和任務的概念，如果覺得這塊理解的清晰了，就不用去碰ActivityManagerService這個龐然大物了。

================
這是轉載的 ，感覺比一樓說的好

=============
一下是自己的

服務（Service）需要配置 才能使用
線程 使用就不說了
hanler ，是用來進行消息隊列的一個東東，handler 可以用來更新控制項的顯示 ，以及線程之間的通信，
service只能啟動後台，屬於應用組件之一

④ android進程管理機制

Android系統與其他操作系統有個很不一樣的地方，就是其他操作系統盡可能移除不再活動的進程，從而盡可能保證多的內存空間，而Android系統卻是反其道而行之，盡可能保留進程。Android這樣設計有什麼優勢呢？又是通過怎樣的方法來管理這些被保留的進程的呢？Android用戶又該如何正確使用手機從而更好發揮Android系統所特有的優勢呢？本文將一一為您解開這些謎團。

      本文的主要內容如下：

一、Android進程管理的特殊設計

       Linux系統對進程的管理方式是一旦進程活動停止，系統就會結束該進程。盡管Android基於Linux Kernel，但在進程管理上，卻採取了另外一種獨特的設計：當進程活動停止時，系統並不會立刻結束它，而是會盡可能地將該進程保存在內存中，在以後的某個時間，一旦需要該進程，系統就會立即打開它，而不用再做一些初始化操作。只有當剩餘內存不夠用了，為了維持新開啟的進程或者比較重要的進程的正常運行，系統才會選擇性地殺掉一些不重要的內存，騰出內存空間來，所以Android系統永遠不會有內存不足的提示。

二、Android獨特進程管理設計的好處

      Android這種獨特的設計，也正是Android標榜的優勢之一，這有兩個好處：

  1、最大限度地提高內存的使用率。

       比如，你的內存是8G，如果每次使用完某個進程就殺掉，那麼被使用的內存基本上會始終保持在某個值，比如4G以內，那麼內存的使用率就總是保存在50%以內，剩餘的4G內存形同虛設，發揮用處的機會非常少。而Android的這種設計，就可以做到有多少內存就用多少內存，盡可能大地提高內存使用率。同樣比如有8G內存，使用完的進程仍保留在內存中，累積下來，被使用的內存就盡可能地會接近8G。

  2、提高再次啟動時的啟動速度

       被駐留在內存中不再活動的進程（後台進程或空進程，後面會再講到），很多是經常需要使用的，當再次使用該進程的時候，系統立即打開它，而不需要再重新初始化。例如，我們常用的瀏覽器，當暫時不再使用時，按下Home鍵或Back鍵，瀏覽器進程就變成了不再活動的進程。如果下次又要使用了，點擊多任務鍵，在最近使用應用列表中點擊瀏覽器即可，瀏覽器界面仍然保持著退出前的界面。但如果退出時把該進程移除了，那麼再次使用時，就需要重新初始化，然後進入該應用，這往往會花費不少的時間。

三、Android進程的五個等級

        Android系統將盡量長時間地保持應用進程，但為了新建進程或運行更重要的進程，最終需要移除舊進程來回收內存。為了確定保留或終止哪些進程，系統會根據進程中正在運行的組件以及這些組件的狀態，將每個進程放入「重要性層次結構」中。必要時，系統會首先消除重要性最低的進程，然後是重要性略遜的進程，以此類推，以回收系統資源。該「重要性層級結構」將進程分為了五個等級：

  1、前台進程（foreground）

       前台進程是指那些有組件正和用戶進行交互的應用程序的進程，也稱為Active進程。這些都是Android嘗試通過回收其他應用程序來使其保持相應的進程。這些進程的數量非常少，只有等到最後關頭才會終止這些進程，是用戶最不希望終止的進程。例如：而當你運行瀏覽器這類應用時，它們的界面就會顯示在前台，它們就屬於前台進程，當你按home鍵回到主界面，他們就變成了後台程序。

       如果一個進程滿足以下任一條件，即視為前台進程：

     （1）託管處於活動狀態的Activity，也就是說，它們位於前台並對用戶事件進行響應，此時的情形為響應了Activity中的onResume()生命周期方法，但沒有響應onPause()。

     （2）託管正在執行onReceive()方法處理事件程序的BroadcastReceiver。

     （3）託管正在執行onStart()、onCreate()或onDestroy()事件處理程序的Service。

     （4）託管正在運行且被標記為在前台運行的Service，即調用了該Service的startForeground()方法。

     （5）託管某個Service，且該Service正綁定在用戶正在交互的Activity的Service，即該Activity正處於活動狀態。

  2、可見進程（visible）

        沒有任何前台組件、但仍然會影響用戶在屏幕上所見內容的進程。如果一個進程滿足以下任一條件，即視為可見進程：

    （1）託管不在前台、但仍對用戶可見的Activity（已調用其onPause（）方法）。例如：如果前台Acitivty啟動了一個對話框，或者啟動了一個非全屏，亦或是一個透明的Activity，允許在其後顯示上一個Activity，則可能會發生這種情況，這類Activity不在前台運行，也不能對用戶事件作出反應。

    （2）託管綁定到可見Activity的Service。（官網上說是綁定到可見或前台Activity，但筆者有一點疑問，這個和「前台進程」中第（5）點相矛盾嗎，綁定到前台Activity，那就是前台進程了）

        可見進程被視為是極其重要的進程，這類進程的數量也很少，只有在資源極度匱乏的環境下，為保證前台進程繼續執行時才會終止。

  3、服務進程（Service）

        正在運行已使用startService（）方法啟動的Serice且不屬於上述兩個更高類別進程的進程。盡管服務進程與用戶所見內容沒有直接關聯，但是它們通常在執行一些用戶關心的操作。因此，除非內存不足以維持所有前台進程和可見進程同時運行，否則系統會讓服務進程保持運行狀態。

       有些資料上面也稱這種進程為次要服務（Secondary Service），而屬於上述兩個更高類別的進程則被稱為主要服務，主要服務往往屬於系統進程，如撥號進程等，不可能被進程管理輕易終止。這里我們以Android開發者官網的稱呼為標准，稱為服務進程。

  4、後台進程（hidden）

       包含目前對用戶不可見的Activity，即該Activity調用了onStop()方法。這些進程對用戶體驗沒有直接影響，系統可能隨時終止它們，以回收內存供上述三個更高級別的進程使用。通常會有很多後台進程在運行，它們會保存在LRU（Least Recently Used，最近最少使用）列表中，以確保包含用戶最近查看的Activity的進程最後一個被終止。如果某個Activity正確實現了生命周期方法，並保存了其當前狀態，則終止其進程不會對用戶體驗產生明顯影響，因為當用戶導航回該Activity時，Activity會恢復其所有可見狀態。

       這里讀者可以做個試驗，先開啟微信，進入到朋友圈界面， 然後點擊手機屏幕下方的導航欄中的Home按鍵進入到後台，再點擊最近使用應用列表顯示按鈕（不同的手機位置不一樣，有的在Home鍵左邊，有的則在Home鍵右邊），在顯示的最近使用應用的列表中清理掉微信應用，最後再點擊桌面的微信圖標啟動微信，會發現顯示的界面仍然是朋友圈界面。

       後台進程，我們可以簡單理解為，應用（只考慮只有Activity組件的情況）啟動後按Home鍵後被切換到後台的進程。如瀏覽器、閱讀器等，當程序顯示在屏幕上時，它們所運行的進程即為前台進程（foreground），一旦按home鍵（注意不是back鍵）返回到桌面，程序就停留在後台，成為後台進程。

  5、空進程（empty）

       不含任何活動應用組件的進程。保留這種進程的唯一目的是用作緩存，以縮短下次再其中運行組件所需要的啟動時間。一般來說，當應用按back按鍵退出後應用後，就變成了一個空進程。比如BTE，在程序退出後，依然會在進程中駐留一個空進程，這個進程里沒有任何數據在運行，作用往往是提高該程序下次的啟動速度或者記錄程序的一些歷史信息。當系統內存不夠用時，無疑，該進程是應該最先終止的。在最近使用應用列表中，可以看到按back鍵退出的應用。

       根據進程中當前活動組件的重要程度，Android會將進程評定為它可能達到的最高級別。通俗地說，就是如果一個進程同時擁有多個對應上述不同等級進程的組件時，會以最高的那個等級作為該進程的等級。例如，如果某進程託管著服務和可見Activity，則會將此進程評定為可見進程，而不是服務進程。

       此外，一個進程的級別可能會因為其他進程對它的依賴而有所提高，即服務於另一進程的進程其級別永遠不會低於其所服務的進程。例如，如果進程A中的內容提供程序為進程B中的客戶端提供服務，或者如果進程A中的服務綁定到進程B中的組件，則進程A始終被視為至少與進程B同樣重要。

       由於運行服務的進程其級別高於託管後台Activity的進程，因此啟動長時間運行操作的Activity最好為該操作啟動Service，而不是簡單地創建工作線程，當操作有可能比Activity更加持久時更應該如此。例如，正在將圖片上傳到網站的Activity應該啟動服務來執行上傳，這樣一來，即使用戶退出Activity，仍可在後台繼續執行上傳操作。使用服務可以保證，無論Activity發生什麼情況，該操作至少具備「服務進程」優先順序。如果某個Activity開啟了線程執行耗時操作，當Activity退出時，該Activity的實例將不會釋放內存資源，直到線程執行完，這樣容易導致內存泄漏。同理，廣播接收器也應該使用服務，而不是簡單地將耗時冗長的操作放入線程中。

四、進程移除順序的依據——閾（yu，第四聲）值

        前面講到，內存不夠用時，會根據進程的等級來決定優先回收哪類進程。那麼系統是根據什麼來判斷需要移除這些進程的時機的呢？答案是閾值。

  1、查看閾值

        我們可以採用如下方法查看手機中各個等級進程的閾值（需要root許可權），如第二排數據所示（其單位為頁）：

       以第一個數據44032為例，計算方法為：

       1page=4KB=4*1024B=4096B

       44032page* 4048B/page =  180355072B

       180355072B/1024/1024 = 172M

       即第一個等級的進程的閾值為172M。依次類推，閾值依次為：172M，190M，208M，226M，316M，415M。

       有必要說明一下，在Android開發者官方文檔中，是將Android應用進程分為了5個等級，但很多資料卻是分的6個等級，在後台進程和空進程之間還有一個「內容提供節點（content provider）進程」。內容提供節點，沒有實體程序，僅提供內容供別的程序去用 ，比如日歷供應節點，郵件供應節點等，在終止進程時，這類進程有比較高的優先權。手機中應該是採用的6個等級的方式，如上六個數據，正好對應著六個等級的進程，等級越高，閾值越低，即前台進程閾值為172M，空進程為415M。當系統的剩餘內存只剩餘不到415M的時候，系統首先會回收空進程，依次類推，只有剩餘內存不到172M了，才會去回收前台進程，這樣就起到了優化保護重要進程的作用。

五、Home鍵、Back鍵和多任務鍵

       Home鍵、Back鍵和多任務鍵，在手機屏幕的下方，這三個按鍵一般稱為導航欄，中間的按鈕為Home鍵，多任務鍵和Back鍵分別在其左右，一般根據手機品牌不同，左右位置也有所差異。

       在運行App的時候，如果按一下Home鍵或者Back鍵，都可以退到桌面，那麼這兩者有什麼區別呢？

Home鍵。按Home鍵的時候，App如果沒有Service開啟，會從一個前台進程轉變為一個後台進程；如果有前台service運行，就仍然是前台進程，比如QQ音樂播放器等；如果是只有普通service運行，那麼就轉變為服務進程（參照前文中講的Android進程的5個級別）。

Back鍵。按Back鍵的時候，App如果沒有Service開啟，會從一個前台進程轉變為一個空進程；對於有Service運行的情況，和按Home鍵一樣。

        後台進程和空進程，都是駐留在後台，處於暫停狀態，也都是除了佔用一部分內存外，不佔用其他如cpu等資源的，那麼問題來了，為什麼要設計後台進程和空進程這兩種空進程呢？它們的區別到底在哪裡呢？我們在前文講Android進程的5個等級的時候講到過，當剩餘內存不足的時候，系統會按照等級順序，優先移除不太重要進程，以收回內存供更重要的進程運行。那麼，它們的區別就是，在剩餘內存不足時，會優先移除空進程，再不足，才會移除空進程。所以，如果確實要退出某個應用一段時間內不大使用了，如果這款應用有退出按鈕，就用應用自帶的退出功能；如果沒有，則最好按系統的Back鍵，這樣可以變成空進程，當系統要回收內存時，就會優先被回收，從而釋放的所佔的資源。如果只是暫時退出去做點別的，過一會還要切換回來，或者對這款應用使用比較頻繁，那就使用Home鍵，因為相比於按Back鍵，這樣可以盡可能保住後台進程，方便下次使用的時候快速啟動。

       當然，按Home鍵或Back鍵，對用戶來說，其實感覺不到差異，使用起來沒什麼兩樣，但是，對於Android開發者來說，卻有必要作為常識來了解其中的道理和差異。無論是按Home鍵還是按Back鍵，在按多任務鍵的時候，都可以看到這些進程，如下圖所示。最下面的按鍵為清理按鍵，點擊後可以清除掉這些進程，回收內存了，當然，前面也講了很多遍了，不建議這樣做。

  2、修改閾值。

       可以採用命令：echo "44032,48640,53248,57856,80896,106241" > /sys/mole/lowmemorykiller/parameters/minfree來修改閾值，如下所示：

       重啟後，會恢復為原來的值。至於如何永久性修改該閾值，這里不深入探討，有興趣的童鞋可以自行研究，一般來說，就按照系統給定的默認值使用就可以了，沒特殊用途的話，沒必要修改。

       對於這一節閾值的內容，暫時先講到這里，如果要更深入，可以自行多研究研究。筆者也沒有看到比較好的更深入的文章，所以也不好推薦，如果讀者看到比較好的，可以推薦給筆者，感激不盡。

六、開發者選項中的進程管理功能

        Android手機都帶有開發者選項，隱藏了很多功能，顧名思義，這些功能主要用於輔助開發者調試程序用的。其中有一些就是關於進程管理功能的，筆者這里簡單介紹一下其中兩款，如下圖紅框部分所示：

不保留活動。用戶離開以後即銷毀每個活動（Activity），這樣做使得後台進程都被銷毀了。筆者試驗過幾款app，比如微信，瀏覽器，開啟/關閉「不保留活動」前後，按Home鍵後，再打開應用，有明顯的差別。當然，也試用了簡訊，DD打車，就沒看出起了什麼作用。讀者若是感興趣可以深入研究研究，到時候在指導指導筆者！

後台進程限制。如下圖所示，給出了後台進程個數限制的選項。

七、進程管理軟體的使用

       Windows操作系統用戶往往總想著保留更多的內存，在使用Android手機的時候，喜歡經常清理後台進程或空進程，而且清理完後，心裡有一種特別爽的感覺，就像給家裡做了一次大掃除一樣，筆者最初使用Android手機的時候也是這樣的心態-_-！基於這樣的心態，一些進程清理軟體，很受普通用戶的青睞。其實這樣做卻正好抹殺了Android系統所標榜的優勢，如前文所講到的。

       那麼進程管理軟體有無必要呢？當然有的，只是需要注意使用場合。當需要運行大型程序的時候，可以手動關閉掉一些進程，騰出足夠的空間供大型程序使用，這樣就可以有效避免系統調用進程調度策略而引起的卡頓，這一點，第八大點第3小節中會有說明。而且由於開發者的原因，可能是程序寫得太爛，或程序容易出錯，或做不該做的動作，或是惡意程序，對於這類程序進程，手動移除也是有好處的。

       但如果是運行一些小程序，就完全沒有必要去預先殺進程了，完全可以交給系統自己管理。讀者可能會疑惑，因為小程序啟動的時候，也有可能會因為內存不足而導致需要移除部分進程的情況。筆者認為，即便是內存不足，小程序運行引起的調用進程調度策略測的次數非常少，要移除的進程也非常少，產生的影響不大。同時，我們也要意識到另外一點就是，無論是手動殺死進程還是自動殺進程，都需要cpu去執行這些任務，所以也會拖慢手機和消耗電量。所以從這一點看，頻繁殺進程，也是一個不好的習慣。

八、答疑解惑

        在以前沒有專門去了解Android進程管理機制的時候，甚至是在研究的過程中，筆者心裡都經常存在很多疑惑，以下整理了其中5個，不知道讀者您是否有也類似的困惑呢？

  1、這么多駐留在內存的進程，不會耗電嗎？

       大多數用慣了Windows操作系統的童鞋，看到Android系統盡可能保留不在活動的進程的設計，可能第一反應就是質疑，難道這樣不會增加耗電量嗎？其實，但一個程序按home鍵變成後台進程或者按back鍵退出變成空進程後，其實已經被暫停了，只保留了運行狀態，不會消耗cpu，一個程序會耗電，是因為它需要調用cpu來運算，現在不消耗cpu了，當然就不會耗電了。當然，開了service的應用就另當別論了，比如QQ音樂播放器，當按home鍵或back鍵後，音樂仍然播放，是因為它開啟了服務，而且是一個前台服務，在後面我們會繼續講到，此時它是一個前台進程，而不是後台進程或空進程。

  2、為什麼一個不太app，運行時會佔用很大的內存呢？

我們經常會碰到這樣一種現象，一個只有20M的App，運行起來的時候，卻會耗掉100M以上的內存。一方面是，程序運行時為對象分配內存，另一方面，是Android虛擬機的原因。Android中的應用啟動的時候，系統都會給它開啟一個獨立的虛擬機，這樣做的好處是可以避免虛擬機崩潰導致整個系統崩潰，代價就是耗用更多的內存。

  3、為什麼內存少的時候，運行大型程序會卡頓呢？

        當剩餘內存不多時，打開大型程序，系統會觸發自身的進程調度策略，去移除一些等級比較低的進程來回收內存，以供大型程序運行。而這個進程調度策略在決定哪些進程需要被移除的過程，是一個十分消耗資源的操作，特別是一個程序頻繁像系統申內存的時候，這樣就導致了系統的卡頓。

 4、應用開得太多了，手機變慢，是因為內存被佔用太多嗎？

        其實手機變慢的根本原因是cpu被耗用太多，而不是內存佔用太多，因為真正執行程序所要完成的任務的最終執行者是CPU，而不是內存（RAM）。在內存足夠的情況下，如果系統中佔用cpu的進程太多，那無疑cpu總有忙不過來的時候，那肯定就會變慢了。這就好比，在一條道路上駕車，道路就像內存，車的引擎就像cpu，如果車的引擎的動力不夠，或者承載的貨物太多，車都跑不快，即便是道路上一路暢通無阻，也無濟於事。所以，內存佔用多少並不重要，只要道路提供給車輛前行的空間是足夠的，手機變慢的責任，就和內存無關了。這個比喻用來解釋第三點也很恰當，道路提供的車輛前進的空間無法滿足車輛所必需的空間時，就需要交通機制花時間來調節交通，給這輛車提供足夠的空間，而在此期間，這輛車只能乖乖候著。

  5、Android手機越用越慢，是什麼原因呢？

Android手機常常是越用越慢，即使是恢復出廠設置，也無法改變這個現象。手機越用越慢，主要由如下幾個原因：（1）虛擬機機制問題。這一點在上一個問題中也提到了，在Android4.4以前的系統，使用的是Dalvik虛擬機，它的設計機制有缺陷，就是越用越慢；在Android4.4系統中有切換按鈕，可以在Art虛擬機和Dalvik虛擬機之間切換；在Android4.4以後的系統就徹底拋棄了Dalvik而全面使用Art。（2）開啟了太多的服務，導致耗用太多的CPU。隨著手機開機使用時間的增長，應用使用越來越多，很多應用看似退出了，而其實後台可能開了不少的服務，而他們可能還沒有關閉。這些服務正在執行一些操作，會消耗CPU，而CPU才是手機變慢的根本原因。 而且Android app比較開放的，有很多不良應用充斥其中，可能對服務處理不當，濫用服務等，增加系統中的服務。（3）系統頻繁調用自身的進程調度演算法。這一點在前面已經說明了，這里不再贅述。（4）手機硬體的自然老化

⑤ 人人都應該了解的 Android 進程管理機制

打開設置--應用與服務（不同機型進入方式可能不同），你就會看到當前正在運行的進程和服務，也就是目前正在「後台運行」的任務。列表中有你剛剛使用過的 APP ，也有一兩小時前打開過的 APP。還有一些軟體你甚至不知道自己什麼時候打開過（其實根本就不是自己打開的），或者記得自己已經「關閉」了，但它們也在列表中，消耗著你的手機資源。列表中有一些條目名字很奇怪，一般人看不懂，但還是覺得「它很重要」，不敢輕易強悔培制關閉。這個列表展示的內容和普通的後台管理界面不太一樣，感覺稍稍有些神秘，然而這又是我們日常使用所迴避不了的一部分。

作為一名資深的手機用戶（我相信人人都是），是時候該解決這類疑問了。這一切都要從人與宇宙的關系。。。咳咳。。手機進程的概念開始說起。

在開發文檔中是這么說的：當一個應用程序啟動時（僅僅只是「啟動時」，並不一定有組件運行），就會產生一個進程。在這個進程中同時會創建一個主線程，使應用內的任務開始執行。Android系統總是盡可能地保留進程。舉個例子，當你打開qq時，進程創建（同時創建主線程），隨後各種內容載入（首先是活動，然後是各種控制項什麼的）。當你完成操作時，一般都會按後退鍵（back），直至退出程序。

這里需要注意，一般情況下我們一直按後退是希望應用程序關閉的。然而事實上這樣做只是關閉了界面（活動），大多數app的「進程」仍會保留（少數良心app可以設置在退出時「完全關閉」），佔用內存以進行後台任務。進程隨應用啟動而產生，但往往並不隨著應用的「關閉」而關閉

所以很多時候我們看上去關閉了程序，但其實它仍在後台運行！（此處請自行回憶那些困擾你的流氓軟體們）。不過不必擔心，Android 系統自有一套進程管理機制來幫你管理後台任務。系統會根據應用的重要程度把所有進程劃歸為幾個等級，最不重要的進程將會被優先關閉，相對重要的進程將獲得資源來保留。

那麼問題來了----到底如何分辨哪些進程重要而哪些不重要呢？

系統當然要保證用戶體驗，所以重要等級的劃分原則就是要首先滿足用戶當前的需求：用戶正在使用的當然不能關閉，而用戶暫時不需要的，相對的就沒那麼重要了。

1.Foreground process 前台進程：也就是用戶正在進行操作的進程。這樣的進程優先順序（優先保留）最高，最不容易銷毀，因為它表現在屏幕上，直接同用戶進行交互，所以只有當內存資源極度緊張等一些其他極端情猛迅況才會關閉，表現為「閃退」。我用的第一台 Android 手機運行內存（RAM）只有 290M，多任務時經常內存不足導致程序「閃退」。這手機我竟然用了兩年，現在想想都佩服我自己hhhh。

不只是界面交互，如果應用程序中的服務（service）組件正在進行一些操作或者廣播接收者（BroadcastReceiver）在執行接收廣播的操作（onReceive）時，該進程仍被視為前台進程。

2.Visible process 可視進程：顧名思義，就是仍然在屏幕上有顯示，但用戶不再能直接與它交互的程序。比如當在應用中打開下滑菜單時（有些下滑菜單是透明的），用戶能「看得到」，但是「摸不著」。優先順序僅次於前台進程。

3.Service process 服務進程：該進程中開啟了一個服務（通過startService方法）。注意這里強調的是服務的「開啟」，區別於第一類中的「服務正在執行一些操作」。大多數音樂軟體都是通過這種方法來保留其播放音樂的進程。

4.Background process 後台進程：當你按下 HOME 鍵或 BACK 鍵時，手機退回主界面，此時應用程序不再可見，轉入後台運行。如果如果不滿足前幾類的條件，這個進程就會被判定為後台進程。

5.Empty process 空進程：A process that doesn't hold any active application components.沒有任何組件在運行，包括活動界面（Activity）。事實上用戶已經不再需要這個進程了，但出於 Android 系統「盡可能保留進程」的原則，這樣的進程出現後不會被立即銷毀。保留進程的唯一理由，就是為了下次開啟這個應用時能快一些。其實現在的手機硬體性能足夠好，這樣的緩存對於用戶體驗的提升效果不怎麼明顯。這樣的進程最不重要，將首先被銷毀。枝前此

也許你已經注意到了，在屏幕上正在顯示的或者正在服務於用戶的進程的重要等級是比較高的，這是出於對用戶體驗的考慮-----誰會接受在自己打王者榮耀的時候游戲突然閃退呢？大多數情況下，一個應用程序的組件成分都會比較復雜，這個進程可能同時滿足多個級別的劃分條件。在這種情況下，它會被盡可能地劃為能夠達到的最重要等級。

如果你的手機上安裝了好幾個同一家公司推出的 APP（比如企鵝系、頭條系等），那麼當你啟動其中之一時，剩下的幾款 APP 大概率也會被喚醒（視軟體的流氓程度而定）。聯動開啟的 APP 會大大佔用內存，讓手機變得卡頓。並且它們許多都需要聯網服務，佔用網速，有些還會在你不知情（因為你並沒有直接開啟或使用它們）的情況下監控你的數據並上傳。

不過，你以為這就完了？

事實上，如果不手動清除，這樣的進程很難被系統關閉，它們會一直長期運行。這些進程大多屬於第三或第四等級，然而如果不同 APP 中的組件構成「相互依賴」的關系，它們所屬進程的保留優先順序就會提高，也就越不容易被關閉。（我等流氓軟體可不是浪得虛名的ε=ε=ε=( _￣▽￣) ）

盡管 Android 想要盡可能的保存所有的進程，但是並非所有的內存都會被用於維持進程。比如系統運行會佔用相當的內存，系統也需要留出一部分閑置內存用以處理新事件。Android 的管理讓內存的分配處於一種「動態平衡」中，以保障各項任務都能盡可能的穩定、高效地執行。

好了，關於進程的管理就暫時說到這了。眾所周知，Android 系統是一個復雜的機體，它管理著手機硬體和軟體，讓它們盡可能的配合，提供給用戶最好的服務。這次只是簡單介紹了進程管理機制，今後我也會盡量用通俗的語言從系統上去解釋那些平常看上去似是而非的問題，期待你的關注！

⑥ 小米2s發熱怎麼解決

小米手機發熱問題根源：

• 後台運行多個任務導致CPU超載；

• 系統I/O處理遇到瓶頸和阻塞；

• 手機充電時導致過熱；

• 後台多個應用消耗一定的電量；

• 手機硬體連接網路時電量損耗最多；

• 手機在長時間通話或使用音頻和視頻時的功耗是很大；

對於上述問題，可以下載安裝One省電衛士進行解決。

1. 解決後台運行多個任務導致CPU超載；

CPU頻率設置過高時會導致過熱，過熱導致耗電更嚴重，CPU頻率設置過低導致手機滯後，應用處理緩慢同樣會導致耗電，因為CPU處理消耗更長的時間，並且可能禪扒導致進程FC，為此，One省電衛士通過Android的Cpufreq模塊，在底層控制各種不同 CPU 所支持的變頻技術以及如何在上層根據系統負載動態選擇合適的運行頻率。