在 Android 系統中有個垃圾內存回收機制，在虛擬機層自動分配和釋放內存，因此不需要在代碼中分配和釋放某一塊內存，從應用層面上不容易出現內存泄漏和內存溢出等問題，但是需要內存管理。Android 系統在內存管理上有一個 Generational Heap Memory 模型，內存回收的大部分壓力不需要應用層關心， Generational Heap Memory 有自己一套管理機制，當內存達到一個閾值時，系統會根據不同的規則自動釋放系統認為可以釋放的內存，也正是因為 Android 程序把內存控制的權力交給了 Generational Heap Memory，一旦出現內存泄漏和溢出方面的問題，排查錯誤將會成為一項異常艱難的工作。除此之外，部分 Android 應用開發人員在開發過程中并沒有特別關注內存的合理使用，也沒有在內存方面做太多的優化，當應用程序同時運行越來越多的任務，加上越來越復雜的業務需求時，完全依賴 Android 的內存管理機制就會導致一系列性能問題逐漸呈現，對應用的穩定性和性能帶來不可忽視的影響，因此，解決內存問題和合理優化內存是非常有必要的。

Android內存管理機制

Android 應用都是在 Android 的虛擬機上運行，應用 程序的內存分配與垃圾回收都是由虛擬機完成的。在 Android 系統，虛擬機有兩種運行模式：Dalvik 和 ART。

1、Java對象生命周期

一般Java對象在虛擬機上有7個運行階段：

創建階段->應用階段->不可見階段->不可達階段->收集階段->終結階段->對象空間重新分配階段

2、內存分配

在 Android 系統中，內存分配實際上是對堆的分配和釋放。當一個 Android 程序啟動，應用進程都是從一個叫做 Zygote 的進程衍生出來，系統啟動 Zygote 進程后，為了啟動一個新的應用程序進程，系統會衍生 Zygote 進程生成一個新的進程，然后在新的進程中加載并運行應用程序的代碼。其中，大多數的 RAM pages 被用來分配給Framework 代碼，同時促使 RAM 資源能夠在應用所有進程之間共享。

但是為了整個系統的內存控制需要，Android 系統會為每一個應用程序都設置一個硬性的 Dalvik Heap Size 最大限制閾值，整個閾值在不同設備上會因為 RAM 大小不同而有所差異。如果應用占用內存空間已經接近整個閾值時，再嘗試分配內存的話，就很容易引起內存溢出的錯誤。

3、內存回收機制

我們需要知道的是，在 Java 中內存被分為三個區域：Young Generation(年輕代)、Old Generation(年老代)、Permanent Generation(持久代)。最近分配的對象會存放在 Young Generation 區域。對象在某個時機觸發 GC 回收垃圾，而沒有回收的就根據不同規則，有可能被移動到 Old Generation，最后累積一定時間在移動到 Permanent Generation 區域。系統會根據內存中不同的內存數據類型分別執行不同的 GC 操作。GC 通過確定對象是否被活動對象引用來確定是否收集對象，進而動態回收無任何引用的對象占據的內存空間。但需要注意的是頻繁的 GC 會增加應用的卡頓情況，影響應用的流暢性，因此需要盡量減少系統 GC 行為，以便提高應用的流暢度，減小卡頓發生的概率。

內存分析工具

做內存優化前，需要了解當前應用的內存使用現狀，通過現狀去分析哪些數據類型有問題，各種類型的分布情況如何，以及在發現問題后如何發現是哪些具體對象導致的，這就需要相關工具來幫助我們。

1、Memory Monitor

Memory Monitor 是一款使用非常簡單的圖形化工具，可以很好地監控系統或應用的內存使用情況，主要有以下功能：

顯示可用和已用內存，并且以時間為維度實時反應內存分配和回收情況。

快速判斷應用程序的運行緩慢是否由于過度的內存回收導致。

快速判斷應用是否由于內存不足導致程序崩潰。

2、Heap Viewer

Heap Viewer 的主要功能是查看不同數據類型在內存中的使用情況，可以看到當前進程中的 Heap Size 的情況，分別有哪些類型的數據，以及各種類型數據占比情況。通過分析這些數據來找到大的內存對象，再進一步分析這些大對象，進而通過優化減少內存開銷，也可以通過數據的變化發現內存泄漏。

3、Allocation Tracker

Memory Monitor 和 Heap Viewer 都可以很直觀且實時地監控內存使用情況，還能發現內存問題，但發現內存問題后不能再進一步找到原因，或者發現一塊異常內存，但不能區別是否正常，同時在發現問題后，也不能定位到具體的類和方法。這時就需要使用另一個內存分析工具 Allocation Tracker，進行更詳細的分析， Allocation Tracker 可以分配跟蹤記錄應用程序的內存分配，并列出了它們的調用堆棧，可以查看所有對象內存分配的周期。

4、Memory Analyzer Tool(MAT)

MAT 是一個快速，功能豐富的 Java Heap 分析工具，通過分析 Java 進程的內存快照 HPROF 分析，從眾多的對象中分析，快速計算出在內存中對象占用的大小，查看哪些對象不能被垃圾收集器回收，并可以通過視圖直觀地查看可能造成這種結果的對象。

常見內存泄漏場景

如果在內存泄漏發生后再去找原因并修復會增加開發的成本，最好在編寫代碼時就能夠很好地考慮內存問題，寫出更高質量的代碼，這里列出一些常見的內存泄漏場景，在以后的開發過程中需要避免這類問題。

資源性對象未關閉。比如Cursor、File文件等，往往都用了一些緩沖，在不使用時，應該及時關閉它們。

注冊對象未注銷。比如事件注冊后未注銷，會導致觀察者列表中維持著對象的引用。

類的靜態變量持有大數據對象。

非靜態內部類的靜態實例。

Handler臨時性內存泄漏。如果Handler是非靜態的，容易導致 Activity 或 Service 不會被回收。

容器中的對象沒清理造成的內存泄漏。

WebView。WebView 存在著內存泄漏的問題，在應用中只要使用一次 WebView，內存就不會被釋放掉。

除此之外，內存泄漏可監控，常見的就是用LeakCanary 第三方庫，這是一個檢測內存泄漏的開源庫，使用非常簡單，可以在發生內存泄漏時告警，并且生成 leak tarce 分析泄漏位置，同時可以提供 Dump 文件進行分析。

優化內存空間

沒有內存泄漏，并不意味著內存就不需要優化，在移動設備上，由于物理設備的存儲空間有限，Android 系統對每個應用進程也都分配了有限的堆內存，因此使用最小內存對象或者資源可以減小內存開銷，同時讓GC 能更高效地回收不再需要使用的對象，讓應用堆內存保持充足的可用內存，使應用更穩定高效地運行。

常見做法如下：

對象引用。強引用、軟引用、弱引用、虛引用四種引用類型，根據業務需求合理使用不同，選擇不同的引用類型。

減少不必要的內存開銷。注意自動裝箱，增加內存復用，比如有效利用系統自帶的資源、視圖復用、對象池、Bitmap對象的復用。

使用最優的數據類型。比如針對數據類容器結構，可以使用ArrayMap數據結構，避免使用枚舉類型，使用緩存Lrucache等等。

圖片內存優化。可以設置位圖規格，根據采樣因子做壓縮，用一些圖片緩存方式對圖片進行管理等等。