BitmapFactory.Options.inTempStorageオプションの使用目的とは何ですか？BitmapFactory.Options.inTempStorageを使用する理由
Documentationは、この上のかなり簡潔です：
一時ストレージが復号化のために使用します。 16Kほどを提案する。
私が間違っていないとすれば、バッファを明示的に提供しないと、バッファが単独で作成され使用されることを意味します。
私が見る唯一の利点は、複数のデコードに同じ16Kバッファを再利用することです。これは、パフォーマンス/メモリ使用の最適化に非常に疑問の余地があります。
so なぜ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マネージコードを使用して実際のrawバイト（ディスク/ネットワークなどから）をフェッチすることです。割り当てられたバッファを使用して各READ呼び出しのバイトを通信します。ですから、実際はInputStreamに依存しています。たとえば、ディスクISはディスクから4Kの大部分を読み込み、16Kはそれ以上のバッファです。バッファがそれを超えると、パフォーマンスは向上しません。これは、READコールごとにバッファが4kを超えないためです。
いずれにしても、この種の最適化を考慮する必要があります。このような場合は、より大きなバッファを用意してパフォーマンスに影響を与えるかどうかを確認することができます。