Android內存優化全解析

本文已同步發表到個人技術微信公衆號，掃一掃文章底部的二維碼或在微信搜索 「程序員驛站」便可關注，天天都會更新優質技術文章。

Android的內存優化，一直是個讓開發者頭痛的問題，這篇文章是」Android電量優化全解析「後關於Android性能的又一篇原創文章，但願對你們有所幫助。今天我講述的內容按照下面的結構進行。

Android電量優化全解析

內存與垃圾回收器

不是全部指令都執行得又快又好，下面介紹內存及它如何影響系統運行。

廣泛認爲，多數程序語言接近硬件或高性能，如C、C++和Fortran，一般程序員會本身管理內存，高手工程師對內存的分配，會慎重處理，並在將來結束使用時再次分配，一旦確認什麼時候及怎樣分配內存，內存管理的品質就依賴於工程師的技能跟效率。實際狀況是工程師們，不都會去追蹤那零碎的內存碎片。程序開發是個混亂又瘋狂的過程，內存一般都沒辦法徹底被釋放，這些被囚禁的內存叫內存泄露。

內存泄露佔用了大量資源，這些資源其實能夠更好地使用，爲減小泄露引發的混亂、負擔、甚至資金損失，便有了內存管理語言。

這些語言在運行時跟蹤內存分配，以便當程序再也不須要時釋放系統內存，徹底不用工程師親自操做，這些內存回收藝術或科學，在內存管理環節下叫垃圾清理。這個設計概念在1959年，當初爲了解決lisp語言問題，由John McCarthy發明的。

垃圾清理的基本概念有：

• 第一，找到將來沒法存取的數據，例如全部不受指令操控的內存。
• 第二，回收被利用過的資源。

原理簡單，可是兩百萬行編碼，跟4gigs的分配，在實際操做時卻很是困難。若是在程序中有20000個對象分配，垃圾清理會讓人困惑，哪個是沒用的？或者，什麼時候啓動垃圾清理釋放內存？這些問題其實很複雜。好在50年來，咱們找到了解決問題的方法，就是Android Runtime中的垃圾清理。比McCarthy最初的方法更高級，速度快且是非侵入性的。經由分配類型，及系統如何有效地組織分配以利GC的運行，並做爲新的配置。全部影響android runtime的內存堆都被分割到空間中，根據這些特色，哪些數據適合放到什麼空間，取決於哪一個Android版本。

最重要的一點是，每一個空間都有預設的大小，在分配目標時要跟蹤綜合大小，且空間不斷地擴大，系統須要執行垃圾清理，以確保內存分配的正常運行，值得一提的是使用不一樣的Android runtime，GC的運行方式就會不一樣。例如在Dalvik中不少GC是中止事件，意思是不少指令的運行直到操做完成纔會中止。

當這些GCs所用時間超過通常值，或者一大堆一塊兒執行會耗費龐大的幀象時間，這是很麻煩的事情。

Android工程師花費大量時間下降干擾，確保這些程序以最快的速度運行，話雖如此，在指令中影響程序執行的問題仍然存在，首先程序在任意幀內執行GCs所用的時間越多，消除少於16毫秒的呈像障礙，所必需的時間就會變少，若是有許多GCs或一大串指令一個接一個地操做，幀象時間極可能會超過16毫秒的呈像障礙，這會致使隱形的碰撞或閃躲。其次，指令流程可能形成GCs強制執行的次數增多，或者，執行時間超過正常值。例如，在一個長期運行的循環最內側分配囤積對象，不少數據就會污染內存堆，立刻就會有許多GCs啓動，因爲這一額外的內存壓力，雖然內存環境管理良好，計算比其餘語言複雜，內存泄露仍會產生，這些漏洞在GCs啓動時，經過沒法被釋放的數據污染內存堆，嚴重下降可用空間的總量，並以常規方式強制GC的執行。就是這樣，若是要減小任意幀內啓動GC的次數，須要着重優化程序的內存使用量，從指令的角度看，或許很難追蹤這些問題的原由，可是，多虧Android SDK擁有一組不錯的工具。

