Android記憶體最佳化之OOM

標籤：

Android的記憶體最佳化是效能最佳化中很重要的一部分，而避免OOM又是記憶體最佳化中比較核心的一點，這是一篇關於記憶體最佳化中如何避免OOM的總結性概要文章，內容大多都是和OOM有關的實踐總結概要。理解錯誤或是偏差的地方，還請多包涵指正，謝謝！

(一)Android的記憶體管理機制

Google在Android的官網上有這樣一篇文章，初步介紹了Android是如何管理應用的進程與記憶體配置：http://developer.android.com/training/articles/memory.html。 Android系統的Dalvik虛擬機器扮演了常規的記憶體垃圾自動回收的角色，Android系統沒有為記憶體提供交換區，它使用paging與memory-mapping(mmapping)的機制來管理記憶體，下面簡要概述一些Android系統中重要的記憶體管理基礎概念。

1）共用記憶體

Android系統通過下面幾種方式來實現共用記憶體：

• Android應用的進程都是從一個叫做Zygote的進程fork出來的。Zygote進程在系統啟動並且載入通用的framework的代碼與資源之後開始啟動。為了啟動一個新的程式進程，系統會fork Zygote進程產生一個新的進程，然後在新的進程中載入並運行應用程式的代碼。這使得大多數的RAM pages被用來分配給framework的代碼，同時使得RAM資源能夠在應用的所有進程之間進行共用。
• 大多數static的資料被mmapped到一個進程中。這不僅僅使得同樣的資料能夠在進程間進行共用，而且使得它能夠在需要的時候被paged out。常見的static資料包括Dalvik Code，app resources，so檔案等。
• 大多數情況下，Android通過顯式的分配共用記憶體地區(例如ashmem或者gralloc)來實現動態RAM地區能夠在不同進程之間進行共用的機制。例如，Window Surface在App與Screen Compositor之間使用共用的記憶體，Cursor Buffers在Content Provider與Clients之間共用記憶體。

2）分配與回收記憶體

• 每一個進程的Dalvik heap都反映了使用記憶體的佔用範圍。這就是通常邏輯意義上提到的Dalvik Heap Size，它可以隨著需要進行增長，但是增長行為會有一個系統為它設定的上限。
• 邏輯上講的Heap Size和實際物理意義上使用的記憶體大小是不對等的，Proportional Set Size(PSS)記錄了應用程式自身佔用以及和其他進程進行共用的記憶體。
• Android系統並不會對Heap中空閑記憶體地區做磁碟重組。系統僅僅會在新的記憶體配置之前判斷Heap的尾端剩餘空間是否足夠，如果空間不夠會觸發gc操作，從而騰出更多閒置記憶體空間。在Android的進階系統版本裡面針對Heap空間有一個Generational Heap Memory的模型，最近分配的對象會存放在Young Generation地區，當這個對象在這個地區停留的時間達到一定程度，它會被移動到Old Generation，最後累積一定時間再移動到Permanent Generation地區。系統會根據記憶體中不同的記憶體資料類型分別執行不同的gc操作。例如，剛分配到Young Generation地區的對象通常更容易被銷毀回收，同時在Young Generation地區的gc操作速度會比Old Generation地區的gc操作速度更快。如所示：

 

每一個Generation的記憶體地區都有固定的大小，隨著新的對象陸續被分配到此地區，當這些對象總的大小快達到這一層級記憶體地區的閥值時，會觸發GC的操作，以便騰出空間來存放其他新的對象。如所示：

通常情況下，GC發生的時候，所有的線程都是會被暫停。執行GC所佔用的時間和它發生在哪一個Generation也有關係，Young Generation中的每次GC操作時間是最短的，Old Generation其次，Permanent Generation最長。執行時間的長短也和當前Generation中的對象數量有關，遍曆樹結構尋找20000個對象比起遍曆50個對象自然是要慢很多的。

3）限制應用的記憶體

