Bitmap內(nèi)存優(yōu)化：
Bitmap是內(nèi)存消耗大戶，絕大多數(shù)的OOM崩潰都是在操作Bitmap時(shí)產(chǎn)生的，下面來(lái)看看如何幾個(gè)處理圖片的方法：

圖片顯示優(yōu)化：
圖片服務(wù)器配合加載對(duì)應(yīng)尺寸的圖片。
根據(jù)屏幕尺寸和用戶體驗(yàn)地最低值選擇圖片壓縮尺寸和質(zhì)量。

圖片大小優(yōu)化：
直接使用ImageView顯示bitmap會(huì)占用較多資源，特別是圖片較大的時(shí)候，可能導(dǎo)致崩潰。
使用BitmapFactory.Options設(shè)置inSampleSize, 這樣做可以減少對(duì)系統(tǒng)資源的要求。
屬性值inSampleSize表示縮略圖大小為原始圖片大小的幾分之一，即如果這個(gè)值為2，則取出的縮略圖的寬和高都是原始圖片的1/2，圖片大小就為原始大小的1/4。

代碼：
BitmapFactory.Options bitmapFactoryOptions = new BitmapFactory.Options();
bitmapFactoryOptions.inJustDecodeBounds = true;
bitmapFactoryOptions.inSampleSize = 2;
// 這里一定要將其設(shè)置回false，因?yàn)橹拔覀儗⑵湓O(shè)置成了true
// 設(shè)置inJustDecodeBounds為true后，decodeFile并不分配空間，即，BitmapFactory解碼出來(lái)的Bitmap為Null,但可計(jì)算出原始圖片的長(zhǎng)度和寬度
options.inJustDecodeBounds = false;
Bitmap bmp = BitmapFactory.decodeFile(sourceBitmap, options);

圖片像素優(yōu)化：
Android中圖片有四種屬性，分別是：
ALPHA_8：每個(gè)像素占用1byte內(nèi)存
ARGB_4444：每個(gè)像素占用2byte內(nèi)存
ARGB_8888：每個(gè)像素占用4byte內(nèi)存 （默認(rèn)）
RGB_565：每個(gè)像素占用2byte內(nèi)存

Android默認(rèn)的顏色模式為ARGB_8888，這個(gè)顏色模式色彩最細(xì)膩，顯示質(zhì)量最高。但同樣的，占用的內(nèi)存也最大。 所以在對(duì)圖片效果不是特別高的情況下使用RGB_565（565沒(méi)有透明度屬性）

，如下：

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);  
}  

圖片回收優(yōu)化：
使用Bitmap過(guò)后，就需要及時(shí)的調(diào)用Bitmap.recycle()方法來(lái)釋放Bitmap占用的內(nèi)存空間，而不要等Android系統(tǒng)來(lái)進(jìn)行釋放。
下面是釋放Bitmap的示例代碼片段。

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

另外也可以使用lru算法來(lái)控制bitmap對(duì)內(nèi)存占用。

捕獲異常優(yōu)化：
經(jīng)過(guò)上面這些優(yōu)化后還會(huì)存在報(bào)OOM的風(fēng)險(xiǎn)，所以下面需要一道最后的關(guān)卡——捕獲OOM異常：

Bitmap bitmap = null;  
try {  
    // 實(shí)例化Bitmap  
    bitmap = BitmapFactory.decodeFile(path);  
} catch (OutOfMemoryError e) {  
    // 捕獲OutOfMemoryError，避免直接崩潰  
}  
if (bitmap == null) {  
    // 如果實(shí)例化失敗 返回默認(rèn)的Bitmap對(duì)象  
    return defaultBitmapMap;  
}  

Java四種引用類(lèi)型：

強(qiáng)引用（strong reference）
如：Object object=new Object（），object就是一個(gè)強(qiáng)引用了。當(dāng)內(nèi)存空間不足，Java虛擬機(jī)寧愿拋出OutOfMemoryError錯(cuò)誤，使程序異常終止，也不會(huì)靠隨意回收具有強(qiáng)引用的對(duì)象來(lái)解

決內(nèi)存不足問(wèn)題。
軟引用（SoftReference）
只有內(nèi)存不夠時(shí)才回收,常用于緩存；當(dāng)內(nèi)存達(dá)到一個(gè)閥值，GC就會(huì)去回收它；
弱引用（WeakReference）
弱引用的對(duì)象擁有更短暫的生命周期。在垃圾回收器線程掃描它 所管轄的內(nèi)存區(qū)域的過(guò)程中，一旦發(fā)現(xiàn)了只具有弱引用的對(duì)象，不管當(dāng)前內(nèi)存空間足夠與否，都會(huì)回收它的內(nèi)存。
虛引用（PhantomReference）
"虛引用"顧名思義，就是形同虛設(shè)，與其他幾種引用都不同，虛引用并不會(huì)決定對(duì)象的生命周期。如果一個(gè)對(duì)象僅持有虛引用，那么它就和沒(méi)有任何引用一樣，在任何時(shí)候都可能被垃圾回收