Memory Monitor工具

咱們來介紹一個叫做Memory Monitor的工具，Memory Monitor用於測試程序在一段時間後佔用了多少內存，下面來操做一下。點擊打開，而後會在Android Studio右下邊的視窗裏，開啓一個製表鍵，一旦發如今運行的程序，就會立刻開始記錄內存使用量，正如這裏所示，在Memory Monitor視窗的左上端，能夠切換當前鏈接的裝置，右邊這裏能夠選擇要監測的程序。幾乎佔用所有視窗的疊層圖，表示還有多少內存可用。深藍色的區域，表示當前正在使用中的內存總量，淺藍色或者淺灰色區域，表示空閒內存或者叫做未分配內存。圖表會在內存使用量變化時不斷更新，隨着時間推移，它也會不斷顯示可用內存量。隨着時間推移，它也會不斷顯示可用內存量，總之，若是程序都沒有在運行，圖表就徹底是平坦的。

光從性能角度看，這是至關理想的狀態，但隨着程序分配跟內存釋放，圖表的分配總量也在跟着變化。若是要裝的程序急需大量內存，內存分配也急劇增長，顯示在空格里，否則的話，裝置內存不足會致使死機。因此對於內存分配，無論何時都要特別當心，當垃圾清理開啓時就要特別留意內存量，在這個範例中垃圾清理運做良好。另外，如圖所示這裏也可能有問題，這裏有個程序佔用了大量內存，而後又一會兒釋放了剛被佔用的內存。生成這些又細又窄的鋒線，不斷重複，這就是程序在花大量時間運行垃圾清理，運行垃圾清理所用的時間越多，其餘可用時間就越少，像播放和發送錄音。咱們來看下實際狀況。
momory monitor已經在監測Sunshine狀況了，點擊一個日期，看下具體內容，點擊返回鍵，重複這個動做，內存就會持續被佔用，如這裏所顯示的。若是想要新的數據，只要改變幾回座標就好了，看下所得的天氣預報，不錯，星期三天氣明朗。內存被慢慢的佔用，最終，內存會被所有佔用，這種狀況若是持續下去，垃圾清理就會啓動，釋放大塊的內存，這裏能夠看到變化。要記得，由於Android內存管理系統是固有的，因此垃圾清理不會釋放全部的內存。咱們的利器，能夠強制執行單項的垃圾清理，在Memory Monitor的左上方有個garbage truck工具，單擊一下，就會開啓單項的垃圾清理，注意圖表右邊的變化。如今能夠多點擊幾回，再繼續點擊，全部可被釋放的內存都會被釋放，裝置會恢復到初始狀態。接下來咱們將瞭解內存泄露和heap viewer工具。

內存泄露

Android的Java語言有個最大的優勢，是託管內存環境，對象在建立或消除時不用特別當心。這點儘管不錯，但也有些潛在的問題不易被發現。劃分到Android運行時的內存堆，是根據聲明類型和利於垃圾清理操做的角度來分配的，每一區域都有其預設的內存空間。

當一個程序所需的總存儲空間接近上限，垃圾清理就會啓動，刪除掉沒用的數據，通常狀況下不用特別注意垃圾清理的執行。

可是大量的清理動做不斷地重複，很快地消耗掉幀像週期，花費在垃圾清理上的時間越多，播放或發送錄音等事情的時間就越少。

工程師們製造的內存泄露，是垃圾清理運行的常見因素，內存泄露是不能被繼續使用的空間，可是垃圾收集器卻沒法辨別出來，結果他們就一直存在於堆中，佔用有效空間，永遠沒法被刪除，隨着內存不斷泄露，堆中的可用空間就不斷變小，這意味着爲了執行經常使用的程序，垃圾清理須要啓動的次數愈來愈多

搜索跟修復泄露是個很棘手的問題，有些泄露很容易就會產生，例如對沒有使用的對象的循環引用。不過有些也很複雜，例如，在類別載入器安裝未完成就強制執行，無論怎樣，一個程序想要運行得又快又好，就需留意可能存在的內存泄露。你的代碼將容許在各類各樣的設備上，又互相結合，不是全部的數據都佔用一樣的內存，不過，還在有一個簡單的工具，能夠查看Android SDK中潛在的漏洞。