• 為了整個Android系統的記憶體控制需要，Android系統為每一個應用程式都設定了一個硬性的Dalvik Heap Size最大限制閾值，這個閾值在不同的裝置上會因為RAM大小不同而各有差異。如果你的應用佔用記憶體空間已經接近這個閾值，此時再嘗試分配記憶體的話，很容易引起OutOfMemoryError的錯誤。
• ActivityManager.getMemoryClass()可以用來查詢當前應用的Heap Size閾值，這個方法會返回一個整數，表明你的應用的Heap Size閾值是多少Mb(megabates)。

4）應用程式切換操作

• Android系統並不會在使用者切換應用的時候做交換記憶體的操作。Android會把那些不包含Foreground組件的應用進程放到LRU Cache中。例如，當使用者開始啟動了一個應用，系統會為它建立了一個進程，但是當使用者離開這個應用，此進程並不會立即被銷毀，而是會被放到系統的Cache當中，如果使用者後來再切換回到這個應用，此進程就能夠被馬上完整的恢複，從而實現應用的快速切換。
• 如果你的應用中有一個被緩衝的進程，這個進程會佔用一定的記憶體空間，它會對系統的整體效能有影響。因此當系統開始進入Low Memory的狀態時，它會由系統根據LRU的規則與應用的優先順序，記憶體佔用情況以及其他因素的影響綜合評估之後決定是否被殺掉。
• 對於那些非foreground的進程，Android系統是如何判斷Kill掉哪些進程的問題，請參考Processes and Threads。

(二)OOM（OutOfMemory）

前面我們提到過使用getMemoryClass()的方法可以得到Dalvik Heap的閾值。簡要的擷取某個應用的記憶體佔用情況可以參考下面的樣本（ 關於更多記憶體查看的知識，可以參考這篇官方教程：Investigating Your RAM Usage ）

1）查看記憶體使用量情況

• 通過命令列查看記憶體詳細佔用情況：

• 通過Android Studio的Memory Monitor查看記憶體中Dalvik Heap的即時變化

 

2）發生OOM的條件

關於Native Heap，Dalvik Heap，Pss等記憶體管理機制比較複雜，這裡不展開描述。簡單的說，通過不同的記憶體配置方式（malloc/mmap/JNIEnv/etc）對不同的對象（bitmap，etc）進行操作會因為Android系統版本的差異而產生不同的行為，對Native Heap與Dalvik Heap以及OOM的判斷條件都會有所影響。在2.x的系統上，我們常常可以看到Heap Size的total值明顯超過了通過getMemoryClass()擷取到的閾值而不會發生OOM的情況，那麼針對2.x與4.x的Android系統，到底是如何判斷會發生OOM呢？

• Android 2.x系統 GC LOG中的dalvik allocated + external allocated + 新分配的大小 >= getMemoryClass()值的時候就會發生OOM。 例如，假設有這麼一段Dalvik輸出的GC LOG：GC_FOR_MALLOC free 2K, 13% free 32586K/37455K, external 8989K/10356K, paused 20ms，那麼32586+8989+(新分配23975)=65550>64M時，就會發生OOM。

• Android 4.x系統 Android 4.x的系統廢除了external的計數器，類似bitmap的分配改到dalvik的java heap中申請，只要allocated + 新分配的記憶體 >= getMemoryClass()的時候就會發生OOM，如所示（雖然圖示示範的是art運行環境，但是統計規則還是和dalvik保持一致）

(三)如何避免OOM總結

前面介紹了一些基礎的記憶體管理機制以及OOM的基礎知識，那麼在實踐操作當中，有哪些指導性的規則可以參考呢？歸納下來，可以從四個方面著手，首先是減小對象的記憶體佔用，其次是記憶體對象的重複利用，然後是避免對象的記憶體泄露，最後是記憶體使用量策略最佳化。

減小對象的記憶體佔用