。

Android 2.3 引用回收變化：

注意：對(duì)于SoftReference(軟引用)或者WeakReference(弱引用)的Bitmap緩存方案，現(xiàn)在已經(jīng)不推薦使用了。自Android2.3版本(API Level 9)開(kāi)始，垃圾回收器更著重于對(duì)軟/弱引用的回收

，那么依靠軟、弱引用來(lái)優(yōu)化內(nèi)存回收已經(jīng)不可靠了。

到底什么時(shí)候使用軟引用，什么時(shí)候使用弱引用呢？

個(gè)人認(rèn)為，如果只是想避免OutOfMemory異常的發(fā)生，則可以使用軟引用。如果對(duì)于應(yīng)用的性能更在意，想盡快回收一些占用內(nèi)存比較大的對(duì)象，則可以使用弱引用。
還有就是可以根據(jù)對(duì)象是否經(jīng)常使用來(lái)判斷。如果該對(duì)象可能會(huì)經(jīng)常使用的，就盡量用軟引用。如果該對(duì)象不被使用的可能性更大些，就可以用弱引用。
另外，和弱引用功能類(lèi)似的是WeakHashMap。WeakHashMap對(duì)于一個(gè)給定的鍵，其映射的存在并不阻止垃圾回收器對(duì)該鍵的回收，回收以后，其條目從映射中有效地移除。WeakHashMap使用

ReferenceQueue實(shí)現(xiàn)的這種機(jī)制。

static final修飾符使用的好處

讓我們來(lái)看看這兩段在類(lèi)前面的聲明：
static int intVal = 42;
static String strVal = "Hello, world!";
編譯器會(huì)生成一個(gè)叫做clinit的初始化類(lèi)的方法，當(dāng)類(lèi)第一次被使用的時(shí)候這個(gè)方法會(huì)被執(zhí)行。方法會(huì)將42賦給intVal，然后把一個(gè)指向類(lèi)中常量表 的引用賦給strVal。當(dāng)以后要用到這些值

的時(shí)候，會(huì)在成員變量表中查找到他們。 下面我們做些改進(jìn)，使用“final”關(guān)鍵字：
static final int intVal = 42;
static final String strVal = "Hello, world!";
現(xiàn)在，類(lèi)不再需要clinit方法，因?yàn)樵诔蓡T變量初始化的時(shí)候，會(huì)將常量直接保存到類(lèi)文件中。用到intVal的代碼被直接替換成42，而使用strVal的會(huì)指向一個(gè)字符串常量，而不是使用成員

變量。
將一個(gè)方法或類(lèi)聲明為final不會(huì)帶來(lái)性能的提升，但是會(huì)幫助編譯器優(yōu)化代碼。舉例說(shuō)，如果編譯器知道一個(gè)getter方法不會(huì)被重載，那么編譯器會(huì)對(duì)其采用內(nèi)聯(lián)調(diào)用。
你也可以將本地變量聲明為final，同樣，這也不會(huì)帶來(lái)性能的提升。使用“final”只能使本地變量看起來(lái)更清晰些（但是也有些時(shí)候這是必須的，比如在使用匿名內(nèi)部類(lèi)的時(shí)候）。

靜態(tài)方法代替虛擬方法

如果不需要訪問(wèn)某對(duì)象的字段，將方法設(shè)置為靜態(tài)，調(diào)用會(huì)加速15%到20%。這也是一種好的做法，因?yàn)槟憧梢詮姆椒暶髦锌闯稣{(diào)用該方法不需要更新此對(duì)象的狀態(tài)。

減少不必要的全局變量

盡量避免static成員變量引用資源耗費(fèi)過(guò)多的實(shí)例,比如Context因?yàn)镃ontext的引用超過(guò)它本身的生命周期，會(huì)導(dǎo)致Context泄漏。所以盡量使用Application這種Context類(lèi)型。 你可以通過(guò)調(diào)

用Context.getApplicationContext()或 Activity.getApplication()輕松得到Application對(duì)象。

避免創(chuàng)建不必要的對(duì)象

最常見(jiàn)的例子就是當(dāng)你要頻繁操作一個(gè)字符串時(shí)，使用StringBuffer代替String。
對(duì)于所有所有基本類(lèi)型的組合：int數(shù)組比Integer數(shù)組好，這也概括了一個(gè)基本事實(shí)，兩個(gè)平行的int數(shù)組比 (int,int)對(duì)象數(shù)組性能要好很多。
總體來(lái)說(shuō)，就是避免創(chuàng)建短命的臨時(shí)對(duì)象。減少對(duì)象的創(chuàng)建就能減少垃圾收集，進(jìn)而減少對(duì)用戶體驗(yàn)的影響。

