歡迎光臨
每天分享高質量文章
當前位置：知識星球 > Android > 正文

Android效能最佳化：關於 記憶體洩露 的知識都在這裡了！（文不如圖，圖不如表）

2019-03-19 分類：Android 閱讀(988) 評論(0)
作者：_陳祥
連結：https://www.jianshu.com/p/e719e0c397e5

前言

在 Android 中，記憶體洩露的現象十分常見；而記憶體洩露導致的後果會使得應用Crash
本文 全面介紹了記憶體洩露的本質、原因 & 解決方案，最終提供一些常見的記憶體洩露分析工具，希望你們會喜歡。

目錄

1.png

1、簡介

即 ML （Memory Leak）
指 程式在申請記憶體後，當該記憶體不需再使用 但 卻無法被釋放 & 歸還給 程式的現象

2、對應用程式的影

容易使得應用程式發生記憶體上限溢位，即 OOM
記憶體上限溢位 簡介：

1.png

3、發生記憶體洩露的本質原因

具體描述

1.jpg

  • 特別註意
    從機制上的角度來說，由於 Java存在垃圾回收機制（GC），理應不存在記憶體洩露；出現記憶體洩露的原因僅僅是外部人為原因 = 無意識地持有物件取用，使得 持有取用者的生命週期 > 被取用者的生命週期

4、儲備知識：Android 記憶體管理機制

4.1 簡介

 

1.png

下麵，將針對回收 行程、物件 、變數的記憶體分配 & 回收進行詳細講解

4.2 針對行程的記憶體策略


a. 記憶體分配策略
由 ActivityManagerService 集中管理 所有行程的記憶體分配


b. 記憶體回收策略


步驟1：Application Framework  決定回收的行程型別


Android中的行程 是託管的；當行程空間緊張時，會 按行程優先順序低->>高的順序 自動回收行程
Android將行程分為5個優先等級，具體如下：

1.png

步驟2：Linux 核心真正回收具體行程
ActivityManagerService 對 所有行程進行評分（評分存放在變數adj中）
更新評分到Linux 核心
由Linux 核心完成真正的記憶體回收

此處僅總結流程，這其中的過程複雜，有興趣的讀者可研究系統原始碼ActivityManagerService.java

 

4.2 針對物件、變數的記憶體策略

 

  • Android的對於物件、變數的記憶體策略同 Java

  • 記憶體管理 = 物件 / 變數的記憶體分配 + 記憶體釋放

下麵，將詳細講解記憶體分配 & 記憶體釋放策略

a. 記憶體分配策略

  • 物件 / 變數的記憶體分配 由程式自動 負責

  • 共有3種：靜態分配、棧式分配、 & 堆式分配，分別面向靜態變數、區域性變數  & 物件實體
    具體介紹如下

1.png

註：用1個實體講解 記憶體分配

public class Sample {    
    int s1 = 0;
    Sample mSample1 = new Sample();   

    // 方法中的區域性變數s2、mSample2存放在 棧記憶體
    // 變數mSample2所指向的物件實體存放在 堆記憶體
      // 該實體的成員變數s1、mSample1也存放在棧中
    public void method() {        
        int s2 = 0;
        Sample mSample2 = new Sample();
    }
}
    // 變數mSample3所指向的物件實體存放在堆記憶體
    // 該實體的成員變數s1、mSample1也存放在堆記憶體中
    Sample mSample3 = new Sample();

b. 記憶體釋放策略

  • 物件 / 變數的記憶體釋放 由Java垃圾回收器（GC） / 幀棧 負責

  • 此處主要講解物件分配（即堆式分配）的記憶體釋放策略 = Java垃圾回收器（GC）

由於靜態分配不需釋放、棧式分配僅 透過幀棧自動出、入棧，較簡單，故不詳細描述

  • Java垃圾回收器（GC）的記憶體釋放 = 垃圾回收演演算法，主要包括：

1.png

具體介紹如下

1.png

5、常見的記憶體洩露原因 & 解決方案

常見引發記憶體洩露原因主要有：

  1. 集合類

  2. Static關鍵字修飾的成員變數

  3. 非靜態內部類 / 匿名類

  4. 資源物件使用後未關閉

下麵，我將詳細介紹每個引發記憶體洩露的原因

5.1 集合類

 

  • 記憶體洩露原因
    集合類 新增元素後，仍取用著 集合元素物件，導致該集合元素物件不可被回收，從而 導致記憶體洩漏
    實體演示:

// 透過 迴圈申請Object 物件 & 將申請的物件逐個放入到集合List
List objectList = new ArrayList<>();        
       for (int i = 0; i 10; i++) {
            Object o = new Object();
            objectList.add(o);
            o = null;
        }