Heap Viewer工具

Heap Viewer是個很簡單的工具，利用它能夠查看內存狀態，以及空間佔用率的狀況。經過Heap Viewer可知程序在特定時間內的內存使用量，跟原來同樣，先在裝置上打開Android Studio裏的sunshine，在執行start Heap Viewer前，先打開Android Device Monitor。 咱們看到，每次垃圾清理後，Heap都會更新，點擊Cause GC，發現全部的數據都更新了，更新後的表格顯示，在Heap上哪些數據是可用的，選中其中任一行數據，就能夠看到詳細數據，點擊class object，屏幕上立刻出現大量更新的數據，矩形圖列出這一數據內存分配的數量，跟確切的容量。咱們這裏討論的是class object，heap viewer能夠有效地分析程序在堆中所分配的數據類型，以及數量和大小。這裏列出在堆中各別類型程序的總容量，例如，這兩個在堆裏超過1400的數據組，用掉約1200個千字節，而這個只有27的數據組，卻佔用了約2個兆字節。heap viewer可以準確地，辨別出程序分配的類型和數量，以及各自在堆中的容量。比方說，這個27的數據組佔用了近2兆的字節，可這4個2000的數據組，目前佔用了228個千字節。在搜索內存漏洞時，這是個至關不錯的工具。

使用Memory Monitor觀察內存泄露

討論下內存泄露的問題，內存泄露的行蹤，經常神出鬼沒，常慢慢不動聲色的出現，有時要幾天或幾個星期後，纔會被發現。實際上，可能到程序莫名其妙地操做緩慢時，纔會發現內存不足的問題。只要用對工具，耐心分析，解決內存泄露不是難事。首先用Memory Monitor，觀察漏洞是怎樣生成的，在下一個影片中，再利用Heap Viewer作初步確認。舉例說明漏洞的生成，以及SDK工具，如何偵測這樣微小的漏洞，先把手機旋轉幾下，而後打開Memory Monitor，這樣作的目的是要說明，一個簡單的動做就會產生漏洞。像這樣不斷改變手機方向，就會有漏洞產生，聽起來很奇怪，可是藉由這一動做，可知漏洞是怎麼緩慢且隱祕地產生的。首先，漏洞慢慢吞噬程序內的可用內存，直到GC的啓動，再來，值得注意的是因爲程序上有漏洞，致使GC沒法回收所有垃圾。結果大約30秒後，就會啓動第二次GC，當漏洞吞噬全部的可用內存時，Android調整並分配給程序更高的內存上限。這樣作的同時，若是漏洞沒有修復，內存會不斷地被吞噬，結果致使系統沒法再配置，手機也就沒辦法再用了，最後死機。稍等下，第三次的GC就會啓動，第四次跟前兩次相似，如今這組指令在持續運行，系統分配更多的內存量，能夠用一樣的方法操做Heap Viewer。

使用Heap Viewer觀察內存泄露

經過Heap Viewer，可知第一次GC僅釋放了1.39兆內存，這種結果顯示，由於漏洞的存在，垃圾清理沒法回收所有垃圾。Heap viewer顯示第二次GC後，系統必須經由配置更多的內存，來調整內存量。堆從第一次GC的20兆，增長到32兆，這次Java堆釋放了12.9兆，這是，系統不斷地爲程序配置更多的內存。以上動做若是一再重複，系統終會沒法配置內存，程序也就掛了。切記，內存漏洞很是緩慢又不易被發現，須要時間，跟適當的環境來確認，有時，這樣的數據，也表示內存的正當存取。好比，處理圖片跟照片的程序，表面看似內存在泄露，實際上它針對核心功能的存儲器，不停地進行數據評估。所以，要明白內存泄露如何顯示在SD上，也要清楚，內存泄露如何顯示在擁有SDK的工具上，如Memory Monitor和Heap Viewer。可是，各位可能不知道他們源於何地，如下這些方法能夠防止漏洞的出現。利用編碼查看程序的壽命，清理不用的文件，接下來，辨別漏洞產生的緣由。