避免OOM的第一步就是要盡量減少新分配出來的對象佔用記憶體的大小，盡量使用更加輕量的對象。

1）使用更加輕量的資料結構

例如，我們可以考慮使用ArrayMap/SparseArray而不是HashMap等傳統資料結構，示範了HashMap的簡要工作原理，相比起Android系統專門為移動作業系統編寫的ArrayMap容器，在大多數情況下，都顯示效率低下，更占記憶體。通常的HashMap的實現方式更加消耗記憶體，因為它需要一個額外的執行個體對象來記錄Mapping操作。另外，SparseArray更加高效在於他們避免了對key與value的autobox自動裝箱，並且避免了裝箱後的解箱。

關於更多ArrayMap/SparseArray的討論，請參考http://hukai.me/android-performance-patterns-season-3/的前三個段落

2）避免在Android裡面使用Enum

Android官方培訓課程提到過“Enums often require more than twice as much memory as static constants. You should strictly avoid using enums on Android.”，具體原理請參考http://hukai.me/android-performance-patterns-season-3/，所以請避免在Android裡面使用到枚舉。

3）減小Bitmap對象的記憶體佔用

Bitmap是一個極容易消耗記憶體的大胖子，減小建立出來的Bitmap的記憶體佔用是很重要的，通常來說有下面2個措施：

• inSampleSize：縮放比例，在把圖片載入記憶體之前，我們需要先計算出一個合適的縮放比例，避免不必要的大圖載入。
• decode format：解碼格式，選擇ARGB_8888/RBG_565/ARGB_4444/ALPHA_8，存在很大差異。

4）使用更小的圖片

在設計給到資源圖片的時候，我們需要特別留意這張圖片是否存在可以壓縮的空間，是否可以使用一張更小的圖片。盡量使用更小的圖片不僅僅可以減少記憶體的使用，還可以避免出現大量的InflationException。假設有一張很大的圖片被XML檔案直接引用，很有可能在初始化視圖的時候就會因為記憶體不足而發生InflationException，這個問題的根本原因其實是發生了OOM。

記憶體對象的重複利用

大多數對象的複用，最終實施的方案都是利用對象池技術，要麼是在編寫代碼的時候顯式的在程式裡面去建立對象池，然後處理好複用的實現邏輯，要麼就是利用系統架構既有的某些複用特性達到減少對象的重複建立，從而減少記憶體的分配與回收。

在Android上面最常用的一個緩衝演算法是LRU(Least Recently Use)，簡要操作原理如所示：

1）複用系統內建的資源

Android系統本身內建了很多的資源，例如字串/顏色/圖片/動畫/樣式以及簡單布局等等，這些資源都可以在應用程式中直接引用。這樣做不僅僅可以減少應用程式的自身負重，減小APK的大小，另外還可以一定程度上減少記憶體的開銷，複用性更好。但是也有必要留意Android系統的版本差異性，對那些不同系統版本上表現存在很大差異，不符合需求的情況，還是需要應用程式自身內建進去。

2）注意在ListView/GridView等出現大量重複子組件的視圖裡面對ConvertView的複用

3）Bitmap對象的複用

• 在ListView與GridView等顯示大量圖片的控制項裡面需要使用LRU的機制來緩衝處理好的Bitmap。

• 利用inBitmap的進階特性提高Android系統在Bitmap分配與釋放執行效率上的提升(3.0以及4.4以後存在一些使用限制上的差異)。使用inBitmap屬性可以告知Bitmap解碼器去嘗試使用已經存在的記憶體地區，新解碼的bitmap會嘗試去使用之前那張bitmap在heap中所佔據的pixel data記憶體地區，而不是去問記憶體重新申請一塊地區來存放bitmap。利用這種特性，即使是上千張的圖片，也只會僅僅只需要佔用螢幕所能夠顯示的圖片數量的記憶體大小。

使用inBitmap需要注意幾個限制條件：

