android 圖片載入,OOM 問題

來源:互聯網
上載者:User

android 圖片載入,OOM 問題

 

 

首先處理這個問題,用了1個星期,非常努力,拚命的尋找哪裡出現了OOM 記憶體溢出的問題,可是都沒找到結果,一直以為是自己使用的Picaso載入圖片框架,只載入了圖片,但是activity 銷毀時,沒有做記憶體釋放的功能,所以自己去嘗試方法去解決問題:

 

1.換一個圖片框架:Xutil 圖片框架

結果只是換湯不換藥。 還是會出現OOM ,記憶體溢出問題

 

2.圖片單獨處理:網上說針對於大圖,要做縮放處理,並對產生的BitMap 對象進行記憶體處理

 

 private void initDisplayImageOption(){        options = new DisplayImageOptions.Builder()                .showImageOnLoading(R.drawable.video_default) //設定圖片在下載期間顯示的圖片                .showImageForEmptyUri(R.drawable.image_background_empty) //設定圖片Uri為空白或是錯誤的時候顯示的圖片                //.showImageOnFail(R.drawable.image_background_erro) //設定圖片載入/解碼過程中錯誤時候顯示的圖片                .cacheInMemory(false) //設定下載的圖片是否緩衝在記憶體中                .cacheOnDisk(true) //設定下載的圖片是否緩衝在SD卡中                .considerExifParams(true) //是否考慮JPEG映像EXIF參數(旋轉,翻轉)                .imageScaleType(ImageScaleType.EXACTLY_STRETCHED) //設定圖片以如何的編碼方式顯示                .bitmapConfig(Bitmap.Config.RGB_565) //設定圖片的解碼類型//               //.decodingOptions(android.graphics.BitmapFactory.Options decodingOptions) //設定圖片的解碼配置                .delayBeforeLoading(0) //int delayInMillis為你設定的下載前的延遲時間                .resetViewBeforeLoading(true)//設定圖片在下載前是否重設,複位                .displayer(new FadeInBitmapDisplayer(100))//是否圖片載入好後漸入的動畫時間                .build();//構建完成    }    @Override    protected void onDestroy() {        mam.popOneActivity(HostessDetailUI.this);        Log.e("onDestroy() isRun!!!");        mHostessImgs.setAdapter(null);        /**釋放圖片,控制項圖片引用資源*/        BitmapDrawable bitmapDrawable = (BitmapDrawable) mHostessMiddle.getBackground();        mHostessMiddle.setBackgroundResource(0);        bitmapDrawable.setCallback(null);        drawable.setCallback(null);        Bitmap bitmap = bitmapDrawable.getBitmap();        if(bitmap != null && !bitmap.isRecycled()){            bitmap.recycle();//回收圖片所佔的記憶體            bitmap = null;        }        btp.recycle(); //回收圖片所佔的記憶體        System.gc();        super.onDestroy();    }

結果還是報oom問題,而且日誌也沒有看見GC操作,記憶體從16MB 跑到96MB 直接閃退,

 

 

3.換一種強大的圖片框架:Universal-Image_loader(UIL)

看見網上說UIL是目前最流行,使用者最多,個人配置最全的圖片框架,於是乎自己換掉picaso,來到UIL的懷抱,可是還是報OOM問題,每次看日誌都是跑到96MB閃退。

自己懷疑是自己對UIL理解不深,配置不全,還是沒有釋放記憶體。(有時間詳細看下UIL源碼實現)

 

4.換上最新的圖片處理架構:Facebook 推薦的fresco 架構

 

dependencies {            compile 'com.facebook.fresco:fresco:0.5.0+'        }

因為這方面的講解很少,自己看了一會兒,覺得好複雜,於是去看了一下官網文檔在AS的使用介紹,簡單的幾個操作,加入到了自己的項目,沒有像其他人說的要配置NDK,編譯什麼的。然後跑起來運行,果然!!記憶體堆沒有在像以前那樣到達96MB OOM問題了,真的是最新的東西會越好

 

 

5.去掉背景大圖,顯示完整

程式不崩潰了,心裡有很多的安慰,畢竟問題已經出現了1個星期了,然而還是有一些個別的圖片很久都載入不出來,fresco架構這麼好,為什麼還是有圖片載入不出來你。然後看日誌 提示:載入圖片太大,無法下載出來,於是看了下後台拉取的圖片大小。納尼。, 一張圖片7MB!! 再完美的架構針對這種圖片也是沒辦法的吧,所以讓幕後處理的圖片規格。

 

最終解決辦法:換上fresco架構+後台圖片縮小處理。現在程式不會出現OOM問題了。好開心!(不過記憶體釋放問題,自己還是沒有做好,有待提高!)

聯繫我們

該頁面正文內容均來源於網絡整理,並不代表阿里雲官方的觀點,該頁面所提到的產品和服務也與阿里云無關,如果該頁面內容對您造成了困擾,歡迎寫郵件給我們,收到郵件我們將在5個工作日內處理。

如果您發現本社區中有涉嫌抄襲的內容,歡迎發送郵件至: info-contact@alibabacloud.com 進行舉報並提供相關證據,工作人員會在 5 個工作天內聯絡您,一經查實,本站將立刻刪除涉嫌侵權內容。

A Free Trial That Lets You Build Big!

Start building with 50+ products and up to 12 months usage for Elastic Compute Service

  • Sales Support

    1 on 1 presale consultation

  • After-Sales Support

    24/7 Technical Support 6 Free Tickets per Quarter Faster Response

  • Alibaba Cloud offers highly flexible support services tailored to meet your exact needs.