追蹤內存泄露的代碼

ListenerCollector.java

import android.view.View;

import java.util.WeakHashMap;

public class ListenerCollector {
    static private MyView.MyListener   sListener;

    public void setsListener(View view, MyView.MyListener listener){ 
        sListener =  listener;
    }
}

MyView.java

import android.content.Context;
import android.view.View;


public class MyView extends View{
    public  MyView(Context context){
        super(context);
        init();
    }

    public interface MyListener{
        public void myListenerCallback();
    }

    private void init(){
        ListenerCollector collector = new ListenerCollector();
        collector.setsListener(this,myListener);
    }

    public MyListener myListener = new MyListener() {
        @Override
        public void myListenerCallback() {
            System.out.print("有被調用");
        }
    };

}

注意到自定義控件init方法中以下代碼：

private void init() {
    ListenerCollector collector = new ListenerCollector();
    collector.setListener(this, mListener);
}

存儲一個Activity中全部視圖監聽器，這個想法看似無害，但若是你忘了清理它們，你可能會不經意地形成一個緩慢的泄漏。相關代碼：

collector.setListener(this, mListener);

當Activity被銷燬和建立時，這一問題被複雜化。在示例中，因爲設備的方向變化使一個新的Activity建立，相關聯的監聽被建立，可是當Activity被銷燬時，該監聽永遠不會被釋放。這意味着，監聽沒法被GC回收，這裏致使了內存泄露。當設備旋轉並調用當前Activity的onStop方法時，必定要清理全部視圖的監聽。

ListenerCollector能夠作以下優化：

import android.view.View;

import java.util.WeakHashMap;

public class ListenerCollector {
    static private WeakHashMap<View,MyView.MyListener> sListener = new WeakHashMap<>();

    public void setsListener(View view, MyView.MyListener listener){ 
        sListener.put(view,listener);
    }

    public static void clearListeners(){
        //移除全部監聽。
        sListener.clear();
    };
}

使用Allocation Tracker觀察內存泄露

另外，分配追蹤器，能夠辨別額外的內存膨脹，這是因爲內存的歷史瀏覽記錄不斷擴充產生的。選擇一組仍在堆中的數據或者程序，這組數據堆中，在這個操做裏，堆中數據叫做onCreate。這樣一來，手機每旋轉一次就有新的動做，相似的數據組，基本上就會在堆中膨脹。因此，若是在漏洞存在時旋轉手機，垃圾清理沒法清除這些數據，就會在堆中產生大量的垃圾。藉由分配追蹤器，能夠弄清這一問題。

什麼是內存抖動？

咱們解決了哪些討厭的泄露，如今遇到了更大的問題，內存抖動。要知道，堆內存都有必定的大小，能容納的數據是有限制的，當Java堆的大小太大時，垃圾收集會啓動中止堆中再也不應用的對象，來釋放內存。如今，內存抖動這個術語可用於描述在極短期內分配給對象的過程。例如，當你在循環語句中配置一系列臨時對象，或者在繪圖功能中配置大量對象時，這至關於內循環，當屏幕須要從新繪製或出現動畫時，你須要一幀幀使用這些功能，不過它會迅速增長你的堆的壓力。這兩種狀況下，咱們都制定瞭解決方案，可在短期內創造大量的對象。根據創造的對象的量，或者每一個對象的大小，你可能很快就消耗掉全部剩餘內存，致使垃圾收集強行開啓。隨着它們的開啓運行，會消耗更多寶貴的幀時間，因此，高性能的應用頗有必要，你須要鑑別並從內循環裏，取消會被重複執行的代碼配置。爲了更好的尋找到這些代碼配置，Android Studio爲此特別打造了一個方便的工具.

使用Allocation Tracker

