2

Android 開発に関する多くのブログとベスト プラクティスは次のように述べています。

「考えられるすべての密度に対してビットマップを提供する必要はありません。Android は現在の密度に合わせてビットマップを (通常はロード時に) スケーリングします。」

参考リンク：https ://plus.google.com/105051985738280261832/posts/6eWwQvFGLV8

試してみたらうまくいきました。しかし、私は一つのことを理解できませんでした。

たとえば、ビュー ページャーにそれぞれ約 1.5 MB の 5 つの全画面画像を含むサンプル アプリを作成しました。

Galaxy Tab 2 のような 7 インチ MDPI デバイス用の重いイメージを作成し、「drawable-large-mdpi」フォルダーに配置しました。少しぎくしゃくしていましたが、クラッシュすることはなく、すべての画像をスクロールできました。

今、ほぼ大型の HDPI デバイスである Nexus 7 でアプリを使用しようとしました。ビットマップのデコード中にアプリが「OOM エラー」でクラッシュしました。

*イメージを大きな MDPI から大きな HDPI に移動すると、両方のデバイスでクラッシュすることなく正常に動作します。*

だから私は2つの質問があります。

  1. この結果は、グラフィック アセットを最も密度の高いドローアブル フォルダーに配置して、その範囲内で自動的に縮小することしかできないという傾向がありますか?
  2. 初めてクラッシュした理由は内部でどうなりますか?
4

2 に答える 2

3

  1. ドローアブルが拡大縮小されたときにきれいに見える限り、それはそれを行う1つの方法です。通常、サイズを縮小する方が拡大するよりも優れています。そうは言っても、次の行があります。

    それでも、ビットマップがデザインされていない密度にスケーリングされると、エッジが柔らかくなるなどのアーティファクトが発生する可能性があります。

    HDPIからへのスケーリングが正常にTVDPI機能する理由は、2つの密度が非常に近いためです。一部の画像の問題は、主要な濃度の間に現れ始めます。たとえば、からジャンプHDPIするLDPIと、画像が低解像度用に設計されていないため、多くのアーティファクトが発生します。

  2. Nexus 7のOOMでクラッシュする可能性が最も高いのは、デバイスが画像と見なす大きな画像を取得し、設定に合わせMDPIてスケールアップするためです。TVDPIこれにより、画像がさらに大きくなります。

    それらをHDPIフォルダーに配置すると、縮小するTVDPIように指示され、結果の画像のメモリフットプリントが少なくなります。

    実際のスケーリングで再生されるオーバーヘッドもあります。

    XHDPIデバイスにスケールアップする場合も、おそらく同じことが起こります。

于 2013-03-11T21:07:15.513 に答える
0
  1. いいえ、グラフィック アセットは任意のドローアブル フォルダーに配置できます。リソースを 1 つの密度フォルダーにのみ配置すると、システムはターゲット デバイスの密度に合わせてスケールアップおよびスケールダウンします。
  2. これらの大きな画像を同時に使用して、多くのメモリを使用したいと考えていました。圧縮された画像形式を使用する場合でも、システムが画面に描画すると、ビットマップとしてメモリに格納されます。そのため、4 ～ 5 個の 1200x800 ピクセルの画像を同時にメモリに保持すると、ビットマップでその量のメモリが使い果たされます。許可されたメモリを使い果たしたため、アプリがクラッシュしました（これはデフォルトでは非常に低く、通常はメーカーによって拡張される 16 MB のみを保証します）。

画像をhdpiに入れると、システムは画像を縮小しました。そのため、小さな画像に十分なメモリがある可能性があります（保証されていません）。

解決策: 大きな画像を背景として使用しないでください。適切にスケーラブルなイメージを試して、9 パッチ形式をチェックしてください:リンク

于 2013-03-11T21:04:44.047 に答える