Android高效加載大圖、多圖解決方案,有效避免程序OOM

原文鏈接http://blog.csdn.net/guolin_blog/article/details/9316683

一.高效加載大圖

1.查看程序可用內(nèi)存大小

int maxMemory = (int)(Runtime.getRuntime().maxMemory()/1024);
Log.d("TAG","Max memory is "+maxmoory+"KB");

因此在展示高分辨率圖片的時(shí)候,最好先將圖片進(jìn)行壓縮。壓縮后的圖片大小應(yīng)該和用來(lái)展示它的控件大小相近,在一個(gè)很小的ImageView上顯示一張超大的圖片不會(huì)帶來(lái)任何視覺(jué)上的好處,但卻會(huì)占用我們相當(dāng)多寶貴的內(nèi)存,而且在性能上還可能會(huì)帶來(lái)負(fù)面影響。

每一種解析方法都提供了一個(gè)可選的BitmapFactory.Options參數(shù),將這個(gè)參數(shù)的inJustDecodeBounds屬性設(shè)置為true就可以讓解析方法禁止為bitmap分配內(nèi)存,返回值也不再是一個(gè)Bitmap對(duì)象,而是null。雖然Bitmap是null了,但是BitmapFactory.Options的outWidth、outHeight和outMimeType屬性都會(huì)被賦值。這個(gè)技巧讓我們可以在加載圖片之前就獲取到圖片的長(zhǎng)寬值和MIME類型,從而根據(jù)情況對(duì)圖片進(jìn)行壓縮。如下代碼所示:

BitmapFactory.Options options = new BitmapFactory.Options();
options.inJustDecodeBounds = true;//禁止為Bitmap分配內(nèi)存
BitmapFactory.decodeResource(getResources(),R.id.myimage,options);
int imageHeihht = options.outHeight;
int imageWidth = options.outWidth;
String imageType = options.outMimeType;

加載圖片前考慮是完整顯示圖片還是要壓縮后再顯示,就需要考慮以下因素:

  • 預(yù)估整張圖片占用的內(nèi)存
  • 為了加在一張圖片,你愿意提供多少內(nèi)存
  • 用于展示的圖片控件的實(shí)際大小
  • 當(dāng)前設(shè)備的屏幕尺寸和分辨率
    對(duì)圖片壓縮需要使用BitmapFactory.Options中的inSampleSize(例如:2048 * 1536像素的圖片,inSampleSize= 4,圖片被壓縮成 512 * 384 所占的內(nèi)存大小為512 * 384 *4 = 0.75M (假設(shè)圖片是ARGB_8888類型,即每個(gè)像素點(diǎn)占用4個(gè)字節(jié))
    下面的方法可以根據(jù)寬高計(jì)算出合適的inSampleSize值:
public static int calculateInSampleSize(BitmapFactory.Options options,int reqWidth,int reqHeight){
    //源圖片的高度和寬度
    final int height  = options.outHeight;
    final int width = options.outWidth;
    int inSampleSaze= 1;
    if(height>reqHeight||width>reqWidth){
        //計(jì)算實(shí)際寬高和目標(biāo)寬高的比率
        final int heightRatio = Math.round((float)height/(float)reqHeight);
        final int widthRatio = Math.round((float)height/(float)reqHeight);
        //選擇寬高比例較小的作為InSampleSize的值,這樣保證最終圖片的寬高是大于目標(biāo)的寬高
        inSampleSize = heightRatio>widthRatio?widthRatio:heightRatio;
        
    }
    return inSampleSize;
}

獲取到inSampleSize值以后再把inJustDecodeBounds設(shè)置為false,就可以使用壓縮后的圖片了

public static Bitmap decodeSampleBitmapFromResource(Resources res,int resId,int reqWidth,int reqHeight){
    //第一次設(shè)置inJustDecodeBounds為true,來(lái)獲取圖片大小
    final BitmapFactory.Options options = new BitmapFactory.Options();
    options.inJustDecodeBounds = true;
    BitmapFactory.decodeResource(res,resId,options);
    //調(diào)用方法計(jì)算inSampleSize
    options.inSampleSize = calculateInSampleSize(options,reqWidth,reqHeight);
    //使用insamplesize在此解析圖片
    options.inJustDecodeBounds = false;
    return BitmapFactory.decodeResource(res,resId,options);
}

下面的代碼非常簡(jiǎn)單的將任意一張圖片設(shè)置壓縮成100*100的縮略圖,并顯示在ImageView上

mImageView.setImageBitmap(decodeSampleBitmapFromResource(getResource(),R.id.myimage,100,100));

二.使用圖片緩存技術(shù)

防止頻繁的顯示多張圖片 以及回收過(guò)的圖片再次顯示導(dǎo)致大量的加載而引起OOM

內(nèi)存緩存技術(shù)對(duì)那些大量占用應(yīng)用程序?qū)氋F內(nèi)存的圖片提供了快速訪問(wèn)的方法。其中最核心的類是LruCache (此類在android-support-v4的包中提供) 。這個(gè)類非常適合用來(lái)緩存圖片,它的主要算法原理是==把最近使用的對(duì)象用強(qiáng)引用存儲(chǔ)在 LinkedHashMap 中,并且把最近最少使用的對(duì)象在緩存值達(dá)到預(yù)設(shè)定值之前從內(nèi)存中移除。==

