ある投稿者は、Android の密度非依存性メカニズムに関する質問への回答として、SDPというプロジェクトを使用することを提案しました。彼はそれを正当化して、次のように述べました。
Android 開発者が複数の画面をサポートするのに役立ちます
なぜそれは一般的に悪い答えまたは悪い考えなのですか?
1 に答える
2
複数の理由:
悪い習慣
このプロジェクトで採用されたアプローチは、ほぼ間違いなく役に立たず、破壊的ですらあります。
Android の密度の独立性が損なわれるため、破壊的です。デバイスの一般化された密度用に設計されているため、ディスプレイの実際のインチあたりのピクセル数のプロパティに一致するようにスケーリングする必要がほとんどない画像が必要です。さらに、10 インチ タブレットでは最大 2.6 倍にスケールアップします。これにより、ぼやけたビットマップまたはピクセル化されたビットマップが発生する必要があります。
次の理由で役に立たない:
そもそも、より大きなデバイスで物理サイズを大きくしたくありません。アプリを使用して、すべてをより大きな画面にスケーリングしたくはありません。これは、2010 年に iPad が最初に登場し、人々がそれを嫌ったときに Apple が行ったことです。
あなたが望むのは、テキスト、ボタン、およびその他の UI 要素の幅に制限を設けることです。また、より広いマージンが必要です。ただし、Android が画面密度を処理する方法をいじるのではなく、大画面用の代替レイアウトを提供することでこれを処理します。ドキュメントはそれについて私に同意します。
また、大画面でグラフィックを大きくしたい場合(一般的にはそうすべきではありません。ここでの 2 番目の画像は、水平方向のストレッチを除いて完全に問題ありません)、すべてのサイズ/密度のドローアブルを提供することで処理する必要があります。応援したいペア。たとえばdrawable-hdpi、、、、。drawable-xhdpi_ drawable-sw720dp-hdpi_ drawable-sw720dp-xhdpiこのようにして、ビットマップはそれらの大きな画面用にスケーリングする必要がなくなり、高品質で表示されます。
誤解を招く
スクリーンショットは、各デバイスで同じ縮尺を使用していません。Nexus 7 は、Nexus One と同じくらい小さく見えます。
縮尺が保持されている場合、プロジェクトを使用した場合の比較は次のようになります。
そして、このように、それを使用しないとき：
無関係
そのプロジェクトは、画面密度ではなく、物理的なサイズを扱います。それが行うことは、さまざまな物理画面サイズに応じて単位をスケーリングします。
聞かれた質問には当てはまりません。これは、「Android は実際の画面密度をどのように一般化していますか?」と言い換えることができます。
于 2015-11-25T13:52:44.700 に答える