這個問題其實早就遇到了，由於停了幾天電無法工作，今天就把這問題記錄下分享下。利用BitmapFactory載入網路中的圖片時，使用decodeStream方法會返回null的錯誤。主要是由於下面幾個原因導致的：

• 流已經關閉
• decodeStream呼叫了兩次
• decodeStream的BUG（本文不討論，詳見參考文章）

這個問題很有意思，剛開始遇到的時候在國內外到找到許多不同的解決方法，在stackoverflow上也有提問相關的問題（詳見參考文章），本人經過驗證總結後和大家分享下。

• 流已經關閉的解決方法
  出現這個問題的主要原因是解析網路流的程式碼寫在了流關閉後，只需要分析清楚流在什麼時候關閉即可。

• decodeStream呼叫了兩次的問題分析和解決方法
  本文主要對此情況進行分析：
  首先是如何重現這種問題，很顯然為了得到圖片的解析度，一般都會先把inJustDecodeBounds設定為true，解析圖片，這時候的decodeStream是必定返回null，api本身設計就是這樣，

options.inJustDecodeBounds = true;
BitmapFactory.decodeStream(is, null, options);

但是如果在上述程式碼再執行類似下面的程式碼，即再次呼叫decodeStream方法，這樣的話就會出現返回的bitmap為null的問題。

options.inJustDecodeBounds = false;
Bitmap bitmap = BitmapFactory.decodeStream(is, null, options);

如果直接不解析解析度decodeStream的話可以正常返回Bitmap物件，這個原因很簡單，第一次decodeStream時已經操作過inputstream了，這時候流的操作位置已經移動了，如果再次decodeStream則不是從流的起始位置解析，所以無法解析出Bitmap物件。
只需要新增下面程式碼使流讀寫位置恢復為起始位置即可：

is.reset();

這個其實在原始碼中有提示需要考慮流的讀取位置變化的問題。

個人建議是，既然需要優化Bitmap的顯示，如果做快取的話，建議把InputStream網路流寫到檔案，利用decodeFile方法來解析就不存在上述的問題。（decodeFile內部是呼叫了decodeStream解析本地流）
個人認為網上有些把網路流重新再讀取一次這種做法不合理，不但浪費使用者流量而且會使處理變慢，另外一些把流包裝了再處理的個人感覺不如寫到本地再解析。

decodeStream的原始碼

 public static Bitmap decodeStream(InputStream is, Rect outPadding, Options opts) {
        // we don't throw in this case, thus allowing the caller to only check
        // the cache, and not force the image to be decoded.
        if (is == null) {
            return null;
        }

        // we need mark/reset to work properly

        if (!is.markSupported()) {
            is = new BufferedInputStream(is, DECODE_BUFFER_SIZE);
        }

        // so we can call reset() if a given codec gives up after reading up to
        // this many bytes. FIXME: need to find out from the codecs what this
        // value should be.
        is.mark(1024);

    ...

宣告

原創文章，歡迎轉載，請保留出處。
有任何錯誤、疑問或者建議，歡迎指出。
我的郵箱:[email protected]

參考文章