Android載入圖片OOM錯(cuò)誤解決方案

頭幾天做項(xiàng)目的時(shí)候，甲方要求是PAD （SAMSUNG P600 10.1寸 2560*1600）的PAD上顯示高分辨率的大圖片。

SQLITE采取BOLD方式存儲(chǔ)圖片，這個(gè)存取進(jìn)程就不說(shuō)了哈，網(wǎng)上1大堆。

但是在載入/讀取/顯示圖片的時(shí)候會(huì)報(bào)OOM毛病，上網(wǎng)查了很多解決方案還繞了很多彎路，最后還是找到了緣由所在，下面從幾個(gè)方面來(lái)解釋1下OOM問(wèn)題的解決方案。

（謝謝周同學(xué)的“尺寸”提示，不然我可能1輩子都要蒙在鼓里）

1.Android APP內(nèi)存

做1個(gè)APP開(kāi)發(fā)的時(shí)候，還是不要想著去擴(kuò)大Android系統(tǒng)賦予的內(nèi)存上限了，部份老機(jī)型老系統(tǒng)16M，大部份都是24M了。

1些大型游戲用dalvik.system.VMRuntime來(lái)干涉GC進(jìn)程（這個(gè)類(lèi)我還沒(méi)有學(xué)過(guò)。。。剛聽(tīng)說(shuō)不久）。

聽(tīng)說(shuō)用NDK開(kāi)發(fā)時(shí)候，C可以動(dòng)態(tài)申請(qǐng)過(guò)剩的內(nèi)存空間，但是我沒(méi)用過(guò)NDK，今后也不打算用了（個(gè)人緣由）。

2.圖片文件大小

甲方給了1大堆文件大小不1的圖片，在載入http://www.vxbq.cn/db/->讀取出來(lái)->顯示出來(lái)的這個(gè)進(jìn)程中，出現(xiàn)了很多OOM，分為：

a.載入圖片時(shí)使用ByteArrayStream創(chuàng)建流，size為Height * Width * 4，OOM；

b.讀取圖片時(shí)候OOM，同上；

c.顯示圖片時(shí)候OOM，decodeResource函數(shù)報(bào)錯(cuò)，OOM；

開(kāi)始時(shí)候以為是文件大小問(wèn)題，后來(lái)發(fā)現(xiàn)有些2M的圖片都能顯示，但是某些1M的圖片確報(bào)錯(cuò)，所以在1定范圍內(nèi)，可以證明，圖片OOM問(wèn)題與文件大小無(wú)關(guān)。

3.圖片尺寸（分辨率）

調(diào)查這些能顯示的圖片和不能顯示的圖片的不同，發(fā)現(xiàn)長(zhǎng)寬差距很大，那些能成功顯示的圖片為1005*1500大小，而其他圖片都是3000*5000以上。

我用PAINT（1款合適小白的圖象處理軟件，雖然不如PS但是功能已非常強(qiáng)大了，最新版需要安裝NET 4.5）緊縮了圖片大小，緊縮到1005*1500，顯示成功。

4.函數(shù)調(diào)用

瀏覽了這位大神的博客：

http://blog.csdn.net/huangbiao86/article/details/8072128

摘取其中最精華的部份吧：

盡可能不要使用setImageBitmap或setImageResource或BitmapFactory.decodeResource來(lái)設(shè)置1張大圖，由于這些函數(shù)在完成decode后，終究都是通過(guò)java層的createBitmap來(lái)完成的，需要消耗更多內(nèi)存。

因此，改用先通過(guò)BitmapFactory.decodeStream方法，創(chuàng)建出1個(gè)bitmap，再將其設(shè)為ImageView的 source，decodeStream最大的秘密在于其直接調(diào)用JNI>>nativeDecodeAsset()來(lái)完成decode，無(wú)需再使用java層的createBitmap，從而節(jié)省了java層的空間。

如果在讀取時(shí)加上圖片的Config參數(shù)，可以跟有效減少加載的內(nèi)存，從而跟有效禁止拋out of Memory異常

另外，decodeStream直接拿的圖片來(lái)讀取字節(jié)碼了， 不會(huì)根據(jù)機(jī)器的各種分辨率來(lái)自動(dòng)適應(yīng)， 使用了decodeStream以后，需要在hdpi和mdpi，ldpi中配置相應(yīng)的圖片資源， 否則在不同分辨率機(jī)器上都是一樣大?。ㄏ袼攸c(diǎn)數(shù)量），顯示出來(lái)的大小就不對(duì)了。

看來(lái)讀底層源碼還是很有用的，setImageBitmap 和 setImageResource 和 decodeResource在履行進(jìn)程中還是調(diào)用了createBitmap來(lái)創(chuàng)建1個(gè)新的bitmap，創(chuàng)建bitmap會(huì)加重內(nèi)存消耗，所以不推薦使用了，應(yīng)當(dāng)使用decodeStream方法。

圖片的緊縮進(jìn)程也能夠設(shè)置1個(gè)適合的百分比來(lái)控制大小。

多張圖片的使用中，請(qǐng)注意流的flush與close（我沒(méi)有及時(shí)flush和close的時(shí)候也運(yùn)行正確了，這個(gè)有待研究1下，但是為了保證1個(gè)良好的習(xí)慣還是注意下吧）。

5.關(guān)于options方法

網(wǎng)上還有很多文章用BitmapFactory.Options來(lái)作為decodeStream時(shí)候的1個(gè)參數(shù)，這個(gè)我暫時(shí)沒(méi)有具體實(shí)驗(yàn)過(guò)，哪位朋友實(shí)驗(yàn)過(guò)了可以回復(fù)交換哈

生活不易，碼農(nóng)辛苦
如果您覺(jué)得本網(wǎng)站對(duì)您的學(xué)習(xí)有所幫助,可以手機(jī)掃描二維碼進(jìn)行捐贈(zèng)