Android有效解決加載大圖檔時記憶體溢出的問題
盡量不要使用setImageBitmap或setImageResource或BitmapFactory.decodeResource來設定一張大圖，
因為這些函數在完成decode後，最終都是通過java層的createBitmap來完成的，需要消耗更多記憶體。
是以，改用先通過BitmapFactory.decodeStream方法，建立出一個bitmap，再将其設為ImageView的 source，
decodeStream最大的秘密在于其直接調用JNI>>nativeDecodeAsset()來完成decode，
無需再使用java層的createBitmap，進而節省了java層的空間。
如果在讀取時加上圖檔的Config參數，可以跟有效減少加載的記憶體，進而跟有效阻止抛out of Memory異常
另外，decodeStream直接拿的圖檔來讀取位元組碼了， 不會根據機器的各種分辨率來自動适應，
使用了decodeStream之後，需要在hdpi和mdpi，ldpi中配置相應的圖檔資源，
否則在不同分辨率機器上都是同樣大小（像素點數量），顯示出來的大小就不對了。
另外，以下方式也大有幫助：
1. InputStream is = this.getResources().openRawResource(R.drawable.pic1);
BitmapFactory.Options options=new BitmapFactory.Options();
options.inJustDecodeBounds = false;
options.inSampleSize = 10; //width，hight設為原來的十分一
Bitmap btp =BitmapFactory.decodeStream(is,null,options);
2. if(!bmp.isRecycle() ){
bmp.recycle() //回收圖檔所占的記憶體
system.gc() //提醒系統及時回收
}
以下奉上一個方法：
Java代碼
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記憶體溢出的解決辦法
轉自：http://www.cppblog.com/iuranus/archive/2010/11/15/124394.html?opt=admin
昨天在模拟器上給gallery放入圖檔的時候，出現java.lang.OutOfMemoryError: bitmap size exceeds VM budget 異常，圖像大小超過了RAM記憶體。
模拟器RAM比較小，隻有8M記憶體，當我放入的大量的圖檔（每個100多K左右），就出現上面的原因。
由于每張圖檔先前是壓縮的情況，放入到Bitmap的時候，大小會變大，導緻超出RAM記憶體，具體解決辦法如下：
//解決加載圖檔 記憶體溢出的問題
//Options 隻儲存圖檔尺寸大小，不儲存圖檔到記憶體
BitmapFactory.Options opts = new BitmapFactory.Options();
//縮放的比例，縮放是很難按準備的比例進行縮放的，其值表明縮放的倍數，SDK中建議其值是2的指數值,值越大會導緻圖檔不清晰
opts.inSampleSize = 4;
Bitmap bmp = null;
bmp = BitmapFactory.decodeResource(getResources(), mImageIds[position],opts);
...
//回收
bmp.recycle();
通過上面的方式解決了，但是這并不是最完美的解決方式。
通過一些了解，得知如下：
優化Dalvik虛拟機的堆記憶體配置設定
對于Android平台來說，其托管層使用的Dalvik Java VM從目前的表現來看還有很多地方可以優化處理，比如我們在開發一些大型遊戲或耗資源的應用中可能考慮手動幹涉GC處理，使用 dalvik.system.VMRuntime類提供的setTargetHeapUtilization方法可以增強程式堆記憶體的處理效率。當然具體原理我們可以參考開源工程，這裡我們僅說下使用方法: private final static float TARGET_HEAP_UTILIZATION = 0.75f; 在程式onCreate時就可以調用 VMRuntime.getRuntime().setTargetHeapUtilization(TARGET_HEAP_UTILIZATION); 即可。
Android堆記憶體也可自己定義大小
對于一些Android項目，影響性能瓶頸的主要是Android自己記憶體管理機制問題，目前手機廠商對RAM都比較吝啬，對于軟體的流暢性來說RAM對性能的影響十分敏感，除了 優化Dalvik虛拟機的堆記憶體配置設定外，我們還可以強制定義自己軟體的對記憶體大小，我們使用Dalvik提供的 dalvik.system.VMRuntime類來設定最小堆記憶體為例:
private final static int CWJ_HEAP_SIZE = 6* 1024* 1024 ;
VMRuntime.getRuntime().setMinimumHeapSize(CWJ_HEAP_SIZE); //設定最小heap記憶體為6MB大小。當然對于記憶體吃緊來說還可以通過手動幹涉GC去處理
bitmap 設定圖檔尺寸，避免 記憶體溢出 OutOfMemoryError的優化方法
★android 中用bitmap 時很容易記憶體溢出，報如下錯誤：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);
以上代碼可以優化記憶體溢出，但它隻是改變圖檔大小，并不能徹底解決記憶體溢出。
● 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 還有一些性能優化的方法：
● 首先記憶體方面，可以參考 Android堆記憶體也可自己定義大小 和 優化Dalvik虛拟機的堆記憶體配置設定
● 基礎類型上，因為Java沒有實際的指針，在敏感運算方面還是要借助NDK來完成。Android123提示遊戲開發者，這點比較有意思的是Google 推出NDK可能是幫助遊戲開發人員，比如OpenGL ES的支援有明顯的改觀，本地代碼操作圖形界面是很必要的。
● 圖形對象優化，這裡要說的是Android上的Bitmap對象銷毀，可以借助recycle()方法顯示讓GC回收一個Bitmap對象，通常對一個不用的Bitmap可以使用下面的方式，如
if(bitmapObject.isRecycled()==false) //如果沒有回收
bitmapObject.recycle();
● 目前系統對動畫支援比較弱智對于正常應用的補間過渡效果可以，但是對于遊戲而言一般的美工可能習慣了GIF方式的統一處理，目前Android系統僅能預覽GIF的第一幀，可以借助J2ME中通過線程和自己寫解析器的方式來讀取GIF89格式的資源。
● 對于大多數Android手機沒有過多的實體按鍵可能我們需要想象下了做好手勢識别 GestureDetector 和重力感應來實作操控。通常我們還要考慮誤操作問題的降噪處理。
Android堆記憶體也可自己定義大小
對于一些大型Android項目或遊戲來說在算法處理上沒有問題外，影響性能瓶頸的主要是Android自己記憶體管理機制問題，目前手機廠商對RAM都比較吝啬，對于軟體的流暢性來說RAM對性能的影響十分敏感，除了上次Android開發網提到的優化Dalvik虛拟機的堆記憶體配置設定外，我們還可以強制定義自己軟體的對記憶體大小，我們使用Dalvik提供的 dalvik.system.VMRuntime類來設定最小堆記憶體為例:
private final static int CWJ_HEAP_SIZE = 6* 1024* 1024 ;
VMRuntime.getRuntime().setMinimumHeapSize(CWJ_HEAP_SIZE); //設定最小heap記憶體為6MB大小。當然對于記憶體吃緊來說還可以通過手動幹涉GC去處理，我們将在下次提到具體應用。
優化Dalvik虛拟機的堆記憶體配置設定
對于Android平台來說，其托管層使用的Dalvik JavaVM從目前的表現來看還有很多地方可以優化處理，比如我們在開發一些大型遊戲或耗資源的應用中可能考慮手動幹涉GC處理，使用 dalvik.system.VMRuntime類提供的setTargetHeapUtilization方法可以增強程式堆記憶體的處理效率。當然具體原理我們可以參考開源工程，這裡我們僅說下使用方法: private final static floatTARGET_HEAP_UTILIZATION = 0.75f; 在程式onCreate時就可以調用 VMRuntime.getRuntime().setTargetHeapUtilization(TARGET_HEAP_UTILIZATION); 即可
http://www.cnblogs.com/santry/archive/2011/08/29/2158438.html
Android雖然會自動管理記憶體，JAVA也有garbage collection (GC )記憶體回收機制。
但是如果程式在一次操作中打開幾個M的檔案，那麼通常會出現下面的錯誤資訊。
02-04 21:46:08.703: ERROR/dalvikvm-heap(2429): 1920000-byte external allocation too large for this process.
或
02-04 21:52:28.463: ERROR/AndroidRuntime(2429): java.lang.OutOfMemoryError: bitmap size exceeds VM budget
移動終端因為記憶體有限，往往圖檔處理經常出現上述的錯誤。
解決方法：
1.明确調用System.gc();
這種記憶體回收會有一定的作用，但是請不要太期待。
2.圖檔處理完成後回收記憶體。
請在調用BitMap進行圖檔處理後進行記憶體回收。
bitmap.recycle();
這樣會把剛剛用過的圖檔占用的記憶體釋放。
3.圖檔處理時指定大小。
下面這個方法處理幾個M的圖檔時是必須的
1. BitMap getBitpMap(){
2. ParcelFileDescriptor pfd;
3. try{
4. pfd = mCon.getContentResolver().openFileDescriptor(uri, "r");
5. }catch (IOException ex){
6. return null;
7. }
8. java.io.FileDescriptor fd = pfd.getFileDescriptor();
9. BitmapFactory.Options options = new BitmapFactory.Options();
10. //先指定原始大小
11. options.inSampleSize = 1;
12. //隻進行大小判斷
13. options.inJustDecodeBounds = true;
14. //調用此方法得到options得到圖檔的大小
15. BitmapFactory.decodeFileDescriptor(fd, null, options);
16. //我們的目标是在800pixel的畫面上顯示。
17. //是以需要調用computeSampleSize得到圖檔縮放的比例
18. options.inSampleSize = computeSampleSize(options, 800);
19. //OK,我們得到了縮放的比例，現在開始正式讀入BitMap資料
20. options.inJustDecodeBounds = false;
21. options.inDither = false;
22. options.inPreferredConfig = Bitmap.Config.ARGB_8888;
23.
24. //根據options參數，減少所需要的記憶體
25. Bitmap sourceBitmap = BitmapFactory.decodeFileDescriptor(fd, null, options);
26. return sourceBitmap;
27. }
28. //這個函數會對圖檔的大小進行判斷，并得到合适的縮放比例，比如2即1/2,3即1/3
29. static int computeSampleSize(BitmapFactory.Options options, int target) {
30. int w = options.outWidth;
31. int h = options.outHeight;
32. int candidateW = w / target;
33. int candidateH = h / target;
34. int candidate = Math.max(candidateW, candidateH);
35. if (candidate == 0)
36. return 1;
37. if (candidate > 1) {
38. if ((w > target) && (w / candidate) < target)
39. candidate -= 1;
40. }
41. if (candidate > 1) {
42. if ((h > target) && (h / candidate) < target)
43. candidate -= 1;
44. }
45. if (VERBOSE)
46. Log.v(TAG, "for w/h " + w + "/" + h + " returning " + candidate + "(" + (w/candidate) + " / " + (h/candidate));
47. return candidate;
48. }
http://wenwen.soso.com/z/q259026573.htm?sp=2000
///
///
android系統的手機在系統底層指定了堆記憶體的上限值，大部分手機的預設值是16MB，不過也有些高配置的機型是24MB的，是以我們的程式在申請記憶體空間時，為了確定能夠成功申請到記憶體空間，應該保證目前已配置設定的記憶體加上目前需要配置設定的記憶體值的總大小不能超過目前堆的最大記憶體值，而且記憶體管理上将外部記憶體完全當成了目前堆的一部分，也就是說Bitmap對象通過棧上的引用來指向堆上的Bitmap對象，而堆上的Bitmap對象又對應了一個使用了外部存儲的native圖像，也就是實際上使用的位元組數組byte[]來存儲的位圖資訊，是以解碼之後的Bitmap的總大小就不能超過8M了。
解決這類問題的最根本的，最有效的辦法就是，使用完bitmap之後，調用bitmap對象的recycle()方法釋放所占用的記憶體，以便于下一次使用。
下面是網上找到的一些常用的優化辦法，但是基本上都不能從本質上解決問題。
1.設定系統的最小堆大小：
int newSize = 4 * 1024 * 1024 ; //設定最小堆記憶體大小為4MB
VMRuntime.getRuntime().setMinimumHeapSize(newSize);
VMRuntime.getRuntime().setTargetHeapUtilization(0.75); // 設定堆記憶體的使用率為75%
補充說明：堆（HEAP）是VM中占用記憶體最多的部分，通常是動态配置設定的。堆的大小不是一成不變的，當堆記憶體實際的使用率偏離設定的值的時候，虛拟機會在GC的時候調整堆記憶體大小，讓實際占用率向個百分比靠攏。比如初始的HEAP是4M大小，當4M的空間被占用超過75%的時候，重新配置設定堆為8M大；當8M被占用超過75%，配置設定堆為16M大。倒過來，當16M的堆利用不足30%的時候，縮減它的大小為8M大。重新設定堆的大小，尤其是壓縮，一般會涉及到記憶體的拷貝，是以變更堆的大小對效率有不良影響。
2.對圖檔的大小進行控制
BitmapFactory? .Options options = new BitmapFactory? .Options();
options.inSampleSize = 2; //圖檔寬高都為原來的二分之一，即圖檔為原來的四分之一
Bitmap bitmap = BitmapFactory? .decodeFile("/mnt/sdcard/a.jpg",options);
補充說明：這種方法隻是對圖檔做了一個縮放處理，降低了圖檔的分辨率，在需要保證圖檔品質的應用中不可取。
3.
BitmapFactory? .Options options = new BitmapFactory? .Options();
options.inTempStorage = new byte[1024*1024*5]; //5MB的臨時存儲空間
Bitmap bm = BitmapFactory? .decodeFile("/mnt/sdcard/a.jpg",options);
補充說明：從建立Bitmap的C++底層代碼BitmapFactory.cpp中的處理邏輯來看，如果option不為null的話，那麼會優先處理option中設定的各個參數，假設目前你設定option的inTempStorage為1024*1024*4(4M)大小的話，而且每次解碼圖像時均使用該option對象作為參數，那麼你的程式極有可能會提前失敗，經過測試，如果使用一張大小為1.03M的圖檔來進行解碼，如果不使用option參數來解碼，可以正常解碼四次，也就是配置設定了四次記憶體，而如果使用option的話，就會出現記憶體溢出錯誤，隻能正常解碼兩次。Options類有一個預處理參數，當你傳入options時，并且指定臨時使用記憶體大小的話，Android将預設先申請你所指定的記憶體大小，如果申請失敗，就會先抛出記憶體溢出錯誤。而如果不指定記憶體大小，系統将會自動計算，如果目前還剩3M空間大小，而解碼隻需要2M大小，那麼在預設情況下将能解碼成功，而在設定inTempStorage大小為4M的情況下就将出現記憶體溢出錯誤。是以，通過設定Options的inTempStorage大小也不能從根本上解決大圖像解碼的記憶體溢出問題。
總之再做android開發時，出現記憶體溢出是屬于系統底層限制，隻要解碼需要的記憶體超過系統可配置設定的最大記憶體值，那麼記憶體溢出錯誤必然會出現.
![Java String.format方法的簡單使用[圖]](data:image/gif;base64,R0lGODlhAQABAIAAAP///wAAACwAAAAAAQABAAACAkQBADs=)