為了能夠選擇一個(gè)合適的緩存大小給LruCache, 有以下多個(gè)因素應(yīng)該放入考慮范圍內(nèi),例如:

  • 你的設(shè)備可以為每個(gè)應(yīng)用程序分配多大的內(nèi)存?
  • 設(shè)備屏幕上一次最多能顯示多少?gòu)垐D片?有多少圖片需要進(jìn)行預(yù)加載,因?yàn)橛锌赡芎芸煲矔?huì)顯示在屏幕上?
  • 你的設(shè)備的屏幕大小和分辨率分別是多少?一個(gè)超高分辨率的設(shè)備(例如 Galaxy Nexus) 比起一個(gè)較低分辨率的設(shè)備(例如 Nexus S),在持有相同數(shù)量圖片的時(shí)候,需要更大的緩存空間。
  • 圖片的尺寸和大小,還有每張圖片會(huì)占據(jù)多少內(nèi)存空間。
  • 圖片被訪問(wèn)的頻率有多高?會(huì)不會(huì)有一些圖片的訪問(wèn)頻率比其它圖片要高?如果有的話,你也許應(yīng)該讓一些圖片常駐在內(nèi)存當(dāng)中,或者使用多個(gè)LruCache 對(duì)象來(lái)區(qū)分不同組的圖片。
  • 你能維持好數(shù)量和質(zhì)量之間的平衡嗎?有些時(shí)候,存儲(chǔ)多個(gè)低像素的圖片,而在后臺(tái)去開(kāi)線程加載高像素的圖片會(huì)更加的有效

下面是一個(gè)使用 LruCache 來(lái)緩存圖片的例子:

private LruCache<String,Bitmap>mMemoryChahe;
@Override
protected void onCreate(Bundle savedInstanceState){
    / 獲取到可用內(nèi)存的最大值,使用內(nèi)存超出這個(gè)值會(huì)引起OutOfMemory異常。  
    // LruCache通過(guò)構(gòu)造函數(shù)傳入緩存值,以KB為單位。  
     int maxMemory = (int) (Runtime.getRuntime().maxMemory() / 1024);  
    // 使用最大可用內(nèi)存值的1/8作為緩存的大小。  
    int cacheSize = maxMemory / 8; 
    mMemoryCache = new LruCache<String,Bitmap>(cacheSize){
        @Override
        protect int sizeOf(String key,Bitmap bitmap){
            //重寫此方法來(lái)衡量每張圖片的大小,默認(rèn)返回圖片數(shù)量.
            return bitmap.getByteCount()/1024;
        }
    };
}

