android中的影像處理

標籤：android

現在的移動手機記憶體越來越大，但是我們在開發時任然需要對我們的應用的記憶體經行把控，對於記憶體中的映像，如果

佔用的記憶體太大，不及時釋放或者對圖片經行壓縮，仍然會出現OOM異常

對於圖片的載入，顯示，處理，現在有許多第三方的工具類，如比較有名的Xutils，或者開源的架構如Universial Image Loader等等，這裡不一一例舉。

   我們先看像的相關東西

   顏色模型

   對於常見的顏色模型，也就RGB，CMYK，YUV，ARGB。大多數API都採用RGB模型，android的API一般採用RGB和ARGB。

   對於顏色的編碼，說白了就是一個像素所佔記憶體的大小，有浮點數編碼（0.5，0.3，0.6），在java中一個float佔4

個位元組，所以一個像素要佔12個位元組。24位的整數編碼（255,255,255），這種方式每個顏色位佔用1個位元組，所以一

個像素需要3位元組，在java中可以用int類型儲存，這樣多出來的高8位我們可以儲存透明度，所以就有了ARGB編碼。

我們可以在BitmapFactory中看到RGB888和ARGB8888的原因。還有16位整數編碼(31，45，31)從左至右依次用5bit，

6bit，5bit，也就是RGB565，所以這種編碼一般用short或者char儲存就可以了，當然他也可以表示透明度，這時候需

要相應的調整，4bit的透明度，4bit的R，4bit的G，4bit的B，這就是ARGB4444。

打個比方如果用ARGB8888編碼，放入一張400*400的圖片，那麼就需要400*400*4位元組的空間了

我們可以看出使用合適的編碼，可以為我們的記憶體減少不少的空間

對於OOM這種異常我們有如下幾種方式去處理：

1 緩衝映像到記憶體，採用軟引用緩衝到記憶體，而不是在每次使用的時候都從新載入到記憶體；

2 調整映像大小，手機螢幕尺寸有限，分配給映像的顯示地區本身就更小，有時映像大小可以做適當調整；

3 採用低記憶體佔用量的編碼方式，比如Bitmap.Config.ARGB_4444比Bitmap.Config.ARGB_8888更省記憶體；

4 及時回收映像，如果引用了大量Bitmap對象，而應用又不需要同時顯示所有圖片，可以將暫時用不到的Bitmap對象

及時回收掉；

5 自訂堆記憶體配置大小，最佳化Dalvik虛擬機器的堆記憶體配置；

android中的影像處理