一個APP在Android上可以使用的記憶體空間最大為24MB。
但一張圖片轉成Bitmap「物件」後，實際大小會是檔案的四倍以上！
也就是說如果圖片有N張、總大小為4MB，那它轉為Bitmap物件後在記憶體中吃掉將近16MB的大小。
這時候如果加上APP本身其他功能在記憶體中佔的大小，很容易會發生「Out Of Memory」的Error！
或許有人會想：但Bitmap物件在Android APP中無法顯示或作用，需要丟給ImageView之類的UI元件後才會顯示，或許這些UI元件並不會保留Bitmap物件、會將它快速丟入Garbage回收列中。
如果是這樣...對一張已經轉給ImageView顯示的Bitmap進行recycle()指令應該會成功才對！但實際上log訊息卻跳出錯誤碼「不能對一張ImageView正在執行顯示的Bitmap執行recycle()」。
也就是說...
顯示圖片要遭遇的問題並不單單是「將圖檔從resource狀態轉成Bitmap的過程」，轉成Bitmap後存在記憶體中的實際大小本身就是問題的根源。
先解釋一下關於：將圖檔從resource狀態轉成Bitmap的過程...
Bitmap物件並沒有建構子，必須使用內建的static型態參數createBitmap()來產生，或是使用BitmapFactory物件的static型態參數decodeStream。
關於後者，顧名思義就是使用Stream來將resource檔轉成InputStream，然後........(不知道怎麼形容這個過程，反正就是接收Stream資料串就是了。Stream的資料串吐出資料的「開啟」機制一直是我覺得這個物件很「謎」的地方。大家可以直接點連結參考一下怎麼用Stream轉成Bitmap物件。)(連結一)
ImageView有setImageResource()的功能，但這功能本身也是將圖檔從resource索引值轉出成Bitmap物件，它的過程和會遭遇的問題跟上面在討論的並沒有不同。
網路上常見的「標準」解決方法(連結一)，其實僅僅只是將圖檔製作縮圖，取得一個比較小的Bitmap物件。
但...「挑戰」之所以是「挑戰」，就是因為永遠會有人、會有狀況來測驗標準/穩定方法的極限！
如果APP的程序中存在著一次要顯示/讀取多張大尺寸Bitmap，則這個方法(連結一)的穩定性會變得跟紙糊的沒兩樣！
大家用動態的流程想像一下...
假設我用縮放尺寸A來讀取的圖片1，然後將圖片1設給ImageView1，接著我要用相同的縮放尺寸A來讀取圖片2.......抱歉，OOM了！因為記憶體的環境已經跟讀取圖片1時的環境不同了！而這樣的環境已經無法用縮放尺寸A來讀取圖片2。
我曾經試過動態的變化縮放尺寸，讓每一張圖片都有「適合」自己的數值。
結果圖片的縮放品質會開始無底線的探底！
如果圖片是「不太講究品質的小icon」，那OOM的問題根本從一開始就不會發生！也就是說會發生OOM，一定都是解析度要講究、內容必須要可以讓使用者精確閱覽的圖片！
所以用Stream來縮放圖片(連結一)雖然符合Java解決問題的精神原則，但實際上根本沒有解決問題！
(其他還有一些「幻燈片/跑馬燈切換」的方式來展示多張圖片，但這都是從根本上限制「APP設計」，碰到「不行！我們就是要同時展示多張圖片！」時，依賴這種技巧等於讓程式設計師陷入一個叫天天不應、求地地不靈的死局。)
真正治標又治本的方式，就是製作一個存在手機端的小網頁，然後將圖片插入這個網頁中，在轉到WebView上顯示！(連結二)
不要聽到WebView就啞然失笑，「用WebAPP？效能不是很差嗎？」
這個方法除了圖片的顯示以外，其他都還是Java Code，效能等同於Native APP！
只是要注意一些小細節：
1.不要使用String.format來組成Html Tag。(執行後，經常會跳出Error，告訴我「Html少了個「"」。)
2.連結二中是Asset資源圖檔的版本，res中的resource資源檔有不同的file路徑寫法。(連結三)
3.如果有辦法精確控制WebView大小會更好，也可以輕鬆顯示多張圖片。(我有自己的秘訣，但.....解釋起來挺複雜的。如果能夠從「用Java動態設置」為方向去思考，會發現不難。)
但一張圖片轉成Bitmap「物件」後，實際大小會是檔案的四倍以上！
也就是說如果圖片有N張、總大小為4MB，那它轉為Bitmap物件後在記憶體中吃掉將近16MB的大小。
這時候如果加上APP本身其他功能在記憶體中佔的大小，很容易會發生「Out Of Memory」的Error！
或許有人會想：但Bitmap物件在Android APP中無法顯示或作用，需要丟給ImageView之類的UI元件後才會顯示，或許這些UI元件並不會保留Bitmap物件、會將它快速丟入Garbage回收列中。
如果是這樣...對一張已經轉給ImageView顯示的Bitmap進行recycle()指令應該會成功才對！但實際上log訊息卻跳出錯誤碼「不能對一張ImageView正在執行顯示的Bitmap執行recycle()」。
也就是說...
顯示圖片要遭遇的問題並不單單是「將圖檔從resource狀態轉成Bitmap的過程」，轉成Bitmap後存在記憶體中的實際大小本身就是問題的根源。
先解釋一下關於：將圖檔從resource狀態轉成Bitmap的過程...
Bitmap物件並沒有建構子，必須使用內建的static型態參數createBitmap()來產生，或是使用BitmapFactory物件的static型態參數decodeStream。
關於後者，顧名思義就是使用Stream來將resource檔轉成InputStream，然後........(不知道怎麼形容這個過程，反正就是接收Stream資料串就是了。Stream的資料串吐出資料的「開啟」機制一直是我覺得這個物件很「謎」的地方。大家可以直接點連結參考一下怎麼用Stream轉成Bitmap物件。)(連結一)
ImageView有setImageResource()的功能，但這功能本身也是將圖檔從resource索引值轉出成Bitmap物件，它的過程和會遭遇的問題跟上面在討論的並沒有不同。
網路上常見的「標準」解決方法(連結一)，其實僅僅只是將圖檔製作縮圖，取得一個比較小的Bitmap物件。
但...「挑戰」之所以是「挑戰」，就是因為永遠會有人、會有狀況來測驗標準/穩定方法的極限！
如果APP的程序中存在著一次要顯示/讀取多張大尺寸Bitmap，則這個方法(連結一)的穩定性會變得跟紙糊的沒兩樣！
大家用動態的流程想像一下...
假設我用縮放尺寸A來讀取的圖片1，然後將圖片1設給ImageView1，接著我要用相同的縮放尺寸A來讀取圖片2.......抱歉，OOM了！因為記憶體的環境已經跟讀取圖片1時的環境不同了！而這樣的環境已經無法用縮放尺寸A來讀取圖片2。
我曾經試過動態的變化縮放尺寸，讓每一張圖片都有「適合」自己的數值。
結果圖片的縮放品質會開始無底線的探底！
如果圖片是「不太講究品質的小icon」，那OOM的問題根本從一開始就不會發生！也就是說會發生OOM，一定都是解析度要講究、內容必須要可以讓使用者精確閱覽的圖片！
所以用Stream來縮放圖片(連結一)雖然符合Java解決問題的精神原則，但實際上根本沒有解決問題！
(其他還有一些「幻燈片/跑馬燈切換」的方式來展示多張圖片，但這都是從根本上限制「APP設計」，碰到「不行！我們就是要同時展示多張圖片！」時，依賴這種技巧等於讓程式設計師陷入一個叫天天不應、求地地不靈的死局。)
真正治標又治本的方式，就是製作一個存在手機端的小網頁，然後將圖片插入這個網頁中，在轉到WebView上顯示！(連結二)
不要聽到WebView就啞然失笑，「用WebAPP？效能不是很差嗎？」
這個方法除了圖片的顯示以外，其他都還是Java Code，效能等同於Native APP！
只是要注意一些小細節：
1.不要使用String.format來組成Html Tag。(執行後，經常會跳出Error，告訴我「Html少了個「"」。)
2.連結二中是Asset資源圖檔的版本，res中的resource資源檔有不同的file路徑寫法。(連結三)
3.如果有辦法精確控制WebView大小會更好，也可以輕鬆顯示多張圖片。(我有自己的秘訣，但.....解釋起來挺複雜的。如果能夠從「用Java動態設置」為方向去思考，會發現不難。)
沒有留言:
張貼留言