2. 程式人生 > >android效能優化——記憶體洩漏

android效能優化——記憶體洩漏

阿新 • • 發佈：2018-12-16

在專案初期階段或者業務邏輯很簡單的時候對於app效能之一塊沒有太多感覺，但是隨著專案版本的迭代和專案業務邏輯越來越大，越來越複雜的時候，就會逐漸感覺到app效能的重要性，所以在專案初期階段時，就要有app效能這一意識，也便於專案後期的版本迭代和業務擴充套件；這裡所提到的效能優化問題是：記憶體洩漏。

什麼是記憶體洩漏？

通俗一點就是記憶體沒有在GC掌控之內；當一個物件已經不需要再使用了，本該被回收，而有另外一個正在使用的物件持有它的引用從而就導致物件不能回收，這就導致了本該被回收的物件不能被回收而停留在堆記憶體中，就產生了記憶體洩漏。

android系統會給正在執行的程式一個獨立的程序，並分配一定的記憶體空間，對於每個程式來說它的記憶體空間是固定的，所以當每個物件不再使用時，應將其所開闢佔用用的記憶體釋放掉，如果發生記憶體洩漏並大量佔用記憶體，當所耗用的記憶體超過系統所分配的記憶體時就會導致記憶體溢位，從而導致程式閃退。

當定義一些成員變數或者例項化一些物件的時候，就會在系統分配的記憶體中去佔用一些記憶體，涉及到棧、堆、靜態方法區幾種記憶體分配策略；

棧：

在執行函式(方法)時，函式一些內部變數的儲存都可以放在棧上面建立，函式執行結束的時候這些儲存單元就會自動被釋放掉，棧記憶體包括分配的運算速度很快，因為內建在處理器裡面的，當然容量有限；

堆：

也叫做動態記憶體分配，有時候可以用malloc或者new來申請分配一個記憶體，在C/C++可能需要自己負責釋放，java裡面可以依賴GC機制，會將已不在使用或沒有其他物件引用的物件回收掉；

靜態方法區：

記憶體在程式編譯的時候就已經分配好，這塊的記憶體在程式整個執行期間都一直存在，它主要存放靜態資料、全域性的static資料和一些常量；

所以討論記憶體洩漏，主要討論堆記憶體，它存放的就是引用指向的物件實體；但是也要主要靜態方法區，大量靜態的使用可能不會造成記憶體洩漏，但是會導致記憶體一直會被佔用而無法釋放；所以在開發過程中根據需要可以使用一些java提供的StrongReference(強引用)、SoftReference(軟引用)、WeakReference(弱引用)、PhatomReference(虛引用);

StrongReference(強引用)：從不回收；生命週期：JVM停止的時候才會停止；

SoftReference(軟引用)：當記憶體不足的時候就會進行回收，SoftReference<String>結合ReferenceQueue構造有效期短；生命週期：記憶體不足時終止；

WeakReference(弱引用)：在垃圾回收的時候就會進行回收；生命週期：GC後終止

PhatomReference(虛引用)：在垃圾回收的時候；使用：合ReferenceQueue來跟蹤物件唄垃圾回收期回收的活動； 生命週期:GC後終止

所以在專案開發過程中需要養成良好的編碼習慣，同時儘量瞭解一些容易引發記憶體洩漏的場景，及一些檢測記憶體洩漏的工具和方法。

先去看一些容易引發記憶體洩漏的場景：

場景一：單例使用造成的記憶體洩漏

在專案開發過程中或多或少會使用到單例，例如：

public class CommUtil {
    private static CommUtil instance;
    private Context context;
    private CommUtil(Context context){
        this.context = context;
    }

    public static CommUtil getInstance(Context context){
        if(instance == null){
            instance = new CommUtil(context);
        }
        return instance;
    }
}
public class MainActivity extends AppCompatActivity {

    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.activity_main);
        //建立例項
        CommUtil commUtil = CommUtil.getInstance(this);
    }
}

