ANDROID記憶體最佳化(大匯總——中)，android記憶體最佳化

ANDROID記憶體最佳化(大匯總——中)，android記憶體最佳化

轉載請註明本文出自大苞米的部落格（http://blog.csdn.net/a396901990），謝謝支援！

寫在最前：

本文的思路主要借鑒了2014年AnDevCon開發人員大會的一個演講PPT，加上把網上搜集的各種記憶體零散知識點進行匯總、挑選、簡化後整理而成。

所以我將本文定義為一個工具類的文章，如果你在ANDROID開發中遇到關於記憶體問題，或者馬上要參加面試，或者就是單純的學習或複習一下記憶體相關知識，都歡迎閱讀。（本文最後我會盡量列出所參考的文章）。

OOM：

記憶體泄露可以引發很多的問題：

1.程式卡頓，響應速度慢（記憶體佔用高時JVM虛擬機器會頻繁觸發GC）

2.莫名消失（當你的程式所佔記憶體越大，它在背景時候就越可能被幹掉。反之記憶體佔用越小，在後台存在的時間就越長）

3.直接崩潰（OutOfMemoryError）

ANDROID記憶體面臨的問題：

1.有限的堆記憶體，原始只有16M

2.記憶體大小消耗等根據裝置，作業系統等級，螢幕尺寸的不同而不同

3.程式不能直接控制

4.支援後台多任務處理（multitasking）

5.運行在虛擬機器之上

5R：

本文主要通過如下的5R方法來對ANDROID記憶體進行最佳化：

1.Reckon（計算）

首先需要知道你的app所消耗記憶體的情況，知己知彼才能百戰不殆

2.Reduce（減少）

消耗更少的資源

3.Reuse（重用）

當第一次使用完以後，盡量給其他的使用

5.Recycle（回收）

返回資源給生產流

4.Review（檢查）

回顧檢查你的程式，看看設計或代碼有什麼不合理的地方。

Reckon：

關於記憶體簡介，和Reckon（記憶體計算）的內容請看上一篇文章：ANDROID記憶體最佳化(大匯總——上)

Reduce ：

Reduce的意思就是減少，直接減少記憶體的使用是最有效最佳化方式。

下面來看看有哪些方法可以減少記憶體使用量：

Bitmap ：Bitmap是記憶體消耗大戶，絕大多數的OOM崩潰都是在操作Bitmap時產生的，下面來看看如何幾個處理圖片的方法：

圖片顯示：

我們需要根據需求去載入圖片的大小。

例如在列表中僅用於預覽時載入縮圖（thumbnails ）。

只有當使用者點擊具體條目想看詳細資料的時候，這時另啟動一個fragment／activity／對話方塊等等，去顯示整個圖片

圖片大小：

直接使用ImageView顯示bitmap會佔用較多資源，特別是圖片較大的時候，可能導致崩潰。 
使用BitmapFactory.Options設定inSampleSize, 這樣做可以減少對系統資源的要求。 
屬性值inSampleSize表示縮圖大小為原始圖片大小的幾分之一，即如果這個值為2，則取出的縮圖的寬和高都是原始圖片的1/2，圖片大小就為原始大小的1/4。 

        BitmapFactory.Options bitmapFactoryOptions = new BitmapFactory.Options();        bitmapFactoryOptions.inJustDecodeBounds = true;        bitmapFactoryOptions.inSampleSize = 2;        // 這裡一定要將其設定回false，因為之前我們將其設定成了true          // 設定inJustDecodeBounds為true後，decodeFile並不分配空間，即，BitmapFactory解碼出來的Bitmap為Null,但可計算出原始圖片的長度和寬度          options.inJustDecodeBounds = false;        Bitmap bmp = BitmapFactory.decodeFile(sourceBitmap, options);

圖片像素：