public void addBitmapToMemoryCache(String key,Bitmap bitmap){
    if(getBitmapFromMemCache(key)==null){
        mMemoryCache.put(key,bitmap);
    }
}
public Bitmap getBitmapFromMemoryCache(String key){
    return mMemoryCache.get(key);
}

在這個(gè)例子當(dāng)中,使用了系統(tǒng)分配給應(yīng)用程序的八分之一內(nèi)存來(lái)作為緩存大小。在中高配置的手機(jī)當(dāng)中,這大概會(huì)有4兆(32/8)的緩存空間。一個(gè)全屏幕的 GridView 使用4張 800x480分辨率的圖片來(lái)填充,則大概會(huì)占用1.5兆的空間(800 * 480 * 4)。因此,這個(gè)緩存大小可以存儲(chǔ)2.5頁(yè)的圖片。

當(dāng)向 ImageView 中加載一張圖片時(shí),首先會(huì)在 LruCache 的緩存中進(jìn)行檢查。如果找到了相應(yīng)的鍵值,則會(huì)立刻更新ImageView ,否則開(kāi)啟一個(gè)后臺(tái)線程來(lái)加載這張圖片。

public void loadBitmap(int resId,ImageView imageview){
    final String imageKay = String valueOf(resId);
    Bitmap bitmap = mMemoryCache.getBitmapFromMemoryCache(imageKey);
    if(bitmap!=null){
        imageview.setImageBitmap(bitmap);
    }else{
        imageview.setImageResource(R.drawable.image_placeholder);
        //緩存
        BitmapWorkerTask task = new BitmapWorkTask(imageview);
        task.execute(resId);
    }
    
}