這是很常見的單例寫法及例項化使用，其實自己沒有學習效能優化之前就是這樣寫的，學習之後才發這是一種錯誤的寫法，很容易就會出現記憶體洩漏；在例項化CommUtil時傳入的this代表的是當前的MainActivity,當MainActivity銷燬後，CommUtil中仍然持有MainActivity的引用，這樣就造成了MainActivity的洩漏；所以在例項化CommUtil的時，傳入的上下文可以使用getApplicationContext方式獲取，這樣就使得CommonUtil生命週期是跟Application程序一致；

public class MainActivity extends AppCompatActivity {

    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.activity_main);
        //建立例項
        CommUtil commUtil = CommUtil.getInstance(getApplicationContext());
    }
}

場景二:執行緒使用導致的記憶體洩漏

專案開發過程中遇到耗時操作時，都會在子線中進行操作；

public class MainActivity extends AppCompatActivity {
    int a=10;
    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.activity_main);
        //模擬載入資料
        loadData();
    }

    private void loadData() {
        new Thread(new Runnable() {
            @Override
            public void run() {
                        int b=a;
                try {
                    Thread.sleep(1000);
                } catch (InterruptedException e) {
                    e.printStackTrace();
                }
            }
        }).start();
    }
}

這是一個模擬資料載入，當離開MainActivity後，如果new Thread()中持有MainActivity中成員變數的引用且子執行緒中的邏輯並沒執行完畢，這個時候就會造成記憶體洩漏，new Thread()其實是一個匿名內部類，這是由匿名內部類與MainActivity生命週期不一致，並持有MainActivity內的引用造成的記憶體洩漏；可以在loadData()方法上加static；

public class MainActivity extends AppCompatActivity {
    int a=10;
    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.activity_main);
        //模擬載入資料
        loadData();
    }

    private static void loadData() {
        new Thread(new Runnable() {
            @Override
            public void run() {
                        int b=a;
                try {
                    Thread.sleep(1000);
                } catch (InterruptedException e) {
                    e.printStackTrace();
                }
            }
        }).start();
    }
}

但是會發現，loadData();加了static後，int b=a；會報錯，如果loadData中沒有引用成員變數直接加static就可以了，如果有引用相應的成員變數可以採用下面的方式：

public class MainActivity extends AppCompatActivity {
    int a=10;
    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.activity_main);
        new LoadThread(new WeakReference<MainActivity>(this)).start();
    }
    private static class LoadThread extends Thread implement Runnable{
        private WeakReference<MainActivity> mainActivity;//設定軟引用儲存，當記憶體一發生GC的時候就會回收。

        public LoadThread(WeakReference<MainActivity> mainActivity) {
            this.mainActivity = mainActivity;
        }

        @Override
        public void run() {
            super.run();
            MainActivity main =  mainActivity.get();
            if(main==null||main.isFinishing()){
                return;
            }
            try {
                int b=main.a;
                Thread.sleep(1000);
            } catch (InterruptedException e) {
                e.printStackTrace();
            }
        }
    }
}

場景三：Handler造成的記憶體洩漏

Handler所造成的記憶體洩漏和執行緒造成的記憶體洩漏原因和解決方式都差不多；這裡直接說解決方式吧；

private static class LoadHander extends Handler{
        private WeakReference<MainActivity> mainActivity;//設定軟引用儲存，當記憶體一發生GC的時候就會回收。

        public LoadHander(WeakReference<MainActivity> mainActivity) {
            this.mainActivity = mainActivity;
        }

        @Override
        public void handleMessage(Message msg) {
            super.handleMessage(msg);
            MainActivity main =  mainActivity.get();
            if(main==null||main.isFinishing()){
                return;
            }
            int b=main.a;
        }
    }

場景四：一些檢視監聽所造成的洩漏

在獲取某個view的高度和寬度的時候，直接獲取是獲取不到的，可以採用view.post()方法，也可以採用監聽該view的檢視樹；

public class MainActivity extends AppCompatActivity {
    