• 在SDK 11 -> 18之間，重用的bitmap大小必須是一致的，例如給inBitmap賦值的圖片大小為100-100，那麼新申請的bitmap必須也為100-100才能夠被重用。從SDK 19開始，新申請的bitmap大小必須小於或者等於已經賦值過的bitmap大小。
• 新申請的bitmap與舊的bitmap必須有相同的解碼格式，例如大家都是8888的，如果前面的bitmap是8888，那麼就不能支援4444與565格式的bitmap了。 我們可以建立一個包含多種典型可重用bitmap的對象池，這樣後續的bitmap建立都能夠找到合適的“模板”去進行重用。如所示：

另外提一點：在2.x的系統上，儘管bitmap是分配在native層，但是還是無法避免被計算到OOM的引用計數器裡面。這裡提示一下，不少應用會通過反射BitmapFactory.Options裡面的inNativeAlloc來達到擴大使用記憶體的目的，但是如果大家都這麼做，對系統整體會造成一定的負面影響，建議謹慎採納。

4）避免在onDraw方法裡面執行對象的建立

類似onDraw等頻繁調用的方法，一定需要注意避免在這裡做建立對象的操作，因為他會迅速增加記憶體的使用，而且很容易引起頻繁的gc，甚至是記憶體抖動。

5）StringBuilder

在有些時候，代碼中會需要使用到大量的字串拼接的操作，這種時候有必要考慮使用StringBuilder來替代頻繁的“+”。

避免對象的記憶體泄露

記憶體對象的泄漏，會導致一些不再使用的對象無法及時釋放，這樣一方面佔用了寶貴的記憶體空間，很容易導致後續需要分配記憶體的時候，空閑空間不足而出現OOM。顯然，這還使得每級Generation的記憶體地區可用空間變小，gc就會更容易被觸發，容易出現記憶體抖動，從而引起效能問題。

最新的LeakCanary開原始檔控制，可以很好的協助我們發現記憶體泄露的情況，更多關於LeakCanary的介紹，請看這裡https://github.com/square/leakcanary(中文使用說明http://www.liaohuqiu.net/cn/posts/leak-canary-read-me/)。另外也可以使用傳統的MAT工具尋找記憶體泄露，請參考這裡http://android-developers.blogspot.pt/2011/03/memory-analysis-for-android.html（便捷的中文資料http://androidperformance.com/2015/04/11/AndroidMemory-Usage-Of-MAT/）

1）注意Activity的泄漏

通常來說，Activity的泄漏是記憶體流失裡面最嚴重的問題，它佔用的記憶體多，影響面廣，我們需要特別注意以下兩種情況導致的Activity泄漏：

• 內部類引用導致Activity的泄漏

最典型的情境是Handler導致的Activity泄漏，如果Handler中有延遲的任務或者是等待執行的任務隊列過長，都有可能因為Handler繼續執行而導致Activity發生泄漏。此時的參考關聯性鏈是Looper -> MessageQueue -> Message -> Handler -> Activity。為瞭解決這個問題，可以在UI退出之前，執行remove Handler訊息佇列中的訊息與runnable對象。或者是使用Static + WeakReference的方式來達到斷開Handler與Activity之間存在參考關聯性的目的。

• Activity Context被傳遞到其他執行個體中，這可能導致自身被引用而發生泄漏。

內部類引起的泄漏不僅僅會發生在Activity上，其他任何內部類出現的地方，都需要特別留意！我們可以考慮盡量使用static類型的內部類，同時使用WeakReference的機制來避免因為互相引用而出現的泄露。

2）考慮使用Application Context而不是Activity Context

對於大部分非必須使用Activity Context的情況（Dialog的Context就必須是Activity Context），我們都可以考慮使用Application Context而不是Activity的Context，這樣可以避免不經意的Activity泄露。

3）注意臨時Bitmap對象的及時回收

