さまざまな画面のリソース作成

Android 自体は、幅広い解像度、画面サイズ、画面密度を持つさまざまなデバイスで実行されます。 Android は、これらのデバイスでアプリケーションを動作させるためにスケーリングとサイズ変更を実行しますが、その結果、最適なユーザー エクスペリエンスにならない可能性があります。 たとえば、画像がぼやけて表示される場合や、期待どおりにビューに配置される場合があります。

概念

複数の画面をサポートするには、いくつかの用語と概念を理解しておくことが重要です。

• 画面サイズ – アプリケーションを表示するための物理領域の容量

• 画面密度 – 画面上の特定の領域のピクセル数。 一般的な単位は、1 インチあたりのドット数 (dpi) です。

• 解像度 – 画面上の合計ピクセル数。 アプリケーションを開発する場合、解像度は画面のサイズや密度ほど重要ではありません。

• 密度に依存しないピクセル (dp) – 密度に依存せずにレイアウトを設計できるようにするための仮想単位。 この数式は、dp を画面ピクセルに変換するために使用されます。

  px = dp × dpi ÷ 160

• 向き – 画面の向きは、縦よりも横が広い場合は横向きと見なされます。 対照的に、縦向きは、画面の横より縦が長い場合です。 ユーザーがデバイスを回転させると、アプリケーションの有効期間中に向きが変わる可能性があります。

これらの概念の最初の 3 つが相互に関連していることに注意してください。密度を上げずに解像度を上げると、画面サイズが大きくなります。 ただし、密度と解像度の両方を上げると、画面サイズを変更せずに保持できます。 画面サイズ、密度、解像度の関係により、画面のサポートが急激に複雑になります。

この複雑さに対処するために、Android フレームワークでは、画面レイアウトに密度に依存しないピクセル (dp) を使用することが優先されます。 密度に依存しないピクセルを使用することで、UI 要素は密度の異なる画面上でもユーザーにとって同じ物理サイズであるように見えます。

さまざまな画面サイズと密度のサポート

Android は、画面構成ごとにレイアウトを適切にレンダリングするために、ほとんどの作業を処理します。 ただし、システムをサポートするために実行できるアクションがいくつかあります。

密度の非依存性を確保するには、ほとんどの場合、レイアウトで実際のピクセルではなく、密度に依存しないピクセルを使用するだけで十分です。 Android では、実行時に描画可能ファイルが適切なサイズにスケーリングされます。 ただし、スケーリングによってビットマップがぼやけて表示される可能性があります。 この問題を回避するには、異なる密度の代替リソースを指定します。 複数の解像度と画面密度に対応するデバイスを設計する場合、より高い解像度または密度のイメージから始めてスケールダウンする方が簡単です。

サポートされている画面サイズを宣言する

画面サイズを宣言すると、サポートされているデバイスでのみアプリケーションをダウンロードできるようになります。 これは、AndroidManifest.xml ファイルで supports-screens 要素を設定することで実現できます。 この要素は、アプリケーションでサポートされる画面サイズを指定するために使用されます。 アプリケーションが画面全体にそのレイアウトを適切に配置できる場合、その画面はサポートされていると見なされます。 このマニフェスト要素を使用することで、画面の仕様を満たしていないデバイスの場合、アプリケーションは Google Play に表示されなくなります。 ただし、サポートされていない画面を使用するデバイスでもアプリケーションが引き続き実行されますが、レイアウトがぼやけたり、ピクセル化されたりする可能性があります。

サポートされている画面 6 は、ソリューションの Properites/AndroidManifest.xml ファイルで宣言されています。

AndroidManifest.xml を編集して、次の supports-screens を含めます。

<manifest xmlns:android="http://schemas.android.com/apk/res/android"
          android:versionCode="1"
          android:versionName="1.0"
          package="HelloWorld.HelloWorld">
      <uses-sdk android:minSdkVersion="21" android:targetSdkVersion="27" />
      <supports-screens android:resizable="true"
                        android:smallScreens="true"
                        android:normalScreens="true"
                        android:largeScreens="true" />
      <application android:allowBackup="true"
                   android:icon="@mipmap/ic_launcher"
                   android:label="@string/app_name"
                   android:roundIcon="@mipmap/ic_launcher_round"
                   android:supportsRtl="true" android:theme="@style/AppTheme">
  </application>
</manifest>

さまざまな画面サイズに代替レイアウトを指定する

代替レイアウトを使用すると、コンポーネント UI 要素の配置またはサイズを変更して、特定の画面サイズに合わせてビューをカスタマイズできます。

API レベル 13 (Android 3.2) 以降では、画面サイズは非推奨になり、swNdp 修飾子の使用が優先されます。 この新しい修飾子は、特定のレイアウトに必要な領域の容量を宣言します。 Android 3.2 以降で実行するアプリケーションでは、これらの新しい修飾子を使用することをお勧めします。

たとえば、レイアウトで画面幅が 700 dp 以上必要な場合、代替レイアウトは layout-sw700dp フォルダーに入ります。

ガイドラインとして、さまざまなデバイスの数値を次に示します。

