ndroid bitmap out of memory總結、心得

• 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之后，需要配置相應大小的圖片資源

• 默認情況下android進程的內存占用量為16M，因為bitmap他除了java中持有數據外，底層C++的skia圖形庫還會持有一個SKBitmap對象，因此一般圖片占用內存推薦大小應該不超過8M

1、BitmapFactory.Options

• inPreferredConfig 指定decode到內存中，手機中所采用的編碼，可選值定義在Bitmap.Config中。缺省值是ARGB_8888。可以使ALPHA_8、ARGB_444、ARGB_8888、RGB_565                                               bitmap占用內存的算法如下：圖片的width*height*Config                                                                                                                                                                                                                                             如果config設置為ARGB_8888，那么上面的Config為4，也就是4個字節的意思。一張480*320的圖片占用的內存就是480*320*4byte。 

• inJustDecodeBounds 如果設置為true，并不會把圖像的數據完全解碼，亦即decodeXyz()返回值為null，但是Options的outAbc中解出了圖像的基本信息。

• inSampleSize 設置decode時的縮放比例。

• inPurgeable設為true的話表示使用BitmapFactory創建的Bitmap用于存儲Pixel的內存空間在系統內存不足時可以被回收，在應用需要再次訪問bitmap的Pixel時，系統會再次條用BitmapFactory decoder重新生成Bitmap的Pixel數組，為了能夠重新解碼圖像，bitmap要能夠訪問存儲bitmap的原始數據。在inPugeable為false時表示創建bitmap的pixel內存空間不能被回收，這樣bitmapfactory在不停decodeByteArray創建新的Bitmap對象，不同設備的內存不同，因此能夠同時創建的Bitmap個數可能有所不同，200個bitmap足以使大部分的設備出現OutOfMemory錯誤。當inPurgeable設為true時，系統中內存不足時，可以回收部分bitmap占據的內存空間，這時一般不會出現OutOfMemory錯誤

• inInputShareable是否深拷貝   

2、以最省內存的方式讀取本地資源的圖片 

1. BitmapFactory.Options opt = new BitmapFactory.Options();   

2. opt.inPreferredConfig = Bitmap.Config.RGB_565;    

3. opt.inPurgeable = true;   

4. opt.inInputShareable = true;   

5. //獲取資源圖片   

6. InputStream is = context.getResources().openRawResource(resId);   

7. BitmapFactory.decodeStream(is,null,opt);  

3、最近解決bitmap加載時out of memory的心得

游戲在加載背景圖片

       要么掛在BitmapFactory. decodeStream( assets .open(path));

    要么掛在surface = Bitmap.createBitmap (surface , 0, 0,
                surface .getWidth(), surface .getHeight(), matrix, true);

第一次嘗試：看到圖片是png格式的，將圖片轉為jpg。圖片大小減少了不少。不過沒多大效果。  

        原因：雖然改為jpg，加載時存儲的方式會默認為ARGB_565，本來是png為ARGB_8888，占用內存會減少一半。不過開銷還是很大，用createBitmap放大時，改方法是java層的實現，效率太差。

第二次嘗試：想到cocos2d-x的瓦片地圖，所以將背景圖片分割為9份（自己用ps切），有些效果，不會每次切換場景都會掛，但是很多的征戰地圖，沒全部切，所以當進入沒切的場景時，還是會掛。

                   原因：沒有找到問題的源頭，變小圖了，加載時開銷的內存確實減少不少。不過太多場景都去切不太實際，這樣程序改變很大。可能會出現bug的風險。

第三次嘗試：配置BitmapFactory.Config的屬性，使用（2）中的方式讀取圖片，省去createBitmap去放大圖片，使用兩套資源，在這些屏幕上用大圖。成功解決問題。

             原因：都用了BitmapFactory.decodeStream方法讀取圖片，改方法直接使用native方法，用c++實現。效率果然是高。雖然當時還不知道這個原因。今天總結的時候通過源代碼才理解。