雖然在大多數情況下，我們會對Bitmap增加緩衝機制，但是在某些時候，部分Bitmap是需要及時回收的。例如臨時建立的某個相對比較大的bitmap對象，在經過變換得到新的bitmap對象之後，應該儘快回收原始的bitmap，這樣能夠更快釋放原始bitmap所佔用的空間。

需要特別留意的是Bitmap類裡面提供的createBitmap()方法：

這個函數返回的bitmap有可能和source bitmap是同一個，在回收的時候，需要特別檢查source bitmap與return bitmap的引用是否相同，只有在不等的情況下，才能夠執行source bitmap的recycle方法。

4）注意監聽器的登出

在Android程式裡面存在很多需要register與unregister的監聽器，我們需要確保在合適的時候及時unregister那些監聽器。自己手動add的listener，需要記得及時remove這個listener。

5）注意緩衝容器中的對象泄漏

有時候，我們為了提高對象的複用性把某些對象放到緩衝容器中，可是如果這些對象沒有及時從容器中清除，也是有可能導致記憶體流失的。例如，針對2.3的系統，如果把drawable添加到緩衝容器，因為drawable與View的強應用，很容易導致activity發生泄漏。而從4.0開始，就不存在這個問題。解決這個問題，需要對2.3系統上的緩衝drawable做特殊封裝，處理引用解除綁定的問題，避免泄漏的情況。

6）注意WebView的泄漏

Android中的WebView存在很大的相容性問題，不僅僅是Android系統版本的不同對WebView產生很大的差異，另外不同的廠商出貨的ROM裡面WebView也存在著很大的差異。更嚴重的是標準的WebView存在記憶體泄露的問題，看這裡WebView causes memory leak - leaks the parent Activity。所以通常根治這個問題的辦法是為WebView開啟另外一個進程，通過AIDL與主進程進行通訊，WebView所在的進程可以根據業務的需要選擇合適的時機進行銷毀，從而達到記憶體的完整釋放。

7）注意Cursor對象是否及時關閉

在程式中我們經常會進行查詢資料庫的操作，但時常會存在不小心使用Cursor之後沒有及時關閉的情況。這些Cursor的泄露，反覆多次出現的話會對記憶體管理產生很大的負面影響，我們需要謹記對Cursor對象的及時關閉。

記憶體使用量策略最佳化1）謹慎使用large heap

正如前面提到的，Android裝置根據硬體與軟體的設定差異而存在不同大小的記憶體空間，他們為應用程式設定了不同大小的Heap限制閾值。你可以通過調用getMemoryClass()來擷取應用的可用Heap大小。在一些特殊的情景下，你可以通過在manifest的application標籤下添加largeHeap=true的屬性來為應用聲明一個更大的heap空間。然後，你可以通過getLargeMemoryClass()來擷取到這個更大的heap size閾值。然而，聲明得到更大Heap閾值的本意是為了一小部分會消耗大量RAM的應用(例如一個大圖片的編輯應用)。不要輕易的因為你需要使用更多的記憶體而去請求一個大的Heap Size。只有當你清楚的知道哪裡會使用大量的記憶體並且知道為什麼這些記憶體必須被保留時才去使用large heap。因此請謹慎使用large heap屬性。使用額外的記憶體空間會影響系統整體的使用者體驗，並且會使得每次gc的已耗用時間更長。在任務切換時，系統的效能會大打折扣。另外, large heap並不一定能夠擷取到更大的heap。在某些有嚴格限制的機器上，large heap的大小和通常的heap size是一樣的。因此即使你申請了large heap，你還是應該通過執行getMemoryClass()來檢查實際擷取到的heap大小。

2）綜合考慮裝置記憶體閾值與其他因素設計合適的緩衝大小

例如，在設計ListView或者GridView的Bitmap LRU緩衝的時候，需要考慮的點有：

