天天看點

Android記憶體性能優化(内部資料總結)

剛入門的童鞋肯能都會有一個疑問,Java不是有虛拟機了麼,記憶體會自動化管理,我們就不必要手動的釋放資源了,反正系統會給我們完成。其實Java中沒有指針的概念,但是指針的使用方式依然存在,一味的依賴系統的gc,很容易就造成了記憶體的浪費。

Java基于垃圾回收的記憶體機制

Java的記憶體管理機制會自動回收無用對象所占用的記憶體,減輕手工管理記憶體的負擔

      1、C/C++: 從申請、使用、釋放都需要手工管理

      2、Java:無用的對象的記憶體會被自動回收

Android記憶體性能優化(内部資料總結)

什麼樣的對象是無用的對象

      1、Java通過引用來操作一個具體的對象,引用類似于C 中的指針。一個對象可以持有其他對象的引用。

      2、從一組根對象(GC Roots)開始,按對象之前的引用關系周遊所有對象,在周遊過程中标記所有的可達對象。如果一個對象由根對象出發不可達,則将它作為垃圾收集。

GCRoot 都有哪些?

1、  Class:由系統的類加載器加載的類對象

2、  Static Fields

3、  Thread:活着的線程

4、  Stack Local: java方法的局部變量或參數

5、  JNI Local: JNI方法中的局部引用

6、  JNI Global: 全局的JNI引用

7、  Monitor used: 用于同步的監控對象

8、Help by VM: 用于JVM特殊目的由GC保留的對象

Android記憶體性能優化(内部資料總結)
Android記憶體性能優化(内部資料總結)
Android記憶體性能優化(内部資料總結)

Java程式中的記憶體洩漏

對象的記憶體在配置設定之後無法通過程式的執行邏輯釋放對該對象的引用,不能被回收該對象所占記憶體

記憶體洩漏的危害

1、  引起OutOfMemoryError

2、  記憶體占用高時JVM虛拟機會頻繁觸發GC, 影響程式響應速度

3、記憶體占用大的程式容易被各種清理優化程式中止,使用者也更傾向于解除安裝這些程式

Android應用的開發語言為Java,每個應用最大可使用的堆記憶體受到Android系統的限制

Android每一個應用的堆記憶體大小有限

      1、  通常的情況為16M-48M

      2、  通過ActivityManager的getMemoryClass()來查詢可用堆記憶體限制

      3、3.0(HoneyComb)以上的版本可以通過largeHeap=“true”來申請更多的堆記憶體

           Nexus S(4.2.1):normal 192, largeHeap 512

      4、如果試圖申請的記憶體大于目前餘下的堆記憶體就會引發OutOfMemoryError()

      5、應用程式由于各方面的限制,需要注意減少記憶體占用,避免出現記憶體洩漏。

用MAT工具來檢測記憶體洩漏

在試圖視窗中建立一個Memory Analysis會出現一個

Android記憶體性能優化(内部資料總結)

沒有的可以去http://www.eclipse.org/mat/downloads.php安裝一下MAT

在Android 的調試環境DDMS下,找到Heap dump

Android記憶體性能優化(内部資料總結)
Android記憶體性能優化(内部資料總結)

Dump下目前記憶體中的鏡像檔案,*****.hprof

Android記憶體性能優化(内部資料總結)

能清楚的看到每一個部分暫用的記憶體大小。

也可以切換試圖,group檢視不同包不同類的占用細節。

Android記憶體性能優化(内部資料總結)

Heap dump

•       包含了觸發Heap dump生成的時刻Java程序的記憶體快照,主要内容為各個Java類和對象在堆記憶體中的配置設定情況

Memory Analyzer Tool (MAT)

常見記憶體洩露原因

Context對象洩漏

      1、如果一個類持有Context對象的強引用,就需要檢查其生存周期是否比Context對象更長。否則就可能發生Context洩漏。

      2、View持有其建立所在Context對象的引用,如果将View對象傳遞給其它生存周期比View所在Context更長的強引用,就可能會引起記憶體洩漏。

例如View#setTag(int, Object)的記憶體洩漏https://code.google.com/p/android/issues/detail?id=18273

      3、把Context對象賦給static變量。

避免Context對象洩漏Checklist

      1、檢查所有持有對Context對象強引用的對象的生命周期是否超出其所持有的Context對象的生命周期。

      2、檢查有沒有把View傳出到View所在Context之外的地方,如果有的話就需要檢查生命周期。

      3、工具類中最好不要有Context成員變量,盡量在調用函數時直接通過調用參數傳入。如果必須有Context成員變量時,可以考慮使用WeakReference來引用Context對象。

      4、View持有其建立所在Context對象的引用,如果将View對象傳遞給其它生存周期比View所在Context更長的強引用,就可能會引起記憶體洩漏。

      5、  檢查把Context或者View對象賦給static變量的地方,看是否有Context洩漏。

      6、檢查所有把View放入容器類的地方(特别是static容器類),看是否有記憶體洩漏。7、使用WeakHashMap也需要注意有沒有value-key的引用。

      7、盡量使用ApplicationContext。

Handler對象洩漏

1、發送到Handler的Message實際上是加入到了主線程的消息隊列等待處理,每一個Message持有其目标Handler的強引用。