Android中圖片有四種屬性，分別是：
ALPHA_8：每個像素佔用1byte記憶體 
ARGB_4444：每個像素佔用2byte記憶體 
ARGB_8888：每個像素佔用4byte記憶體 （預設）
RGB_565：每個像素佔用2byte記憶體 
Android預設的顏色模式為ARGB_8888，這個顏色模式色彩最細膩，顯示品質最高。但同樣的，佔用的記憶體也最大。 所以在對圖片效果不是特別高的情況下使用RGB_565（565沒有透明度屬性），如下：

        publicstaticBitmapreadBitMap(Contextcontext, intresId) {            BitmapFactory.Optionsopt = newBitmapFactory.Options();            opt.inPreferredConfig = Bitmap.Config.RGB_565;            opt.inPurgeable = true;            opt.inInputShareable = true;            //擷取資源圖片             InputStreamis = context.getResources().openRawResource(resId);            returnBitmapFactory.decodeStream(is, null, opt);        }

圖片回收：

使用Bitmap過後，就需要及時的調用Bitmap.recycle()方法來釋放Bitmap佔用的記憶體空間，而不要等Android系統來進行釋放。

下面是釋放Bitmap的範例程式碼片段。

        // 先判斷是否已經回收        if(bitmap != null && !bitmap.isRecycled()){            // 回收並且置為null            bitmap.recycle();            bitmap = null;        }        System.gc();

捕獲異常：

經過上面這些最佳化後還會存在報OOM的風險，所以下面需要一道最後的關卡——捕獲OOM異常：

        Bitmap bitmap = null;        try {            // 執行個體化Bitmap            bitmap = BitmapFactory.decodeFile(path);        } catch (OutOfMemoryError e) {            // 捕獲OutOfMemoryError，避免直接崩潰        }        if (bitmap == null) {            // 如果執行個體化失敗 返回預設的Bitmap對象            return defaultBitmapMap;        }

修改對象參考型別：

參考型別：

引用分為四種層級，這四種層級由高到低依次為：強引用>軟引用>弱引用>虛引用。

強引用（strong reference）
如：Object object=new Object（），object就是一個強引用了。當記憶體空間不足，Java虛擬機器寧願拋出OutOfMemoryError錯誤，使程式異常終止，也不會靠隨意回收具有強引用的對象來解決記憶體不足問題。

軟引用（SoftReference）
只有記憶體不夠時才回收,常用於緩衝；當記憶體達到一個閥值，GC就會去回收它；

弱引用（WeakReference）   

弱引用的對象擁有更短暫的生命週期。在記憶體回收行程線程掃描它 所管轄的記憶體地區的過程中，一旦發現了只具有弱引用的對象，不管當前記憶體空間足夠與否，都會回收它的記憶體。 

虛引用（PhantomReference）   

"虛引用"顧名思義，就是形同虛設，與其他幾種引用都不同，虛引用並不會決定對象的生命週期。如果一個對象僅持有虛引用，那麼它就和沒有任何引用一樣，在任何時候都可能被記憶體回收。  

軟引用和弱引用的應用執行個體：

在Android應用的開發中，為了防止記憶體溢出，在處理一些佔用記憶體大而且聲明周期較長的對象時候，可以盡量應用軟引用和弱引用技術。

下面以使用軟引用為例來詳細說明（弱引用的使用方式與軟引用是類似的）：

假設我們的應用會用到大量的預設圖片，而且這些圖片很多地方會用到。如果每次都去讀取圖片，由於讀取檔案需要硬體操作，速度較慢，會導致效能較低。所以我們考慮將圖片緩衝起來，需要的時候直接從記憶體中讀取。但是，由於圖片佔用記憶體空間比較大，緩衝很多圖片需要很多的記憶體，就可能比較容易發生OutOfMemory異常。這時，我們可以考慮使用軟引用技術來避免這個問題發生。

首先定義一個HashMap，儲存軟引用對象。

private Map<String, SoftReference<Bitmap>> imageCache = new HashMap<String, SoftReference<Bitmap>>();

再來定義一個方法，儲存Bitmap的軟引用到HashMap。

 public void addBitmapToCache(String path) {        // 強引用的Bitmap對象        Bitmap bitmap = BitmapFactory.decodeFile(path);        // 軟引用的Bitmap對象        SoftReference<Bitmap> softBitmap = new SoftReference<Bitmap>(bitmap);        // 添加該對象到Map中使其緩衝        imageCache.put(path, softBitmap);    }

擷取的時候，可以通過SoftReference的get()方法得到Bitmap對象。

public Bitmap getBitmapByPath(String path) {        // 從緩衝中取軟引用的Bitmap對象        SoftReference<Bitmap> softBitmap = imageCache.get(path);        // 判斷是否存在軟引用        if (softBitmap == null) {            return null;        }        // 取出Bitmap對象，如果由於記憶體不足Bitmap被回收，將取得空        Bitmap bitmap = softBitmap.get();        return bitmap;    }

使用軟引用以後，在OutOfMemory異常發生之前，這些緩衝的圖片資源的記憶體空間可以被釋放掉的，從而避免記憶體達到上限，避免Crash發生。

需要注意的是，在記憶體回收行程對這個Java對象回收前，SoftReference類所提供的get方法會返回Java對象的強引用，一旦垃圾線程回收該Java對象之後，get方法將返回null。所以在擷取軟引用對象的代碼中，一定要判斷是否為null，以免出現NullPointerException異常導致應用崩潰。

到底什麼時候使用軟引用，什麼時候使用弱引用呢？

個人認為，如果只是想避免OutOfMemory異常的發生，則可以使用軟引用。如果對於應用的效能更在意，想儘快回收一些佔用記憶體比較大的對象，則可以使用弱引用。

還有就是可以根據對象是否經常使用來判斷。如果該對象可能會經常使用的，就盡量用軟引用。如果該對象不被使用的可能性更大些，就可以用弱引用。

另外，和弱引用功能類似的是WeakHashMap。WeakHashMap對於一個給定的鍵，其映射的存在並不阻止記憶體回收行程對該鍵的回收，回收以後，其條目從映射中有效地移除。WeakHashMap使用ReferenceQueue實現的這種機制。

其他小tips：

對常量使用static final修飾符

讓我們來看看這兩段在類前面的聲明：

static int intVal = 42;
static String strVal = "Hello, world!";
編譯器會產生一個叫做clinit的初始化類的方法，當類第一次被使用的時候這個方法會被執行。方法會將42賦給intVal，然後把一個指向類中常量表 的引用賦給strVal。當以後要用到這些值的時候，會在成員變數表中尋找到他們。 下面我們做些改進，使用“final”關鍵字：

static final int intVal = 42;
static final String strVal = "Hello, world!";

現在，類不再需要clinit方法，因為在成員變數初始化的時候，會將常量直接儲存到類檔案中。用到intVal的代碼被直接替換成42，而使用strVal的會指向一個字串常量，而不是使用成員變數。

將一個方法或類聲明為final不會帶來效能的提升，但是會協助編譯器最佳化代碼。舉例說，如果編譯器知道一個getter方法不會被重載，那麼編譯器會對其採用內聯調用。

你也可以將本地變數聲明為final，同樣，這也不會帶來效能的提升。使用“final”只能使本地變數看起來更清晰些（但是也有些時候這是必須的，比如在使用匿名內部類的時候）。

靜態方法代替虛擬方法

如果不需要訪問某對象的欄位，將方法設定為靜態，調用會加速15%到20%。這也是一種好的做法，因為你可以從方法聲明中看出調用該方法不需要更新此對象的狀態。

減少不必要的全域變數

盡量避免static成員變數引用資源耗費過多的執行個體,比如Context

因為Context的引用超過它本身的生命週期，會導致Context泄漏。所以盡量使用Application這種Context類型。 你可以通過調用Context.getApplicationContext()或 Activity.getApplication()輕鬆得到Application對象。 

避免建立不必要的對象

最常見的例子就是當你要頻繁操作一個字串時，使用StringBuffer代替String。

對於所有所有基本類型的組合：int數組比Integer數組好，這也概括了一個基本事實，兩個平行的int數組比 (int,int)對象數組效能要好很多。

總體來說，就是避免建立短命的臨時對象。減少對象的建立就能減少垃圾收集，進而減少對使用者體驗的影響。

避免內部Getters/Setters在Android中，虛方法調用的代價比直接欄位訪問高昂許多。通常根據物件導向語言的實踐，在公用介面中使用Getters和Setters是有道理的，但在一個欄位經常被訪問的類中宜採用直接存取。

避免使用浮點數

通常的經驗是，在Android裝置中，浮點數會比整型慢兩倍。

使用實體類比介面好

假設你有一個HashMap對象，你可以將它聲明為HashMap或者Map：

Map map1 = new HashMap();HashMap map2 = new HashMap();

哪個更好呢？

按照傳統的觀點Map會更好些，因為這樣你可以改變他的具體實作類別，只要這個類繼承自Map介面。傳統的觀點對於傳統的程式是正確的，但是它並不適合嵌入式系統。調用一個介面的引用會比調用實體類的引用多花費一倍的時間。如果HashMap完全適合你的程式，那麼使用Map就沒有什麼價值。如果有些地方你不能確定，先避免使用Map，剩下的交給IDE提供的重構功能好了。(當然公用API是一個例外：一個好的API常常會犧牲一些效能）

避免使用枚舉

枚舉變數非常方便，但不幸的是它會犧牲執行的速度和並大幅增加檔案體積。

使用枚舉變數可以讓你的API更出色，並能提供編譯時間的檢查。所以在通常的時候你毫無疑問應該為公用API選擇枚舉變數。但是當效能方面有所限制的時候，你就應該避免這種做法了。

for迴圈

訪問成員變數比訪問本地變數慢得多，如下面一段代碼：

for(int i =0; i < this.mCount; i++)  {}

永遠不要在for的第二個條件中調用任何方法，如下面一段代碼：

for(int i =0; i < this.getCount(); i++) {}

對上面兩個例子最好改為：

int count = this.mCount; / int count = this.getCount();for(int i =0; i < count; i++)  {}

在java1.5中引入的for-each文法。編譯器會將對數組的引用和數組的長度儲存到本地變數中，這對訪問數組元素非常好。 但是編譯器還會在每次迴圈中產生一個額外的對本地變數的儲存操作（如下面例子中的變數a），這樣會比普通迴圈多出4個位元組，速度要稍微慢一些：

for (Foo a : mArray) {    sum += a.mSplat;}

瞭解並使用類庫

選擇Library中的代碼而非自己重寫，除了通常的那些原因外，考慮到系統空閑時會用彙編代碼調用來替代library方法，這可能比JIT中產生的等價的最好的Java代碼還要好。

當你在處理字串的時候，不要吝惜使用String.indexOf()，String.lastIndexOf()等特殊實現的方法。這些方法都是使用C/C++實現的，比起Java迴圈快10到100倍。

System.arraycopy方法在有JIT的Nexus One上，自行編碼的迴圈快9倍。

android.text.format包下的Formatter類，提供了IP地址轉換、檔案大小轉換等方法；DateFormat類，提供了各種時間轉換，都是非常高效的方法。

TextUtils類，對於字串處理Android為我們提供了一個簡單實用的TextUtils類，如果處理比較簡單的內容不用去思考Regex不妨試試這個在android.text.TextUtils的類

高效能MemoryFile類，很多人抱怨Android處理底層I/O效能不是很理想，如果不想使用NDK則可以通過MemoryFile類實現高效能的檔案讀寫操作。MemoryFile適用於哪些地方呢？對於I/O需要頻繁操作的，主要是和外部儲存相關的I/O操作，MemoryFile通過將 NAND或SD卡上的檔案，分段映射到記憶體中進行修改處理，這樣就用高速的RAM代替了ROM或SD卡，效能自然提高不少，對於Android手機而言同時還減少了電量消耗。該類實現的功能不是很多，直接從Object上繼承，通過JNI的方式直接在C底層執行。

Reuse:

Reuse重用，減少記憶體消耗的重要手段之一。核心思路就是將已經存在的記憶體資源重新使用而避免去建立新的，最典型的使用就是 緩衝（Cache ）和 池（Pool）。
Bitmap緩衝：

Bitmap緩衝分為兩種：

一種是記憶體緩衝，一種是硬碟緩衝。

記憶體緩衝（LruCache）：

以犧牲寶貴的應用記憶體為代價，記憶體緩衝提供了快速的Bitmap訪問方式。系統提供的LruCache類是非常適合用作緩衝Bitmap任務的，它將最近被引用到的Object Storage Service在一個強引用的LinkedHashMap中，並且在緩衝超過了指定大小之後將最近不常使用的對象釋放掉。

注意：以前有一個非常流行的記憶體緩衝實現是SoftReference(軟引用)或者WeakReference(弱引用)的Bitmap緩衝方案，然而現在已經不推薦使用了。自Android2.3版本(API Level 9)開始，記憶體回收行程更著重於對軟/弱引用的回收，這使得上述的方案相當無效。

硬碟緩衝（DiskLruCache）：

一個記憶體緩衝對加速訪問最近瀏覽過的Bitmap非常有協助，但是你不能局限於記憶體中的可用圖片。GridView這樣有著更大的資料集的組件可以很輕易消耗掉記憶體緩衝。你的應用有可能在執行其他任務(如打電話)的時候被打斷，並且在背景任務有可能被殺死或者緩衝被釋放。一旦使用者重新聚焦(resume)到你的應用，你得再次處理每一張圖片。

在這種情況下，硬碟緩衝可以用來儲存Bitmap並在圖片被記憶體緩衝釋放後減小圖片載入的時間(次數)。當然，從硬碟載入圖片比記憶體要慢，並且應該在後台線程進行，因為硬碟讀取的時間是不可預知的。

注意：如果訪問圖片的次數非常頻繁，那麼ContentProvider可能更適合用來儲存緩衝圖片，例如Image Gallery這樣的應用程式。