    @RequiresApi(api = Build.VERSION_CODES.JELLY_BEAN_MR2)
    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.activity_main);
		
        final TextView tv= (TextView) findViewById(R.id.tv);
		
        tv.getViewTreeObserver().addOnWindowFocusChangeListener(new ViewTreeObserver.OnWindowFocusChangeListener() {
            @Override
            public void onWindowFocusChanged(boolean hasFocus) {
                //計算完後，一定要移除這個監聽
                tv.getViewTreeObserver().removeOnWindowFocusChangeListener(this);
            }
        });
    }
}

但是採用監聽view檢視樹的方式需要注意在操作完成後需要將該監聽移除調，在新增監聽的時候，該監聽是新增到了CopyOnWriteArrayList集合中，所以在不需要的時候就要從CopyOnWriteArrayList集合中移除。

當然了造成記憶體洩漏的場景不只上面這些，在專案開發中要養成效能優化的意識，養成良好的編碼習慣；還可以使用工具來檢測程式碼或者程式是否有記憶體洩漏。

Android Monitor工具

這是android studio自帶的一個工具；執行專案，在android studio下方找到Android Monitor，切換到Monitor


會看到Memory(反映記憶體情況)、CPU(CPU執行情況)、Network(網路耗用情況)、GPU(虛擬機器是沒有的，真機會有，反映ui渲染情況),Memory就是程式執行的記憶體情況,Free(剩下的記憶體)，Allocated（已經使用的記憶體），在Memory右邊有些按鈕可以點選；


手動點選GC（多點選幾次），就會將沒有持有引用或空閒的記憶體回收掉；


多點選幾次GC，當記憶體耗用平穩後，點選形成快照，系統就會根據記憶體的情況形成一個.hporf檔案；




多次點選GC後生產的記憶體快照檔案中有兩個MainActivity，有一個被CommUtil持有沒有釋放就容易會造成洩漏。

Lint分析工具

Lint分析工具也是android studio自帶的工具，很方便，很好用，功能強大；

  1. 檢測資原始檔是否有沒有用到的資源。
  2. 檢測常見記憶體洩露
  3. 安全問題SDK版本安全問題
  4. 是否有費的程式碼沒有用到
  5. 程式碼的規範---甚至駝峰命名法也會檢測
  6. 自動生成的羅列出來
  7. 沒用的導包
  8. 可能的bug

上面這些是可以自動檢測的，Analyze--->Inspect Code


根據彈框選擇如下（第一次）：


第一次好像和第二次的選擇好像不一樣；第二次選擇：


就會出現下面頁面：


可以根據提示對專案進行各方面的優化；

Memory Usage

Memory Usage只能大致粗略的知道程式有沒有記憶體洩漏等，不能定位到大致的造成洩漏的地方；


點選檢視生產的txt檔案，找到Objects，主要看Views和Activities，需要注意的是Views的數量並不代表就存在記憶體洩漏，還是要看Activities的數量，如果數量不對多半會是記憶體洩漏。


LeakCanary

LeakCanary是一個第三方的檢測記憶體洩漏，使用方便、簡單，可以定位到具體造成洩漏的地方，它是根據程式去進行檢測的，反饋的時間會有些遲；

github地址：https://github.com/square/leakcanary

首先引入依賴庫：

dependencies {
  debugImplementation 'com.squareup.leakcanary:leakcanary-android:1.5.4'
  releaseImplementation 'com.squareup.leakcanary:leakcanary-android-no-op:1.5.4'
}

在專案的Application檔案中進行註冊；

public class ExampleApplication extends Application {

  @Override public void onCreate() {
    super.onCreate();
    if (LeakCanary.isInAnalyzerProcess(this)) {
      // This process is dedicated to LeakCanary for heap analysis.
      // You should not init your app in this process.
      return;
    }
    LeakCanary.install(this);
    // Normal app init code...
  }
}

執行應用程式，會在手機安裝相應的檢測程式；


操作應用程式，有造成記憶體洩漏的時候，LeakCanary就會發送訊息在手機通知欄，並顯示造成洩漏的地方；