避免內(nèi)部Getters/Setters

在Android中，虛方法調(diào)用的代價(jià)比直接字段訪問(wèn)高昂許多。通常根據(jù)面向?qū)ο笳Z(yǔ)言的實(shí)踐，在公共接口中使用Getters和Setters是有道理的，但在一個(gè)字段經(jīng)常被訪問(wèn)的類(lèi)中宜采用直接訪問(wèn)

。

避免使用浮點(diǎn)數(shù)

通常的經(jīng)驗(yàn)是，在Android設(shè)備中，浮點(diǎn)數(shù)會(huì)比整型慢兩倍。

使用實(shí)體類(lèi)比接口好

假設(shè)你有一個(gè)HashMap對(duì)象，你可以將它聲明為HashMap或者M(jìn)ap：
Map map1 = new HashMap();
HashMap map2 = new HashMap();
哪個(gè)更好呢？
按照傳統(tǒng)的觀點(diǎn)Map會(huì)更好些，因?yàn)檫@樣你可以改變他的具體實(shí)現(xiàn)類(lèi)，只要這個(gè)類(lèi)繼承自Map接口。傳統(tǒng)的觀點(diǎn)對(duì)于傳統(tǒng)的程序是正確的，但是它并不適合嵌入式系統(tǒng)。調(diào)用一個(gè)接口的引用會(huì)

比調(diào)用實(shí)體類(lèi)的引用多花費(fèi)一倍的時(shí)間。如果HashMap完全適合你的程序，那么使用Map就沒(méi)有什么價(jià)值。如果有些地方你不能確定，先避免使用Map，剩下的交給IDE提供的重構(gòu)功能好了。(當(dāng)

然公共API是一個(gè)例外：一個(gè)好的API常常會(huì)犧牲一些性能）

避免使用枚舉

枚舉變量非常方便，但不幸的是它會(huì)犧牲執(zhí)行的速度和并大幅增加文件體積。
使用枚舉變量可以讓你的API更出色，并能提供編譯時(shí)的檢查。所以在通常的時(shí)候你毫無(wú)疑問(wèn)應(yīng)該為公共API選擇枚舉變量。但是當(dāng)性能方面有所限制的時(shí)候，你就應(yīng)該避免這種做法了。

for循環(huán)已經(jīng)foreach 循環(huán)

在java1.5中引入的for-each語(yǔ)法。編譯器會(huì)將對(duì)數(shù)組的引用和數(shù)組的長(zhǎng)度保存到本地變量中，這對(duì)訪問(wèn)數(shù)組元素非常好。 但是編譯器還會(huì)在每次循環(huán)中產(chǎn)生一個(gè)額外的對(duì)本地變量的存儲(chǔ)操

作（如下面例子中的變量a），這樣會(huì)比普通循環(huán)多出4個(gè)字節(jié)，速度要稍微慢一些：
使用for循環(huán)時(shí)，判斷條件盡量使用局部變量和常量。

了解并使用類(lèi)庫(kù)

選擇Library中的代碼而非自己重寫(xiě)，除了通常的那些原因外，考慮到系統(tǒng)空閑時(shí)會(huì)用匯編代碼調(diào)用來(lái)替代library方法，這可能比JIT中生成的等價(jià)的最好的Java代碼還要好。
當(dāng)你在處理字串的時(shí)候，不要吝惜使用String.indexOf()，String.lastIndexOf()等特殊實(shí)現(xiàn)的方法。這些方法都是使用C/C++實(shí)現(xiàn)的，比起Java循環(huán)快10到100倍。
System.arraycopy方法在有JIT的Nexus One上，自行編碼的循環(huán)快9倍。
android.text.format包下的Formatter類(lèi)，提供了IP地址轉(zhuǎn)換、文件大小轉(zhuǎn)換等方法；DateFormat類(lèi)，提供了各種時(shí)間轉(zhuǎn)換，都是非常高效的方法。
TextUtils類(lèi)，對(duì)于字符串處理Android為我們提供了一個(gè)簡(jiǎn)單實(shí)用的TextUtils類(lèi)，如果處理比較簡(jiǎn)單的內(nèi)容不用去思考正則表達(dá)式不妨試試這個(gè)在android.text.TextUtils的類(lèi)
高性能MemoryFile類(lèi)，很多人抱怨Android處理底層I/O性能不是很理想，如果不想使用NDK則可以通過(guò)MemoryFile類(lèi)實(shí)現(xiàn)高性能的文件讀寫(xiě)操作。MemoryFile適用于哪些地方呢？對(duì)于I/O需要

頻繁操作的，主要是和外部存儲(chǔ)相關(guān)的I/O操作，MemoryFile通過(guò)將 NAND或SD卡上的文件，分段映射到內(nèi)存中進(jìn)行修改處理，這樣就用高速的RAM代替了ROM或SD卡，性能自然提高不少，對(duì)于

Android手機(jī)而言同時(shí)還減少了電量消耗。該類(lèi)實(shí)現(xiàn)的功能不是很多，直接從Object上繼承，通過(guò)JNI的方式直接在C底層執(zhí)行。

內(nèi)存緩存（LruCache）：

以犧牲寶貴的應(yīng)用內(nèi)存為代價(jià)，內(nèi)存緩存提供了快速的Bitmap訪問(wèn)方式。系統(tǒng)提供的LruCache類(lèi)是非常適合用作緩存Bitmap任務(wù)的，它將最近被引用到的對(duì)象存儲(chǔ)在一個(gè)強(qiáng)引用的

LinkedHashMap中，并且在緩存超過(guò)了指定大小之后將最近不常使用的對(duì)象釋放掉。
注意：以前有一個(gè)非常流行的內(nèi)存緩存實(shí)現(xiàn)是SoftReference(軟引用)或者WeakReference(弱引用)的Bitmap緩存方案，然而現(xiàn)在已經(jīng)不推薦使用了。自Android2.3版本(API Level 9)開(kāi)始，垃

圾回收器更著重于對(duì)軟/弱引用的回收，這使得上述的方案相當(dāng)無(wú)效。

硬盤(pán)緩存（DiskLruCache）：

一個(gè)內(nèi)存緩存對(duì)加速訪問(wèn)最近瀏覽過(guò)的Bitmap非常有幫助，但是你不能局限于內(nèi)存中的可用圖片。GridView這樣有著更大的數(shù)據(jù)集的組件可以很輕易消耗掉內(nèi)存緩存。你的應(yīng)用有可能在執(zhí)行

其他任務(wù)(如打電話)的時(shí)候被打斷，并且在后臺(tái)的任務(wù)有可能被殺死或者緩存被釋放。一旦用戶重新聚焦(resume)到你的應(yīng)用，你得再次處理每一張圖片。
在這種情況下，硬盤(pán)緩存可以用來(lái)存儲(chǔ)Bitmap并在圖片被內(nèi)存緩存釋放后減小圖片加載的時(shí)間(次數(shù))。當(dāng)然，從硬盤(pán)加載圖片比內(nèi)存要慢，并且應(yīng)該在后臺(tái)線程進(jìn)行，因?yàn)橛脖P(pán)讀取的時(shí)間是