// 雖釋放了集合元素取用的本身：o=null）
// 但集合List 仍然取用該物件，故垃圾回收器GC 依然不可回收該物件

  • 解決方案
    集合類 新增集合元素物件 後，在使用後必須從集合中刪除

由於1個集合中有許多元素，故最簡單的方法 = 清空集合物件 & 設定為null

 // 釋放objectList
        objectList.clear();
        objectList=null;

 

5.2 Static 關鍵字修飾的成員變數

 

  • 儲備知識
    被 Static 關鍵字修飾的成員變數的生命週期 = 應用程式的生命週期

  • 洩露原因
    若使被 Static 關鍵字修飾的成員變數 取用耗費資源過多的實體（如Context），則容易出現該成員變數的生命週期 > 取用實體生命週期的情況，當取用實體需結束生命週期銷毀時，會因靜態變數的持有而無法被回收，從而出現記憶體洩露
    實體講解:

public class ClassName {
 // 定義1個靜態變數
 private static Context mContext;
 //...
// 取用的是Activity的context
 mContext = context; 

// 當Activity需銷毀時，由於mContext = 靜態 & 生命週期 = 應用程式的生命週期，故 Activity無法被回收，從而出現記憶體洩露
}

  • 解決方案

  1. 儘量避免 Static 成員變數取用資源耗費過多的實體（如 Context）

若需取用 Context，則儘量使用Applicaiton的Context

  1. 使用 弱取用（WeakReference） 代替 強取用 持有實體

註：靜態成員變數有個非常典型的例子 = 單例樣式

  • 儲備知識
    單例樣式 由於其靜態特性，其生命週期的長度 = 應用程式的生命週期

  • 洩露原因
    若1個物件已不需再使用 而單例物件還持有該物件的取用，那麼該物件將不能被正常回收 從而 導致記憶體洩漏

實體演示：

// 建立單例時，需傳入一個Context
// 若傳入的是Activity的Context，此時單例 則持有該Activity的取用
// 由於單例一直持有該Activity的取用（直到整個應用生命週期結束），即使該Activity退出，該Activity的記憶體也不會被回收
// 特別是一些龐大的Activity，此處非常容易導致OOM

public class SingleInstanceClass {    
    private static SingleInstanceClass instance;    
    private Context mContext;    
    private SingleInstanceClass(Context context) {        
        this.mContext = context; // 傳遞的是Activity的context
    }  

    public SingleInstanceClass getInstance(Context context) {        
        if (instance == null) {
            instance = new SingleInstanceClass(context);
        }        
        return instance;
    }
}

  • 解決方案
    單例樣式取用的物件的生命週期 = 應用的生命週期

如上述實體，應傳遞Application的Context，因Application的生命週期 = 整個應用的生命週期

public class SingleInstanceClass {    
    private static SingleInstanceClass instance;    
    private Context mContext;    
    private SingleInstanceClass(Context context) {        
        this.mContext = context.getApplicationContext(); // 傳遞的是Application 的context
    }    

    public SingleInstanceClass getInstance(Context context) {        
        if (instance == null) {
            instance = new SingleInstanceClass(context);
        }        
        return instance;
    }
}

 

5.3 非靜態內部類 / 匿名類

 

  • 儲備知識
    非靜態內部類 / 匿名類 預設持有 外部類的取用；而靜態內部類則不會

  • 常見情況
    3種，分別是：非靜態內部類的實體  = 靜態、多執行緒、訊息傳遞機制（Handler）

5.3.1 非靜態內部類的實體  = 靜態

  • 洩露原因
    若 非靜態內部類所建立的實體 = 靜態（其生命週期 = 應用的生命週期），會因 非靜態內部類預設持有外部類的取用 而導致外部類無法釋放，最終 造成記憶體洩露

即 外部類中 持有 非靜態內部類的靜態物件
實體演示:

// 背景：
   a. 在啟動頻繁的Activity中，為了避免重覆建立相同的資料資源，會在Activity內部建立一個非靜態內部類的單例
   b. 每次啟動Activity時都會使用該單例的資料

public class TestActivity extends AppCompatActivity {  

    // 非靜態內部類的實體的取用
    // 註：設定為靜態  
    public static InnerClass innerClass = null; 

    @Override
    protected void onCreate(@Nullable Bundle savedInstanceState) {        
        super.onCreate(savedInstanceState);   

        // 保證非靜態內部類的實體只有1個
        if (innerClass == null)
            innerClass = new InnerClass();
    }

