이미지나 문자열과 같은 애플리케이션 리소스는 항상 코드에서 외부화해야 합니다. 그래야 이들을 독립적으로 유지관리할 수 있습니다. 특정 기기 구성에 대한 대체 리소스도 제공해야 합니다. 이것은 특별하게 명명한 리소스 디렉터리에 그룹화하는 방법을 씁니다. Android는 런타임에 현재 구성을 근거로 적절한 리소스를 사용합니다. 예를 들어 여러 가지 화면 크기에 따라 여러 가지 UI 레이아웃을 제공하거나 언어 설정에 따라 각기 다른 문자열을 제공하고자 할 수 있습니다.
애플리케이션 리소스를 외부화하면
프로젝트의 R 클래스에서 생성된 리소스 ID를 사용하여 이러한 리소스에 액세스할 수 있습니다. 애플리케이션에서
리소스를 사용하는 방법은 리소스
액세스에서 설명합니다. 이 문서에서는 Android 프로젝트에서 리소스를 그룹화하는 방법과 특정 기기 구성에 대한
대체 리소스를 제공하는 방법을 보여드립니다.
리소스 유형 그룹화
프로젝트의
res/ 디렉터리에 속한 특정 하위 디렉터리에 각 유형의 리소스를 배치해야 합니다. 예를 들어, 다음은 간단한 프로젝트의 파일 계층입니다.
MyProject/
src/
MyActivity.java
res/
drawable/
graphic.png
layout/
main.xml
info.xml
mipmap/
icon.png
values/
strings.xml
이 예시에서 res/ 디렉터리가 모든 리소스(이미지 리소스 한 개, 레이아웃 리소스 두 개, 런처 아이콘용 mipmap/ 디렉터리,
문자열 리소스 파일 한 개)를 하위 디렉터리에
포함하는 것을 볼 수 있습니다. 리소스 디렉터리 이름은
중요하며 표1에 설명되어 있습니다.
참고: Mipmap 폴더를 사용하는 자세한 방법은 프로젝트 관리 개요를 참조하세요.
표 1. 프로젝트 res/ 디렉터리 내부에서 지원되는
리소스 디렉터리.
| 디렉터리 | 리소스 유형 |
|---|---|
animator/ |
속성 애니메이션을 정의하는 XML 파일입니다. |
anim/ |
tween
애니메이션을 정의하는 XML 파일입니다. (속성 애니메이션도 이 디렉터리에 저장할 수 있지만
두 가지 유형을 구분하기 위해 속성 애니메이션은
animator/ 디렉터리에 저장하는 것이 좋습니다.) |
color/ |
색상의 상태 목록을 정의하는 XML 파일입니다. 색상 상태 목록 리소스를 참조하세요. |
drawable/ |
다음 드로어블 리소스 하위 유형으로 컴파일되는
비트맵 파일(
드로어블 리소스를 참조하세요. |
mipmap/ |
각기 다른 런처 아이콘 밀도에 대한 드로어블 파일입니다. mipmap/ 폴더로 런처 아이콘을
관리하는 방법에 대한 자세한 내용은
프로젝트 관리 개요를 참조하세요. |
layout/ |
사용자 인터페이스 레이아웃을 정의하는 XML 파일입니다. 레이아웃 리소스를 참조하세요. |
menu/ |
옵션 메뉴, 컨텍스트 메뉴 또는 하위 메뉴 등과 같은 애플리케이션 메뉴를 정의하는 XML 파일입니다. 메뉴 리소스를 참조하세요. |
raw/ |
원시 형태로 저장하기 위한 임의의 파일입니다. 원시
그러나 원본 파일 이름과 파일 계층에 액세스해야 하는 경우,
|
values/ |
문자열, 정수 및 색과 같은 단순 값이 들어있는 XML 파일입니다. 다른 각 리소스가 자체 XML 요소로 정의되므로, 원하는 대로 파일을 정의하고 하나의 파일에 여러 가지 리소스 유형을 배정할 수 있습니다. 하지만 명확히 하려면 여러 가지 파일에 각기 고유한 리소스를 배치하는 것이 좋을 수도 있습니다. 예를 들어, 다음은 이 디렉터리에서 생성할 수 있는 리소스를 위한 파일 이름 명명 규칙입니다.
문자열 리소스, 스타일 리소스 및 자세한 리소스 유형을 참조하세요. |
xml/ |
Resources.getXML()을 호출하여 런타임에 읽을 수 있는 임의의 XML 파일입니다. 다양한 XML 구성 파일을 여기에 저장해야 합니다. 예를 들어
검색 가능한 구성 등이 이에 해당됩니다.
|
주의: 리소스 파일을
res/ 디렉터리에 직접 저장하면 절대로 안 됩니다. 컴파일러 오류를 초래하게 됩니다.
특정 유형의 리소스에 관한 자세한 정보는 리소스 유형 문서를 참조하세요.
표 1에 정의된 하위 디렉터리에 저장하는 리소스는 "기본" 리소스입니다. 다시 말해, 이러한 리소스가 애플리케이션의 기본 디자인과 콘텐츠를 정의한다는 뜻입니다. 그러나, 여러 가지 유형의 Android 구동 기기는 각기 다른 유형의 리소스를 호출할 수도 있습니다. 예를 들어 어느 기기의 화면이 보통보다 큰 편이라면, 추가적인 화면 공간의 이점을 활용할 수 있는 다른 레이아웃 리소스를 제공해야 합니다. 또는, 기기에 다른 언어 설정이 있을 경우 해당 텍스트를 사용자 인터페이스에 번역하는 다른 문자열 리소스를 제공해야 합니다. 여러 가지 기기 구성에 여러 가지 리소스를 제공하려면, 기본 리소스 외에 대체 리소스를 제공해야 합니다.
대체 리소스 제공
그림 1. 각각 다른 레이아웃 리소스를 사용하는 서로 다른 두 개의 기기.
거의 모든 애플리케이션이 특정 기기 구성을 지원하는 대체 리소스를 제공해야 합니다. 예를 들어 여러 가지 화면 밀도에 맞는 대체 드로어블 리소스를 포함시켜야 하며 여러 가지 언어에 맞게 대체 문자열 리소스도 포함시켜야 합니다. Android는 런타임에 현재 기기 구성을 감지하고 애플리케이션에 대해 적절한 리소스를 로드합니다.
리소스 세트에 대하여 구성별로 적절한 대체를 지정하려면 다음과 같이 합니다.
res/에<resources_name>-<config_qualifier>형식으로 이름을 지정하여 새 디렉터리를 만듭니다.<resources_name>은 해당 기본 리소스의 디렉터리 이름입니다(표 1에 정의되어 있음).<qualifier>는 리소스를 사용할 개별 구성을 지정하는 이름입니다(표 2에 정의되어 있음).
하나 이상의
<qualifier>를 추가할 수 있습니다. 각기 대시로 구분합니다.주의: 여러 한정자를 추가할 때는 표 2에 나열된 것과 같은 순서로 배치해야 합니다. 한정자의 순서가 잘못 지정되면 해당 리소스가 무시됩니다.
- 해당되는 각 대체 리소스를 이 새 디렉터리에 저장하세요. 이 리소스 파일은 기본 리소스 파일과 똑같은 이름을 지정해야 합니다.
예를 들어 다음은 기본 리소스와 대체 리소스입니다.
res/
drawable/
icon.png
background.png
drawable-hdpi/
icon.png
background.png
hdpi 한정자는 해당 디렉터리의 리소스가
고화질 화면 기기용이라는 것을 나타냅니다. 각 드로어블 디렉터리의 이미지는 특정 화면 화질에 맞추어
크기가 지정되었으나 파일 이름은
똑같습니다. 이렇게 하면 icon.png 또는 background.png 이미지를 참조하는 데 사용하는 리소스 ID는 항상 같지만 Android가 각 리소스 중에서 현재 기기에 가장 잘 일치하는
버전을 선택하게 됩니다. 이때 리소스 디렉터리 이름의 한정자를 기기 구성 정보와
비교하는 방법을 씁니다.
Android는 여러 가지 구성 한정자를 지원하며 한 디렉터리 이름에 여러 개의 한정자를 추가할 수 있습니다. 각 한정자를 대시로 구분하면 됩니다. 표 2는 유효한 구성 한정자를 우선 순위대로 나열한 것입니다. 리소스 디렉터리에 여러 개의 한정자를 사용하는 경우, 해당 한정자를 디렉터리 이름에 추가할 때 이 표에 나열된 것과 같은 순서로 추가해야 합니다.
표 2. 구성 한정자 이름.
| 구성 | 한정자 값 | 설명 |
|---|---|---|
| MCC 및 MNC | 예:mcc310mcc208-mnc00등 |
이동통신 국가 코드(MCC)에 선택적으로 이동통신 네트워크 코드(MNC)가 이어지는 형태로,
기기의 SIM 카드에서 가져옵니다. 예를 들어, 기기가 무선 연결(GSM 전화)을 사용할 경우, MCC와 MNC 값은 SIM 카드에서 가져옵니다. MCC만 단독으로 사용할 수도 있습니다(예를 들어, 애플리케이션에 국가별 합법적 리소스를 포함하는 경우). 언어에 기초해서만 지정해야 할 경우, 언어 및 지역 한정자를 대신 사용합니다(아래에 설명). MCC와 MNC 한정자를 사용할 경우, 조심해서 사용하고 예상한 대로 작동하는지 테스트해야 합니다. 또한, 구성 필드 |
| 언어 및 지역 | 예:enfren-rUSfr-rFRfr-rCA등 |
언어는 두 글자의 ISO
639-1 언어 코드로 정의되고,
뒤이어 두 글자의 ISO
3166-1-alpha-2 지역 코드(앞에 소문자 '
코드는 대소문자를 구별하지 않습니다. 사용자가 시스템 설정에서 언어를 변경할 경우 애플리케이션 수명 중에 변경될 수 있습니다. 런타임에서 애플리케이션에 어떤 영향을 미치는지 자세히 알아보려면 런타임 변경 처리를 참조하세요. 다른 여러 언어에 맞게 애플리케이션을 현지화하기 위한 전체 지침은 현지화를 참조하세요. 또한, 현재 로케일을 나타내는 |
| 레이아웃 방향 | ldrtlldltr |
애플리케이션의 레이아웃 방향입니다. 이는 레이아웃이나 드로어블, 값 등의 모든 리소스에 적용할 수 있습니다. 예를 들어, 아랍어에 대한 특정 레이아웃을 제공하고 다른 "오른쪽에서 왼쪽으로 쓰는" 언어(히브리어 또는 페르시아어)에 제네릭 레이아웃을 제공하고 싶다면 다음과 같이 해야 합니다.
res/
layout/
main.xml (Default layout)
layout-ar/
main.xml (Specific layout for Arabic)
layout-ldrtl/
main.xml (Any "right-to-left" language, except
for Arabic, because the "ar" language qualifier
has a higher precedence.)
참고: 앱에서 오른쪽에서 왼쪽 레이아웃 기능을 활성화하려면
API 레벨 17에서 추가되었습니다. |
| smallestWidth | sw<N>dp예: sw320dpsw600dpsw720dp등 |
화면의 기본 크기로, 사용 가능한 화면 영역의 가장 짧은 치수로
나타냅니다. 구체적으로 기기의 smallestWidth는 해당 화면의 이용 가능한 높이와 너비의
가장 짧은 치수를 말합니다(이것을 화면에 대한 "가능한 한 가장 좁은 너비"로 생각해도 됩니다). 이 한정자를 사용하면
화면의 현재 방향에 관계없이
애플리케이션이 해당 UI에서 이용 가능한 너비 중 최소 예를 들어, 레이아웃에 언제나
600dp 이상의 화면 최소 치수가 필요하다면, 이 한정자를 사용하여 레이아웃 리소스 기기의 smallestWidth는 화면 장식과 시스템 UI를 감안합니다. 예를 들어, 화면 상에서 최소 너비의 축 주변 공간을 차지하는 영구 UI 요소가 있다면, 시스템은 smallestWidth를 실제 화면 크기보다 작게 선언합니다. 이것은 개발자의 UI가 사용할 수 없는 화면 픽셀이기 때문입니다. 따라서 개발자가 사용하는 값은 레이아웃에서 요구하는 실제 최소 치수여야 합니다. (일반적으로 이 값은 화면의 현재 방향과 관계없이 레이아웃이 지원하는 "최소 너비"가 됩니다.) 다음의 몇몇 값은 일반적인 화면 크기에 대해 사용할 수 있습니다.
애플리케이션이 smallestWidth 한정자의 여러 값이 포함된 여러 리소스 디렉터리를 제공하면, 시스템은 기기의 smallestWidth에 가장 가까운(그러나 이를 초과하지 않는) 값을 사용합니다. API 레벨 13에서 추가되었습니다. 이외에도 애플리케이션과 호환되는 최소한의 smallestWidth를 선언하는 여러 가지 화면에 맞는 디자인과 한정자 사용에 관한 자세한 정보는 다중 화면 지원 개발자 가이드를 참조하세요. |
| 이용 가능한 너비 | w<N>dp예: w720dpw1024dp등 |
리소스를 사용해야 하는 애플리케이션이 이 구성에 대해 서로 다른 값이 포함된 여러 개의 리소스 디렉터리를 제공하면, 시스템은 기기의 현재 화면 너비에 가장 가까운(그러나 이를 초과하지 않는) 값을 사용합니다. 이 값은 화면 장식을 감안한 것이므로, 기기의 왼쪽이나 오른쪽 가장자리에 영구 UI 요소가 있을 경우, 기기는 이러한 UI 요소를 감안하여 애플리케이션의 이용 가능한 공간을 줄여서 실제 화면 크기보다 작은 너비 값을 사용합니다. API 레벨 13에서 추가되었습니다. 현재 화면 너비를 보유한 여러 가지 화면에 맞는 디자인과 한정자 사용에 관한 자세한 정보는 다중 화면 지원 개발자 가이드를 참조하세요. |
| 이용 가능한 높이 | h<N>dp예: h720dph1024dp등 |
리소스가 사용되어야 하는 최소한의 사용 가능한 화면 높이를 "dp" 단위로 나타냅니다.
이는 애플리케이션이 이 구성에 대해 서로 다른 값이 포함된 여러 개의 리소스 디렉터리를 제공하면, 시스템은 기기의 현재 화면 높이에 가장 가까운(그러나 이를 초과하지 않는) 값을 사용합니다. 이 값은 화면 장식을 감안한 것이므로, 기기의 상단이나 하단 가장자리에 영구 UI 요소가 있을 경우, 기기는 이러한 UI 요소를 감안하여 애플리케이션의 이용 가능한 공간을 줄여서 실제 화면 크기보다 작은 높이 값을 사용합니다. 상태 표시줄에 고정되지 않은 화면 장식(예를 들어 전화 상태 표시줄은 전체 화면에서 숨길 수 있음)은 여기에서 감안하지 않았고, 제목 표시줄이나 작업 모음 등의 창 장식도 감안되지 않았으므로, 애플리케이션 입장에서는 자신이 지정한 것보다 어느 정도 작은 공간을 받아들일 대비를 해야 합니다. API 레벨 13에서 추가되었습니다. 현재 화면 너비를 보유한 여러 가지 화면에 맞는 디자인과 한정자 사용에 관한 자세한 정보는 다중 화면 지원 개발자 가이드를 참조하세요. |
| 화면 크기 |
smallnormallargexlarge
|
참고: 크기 한정자를 사용하더라도 해당 리소스가 그 크기의 화면 전용이라는 뜻은 아닙니다. 현재 기기 구성과 더욱 잘 맞는 한정자가 포함된 대체 리소스를 제공하지 않으면, 시스템이 가장 잘 일치하는 리소스를 사용합니다. 주의: 모든 리소스가 현재 화면보다
큰 크기 한정자를 사용하는 경우, 시스템은 리소스를 사용하지 않으며 애플리케이션은
런타임에 작동이 중단됩니다(예: 모든 레이아웃 리소스에 API 레벨 4에서 추가되었습니다. 자세한 정보는 다중 화면 지원을 참조하세요.
|
| 화면 비율 |
longnotlong
|
API 레벨 4에서 추가되었습니다. 이것은 순전히 화면 비율에만 기초합니다("긴" 화면이 더 넓습니다). 이는 화면 방향과 관계가 없습니다.
|
| 원형 화면 |
roundnotround
|
API 레벨 23에서 추가되었습니다.
|
| 화면 방향 |
portland
|
이것은 사용자가 화면을 돌리는 경우 애플리케이션 수명 중에 변경될 수 있습니다. 이것이 런타임에 애플리케이션에 어떤 영향을 미치는지 알아보려면 런타임 변경 처리를 참조하세요.
|
| UI 모드 |
cardesktelevision |
API 레벨 8에서 추가되었고, 텔레비전은 API 13에서, 시계는 API 20에서 추가되었습니다. 기기가 도크에 삽입되거나 제거될 때 앱이 응답하는 방식에 관한 정보는 도킹 상태 및 유형 판별과 모니터링을 읽어보세요. 이것은 사용자가 기기를 도크에 놓는 경우 애플리케이션 수명 중에
변경될 수 있습니다. 이러한 모드 중 몇 가지는 |
| 야간 모드 |
nightnotnight
|
API 레벨 8에서 추가되었습니다. 이것은 야간 모드가 자동 모드인 상태(기본)에서 애플리케이션의 수명 중에
변경될 수 있습니다. 이 경우 모드는 하루 중 시간대를 기반으로 변경됩니다. 이 모드는
|
| 화면 픽셀 밀도(dpi) |
ldpimdpihdpixhdpixxhdpixxxhdpinodpitvdpianydpi
|
여섯 가지 기본 밀도간에 3:4:6:8:12:16 비율 척도가 있습니다(tvdpi 밀도는 무시). 그러므로 ldpi의 9x9 비트맵은 mdpi에서 12x12이고, hdpi에서 18x18, xhdpi에서 24x24 등, 이런 식으로 적용됩니다. 이미지 리소스가 텔레비전이나 특정 기기에서 제대로 보이지 않는다고 결정하고 tvdpi 리소스를 사용하려 할 경우, 배율은 1.33*mdpi입니다. 예를 들어, mdpi 화면의 100px x 100px 이미지는 tvdpi에서 133px x 133px가 되어야 합니다. 참고: 밀도 한정자를 사용하더라도 해당 리소스가 그 밀도의 화면 전용이라는 뜻은 아닙니다. 현재 기기 구성과 더욱 잘 맞는 한정자가 포함된 대체 리소스를 제공하지 않으면, 시스템이 가장 잘 일치하는 리소스를 사용합니다. 다양한 화질을 처리하는 방법과 Android가 현재 화질에 맞춰 비트맵을 축소하는 방법에 관한 자세한 정보는 다중 화면 지원을 참조하세요. |
| 터치스크린 유형 |
notouchfinger
|
|
| 키보드 가용성 |
keysexposedkeyshiddenkeyssoft
|
이것은 사용자가 하드웨어 키보드를 여는 경우 애플리케이션 수명 중에 변경될 수 있습니다. 이것이 런타임에 애플리케이션에 어떤 영향을 미치는지 알아보려면 런타임 변경 처리를 참조하세요. 또한, 구성 필드 |
| 기본 텍스트 입력 방법 |
nokeysqwerty12key
|
구성 필드 |
| 탐색 키 가용성 |
navexposednavhidden
|
이것은 사용자가 탐색 키를 드러내는 경우 애플리케이션 수명 중에 변경될 수 있습니다. 이것이 런타임에 애플리케이션에 어떤 영향을 미치는지 알아보려면 런타임 변경 처리를 참조하세요. 구성
필드 |
| 기본 비터치 탐색 방법 |
nonavdpadtrackballwheel
|
구성 필드 |
| 플랫폼 버전(API 레벨) | 예:v3v4v7등 |
기기에서 지원하는 API 레벨입니다. 예를 들어, |
참고: 일부 구성 한정자는 Android
1.0 이후부터 추가되었으므로 모든 Android 버전이 모든 한정자를 지원하는 것은 아닙니다. 새로운 한정자를 사용하면 암묵적으로
플랫폼 버전 한정자도 추가하므로 구형 기기가 이를 무시하게 됩니다. 예를 들어
w600dp 한정자를 사용하면 자동적으로 v13 한정자를 포함합니다.
사용 가능한 너비 한정자가 API 레벨 13부터 새로 도입되었기 때문입니다. 문제를 애초에 피하려면, 항상
기본 리소스를 한 세트 포함하세요(한정자 없는 리소스 한 세트). 자세한 정보는
리소스와 연관된 최선의 기기 호환성 제공
을 참조하세요.
한정자 이름 규칙
다음은 구성 한정자 이름 사용에 관한 규칙입니다.
- 한 가지 리소스 세트에 여러 개의 한정자를 사용할 수 있으며, 이를 대시로 구분하면 됩니다. 예를 들어,
drawable-en-rUS-land는 수평 방향의 US-English 기기에 적용합니다. - 한정자는 표 2에 나열된 순서를 따라야 합니다. 예를 들면
다음과 같습니다.
- 잘못된 배열:
drawable-hdpi-port/ - 맞는 배열:
drawable-port-hdpi/
- 잘못된 배열:
- 대체 리소스 디렉터리는 중첩될 수 없습니다. 예를 들어,
res/drawable/drawable-en/는 있을 수 없습니다. - 값은 대소문자를 구분하지 않습니다. 리소스 컴파일러가 처리 전에 디렉터리 이름을 소문자로 바꿔 대소문자를 구분하지 않는 파일 시스템에서 문제를 일으키지 않도록 방지합니다. 이름에 대문자가 있는 것은 오로지 가독성을 향상하기 위해서입니다.
- 각 한정자 유형마다 한 개의 값만 지원됩니다. 예를 들어, 스페인과 프랑스에
같은 드로어블 파일을 사용하고자 하는 경우 디렉터리 이름이
drawable-rES-rFR/이면 안 됩니다. 대신drawable-rES/와drawable-rFR/같이 적절한 파일이 포함된 두 개의 리소스 디렉터리가 필요합니다. 그러나 두 위치에서 같은 파일을 실제로 복제할 필요는 없습니다. 대신 리소스에 별칭을 만들면 됩니다. 아래의 별칭 리소스 생성을 참조하세요.
이런 한정자로 이름을 지은 디렉터리에 대체 리소스를 저장하고 나면 Android가 현재 기기 구성에 기초하여 애플리케이션에 자동으로 리소스를 적용합니다. 리소스가 요청될 때마다 Android가 요청한 리소스 파일이 들어있는 대체 리소스 디렉터리를 확인하고, 그런 다음 가장 잘 일치하는 리소스를 찾습니다(아래에서 논함). 특정 기기 구성에 일치하는 대체 리소스가 없는 경우, Android는 상응하는 기본 리소스(구성 한정자를 포함하지 않는 특정 리소스 유형에 대한 리소스 세트 )를 사용합니다.
별칭 리소스 생성
어떤 리소스를 하나 이상의 기기 구성에서 사용하고자 하는 경우(그렇지만 이를 기본 리소스를 제공하는 것은 원치 않는 경우), 같은 리소스를 하나 이상의 대체 리소스 디렉터리에 넣지 않아도 됩니다. 대신, 기본 리소스 디렉터리에 저장된 리소스에 대해 별칭 역할을 하는 대체 리소스를 만들면 됩니다(경우에 따라).
참고: 모든 리소스가 다른 리소스에 대한
별칭을 생성할 수 있는 메커니즘을 제공하는 것은 아닙니다. 특히, xml/ 디렉터리의 애니메이션, 메뉴, 원시 및 기타 지정되지 않은
리소스는 이 기능을 제공하지 않습니다.
예를 들어, 애플리케이션 아이콘 icon.png가 있고 여러 로케일에 각각 고유한 아이콘 버전이
필요하다고 가정해 봅니다. 그러나 두 로케일, English-Canadian과 French-Canadian은 같은 버전을
사용해야 합니다. 같은 이미지를 English-Canadian과 French-Canadian 양쪽
모두에 대한 리소스 디렉터리에 복사해야 한다고 생각할 수 있지만, 실은
그렇지 않습니다. 대신, 두 로케일에서 사용하는 이미지를 icon_ca.png(icon.png 이외에 어떤
이름이든 가능)로 저장하고 이를
기본 res/drawable/ 디렉터리에 넣으면 됩니다. 그런 다음 <bitmap> 요소를 사용하여 icon_ca.png
리소스를 참조하는 res/drawable-en-rCA/ 및 res/drawable-fr-rCA/에서 icon.xml 파일을 생성합니다. 이렇게 하면
PNG 파일 버전 하나와 그것을 가리키는 작은 XML 파일 두 개만 저장할 수 있습니다. (XML 파일 예시는 아래와 같습니다.)
드로어블
기존 드로어블에 별칭을 생성하려면 <drawable> 요소를 사용합니다.
예를 들면 다음과 같습니다.
<?xml version="1.0" encoding="utf-8"?>
<bitmap xmlns:android="http://schemas.android.com/apk/res/android"
android:src="@drawable/icon_ca" />
파일을
res/drawable-en-rCA/와 같은 대체 리소스 디렉터리에 icon.xml로 저장하면,
R.drawable.icon으로 참조할 수 있는 리소스로 컴파일됩니다. 그러나 이것은 실제로는 R.drawable.icon_ca 리소스(res/drawable/에 저장됨)의 별칭입니다.
레이아웃
기존 레이아웃에 별칭을 생성하려면 <merge> 안에 싸여 있는 <include>
요소를 사용합니다. 예:
<?xml version="1.0" encoding="utf-8"?>
<merge>
<include layout="@layout/main_ltr"/>
</merge>
파일을 main.xml로 저장하면, R.layout.main으로
참조할 수 있는 리소스로 컴파일됩니다. 그러나 이것은 실제로는 R.layout.main_ltr
리소스의 별칭입니다.
문자열 및 기타 단순 값
기존 문자열에 별칭을 생성하려면 원하는 문자열의 리소스 ID를 새 문자열의 값으로 사용하면 됩니다. 예:
<?xml version="1.0" encoding="utf-8"?>
<resources>
<string name="hello">Hello</string>
<string name="hi">@string/hello</string>
</resources>
이제 R.string.hi 리소스는 R.string.hello의 별칭입니다.
기타 단순 값도 같은 방식으로 동작합니다. 예를 들면 색상은 다음과 같습니다.
<?xml version="1.0" encoding="utf-8"?>
<resources>
<color name="red">#f00</color>
<color name="highlight">@color/red</color>
</resources>
리소스와 연관된 최선의 기기 호환성 제공
애플리케이션이 여러 기기 구성을 지원하게 하려면, 언제나 애플리케이션이 사용하는 각 유형의 리소스에 기본 리소스를 제공하는 것이 매우 중요합니다.
예를 들어 애플리케이션이 여러 언어를 지원할 경우, 항상 언어 및 지역 한정자 없이 values/ 디렉터리(문자열이 저장된 디렉터리)를 포함시켜야 합니다. 그렇게 하지 않고 언어와 지역 한정자가 있는 디렉터리에
모든 문자열을 넣으면, 문자열이 지원하지 않는 언어로 설정된 기기에서 애플리케이션을
실행하면 작동이 중단됩니다. 그러나 기본
values/ 리소스를 제공하는 한, 애플리케이션이 제대로 실행됩니다(작동이 중단되는 것보다는 나으므로 사용자가
해당 언어를 이해할 수 없는 경우에도 제대로 실행됨).
마찬가지로 화면 방향에 기초하여 여러 가지 레이아웃 리소스를 제공하는 경우
하나의 방향을 기본값으로 선택해야 합니다. 예를 들어 가로 방향에는 layout-land/로, 세로 방향에는 layout-port/로 레이아웃 리소스를 제공하는 대신 하나를 기본으로 남겨두세요.
가로 방향인 경우 layout/으로 제공하고, 세로 방향인 경우 layout-port/로 제공하는 식으로 하면 됩니다.
애플리케이션이 예상치 못한 구성에서 실행될 수 있을 뿐만 아니라
Android의 새 버전에서 이전 버전에서는 지원하지 않는 구성 한정자를 추가할 수도 있으므로,
기본 리소스를 제공하는 것이 중요합니다. 새 리소스 한정자를 사용하지만,
Android 이전 버전과 코드 호환성은 유지한 경우, 그 후 Android 이전 버전이
애플리케이션을 실행하면 새로운 한정자로 이름을 지정한 리소스를 사용할 수 없으므로 기본 리소스를 제공하지 않으면
애플리케이션 작동이 중단됩니다. 예를 들어, minSdkVersion이 4로 설정되어 있는데 야간 모드(API 레벨 8에서 추가된 night 또는 notnight)를 사용하여 모든 드로어블 리소스를 한정할 경우, API 레벨 4 기기가
드로어블 리소스에 액세스하지 못하고 작동을 중단합니다. 이 경우,
notnight를 기본 리소스로 제공하는 것이 좋습니다. 즉, 드로어블 리소스가 drawable/ 또는 drawable-night/이 되도록 해당 한정자를 제외해야
합니다.
그러므로 최선의 기기 호환성을 제공하려면 언제나 애플리케이션에서 반드시 제대로 수행해야 하는 리소스에 대해 기본 리소스를 제공하세요. 그런 다음 구성 한정자를 사용하여 특정 기기 구성에 대해 대체 리소스를 생성하면 됩니다.
이 규칙에는 한 가지 예외가 있습니다. 애플리케이션의 minSdkVersion이 4 이상이면
화면 밀도 한정자로 대체 드로어블 리소스를 제공할 때 기본 드로어블
리소스가 없어도 됩니다. 기본
드로어블 리소스가 없더라도 Android가 대체 화면 화질 중에서 가장 잘 맞는 리소스를 찾고
필요에 따라 비트맵을 축소합니다. 그러나 모든 유형의 기기에서 최상의 경험을 제공하려면,
모든 세 가지 유형의 밀도에 대해 대체 드로어블을 제공해야 합니다.
Android가 가장 잘 일치하는 리소스를 찾는 방법
개발자가 자신이 대체를 제공하는 리소스를 요청하면 Android가 런타임에 어느 대체 리소스를 사용할지 현대 기기 구성에 따라 여러 가지로 선택합니다. Android가 대체 리소스를 선택하는 방법을 보여주기 위해 다음 드로어블 디렉터리에 각각 같은 이미지의 서로 다른 버전이 들어있다고 가정하겠습니다.
drawable/ drawable-en/ drawable-fr-rCA/ drawable-en-port/ drawable-en-notouch-12key/ drawable-port-ldpi/ drawable-port-notouch-12key/
그리고 기기 구성은 다음과 같다고 가정해봅시다.
로케일 = en-GB
화면 방향 = port
화면 픽셀 밀도 = hdpi
터치 스크린 유형 = notouch
기본 텍스트 입력 방법 = 12key
Android는 기기 구성을 이용 가능한 대체 리소스와 비교하여,
drawable-en-port에서 드로어블을 선택합니다.
시스템은 다음과 같은 논리에 따라 어느 리소스를 사용할지 결정합니다.
그림 2. Android가 가장 잘 일치하는 리소스를 찾는 방법을 나타낸 흐름도.
- 기기 구성과 충돌하는 리소스 파일을 제거합니다.
drawable-fr-rCA/는en-GB로케일과 충돌하므로 제거되었습니다.drawable/ drawable-en/
drawable-fr-rCA/drawable-en-port/ drawable-en-notouch-12key/ drawable-port-ldpi/ drawable-port-notouch-12key/예외: 화면 픽셀 밀도 한정자 하나만은 충돌을 이유로 제거되지 않습니다. 기기의 화면 밀도가 hdpi라도, 현 시점에서는 모든 화면 밀도가 일치로 간주되므로
drawable-port-ldpi/를 제거하지 않습니다. 자세한 정보는 다중 화면 지원 문서에서 이용하실 수 있습니다. - 목록(표2)에서 (그 다음으로) 우선 순위가 가장 높은 한정자를 선택합니다 (MCC부터 시작하여 아래로 내려가세요).
- 리소스 디렉터리 중에 이 한정자를 포함한 것이 있나요?
- 없을 경우, 2단계로 돌아가 다음 한정자를 살펴보세요 (이 예시의 경우 언어 한정자에 도달할 때까지 답은 "없습니다"입니다).
- 있는 경우, 4단계로 계속 진행합니다.
- 이 한정자를 포함하지 않는 디렉터리를 제거합니다. 이 예시에서는 시스템이 언어 한정자를 포함하지 않는 디렉터리를 모두 제거합니다.
- 뒤로 돌아가 디렉터리가 한 개만 남을 때까지 2, 3 및 4단계를 반복합니다. 이 예시에서, 일치하는 것이 있는 다음 한정자는
화면 방향입니다.
그러므로 화면 방향을 지정하지 않는 리소스가 제거됩니다.
drawable-en/drawable-en-port/drawable-en-notouch-12key/남은 디렉터리는
drawable-en-port입니다.
drawable/drawable-en/ drawable-en-port/ drawable-en-notouch-12key/drawable-port-ldpi/drawable-port-notouch-12key/
예외: 문제의 한정자가 화면 픽셀 밀도라면, Android는 기기 화면 밀도와 가장 가깝게 일치하는 옵션을 선택합니다. 일반적으로, Android는 작은 원본 이미지를 확대하는 것보다 큰 원본 이미지를 축소하는 것을 선호합니다. 다중 화면 지원을 참조하세요.
이 절차는 요청된 각 리소스에 대해 실행하지만, 시스템이 몇 가지 측면을 추가로 최적화합니다. 그러한 최적화 가운데에는 일단 기기 구성을 알게 되고 나면 절대 일치할 가능성이 없는 대체 리소스를 시스템이 제거할 수 있다는 점도 있습니다. 예를 들어, 구성 언어가 영어("en")이고 영어 이외의 다른 언어 한정자로 설정된 리소스 디렉터리는 절대 확인된 리소스 풀에 포함되지 않습니다( 언어 한정자가 포함되지 않는 리소스 디렉터리는 여전히 포함됩니다).
화면 크기 한정자에 기초하여 리소스를 선택할 때 시스템은 가장 잘 일치하는 리소스가 없다면
현재 화면보다 작은 화면에 지정된 리소스를 사용합니다
(예를 들어, 큰 화면은 필요에 따라 일반 크기 화면 리소스를 사용합니다). 그러나
이용 가능한 리소스가 현재 화면보다 큰 리소스뿐이라면, 시스템은
이를 사용하지 않고, 기기
구성에 일치하는 리소스가 없으면 애플리케이션이 작동 중단됩니다(예: 모든 레이아웃 리소스가 xlarge 한정자로 태그가 지정되어 있지만,
기기가 보통 크기 화면일 경우).
참고: 한정자의 우선 순위(표 2 참조)가 기기와 정확하게 일치하는
한정자 수보다 더 중요합니다. 예를 들어 위의 4단계에서
목록의 마지막 선택에 기기와 정확히 일치하는 한정자가 세 개 포함되어 있지만(방향, 터치 스크린
유형 및 입력 방법), drawable-en에는 일치하는 매개변수가
하나뿐입니다(언어). 다만, 언어가 이러한 다른 한정자보다 우선 순위가 높기 때문에
drawable-port-notouch-12key는 탈락합니다.
애플리케이션에서 리소스를 사용하는 것에 대한 자세한 정보는 리소스 액세스로 계속하여 알아보세요.