使用起來還是比較簡單的，並且容易定位地方；當然了檢測記憶體洩漏的方法和工具不止上面這些，還有MAT、HeapTool(檢視堆資訊)、Allaction Tracking等方法，下面提供了一些檢測方法和工具使用的word文件地址：

https://pan.baidu.com/s/1r0V6bbSyR3aY7Qy8uqhB1Q

相關推薦

android效能優化——記憶體洩漏

在專案初期階段或者業務邏輯很簡單的時候對於app效能之一塊沒有太多感覺，但是隨著專案版本的迭代和專案業務邏輯越來越大，越來越複雜的時候，就會逐漸感覺到app效能的重要性，所以在專案初期階段時，就要有app效能這一意識，也便於專案後期的版本迭代和業務擴充套件；這裡所提到的效能優化問題是：記憶體洩漏

Android 效能優化——記憶體篇

歡迎轉載，轉載請標明出處【Hoolay Team】： http://www.cnblogs.com/hoolay/p/6278229.html Author : Hoolay Android Team  Chiclaim 一、android官方一

Android 效能優化—記憶體篇

一、android官方一些記憶體方面的記憶體tips 1、避免建立不必要的物件。 如儘量避免字串的加號拼接，可以使用StringBuilder來拼接。 如果需要TextView設定多個字串片段，可以使用textView.append方法，不要直接用加號拼起

Android效能優化--記憶體篇

看到很多關於記憶體優化的部落格好文，也收藏了好多地址，但每次看時都需要在眾多收藏的地址裡尋找一番，不如寫到自己的部落格裡，方便隨時翻看。 記憶體優化也是android進階的必學內容。APP記憶體的使用，是評價一款應用效能高低的一個重要指標。 1.記憶體與記憶

Android 效能優化 ---- 記憶體優化

### 1、Android記憶體管理機制 #### 1.1 Java記憶體分配模型 先上一張JVM將記憶體劃分區域的圖 ![](https://img2020.cnblogs.com/blog/967362/202007/967362-20200717091650518-110380858.png) 程式

Android效能優化篇之記憶體優化--記憶體洩漏

文章目錄 介紹 什麼是記憶體洩露 android中導致記憶體洩漏的主要幾種情況 1.單例模式 2.使用非靜態內部類 3.使用非同步事件處理機制Handler 4.使用靜態

Android 效能優化之記憶體洩漏檢測以及記憶體優化（中）

Android 記憶體洩漏檢測 　　通過上篇部落格我們瞭解了 Android JVM/ART 記憶體的相關知識和洩漏的原因，再來歸類一下記憶體洩漏的源頭，這裡我們簡單將其歸為一下三類：自身編碼引起由專案開發人員自身的編碼造成；第三方程式碼引起這裡的第三

Android 效能優化之記憶體洩漏的檢測與修復

在 Android 開發中, 記憶體優化是APP效能優化中很重要的一個部分. 而在記憶體優化中, 最重要的就是修復記憶體洩漏問題. 本文就來介紹一下記憶體洩漏的基本概念以及常用的檢測手段. 1. 什麼是記憶體洩漏 簡單來說, 當一個物件不再被使用時,

Android 效能優化之記憶體洩漏檢測以及記憶體優化（下）

Android 記憶體優化 　　上篇部落格描述瞭如何檢測和處理記憶體洩漏，這種問題從某種意義上講是由於程式碼的錯誤導致的，但是也有一些是程式碼沒有錯誤，但是我們可以通過很多方式去降低記憶體的佔用，使得應用的整體記憶體處於一個健康的水平，下面總結一下記憶

Android記憶體優化—記憶體洩漏、記憶體抖動、記憶體溢位

記憶體洩漏 當某些物件不再被程式所使用，但是這些物件仍然被某些物件所引用著，進而導致垃圾收集器不能及時釋放它們。 記憶體洩露 指由於疏忽或錯誤造成程式未能釋放已經不再使用的記憶體。 解決辦法：在不需要的時候及時釋放掉資源 記憶體抖動 記憶體抖動 指記憶體頻繁地分配和回

