內(nèi)存優(yōu)化

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

Android內(nèi)存管理機制

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

1、Java對象生命周期

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

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

2、內(nèi)存分配

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

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

3、內(nèi)存回收機制

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

內(nèi)存分析工具

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

1、Memory Monitor

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

• 顯示可用和已用內(nèi)存，并且以時間為維度實時反應內(nèi)存分配和回收情況。
• 快速判斷應用程序的運行緩慢是否由于過度的內(nèi)存回收導致。
• 快速判斷應用是否由于內(nèi)存不足導致程序崩潰。

2、Heap Viewer

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

3、Allocation Tracker

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

4、Memory Analyzer Tool(MAT)

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

常見內(nèi)存泄漏場景

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

• 資源性對象未關閉。比如Cursor、File文件等，往往都用了一些緩沖，在不使用時，應該及時關閉它們。
• 注冊對象未注銷。比如事件注冊后未注銷，會導致觀察者列表中維持著對象的引用。
• 類的靜態(tài)變量持有大數(shù)據(jù)對象。
• 非靜態(tài)內(nèi)部類的靜態(tài)實例。
• Handler臨時性內(nèi)存泄漏。如果Handler是非靜態(tài)的，容易導致 Activity 或 Service 不會被回收。
• 容器中的對象沒清理造成的內(nèi)存泄漏。
• WebView。WebView 存在著內(nèi)存泄漏的問題，在應用中只要使用一次 WebView，內(nèi)存就不會被釋放掉。

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

優(yōu)化內(nèi)存空間

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

常見做法如下：

• 對象引用。強引用、軟引用、弱引用、虛引用四種引用類型，根據(jù)業(yè)務需求合理使用不同，選擇不同的引用類型。
• 減少不必要的內(nèi)存開銷。注意自動裝箱，增加內(nèi)存復用，比如有效利用系統(tǒng)自帶的資源、視圖復用、對象池、Bitmap對象的復用。
• 使用最優(yōu)的數(shù)據(jù)類型。比如針對數(shù)據(jù)類容器結構，可以使用ArrayMap數(shù)據(jù)結構，避免使用枚舉類型，使用緩存Lrucache等等。
• 圖片內(nèi)存優(yōu)化?？梢栽O置位圖規(guī)格，根據(jù)采樣因子做壓縮，用一些圖片緩存方式對圖片進行管理等等。