儘量不要使用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代碼
1. /**
2. * 以最省內存的方式讀取本地資源的圖片
3. * @param context
4. * @param resId
5. * @return
6. */
7. public static Bitmap readBitMap(Context context, int resId){
8. BitmapFactory.Options opt = new BitmapFactory.Options();
9. opt.inPreferredConfig = Bitmap.Config.RGB_565;
10. opt.inPurgeable = true;
11. opt.inInputShareable = true;
12. //獲取資源圖片
13. InputStream is = context.getResources().openRawResource(resId);
14. return BitmapFactory.decodeStream(is,null,opt);
15. }
優化Dalvik虛擬機的堆內存分配
對 於Android平臺來說，其託管層使用的Dalvik JavaVM從目前的表現來看還有很多地方可以優化處理，比如我們在開發一些大型遊戲或耗資源的應用中可能考慮手動干涉GC處理，使用 dalvik.system.VMRuntime類提供的setTargetHeapUtilization方法可以增強程序堆內存的處理效率。當然具體 原理我們可以參考開源工程，這裏我們僅說下使用方法: private final static floatTARGET_HEAP_UTILIZATION = 0.75f; 在程序onCreate時就可以調用
VMRuntime.getRuntime().setTargetHeapUtilization(TARGET_HEAP_UTILIZATION); 即可。
介紹一下圖片佔用進程的內存算法吧。
android中處理圖片的基礎類是Bitmap，顧名思義，就是位圖。佔用內存的算法如下：
圖片的width*height*Config。
如果Config設置爲ARGB_8888，那麼上面的Config就是4。一張480*320的圖片佔用的內存就是480*320*4 byte。
前面有人說了一下8M的概念，其實是在默認情況下android進程的內存佔用量爲16M，因爲Bitmap他除了java中持有數據外，底層C++的 skia圖形庫還會持有一個SKBitmap對象，因此一般圖片佔用內存推薦大小應該不超過8M。這個可以調整，編譯源代碼時可以設置參數