다중 화면 지원
안드로이드는 다양한 화면 크기와 밀도를 제공되며 다양한 기기에서 실행한다. 응용 프로그램은 안드로이드 시스템은 일관된 개발 환경을 제공하며, 이를 통해 화면에 각 응용 프로그램의 사용자 인터페이스를 조정하는 작업하도록 처리되어 있다. 동시에, 시스템은 다른 화면 구성에 대한 UI 디자인을 최적화하기 위해 특정 화면 크기와 밀도에 대한 응용 프로그램의 UI를 제어 할 수 있는 API를 제공한다. 예를 들어, 단말기의 UI과 테블릿의 UI를 다르게 구성할 수 있다.
시스템에서 다른 화면에서 응용 프로그램이 작동하도록 크기 조정을 수행하지만, 다른 화면 크기와 밀도에 대한 응용 프로그램을 최적화 할 수있는 노력을해야 한다. 단순히 자신의 기기의 화면에 맞게 늘어 보다 설계되었다고 생각 모든 장치 및 사용자에 대한 사용자 경험을 극대화 할 수 있습니다.
이 문서에 설명 된 규정에 따라, 하나의 APK파일로 모든 화면 구성하는 제대로 표시하고 지원되는등 최적화 된 사용자 경험을 제공하는 응용 프로그램을 만들 수 있습니다.
참고 :이 문서의 정보는 응용 프로그램이 안드로이드 1.6 (API 레벨 4) 이상을 위해 설계한다고 가정한다. 응용 프로그램이 안드로이드 1.5 이하를 지원하는 경우, 먼저 읽어 보시기 바랍니다 안드로이드 1.5 전략 .
또한, 안드로이드 3.2는 보다 정확하게 응용 프로그램이 서로 다른 화면 크기에 사용하는 레이아웃 리소스를 제어 할 수 있도록 새로운 API를 도입하지 않을 수도 있습니다. 태블릿에 최적화 된이있는 응용 프로그램을 개발하는 경우 이러한 새로운 기능은 특히 중요합니다. 자세한 내용은 대한 섹션을 참조하십시오 안드로이드 3.2을위한 태블릿 레이아웃을 선언을 .
화면의 개요 지원
이 문서와 API, 시스템이 지원하는 화면 구성의 요약에서 사용하는 용어와 개념을 소개하고, API와 기본 화면의 개요 :이 섹션 등 다양한 스크린에 대한 Android의 지원에 대한 개요를 제공합니다 호환성 기능을 제공합니다.
용어와 개념
Screen size
화면의 대각선으로 측정 실제 실제 크기.
편의를 위해, 네 일반화 된 크기에 안드로이드 그룹은 모든 실제 스크린 크기 : 대형 소형, 일반, 대형, 및 추가.
Screen density
화면의 물리적 인 영역에 픽셀의 수량은, 일반적으로 DPI (인치당 도트 수)로 지칭. 예를 들어, "낮은"밀도 화면이 "보통"또는 "높음"밀도 화면에 비해 주어진 물리적 공간에서 적은 픽셀을 가지고 있습니다.
편의를 위해, 네 일반화 된 밀도에 안드로이드는 그룹 모든 실제 스크린 밀도를 : 낮은, 중간 높은, 그리고 더 높은.
Orientation
보기의 사용자의 시점에서 화면의 방향. 이 화면의 가로 세로 비율이 각각 넓은 또는 높이 중 하나입니다 즉, 가로 또는 세로 중입니다. 할 다른 장치뿐만 아니라 기본적으로 서로 다른 방향에서 작동하지만 사용자가 장치를 회전하면 방향이 런타임에 변경할 수 있음에 유의해야합니다.
Resolution
화면의 실제 픽셀의 총 수입니다. 여러 스크린에 대한 지원을 추가 할 때, 응용 프로그램은 해상도와 직접 작동하지 않습니다, 일반화 크기와 밀도 그룹에서 지정한 응용 프로그램 만 화면 크기 및 밀도에 관심을해야합니다.
Density-independent pixel (dp)
UI 레이아웃을 정의 할 때 밀도 독립적 인 방식으로 레이아웃 크기 또는 위치를 표현하기 위해 사용해야하는 가상 픽셀 단위입니다.
밀도 독립적 픽셀은 "중간"밀도 화면에 시스템에 의해 가정 기준 밀도있는 160 dpi의 화면에 하나 물리적 픽셀에 해당합니다. 런타임에서, 시스템은 투명하게 사용되는 스크린의 실제 밀도에 따라 필요한 DP 단위, 어떤 스케일링을 처리합니다. 화면 픽셀 DP 단위의 변환이 간단하다 : px = dp * (dpi / 160) . 예를 들어, 240 dpi의 화면에서, 1 DP 1.5 물리적 픽셀 같습니다. 애플리케이션의 UI를 정의 할 때 항상 다른 밀도로 화면에 UI의 적절한 표시를 보장하기 위해, DP 단위를 사용해야합니다.
지원되는 화면의 범위
안드로이드 1.6 (API 레벨 4)를 시작으로, 안드로이드는 장치가있을 수 있습니다하는 다양한 화면 구성을 반영, 여러 화면 크기와 밀도에 대한 지원을 제공합니다. 각 화면 구성에 대한 응용 프로그램의 사용자 인터페이스를 최적화하고 응용 프로그램이 제대로 렌더링하지만, 각각의 화면에 최상의 사용자 경험을 제공뿐만 아니라 수 있도록 안드로이드 시스템의 기능을 사용할 수 있습니다.
여러 개의 스크린을 위해 사용자 인터페이스를 디자인하는 방법을 단순화하기 위해, 안드로이드는에 실제 화면 크기와 밀도의 범위를 나누어 :
- 네 일반적인 크기의 세트 : 작은 정상, 큰, 그리고 xlarge 참고 : 초보 안드로이드 3.2 (API 레벨 13)로,이 크기 그룹이 사용할 수있는 화면 폭에 따라 화면 크기를 관리하기위한 새로운 기술의 주장을 중지합니다. 안드로이드 3.2 이상을 위해 개발하는 경우를 참조 안드로이드 3.2을위한 태블릿 레이아웃을 선언 자세한 내용은.
- ldpi (낮은), mdpi (중간), hdpi (높은) 및 xhdpi (높은 추가) : 네 개의 일반화 된 밀도의 세트
일반적인 크기와 밀도는 보통 크기와 mdpi (중) 밀도 인 기준 구성 중심으로 정렬되어 있습니다. 이 기준은 최초의 Android 구동 기기의 화면 구성에 기반, HVGA 스크린이있는 T-모바일 G1은 (안드로이드 1.6까지이 유일한 화면 구성이 안드로이드 지원이).
각각의 일반화 크기와 밀도가 실제 화면 크기와 밀도의 범위에 걸쳐. 예를 들어, 두 개의 장치를 모두보고 정상의 화면 크기는 손으로 측정하면 약간 다른 실제 화면 크기와 가로 세로 비율이있을 수 있다는. 마찬가지로, hdpi의 화면 밀도를보고 두 장치가 약간 다른 실제 픽셀 밀도가있을 수 있습니다. 안드로이드는 응용 프로그램에 추상적 이러한 차이를 만들어, 그래서 일반화 된 크기와 밀도위한 UI를 제공하고 시스템이 필요에 따라 모든 최종 조정을 처리 할 수 있도록 할 수 있습니다. 그림 1은 서로 다른 크기와 밀도는 대략 서로 다른 크기와 밀도 그룹으로 분류하는 방법을 보여줍니다.
그림 1. 안드로이드가 대략 일반화 된 크기와 밀도 (수치가 정확한되지 않습니다)에 실제 크기와 밀도를 매핑하는 방법 그림.
다른 화면 크기에 대한 UI를 디자인 한 각각의 디자인 공간의 최소 금액을 요구하는 발견됩니다. 따라서, 각 일반화 된 화면 크기는 위의 시스템에 의해 한정 관련 최소 해상도를 갖추고 있습니다. 시스템이 화면 밀도의 변화에 대한 걱정을 방지 할 수 있습니다 레이아웃 - 어떤 정의 할 때 다음의 최소 크기는 사용한다 "DP"단위 - 동일한 단위입니다.
- xlarge 스크린은 적어도 960dp X 720dp 아르
- 대형 스크린은 적어도 640dp X 480dp 아르
- 일반 화면은 적어도 470dp X 320dp 아르
- 작은 화면은 적어도 426dp X 320dp 아르
참고 :이 최소 화면 크기는뿐만 아니라 사전에 안드로이드 3.0 정의되지 않은하므로 일반 및 대형 사이에 잘못된 분류 된 일부 장치가 발생할 수 있습니다. 이 또한 화면의 물리적 해상도에 따라, 그래서에서 다를 수 있습니다 장치 - 예를 들어 시스템 바 1024x720 태블릿이 실제로이 시스템 바에서 사용중인으로 인해 응용 프로그램을 사용할 수 적은 공간을 조금 있습니다. 아르
다른 화면 크기와 밀도에 대한 응용 프로그램의 UI를 최적화하려면 제공 할 수있는 대체 자원을 일반화 크기와 밀도의하십시오. 일반적으로, 다른 스크린 밀도에 대한 다른 화면 크기와 다른 비트 맵 이미지의 일부 대체 레이아웃을 제공해야합니다. 런타임에서, 시스템은 현재의 디바이스 화면의 일반화 된 크기 나 밀도에 따라, 응용 프로그램에 적합한 리소스를 사용합니다.
화면 크기 및 밀도의 모든 조합에 대한 대체 자원을 제공 할 필요가 없습니다. 시스템은 (같이에 설명이 우아하게 크기를 조절 할 수 있도록 기술을 사용하여 UI를 구현 한 제공하는 장치 화면에서 응용 프로그램을 렌더링 작업의 대부분을 처리 할 수있는 강력한 호환성 기능을 제공 모범 사례 아래).
참고 : 장치의 일반화 된 스크린 크기 및 밀도를 정의하는 특성이 서로 독립적입니다. 의 물리적 크기가 T-모바일 G1 (안드로이드의 첫 번째 장치 및 기본 화면 구성)로에 대한 동일하기 때문에 예를 들어, WVGA 고밀도 화면이 원래 크기 화면을 간주됩니다. 한편, WVGA 중간 밀도 스크린은 대형 화면 간주됩니다. 이 같은 해상도 (픽셀 같은 번호)를 제공하지만, WVGA 중간 밀도 스크린 화면 따라서, 전체 화면 기준 (일반 크기)보다 큰 각 픽셀이 물리적으로 더 큰 것을 의미 낮은 화면 밀도를 가지고 있으며 .
밀도 독립성
다른 밀도로 화면에 표시 할 때 사용자 인터페이스 요소의 물리적 크기를 (보기의 사용자의 입장에서) 보존 할 때 응용 프로그램은 "밀도 독립"을 실현.
그것없이, UI 요소 (예 : 버튼)을 물리적으로 낮은 밀도 화면에 크고 높은 밀도 화면에 작은 표시하기 때문에 밀도 독립성을 유지하는 것이 중요합니다. 이러한 밀도 관련 사이즈 변경 응용 프로그램 레이아웃과 사용성에 문제를 일으킬 수 있습니다. 이 밀도 독립과 때 않으며, 각각을 제공하지 않는 경우도 2 및도 3은 응용 프로그램 사이의 차이점을 보여줍니다.
다른 밀도에 대한 지원없이 그림 2. 예를 들어 응용 프로그램의 낮은, 매체 및 고밀도 화면에 표시.
그림 3.의 낮은, 매체 및 고밀도 화면에 표시된 다른 밀도에 좋은 지원 (그 밀도 독립적입니다)와 예제 응용 프로그램.
: 안드로이드 시스템은 응용 프로그램이 두 가지 방법으로 밀도 독립을 달성하는 데 도움이
- 현재 화면 밀도에 맞게 시스템 저울 DP 단위
- 현재 화면 밀도에 따라 적절한 크기로 시스템 비늘이 drawable 리소스를 필요한 경우
그림 2에서 drawable 텍스트보기 및 비트 맵은 픽셀 (에 지정된 크기를 px 단위), 전망은 물리적으로 낮은 밀도 화면에 크고 높은 밀도 화면에 작은 갖고 있습니다. 이것은 실제 화면 크기가 같은 수 있지만 때문입니다 고밀도 화면 인치 당 더 많은 픽셀 (픽셀의 동일한 금액이 작은 지역에 맞게)이 있습니다. 그림 3에서, 레이아웃 크기는 밀도 독립적 픽셀 (에 명시되어 있습니다 dp 단위). 밀도 독립적 픽셀에 대한 기준은 중간 밀도 스크린이기 때문에이 그림 2에서와 같은 중간 밀도 스크린 장치는 같은 보입니다. 각각 낮은 밀도와 고밀도 스크린을 위해, 그러나, 시스템 비늘은 밀도 독립적 픽셀 값 위쪽 및 아래쪽, 적절하게 화면에 맞게합니다.
대부분의 경우 단순히 밀도 독립적 픽셀 (모든 레이아웃 치수 값을 지정하여 응용 프로그램의 밀도 독립성을 보장 할 수 있습니다 dp 단위) 또는있는 "wrap_content" 적절한. 시스템이 현재 화면의 밀도에 해당하는 크기 조정 요소에 따라 적절한 크기로 적절한 체중 비트 맵 drawables 표시 순서를 유지해야합니다.
그러나, 비트 맵 크기 조절은 위의 스크린 샷에서 발견 할 수 흐릿하거나 pixelated 비트 맵에서 발생할 수 있습니다. 이러한 유물을 방지하기 위해 다른 밀도에 대한 대안 비트 맵 자원을 제공해야합니다. 예를 들어, 고밀도 화면에 높은 해상도의 비트 맵을 제공해야하고 시스템 대신 크기 조정의 그 중간 밀도 스크린을 위해 설계 비트 맵을 사용합니다. 다음 절에서는 서로 다른 화면 구성에 대한 대체 자원을 제공하는 방법에 대해 자세히 설명합니다.
다중 화면을 지원하는 방법
여러 화면에 대한 Android의 지원 기반은 현재 화면 구성을위한 적절한 방법으로 응용 프로그램의 레이아웃 및 비트 맵 drawables의 렌더링을 관리 할 수 있는 능력입니다. 이 시스템은 적절하게, 스크린 밀도에 대한 화면 크기 / 밀도와 확장 비트 맵 drawables에 맞게 확장 레이아웃에 의해 각 화면 구성에 제대로 응용 프로그램을 렌더링 작업의 대부분을 처리합니다. 더 우아하게 다른 화면 구성을 처리 할 그러나, 여러분은해야 :
- 명시 적으로 화면 크기는 응용 프로그램이 지원하는 매니페스트에 선언 어떤 화면 크기의 응용 프로그램이 지원하는 선언하면 지원하는 화면 만 장치 응용 프로그램을 다운로드 할 수 있도록 할 수 있습니다. 다른 화면 크기에 대한 지원을 선언하면 시스템이 응용 프로그램에서 실행 여부, 큰 화면 - 구체적으로 당신의 신청서를 그리는 방법에 영향을 줄 수 있습니다 화면 호환성 모드 .
응용 프로그램이 지원하는 화면 크기를 선언하려면 포함해야 <supports-screens> 매니페스트 파일에 요소를. - 다른 화면 크기에 대해 서로 다른 레이아웃을 제공합니다 기본적으로 안드로이드는 현재 장치 화면에 맞게 응용 프로그램 레이아웃 크기를 조절. 대부분의 경우,이 잘 동작합니다. 다른 경우, UI가 좋은 것처럼 보일지도 서로 다른 화면 크기를 조정해야 할 수도 있습니다. 그 모든 화면에 맞게 할 수 있도록 예를 들어, 큰 화면에 추가 스크린 공간을 활용하는 일부 요소의 위치 및 크기를 조정 할 수도, 또는 작은 화면에 크기를 조정해야 할 수도 있습니다.
크기가 특정 자원을 제공하는 데 사용할 수있는 구성 예선은 small , normal , large , 그리고 xlarge . 예를 들어, 특 대형 화면 레이아웃에 가야 layout-xlarge/ .
안드로이드 3.2 (API 레벨 13)부터, 위의 크기 그룹이 중지되고 대신 사용해야 sw<N>dp 레이아웃 리소스에 필요한 가장 작은 가능한 폭을 정의하는 구성 예선합니다. 멀티 창 태블릿 레이아웃 화면 폭의 최소 600dp를 요구하는 경우 예를 들어, 배치해야 layout-sw600dp/ . 레이아웃 리소스를 선언에 대한 새 기술을 사용하면에 대한 섹션에서 추가로 설명되어 있습니다 안드로이드 3.2을위한 태블릿 레이아웃을 선언 . - 다른 스크린 밀도에 대해 서로 다른 비트 맵 drawables를 제공합니다 기본적으로 안드로이드 비늘하여 비트 맵 drawables ( .png , .jpg , 그리고 .gif 파일)과 아홉 패치 drawables ( .9.png 는 각 장치에 적절한 물리적 크기 렌더링 있도록 파일). 예를 들어, 때 저밀도 화면에서 응용 프로그램이 비트 맵 다음은 기준에 대한 drawables, 중간 화면 밀도 (mdpi), 시스템이 비늘을 최대 고밀도 화면에, 그리고 비늘을 아래로 제공하는 경우. 이 확장은 비트 맵의 유물이 발생할 수 있습니다. 귀하의 비트 맵이 최선을 볼 수 있도록하려면 다른 스크린 밀도에 대해 서로 다른 해상도의 대체 버전을 포함해야합니다.
밀도 특정 자원을 사용할 수있는 구성 예선은 ldpi (저), mdpi (중간), hdpi (높은) 및 xhdpi (높은 추가). 예를 들어, 고밀도 화면에 대한 비트 맵은에 가야 drawable-hdpi/ .
크기와 밀도 구성 예선에 설명 된 일반화 된 크기와 밀도에 해당하는 지원 화면의 범위 위.
참고 : 구성 예선에 익숙하지와 시스템이 대체 자원을 적용하도록 사용하는 방법 경우, 읽기 대체 자원을 제공하는 자세한 내용은.
런타임에서, 시스템은 특정 리소스에 대한 다음과 같은 절차에 현재 화면에 최선의 표시를 보장합니다 :
- 이 시스템은 적절한 대체 자원을 사용 현재 화면의 크기와 밀도에 따라, 시스템은 크기와 응용 프로그램에서 제공 밀도 별 리소스를 사용합니다. 장치가 고밀도 화면을 가지고 있으며 응용 프로그램이 drawable 리소스를 요청한 경우 예를 들어, 시스템은 가장 장치 구성과 일치하는 drawable 리소스 디렉토리를 찾습니다. 사용할 수있는 다른 대체 자원과 자원 디렉토리에 따라 hdpi 예선은 (예 : drawable-hdpi/ ) 가장 일치 될 수, 시스템이 디렉토리에서 drawable 리소스를 사용하므로.
- 일치 리소스를 사용할 수없는 경우 현재 화면 크기 및 밀도에 맞게 필요에 따라, 시스템은 기본 리소스와 비늘 그걸 사용 또는 아래로 "기본"자원 구성 예선 태그가되지 않은 수 있습니다. 예를 들어,의 리소스 drawable/ 기본 drawable 리소스에 있습니다. 이 시스템은 기본 자원 기준 화면의 크기와 일반 화면 크기와 중간 밀도입니다 밀도,을 위해 설계되었습니다 있다고 가정합니다. 이와 같이, 고밀도 스크린을위한 시스템이 저울 기본 밀도 자원을 위, 아래로 낮은 밀도 스크린에, 적절한.
그러나, 시스템이 밀도 특정 리소스에 대해 찾고 있으며, 밀도 특정 디렉토리에서 찾을하지 않을 때, 그것은 항상 기본 리소스를 사용하지 않습니다. 이 시스템은 대신 축소하여보다 나은 결과를 제공하기 위해 다른 밀도 별 리소스 중 하나를 사용할 수 있습니다. 시스템이 쉽게하여 낮은 밀도로 고밀도 자원을 확장 할 수 있기 때문에 예를 들어, 저밀도 자원을 찾고 있으며 사용할 수없는 경우, 시스템은 자원의 고밀도 버전을로 확장 다운 선호 0.5의 요소, 적은 유물과, 0.75의 요소를 기준으로 스케일링 중간 밀도 리소스를 비교.
안드로이드 장치 구성에 구성 예선과 일치하여 대체 자원을 선택하는 방법에 대한 자세한 내용은 다음 페이지를 참조 안드로이드가 가장 일치하는 리소스를 찾습니다 방법 .
구성 예선을 사용하여
안드로이드는 시스템이 현재의 디바이스 스크린의 특성에 따라 대체 자원을 선택하는 방법을 제어 할 수 있도록 여러 가지 구성 예선을 지원합니다. 구성 예선은 귀하 안드로이드 프로젝트에서 리소스 디렉토리에 추가하여 자원이 내부에 설계되어있는 구성을 지정 할 수있는 문자열입니다.
구성 예선을 사용하려면 :
- 프로젝트의에서 새로운 디렉토리를 만들 res/ 디렉토리와 포맷 사용하여 이름 : <resources_name>-<qualifier>
- <resources_name> 표준 리소스 이름 (예입니다 drawable 또는 layout ).
- <qualifier> 이러한 자원 (예 : 사용됩니다되는 화면 구성을 지정, 아래의 표 1에서 구성 예선이 hdpi 또는 xlarge ).
- 더 이상 사용할 수 <qualifier> 대시로 시간을 간단하게 별도의 각 예선에서.
- 이 새로운 디렉토리에 적절한 구성 - 특정 자원을 저장합니다. 리소스 파일은 기본 리소스 파일과 같은 똑같은 이름을 지정해야합니다.
예를 들어, xlarge 초대형 스크린을위한 구성 예선입니다. 리소스 디렉토리 이름 (예 :이 문자열을 추가 할 때 layout-xlarge ), 이러한 자원을 추가 대형 스크린이 장치에 사용할 수 있다는 시스템에 나타냅니다.
표 1. 서로 다른 화면 구성을위한 특별한 자원을 제공 할 수 있도록 구성 예선.
|
화면 특성 |
한정자 |
기술 |
|
크기 |
small |
소형 스크린을위한 자료. |
|
normal |
일반 크기의 스크린을위한 자료. (이 기준 크기입니다.) | |
|
large |
대형 화면을위한 자료. | |
|
xlarge |
특 대형 사이즈의 스크린을위한 자료. | |
|
밀도 |
ldpi |
낮은 밀도 (ldpi) 화면 (~ 120dpi)을위한 자료. |
|
mdpi |
중간 밀도에 대한 자료 (mdpi)는 화면 (~ 160dpi). (이 기준 밀도입니다.) | |
|
hdpi |
고밀도 (hdpi) 화면 (~ 240dpi)을위한 자료. | |
|
xhdpi |
추가 고밀도 (xhdpi) 화면 (~ 320dpi)을위한 자료. | |
|
nodpi |
모든 밀도에 대한 자료. 이러한 밀도 독립적 인 자원입니다. 이 시스템은 규모 리소스에 관계없이 현재 화면의 밀도,이 한정자 태그가 없습니다. | |
|
tvdpi |
약 213dpi, 어디 선가 mdpi와 hdpi 사이의 스크린을위한 자료. 이것은 "주"밀도 그룹으로 간주되지 않습니다. 그것은 주로 텔레비전위한 것입니다 및 대부분의 애플리케이션은 mdpi와 hdpi 자원은 대부분의 응용 프로그램에 대한 충분하고 시스템이 적절한로 크기를 조정합니다 IT-제공 할 필요는 없을 것입니다. 당신이 tvdpi 자원을 제공 할 필요 찾아내는 경우에 크기가 그들에게 1.33 * mdpi의 요소에 해야지. 예를 들어, mdpi 화면에 100px X 100px 이미지가 tvdpi for 133px X 133px해야합니다. | |
|
정위 |
land |
가로 방향으로 화면을위한 자료 (폭 비율). |
|
port |
세로 방향으로 화면을위한 자료 (높이 비율). | |
|
가로 세로 비율 |
long |
기본 화면 구성보다 훨씬 더 큰 또는 더 넓은 화면 비율 (세로 또는 가로 방향으로 각각)가 스크린을위한 자료. |
|
notlong |
기본 화면 구성과 비슷한 가로 세로 비율을 사용 스크린을위한 자료. |
참고 : 안드로이드 3.2 이상에 대한 응용 프로그램을 개발하는 경우에 대해 섹션을 참조하십시오 안드로이드 3.2을위한 태블릿 레이아웃을 선언 특정 화면 크기에 대한 레이아웃 리소스 (대신 크기 예선를 사용하는 선언 할 때 사용해야 새 구성 예선에 대한 정보 에 표 1).
이 예선은 약 실제 화면 크기와 밀도에 해당하는 방법에 대한 자세한 내용은 지원되는 화면의 범위 본 문서의 이전 버전을.
예를 들어, 다음은, 중간 높은, 그리고 여분의 고밀도 화면에 대해 서로 다른 화면 크기와 다른 비트 맵 drawables에 대해 서로 다른 레이아웃 디자인을 제공하는 응용 프로그램의 리소스 디렉토리의 목록입니다.
일반 화면 크기에 해상도 / 레이아웃 / my_layout.xml / / 레이아웃 ( "기본")
작은 화면 크기에 해상도 / 레이아웃 소형 / my_layout.xml / / 레이아웃
큰 화면 크기에 해상도 / 레이아웃 대형 / my_layout.xml / / 레이아웃
고해상도 / 레이아웃 xlarge / 특 대형 화면 크기에 / / 레이아웃을 my_layout.xml
고해상도 / 레이아웃 xlarge-토지 / my_layout.xml / / 레이아웃 가로 방향으로 큰 추가를위한
중간 밀도에 대한 고해상도 / drawable-mdpi / my_icon.png / / 비트 맵
고밀도를위한 고해상도 / drawable-hdpi / my_icon.png / / 비트 맵
추가 고밀도를위한 고해상도 / drawable-xhdpi / my_icon.png / / 비트 맵
대체 자원 및 구성 예선의 전체 목록 (아니라 화면 구성)을 사용하는 방법에 대한 자세한 내용은 대체 자원을 제공 .
주의 자원을 런타임에 사용할 수있는 안드로이드 시스템 추천, 그건 "최고의 검색 '자료를 determing에 특정 논리를 사용하면, 그. 즉, 사용하는 예선 정확히를 사용하는 시스템에 대한 순서로 모든 경우에서 현재 화면 구성과 일치 할 필요가 없습니다. 더 자원이있는 경우 더 잘 일치합니다 (예를 들어, 대형 화면이 정상 크기의 화면 자료를 사용하는 항목이 없을 경우 특히, 크기 예선에 따라 자원을 선택할 때, 시스템은 현재 화면보다 작은 화면을위한 리소스를 사용합니다 필요). 만 사용할 수있는 리소스가 현재 화면보다 큰 경우, 시스템은 다른 자원 장치 구성 (예를 들어, 일치하지 않으면 그들과 응용 프로그램이 충돌 사용하지 않을 모든 레이아웃 리소스로 태그가 지정되는 경우 xlarge 예선하지만, 장치)는 정상 크기의 화면입니다. 시스템 자원을 선택하는 방법에 대한 자세한 내용은 다음 페이지를 참조 안드로이드가 가장 일치하는 리소스를 찾습니다 방법 .
팁 : (이미지 직접 런타임에서 몇 가지 조정을 수행하기 때문에 아마도)는 시스템이 확장되지 않아야 할 몇 가지 drawable 리소스가있는 경우, 당신이있는 디렉토리에 배치해야합니다 nodpi 구성 예선. 이 예선과 자원 밀도 무신론자로 간주되어 시스템을 확장하지 않습니다.
다른 레이아웃과 drawables를 설계
당신이 작성해야합니다 대체 자원의 종류는 응용 프로그램의 요구 사항에 따라 달라집니다. 보통 다른 레이아웃 리소스를 제공하고 다른 비트 맵 drawable 리소스를 제공하는 밀도 예선을 사용하여 크기와 방향 예선을 사용해야합니다.
다음 절은 각각 다른 레이아웃과 drawables를 제 공하기 위해 크기와 밀도 예선를 사용하려면하는 방법을 요약.
다른 레이아웃
일반적으로 다른 화면 구성에서 응용 프로그램을 테스트 일단 다른 화면 크기에 대한 대안 레이아웃을해야하는지 알 수 있습니다. 예를 들면 다음과 같습니다
- 작은 화면에서 테스트를 할 때 레이아웃이 매우 화면에 맞지 않는 것을 발견 할 수 있습니다. 예를 들어, 버튼의 행은 작은 화면 장치 화면의 너비에 맞게하지 않을 수도 있습니다. 이 경우에는 버튼의 크기 나 위치를 조정합니다 작은 화면에 대한 대체 레이아웃을 제공해야합니다.
- 특 대형 화면에 테스트를 할 때 레이아웃을 큰 화면의 효율적 사용하지 않습니다는 것을 될 수도 있고 분명히 그것을 채울 수있을만큼 늘어납니다. 이 경우는 타블렛과 같은 큰 화면에 최적화되어 있습니다 디자인 UI을 제공합니다 여분의 대형 스크린에 대한 대안 레이아웃을 제공해야합니다. 응용 프로그램이 큰 화면에 다른 레이아웃없이 잘 작동해야하지만, 그것이 자신의 장치를 위해 특별히 설계되었습니다 것처럼 응용 프로그램의 모양을하는 사용자에게 매우 중요합니다. UI가 명백하게 늘어되어있는 경우, 사용자는 응용 프로그램 환경 불만 될 가능성이 더 높습니다.
- 그리고 세로 방향에 비해 가로 방향에서 테스트 할 때 세로 방향의 화면 하단에 배치 UI 요소 대신 가로 방향으로 화면의 오른쪽에 있어야합니다 것을 알 수 있습니다.
즉, 확신 할 수 귀하의 응용 프로그램을 레이아웃합니다 :
- 작은 화면에서 맞는 (그래서 사용자가 실제로 응용 프로그램을 사용할 수 있습니다)
- 추가 스크린 공간을 활용하는 더 큰 화면에 최적화되어 있습니다
- 풍경과 인물 방향 모두에 최적화되어 있습니다
귀하의 UI에도 시스템 비늘 레이아웃 (예 : 버튼의 배경 이미지 등) 한 후 뷰의 크기에 맞게 할 필요가 비트 맵을 사용하는 경우에 사용해야 아홉 패치 비트 맵 파일을. 아홉 패치 파일은 기본적으로 stretchable 아르에서 당신이 특정 2 차원 지역 PNG 파일입니다. 시스템이 비트 맵이 사용되는 뷰를 확장해야하는 경우, 시스템은 아홉 패치 비트 맵을 뻗어 있지만 지정된 지역 속합니다. 나인 - 패치 비트 맵 어떤 크기로 조정할 수 있기 때문에 같은 다른 화면 크기에 대해 서로 다른 drawables를 제 공 할 필요가 없습니다. 단, 다른 스크린 밀도에 대한 아홉 패치 파일의 대체 버전을 제공해야합니다.
대체 drawables
그림 4. 각 밀도를 지원하는 비트 맵 drawables에 대한 상대 크기.
거의 모든 응용 프로그램이 시작 아이콘이 그 아이콘이 모든 스크린 밀도에 좋지해야하기 때문에 거의 모든 응용 프로그램은 서로 다른 스크린 밀도에 대한 대안 drawable 리소스가 있어야합니다. 귀하의 응용 프로그램에서 다른 비트 맵 drawables (예 : 응용 프로그램에서 메뉴 아이콘 또는 기타 그래픽 등)를 포함하는 경우 마찬가지로 다른 밀도를 들어, 대체 버전 또는 각 하나를 제공해야합니다.
참고 : 비트 맵 파일에 대한 밀도 별 drawables를 제공하기 위해 필요한 ( .png , .jpg , 또는 .gif 와 아홉 경로 파일 () .9.png ). 모양, 색상, 또는 다른 정의 XML 파일을 사용하는 경우 drawable 리소스를 기본 drawable 디렉토리 (에 하나의 사본을 놓아야합니다 drawable/ ).
다른 밀도에 대한 대안 비트 맵 drawables를 만들려면 4가지 일반화 된 밀도 사이의 3:4:6:8 크기 조정 비율을 따라야합니다. 당신이 중간 밀도 화면 (런처 아이콘의 크기)에 48x48 픽셀입니다 비트 맵 drawable이있는 경우 예를 들어, 모든 다른 크기는 다음과 같아야합니다 :
- 저밀도을위한 36x36
- 중간 밀도에 대한 48x48
- 고밀도를위한 72x72
- 추가 고밀도를위한 96x96
디자인 아이콘에 대한 자세한 내용은 참조 아이콘 디자인 가이드 라인을 같은 런처 아이콘, 메뉴 아이콘, 상태 표시 줄 아이콘 탭 아이콘 등의 다양한 비트 맵 drawables에 대한 크기 정보를 포함.
안드로이드 3.2에 태블릿 레이아웃을 선언
안드로이드 3.0을 실행 태블릿의 첫 번째 세대를 들어, 태블릿 레이아웃을 선언 할 수있는 적절한 방법은있는 디렉토리에 넣어하는 것이 었습니다 xlarge 구성 예선 (예를 들어, res/layout-xlarge/ ). 태블릿 및 화면 크기 - 특히, 7의 다른 유형을 수용하기 위해 "타블렛 - 안드로이드 3.2 이상 이산 화면 크기에 대한 자원을 지정 할 수있는 새로운 방법을 소개합니다. 새로운 기술은 레이아웃에 필요한 공간의 양 (예를 기반으로 폭 600dp), 대신 레이아웃이 일반화 크기 그룹 (예 : 크거나 xlarge 등)에 맞게 만들려고 노력하는 것보다.
태블릿 5 "단말기 (대형 그룹)와 같은 그룹에 기술적으로이 7 설계하는 이유"일반화 된 크기의 그룹을 사용하면 7이 그렇게 할 때 정제가 까다 롭습니다. "이 두 장치가 보이는 크기가 서로 인접 해있는 동안 , 응용 프로그램의 UI위한 공간의 양이 크게 다른 등, 따라서. 7 사용자 상호 작용의 스타일 "와 5"화면이 항상 같은 레이아웃을 사용해서는 안됩니다.이 가능하면이에 대해 서로 다른 레이아웃을 제공 할 수 있도록 화면의 두 종류, 안드로이드는 이제 DP 단위에 지정된 응용 프로그램의 레이아웃에 대해 실제로 사용할 폭 및 / 또는 높이에 따라 레이아웃 리소스를 지정할 수 있습니다.
태블릿 스타일의 기기에 사용할 레이아웃을 설계 한 후 예를 들어 화면보다 600dp 다양한 경우의 레이아웃이 잘 작동을 멈 춥니 다 판단 할 수 있습니다. 이 임계 값은 따라서 귀하의 태블릿 레이아웃 필요한 최소 크기가됩니다. 따라서, 이제 응용 프로그램의 UI에 사용할 폭의 최소 600dp이있는 경우 이러한 레이아웃 리소스 만 사용되어야 지정할 수 있습니다.
여러분은 폭과 디자인 거기에 최소 크기 또는 레이아웃을 한번이 완료 지원하는 가장 작은 폭인지 시험을 선택해야합니다.
참고 : 만약 당신이 걱정하는 것은 시스템 후 사용 가능한 화면 공간의 양이기 때문에 새로운 크기의 API로 사용되는 모든 수치는 밀도 indpendent 픽셀 (DP) 값이며 레이아웃 크기도 항상 DP 단위를 사용하여 정의되어야한다는 것을 기억 화면 밀도를 차지합니다 (원시 픽셀 해상도를 사용하여 반대). 밀도 indpendent 픽셀에 대한 자세한 내용은 다음 페이지를 참조 이용 개념을 이 문서에 이전.
새로운 크기 예선을 사용하여
귀하의 레이아웃에 사용할 수있는 공간에 따라 지정할 수있는 다양한 자원 구성은 표 2에 요약되어있다. 이 새로운 예선은 당신에게 기존의 화면 크기 그룹 (소형, 일반, 대형, 그리고 xlarge)에 비해 응용 프로그램이 지원하는 특정 화면 크기,보다 효과적으로 제어를 제공합니다.
참고 :이 예선을 사용하여 지정하는 크기가 실제 화면 크기 없습니다. 오히려, 크기는 활동의 창에 사용할 수 있습니다 DP 단위의 너비 나 높이가위한 것입니다. 안드로이드 시스템은 시스템 UI (예 : 상단에있는 화면이나 상태 표시 줄의 맨 아래에있는 시스템 표시 줄 등) 화면의 일부를 사용할 수 있으므로 화면의 일부가 레이아웃에 사용할 수 없습니다. 따라서, 당신이 선언의 크기는 레이아웃을 제공 공간이 얼마나 선언 시스템 UI에서 사용하는 공간을 위해 활동 - 시스템 계정에 필요한 크기에 대해 구체적으로해야합니다. 또한 것을 조심 작업 표시 줄이 레이아웃가 선언하지 않습니다 있지만, 응용 프로그램의 창 공간의 일부로 간주됩니다 때문에 레이아웃에 사용할 수있는 공간을 감소시키고 당신의 디자인으로 그것을 설명해야합니다.
화면 크기에 대한 표 2. 새로운 구성 qualifers (안드로이드 3.2에서 소개).
|
화면 구성 |
한정자 값 |
기술 |
|
smallestWidth |
sw<N>dp 예 : sw600dp sw720dp |
화면의 기본 크기는로 사용할 수있는 화면 영역의 짧은 치수로 표시. 특히, 장치의 smallestWidth은 화면의 사용 가능한 높이와 너비의 가장 짧은 것입니다 (이 또한 화면의 "가능한 가장 작은 폭"으로 생 각 될 수 있습니다.) 에 관계없이 화면의 현재 방향, 응용 프로그램의 적어도 가지고 있는지 확인이 예선을 사용할 수 있습니다 <N> 그 UI에 사용할 폭 DPS합니다. 레이아웃 화면 영역의 그 작은 크기가 항상 최소한 600 DP 할 수 있어야합니다 예를 들어, 다음은 레이아웃 리소스를 만들려면이 qualifer를 사용할 수 있습니다 res/layout-sw600dp/ . 사용 가능한 화면의 가장 작은 치수가 적어도 600dp 경우에만 시스템에 관계없이 600dp면이 사용자가 인식 높이 또는 폭인지 여부의 이러한 리소스를 사용합니다. smallestWidth는 장치의 고정 된 화면 크기 특성이며 장치의 smallestWidth는 화면의 방향을 변경하면 변경되지 않습니다. 장치의 smallestWidth은 계정 화면 장식 및 시스템 UI에 걸립니다. 장치가 화면에 몇 가지 영구적 인 UI 요소가있는 경우 예를 들어, smallestWidth의 축을 따라 공간에 대한 계정, 시스템은 이러한 사용자 UI를 사용할 수 없습니다 화면 픽셀이기 때문에 smallestWidth은 실제 화면 크기보다 작은 것으로 선언하는. 이렇게하면 UI에 사용할 수있는 효과적인 크기 이산 번호를 정의 할 수 있습니다 일반화 화면 크기 예선 (소형, 일반, 대형, xlarge)에 대한 대안입니다. 폭은 종종 레이아웃을 디자인의 추진 요인이기 때문에 일반 화면 크기를 결정하는 smallestWidth를 사용하면 유용합니다. UI는 종종 수직 스크롤 있지만, 수평 필요한 최소한의 공간이 매우 어려운 제약을 갖게됩니다. 사용할 수있는 폭은 휴대폰이나 타블렛에 대한 다중 창 레이아웃을 한 창 레이아웃을 사용할지 여부를 결정하는 주요 요소입니다. 따라서 가능성이 가장 작은 가능한 너비는 각 장치에 대해 살펴 보도록하겠습니다 대해 가장 신경. |
|
사용 가능한 화면 너비 |
w<N>dp 예 : w720dp w1024dp |
자원이 사용하는 정의해야되는 DP 단위의 최소 사용 가능한 폭을 지정합니다 <N> 가치를. 화면의 방향은 UI 가능한 현재의 실제 폭을 반영하기 위해 풍경 및 인물 사이의 전환 폭 변화에 대한 시스템의 해당 값입니다. 이렇게하면 경치만큼도 태블릿 장치에서 종종 세로 방향에 대해 동일한 다중 창 레이아웃을 원하는하지 않기 때문에, 다중 창 레이아웃을 사용할지 여부를 결정하는 것이 유용합니다. 따라서, 대신 함께 화면 크기와 방향 예선을 모두 사용하는, 레이아웃에 필요한 최소 너비를 지정하려면이를 사용할 수 있습니다. |
|
사용 가능한 스크린의 높이 |
h<N>dp 예 : h720dp h1024dp 기타 |
자원이 사용하는 정의해야되는 DP 단위의 최소 화면 높이를 지정 <N> 가치를. 화면의 방향은 UI 가능한 현재의 실제 높이를 반영하기 위해 풍경 및 인물 사이의 전환 높이 변화에 대한 시스템의 해당 값입니다. 레이아웃에 필요한 높이를 정의하려면이를 사용하여 같은 방법으로 유용합니다 w<N>dp 대신 화면 크기와 방향 예선을 모두 사용하는, 필요한 폭을 정의하는 것입니다. 그러나 대부분의 응용 프로그램은 폭이 더 엄격한 반면 UIs가 자주, 수직 스크롤 및 높이를 사용할 수 얼마나와 때문에보다 유연하다고 생각이 예선을 필요가 없습니다. |
이러한 예선를 사용하여 화면 크기 그룹을 사용하는 것보다 더 복잡한 것 수 있지만, 사실은 일단 당신이 당신의 UI에 대한 요구 사항을 결정 간단해야합니다. UI를 디자인 할 때 아마도 신경 중요한 것은 실제 크기입니다에서 단말기 스타일의 UI와 여러 창을 사용하는 태블릿 스타일의 UI 사이의 응용 프로그램 스위치. 이 스위치의 정확한 포인트는 디자인 어쩌면 720dp 태블릿 레이아웃의 너비, 어쩌면 600dp 충분, 또는 480dp, 또는 이들 사이의 번호가 필요합니다 특정에 따라 달라집니다. 표 2에 이러한 예선를 사용하면 정확한 크기에서 레이아웃 변경 관리에 있습니다.
이러한 크기 구성 예선에 대한 자세한 내용을 보려면 참조 제공하는 자료 문서를.
구성 예
여기에, 장치의 다른 유형을 위해 디자인의 일부를 타겟팅 할 수 있도록하려면 일반적으로 화면 폭을위한 숫자입니다 :
- 320dp : 일반 전화 화면 (240x320 ldpi, mdpi 320x480, 480x800 hdpi 등).
- 480dp : 승리처럼 왕따 타블렛 (480x800 mdpi).
- 600dp : 7 "타블렛 (600x1024 mdpi).
- 720dp : 10 "타블렛 (720x1280 mdpi, 800x1280 mdpi 등).
표 2에서 크기 예선 사용하여 응용 프로그램은 폭 및 / 또는 높이에 대해 원하는 번호를 사용하여 단말기와 태블릿에 대한 다른 레이아웃 리소스 사이를 전환 할 수 있습니다. 600dp이 태블릿 레이아웃에서 지원하는 가장 작은 가능한 폭 경우 예를 들어 레이아웃의 두 세트를 제공 할 수 있습니다 :
고해상도 / 레이아웃 / 휴대 전화 용 # main_activity.xml
타블렛은 # res/layout-sw600dp/main_activity.xml
이 경우 사용 가능한 화면 공간의 가장 작은 폭 적용 할 태블릿 레이아웃하기 위해서는 600dp해야합니다.
당신이 더 예 : 7과 같은 크기 "및 10"태블릿을 구별하기 위해 UI를 사용자 정의 할 다른 경우는, 추가 작은 폭 레이아웃을 정의 할 수 있습니다 :
고해상도 / 레이아웃 / 휴대 전화 (작은 것보다 600dp 가능한 폭)의 경우 # main_activity.xml
7 "정제 (폭 600dp와 더 큰)의 경우 # res/layout-sw600dp/main_activity.xml
# 10 "정제 용 res/layout-sw720dp/main_activity.xml (720dp 폭 커)
예를 들어 자원의 이전 두 세트는 "작은 폭"qualifer 사용납니다 sw<N>dp 에 관계없이 장치의 현재 방향의 화면의 두 측면의 작은을 지정. 따라서, 사용하는 sw<N>dp 화면의 방향을 무시하여 레이아웃에 사용할 수있는 전체 화면 크기를 지정하는 간단한 방법입니다.
레이아웃 정확히 얼마나 폭 또는 높이가 현재 이용이 가능합니다에 대한 그러나, 몇몇 경우에, 중요한 일 수 있습니다. 두 조각 나란히있는 두 창 레이아웃이있는 경우 예를 들어 화면 장치가 가로 또는 세로 방향에 있는지, 폭 최소 600dp를 제공 할 때마다 그것을 사용 할 수 있습니다. 이 경우, 자원은 다음과 같이 보일 수 있습니다 :
고해상도 / 레이아웃 / 휴대 전화 (작은 것보다 600dp 가능한 폭)의 경우 # main_activity.xml
# 멀티 창 (600dp 가능한 폭 이상이있는 화면) res/layout-w600dp/main_activity.xml
두 번째 세트는 "가능한 폭"예선 사용되는지 확인합니다 w<N>dp . 이 방법은 하나의 장치는 실제로 화면의 방향에 따라 두 레이아웃을 사용할 수 있습니다 (가능한 폭은 한 방향으로 최소 600dp와 다른 방향으로보다 600dp 경우).
사용할 수있는 높이가 당신을 위해 관심사 경우에는 사용하여 동일한 작업을 수행 할 수 있습니다 h<N>dp 예선을. 또는 심지어 결합 w<N>dp 와 h<N>dp 당신이 정말로 구체적으로해야하는 경우 예선합니다.
화면 크기를 지원 선언
일단 다른 화면 크기에 대한 레이아웃을 구현 한 응용 프로그램이 지원하는 심사 매니페스트 파일에 선언 똑같이 중요합니다.
화면 크기에 대한 새 구성 예선과 함께, 안드로이드 3.2을위한 새로운 속성을 도입 <supports-screens> 매니페스트 요소 :
android:requiresSmallestWidthDp
최소 smallestWidth가 필요합니다 지정합니다. smallestWidth는 화면 공간 (에서의 짧은 치수입니다 dp 응용 프로그램 UI - 즉, 사용 가능한 화면의 2 차원 중 가장 짧은 것입니다 사용할 수 있어야합니다 단위). 따라서 응용 프로그램과 호환 간주 될 수있는 장치에 대한 위해 장치의 smallestWidth가 같거나이 값보다 커야합니다. (보통,이에 대한 공급의 값에 관계없이 화면의 현재 방향, 레이아웃에서 지원하는 "작은 폭"입니다.)
예를 들어, 응용 프로그램이 600dp 작은 가능한 폭 태블릿 스타일의 기기에 해당되는 경우 :
<참고 ... >
<supports-screens android:requiresSmallestWidthDp="600" />
...
</ 매니페스트>
응용 프로그램이 안드로이드 (426dp X 320dp처럼 작은)에서 지원하는 모든 화면 크기를 지원하는 경우 응용 프로그램이 필요로하는 작은 폭 어떤 장치에 가장 작은 수 있기 때문에 그러나, 다음이 속성을 선언 할 필요가 없습니다.
주의 : Android 시스템이 속성에주의를 지불하지 않기 때문에 귀하의 응용 프로그램이 런타임에 작동 방법에 영향을 미치지 않습니다. 대신, 그것은 예 : Google 재생 등의 서비스에 응용 프로그램에 대한 필터링 활성화하는 데 사용됩니다. 그러나 Google 플레이는 현재 (안드로이드 3.2)에 필터링이 속성을 지원하지 않기 때문에 응용 프로그램이 작은 화면을 지원하지 않는 경우는 다른 크기 속성을 계속 사용합니다.
android:compatibleWidthLimitDp
이 속성은 사용 할 수 있습니다 화면 호환성 모드 응용 프로그램이 지원하는 최대 "작은 폭"을 지정하여 사용자 선택 기능으로합니다. 장치의 사용 가능한 화면의 가장 작은면이 여기 값보다 크면 사용자는 여전히 응용 프로그램을 설치할 수 있지만, 화면 호환성 모드에서 실행 이용하실 수 있습니다. 기본적으로 화면 호환성 모드가 비활성화되고 레이아웃은 평상시와 같이 화면에 맞게 크기가 조정되어 있지만, 버튼은 사용자가 화면 호환성 모드를 설정하거나 해제하도록 전환 할 수있는 시스템 바에서 사용할 수 있습니다.
참고 : 응용 프로그램의 레이아웃이 제대로 대형 스크린에 대한 크기를 조정하는 경우이 속성을 사용할 필요가 없습니다. 우리는이 속성을 사용하지 않도록하고 대신이 문서에 권장 사항을 따라 큰 화면에 대한 레이아웃 크기를 조절되도록하는 것이 좋습니다.
이 속성은 강제로 활성화 할 수 있도록 화면 호환성 모드를 응용 프로그램이 지원하는 최대 "작은 폭"을 지정하여. 장치의 사용 가능한 화면의 가장 작은면이 여기 값보다 큰 경우, 응용 프로그램을 비활성화 할 수있는 사용자에 대한 어떠한 방식으로 화면 호환성 모드에서 실행됩니다.
참고 : 응용 프로그램의 레이아웃이 제대로 대형 스크린에 대한 크기를 조정하는 경우이 속성을 사용할 필요가 없습니다. 우리는이 속성을 사용하지 않도록하고 대신이 문서에 권장 사항을 따라 큰 화면에 대한 레이아웃 크기를 조절되도록하는 것이 좋습니다.
주의 : 안드로이드 3.2 이상을 개발하면 위에서 열거 한 속성과 함께 이전 화면 크기 속성을 사용하면 안됩니다. 새로운 특성과 기존의 크기 속성을 모두 사용하면 예기치 않은 동작이 발생할 수 있습니다.
이러한 속성의 각에 대한 자세한 내용을 보려면 위의 각각의 링크를 따르십시오.
우수 사례
여러 화면을 지원의 목적은 제대로 작동하고 안드로이드에서 지원하는 일반화 된 화면 구성의 잘 어울릴 수있는 응용 프로그램을 만드는 것입니다. 이 문서의 이전 섹션은 안드로이드 화면 구성에 응용 프로그램을 적응하고 어떻게 다른 화면 구성에서 응용 프로그램의 모양을 사용자 정의 할 수있는 방법에 대한 정보를 제공합니다. 이 섹션 데 도움이 몇 가지 추가 도움말 및 기술에 대한 개요를 제공하는 다른 화면 구성에 대한 적절한 응용 프로그램 비늘.
다음은 응용 프로그램이 서로 다른 화면에 제대로 표시되도록 할 수있는 방법에 대한 간단한 체크리스트는 다음과 같습니다
- 사용 wrap_content , fill_parent , 또는 dp XML 레이아웃 파일에 크기를 지정할 때 단위를
- 응용 프로그램 코드에 하드 코딩 픽셀 값을 사용하지 마십시오
- 사용하지 마십시오 AbsoluteLayout (가 중지됨있어)
- 다른 스크린 밀도에 대한 대안 비트 맵 drawables 공급
다음 섹션에서는 자세한 내용을 제공합니다.
1. 레이아웃 크기에 wrap_content, fill_parent 또는 DP 단위를 사용
정의 할 때 android:layout_width 와 android:layout_height 사용하여 XML 레이아웃 파일에 전망에 대해 "wrap_content" , "fill_parent" 또는 dp 보기가 현재의 디바이스 화면에 적절한 크기를 부여하는 단위 보장.
예를 들어,있는 전망 layout_width="100dp" 보기가 화면에 거의 동일한 물리적 공간을 차지하므로, 고밀도 화면에 150 픽셀 폭에 최대 중간 밀도 스크린에 100 픽셀 (폭)를 측정하고 시스템의 비늘 .
마찬가지로 원하는해야 sp (규모 독립적 인 픽셀) 텍스트 크기를 정의 할 수 있습니다. sp 규모 계수는 사용자 설정과 시스템 비늘이를 위해서 같은 같은 크기에 따라 달라집니다 dp .
2. 응용 프로그램 코드에 하드 코딩 된 픽셀 값을 사용하지 마십시오
성능 향상을 위해와 코드가 단순하게하기 위해, 안드로이드 시스템은 크기 나 좌표 값을 표현하는 표준 단위로 픽셀을 사용합니다. 그건 뷰의 크기는 항상 픽셀을 사용하여 코드로 표현하지만, 항상 현재 화면 밀도를 기반으로합니다 것을 의미합니다. 경우 예를 들어, myView.getWidth() 10을 반환,보기는 현재 화면에 10 픽셀 폭이지만, 높은 밀도 화면 장치에 표시되는 값은 15이 될 수 있습니다. 현재 화면 밀도에 대한 사전 조정되지 않는 비트 맵 작동하도록 응용 프로그램 코드에서 픽셀 값을 사용하는 경우 유엔 규모 비트 맵 소스를 일치하도록 코드에서 사용하는 픽셀 값을 확장해야 할 수도 있습니다.
응용 프로그램이 비트 맵 또는 런타임에 픽셀 값으로 거래를 조작하는 경우에 대한 다음 섹션 참조 추가 밀도 고려 사항을 .
3. AbsoluteLayout를 사용하지 마십시오
다른 레이아웃 위젯과는 달리, AbsoluteLayout 쉽게 다른 디스플레이에서 제대로 작동하지 않는 사용자 인터페이스로 이어질 수 하위 전망을 배치하는 고정 위치의 사용을 적용합니다. 이 때문에 AbsoluteLayout 안드로이드 1.5 (API 레벨 3)에 사용 중지되었습니다.
대신 사용해야합니다 RelativeLayout 하위 전망을 배치 할 상대 위치를 사용. 예를 들어, 버튼 위젯은 텍스트 위젯 "의 오른쪽에있는"나타납니다 지정할 수 있습니다.
4. 크기 및 밀도 별 리소스를 사용하여
시스템이 비늘 레이아웃하고 현재의 화면 구성을 기반으로 drawable 리소스에 있지만, 서로 다른 화면 크기에 UI를 조정하고 다른 밀도에 최적화 된 비트 맵 drawables를 제 공 할 수 있습니다. 이 본질적으로이 문서의 이전의 정보를 한나.
귀하의 응용 프로그램이 다양한 화면 구성에서 표시 될 모양을 정확하게 제어해야하는 경우, 구성 - 특정 리소스 디렉토리에 레이아웃과 비트 맵 drawables를 조정합니다. 예를 들어, 중간 및 높은 밀도 화면에 표시 할 아이콘을 고려해보십시오. 간단하게 두 개의 서로 다른 크기 (고밀도에 대한 중간 밀도와 150x150에 대한 예를 들어 100x100의 경우)에서 아이콘을 만들고 적절한 예선을 사용하여 해당 디렉토리에 두 변형을 넣어 :
중간 밀도 스크린에 해상도 / drawable-mdpi / icon.png / /
고밀도 스크린에 해상도 / drawable-hdpi / icon.png / /
참고 : 밀도 예선에 디렉토리 이름에 정의되어 있지 않은 경우, 시스템이 해당 디렉토리에 자원이 기준 중간 밀도 위해 설계되었습니다 있다고 가정하고 적절한와 같은 다른 밀도에 확장됩니다.
유효한 구성 예선에 대한 자세한 내용은 구성 예선을 사용하여 이전에이 문서에.
추가 밀도 고려 사항
이 섹션에서는 안드로이드가 다른 화면 밀도에 그리고 더 이상 비트 맵이 서로 다른 밀도에 그려진되는 방식을 제어 할 수 있습니다 비트 맵 drawables에 대한 확장을 수행하는 방법에 대한 자세한 내용을 설명합니다. 다른 화면 밀도 또는 응용 프로그램에 그래픽을 조작에서 실행시 사용자가 자신의 응용 프로그램에서 문제가 발생하지 않는 한이 섹션의 정보는 대부분의 응용 프로그램에 중요한 안됩니다.
더 나은 런타임에 그래픽을 조작 할 때 여러 밀도를 지원할 수있는 방법을 이해하려면 시스템이 다음과 같은 방법으로 비트 맵에 대한 적절한 규모를 극대화 할 수 있습니다 이해합니다 :
- 자원의 사전 스케일링 (예 : 비트 맵 drawables 등) 현재 화면의 밀도에 따라, 시스템은 응용 프로그램에서 모든 크기 또는 밀도 별 리소스를 사용 및 확장없이 표시됩니다. 자원 올바른 밀도에서 사용할 수없는 경우, 시스템은 현재 화면의 밀도에 맞게 필요에 따라 기본 자원과 비늘을 위로 또는 아래로를로드합니다. 이 시스템은 그들이 밀도 별 리소스 디렉토리에서로드하지 않는 기본 자원 (구성 예선이없는 디렉토리에서 해당), 기준 화면 밀도 (mdpi)을 위해 설계되었습니다 있다고 가정합니다. 사전 스케일링 할 때 크기를 현재 화면 밀도에 해당하는 크기로 비트 맵 시스템이 무엇을, 따라서이다.
당신이 사전에 스케일 자원의 크기를 요청하는 경우, 시스템은 확장 후 크기를 나타내는 값을 반환합니다. 예를 들어, mdpi 화면에 50x50 픽셀로 디자인 된 비트 맵은 hdpi 화면에서 75x75 픽셀 (hdpi에 대한 대체 자원이없는 경우)에 따라 결정되며 시스템은 다음과 같은 크기를보고합니다.
당신이 사전에 대규모 리소스에 안드로이드 원하지 않을 수있는 몇 가지 상황이 있습니다. 미리 스케일링을 방지하는 가장 쉬운 방법은있는 자원 디렉토리에 리소스를 넣어하는 것입니다 nodpi 구성 예선. 예를 들면 다음과 같습니다
고해상도 / drawable-nodpi / icon.png
시스템이 사용하면 icon.png 이 폴더에서 비트 맵, 그것은 현재 장치 밀도에 따라 그 크기를 조정하지 않습니다. - 픽셀 크기와 좌표의 자동 스케일링 응용 프로그램 설정에서 미리 스케일링을 해제 할 수 있습니다 android:anyDensity 에 "false" 에 대한 프로그램 매니페스트 나에 Bitmap 설정하여 inScaled 에 "false" . 이 경우, 시스템은 자동 저울 그리기 시간에 어떤 절대 픽셀 좌표 및 픽셀 치수 값. 그 사람들이 기본 화면 밀도 (mdpi)에있을 것 같은 픽셀 정의 된 화면 요소가 여전히 거의 동일한 실제 크기에 표시되는 것을 보장하기 위해이 작업을 수행합니다. 시스템은 응용 프로그램에 투명하게이 스케일링을 처리하고 대신 실제 픽셀 크기보다 응용 프로그램에 조정 된 픽셀 크기를보고합니다.
예를 들어, 장치가 480x800과 전통적인 HVGA 화면과 같은 크기 인 WVGA 고밀도 스크린을 가지고 있지요하지만 제가 미리 스케일링을 사용 중지했습니다 응용 프로그램을 실행하는거야. 이 경우, 시스템은 응용 프로그램에 "거짓말"할 때 화면 크기에 대한 쿼리 및 보고서 320x533 (화면 밀도에 대한 대략적인 mdpi 번역). 그런 다음, 응용 프로그램이 (100, 100)에에서 사각형 (10,10)를 무용으로 작업을 그리기 않을 경우, 시스템은 확장 그들에게 적절한 양을하여 좌표를 변환하고, 실제로 지역 (15,15)로 무효화 (150, 150). 응용 프로그램이 직접 스케일 비트 맵을 조작 있지만, 이것은 가능한 한 좋은대로 응용 프로그램의 성능을 유지하기 트레이드 오프 합리적인 것으로 간주하는 경우 이러한 불일치는 예기치 않은 문제가 발생할 수 있습니다. 이 상황을 발생하는 경우에 대해 다음 섹션을 읽어 픽셀 단위로 DP 단위를 변환을 .
보통 사전 크기 조절을 사용해서는 안됩니다. 여러 화면을 지원하는 가장 좋은 방법은 위 설명 된 기본 기술을 따라하는 것입니다 여러 화면을 지원하는 방법을 .
응용 프로그램이 비트 맵을 조작하거나 다른 방법으로 화면에 픽셀과 상호 작용하는 경우 다른 스크린 밀도를 지원하기 위해 추가 단계를 수행해야 할 수도 있습니다. 니가 손가락이 교차하는 픽셀의 수를 계산하여 동작을 터치에 응답하는 경우 예를 들어, 적절한 밀도 독립적 픽셀 값 대신 실제 픽셀을 사용해야합니다.
런타임에서 생성 스케일링 비트 맵 객체
그림 5.에서 사전에 스케일 및 자동 스케일 비트 맵의 비교, ApiDemos .
응용 프로그램에서 메모리 비트 맵을 (만드는 경우 Bitmap 개체) 추첨 시간에 비트 맵, 시스템은 비트 맵은 기본적으로 기준 중간 밀도 스크린을 위해 설계되어 있다고 가정하고, 자동 저울. 시스템에 "자동 크기 조절"을 적용 Bitmap 비트 맵이 지정되지 않은 밀도 속성을 가질 때. 현재 장치의 스크린 밀도에 맞게 계정을하지 않고 비트 맵의 밀도 속성을 지정하면 자동 크기 조절은 대체 자원을 제공하지 않는 경우와 동일한 크기 조절 유물이 발생할 수 있습니다.
할지 여부를 제어 할 Bitmap 런타임에서 생성이 확장되지 않았거나 다음과 같은 비트 맵의 밀도 지정할 수 있습니다 setDensity() 에서 상수 밀도를 전달, DisplayMetrics 같은 DENSITY_HIGH 또는 DENSITY_LOW .
당신이 만드는 경우 Bitmap 사용 BitmapFactory 같은 파일 또는 스트림에서로를 사용할 수 있습니다 BitmapFactory.Options 이미 존재하는 시스템을 확장 할 경우 또는 방법을 결정하는 비트 맵의 속성을 정의 할 수 있습니다. 예를 들어 사용할 수 있습니다 inDensity 비트 맵을 설계하는 밀도와 정의 필드를 inScaled 비트 맵은 현재 장치의 스크린 밀도에 맞게 크기를 조정할지 여부를 지정 필드를.
당신이 설정하는 경우 inScaled 에 필드에 false 한 다음 시스템이 비트 맵과 시스템 추첨 시간에 의지 한 후 자동 규모 여기에 적용 할 수있는 미리 스케일링을 해제합니다. 대신 사전 스케일링의 자동 크기 조절을 사용하면 비용이 더 CPU 수 있지만, 적은 메모리를 사용 할 수 있습니다.
(120) 낮은 중간 (160)과 고밀도 화면에 높은 (240) 밀도 비트 맵을로드 할 때 그림 5는 사전 규모와 자동 규모 메커니즘의 결과를 보여줍니다. 비트 맵의 모든 그러나 스케일 비트 맵들이 추첨 할 때 사전 스케일 또는 자동 조정됩니다 여부에 따라 약간 다른 모습을 가지고, 현재의 화면 밀도에 맞게 크기를 조정하고 있기 때문에 차이는 미묘합니다. 귀하는 사전 스케일 및 자동 스케일 비트 맵을 사용하여 설명이 샘플 응용 프로그램의 소스 코드를 찾을 수 있습니다 ApiDemos .
참고 : 위의 안드로이드 3.0에서 그래픽 프레임 워크의 개선으로 인해 사전에 스케일 및 자동 스케일 비트 맵을 사이에인지 할 수있는 차이,이 없어야합니다.
픽셀 단위로 DP 단위를 변환
어떤 경우에는 크기 표현해야합니다 dp 하고 픽셀로 변환합니다. 사용자의 손가락이 최소 16 픽셀 이동 한 후 스크롤이나 실컷 제스처가 인식되는 응용 프로그램을 상상해보십시오. 기준 화면에서 사용자의 방법으로 이동해야합니다 16 pixels / 160 dpi 제스처가 인식되기 전에 인치 (또는 2.5 mm)의 1/10th 같습니다. 고밀도 디스플레이 (240dpi)와 장치에서 사용자의 방법으로 이동해야합니다 16 pixels / 240 dpi 인치 (또는 1.7 mm)의 1/15th 같습니다. 거리가 훨씬 짧은하며 응용 프로그램은 따라서 사용자에게 더 민감 나타납니다.
이 문제를 해결하려면 동작 임계 값의 코드로 표현해야 dp 하고 실제 픽셀로 변환. 예를 들면 다음과 같습니다
/ / 동작 임계 값은 DP로 표시
개인 정적 최종 플로트 GESTURE_THRESHOLD_DP = 16.0f;
/ /은 화면의 밀도 규모를 가져 오기
최종 플로트 규모 = getResources() . getDisplayMetrics() 밀도.;
/ / 밀도 규모에 따라 픽셀로 DPS를 변환
mGestureThreshold = (INT) (GESTURE_THRESHOLD_DP * 스케일 + 0.5f);
/ / 픽셀 거리로 mGestureThreshold 사용 ...
DisplayMetrics.density 필드를 변환하는 데 사용할해야 규모의 요소를 지정 dp 현재 화면 밀도에 따라, 픽셀 단위. 중간 밀도의 화면에서 DisplayMetrics.density 1.0을 동일, 고밀도 화면에 그 1.5를 동일, 추가 고밀도 화면에, 그것은 2.0을 동일하고, 낮은 밀도 화면에, 그것은 0.75와 같습니다. 이 수치는 곱해야하는이 요소 dp 현재 화면의 실제 픽셀 수를 얻을 주문 단위를. (그런 다음 추가 0.5f 정수로 변환 할 때, 가장 가까운 정수로 그림을 반올림합니다.) 자세한 내용은을 참조 DisplayMetrics 클래스입니다.
대신 이벤트의 종류 임의의 임계 값을 정의하지만 에서 구할 수 있습니다 사전 규모의 구성 값 사용해야합니다 ViewConfiguration .
사전 조정 된 구성 값을 사용하여
사용할 수 있습니다 ViewConfiguration 안드로이드 시스템에서 사용하는 일반적인 거리, 속도 및 시간을 액세스 할 수 클래스를. 예를 들어, 스크롤 임계 값과 같은 프레임 워크에서 사용하는 픽셀 단위의 거리를 함께 얻을 수 getScaledTouchSlop() :
. 개인 정적 최종 INT GESTURE_THRESHOLD_DP = ViewConfiguration.get (myContext) getScaledTouchSlop ();
의 방법 ViewConfiguration 로 시작 getScaled 접두사가 제대로 관계없이 현재 화면 밀도 표시됩니다 픽셀 단위로 값을 반환 받으실 수 있습니다.
여러 화면에서 응용 프로그램을 테스트하는 방법
그림 6. 화면 지원을 테스트하기 위해 AVDS의 집합입니다.
응용 프로그램을 게시하기 전에 철저하게 지원되는 화면 크기와 밀도의에서 테스트해야합니다. 안드로이드 SDK는 응용 프로그램이 실행 가능성이있는 일반적인 화면 구성의 크기와 밀도를 복제하는 사용할 수있는 에뮬레이터 스킨이 포함되어 있습니다. 또한 기본 크기, 밀도, 그리고 특정 화면의 특성을 복제 할 수있는 에뮬레이터 스킨의 해상도를 수정할 수 있습니다. 에뮬레이터 스킨 및 추가 사용자 정의 구성을 사용하면 어떤 가능한 화면 구성을 테스트 할 수 있습니다, 그래서 응용 프로그램의 화면 지원을 테스트하는 다양한 장치를 구입할 필요가 없습니다.
응용 프로그램의 화면을 지원 테스트 환경을 설정하려면 응용 프로그램이 지원하고자하는 화면 크기와 밀도를 에뮬레이션 에뮬레이터 스킨 및 화면 구성을 사용하여, AVDS (안드로이드 가상 장치)의 일련를 작성해야합니다. 이렇게하려면 AVDS를 생성하고 그래픽 인터페이스를 실행하는 AVD Manager를 사용할 수 있습니다.
안드로이드 SDK Manager를 실행하려면 실행 SDK Manager.exe 귀하의 안드로이드 SDK 디렉토리에서 (Windows에서만) 또는 실행 android 에서 <sdk>/tools/ 디렉토리 (모든 플랫폼에서). 그림 6은 다양한 화면 구성을 테스트, AVDS의 선택으로 AVD Manager를 보여줍니다.
표 3은 가장 일반적인 화면 구성의 일부를 에뮬레이트하는 데 사용할 수있는 안드로이드 SDK에서 사용할 수있는 다양한 에뮬레이터 스킨을 보여줍니다.
만들고 응용 프로그램을 테스트 할 AVDS를 사용하는 방법에 대한 자세한 내용은 AVD Manager와 AVDS 관리 .
표 3. 안드로이드 SDK에서 에뮬레이터 스킨 (굵은 글씨로 표시) 및 기타 담당자 해상도에서 제공 다양한 화면 구성.
|
|
낮은 밀도 (120), ldpi |
중간 밀도 (160), mdpi |
고밀도 (240) hdpi |
추가 고밀도 (320), xhdpi |
|
작은 화면 |
QVGA (240x320) |
|
480x640 |
|
|
일반 화면 |
WQVGA400 (240x400) WQVGA432 (240x432) |
HVGA (320x480) |
WVGA800 (480x800) WVGA854 (480x854) 600x1024 |
640x960 |
|
대형 스크린 |
WVGA800 ** (480x800) WVGA854 ** (480x854) |
WVGA800 * (480x800) WVGA854 * (480x854) 600x1024 |
|
|
|
추가 대형 스크린 |
1024x600 |
WXGA (1280x800) † 가 1024x768 1280x768 |
1536x1152 1920x1152 1920x1200 |
2048x1536 2560x1536 2560x1600 |
|
* WVGA800 또는 WVGA854 피부를 사용하는 AVD를 만들 때이 구성을 에뮬레이트하려면 160 사용자 정의 밀도를 지정합니다. ** WVGA800 또는 WVGA854 피부를 사용하는 AVD를 만들 때이 구성을 에뮬레이트하려면 (120)의 사용자 정의 밀도를 지정합니다. †이 피부는 안드로이드 3.0 플랫폼에서 사용할 수 있습니다 | ||||
특정 화면 구성을 지원중인 장치의 상대 번호를 확인하려면 확인 화면 크기와 밀도의 대시 보드를.
그림 7. 크기와 AVD Manager에서 AVD를 시작 밀도가 설정할 수 있습니다 옵션.
또한 밀접하게 실제 장치를 일치하는 실제 크기로 실행하도록 설정되어 에뮬레이터에서 응용 프로그램을 테스트하는 것이 좋습니다. 이렇게하면 더 쉽게 다양한 크기와 밀도에 결과를 비교 할 수 있습니다. 귀하의 컴퓨터 모니터의 DPI의 대략적인 밀도를, 알 필요가 이렇게하려면 (예를 들어, 30 "델 모니터가 96에 대한 DPI의 밀도를 있습니다.)이 AVD Manager에서 AVD를 실행하면 지정할 수 있습니다 그림 7에 표시된 시작 옵션에서 에뮬레이터 및 모니터 DPI에 대한 화면 크기.
내장 된 스킨에서 지원하지 않는 해상도 나 밀도를 사용하는 화면에서 응용 프로그램을 테스트하려는 경우 사용자 정의 해상도 나 밀도를 사용하는 AVD를 만들 수 있습니다. AVD Manager에서 AVD를 생성하면, 대신 내장 스킨을 선택하는, 해상도를 지정합니다.
커맨드 라인에서 AVD를 실행하는 경우와 에뮬레이터의 규모를 지정할 수 있습니다 -scale 옵션을 선택합니다. 예를 들면 다음과 같습니다
에뮬레이터 - avd <avd_name> 규모의 96dpi
에뮬레이터의 크기를 조정하려면 대신 전달할 수 -scale 옵션에게 원하는 크기(0.1~3 사이)조정 요소를 나타냅니다.
원문: http://developer.android.com/guide/practices/screens_support.html
'안드로이드 개발 > Design' 카테고리의 다른 글
| 안드로이드 앱 개발자가 제안하는 디자인 방법론 - 1. 나인패치(Nine-patch) 개념 (14) | 2013.02.28 |
|---|---|
| 해상도별 레이아웃 처리 (0) | 2012.09.25 |
| Android 해상도 단위 관련 Dip (0) | 2012.07.30 |
