AndroidにおけるScreen Density(Density Buckets)の本質を解説します — ピクセル密度による画面の分類:mdpi、hdpi、xhdpi、xxhdpi、xxxhdpi。Screen Densityは、画面の1インチに何個の物理ピクセルが収まるかを決定し、異なるデバイスでの画像やインターフェースの表示に直接影響します。Google Android Compatibility Definition(2025)によると、Androidは6つの主要なDensity Bucketsと、折りたたみデバイス向けに最大8つの追加Bucketsをサポートしています。
重要なポイント
Screen Densityとは、画面の1インチあたりの物理ピクセル数です(ppi — ピクセル/インチ、またはdpi — ドット/インチ)。AndroidはDensity Bucketsの概念を使用しています — 同様の密度を持つ画面をグループ化し、同じスケーリング係数を適用します。解像度(幅と高さのピクセル数)とは異なり、密度は画面上のピクセルの物理的なサイズを決定します。Google Pixel Team(2025)によると、最新フラッグシップの密度は450〜550 ppiで、xxhdpi〜xxxhdpiバケットに相当します。
Density Bucketsシステムは、Android 1.6 Donut(2009)で160 dpi(mdpi)の最初のデバイスとともに登場しました。画面解像度の向上に伴い、新しいバケットが追加されました:hdpi(Android 1.6)、xhdpi(Android 2.3)、xxhdpi(Android 4.1)、xxxhdpi(Android 4.4)。新しいバケットはそれぞれ、前のバケットと比較して1.5倍または2倍の密度増加を反映しています。Android Open Source Project(2025)によると、現在アクティブなAndroidデバイスの96%がhdpiからxxxhdpiの範囲の密度を持っています。
Density Bucketsとは、GoogleがAndroid画面をグループ化するために定義した密度範囲です。ベースバケットはmdpi(160 dpi)です。スケール係数は、特定のバケットのリソースがmdpiと比較して何倍大きいかを示します。例えば、xhdpi(2×)は、画像の幅と高さがmdpiバージョンの2倍である必要があることを意味します。Android Studio Resource Manager(2025)によると、xxhdpiはアクティブデバイスの中で最も一般的なバケットです(市場シェア38%)、次いでxhdpi(28%)です。
| バケット | DPI範囲 | スケール | デバイス例 | 市場シェア(2025) |
|---|---|---|---|---|
| ldpi | 120 dpi | 0.75× | 古い低価格デバイス | 1%未満 |
| mdpi | 120-160 dpi | 1× | HTC Dream(G1)、7インチタブレット | 3% |
| hdpi | 160-240 dpi | 1.5× | Samsung Galaxy S2、Nexus 4 | 12% |
| xhdpi | 240-320 dpi | 2× | Google Nexus 5、Moto G | 28% |
| xxhdpi | 320-480 dpi | 3× | Samsung Galaxy S8、Pixel 3 | 38% |
| xxxhdpi | 480-640 dpi | 4× | Samsung Galaxy S24 Ultra、Pixel 9 Pro | 18% |
画面解像度は、幅と高さの総ピクセル数です(例:1080×2400)。画面密度は、1インチあたりのピクセル数です。同じ解像度の2つのデバイスでも、物理的な画面サイズが異なる場合は密度が異なる可能性があります。例えば、解像度1080×2400の6インチスマートフォンの密度は約440 dpi(xxhdpi)ですが、同じ解像度の5インチスマートフォンでは約530 dpi(xxxhdpi)です。これが重要な違いです:インターフェースは解像度ではなく密度に適応する必要があります。そうしないと、高密度デバイスでは要素が小さくなりすぎます。
Androidは、特定の画面密度のリソースを読み込むために、resフォルダ名に修飾子を使用します:drawable-mdpi、drawable-hdpi、drawable-xhdpi、drawable-xxhdpi、drawable-xxxhdpi。アプリケーション起動時、Androidはデバイスの密度に最も適合するフォルダからリソースを選択します。完全に一致するものがない場合、システムは最も近いバケットを使用するか、低密度からリソースをスケーリングします。Android Docs(2025)によると、ベクター(VectorDrawable)には密度修飾子は不要です — 自動的にスケーリングされます。
/res/
drawable-mdpi/
icon_app.png (48x48 px)
drawable-hdpi/
icon_app.png (72x72 px)
drawable-xhdpi/
icon_app.png (96x96 px)
drawable-xxhdpi/
icon_app.png (144x144 px)
drawable-xxxhdpi/
icon_app.png (192x192 px)
この構造では、各フォルダに同じアイコンが含まれていますが、物理ピクセルサイズが異なります。mdpiのベースサイズ48×48ピクセルが、各バケットのスケール係数で乗算されます。AndroidはデバイスのDisplayMetrics.densityに基づいて自動的に正しいファイルを選択します。VectorDrawable(XML形式)の場合、drawable/内の単一ファイルで十分です — システムは品質を損なうことなくスケーリングします。
サイズの計算は、各密度の画像に対して単純な式に基づいています:mdpiでのサイズ×スケール係数。mdpiのアイコンが48×48 pxの場合、hdpiでは72×72 px(48×1.5)、xhdpiでは96×96 px(48×2)、xxhdpiでは144×144 px(48×3)、xxxhdpiでは192×192 px(48×4)になります。Material Design Guidelines(2025)によると、この式はすべてのラスターリソース(アイコン、背景、画像、9-patch)に適用されます。
| バケット | スケール | mdpiサイズ(px) | バケットサイズ(px) |
|---|---|---|---|
| mdpi | 1× | 48×48 | 48×48 |
| hdpi | 1.5× | 48×48 | 72×72 |
| xhdpi | 2× | 48×48 | 96×96 |
| xxhdpi | 3× | 48×48 | 144×144 |
| xxxhdpi | 4× | 48×48 | 192×192 |
適切な準備 Density Buckets向けのリソースには5つの主要ルールが含まれます。第一に、シンプルなアイコンにはVectorDrawableを使用します — これにより5つのコピーが不要になります。第二に、ラスター画像の場合は、デザインツールからすべての密度をエクスポートします(Android Studio Asset Studioが自動生成します)。第三に、修飾子なしでdrawable/に画像を配置しないでください — システムが品質を損なってスケーリングします。第四に、メインデバイスとは異なる密度のデバイスでテストします — エミュレータで密度を変更できます。第五に、PNGの代わりにWebPを使用します — Google(2025)によると、WebPは同じ品質で25〜35%小さなサイズを実現します。
よくある質問
mdpi(medium-density pixel-independent)— AndroidにおけるベースのDensity Bucketで、密度は160 dpiです。他のすべてのバケットはmdpiに対して計算されます:hdpi — 1.5×、xhdpi — 2×など。mdpiは1密度非依存ピクセル(dp)あたり1物理ピクセルに相当します。デザイナーはレイアウト作成時にmdpiを基準として使用します。
DisplayMetricsを使用します:getResources().getDisplayMetrics().densityはスケール係数を返します(mdpiの場合は1.0、xxhdpiの場合は3.0)。プログラムでバケットを特定するには、getResources().getConfiguration().densityDpiを呼び出します。Android Studioには、接続されたデバイスのdensityDpiを表示するDevice Explorerもあります。
技術的には — 可能ですが、品質が低下します。リソースがdrawable-xxhdpiにのみある場合、mdpiデバイスでは3分の1に縮小され、画像がぼやけます。リソースがmdpiにのみある場合、xxhdpiでは拡大され、ピクセル化が発生します。推奨は、少なくともxhdpi、xxhdpi、xxxhdpi用に準備することです — これでアクティブデバイスの84%(2025年)をカバーします。VectorDrawableの場合は、修飾子なしの単一ファイルで十分です。
まとめ
ターンキー方式のモバイルアプリケーションを開発します
IT Sectrは2017年からスタートアップや企業向けにiOS・Androidアプリケーションを開発しています。私たちがご相談に乗り、最適なソリューションをご提案します。