盡量不要使用setImageBitmap或setImageResource或BitmapFactory.decodeResource來設(shè)置一張大圖，
因?yàn)檫@些函數(shù)在完成decode后，最終都是通過java層的createBitmap來完成的，需要消耗更多內(nèi)存。
因此，改用先通過BitmapFactory.decodeStream方法，創(chuàng)建出一個(gè)bitmap，再將其設(shè)為ImageView的 source，
decodeStream最大的秘密在于其直接調(diào)用JNI>>nativeDecodeAsset()來完成decode，
無需再使用java層的createBitmap，從而節(jié)省了java層的空間。
如果在讀取時(shí)加上圖片的Config參數(shù)，可以跟有效減少加載的內(nèi)存，從而跟有效阻止拋out of Memory異常
另外，decodeStream直接拿的圖片來讀取字節(jié)碼了， 不會(huì)根據(jù)機(jī)器的各種分辨率來自動(dòng)適應(yīng)，
使用了decodeStream之后，需要在hdpi和mdpi，ldpi中配置相應(yīng)的圖片資源，
否則在不同分辨率機(jī)器上都是同樣大小（像素點(diǎn)數(shù)量），顯示出來的大小就不對(duì)了。
另外，以下方式也大有幫助：
1. InputStream is = this.getResources().openRawResource(R.drawable.pic1);
BitmapFactory.Options options=new BitmapFactory.Options();
options.inJustDecodeBounds = false;
options.inSampleSize = 10; //width，hight設(shè)為原來的十分一
Bitmap btp =BitmapFactory.decodeStream(is,null,options);
2. if(!bmp.isRecycle() ){
bmp.recycle() //回收?qǐng)D片所占的內(nèi)存
system.gc() //提醒系統(tǒng)及時(shí)回收
}
以下奉上一個(gè)方法：
//以最省內(nèi)存的方式讀取本地資源的圖片
public static Bitmap readBitMap(Context context, int resId){
BitmapFactory.Options opt = new BitmapFactory.Options();
opt.inPreferredConfig = Bitmap.Config.RGB_565;
opt.inPurgeable = true;
opt.inInputShareable = true;
//獲取資源圖片
InputStream is = context.getResources().openRawResource(resId);
return BitmapFactory.decodeStream(is,null,opt);
}
================================================================================
Android內(nèi)存溢出的解決辦法
轉(zhuǎn)自：http://www.cppblog.com/iuranus/a ... 4394.html?opt=admin
昨天在模擬器上給gallery放入圖片的時(shí)候，出現(xiàn)java.lang.OutOfMemoryError: bitmap size exceeds VM budget 異常，圖像大小超過了RAM內(nèi)存。
模擬器RAM比較小，只有8M內(nèi)存，當(dāng)我放入的大量的圖片（每個(gè)100多K左右），就出現(xiàn)上面的原因。
由于每張圖片先前是壓縮的情況，放入到Bitmap的時(shí)候，大小會(huì)變大，導(dǎo)致超出RAM內(nèi)存，具體解決辦法如下：
//解決加載圖片 內(nèi)存溢出的問題
//Options 只保存圖片尺寸大小，不保存圖片到內(nèi)存
BitmapFactory.Options opts = new BitmapFactory.Options();
//縮放的比例，縮放是很難按準(zhǔn)備的比例進(jìn)行縮放的，其值表明縮放的倍數(shù)，SDK中建議其值是2的指數(shù)值,值越大會(huì)導(dǎo)致圖片不清晰
opts.inSampleSize = 4;
Bitmap bmp = null;
bmp = BitmapFactory.decodeResource(getResources(), mImageIdsposition ,opts);
...
//回收
bmp.recycle();
通過上面的方式解決了，但是這并不是最完美的解決方式。
通過一些了解，得知如下：
優(yōu)化Dalvik虛擬機(jī)的堆內(nèi)存分配
對(duì)于Android平臺(tái)來說，其托管層使用的Dalvik Java VM從目前的表現(xiàn)來看還有很多地方可以優(yōu)化處理，比如我們?cè)陂_發(fā)一些大型游戲或耗資源的應(yīng)用中可能考慮手動(dòng)干涉GC處理，使用 dalvik.system.VMRuntime類提供的setTargetHeapUtilization方法可以增強(qiáng)程序堆內(nèi)存的處理效率。當(dāng)然具體 原理我們可以參考開源工程，這里我們僅說下使用方法: private final static float TARGET_HEAP_UTILIZATION = 0.75f; 在程序onCreate時(shí)就可以調(diào)用 VMRuntime.getRuntime().setTargetHeapUtilization(TARGET_HEAP_UTILIZATION); 即可。
Android堆內(nèi)存也可自己定義大小
對(duì)于一些Android項(xiàng)目，影響性能瓶頸的主要是Android自己內(nèi)存管理機(jī)制問題，目前手機(jī)廠商對(duì)RAM都比較吝嗇，對(duì)于軟件的流暢性來說 RAM對(duì) 性能的影響十分敏感，除了 優(yōu)化Dalvik虛擬機(jī)的堆內(nèi)存分配外，我們還可以強(qiáng)制定義自己軟件的對(duì)內(nèi)存大小，我們使用Dalvik提供的 dalvik.system.VMRuntime類來設(shè)置最小堆內(nèi)存為例:
private final static int CWJ_HEAP_SIZE = 6* 1024* 1024 ;
VMRuntime.getRuntime().setMinimumHeapSize(CWJ_HEAP_SIZE); //設(shè)置最小heap內(nèi)存為6MB大小。當(dāng)然對(duì)于內(nèi)存吃緊來說還可以通過手動(dòng)干涉GC去處理
bitmap 設(shè)置圖片尺寸，避免 內(nèi)存溢出 OutOfMemoryError的優(yōu)化方法
★android 中用bitmap 時(shí)很容易內(nèi)存溢出，報(bào)如下錯(cuò)誤：Java.lang.OutOfMemoryError : bitmap size exceeds VM budget
● 主要是加上這段：
BitmapFactory.Options options = new BitmapFactory.Options();
options.inSampleSize = 2;
● eg1：(通過Uri取圖片)
private ImageView preview;
BitmapFactory.Options options = new BitmapFactory.Options();
options.inSampleSize = 2;//圖片寬高都為原來的二分之一，即圖片為原來的四分之一
Bitmap bitmap = BitmapFactory.decodeStream(cr
.openInputStream(uri), null, options);
preview.setImageBitmap(bitmap);
以上代碼可以優(yōu)化內(nèi)存溢出，但它只是改變圖片大小，并不能徹底解決內(nèi)存溢出。
● eg2:（通過路徑去圖片）
private ImageView preview;
private String fileName= "/sdcard/DCIM/Camera/2010-05-14 16.01.44.jpg";
BitmapFactory.Options options = new BitmapFactory.Options();
options.inSampleSize = 2;//圖片寬高都為原來的二分之一，即圖片為原來的四分之一
Bitmap b = BitmapFactory.decodeFile(fileName, options);
preview.setImageBitmap(b);
filePath.setText(fileName);
★Android 還有一些性能優(yōu)化的方法：
● 首先內(nèi)存方面，可以參考 Android堆內(nèi)存也可自己定義大小 和 優(yōu)化Dalvik虛擬機(jī)的堆內(nèi)存分配
● 基礎(chǔ)類型上，因?yàn)镴ava沒有實(shí)際的指針，在敏感運(yùn)算方面還是要借助NDK來完成。Android123提示游戲開發(fā)者，這點(diǎn)比較有意思的是 Google 推出NDK可能是幫助游戲開發(fā)人員，比如OpenGL ES的支持有明顯的改觀，本地代碼操作圖形界面是很必要的。
● 圖形對(duì)象優(yōu)化，這里要說的是Android上的Bitmap對(duì)象銷毀，可以借助recycle()方法顯示讓GC回收一個(gè)Bitmap對(duì)象，通常對(duì)一個(gè)不用的Bitmap可以使用下面的方式，如
if(bitmapObject.isRecycled()==false) //如果沒有回收
bitmapObject.recycle();
● 目前系統(tǒng)對(duì)動(dòng)畫支持比較弱智對(duì)于常規(guī)應(yīng)用的補(bǔ)間過渡效果可以，但是對(duì)于游戲而言一般的美工可能習(xí)慣了GIF方式的統(tǒng)一處理，目前Android系統(tǒng)僅能預(yù)覽GIF的第一幀，可以借助J2ME中通過線程和自己寫解析器的方式來讀取GIF89格式的資源。
● 對(duì)于大多數(shù)Android手機(jī)沒有過多的物理按鍵可能我們需要想象下了做好手勢(shì)識(shí)別 GestureDetector 和重力感應(yīng)來實(shí)現(xiàn)操控。通常我們還要考慮誤操作問題的降噪處理。
Android堆內(nèi)存也可自己定義大小
對(duì)于一些大型Android項(xiàng)目或游戲來說在算法處理上沒有問題外，影響性能瓶頸的主要是Android自己內(nèi)存管理機(jī)制問題，目前手機(jī)廠商對(duì) RAM都 比較吝嗇，對(duì)于軟件的流暢性來說RAM對(duì)性能的影響十分敏感，除了上次android開發(fā)網(wǎng)提到的優(yōu)化Dalvik虛擬機(jī)的堆內(nèi)存分配外，我們還可以強(qiáng)制 定義自己軟件的對(duì)內(nèi)存大小，我們使用Dalvik提供的 dalvik.system.VMRuntime類來設(shè)置最小堆內(nèi)存為例:
private final static int CWJ_HEAP_SIZE = 6* 1024* 1024 ;
VMRuntime.getRuntime().setMinimumHeapSize(CWJ_HEAP_SIZE); //設(shè)置最小heap內(nèi)存為6MB大小。當(dāng)然對(duì)于內(nèi)存吃緊來說還可以通過手動(dòng)干涉GC去處理，我們將在下次提到具體應(yīng)用。
優(yōu)化Dalvik虛擬機(jī)的堆內(nèi)存分配
對(duì)于Android平臺(tái)來說，其托管層使用的Dalvik JavaVM從目前的表現(xiàn)來看還有很多地方可以優(yōu)化處理，比如我們?cè)陂_發(fā)一些大型游戲或耗資源的應(yīng)用中可能考慮手動(dòng)干涉GC處理，使用 dalvik.system.VMRuntime類提供的setTargetHeapUtilization方法可以增強(qiáng)程序堆內(nèi)存的處理效率。當(dāng)然具體 原理我們可以參考開源工程，這里我們僅說下使用方法: private final static floatTARGET_HEAP_UTILIZATION = 0.75f; 在程序onCreate時(shí)就可以調(diào)用 VMRuntime.getRuntime().setTargetHeapUtilization(TARGET_HEAP_UTILIZATION); 即可。
模擬器RAM比較小，只有8M內(nèi)存，當(dāng)我放入的大量的圖片（每個(gè)100多K左右），就出現(xiàn)上面的原因。由于每張圖片先前是壓縮的情況。放入到Bitmap的時(shí)候，大小會(huì)變大，導(dǎo)致超出RAM內(nèi)存，具體解決辦法如下：
Java代碼：
1. //解決加載圖片 內(nèi)存溢出的問題
2. //Options 只保存圖片尺寸大小，不保存圖片到內(nèi)存
3.
4.
5. BitmapFactory.Options opts = new BitmapFactory.Options();
6.
7.
8. /縮放的比例，縮放是很難按準(zhǔn)備的比例進(jìn)行縮放的，其值表明縮放的倍數(shù)，SDK中建議其值是2的指數(shù)值,值越大會(huì)導(dǎo)致圖片不清晰 /
9.
10.
11. opts.inSampleSize = 4;
12. Bitmap bmp = null;
13. bmp = BitmapFactory.decodeResource(getResources(), mImageIdsposition ,opts);
14. ...
15. //回收
16. bmp.recycle();
復(fù)制代碼
還可以用到優(yōu)化Dalvik虛擬機(jī)的堆內(nèi)存分配
對(duì)于Android平臺(tái)來說，其托管層使用的Dalvik Java VM從目前的表現(xiàn)來看還有很多地方可以優(yōu)化處理，比如我們?cè)陂_發(fā)一些大型游戲或耗資源的應(yīng)用中可能考慮手動(dòng)干涉GC處理，使用 dalvik.system.VMRuntime類提供的setTargetHeapUtilization方法可以增強(qiáng)程序堆內(nèi)存的處理效率。當(dāng)然具體原理我們可以參考開源工程，這里我們僅說下使用方法: private final static float TARGET_HEAP_UTILIZATION = 0.75f; 在程序onCreate時(shí)就可以調(diào)用 VMRuntime.getRuntime().setTargetHeapUtilization(TARGET_HEAP_UTILIZATION);
Android堆內(nèi)存也可自己定義大小
對(duì)于一些Android項(xiàng)目，影響性能瓶頸的主要是Android自己內(nèi)存管理機(jī)制問題，除了 優(yōu)化Dalvik虛擬機(jī)的堆內(nèi)存分配外，我們還可以強(qiáng)制定義自己軟件的對(duì)內(nèi)存大小，我們使用Dalvik提供的 dalvik.system.VMRuntime類來設(shè)置最小堆內(nèi)存為例:
Java代碼：
1. private final static int CWJ_HEAP_SIZE = 6* 1024* 1024 ;
2.
3. VMRuntime.getRuntime().setMinimumHeapSize(CWJ_HEAP_SIZE);
4. //設(shè)置最小heap內(nèi)存為6MB大小。當(dāng)然對(duì)于內(nèi)存吃緊來說還可以通過手動(dòng)干涉GC去處理

轉(zhuǎn)載于:https://www.cnblogs.com/elliotta/p/3633756.html

總結(jié)

以上是生活随笔為你收集整理的android 图片与内存加载的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。