    // 非靜態內部類的定義    
    private class InnerClass {        
        //...
    }
}

// 造成記憶體洩露的原因：
    // a. 當TestActivity銷毀時，因非靜態內部類單例的取用（innerClass）的生命週期 = 應用App的生命週期、持有外部類TestActivity的取用
    // b. 故 TestActivity無法被GC回收，從而導致記憶體洩漏

  • 解決方案

  1. 將非靜態內部類設定為：靜態內部類（靜態內部類預設不持有外部類的取用）

  2. 該內部類抽取出來封裝成一個單例

  3. 儘量 避免 非靜態內部類所建立的實體 = 靜態

若需使用Context，建議使用 Application 的 Context

5.3.2 多執行緒：AsyncTask、實現Runnable介面、繼承Thread類

  • 儲備知識
    多執行緒的使用方法 = 非靜態內部類 / 匿名類；即 執行緒類 屬於 非靜態內部類 / 匿名類

  • 洩露原因
    當 工作執行緒正在處理任務 & 外部類需銷毀時， 由於 工作執行緒實體 持有外部類取用，將使得外部類無法被垃圾回收器（GC）回收，從而造成 記憶體洩露

多執行緒主要使用的是：AsyncTask、實現Runnable介面 & 繼承Thread類
前3者記憶體洩露的原理相同，此處主要以繼承Thread類 為例說明

實體演示

/** 
     * 方式1：新建Thread子類（內部類）
     */  
        public class MainActivity extends AppCompatActivity {

        public static final String TAG = "carson：";
        @Override
        public void onCreate(Bundle savedInstanceState) {
            super.onCreate(savedInstanceState);
            setContentView(R.layout.activity_main);

            // 透過建立的內部類 實現多執行緒
            new MyThread().start();

        }
        // 自定義的Thread子類
        private class MyThread extends Thread{
            @Override
            public void run() {
                try {
                    Thread.sleep(5000);
                    Log.d(TAG, "執行了多執行緒");
                } catch (InterruptedException e) {
                    e.printStackTrace();
                }
            }
        }
    }

   /** 
     * 方式2：匿名Thread內部類
     */ 
     public class MainActivity extends AppCompatActivity {

    public static final String TAG = "carson：";

    @Override
    public void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.activity_main);

        // 透過匿名內部類 實現多執行緒
        new Thread() {
            @Override
            public void run() {
                try {
                    Thread.sleep(5000);
                    Log.d(TAG, "執行了多執行緒");
                } catch (InterruptedException e) {
                    e.printStackTrace();
                }

            }
        }.start();
    }
}

/** 
  * 分析：記憶體洩露原因
  */ 
  // 工作執行緒Thread類屬於非靜態內部類 / 匿名內部類，執行時預設持有外部類的取用
  // 當工作執行緒執行時，若外部類MainActivity需銷毀
  // 由於此時工作執行緒類實體持有外部類的取用，將使得外部類無法被垃圾回收器（GC）回收，從而造成 記憶體洩露

  • 解決方案
    從上面可看出，造成記憶體洩露的原因有2個關鍵條件：

  1. 存在 ”工作執行緒實體 持有外部類取用“ 的取用關係

  2. 工作執行緒實體的生命週期 > 外部類的生命週期，即工作執行緒仍在執行 而 外部類需銷毀
    解決方案的思路 = 使得上述任1條件不成立 即可。

// 共有2個解決方案：靜態內部類 & 當外部類結束生命週期時，強制結束執行緒
// 具體描述如下

   /** 
     * 解決方式1：靜態內部類
     * 原理：靜態內部類 不預設持有外部類的取用，從而使得 “工作執行緒實體 持有 外部類取用” 的取用關係 不復存在
     * 具體實現：將Thread的子類設定成 靜態內部類
     */  
        public class MainActivity extends AppCompatActivity {

        public static final String TAG = "carson：";
        @Override
        public void onCreate(Bundle savedInstanceState) {
            super.onCreate(savedInstanceState);
            setContentView(R.layout.activity_main);

            // 透過建立的內部類 實現多執行緒
            new MyThread().start();

        }
        // 分析1：自定義Thread子類
        // 設定為：靜態內部類
        private static class MyThread extends Thread{
            @Override
            public void run() {
                try {
                    Thread.sleep(5000);
                    Log.d(TAG, "執行了多執行緒");
                } catch (InterruptedException e) {
                    e.printStackTrace();
                }
            }
        }
    }

   /** 
     * 解決方案2：當外部類結束生命週期時，強制結束執行緒
     * 原理：使得 工作執行緒實體的生命週期 與 外部類的生命週期 同步
     * 具體實現：當 外部類（此處以Activity為例） 結束生命週期時（此時系統會呼叫onDestroy（）），強制結束執行緒（呼叫stop（））
     */ 
     @Override
    protected void onDestroy() {
        super.onDestroy();
        Thread.stop();
        // 外部類Activity生命週期結束時，強制結束執行緒
    }