• 應用程式剩下了多少可用的記憶體空間?
• 有多少圖片會被一次呈現到螢幕上？有多少圖片需要事先緩衝好以便快速滑動時能夠立即顯示到螢幕？
• 裝置的螢幕大小與密度是多少? 一個xhdpi的裝置會比hdpi需要一個更大的Cache來hold住同樣數量的圖片。
• 不同的頁面針對Bitmap的設計的尺寸與配置是什麼，大概會花費多少記憶體？
• 頁面圖片被訪問的頻率？是否存在其中的一部分比其他的圖片具有更高的訪問頻繁？如果是，也許你想要儲存那些最常訪問的到記憶體中，或者為不同組別的位元影像(按訪問頻率分組)設定多個LruCache容器。

3）onLowMemory()與onTrimMemory()

Android使用者可以隨意在不同的應用之間進行快速切換。為了讓background的應用能夠迅速的切換到forground，每一個background的應用都會佔用一定的記憶體。Android系統會根據當前的系統的記憶體使用量情況，決定回收部分background的應用記憶體。如果background的應用從暫停狀態直接被恢複到forground，能夠獲得較快的恢複體驗，如果background應用是從Kill的狀態進行恢複，相比之下就顯得稍微有點慢。

• onLowMemory()：Android系統提供了一些回調來通知當前應用的記憶體使用量情況，通常來說，當所有的background應用都被kill掉的時候，forground應用會收到onLowMemory()的回調。在這種情況下，需要儘快釋放當前應用的非必須的記憶體資源，從而確保系統能夠繼續穩定運行。

• onTrimMemory(int)：Android系統從4.0開始還提供了onTrimMemory()的回調，當系統記憶體達到某些條件的時候，所有正在啟動並執行應用都會收到這個回調，同時在這個回調裡面會傳遞以下的參數，代表不同的記憶體使用量情況，收到onTrimMemory()回調的時候，需要根據傳遞的參數類型進行判斷，合理的選擇釋放自身的一些記憶體佔用，一方面可以提高系統的整體運行流暢度，另外也可以避免自己被系統判斷為優先需要殺掉的應用。介紹了各種不同的回調參數：

• TRIM_MEMORY_UI_HIDDEN：你的應用程式的所有UI介面被隱藏了，即使用者點擊了Home鍵或者Back鍵退出應用，導致應用的UI介面完全不可見。這個時候應該釋放一些不可見的時候非必須的資源

當程式正在前台啟動並執行時候，可能會接收到從onTrimMemory()中返回的下面的值之一：

• TRIM_MEMORY_RUNNING_MODERATE：你的應用正在運行並且不會被列為可殺死的。但是裝置此時正運行於低記憶體狀態下，系統開始觸發殺死LRU Cache中的Process的機制。
• TRIM_MEMORY_RUNNING_LOW：你的應用正在運行且沒有被列為可殺死的。但是裝置正運行於更低記憶體的狀態下，你應該釋放不用的資源用來提升系統效能。
• TRIM_MEMORY_RUNNING_CRITICAL：你的應用仍在運行，但是系統已經把LRU Cache中的大多數進程都已經殺死，因此你應該立即釋放所有非必須的資源。如果系統不能回收到足夠的RAM數量，系統將會清除所有的LRU緩衝中的進程，並且開始殺死那些之前被認為不應該殺死的進程，例如那個包含了一個運行態Service的進程。

當應用進程退到後台正在被Cached的時候，可能會接收到從onTrimMemory()中返回的下面的值之一：

• TRIM_MEMORY_BACKGROUND: 系統正運行於低記憶體狀態並且你的進程正處於LRU緩衝名單中最不容易殺掉的位置。儘管你的應用進程並不是處於被殺掉的高危險狀態，系統可能已經開始殺掉LRU緩衝中的其他進程了。你應該釋放那些容易恢複的資源，以便於你的進程可以保留下來，這樣當使用者回退到你的應用的時候才能夠迅速恢複。
• TRIM_MEMORY_MODERATE: 系統正運行於低記憶體狀態並且你的進程已經已經接近LRU名單的中部位置。如果系統開始變得更加記憶體緊張，你的進程是有可能被殺死的。
• TRIM_MEMORY_COMPLETE: 系統正運行於低記憶體的狀態並且你的進程正處於LRU名單中最容易被殺掉的位置。你應該釋放任何不影響你的應用恢複狀態的資源。

