您當(dāng)前位置：首頁(yè) > 互聯(lián)網(wǎng) > ANDROID內(nèi)存優(yōu)化(大匯總――中)

ANDROID內(nèi)存優(yōu)化(大匯總――中)

來(lái)源：程序員人生發(fā)布時(shí)間：2014-10-11 08:00:01 閱讀次數(shù)：2642次

轉(zhuǎn)載請(qǐng)注明本文出自大苞米的博客（http://blog.csdn.net/a396901990），謝謝支持！

寫(xiě)在最前：

本文的思路主要借鑒了2014年AnDevCon開(kāi)發(fā)者大會(huì)的一個(gè)演講PPT，加上把網(wǎng)上搜集的各種內(nèi)存零散知識(shí)點(diǎn)進(jìn)行匯總、挑選、簡(jiǎn)化后整理而成。

所以我將本文定義為一個(gè)工具類(lèi)的文章，如果你在ANDROID開(kāi)發(fā)中遇到關(guān)于內(nèi)存問(wèn)題，或者馬上要參加面試，或者就是單純的學(xué)習(xí)或復(fù)習(xí)一下內(nèi)存相關(guān)知識(shí)，都?xì)g迎閱讀。（本文最后我會(huì)盡量列出所參考的文章）。

OOM：

內(nèi)存泄露可以引發(fā)很多的問(wèn)題：

1.程序卡頓，響應(yīng)速度慢（內(nèi)存占用高時(shí)JVM虛擬機(jī)會(huì)頻繁觸發(fā)GC）

2.莫名消失（當(dāng)你的程序所占內(nèi)存越大，它在后臺(tái)的時(shí)候就越可能被干掉。反之內(nèi)存占用越小，在后臺(tái)存在的時(shí)間就越長(zhǎng)）

3.直接崩潰（OutOfMemoryError）

ANDROID內(nèi)存面臨的問(wèn)題：

1.有限的堆內(nèi)存，原始只有16M

2.內(nèi)存大小消耗等根據(jù)設(shè)備，操作系統(tǒng)等級(jí)，屏幕尺寸的不同而不同

3.程序不能直接控制

4.支持后臺(tái)多任務(wù)處理（multitasking）

5.運(yùn)行在虛擬機(jī)之上

5R：

本文主要通過(guò)如下的5R方法來(lái)對(duì)ANDROID內(nèi)存進(jìn)行優(yōu)化：

1.Reckon（計(jì)算）

首先需要知道你的app所消耗內(nèi)存的情況，知己知彼才能百戰(zhàn)不殆

2.Reduce（減少）

消耗更少的資源

3.Reuse（重用）

當(dāng)?shù)谝淮问褂猛暌院螅M量給其他的使用

5.Recycle（回收）

返回資源給生產(chǎn)流

4.Review（檢查）

回顧檢查你的程序，看看設(shè)計(jì)或代碼有什么不合理的地方。

Reckon：

關(guān)于內(nèi)存簡(jiǎn)介，和Reckon（內(nèi)存計(jì)算）的內(nèi)容請(qǐng)看上一篇文章：ANDROID內(nèi)存優(yōu)化(大匯總――上)

Reduce ：

Reduce的意思就是減少，直接減少內(nèi)存的使用是最有效的優(yōu)化方式。

下面來(lái)看看有哪些方法可以減少內(nèi)存使用：

Bitmap：

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

圖片顯示：

我們需要根據(jù)需求去加載圖片的大小。

例如在列表中僅用于預(yù)覽時(shí)加載縮略圖（thumbnails ）。

只有當(dāng)用戶(hù)點(diǎn)擊具體條目想看詳細(xì)信息的時(shí)候，這時(shí)另啟動(dòng)一個(gè)fragment／activity／對(duì)話框等等，去顯示整個(gè)圖片

圖片大小：

直接使用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);

圖片像素：

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

圖片回收：

使用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();

捕獲異常：

經(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; }

修改對(duì)象引用類(lèi)型：

引用類(lèi)型：

引用分為四種級(jí)別，這四種級(jí)別由高到低依次為：強(qiáng)引用>軟引用>弱引用>虛引用。

強(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í)候都可能被垃圾回收。

軟引用和弱引用的應(yīng)用實(shí)例：

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

在Android應(yīng)用的開(kāi)發(fā)中，為了防止內(nèi)存溢出，在處理一些占用內(nèi)存大而且聲明周期較長(zhǎng)的對(duì)象時(shí)候，可以盡量應(yīng)用軟引用和弱引用技術(shù)。