如我們通常使用的匿名内部類Handler

[java] view plaincopyprint?

Android記憶體性能優化(内部資料總結)

<span style="font-size:18px;">HandlermHandler = new Handler() {  

    @Override  

    public voidhandleMessage(Message msg) {  

       mImageView.setImageBitmap(mBitmap);  

    }  

}</span>  

上面是一段簡單的Handler的使用。當使用内部類(包括匿名類)來建立Handler的時候,Handler對象會隐式地持有一個外部類對象(通常是一個Activity)的引用,因為View會依附着一個Activity。而Handler通常會伴随着一個耗時的背景線程(例如從網絡拉取圖檔)一起出現,這個背景線程在任務執行完畢(例如圖檔下載下傳完畢)之後,通過消息機制通知Handler,然後Handler把圖檔更新到界面。然而,如果使用者在網絡請求過程中關閉了Activity,正常情況下,Activity不再被使用,它就有可能在GC檢查時被回收掉,但由于這時線程尚未執行完,而該線程持有Handler的引用(不然它怎麼發消息給Handler?),這個Handler又持有Activity的引用,就導緻該Activity無法被回收(即記憶體洩露),直到網絡請求結束(例如圖檔下載下傳完畢)。另外,如果你執行了Handler的postDelayed()方法,該方法會将你的Handler裝入一個Message,并把這條Message推到MessageQueue中,那麼在你設定的delay到達之前,會有一條MessageQueue -> Message -> Handler -> Activity的鍊,導緻你的Activity被持有引用而無法被回收。

當然,應為是Handler對外部持有引用的原因,我們就可以将Activity設定為一個弱引用,在不必要的時候,不再執行内部方法。

Android記憶體性能優化(内部資料總結)

<span style="font-size:18px;">/**

* @author zhoushengtao

*/  

import android.app.Activity;  

importandroid.content.Context;  

importandroid.os.Handler;  

importandroid.os.Message;  

importjava.lang.ref.WeakReference;  

publicclass WeakRefHandler extends Handler  

{  

    WeakReference<Context> mWeakContext;  

    public WeakRefHandler(Context context)  

    {  

        mWeakContext = newWeakReference<Context>(context);  

    public void handleMessage(Message msg)  

        if((mWeakContext.get() instanceofActivity )&& ((Activity)mWeakContext.get()).isFinishing())  

                return ;  

        if(mWeakContext==null){  

            return ;  

        }  

        super.handleMessage(msg);  

2、Non-staticinner class 和anonymous class持有其outer class的引用。

Drawable.Callback引起的記憶體洩漏

Drawable對象持有Drawable.callback的引用。當把一個Drawable對象設定到一個View時,Drawable對象會持有該View的引用作為Drawable.Callback

Android記憶體性能優化(内部資料總結)

避免Drawable.Callback引起記憶體洩漏

•       盡量不要在static成員中儲存Drawable對象

•       對于需要儲存的Drawable對象, 在需要時調用Drawable#setCallback(null).

Android記憶體性能優化(内部資料總結)

其他記憶體洩漏

      1、Android DigitalClock引起的記憶體洩漏http://code.google.com/p/android/issues/detail?id=17015

      2、使用Map容器類時,作為Key 的類沒有正确的實作hashCode和equal函數

•       JNI程式中的記憶體洩漏

1、  Malloc/free。

2、  JNI Global reference

•       Thread-Local Variable

1、  相當于Thread對象的成員變量, 可以存儲線程相關的狀态

2、  如果thread是alive狀态,那麼Thread-Local中的對象就無法被GC。

程序記憶體占用監測工具

Dumpsys

•       $ dumpsys meminfo [pid]

Android記憶體性能優化(内部資料總結)

Procrank + Shell腳本

•       #procrank

      1、  VSS - Virtual Set Size 虛拟耗用記憶體(包含共享庫占用的記憶體)

      2、  RSS - Resident Set Size 實際使用實體記憶體(包含共享庫占用的記憶體)

3、  PSS - Proportional Set Size 實際使用的實體記憶體(比例配置設定共享庫占用的記憶體)

4、  USS - Unique Set Size 程序獨自占用的實體記憶體(不包含共享庫占用的記憶體)

Android記憶體性能優化(内部資料總結)

Shell腳本

#!/bin/bash

while true; do

         adbshell procrank | grep "com.qihoo360.mobilesafe"

         sleep1

done

當然,部分機型的sh都是經過第三方手機商精簡過的,很多指令都用不了。Procrank,就是一個經常被精簡掉的指令。

         鑒于此:

         自己寫了一個小工具,檢測記憶體的實時變化,

Github位址:https://github.com/stchou/JasonTest

Android記憶體性能優化(内部資料總結)
Android記憶體性能優化(内部資料總結)

小結

      1.      儲存對象前要三思

                               I.           對象本身有無隐含的引用

                             II.           儲存後何時能夠回收

      2.      要了解常見的隐含引用

                               I.           anonymous class outer class

                             II.           View to context

      3.      要通過各種工具檢查記憶體占用是否有異常

      4.      建立大對象時,要檢查它的生命周期

摘自:http://www.eoeandroid.com/thread-334987-1-1.html

繼續閱讀