• 標準的な電話 - 320 dp: 標準的な電話

• 5 インチ タブレット/"tweener" デバイス - 480 dp: Samsung Note など

• 7 インチ タブレット – 600 dp: Barnes & Noble Nook など

• 10 インチ タブレット – 720 dp: Motorola Xoom など

最大 12 (Android 3.1) の API レベルを対象とするアプリケーションの場合、ほとんどのデバイスで使用できるさまざまな画面サイズの一般化として、小/標準/大/特大の修飾子を使用するディレクトリにレイアウトを配置する必要があります。 たとえば、次の図では、4 つの異なる画面サイズに対応する代替リソースがあります。

以下は、以前の API レベル 13 の画面サイズ修飾子と密度に依存しないピクセルとの比較です。

• 426 dp x 320 dp は小

• 470 dp x 320 dp は標準

• 640 dp x 480 dp は大

• 960 dp x 720 dp は特大

API レベル 13 以上の新しい画面サイズ修飾子は、API レベル 12 以下の古い画面修飾子よりも優先順位が高くなります。 新旧の API レベルにまたがるアプリケーションの場合は、次のスクリーンショットに示すように、両方の修飾子セットを使用して代替リソースを作成する必要がある場合があります。

画面密度ごとに異なるビットマップを指定する

Android では、デバイスの必要に応じてビットマップをスケーリングしますが、ビットマップ自体がエレガントにスケールアップまたはスケールダウンされず、あいまいになったりぼやけたりする可能性があります。 画面密度に適したビットマップを指定することで、この問題が軽減されます。

たとえば、次の図は、密度指定リソースが指定されていない場合に発生する可能性があるレイアウトと外観の問題の例です。

これを、密度指定リソースを使用して設計されたレイアウトと比較します。

Android Asset Studio を使用してさまざまな密度リソースを作成する

このようなさまざまな密度のビットマップを作成するのは少し面倒な場合があります。 そのため、Google は、Android Asset Studio と呼ばれるこれらのビットマップの作成に関連する面倒な作業の一部を削減できるオンライン ユーティリティを作成しました。

この Web サイトは、1 つのイメージを指定することで、4 つの一般的な画面密度を対象としたビットマップの作成に役立ちます。 その後、Android Asset Studio によって、一部カスタマイズされたビットマップが作成され、zip ファイルとしてダウンロードできるようになります。

複数の画面のヒント

Android は非常に多くのデバイスで実行され、画面サイズと画面密度の組み合わせに圧倒される場合があります。 次のヒントは、さまざまなデバイスをサポートするために必要な作業を最小限に抑えるのに役立ちます。

• 必要なものだけを設計し、開発する - さまざまなデバイスがありますが、設計と開発に多大な労力を要する可能性のあるまれなフォーム ファクターに存在するものもあります。 [画面のサイズと密度] ダッシュボードは、画面サイズ/画面密度マトリックスの内訳に関するデータを提供する Google によって提供されるページです。 この内訳では、サポート画面での開発作業の方法に関する分析情報が提供されます。

• ピクセルではなく DP を使用する - 画面密度が変化するとピクセルが面倒になります。 ピクセル値をハードコーディングしないでください。 ピクセルは避け、dp (密度に依存しないピクセル) を優先します。

• Avoid AbsoluteLayoutWherever Possible – API レベル 3 (Android 1.5) では非推奨となり、レイアウトが脆弱になります。 これは使用できません。 代わりに、LinearLayout、RelativeLayout、GridLayout などのより柔軟性の高いレイアウト ウィジェットを使用してみてください。

• 既定のレイアウト方向を 1 つ選択する - たとえば、代替リソース layout-land と layout-port を指定する代わりに、横向きのリソースを layout に、縦向きのリソースを layout-port に配置します。

• 高さと幅に LayoutParams を使用する - XML レイアウト ファイルで UI 要素を定義する場合、wrap_content 値と fill_parent 値を使用する Android アプリケーションでは、ピクセル単位または密度に依存しない単位を使用する場合よりも、さまざまなデバイス間で適切な外観を確保できます。 これらのディメンション値により、Android はビットマップ リソースを適切にスケーリングします。 これと同じ理由で、密度に依存しない単位は、UI 要素の余白やパディングを指定するときに最適な形で予約されます。

複数の画面のテスト

Android アプリケーションは、サポートされるすべての構成に対してテストする必要があります。 理想的には、デバイスは実際のデバイス自体でテストする必要がありますが、多くの場合、これは不可能であるか実用的ではありません。 この場合、各デバイスの構成に合わせてエミュレーターと Android 仮想デバイスの設定を使用することが有効です。

Android SDK には、AVD の作成に使用できるエミュレーター スキンがいくつか用意されており、多くのデバイスのサイズ、密度、解像度がレプリケートされます。 多くのハードウェア ベンダーも同様に、デバイス用のスキンを提供しています。

もう 1 つのオプションは、サード パーティのテスト サービスを使用することです。 これらのサービスは、APK を取得し、さまざまなデバイスで実行した後、アプリケーションの動作に関するフィードバックを提供します。