下面以使用軟引用為例來(lái)詳細(xì)說(shuō)明（弱引用的使用方式與軟引用是類(lèi)似的）：

假設(shè)我們的應(yīng)用會(huì)用到大量的默認(rèn)圖片，而且這些圖片很多地方會(huì)用到。如果每次都去讀取圖片，由于讀取文件需要硬件操作，速度較慢，會(huì)導(dǎo)致性能較低。所以我們考慮將圖片緩存起來(lái)，需要的時(shí)候直接從內(nèi)存中讀取。但是，由于圖片占用內(nèi)存空間比較大，緩存很多圖片需要很多的內(nèi)存，就可能比較容易發(fā)生OutOfMemory異常。這時(shí)，我們可以考慮使用軟引用技術(shù)來(lái)避免這個(gè)問(wèn)題發(fā)生。

首先定義一個(gè)HashMap，保存軟引用對(duì)象。

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

再來(lái)定義一個(gè)方法，保存Bitmap的軟引用到HashMap。

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

獲取的時(shí)候，可以通過(guò)SoftReference的get()方法得到Bitmap對(duì)象。

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

使用軟引用以后，在OutOfMemory異常發(fā)生之前，這些緩存的圖片資源的內(nèi)存空間可以被釋放掉的，從而避免內(nèi)存達(dá)到上限，避免Crash發(fā)生。

需要注意的是，在垃圾回收器對(duì)這個(gè)Java對(duì)象回收前，SoftReference類(lèi)所提供的get方法會(huì)返回Java對(duì)象的強(qiáng)引用，一旦垃圾線程回收該Java對(duì)象之后，get方法將返回null。所以在獲取軟引用對(duì)象的代碼中，一定要判斷是否為null，以免出現(xiàn)NullPointerException異常導(dǎo)致應(yī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ī)制。

其他小tips：

對(duì)常量使用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ì)用戶(hù)體驗(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)

訪問(wèn)成員變量比訪問(wèn)本地變量慢得多，如下面一段代碼：

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

永遠(yuǎn)不要在for的第二個(gè)條件中調(diào)用任何方法，如下面一段代碼：

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

對(duì)上面兩個(gè)例子最好改為：

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

在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 (Foo a : mArray) { sum += a.mSplat; }

了解并使用類(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í)行。

Reuse:

Reuse重用，減少內(nèi)存消耗的重要手段之一。

核心思路就是將已經(jīng)存在的內(nèi)存資源重新使用而避免去創(chuàng)建新的，最典型的使用就是緩存（Cache）和池（Pool）。

Bitmap緩存：

Bitmap緩存分為兩種：

一種是內(nèi)存緩存，一種是硬盤(pán)緩存。

內(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ù)有可能被殺死或者緩存被釋放。一旦用戶(hù)重新聚焦(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ù)知的。

注意：如果訪問(wèn)圖片的次數(shù)非常頻繁，那么ContentProvider可能更適合用來(lái)存儲(chǔ)緩存圖片，例如Image Gallery這樣的應(yīng)用程序。

更多關(guān)于內(nèi)存緩存和硬盤(pán)緩存的內(nèi)容請(qǐng)看Google官方教程https://developer.android.com/develop/index.html

圖片緩存的開(kāi)源項(xiàng)目：

對(duì)于圖片的緩存現(xiàn)在都傾向于使用開(kāi)源項(xiàng)目，這里我列出幾個(gè)我搜到的：

1. Android-Universal-Image-Loader 圖片緩存

目前使用最廣泛的圖片緩存，支持主流圖片緩存的絕大多數(shù)特性。
項(xiàng)目地址：https://github.com/nostra13/Android-Universal-Image-Loader

2. picasso square開(kāi)源的圖片緩存
項(xiàng)目地址：https://github.com/square/picasso
特點(diǎn)：(1)可以自動(dòng)檢測(cè)adapter的重用并取消之前的下載
(2)圖片變換
(3)可以加載本地資源
(4)可以設(shè)置占位資源
(5)支持debug模式

生活不易，碼農(nóng)辛苦
如果您覺(jué)得本網(wǎng)站對(duì)您的學(xué)習(xí)有所幫助,可以手機(jī)掃描二維碼進(jìn)行捐贈(zèng)
程序員人生