今天做項目，發現需要顯示一張超大圖片，處理過后，還有561Kb
加載的時候，就crash --- OOM
shortMsg:java.lang.OutOfMemoryError
longMsg:java.lang.OutOfMemoryError: bitmap size exceeds VM budget
stackTrace:java.lang.OutOfMemoryError: bitmap size exceeds VM budget
at android.graphics.Bitmap.nativeCreate(Native Method)
at android.graphics.Bitmap.createBitmap(Bitmap.java:477)
at android.graphics.Bitmap.createBitmap(Bitmap.java:444)
at android.graphics.Bitmap.createScaledBitmap(Bitmap.java:349)
at android.graphics.BitmapFactory.finishDecode(BitmapFactory.java:512)
at android.graphics.BitmapFactory.decodeStream(BitmapFactory.java:487)
at android.graphics.BitmapFactory.decodeResourceStream(BitmapFactory.java:336)
代碼如下：
detailView=(ImageView)findViewById(R.id.detailView);
detailView.setBackgroundResource(R.drawable.more_info);//this line will lead to OOM
換成這種：
detailView.setImageResource(R.drawable.more_info); //也同樣會OOM
后來找到了solution:
/**
* 以最省內存的方式讀取本地資源的圖片
* @param context
*@param resId
* @return
*/
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);
}
取得bitmap之后，再 detailView.setImageBitmap(pdfImage);?就ok了！
那是為什么，會導致oom呢：
原來當使用像 imageView.setBackgroundResource，imageView.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中配置相應的圖片資源，否則在不同分辨率機器上都是同樣大小（像素點數量），顯示出來的大小就不對了。
http://blog.csdn.net/woshicaixianfeng/article/details/6825295