不可預(yù)知的。

對(duì)象池：
對(duì)象池使用的基本思路是：將用過(guò)的對(duì)象保存起來(lái)，等下一次需要這種對(duì)象的時(shí)候，再拿出來(lái)重復(fù)使用，從而在一定程度上減少頻繁創(chuàng)建對(duì)象所造成的開(kāi)銷(xiāo)。 并非所有對(duì)象都適合拿來(lái)池化―

―因?yàn)榫S護(hù)對(duì)象池也要造成一定開(kāi)銷(xiāo)。對(duì)生成時(shí)開(kāi)銷(xiāo)不大的對(duì)象進(jìn)行池化，反而可能會(huì)出現(xiàn)“維護(hù)對(duì)象池的開(kāi)銷(xiāo)”大于“生成新對(duì)象的開(kāi)銷(xiāo)”，從而使性能降低的情況。但是對(duì)于生成時(shí)開(kāi)銷(xiāo)

可觀的對(duì)象，池化技術(shù)就是提高性能的有效策略了。

線程池：
線程池的基本思想還是一種對(duì)象池的思想，開(kāi)辟一塊內(nèi)存空間，里面存放了眾多(未死亡)的線程，池中線程執(zhí)行調(diào)度由池管理器來(lái)處理。當(dāng)有線程任務(wù)時(shí)，從池中取一個(gè)，執(zhí)行完成后線程對(duì)

象歸池，這樣可以避免反復(fù)創(chuàng)建線程對(duì)象所帶來(lái)的性能開(kāi)銷(xiāo)，節(jié)省了系統(tǒng)的資源。
比如：一個(gè)應(yīng)用要和網(wǎng)絡(luò)打交道，有很多步驟需要訪問(wèn)網(wǎng)絡(luò)，為了不阻塞主線程，每個(gè)步驟都創(chuàng)建個(gè)線程，在線程中和網(wǎng)絡(luò)交互，用線程池就變的簡(jiǎn)單，線程池是對(duì)線程的一種封裝，讓線程

用起來(lái)更加簡(jiǎn)便，只需要?jiǎng)?chuàng)一個(gè)線程池，把這些步驟像任務(wù)一樣放進(jìn)線程池，在程序銷(xiāo)毀時(shí)只要調(diào)用線程池的銷(xiāo)毀函數(shù)即可。