Android記憶體管理

非同步社群發表於2018-06-13

Android是一個基於Linux實現的作業系統。但對於Linux核心來說，Android也僅僅只是一個執行在核心之上的應用程式，與其他執行在核心之上的應用程式沒有任何區別。所以Android需要一套機制管理執行在Linux程式中的APK應用程式。Android記憶體管理包含兩部分，一部分是Framework對記憶體的管理，一部分是Linux核心對記憶體管理，這兩部分共同決定應用程式的生命週期。本文主要闡述Android記憶體管理機制的實現原理，以及在應用開發中需要注意的一些事項，最後本文總結了如何實現殺不死程式的一種方法。

Linux 程式回收

在Android中，大部分應用程式都執行在一個獨立的Linux程式中，每個程式都有獨立的記憶體空間。隨著各種應用程式啟動，系統記憶體不斷下降，為了保證新應用能夠執行，Android需要一套機制殺死暫時閒置的程式。

Android Framework並不能直接回收記憶體，其管理程式的服務（ActivityManagerService，以下簡稱AmS）也同應用程式一樣執行在Java虛擬機器環境裡。Java虛擬機器都執行在各自獨立的記憶體空間，所以ActivityManagerService沒有辦法感知應用程式是否OOM。

Android系統中還執行了一個OOM程式。該程式啟動時首先會在Linux核心中把自己註冊為一個OOM Killer。AmS需要把每一個應用程式的oom_adj值告知OOM Killer，這個值的範圍在-16到15之間，值越低，說明越重要，這個值類似於Linux中的nice值，只在標準的Linux中，有其自己的OOM Killer。Android中的OOM Killer程式僅僅適用於Android應用程式。

當核心的記憶體管理模組檢測到系統記憶體不足時就會通知OOM Killer，然後OOM Killer根據AmS所告知的優先順序強制退出優先順序低的應用程式。

應用程式在記憶體中的狀態

Android官方聲稱，Activity退出後，其所在程式並不會被立即殺死，從而在下次啟動Activity時，能夠提高啟動速度。這些Activity只有在記憶體緊張時才會被系統殺死。所以對於應用程式來說，關閉並不意味著釋放記憶體。

Activity在記憶體中的狀態
系統只有一個Activity處於與使用者互動的狀態，對於非互動狀態的Activity，AmS會在內部暫時快取起來而不是立即殺死，但如果後臺Activity數目超過一定閾值，AmS則會強制殺死一些優先順序低的Activity。以下是Activity在記憶體或者說在AmS中的狀態：

AmS會記錄最近啟動的20個Activity，如果超過20則捨棄最早記錄的Activity。

AmS會將所有正在執行的Activity儲存在一個列表中，對於使用back返回的Activity則從列表中清除。

AmS使用Lru演算法儲存所有最近使用過的Activity。

AmS使用一個列表（mStoppingActivities）儲存需要停止的Activity，這種情況
發生在啟動一個Activity時，AmS遵循先啟動後停止的策略，將需要停止的Activity儲存在此列表中，等AmS閒置下來後再停止Activity。

AmS使用一個列表儲存處於finish狀態(onDestory())的Activity，當一個Activity處於finish狀態時（onDestory()執行後）不會被立即殺死，而是儲存到該列表中直到超過系統設定的警戒線才會回收該列表中的Activity。

應用程式在記憶體中的狀態
每個應用程式都對應著一個ActivityThread類，該類初始化後就進入Looper.loop()函式中無限迴圈。

以後則依靠訊息機制執行，既當有訊息時處理訊息，沒有訊息則應用程式進入sleep狀態。loop()方法內部程式碼如下所示：

在Linux核心排程中，如果一個執行緒的狀態為sleep，則除了佔用排程本身的時間，不會佔用CPU時間片。

有三種情況會喚醒應用執行緒，一種是定時器中斷（比如我們設定的鬧鐘，在程式中可以設定定時任務），第二種是使用者按鍵訊息，第三種是Binder訊息（Binder用於程式間通訊，其在應用程式中會自動建立一個執行緒，Binder在接收到訊息後會想UI主執行緒傳送一個訊息從而使queue.next()繼續執行）這就是所謂的訊息驅動模式。