• 因為onTrimMemory()的回調是在API 14才被加進來的，對於老的版本，你可以使用onLowMemory)回調來進行相容。onLowMemory相當與TRIM_MEMORY_COMPLETE。
• 請注意：當系統開始清除LRU緩衝中的進程時，雖然它首先按照LRU的順序來執行操作，但是它同樣會考慮進程的記憶體使用量量以及其他因素。佔用越少的進程越容易被留下來。

4）資源檔需要選擇合適的檔案夾進行存放

我們知道hdpi/xhdpi/xxhdpi等等不同dpi的檔案夾下的圖片在不同的裝置上會經過scale的處理。例如我們只在hdpi的目錄下放置了一張100100的圖片，那麼根據換算關係，xxhdpi的手機去引用那張圖片就會被展開到200200。需要注意到在這種情況下，記憶體佔用是會顯著提高的。對於不希望被展開的圖片，需要放到assets或者nodpi的目錄下。

5）Try catch某些大記憶體配置的操作

在某些情況下，我們需要事先評估那些可能發生OOM的代碼，對於這些可能發生OOM的代碼，加入catch機制，可以考慮在catch裡面嘗試一次降級的記憶體配置操作。例如decode bitmap的時候，catch到OOM，可以嘗試把採樣比例再增加一倍之後，再次嘗試decode。

6）謹慎使用static對象

因為static的生命週期過長，和應用的進程保持一致，使用不當很可能導致對象泄漏，在Android中應該謹慎使用static對象。

7）特別留意單例對象中不合理的持有

雖然單例模式簡單實用，提供了很多便利性，但是因為單例的生命週期和應用保持一致，使用不合理很容易出現持有對象的泄漏。

8）珍惜Services資源

如果你的應用需要在後台使用service，除非它被觸發並執行一個任務，否則其他時候Service都應該是停止狀態。另外需要注意當這個service完成任務之後因為停止service失敗而引起的記憶體流失。 當你啟動一個Service，系統會傾向為了保留這個Service而一直保留Service所在的進程。這使得進程的運行代價很高，因為系統沒有辦法把Service所佔用的RAM空間騰出來讓給其他組件，另外Service還不能被Paged out。這減少了系統能夠存放到LRU緩衝當中的進程數量，它會影響應用之間的切換效率，甚至會導致系統記憶體使用量不穩定，從而無法繼續保持住所有目前正在啟動並執行service。 建議使用IntentService，它會在處理完交代給它的任務之後儘快結束自己。更多資訊，請閱讀Running in a Background Service。

9）最佳化布局層次，減少記憶體消耗

越扁平化的視圖布局，佔用的記憶體就越少，效率越高。我們需要盡量保證布局足夠扁平化，當使用系統提供的View無法實現足夠扁平的時候考慮使用自訂View來達到目的。

10）謹慎使用“抽象”編程

很多時候，開發人員會使用抽象類別作為”好的編程實踐”，因為抽象能夠提升代碼的靈活性與可維護性。然而，抽象會導致一個顯著的額外記憶體開銷：他們需要同等量的代碼用於可執行，那些代碼會被mapping到記憶體中，因此如果你的抽象沒有顯著的提升效率，應該盡量避免他們。

11）使用nano protobufs序列化資料

Protocol buffers是由Google為序列化結構資料而設計的，一種語言無關，平台無關，具有良好的擴充性。類似XML，卻比XML更加輕量，快速，簡單。如果你需要為你的資料實現序列化與協議化，建議使用nano protobufs。關於更多細節，請參考protobuf readme的”Nano version”章節。

