複数の画面をサポートするアプリケーションスケルトン

Androidにはさまざまな機能、解像度、画面サイズを備えたさまざまなデバイスが付属しているため、複数の（大小の）画面をサポートするアプリケーションを開発する際には、サイズとレイアウトに障害があります。

これにより、画面サイズ、解像度、DPIの組み合わせが異なります、Androidデバイス向けに設計および開発する際に大きな課題を生み出します。他のメーカー（Android以外）の解像度とDPIは異なりますが、同じ画面サイズを共有し、解像度は同じアスペクト比に従います。したがって、Android以外のデバイスに合うようにイメージを作成できます。

私の質問は、要件を満たすために従うべき適切なフローまたはアーキテクチャがあるということです。

サイズと解像度が異なるタブレットがあることに注意してください。

Androidデベロッパーにこの情報が含まれていることは承知していますが、私の見方は実装からのものです。

私の理解からわかったことは、Androidグラフィックを設計するために、プログラマーでさえ設計概念を知っている必要があるということです。

最後に、複数の画面のレイアウトとアイコンを処理する構造を作成しました。

Androidは、次の2つのパラメーターに基づいて、デバイスの表示をカテゴリに一般化します。

• 画面サイズ、ディスプレイの物理的なサイズ（対角線で測定）
• 画面密度、ディスプレイの物理的なピクセル密度（ピクセル/インチ、またはppi） `

画面のサイズと密度をすばやく決定するには、「What's my Size」をインストールしてください Android用」アプリ。

画面サイズ

Androidでは、4つの一般的な画面サイズを定義しています。

 Qualifier           Size

 small               ~3 inches (approx) 
 normal              ~4 inches (approx) 
 large               Exceeds 4 inches    
 xlarge              Exceeds 7 inches  

• ほとんどの電話は、小型または通常（対角約3〜4インチ）に分類されます。しかし今、Galaxy S4、HTC One、Xperia Zなどの大画面のスマートフォンがたくさんあります
• Samsung Galaxy Tabのような小さいタブレットは大きい（4インチより大きい）として分類されます
• 特大は、大型タブレットなどの大型デバイスに適用されます

Androidは4つの一般的な画面密度を定義しています。

 Qualifier         Description         Nominal value

 ldpi              low density          120 ppi
 mdpi              medium density       160 ppi
 hdpi              high density         240 ppi
 xhdpi             extra high density   320 ppi

通常：

• 画面サイズはアプリのレイアウトに最も影響します
• 画面密度は画像やグラフィックリソースに最も影響します

ここにデバイス画面のパーセンテージの違いがリストされています

• Ldpi- 75％
• Mdpi- 100％（Android開発者サイトによるとベース）
• Hdpi- 150％
• XHdpi- 200％

しかし、私たちが今知っているように、ほとんどのデバイスは480X800を搭載しているので、これをベースデバイスと見なしているので、新しい計算は次のようになります

• Ldpi- 50％
• Mdpi- 66.67％
• Hdpi- 100％
• XHdpi- 133.33％

つまり、480X800用に最初のアイコンとデザインが作成されますのみ、残りの（Ldpi、Mdpi、Xhdpi）で作成されます。

すべてのレイアウトに共通で、色や形が均一でなければならない画像があります（複雑な形状や曲線はありません）。この種の画像については9patch、「drawable（no-suffix）」フォルダーに配置する画像を作成しています。9Patch画像を作成するには、DrawNinePatchまたはBetterNinePatchを使用できます。

次に、Androidの標準に基づいて画像の名前を変更し、アプリケーションを完成させてhdpiから、drawable-hdpiフォルダーとOpen Adode Photoshop（推奨）を作成します。複数のサイズのアクションを作成します（パーセンテージ比率に従ってサイズを変更します）。バッチ自動化し、source（drawable-hdpi）およびdestination（drawable-ldpi、drawable-mdpi、drawable-xdpi）を指定します。

アクションで画像のサイズが自動的に変更されるため、Photoshopを使用するように私が主張した理由ともう1つプラスの点は、ファイルの名前を変更する必要がないことです（元のファイルと同じ名前が割り当てられます）。

すべてのイメージの作成が完了したら、プロジェクトを更新してテストします。

画面（xhdpi、hdpi、mdpi）をサポートするレイアウトが小さな画面（ldpi）で切り取られる可能性がある場合があるので、これを処理するには、レイアウト用の別のレイアウトフォルダー（layout-small）を作成し、ScrollView（ほとんど）追加します。それでおしまい。

タブレット タブレットは2つのサイズに分類されます。

1. 7インチ（1024X（600-48（ナビゲーションバー）））= 1024X552（ドローアブル-大）
2. 10インチ（1280X（800-48（ナビゲーションバー）））= 1280X752（ドローアブルxラージ）

これでは、両方の画面の画像を作成し、それに応じて配置する必要があります

したがって、全体として、アプリケーションにこのフォルダを配置して、複数画面をサポートします。

drawable
drawable-ldpi
drawable-mdpi
drawable-hdpi
drawable-xhdpi
drawable-large
drawable-xlarge

より修飾子の組み合わせになります Screen size and Screen density

drawable-large-ldpi
drawable-large-mdpi
drawable-large-hdpi
drawable-large-xhdpi

より多くの修飾子 Screen density and Version

drawable-ldpi-v11
drawable-mdpi-v11
drawable-hdpi-v11
drawable-xhdpi-v11

とより多くの修飾子 Screen size and Version

drawable-large-v11
drawable-xlarge-v11

とより多くの修飾子 Smallest width concept(SW)

 drawable-sw???dp

さらにAndroid V3.0 HoneycombではSW(smallest width)、どのデバイスが画面の幅に分類されるかという新しい概念が導入されたので、drawable-sw360dp、720dp（幅または高さ）のデバイスはこのフォルダーのリソースを使用します。

たとえば、接尾辞Samsung Galaxy S3 dpをdrawable-sw？dpに見つけるには
、DP計算を参照します。レイアウトまたはS3へのドローアブルをサポートする場合、計算は次のようになります。

px =デバイスの幅= 720
dpi =デバイスの密度= 320

与えられた式

    px = dp * (dpi / 160)

pxの値があるため、式を交換する

    dp = px / (dpi / 160)

今価値を置く、

     dp= 720 / (320/160);
     dp=360. 

そう drawable-sw360dp仕事をします

GsmArena Sameway からデバイス構成を取得するデバイスのAndroid APIバージョン、つまりdrawable-hdpi-v11`に従ってフォルダーを作成して、API11を備えているデバイスがHdpiの場合、このリソースを使用することもできます。