所以設計良好的應用程式當處於後臺時不會佔用任何CPU時間，更不會拖慢系統執行速度。其所佔用的僅僅是記憶體，即使釋放所佔用的記憶體也不會提高系統執行速度。當然這裡說的是設計良好的應用程式，目前國內很多應用在處於後臺狀態時依然會偷偷幹很多事情，這無疑就拖慢了系統執行速度。

Android 記憶體回收

Activity所佔記憶體在一般情況下不會被回收，只有在系統記憶體不夠用時才會回收，並且回收會遵循一定規則。大致可以概括為前臺Activity最後回收，其次是包含前臺的Service或者Provider，再其次是後臺Activity，最後是空程式。

記憶體釋放的三個地方

第一個是在ActivityManagerService中執行，即Android所聲稱的當系統記憶體低時，優先釋放沒有任何Activity的程式，然後釋放非前臺Activity對應的程式。

第二個是在OOM Killer中，此時AmS只要告訴OOM各個應用的優先順序，然後OOM就會呼叫Linux內部的程式管理方法殺死優先順序較低的程式。

第三個是在應用程式本身之中，當AmS認為目標程式需要被殺死時，首先會通知目標程式程式記憶體釋放。這包括呼叫目標程式的scheduleLowMemory()方法和processInBackground()方法。

關閉Activity的三種情況

第一種，從呼叫startActivity()開始，一般情況下，當前都有正在執行的Activity，所以需要先暫停當前的Activity，而暫停完畢後，AmS會收到一個Binder訊息，並開始從completePaused()處執行。在該函式中，由於上一個Activity並沒有finishing，僅僅是stop，所以這裡會把上一個Activity新增到mStoppingActivity列表中。當目標Activity啟動後，會向Ams傳送一個請求進行記憶體回收的訊息，這會導致AmS在內部呼叫activityIdleInternal()方法，該方法中首先會處理mStoppingActivities列表中的Activity，這就會呼叫stopActivityLocked()方法。這又會通過IPC呼叫，通知應用程式stop指定的Activity，當stop完畢後，再報告給AmS，於是AmS再從activityStopped()出開始執行，而這會呼叫trimApplication()方法，該方法會執行記憶體相關的操作。

第二種，當按Back鍵後，會呼叫finishActivityLocked()，然後把該Activity的finishing標識設為true，然後再呼叫startPausingLocked()，當目標Activity完成暫停後，就會報告AmS，此時AmS又會從completePaused()處開始執行。與第一種情況不同，由於此時暫停的Activity的finishing狀態已經設定為true，所以會執行finishingActivityLocked()，而不是像第一種情況中僅僅把該Activity新增到mStoppingActivities列表。

第三種，當Activity啟動後，會向AmS傳送一個Idle訊息，這會導致AmS開始執行activityIdleInternal()方法。該方法會首先處理mStoppingActivities列表中的物件，接著處理mFinishingActivities列表，最後再呼叫trimApplication()方法。

以上就是關閉Activity的三種情況，包括stop和destory，客戶程式中與之對應的就是onStop()和onDestory()的呼叫。

如果使用OOM還有AmS機制殺死後臺程式後，此時執行的Activity數量依然超過MAX_ACTIVITIES(20)，則需要繼續銷燬滿足以下三個條件的Activity：

Activity必須已經stop，但卻沒有finishing

必須是不可見的，既該Activity視窗上面有其他全屏的視窗，如果不是全屏，則後面的Activity是可見的。

不能是persistent型別，既常駐程式不能被殺死。

程式優先順序

Android系統試圖儘可能長時間地保持應用程式程式，但為了新建或者執行更加重要的程式，總是需要清除過時程式來回收記憶體。為了決定保留或終止哪個程式，根據程式內執行的元件及這些元件的狀態，系統把每個程式都劃入一個“重要性層次結構”中。重要性最低的程式首先會被清除，然後是下一個最低的，依此類推。