12）謹慎使用依賴注入架構

使用類似Guice或者RoboGuice等架構注入代碼，在某種程度上可以簡化你的代碼。下面是使用RoboGuice前後的對比圖：

 

使用RoboGuice之後，代碼是簡化了不少。然而，那些注入架構會通過掃描你的代碼執行許多初始化的操作，這會導致你的代碼需要大量的記憶體空間來mapping代碼，而且mapped pages會長時間的被保留在記憶體中。除非真的很有必要，建議謹慎使用這種技術。

13）謹慎使用多進程

使用多進程可以把應用中的部分組件運行在單獨的進程當中，這樣可以擴大應用的記憶體佔用範圍，但是這個技術必須謹慎使用，絕大多數應用都不應該貿然使用多進程，一方面是因為使用多進程會使得代碼邏輯更加複雜，另外如果使用不當，它可能反而會導致顯著增加記憶體。當你的應用需要運行一個常駐背景任務，而且這個任務並不輕量，可以考慮使用這個技術。

一個典型的例子是建立一個可以長時間後台播放的Music Player。如果整個應用都運行在一個進程中，當後台播放的時候，前台的那些UI資源也沒有辦法得到釋放。類似這樣的應用可以切分成2個進程：一個用來操作UI，另外一個給背景Service。

14）使用ProGuard來剔除不需要的代碼

ProGuard能夠通過移除不需要的代碼，重新命名類，域與方法等等對代碼進行壓縮，最佳化與混淆。使用ProGuard可以使得你的代碼更加緊湊，這樣能夠減少mapping代碼所需要的記憶體空間。

15）謹慎使用第三方libraries

很多開源的library代碼都不是為移動網路環境而編寫的，如果運用在行動裝置上，並不一定適合。即使是針對Android而設計的library，也需要特別謹慎，特別是在你不知道引入的library具體做了什麼事情的時候。例如，其中一個library使用的是nano protobufs, 而另外一個使用的是micro protobufs。這樣一來，在你的應用裡面就有2種protobuf的實現方式。這樣類似的衝突還可能發生在輸出日誌，載入圖片，緩衝等等模組裡面。另外不要為了1個或者2個功能而匯入整個library，如果沒有一個合適的庫與你的需求相吻合，你應該考慮自己去實現，而不是匯入一個大而全的解決方案。

16）考慮不同的實現方式來最佳化記憶體佔用

在某些情況下，設計的某個方案能夠快速實現需求，但是這個方案卻可能在記憶體佔用上表現的效率不夠好。例如：

對於上面這樣一個時鐘錶盤的實現，最簡單的就是使用很多張包含指標的錶盤圖片，使用幀動畫實現指標的旋轉。但是如果把指標扣出來，單獨進行旋轉繪製，顯然比載入N多張圖片佔用的記憶體要少很多。當然這樣做，代碼複雜度上會有所增加，這裡就需要在最佳化記憶體佔用與實現簡易度之間進行權衡了。

寫在最後：

• 設計風格很大程度上會影響到程式的記憶體與效能，相對來說，如果大量使用類似Material Design的風格，不僅安裝包可以變小，還可以減少記憶體的佔用，渲染效能與載入效能都會有一定的提升。
• 記憶體最佳化並不就是說程式佔用的記憶體越少就越好，如果因為想要保持更低的記憶體佔用，而頻繁觸發執行gc操作，在某種程度上反而會導致應用效能整體有所下降，這裡需要綜合考慮做一定的權衡。
• Android的記憶體最佳化涉及的知識面還有很多：記憶體管理的細節，記憶體回收的工作原理，如何尋找記憶體流失等等都可以展開講很多。OOM是記憶體最佳化當中比較突出的一點，盡量減少OOM的機率對記憶體最佳化有著很大的意義。

Android記憶體最佳化之OOM