（doc）displaying bitmaps efficiently
這篇是翻譯的,
此次是實踐,是關於android系統的解碼的例項
文中說到:
攝像頭在galaxynexus拍一張**有2592*1936畫素，如果bitmap使用argb_8888配置（2.3預設的），載入這張**到記憶體需要消耗約19mb記憶體，（2592*1936*4bytes）
19m的記憶體對模擬器的16m來說,顯然太大了,但對於真實的機器 ,還是可以的
至於說android的記憶體8m,這個不知道是聽誰說的,總之我也沒有找到標準的答案,有可能是在android剛出來的時候定義的乙個堆大小,我覺得最有可能的是這個值作為解碼的記憶體大小,卻不是對的大小限制的.所以上面的是可以解碼顯示出來的.
先說下情況:
一張440*17514大小的,直接在galaxy上解析,然後得到bitmap,再放到imageview中顯示,一切正常的.說下galaxy的情況:
/system/build.prop中的heapsize=64m
兩種方法,一種是argb_8888配置,一種 是rgb_565
實踐也表明了,兩種解碼後的效果差不多的,如果不是影象處理,完全可以用rgb_565來處理的顯示,
顯然這張解析需要29m左右的記憶體,<64m.所以我覺得android的記憶體限制不是只是上,而是整個程序的,當程序占用的記憶體沒有超過這個值,就是正常的,而,解析通常是最耗記憶體的操作.
在imageview中顯示一張,argb_8888,然後再解碼一次,29*2+其它的操作,物件記憶體,勉強》64m了,只能解碼一次.
使用rgb_565解碼一次15m左右,可以有四次的機會,為什麼不是三次呢,29*2<64,但一次解析大圖,消耗的其它物件記憶體也大了.
於是修改了/system/build.prop中的heapsize=48m,重啟了,
再執行,argb_8888一次解碼正常的.二次崩潰.
使用rgb_565解碼,可以兩次,三次崩潰.
於是修改了/system/build.prop中的heapsize=24m,重啟了,
再執行,argb_8888一次崩潰.
使用rgb_565解碼,可以一次,第二次崩潰.
,由此可見,不是一張大的圖不可以顯示出來,通常一張拍攝的**像2592*1936這樣的,有這樣的解析度,就有相應的機器對應,所以記憶體也就大了,不是所謂的8m.
由於只分析了一些實踐結果,對系統的**沒有研究,有可能這是不對的,或許
c對解碼作了一些記憶體上的限制.
但是可以知道,8m的記憶體是不對的,即使現在新機器中最爛的也不小於512m的記憶體,heapsize也》24m,所以對於上面這種大的,使用rgb_565解碼,是沒有問題的.
final int memclass = ((activitymanager) this.getsystemservice(context.activity_service)).getmemoryclass();
system.out.println("memclass:"+memclass);
可以得到這個值的大小.
最近做的微博程式中大圖瀏覽直接崩潰,記憶體不足,64m的記憶體,快取各種64張,大小大約是在400*1600,幾十張載入後就崩潰了.
當然如果沒有必要,還是縮放一下較好:
bitmapfactory.options options = new bitmapfactory.options();
使用縮放的效果明顯要比使用rgb_565解碼糟糕的多了.
android bitmap記憶體處理
程式中一次性載入多張，而且還要適應螢幕，這就造成記憶體緊張，程序會出現oom，特別是現在的手機解析度高達1920 1024，一張占用記憶體高達8m，首先要獲取原的高寬 減少記憶體 bitmapfactory.options options new bitmapfactory.options opti...
Android Bitmap應用收集
bitmap代表一張位圖，副檔名可以是.bmp或者.dib。點陣圖是windows標準格式圖形檔案，它將影象定義為由點 畫素 組成，每個點可以由多種色彩表示，包括2 4 8 16 24和32位色彩。例如，一幅1024 768解析度的32位真彩，其所佔儲存位元組數為 1024 768 32 8 307...
Android bitmap用法介紹
bitmap是android中重要的影象處理工具類，通過bitmap可以對影象進行剪下 旋轉 縮放等操作，同時還可以指定格式和壓縮質量儲存影象檔案。一 拿到乙個bitmap物件 檢視原始碼我們知道，bitmap被final修飾，因此不可以通過new來獲得乙個bitmap的例項，獲得乙個bitmap物...