追加のヒント：

• 相対レイアウト、dp、sp、mmを使用する

  dp units-デバイスに依存しないピクセル。160ppi画面で1物理ピクセルに正規化されます。つまり、中密度です。実行時にスケーリングされます。画面要素の寸法に使用

  sp units -dp単位に基づいて浮動小数点値として指定されますが、ユーザーのfont-size設定に合わせてさらにスケーリングされた、スケーリングされたピクセル。実行時にスケーリングされます。フォントサイズに使用

  レイアウトには常にRelativeLayoutを使用する必要があります。AbsoluteLayoutは非推奨であり、使用しないでください。

• 適切な画像形式を使用する-PNGとJPEG

  Android "prefers" PNG for bitmap image files, "accepts" JPEG, and "discourages" GIF.

  ただし、PNGとJPEGは同等ではありません。品質のトレードオフは異なり、PNGが常に最良であるとは限りません。

  JPEGはPNGよりも最大50％のファイルサイズを削減できます。これは、アプリが画像を多用する場合に重要です。

  同じファイルサイズの場合、高品質の「可逆」JPEGは、高度に圧縮された「可逆」PNGよりも見栄えがよくなる場合があります。

• デバッグのために画像とグラフィックにラベルを追加する

• supports-screens要素を使用する

• 実際のデバイス値でエミュレーターを構成する

  従来、デスクトップシステムは72ppi（Mac）、または96ppi（Windows、Linux）で表示されます。モバイルと比較して、デスクトップディスプレイは常に低密度です。

  実際のデバイス値を模倣するようにAndroidエミュレーターを常に構成し、デバイス密度をエミュレートするようにスケーリングするように常に設定します。

  Eclipseでは、実際のデバイスの値で構成された複数のエミュレーターを簡単に作成できます（Eclipseメニューバーから[ ウィンドウ]> [AVDマネージャー]> [新規 ]を選択）。

  エミュレーターにエミュレートする実際のデバイスの名前を指定します。解像度を指定します。組み込みの一般的なサイズは使用しません。デバイスの密度を実際のデバイスと一致するように設定します（ハードウェアペインで、抽象LCDプロパティを実際の密度に設定します。常に整数値です）。

  デバイスを起動するときは、常に[画面を実際のサイズに拡大縮小]を選択し、実際の画面の寸法をインチで入力します。

  デバイス密度を設定しない場合、エミュレータはデフォルトで低密度になり、常にldpi固有のリソースをロードします。解像度（ピクセル寸法）は正しくなりますが、密度に依存する画像リソースは意図したとおりに表示されません。

  もちろん、低密度のデスクトップディスプレイで高密度の画像品質を再現することはありません。

2012年10月1日までの7日間に収集されたデータを以下に示します。Androidプラットフォームのバージョンに関する最新の統計を確認するには、こちらにアクセスしてください

画面サイズに基づく

画面密度に基づく

デザイナーは、の基本設計を作成する必要があります

base size of mdpi devices * density conversion factor of highest supported density bucket
サイズ：基本画面サイズは320 X 480ピクセルで、密度バケットは次のとおりです。

• ldpi：0.75
• mdpi：1.0（基本密度）
• hdpi：1.5
• xhdpi：2.0
• xxhdpi：3.0
• xxxhdpi：4.0

また、Androidデバイスで利用可能な余分なスペースに取り組むには、両方向（水平および垂直）に伸縮可能なコンポーネントを使用する必要があります。詳細情報はここにあります：

http://vinsol.com/blog/2014/11/20/tips-for-designers-from-a-developer/