アプリの場合、トップダウンでレイアウトを設計したいと考えています。フルスクリーンサイズから始めて、スクリーンサイズをグリッドに分割し、このグリッド内の固定位置にコントロールを配置するなどです。私にとっては、それが最も簡単な方法のようですほぼすべての画面サイズに適合するアプリを設計します。理想的には、コーナーラウンディング、フォントサイズなど、他のものもスケーリングしたいと思います.
これまでの私の印象では、Android はこのアプローチをサポートしたくないということです: ほとんどすべてのものをスケーリングするためのメカニズムがありますが、かなり速く醜くなります.ネストされたレイアウトがたくさん必要です。これには何らかの設計上の理由がありますか？AbsoluteLayout に似ているが、すべてが利用可能な画面サイズの一部に基づいているレイアウトを実装するのは非常に簡単なはずですが、そのようなものは存在しません。
なぜだめですか？そのようなことを望まない理由があるのでしょうか、それともまだ誰もそれを実装しようとしていないだけなのでしょうか?
画面サイズに合わせて拡大縮小するレイアウトの場合、ピクセルを使用してサイズを指定しないでください。代わりに "dp" 単位 (または dip) を使用してください。このユニットは密度に依存しないため、レイアウトをエミュレータの画面サイズに完全に合わせると、Android がスケーリングを処理し、安価な携帯電話 (320x240px) のような小さな画面から、 10 インチのタブレット。もちろん、さまざまな解像度の画像を提供する必要があります。これは、画像のスケーリングが常に非常に急速に悪化するためです。
Android デベロッパーの公式 Web サイトから:
異なる画面では異なるピクセル密度があり、同じ数のピクセルが異なるデバイスでは異なる物理サイズに対応する可能性があるため、レイアウトの寸法をピクセルで定義することは問題です。したがって、寸法を指定するときは、常に dp または sp 単位を使用してください。dp は、160 dpi でのピクセルの物理サイズに対応する、密度に依存しないピクセルです。sp は同じ基本単位ですが、ユーザーの好みのテキスト サイズ (スケールに依存しないピクセル) によってスケーリングされるため、テキスト サイズを定義するときはこの測定単位を使用する必要があります (ただし、レイアウト サイズには決して使用しないでください)。
同じページで、さまざまな画面密度の画像を提供する方法を示しています。
http://developer.android.com/training/multiscreen/screendensities.html