如今看一下你的應用內存分配圖，這能有效的獲悉大部分數據到底用在哪裏，以及正在分配哪一種類型的數據，這能幫你找到現有的沒必要要分配的數據。惋惜Heap Viewer不能顯示你的數據具體分配在代碼的何處，爲此，咱們須要一個叫作分配追蹤器的工具。和之前同樣，咱們打開Android Studio Device Monitor，在前臺載入Sunshine，打開DDMS視圖點擊start allocation tracking按鈕，而後使用應用，隔一段時間在點擊stop allocation tracking按鈕。中止以後在DDMS出現了一個列表，這個列表顯示了你在使用應用期間，全部的分配狀況，這裏的每一行都表明不一樣的分配，allocation order這一欄會提示你，分配進行的具體時間，分配類別這一欄顯示了分配數據的類型，以及大小，還有其餘信息來告訴你哪一個線程具體決定了這一分配。最後，分配站這一欄告訴你代碼的哪個功能實際分配了內存。好比，咱們選擇整型，測試的值決定了這個整型的分配，若是你點擊一個分配，你能夠看見完整的調用堆棧。這個表格包含大量信息！

經過Trace View找出內存抖動

本次練習，咱們來運行內存抖動活動。下面點這個按鈕，對數組來點有意思的事情，你會發現跳着舞的海盜會暫停，但最後都會接着跳舞。這就是討厭的卡頓，讓咱們解決它吧。經過跟蹤顯示來剖析這個活動，打開trace view的面板，注意短期內發生的頻繁的垃圾收集活動，可能會傷害到應用的性能。記住，咱們還能夠採集這個內存監控器圖像，這個截屏展現了內存抖動是怎樣經過Memory Monitor清晰顯示的。

什麼致使了內存抖動？

咱們已經使用SDK工具採集足夠多的數據，能知道內存抖動狀況出現的時間，如今來揪出致使這種狀況的代碼吧。Trace View給咱們提供了一個方法，讓咱們仔細看一下在主線程裏，選擇方式時的數據配置文件，當你選擇主線程方式時，你會發現反覆出現的Java字符串賦值操做，好比這個。再看調用堆棧，咱們會更加肯定數據隊列副本被運用於擴大字符串緩衝。來看MemoryChurnActivity的源代碼，正如OnClickListener所顯示，咱們稱此功能爲imPrettySureSortingIsFree，讓咱們來看這個代碼。此處的方法叫做imPrettySureSortingIsFree，這個代碼產生了新的字符串，經過字符串鏈接每次都有一個單元值，看一下我說的這個代碼的指導提示，可是，出現鏈接的地方比較特別。這個初看起來彷佛沒什麼問題，爲何這個代碼會致使內存抖動？ 頻繁使用垃圾清理會形成兩種後果，一是，每一個單元值的連結都會生成新的字符數組，這是由於，在循環以內驟然接到重複指令組合而成，二是，經過定位追蹤器，確認字符數組的膨脹，更新一下數據，在下一節中，向你們介紹所得的結果。

修改代碼減小內存抖動

咱們能夠在咱們的代碼進行小的調整，以防止內存抖動。讓咱們來看看對比圖，而不是在一個時間串聯一個單元格值打造每一行，讓咱們使用一個StringBuilder實例，並用一個字符串構造每一行，須要注意的是StringBuilder中的實例化的循環外。所以它的內存分配一次，而後，咱們只是做爲一個緩衝，在每次循環咱們先清除它，而後咱們追加，整數的一個字符串來表示對於循環迭代的行。更多細節見導師的筆記到這個代碼段，運行memory_churn_optimized，確認咱們減小的GC在短時間時間窗中發生的量，您也可使用allocation tracker驗證。如今對於咱們來講，即便修改了代碼，海盜動畫仍然會出現卡頓的現象，這意味着該處理放到後臺處理可能更加合適。

工具的特點

1）Memory Monitor：得到內存的動態視圖
2）Heap Viewer：顯示堆內存中存儲了什麼
3）Allocation Tracke： 具體是哪些代碼使用了內存

關注個人技術公衆號"程序員驛站"，天天都有優質技術文章推送，微信掃一掃下方二維碼便可關注：