まず、目的のサイズに近いサイズでビットマップをロードするために、inJustDecodeBoundsおよびサイズを使用するという推奨されるアプローチを認識しています。inSampleただし、これはターゲットに近い画像のみを取得するかなり広範なアプローチです。
私は、ネイティブローダーを利用options.inDensityして、画像をより正確に目的のターゲットサイズにスケーリングするように仕向けました。options.inTargetDensity基本的にoptions.inDensity、画像の実際の幅とoptions.inTargetDensity目的の幅に設定すると、実際に目的のサイズの画像が得られます (この場合、縦横比はたまたま同じままです)。次にimage.setDensity(DENSITY_NONE)、結果の画像を設定すると、すべて正常に動作するように見えます。
このアプローチに何か問題があることを知っている人はいますか? メモリ効率と画質について何か考えはありますか?
私には素晴らしいですね！（Android開発者がコードを書いたのに、機能を正気で賢明な方法で公開しなかったとは信じられません）。
ひとつ気になることがあります。Android は、いずれかの寸法が 2048x2048 ピクセルを超えるインスタンス化されたビットマップを処理できないと信じる十分な理由があります。再スケーリングを行う内部コードが十分にインテリジェントでない場合、2048x2048 より大きいビットマップをロードするときに失敗する可能性があります。
私はこれについて自分で考えていました.inDensityとinTargetDensityを使用して、デコード時にビットマップを拡大/縮小しました。これはうまく機能しますが、残念ながらパフォーマンス (アニメーション) の結果が非常に悪くなります。残念ながらダウンサンプリング専用のinSampleSizeと同様に、これをデコード時にスケールアップ/ダウンするための「ユニバーサル」アプローチとして使用できることを望んでいました。異なるネイティブ実装があるようです: inSampleSize は適切に機能し、明らかなパフォーマンスへの影響はありませんが、inDensity/inTargetDensity は顕著なパフォーマンスへの影響 (スローモーションなど) を導入しました。
または、何か不足していますか？
I have always got better image management with Opengl 2.0 and surface views.