什麼打算使用案例BitmapFactory.Options.inTempStorage選項？爲什麼使用BitmapFactory.Options.inTempStorage？
Documentation是這個漂亮簡潔：
臨時存儲用於解碼。建議16K左右。
如果我沒有弄錯，這意味着如果你沒有明確提供緩衝區，它會自行創建和使用一個緩衝區。
所以我看到的唯一好處是重用多個decodings同一16K緩衝區，這似乎對性能/內存佔用優化相當可疑的影響。
那麼爲什麼SDK的作者給我們在臨時存儲解碼控制？應該提供更大的緩衝區來提高解碼性能嗎？
有人能在這個擴張？
看來，你的假設是正確的 - 這個選項主要是爲回收緩衝區本身。
從Android Source Code：
// pass some temp storage down to the native code. 1024 is made up,
// but should be large enough to avoid too many small calls back
// into is.read(...) This number is not related to the value passed
// to mark(...) above.
byte [] tempStorage = null;
if (opts != null) tempStorage = opts.inTempStorage;
if (tempStorage == null) tempStorage = new byte[16 * 1024];
這意味着，如果你不發這個緩衝區，將分配。儘管在大多數情況下看起來並不像大多數情況下的優化，但如果加載很多小圖像 - 每個圖像分配16K緩衝區可能會很昂貴。
關於緩衝區大小，您可以從代碼中的註釋中看到 - 沒有幻數。會發生什麼是解碼圖像的本機代碼，使用InputStream託管代碼來獲取實際的原始字節（從磁盤/網絡等）。它使用分配的緩衝區來傳遞每個READ調用的字節。所以，這實際上取決於InputStream。例如，磁盤IS可能會從磁盤讀取大量4k的數據，然後16k就足夠了 - 傳入大於緩衝區的緩衝區不會提高性能，因爲在每次READ調用時，緩衝區的填充不會超過4k。
在任何情況下，考慮到這種優化應該是一個真正的特定情況 - 如果你有這種情況，你可以提供一個更大的緩衝區，看它是否對性能有任何影響。