Android は、サイズとピクセル密度が異なる画面を備えたさまざまな端末上で動作します。 各画面に合わせたユーザー インターフェースの基本的なスケーリングとサイズ変更はシステムが行いますが、各種類の画面に UI をスムーズに適応させるためにデベロッパーがさらに行うべき作業があります。
このページでは、こうしたトピックについて概説します。また、アプリを画面に適応させるのに役立つ、Android の機能を紹介します。 さまざまな画面に対応したアプリの作成方法については、以下のページの具体的な説明をご覧ください。
画面サイズ
画面サイズとは、アプリの UI 用に提供される表示スペースです。 アプリが認識する画面サイズは、端末の画面の実際のサイズではなく、画面の向き、システム デコレーション(ナビゲーション バーなど)、ウィンドウ構成の変更(ユーザーによるマルチ ウィンドウ モードの有効化など)が考慮されます。
柔軟性のあるレイアウト
Android では、デフォルトで現在の画面に合うようにアプリのレイアウトがリサイズされます。 画面サイズのわずかな変化に対してもレイアウトが適切にリサイズされるようにするには、柔軟性を念頭に置いてレイアウトを実装する必要があります。 その際は、UI コンポーネントの配置やサイズのハードコーディングを避けるという基本原則を遵守するようにしてください。 代わりに、表示サイズを伸縮できるようにし、親ビューや他の兄弟ビューに対する相対的な表示位置を指定することで、レイアウトが拡大しても、意図した順序や相対的サイズをそのまま維持することができます。
代替レイアウト
柔軟性のあるレイアウトにすることは非常に重要です。ただし、スマートフォンやタブレットなど、それぞれの端末で利用可能な領域に応じてユーザー エクスペリエンスを最適化するには、複数のレイアウトを設計する必要があります。 Android では、現在の端末の画面サイズに応じて実行時に適用される代替レイアウトのファイルを用意することができます。
図 1. 同じアプリでも、画面サイズに合わせて異なるレイアウトを使用できる
伸縮可能な画像
レイアウトは現在の画面に合うように伸縮する必要があるため、すべてのレイアウト ビューにアタッチされるビットマップも同様に伸縮可能でなければなりません。 ただし、一般的なビットマップを任意の方向に引き伸ばすと、不自然なスケーリングの乱れが発生し、画像がゆがむ恐れがあります。
この問題を解決するため、Android では 9-patch ビットマップをサポートしています。9-patch ビットマップでは、伸縮可能な小さなピクセル領域を指定します(画像の他の領域は伸縮されないままになります)。
ピクセル密度
ピクセル密度とは画面の物理領域内に含まれるピクセル数であり、dpi(1 インチあたりのドット数)と表記されます。 これは、画面上のピクセル総数を表す解像度とは異なります。
図 2. サイズは同じでピクセル密度が大きく異なる 2 つの端末の違いを強調した図
密度非依存
(図 2 に示すような)異なるピクセル密度を持つ画面にアプリを表示したときに、(ユーザーから見た)UI デザインの物理サイズが維持される場合に、アプリで「密度非依存」が実現します。 密度を非依存にすることは非常に重要です。非依存でないと、ボタンなどの UI 要素は、低密度画面では大きく表示され、高密度画面では小さく表示されてしまいます(図 2 に示すように、ピクセルが大きいと、数ピクセルでかなりの面積を占めます)。
Android システムでは、測定単位としてピクセル(px)ではなく密度非依存ピクセル(dp または dip)を指定することによって密度非依存を実現できます。
代替ビットマップ
すべての画面で画像が最適に表示されるようにするには、各画面密度に対応する代替ビットマップを用意する必要があります。 たとえば、中密度(mdpi)の画面に対応したビットマップしか用意していないアプリを高密度の画面上に表示する場合、画面上で画像が同じ物理領域を占めるように、Android はビットマップを引き伸ばします。 この処理によって、ビットマップに目に見えるスケーリングの乱れが発生する場合があります。 そのため、高解像度の場合はアプリに代替ビットマップを含める必要があります。
ベクター グラフィック
シンプルな画像(主にアイコン)の場合は、ベクター グラフィックを使用すると、各密度に対応した画像を別々に作成せずに済みます。 ベクター グラフィックでは、ピクセルではなく幾何学的なラインパスを使用してイラストを定義するため、スケーリングの乱れを発生させずに、任意のサイズでイラストを描画できます。
Wear OS、TV、Auto、Chrome OS
上記の推奨事項は、すべての Android フォーム ファクタに当てはまります。ただし、Wear OS、Android TV、Android Auto、Chrome OS 端末向けにアプリを作成する場合は、もう少し必要な作業があります。
これらの各端末には独自のユーザー インタラクション モデルがあるため、アプリでそのモデルに対応しなければなりません。 たとえば Wear OS など、一部のケースでは、アプリのユーザー エクスペリエンスを再検討して、その端末に最適なアプリを作成する必要があります。 また、Chrome OS 端末(Google Pixelbook など)をサポートする場合は、既存のアプリを少しだけ変更して、キーボードやマウスとのインタラクションに対応し、非常に大きな画面をサポートしなければなりません。
こうした端末をサポートする際は、以下のデベロッパー ガイドをご覧ください。
画面の非互換性
Android のフレームワークとツールには、アプリをあらゆる画面構成で使用できるようにするために必要なものがすべて用意されていますが、なんらかの非互換性により、画面構成によってはアプリを使用不可にしたいと思うかもしれません。
そのような場合は、特定の画面のみをアプリでサポートするように宣言できます。