ndroidbitmapoutofmemory總結(jié)、心得-創(chuàng)新互聯(lián)

setImageBitmap或setImageResource或BitmapFactory.decodeResource來設(shè)置一張大圖，這些函數(shù)在完成decode后，最終都是通過java層的createBitmap來完成的，需要消耗更多的內(nèi)存。
創(chuàng)新互聯(lián)是專業(yè)的遷安網(wǎng)站建設(shè)公司，遷安接單;提供成都網(wǎng)站設(shè)計、網(wǎng)站建設(shè)、外貿(mào)網(wǎng)站建設(shè),網(wǎng)頁設(shè)計,網(wǎng)站設(shè)計,建網(wǎng)站,PHP網(wǎng)站建設(shè)等專業(yè)做網(wǎng)站服務(wù);采用PHP框架,可快速的進(jìn)行遷安網(wǎng)站開發(fā)網(wǎng)頁制作和功能擴(kuò)展;專業(yè)做搜索引擎喜愛的網(wǎng)站,專業(yè)的做網(wǎng)站團(tuán)隊,希望更多企業(yè)前來合作!
改用先通過BitmapFactory.decodeStream方法，創(chuàng)建出一個bitmap，再將其設(shè)為ImageView的source
decodeStream大的好處在于其直接調(diào)用JNI 的nativeDecodeAsset()來完成decode，無需再使用java層的createBitmap，從而節(jié)省了java層的空間
如果在讀取時加上圖片的Config參數(shù)，可以更有效減少加載的內(nèi)存，從而更有效避免out of memory的異常
另外，decodeStream直接拿圖片來讀取字節(jié)碼，不會根據(jù)機(jī)器的各種分辨率來自動適應(yīng)，使用了decodeStream之后，需要配置相應(yīng)大小的圖片資源
默認(rèn)情況下android進(jìn)程的內(nèi)存占用量為16M，因為bitmap他除了java中持有數(shù)據(jù)外，底層C++的skia圖形庫還會持有一個SKBitmap對象，因此一般圖片占用內(nèi)存推薦大小應(yīng)該不超過8M

1、BitmapFactory.Options

inPreferredConfig 指定decode到內(nèi)存中，手機(jī)中所采用的編碼，可選值定義在Bitmap.Config中。缺省值是ARGB_8888。可以使ALPHA_8、ARGB_444、ARGB_8888、RGB_565 bitmap占用內(nèi)存的算法如下：圖片的width*height*Config 如果config設(shè)置為ARGB_8888，那么上面的Config為4，也就是4個字節(jié)的意思。一張480*320的圖片占用的內(nèi)存就是480*320*4byte。
inJustDecodeBounds 如果設(shè)置為true，并不會把圖像的數(shù)據(jù)完全解碼，亦即decodeXyz()返回值為null，但是Options的outAbc中解出了圖像的基本信息。
inSampleSize 設(shè)置decode時的縮放比例。
inPurgeable設(shè)為true的話表示使用BitmapFactory創(chuàng)建的Bitmap用于存儲Pixel的內(nèi)存空間在系統(tǒng)內(nèi)存不足時可以被回收，在應(yīng)用需要再次訪問bitmap的Pixel時，系統(tǒng)會再次條用BitmapFactory decoder重新生成Bitmap的Pixel數(shù)組，為了能夠重新解碼圖像，bitmap要能夠訪問存儲bitmap的原始數(shù)據(jù)。在inPugeable為false時表示創(chuàng)建bitmap的pixel內(nèi)存空間不能被回收，這樣bitmapfactory在不停decodeByteArray創(chuàng)建新的Bitmap對象，不同設(shè)備的內(nèi)存不同，因此能夠同時創(chuàng)建的Bitmap個數(shù)可能有所不同，200個bitmap足以使大部分的設(shè)備出現(xiàn)OutOfMemory錯誤。當(dāng)inPurgeable設(shè)為true時，系統(tǒng)中內(nèi)存不足時，可以回收部分bitmap占據(jù)的內(nèi)存空間，這時一般不會出現(xiàn)OutOfMemory錯誤
inInputShareable是否深拷貝

2、以最省內(nèi)存的方式讀取本地資源的圖片

BitmapFactory.Options opt = new BitmapFactory.Options();
opt.inPreferredConfig = Bitmap.Config.RGB_565;
opt.inPurgeable = true;
opt.inInputShareable = true;
//獲取資源圖片
InputStream is = context.getResources().openRawResource(resId);
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格式的，將圖片轉(zhuǎn)為jpg。圖片大小減少了不少。不過沒多大效果。

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

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

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

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

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

另外有需要云服務(wù)器可以了解下創(chuàng)新互聯(lián)scvps.cn，海內(nèi)外云服務(wù)器15元起步，三天無理由+7*72小時售后在線，公司持有idc許可證，提供“云服務(wù)器、裸金屬服務(wù)器、高防服務(wù)器、香港服務(wù)器、美國服務(wù)器、虛擬主機(jī)、免備案服務(wù)器”等云主機(jī)租用服務(wù)以及企業(yè)上云的綜合解決方案，具有“安全穩(wěn)定、簡單易用、服務(wù)可用性高、性價比高”等特點(diǎn)與優(yōu)勢，專為企業(yè)上云打造定制，能夠滿足用戶豐富、多元化的應(yīng)用場景需求。

當(dāng)前標(biāo)題：ndroidbitmapoutofmemory總結(jié)、心得-創(chuàng)新互聯(lián)
文章轉(zhuǎn)載：http://muchs.cn/article8/doogop.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供網(wǎng)站收錄、微信公眾號、網(wǎng)站改版、搜索引擎優(yōu)化、定制網(wǎng)站、商城網(wǎng)站

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請盡快告知，我們將會在第一時間刪除。文章觀點(diǎn)不代表本網(wǎng)站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時需注明來源：創(chuàng)新互聯(lián)

猜你還喜歡下面的內(nèi)容

ndroidbitmapoutofmemory總結(jié)、心得-創(chuàng)新互聯(lián)

ndroidbitmapoutofmemory總結(jié)、心得-創(chuàng)新互聯(lián)