5.3.3 訊息傳遞機制：Handler

Android 記憶體洩露：詳解 Handler 記憶體洩露的原因與解決方案
https://www.jianshu.com/p/031515d8a7ca

5.4 資源物件使用後未關閉

 

  • 洩露原因
    對於資源的使用（如 廣播BraodcastReceiver、檔案流File、資料庫遊標Cursor、圖片資源Bitmap等），若在Activity銷毀時無及時關閉 / 登出這些資源，則這些資源將不會被回收，從而造成記憶體洩漏

  • 解決方案
    在Activity銷毀時 及時關閉 / 登出資源

// 對於 廣播BraodcastReceiver：登出註冊
unregisterReceiver()

// 對於 檔案流File：關閉流
InputStream / OutputStream.close()

// 對於資料庫遊標cursor：使用後關閉遊標
cursor.close（）

// 對於 圖片資源Bitmap：Android分配給圖片的記憶體只有8M，若1個Bitmap物件佔記憶體較多，當它不再被使用時，應呼叫recycle()回收此物件的畫素所佔用的記憶體；最後再賦為null 
Bitmap.recycle()；
Bitmap = null;

// 對於動畫（屬性動畫）
// 將動畫設定成無限迴圈播放repeatCount = “infinite”後
// 在Activity退出時記得停止動畫

 

5.5 其他使用

 

  • 除了上述4種常見情況，還有一些日常的使用會導致記憶體洩露

  • 主要包括：Context、WebView、Adapter，具體介紹如下

1.png

 

5.6 總結


下麵，我將用一張圖總結Android中記憶體洩露的原因 & 解決方案

1.png

6、輔助分析記憶體洩露的工具

    • 哪怕完全瞭解 記憶體洩露的原因，但難免還是會出現記憶體洩露的現象

    • 下麵將簡單介紹幾個主流的分析記憶體洩露的工具，分別是

 

  1. MAT(Memory Analysis Tools)

  2. Heap Viewer

  3. Allocation Tracker

  4. Android Studio 的 Memory Monitor

  5. LeakCanary

 

6.1 MAT(Memory Analysis Tools)

 

  • 定義：一個Eclipse的 Java Heap 記憶體分析工具 ->>下載地址

  • 作用：檢視當前記憶體佔用情況

透過分析 Java 行程的記憶體快照 HPROF 分析，快速計算出在記憶體中物件佔用的大小，檢視哪些物件不能被垃圾收集器回收 & 可透過檢視直觀地檢視可能造成這種結果的物件

具體使用：MAT使用攻略

6.2 Heap Viewer

定義：一個的 Java Heap 記憶體分析工具
作用：檢視當前記憶體快照

可檢視 分別有哪些型別的資料在堆記憶體總 & 各種型別資料的佔比情況

具體使用：Heap Viewer使用攻略

6.3 Allocation Tracker

簡介：一個記憶體追蹤分析工具
作用：追蹤記憶體分配資訊，按順序排列
具體使用：Allocation Tracker使用攻略

6.4 Memory Monitor

簡介：一個 Android Studio 自帶 的圖形化檢測記憶體工具
作用：跟蹤系統 / 應用的記憶體使用情況。核心功能如下

1.png

具體使用：Android Studio 的 Memory Monitor使用攻略

6.5 LeakCanary

簡介：一個square出品的Android開源庫 ->>下載地址
作用：檢測記憶體洩露
具體使用：https://www.liaohuqiu.net/cn/posts/leak-canary/

7、總結

本文 全面介紹了記憶體洩露的本質、原因 & 解決方案，希望大家在開發時儘量避免出現記憶體洩露

贊(0)
標籤：

相關推薦

熱門標籤

iOS (11238)微軟 (4955)Linux (4274)安全 (4180)Python (4161)效能 (3165)運維 (2774)最佳化 (2419).NET (2262)Google (2136)機器學習 (1795)併發 (1613)分散式 (1559)叢集 (1240)SQL (1174)Mysql (1060)區塊鏈 (1017)Docker (977)微服務 (922)面試 (919)Apache (743)NLP (725)Redis (719)Android (668)Git (640)架構師 (632)Nginx (630)Facebook (599)JVM (595)爬蟲 (476)

熱門文章

分享創造快樂