class BitmapWorkerTask extends AsyncTask<Integer,Void,Bitmap>{
    //異步加載圖片
    @Override
    protected Bitmap doInBackground(Integer...params){
        final Bitmap bitmap = edcodeSampleBitmapFromResource(getResource(),params[0],100,100);
        addBitmapToMemoryCache(String.valueOf(params[0],bitmap));
        return bitmap;
    }
}
?著作權(quán)歸作者所有,轉(zhuǎn)載或內(nèi)容合作請(qǐng)聯(lián)系作者
平臺(tái)聲明:文章內(nèi)容(如有圖片或視頻亦包括在內(nèi))由作者上傳并發(fā)布,文章內(nèi)容僅代表作者本人觀點(diǎn),簡(jiǎn)書(shū)系信息發(fā)布平臺(tái),僅提供信息存儲(chǔ)服務(wù)。
  • 序言:七十年代末,一起剝皮案震驚了整個(gè)濱河市,隨后出現(xiàn)的幾起案子,更是在濱河造成了極大的恐慌,老刑警劉巖,帶你破解...
    沈念sama閱讀 230,431評(píng)論 6 544
  • 序言:濱河連續(xù)發(fā)生了三起死亡事件,死亡現(xiàn)場(chǎng)離奇詭異,居然都是意外死亡,警方通過(guò)查閱死者的電腦和手機(jī),發(fā)現(xiàn)死者居然都...
    沈念sama閱讀 99,637評(píng)論 3 429
  • 文/潘曉璐 我一進(jìn)店門,熙熙樓的掌柜王于貴愁眉苦臉地迎上來(lái),“玉大人,你說(shuō)我怎么就攤上這事。” “怎么了?”我有些...
    開(kāi)封第一講書(shū)人閱讀 178,555評(píng)論 0 383
  • 文/不壞的土叔 我叫張陵,是天一觀的道長(zhǎng)。 經(jīng)常有香客問(wèn)我,道長(zhǎng),這世上最難降的妖魔是什么? 我笑而不...
    開(kāi)封第一講書(shū)人閱讀 63,900評(píng)論 1 318
  • 正文 為了忘掉前任,我火速辦了婚禮,結(jié)果婚禮上,老公的妹妹穿的比我還像新娘。我一直安慰自己,他們只是感情好,可當(dāng)我...
    茶點(diǎn)故事閱讀 72,629評(píng)論 6 412
  • 文/花漫 我一把揭開(kāi)白布。 她就那樣靜靜地躺著,像睡著了一般。 火紅的嫁衣襯著肌膚如雪。 梳的紋絲不亂的頭發(fā)上,一...
    開(kāi)封第一講書(shū)人閱讀 55,976評(píng)論 1 328
  • 那天,我揣著相機(jī)與錄音,去河邊找鬼。 笑死,一個(gè)胖子當(dāng)著我的面吹牛,可吹牛的內(nèi)容都是我干的。 我是一名探鬼主播,決...
    沈念sama閱讀 43,976評(píng)論 3 448
  • 文/蒼蘭香墨 我猛地睜開(kāi)眼,長(zhǎng)吁一口氣:“原來(lái)是場(chǎng)噩夢(mèng)啊……” “哼!你這毒婦竟也來(lái)了?” 一聲冷哼從身側(cè)響起,我...
    開(kāi)封第一講書(shū)人閱讀 43,139評(píng)論 0 290
  • 序言:老撾萬(wàn)榮一對(duì)情侶失蹤,失蹤者是張志新(化名)和其女友劉穎,沒(méi)想到半個(gè)月后,有當(dāng)?shù)厝嗽跇?shù)林里發(fā)現(xiàn)了一具尸體,經(jīng)...
    沈念sama閱讀 49,686評(píng)論 1 336
  • 正文 獨(dú)居荒郊野嶺守林人離奇死亡,尸身上長(zhǎng)有42處帶血的膿包…… 初始之章·張勛 以下內(nèi)容為張勛視角 年9月15日...
    茶點(diǎn)故事閱讀 41,411評(píng)論 3 358
  • 正文 我和宋清朗相戀三年,在試婚紗的時(shí)候發(fā)現(xiàn)自己被綠了。 大學(xué)時(shí)的朋友給我發(fā)了我未婚夫和他白月光在一起吃飯的照片。...
    茶點(diǎn)故事閱讀 43,641評(píng)論 1 374
  • 序言:一個(gè)原本活蹦亂跳的男人離奇死亡,死狀恐怖,靈堂內(nèi)的尸體忽然破棺而出,到底是詐尸還是另有隱情,我是刑警寧澤,帶...
    沈念sama閱讀 39,129評(píng)論 5 364
  • 正文 年R本政府宣布,位于F島的核電站,受9級(jí)特大地震影響,放射性物質(zhì)發(fā)生泄漏。R本人自食惡果不足惜,卻給世界環(huán)境...
    茶點(diǎn)故事閱讀 44,820評(píng)論 3 350
  • 文/蒙蒙 一、第九天 我趴在偏房一處隱蔽的房頂上張望。 院中可真熱鬧,春花似錦、人聲如沸。這莊子的主人今日做“春日...
    開(kāi)封第一講書(shū)人閱讀 35,233評(píng)論 0 28
  • 文/蒼蘭香墨 我抬頭看了看天上的太陽(yáng)。三九已至,卻和暖如春,著一層夾襖步出監(jiān)牢的瞬間,已是汗流浹背。 一陣腳步聲響...
    開(kāi)封第一講書(shū)人閱讀 36,567評(píng)論 1 295
  • 我被黑心中介騙來(lái)泰國(guó)打工, 沒(méi)想到剛下飛機(jī)就差點(diǎn)兒被人妖公主榨干…… 1. 我叫王不留,地道東北人。 一個(gè)月前我還...
    沈念sama閱讀 52,362評(píng)論 3 400
  • 正文 我出身青樓,卻偏偏與公主長(zhǎng)得像,于是被迫代替她去往敵國(guó)和親。 傳聞我的和親對(duì)象是個(gè)殘疾皇子,可洞房花燭夜當(dāng)晚...
    茶點(diǎn)故事閱讀 48,604評(píng)論 2 380

推薦閱讀更多精彩內(nèi)容