重要性層次結構共有5級，以下列表按照重要程度列出了各類程式（第一類程式是最重要的，將最後一個被終止）：

1）前臺程式

使用者當前操作所必須的程式。滿足以下任一條件時，程式被視作處於前臺：
其中執行著正與使用者互動的Activity（Activity物件的onResume()方法已被呼叫）。
其中執行著與使用者互動的activity繫結的Service。
其中執行著前臺Service，既該Service以startForeground()方式被呼叫。
其中執行著正在執行生命週期回撥方法（onCreate()、onStart()或onDestory()）的Service。
其中執行著正在執行onReceive()方法的BroadcastReceiver。

一般而言，任何時刻前臺程式的數量都為數不多，只有當記憶體不足以維持它們同時執行時才會被終止。通常，裝置這時候已經到了使用虛擬記憶體的地步，終止一些前臺程式是為了保證使用者介面的及時響應。

2）可見程式

沒有前臺元件、但仍會影響使用者在螢幕上所見內容的程式。滿足以下任一條件時，程式被認為是可見的：
其中執行著非前臺Activity，但使用者仍然可見到此activity（onPause()方法被呼叫）。例如，開啟了一個對話方塊，而activity還允許顯示在對話方塊後面，對使用者依然可見。
其中執行著被可見（或前臺）activity繫結的Service。

可見程式被認為是非常重要的程式，除非無法維持所有前臺程式同時執行了，否則它們是不會被終止的。

3）服務程式

此程式執行著由startService()方法啟動的服務，它不會升級為前臺程式或可見程式。儘管服務程式不直接和使用者所見內容關聯，但他們通常在執行一些使用者關心的操作（比如在後臺播放音樂或從網路下載資料）。因此，除非記憶體不足以維持所有前臺、可見程式同時執行，系統會保持服務程式的執行。

4）後臺程式

包含使用者不可見activity（Activity物件的onStop()方法已被呼叫）的程式。這些程式對使用者體驗沒有直接的影響，系統可能在任意時間終止它們，以回收記憶體供前臺程式、可見程式及服務程式使用。

通常系統會有很多後臺程式在執行，所以它們被儲存在一個LRU（最近最少使用）列表中，以確保最近被使用者使用的activity最後一個被終止。如果一個activity正確實現了生命週期方法，並儲存了當前的狀態，則終止此類程式不會對使用者體驗產生可見的影響。因為在使用者返回時，activity會恢復所有可見的狀態。關於儲存和恢復狀態的詳細資訊，請參閱Activity文件。

5）空程式

不含任何活動應用程式元件的程式。保留這種程式的唯一目的就是用作快取，以改善下次在此程式中執行元件的啟動時間。為了在程式快取和核心快取間平衡系統整體資源，系統經常會終止這種程式。

依據程式中目前活躍元件的重要程度，Android會給程式評估一個儘可能高的級別。例如，如果一個程式中執行著一個服務和一個使用者可見的activity，則此程式會被評定為可見程式，而不是服務程式。

此外，一個程式的級別可能會由於其它程式的依賴而被提高——為其它程式提供服務的程式級別永遠不會低於使用此服務的程式。比如：如果A程式中的content provider為程式B中的客戶端提供服務，或程式A中的服務被程式B中的元件所呼叫，則A程式至少被視為與程式B同樣重要。

因為執行服務的程式級別是高於後臺activity程式的，所以，如果activity需要啟動一個長時間執行的操作，則為其啟動一個服務會比簡單地建立一個工作執行緒更好些——尤其是該操作時間比activity的生存期還要長的情況下。比如，一個activity要把圖片上傳至Web網站，就應該建立一個服務來執行之，即使使用者離開了此activity，上傳還是會在後臺繼續執行。不論activity發生什麼情況，使用服務可以保證操作至少擁有“服務程式”的優先順序。同理，廣播接收器broadcast receiver也是使用服務來處理耗時任務的，而不是簡單地把它放入執行緒中。