Android 效能優化——管理應用的記憶體

請保持淡定，分析程式碼，記住：效能很重要。 隨機存取儲存器（RAM）在任何軟體開發環境中都是一個很寶貴的資源。這一點在實體記憶體通常很有限的移動作業系統上，顯得尤為突出。儘管 Android Runtime（ART）和 Dalvik 虛擬機器都扮演了常

Android 效能優化之記憶體檢測、卡頓優化、耗電優化、APK瘦身

導語 自2008年智慧時代開始，Android作業系統一路高歌，10年智慧機發展之路，如今 Android 9.0 代號P  都發布了，Android系統性能已經非常流暢了。但是，到了各大廠商手裡，改原始碼自定系統，使得Android原生系統變得魚龍混雜。另外，到了不同層次的

Android效能優化（一）記憶體洩露優化（靜態變數、單例模式、屬性動畫）

記憶體洩露優化分為兩個方面，一方面是在開發過程中避免寫出有記憶體洩露的程式碼，另一方面是通過一些分析工具比如 MAT來找出潛在的記憶體洩露繼而解決。 一、靜態變數導致記憶體洩露。一般情況下靜態變數引用

Android效能優化：手把手帶你全面瞭解 記憶體洩露 & 解決方案

前言 在Android中，記憶體洩露的現象十分常見；而記憶體洩露導致的後果會使得應用Crash 本文 全面介紹了記憶體洩露的本質、原因 & 解決方案，最終提供一些常見的記憶體洩露分析工具，希望你們會喜歡。 掃碼檢視公眾號： 目錄 1. 簡介 即 ML （

Android效能優化系列之記憶體優化

在Java中，記憶體的分配是由程式完成的，而記憶體的釋放是由垃圾收集器(Garbage Collection，GC)完成的，程式設計師不需要通過呼叫函式來釋放記憶體，但也隨之帶來了記憶體洩漏的可能，上篇部落格，我介紹了 Android效能優化系列之佈局優化，本篇部落格，我將介

[Android 效能優化系列]記憶體之基礎篇--Android如何管理記憶體

轉載請標明出處(http://blog.csdn.net/kifile),再次感謝 在接下來的一段時間裡，我會每天翻譯一部分關於效能提升的Android官方文件給大家 下面是本次的正文: ################ 隨機訪問儲存器（Ram） 不管在哪種軟體開發

Android記憶體優化-記憶體洩漏的幾個場景以及解決方式

一.什麼是記憶體洩漏 在Java程式中，如果一個物件沒有利用價值了，正常情況下gc是會對其進行回收的，但是此時仍然有其他引用指向這個活在堆記憶體中的物件，那麼gc就不會認為這個物件是一個垃圾，那麼就不會對其進行回收，所以它會一直活在堆記憶體中佔用記憶體

Android效能優化之記憶體篇

Google近期在Udacity上釋出了Android效能優化的線上課程，分別從渲染，運算與記憶體，電量幾個方面介紹瞭如何去優化效能，這些課程是Google之前在Youtube上釋出的Android效能優化典範專題課程的細化與補充。 下面是記憶體篇章的學習筆記，部分內容與前面的效能優化典範有重合，歡

Android效能優化——渲染、記憶體、電源優化

越整理越要找更多資料，越寫越發覺自己不懂的東西更多。學習的路還很長… 本文主要從 介面，記憶體，電量優化三個方面展開，梳理一下自己的知識。 介面、GPU 渲染效能 大多數使用者感知到的卡頓等效能問題的最主要根源都是因為渲染效能。從設計師的角

Android 效能優化之記憶體優化

在移動作業系統上，通常實體記憶體有限，儘管 Android 的 Dalvik 虛擬機器扮演了常規的垃圾回收的角色，但這並不意味著我們可以忽略 APP 的記憶體分配與釋放，為了 GC 能夠從 APP 中及時回收記憶體，我們在日常的開發中就需要時刻注意記憶體洩露，並在合適的時候來