page.title=리소스 제공 parent.title=애플리케이션 리소스 parent.link=index.html @jd:body
이미지나 문자열과 같은 애플리케이션 리소스는 항상 코드에서 외부화해야 합니다. 그래야 이들을 독립적으로 유지관리할 수 있습니다. 특정 기기 구성에 대한 대체 리소스도 제공해야 합니다. 이것은 특별하게 명명한 리소스 디렉터리에 그룹화하는 방법을 씁니다. Android는 런타임에 현재 구성을 근거로 적절한 리소스를 사용합니다. 예를 들어 여러 가지 화면 크기에 따라 여러 가지 UI 레이아웃을 제공하거나 언어 설정에 따라 각기 다른 문자열을 제공하고자 할 수 있습니다.
애플리케이션 리소스를 외부화하면 프로젝트 {@code R} 클래스에서 발생하는 리소스 ID로 액세스할 수 있습니다. 애플리케이션에서 리소스를 사용하는 방법은 리소스 액세스에서 설명합니다. 이 문서에서는 Android 프로젝트에서 리소스를 그룹화하는 방법과 특정 기기 구성에 대한 대체 리소스를 제공하는 법을 보여드립니다.
프로젝트 {@code res/} 디렉터리의 특정 하위 디렉터리에 각 유형의 리소스를 배치해야 합니다. 예를 들어, 다음은 간단한 프로젝트의 파일 계층입니다.
MyProject/ src/ MyActivity.java res/ drawable/ graphic.png layout/ main.xml info.xml mipmap/ icon.png values/ strings.xml
이 예시에서 {@code res/} 디렉터리가 모든 리소스(이미지 리소스, 레이아웃 리소스 두 개, 시작 관리자 아이콘용 {@code mipmap/} 디렉터리, 문자열 리소스 파일)를 (하위 디렉터리에 ) 포함하는 것을 볼 수 있습니다. 리소스 디렉터리 이름은 중요하며 표1에 설명되어 있습니다.
참고: Mipmap 폴더를 사용하는 자세한 방법은 프로젝트 관리 개요를 참조하십시오.
디렉터리 | 리소스 유형 |
---|---|
animator/ |
속성 애니메이션을 정의하는 XML 파일입니다. |
anim/ |
tween 애니메이션을 정의하는 XML 파일입니다 (속성 애니메이션도 이 디렉터리에 저장할 수 있지만 두 가지 유형을 구분하기 위해 속성 애니메이션에는 {@code animator/} 디렉터리가 기본 설정됩니다 ). |
color/ |
색상의 상태 목록을 정의하는 XML 파일입니다. 색상 상태 목록 리소스를 참조하십시오. |
drawable/ |
다음 드로어블 리소스 하위 유형으로 컴파일 되는 비트맵 파일({@code .png}, {@code .9.png}, {@code .jpg}, {@code .gif}) 또는 XML 파일입니다.
드로어블 리소스를 참조하십시오. |
mipmap/ |
각기 다른 시작 관리자 아이콘 밀도에 대한 드로어블 파일입니다. {@code mipmap/} 폴더로 시작 관리자 아이콘을 관리하는 자세한 방법은 프로젝트 관리 개요를 참조하십시오. |
layout/ |
사용자 인터페이스 레이아웃을 정의하는 XML 파일입니다. 레이아웃 리소스를 참조하십시오. |
menu/ |
옵션 메뉴, 컨텍스트 메뉴 또는 하위 메뉴 등과 같은 애플리케이션 메뉴를 정의하는 XML입니다. 메뉴 리소스를 참조하십시오. |
raw/ |
원시 형태로 저장하기 위한 임의의 파일입니다. 원시 {@link java.io.InputStream}으로 이런 리소스를 열려면 리소스 ID, {@code R.raw.filename}으로 {@link android.content.res.Resources#openRawResource(int) Resources.openRawResource()}를 호출합니다. 그러나 원본 파일 이름과 파일 계층에 액세스해야 하는 경우, ({@code res/raw/}가 아니라) {@code assets/} 디렉터리에 몇몇 리소스를 저장해두는 것을 고려해 볼 수 있습니다. {@code assets/}에 있는 파일에는 리소스 ID가 주어지지 않으므로, 이들을 읽는 유일한 방법은 {@link android.content.res.AssetManager}를 사용하는 것뿐입니다. |
values/ |
문자열, 정수 및 색과 같은 단순 값이 들어있는 XML 파일입니다. 다른 {@code res/} 하위 디렉터리에 있는 XML 리소스 파일은 XML 파일 이름을 근거로 하나의 리소스를 정의하는 반면, {@code values/} 디렉터리에 있는 파일은 여러 개의 리소스를 설명합니다. 이 디렉터리 안에 있는 파일의 경우, {@code <resources>} 요소의 각 하위 요소가 리소스를 하나씩 정의합니다. 예를 들어 {@code <string>} 요소는 {@code R.string} 리소스를 생성하고 {@code <color>} 요소는 {@code R.color} 리소스를 생성합니다. 각 리소스가 자체 XML 요소로 정의되므로, 원하는 대로 파일을 정의하고 하나의 파일에 여러 가지 리소스 유형을 배정할 수 있습니다. 하지만 명확히 하려면 여러 가지 파일에 각기 고유한 리소스를 배치하는 것이 좋을 수도 있습니다. 예를 들어, 다음은 이 디렉터리에서 생성할 수 있는 리소스를 위한 파일 이름 명명법입니다.
문자열 리소스, 스타일 리소스 및 자세한 리소스 유형을 참조하십시오. |
xml/ |
런타임에 읽을 수 있는 임의의 XML 파일로, 이때 {@link android.content.res.Resources#getXml(int) Resources.getXML()}을 호출하는 방법을 씁니다. 다양한 XML 구성 파일을 여기에 저장해야 합니다. 예를 들어 검색 가능한 구성 등이 이에 해당됩니다. |
주의: 리소스 파일을 {@code res/} 디렉터리에 직접 저장하면 절대로 안 됩니다. 컴파일러 오류를 초래하게 됩니다.
특정 유형의 리소스에 관한 자세한 정보는 리소스 유형 문서를 참조하십시오.
표1에 정의된 하위 디렉터리에 저장하는 리소스는 "기본" 리소스입니다. 다시 말해, 이러한 리소스가 애플리케이션의 기본 디자인과 콘텐츠를 정의한다는 뜻입니다. 그러나, 여러 가지 유형의 Android 구동 기기는 각기 다른 유형의 리소스를 호출할 수도 있습니다. 예를 들어 어느 기기의 화면이 보통보다 큰 편이라면, 추가적인 화면 공간의 이점을 활용할 수 있는 다른 레이아웃 리소스를 제공해야 합니다. 또는, 기기에 다른 언어 설정이 있을 경우 해당 텍스트를 사용자 인터페이스에 번역하는 다른 문자열 리소스를 제공해야 합니다. 여러 가지 기기 구성에 여러 가지 리소스를 제공하려면, 기본 리소스 외에 대체 리소스를 제공해야 합니다.
거의 모든 애플리케이션이 특정 기기 구성을 지원하는 대체 리소스를 제공해야 합니다. 예를 들어 여러 가지 화면 밀도에 맞는 대체 드로어블 리소스를 포함시켜야 하며 여러 가지 언어에 맞게 대체 문자열 리소스도 포함시켜야 합니다. Android는 런타임에 현재 기기 구성을 감지하고 애플리케이션에 대해 적절한 리소스를 로드합니다.
리소스 세트에 대하여 구성별로 적절한 대체를 지정하려면 다음과 같이 합니다.
하나 이상의 {@code <qualifier>}를 추가할 수 있습니다. 각기 대시로 구분합니다.
주의: 여러 한정자를 추가할 때는 표2에 나열된 것과 같은 순서로 배치해야 합니다. 한정자의 순서가 잘못 지정되면 해당 리소스가 무시됩니다.
예를 들어 다음은 기본 리소스와 대체 리소스입니다.
res/ drawable/ icon.png background.png drawable-hdpi/ icon.png background.png
{@code hdpi} 한정자는 해당 디렉터리의 리소스가 고화질 화면 기기용이라는 것을 나타냅니다. 각 드로어블 디렉터리의 이미지는 특정 화면 화질에 맞추어 크기가 지정되었으나 파일 이름은 똑같습니다. 이렇게 하면 {@code icon.png} 또는 {@code background.png} 이미지를 참조하는 데 사용하는 리소스 ID는 항상 같지만 Android가 각 리소스 중에서 현재 기기에 가장 잘 일치하는 버전을 선택하게 됩니다. 이때 리소스 디렉터리 이름의 한정자를 기기 구성 정보와 비교하는 방법을 씁니다.
Android는 여러 가지 구성 한정자를 지원하며 한 디렉터리 이름에 여러 개의 한정자를 추가할 수 있습니다. 각 한정자를 대시로 구분하면 됩니다. 표 2는 유효한 구성 한정자를 우선 순위대로 나열한 것입니다. 리소스 디렉터리에 여러 개의 한정자를 사용하는 경우, 해당 한정자를 디렉터리 이름에 추가할 때 이 표에 나열된 것과 같은 순서로 추가해야 합니다.
구성 | 한정자 값 | 설명 |
---|---|---|
MCC 및 MNC | 예:mcc310
mcc208-mnc00 등. |
이동통신 국가 코드(MCC)에 선택적으로 이동통신 네트워크 코드(MNC)가 이어지는 형태로,
기기의 SIM 카드에서 가져옵니다. 예를 들어, 기기가 무선 연결(GSM 전화)을 사용할 경우, MCC와 MNC 값은 SIM 카드에서 가져옵니다. MCC만 단독으로 사용할 수도 있습니다(예를 들어, 애플리케이션에 국가별 합법적 리소스를 포함하는 경우). 언어에 기초해서만 지정해야 할 경우, 언어 및 지역 한정자를 대신 사용합니다(아래에 설명). MCC와 MNC 한정자를 사용할 경우, 조심해서 사용하고 예상한 대로 작동하는지 테스트해야 합니다. 또한, 구성 필드 {@link android.content.res.Configuration#mcc}와 {@link android.content.res.Configuration#mnc}를 참조하십시오. 이 구성 필드는 각각 이동통신 국가 코드와 이동통신 네트워크 코드를 나타냅니다. |
언어 및 지역 | 예:en fr en-rUS fr-rFR fr-rCA 등. |
언어는 두 글자의 ISO 639-1 언어 코드로 정의되고, 뒤이어 두 글자의 ISO 3166-1-alpha-2 지역 코드가 선택적으로 따라옵니다(소문자 "{@code r}" 뒤에 붙음). 코드는 대소문자를 구별하지 않습니다. {@code r} 접두사는 지역 부분을 구별하기 위해 사용합니다. 지역만 지정할 수는 없습니다. 사용자가 시스템 설정에서 언어를 변경할 경우 애플리케이션 수명 중에 변경될 수 있습니다. 런타임에서 애플리케이션에 어떤 영향을 미치는지 자세히 알아보려면 런타임 변경 처리를 참조하십시오. 다른 여러 언어에 맞게 애플리케이션을 지역화하기 위한 전체 지침은 지역화를 참조하십시오. 또한, 현재 로케일을 나타내는 {@link android.content.res.Configuration#locale} 구성 필드도 참조하십시오. |
레이아웃 방향 | ldrtl ldltr |
애플리케이션의 레이아웃 방향입니다. {@code ldrtl}는 "오른쪽에서 왼쪽 방향 레이아웃"을 나타냅니다. {@code ldltr}는 "왼쪽에서 오른쪽 방향 레이아웃"을 나타내고 기본 암시적 값입니다. 이는 레이아웃이나 드로어블, 값 등의 모든 리소스에 적용할 수 있습니다. 예를 들어, 아랍어에 대한 특정 레이아웃을 제공하고 다른 "오른쪽에서 왼쪽으로 쓰는" 언어(히브리어 또는 페르시아어)에 제네릭 레이아웃을 제공하고 싶다면 다음과 같이 해야 합니다. 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.) 참고: 앱에서 오른쪽에서 왼쪽 레이아웃 기능을 활성화하려면 {@code supportsRtl}을 {@code "true"}로 설정하고 {@code targetSdkVersion}을 17 이상으로 설정해야 합니다. API 레벨 17에서 추가되었습니다. |
smallestWidth | sw<N>dp 예: sw320dp sw600dp sw720dp 등. |
화면의 기본 크기로, 사용 가능한 화면 영역의 가장 짧은 치수가 나타냅니다. 구체적으로 기기의 smallestWidth는 해당 화면의 이용 가능한 높이와 너비의 가장 짧은 치수를 말합니다(이것을 화면에 대한 "가능한 한 가장 좁은 너비"로 생각해도 됩니다). 이 한정자를 사용하면 화면의 현재 방향에 관계 없이 애플리케이션이 해당 UI에서 이용 가능한 너비 중 최소 {@code <N>}dps를 확보하도록 할 수 있습니다. 예를 들어, 레이아웃에 언제나 600dp 이상의 화면 최소 치수가 필요하다면, 이 한정자를 사용하여 레이아웃 리소스, {@code res/layout-sw600dp/}를 만들 수 있습니다. 시스템이 이러한 리소스를 사용하는 것은 사용 가능한 화면의 최소 치수가 적어도 600dp가 되는 경우뿐이며, 이때 600dp라는 크기가 사용자 쪽에서 보기에 높이이든 너비이든 관계 없습니다. 이 smallestWidth는 기기의 고정된 화면 크기 특성입니다. 기기의 smallestWidth는 화면 방향이 변경되어도 바뀌지 않습니다. 기기의 smallestWidth는 화면 장식과 시스템 UI를 감안합니다. 예를 들어, 화면 상에서 최소 너비의 축 주변 공간을 차지하는 영구 UI 요소가 있다면, 시스템은 smallestWidth를 실제 화면 크기보다 작게 선언합니다. 이것은 개발자의 UI가 사용할 수 없는 화면 픽셀이기 때문입니다. 따라서 개발자가 사용하는 값은 레이아웃에서 요구하는 실제 최소 치수여야 합니다(일반적으로 이 값은 화면의 현재 방향과 관계없이 레이아웃이 지원하는 "최소 너비"가 됩니다.). 다음의 몇몇 값은 보편적인 화면 크기에 대하여 사용할 수 있습니다.
애플리케이션이 smallestWidth 한정자의 여러 값이 포함된 여러 리소스 디렉터리를 제공하면, 시스템은 기기의 smallestWidth에 가장 가까운(그러나 이를 초과하지 않는) 값을 사용합니다. API 레벨 13에서 추가되었습니다. 이외에도 애플리케이션과 호환되는 최소한의 smallestWidth를 선언하는 {@code android:requiresSmallestWidthDp} 속성과 기기의 smallestWidth 값을 보유한 {@link android.content.res.Configuration#smallestScreenWidthDp} 구성 필드도 참조하십시오. 여러 가지 화면에 맞는 디자인과 한정자 사용에 관한 자세한 정보는 다중 화면 지원 개발자 가이드를 참조하십시오. |
이용 가능한 너비 | w<N>dp 예: w720dp w1024dp 등. |
리소스를 사용해야 하는 {@code dp} 단위에서 최소 이용 가능한 화면 너비를 지정합니다.
이는 애플리케이션이 이 구성에 대해 서로 다른 값이 포함된 여러 개의 리소스 디렉터리를 제공하면, 시스템은 기기의 현재 화면 너비에 가장 가까운(그러나 이를 초과하지 않는) 값을 사용합니다. 이 값은 화면 장식을 감안한 것이므로, 기기의 왼쪽이나 오른쪽 가장자리에 영구 UI 요소가 있을 경우, 기기는 이러한 UI 요소를 감안하여 애플리케이션의 이용 가능한 공간을 줄여서 실제 화면 크기보다 작은 너비 값을 사용합니다. API 레벨 13에서 추가되었습니다. 현재 화면 너비를 보유한 {@link android.content.res.Configuration#screenWidthDp} 구성 필드도 참조하십시오. 여러 가지 화면에 맞는 디자인과 한정자 사용에 관한 자세한 정보는 다중 화면 지원 개발자 가이드를 참조하십시오. |
이용 가능한 높이 | h<N>dp 예: h720dp h1024dp 등. |
리소스가 사용되어야 하는 최소한의 사용 가능한 화면 높이를 "dp" 단위로 나타냅니다.
이는 애플리케이션이 이 구성에 대해 서로 다른 값이 포함된 여러 개의 리소스 디렉터리를 제공하면, 시스템은 기기의 현재 화면 높이에 가장 가까운(그러나 이를 초과하지 않는) 값을 사용합니다. 이 값은 화면 장식을 감안한 것이므로, 기기의 상단이나 하단 가장자리에 영구 UI 요소가 있을 경우, 기기는 이러한 UI 요소를 감안하여 애플리케이션의 이용 가능한 공간을 줄여서 실제 화면 크기보다 작은 높이 값을 사용합니다. 상태 표시줄에 고정되지 않은 화면 장식(예를 들어 전화 상태 표시줄은 전체 화면에서 숨길 수 있음)은 여기에서 감안하지 않았고, 제목 표시줄이나 작업 모음 등의 창 장식도 감안되지 않았으므로, 애플리케이션 입장에서는 자신이 지정한 것보다 어느 정도 작은 공간을 받아들일 대비를 해야 합니다. API 레벨 13에서 추가되었습니다. 현재 화면 너비를 보유한 {@link android.content.res.Configuration#screenHeightDp} 구성 필드도 참조하십시오. 여러 가지 화면에 맞는 디자인과 한정자 사용에 관한 자세한 정보는 다중 화면 지원 개발자 가이드를 참조하십시오. |
화면 크기 |
small normal large xlarge
|
참고: 크기 한정자를 사용하더라도 해당 리소스가 그 크기의 화면 전용이라는 뜻은 아닙니다. 현재 기기 구성과 더욱 잘 맞는 한정자가 포함된 대체 리소스를 제공하지 않으면, 시스템이 가장 잘 일치하는 리소스를 사용합니다. 주의: 모든 리소스가 현재 화면보다 큰 크기 한정자를 사용하는 경우, 시스템은 리소스를 사용하지 않으며 애플리케이션은 런타임에 작동이 중단됩니다(예를 들어, 모든 레이아웃 리소스에 {@code xlarge} 한정자가 태그되어 있지만 기기는 일반 크기 화면일 경우 ). API 레벨 4에서 추가되었습니다. 자세한 정보는 다중 화면 지원을 참조하십시오. {@link android.content.res.Configuration#screenLayout} 구성 필드도 참조하십시오. 이것은 화면이 소형, 일반 크기 또는 대형인지를 나타냅니다. |
화면 비율 |
long notlong
|
API 레벨 4에서 추가되었습니다. 이것은 순전히 화면 비율에만 기초합니다("긴" 화면이 더 넓습니다). 이는 화면 방향과 관계가 없습니다. {@link android.content.res.Configuration#screenLayout}도 참조하십시오. 이것은 화면이 긴 화면인지 여부를 나타냅니다. |
화면 방향 |
port land
|
이것은 사용자가 화면을 돌리는 경우 애플리케이션 수명 중에 변경될 수 있습니다. 이것이 런타임에 애플리케이션에 어떤 영향을 미치는지 알아보려면 런타임 변경 처리를 참조하십시오. {@link android.content.res.Configuration#orientation} 구성 필드도 참조하십시오. 이는 현재 기기 방향을 나타냅니다. |
UI 모드 |
car desk television appliance
watch
|
API 레벨 8에서 추가되었고, 텔레비전은 API 13에서, 시계는 API 20에서 추가되었습니다. 기기가 도크에 삽입되거나 제거될 때 앱이 응답하는 방식에 관한 정보는 도킹 상태 및 유형 판별과 모니터링을 읽어보십시오. 이것은 사용자가 기기를 도크에 놓는 경우 애플리케이션 수명 중에 변경될 수 있습니다. 이러한 모드 중 몇 가지는 {@link android.app.UiModeManager}를 사용하여 활성화 또는 비활성화할 수 있습니다. 이것이 런타임에 애플리케이션에 어떤 영향을 미치는지 알아보려면 런타임 변경 처리를 참조하십시오. |
야간 모드 |
night notnight
|
API 레벨 8에서 추가되었습니다. 이것은 야간 모드가 자동 모드인 상태(기본)에서 애플리케이션의 수명 중에 변경될 수 있습니다. 이 경우 모드는 하루 중 시간대를 기반으로 변경됩니다. 이 모드는 {@link android.app.UiModeManager}를 사용하여 활성화 또는 비활성화할 수 있습니다. 이것이 런타임 중 애플리케이션에 어떤 영향을 미치는지 알아보려면 런타임 변경 처리를 참조하십시오. |
화면 픽셀 밀도(dpi) |
ldpi mdpi hdpi xhdpi xxhdpi xxxhdpi nodpi tvdpi
|
여섯 가지 기본 밀도간에 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가 현재 화질에 맞춰 비트맵을 축소하는 방법에 관한 자세한 정보는 다중 화면 지원을 참조하십시오. |
터치 스크린 유형 |
notouch finger
|
{@link android.content.res.Configuration#touchscreen} 구성 필드도 참조하십시오. 이는 기기에서 사용되는 터치 스크린의 유형을 나타냅니다. |
키보드 가용성 |
keysexposed keyshidden keyssoft
|
이것은 사용자가 하드웨어 키보드를 여는 경우 애플리케이션 수명 중에 변경될 수 있습니다. 이것이 런타임에 애플리케이션에 어떤 영향을 미치는지 알아보려면 런타임 변경 처리를 참조하십시오. 또한, 구성 필드 {@link android.content.res.Configuration#hardKeyboardHidden}과 {@link android.content.res.Configuration#keyboardHidden}을 참조하십시오. 이 필드는 각각 하드웨어 키보드의 가시성과 모든 종류의 키보드(소프트웨어 포함)의 가시성을 나타냅니다. |
기본 텍스트 입력 메서드 |
nokeys qwerty 12key
|
{@link android.content.res.Configuration#keyboard} 구성 필드도 참조하십시오. 이는 기본 텍스트 입력 메서드를 사용할 수 있는지 여부를 나타냅니다. |
탐색 키 가용성 |
navexposed navhidden
|
이것은 사용자가 탐색 키를 드러내는 경우 애플리케이션 수명 중에 변경될 수 있습니다. 이것이 런타임에 애플리케이션에 어떤 영향을 미치는지 알아보려면 런타임 변경 처리를 참조하십시오. {@link android.content.res.Configuration#navigationHidden} 구성 필드도 참조하십시오. 이는 탐색 키가 숨겨져 있는지 여부를 나타냅니다. |
기본 비터치 탐색 메서드 |
nonav dpad trackball wheel
|
{@link android.content.res.Configuration#navigation} 구성 필드도 참조하십시오. 이는 사용 가능한 탐색 메서드의 유형을 나타냅니다. |
플랫폼 버전(API 레벨) | 예:v3 v4 v7 등. |
기기에서 지원하는 API 레벨입니다. 예를 들어, |
참고: 일부 구성 한정자는 Android
1.0 이후부터 추가되었으므로 모든 Android 버전이 모든 한정자를 지원하는 것은 아닙니다. 새로운 한정자를 사용하면 암시적으로
플랫폼 버전 한정자도 추가하므로 구형 기기가 이를 무시하게 됩니다. 예를 들어
w600dp
한정자를 사용하면 자동적으로 v13
한정자를 포함합니다.
사용 가능한 너비 한정자가 API 레벨 13부터 새로 도입되었기 때문입니다. 문제를 애초에 피하려면, 항상
기본 리소스를 한 세트 포함하세요(한정자 없는 리소스 한 세트). 자세한 정보는
리소스와 연관된 최선의 기기 호환성 제공
을 참조하십시오.
다음은 구성 한정자 이름 사용에 관한 규칙입니다.
drawable-en-rUS-land
는 수평 방향의
US-English 기기에 적용합니다.drawable-hdpi-port/
drawable-port-hdpi/
res/drawable/drawable-en/
는 있을 수 없습니다.drawable-rES-rFR/
이면 안 됩니다. 대신
drawable-rES/
와 drawable-rFR/
같이 적절한 파일이 포함된 두 개의 리소스 디렉터리가 필요합니다.
그러나 두 위치에서 같은 파일을 실제로 복제할 필요는 없습니다. 대신
리소스에 별명을 만들면 됩니다. 아래의 별명 리소스
생성을 참조하십시오.이런 한정자로 이름을 지은 디렉터리에 대체 리소스를 저장하고 나면 Android가 현재 기기 구성에 기초하여 애플리케이션에 자동으로 리소스를 적용합니다. 리소스가 요청될 때마다 Android가 요청한 리소스 파일이 들어있는 대체 리소스 디렉터리를 확인하고, 그런 다음 가장 잘 일치하는 리소스를 찾습니다(아래에서 논함). 특정 기기 구성에 일치하는 대체 리소스가 없는 경우, Android는 상응하는 기본 리소스(구성 한정자를 포함하지 않는 특정 리소스 유형에 대한 리소스 세트 )를 사용합니다.
어떤 리소스를 하나 이상의 기기 구성에서 사용하고자 하는 경우(그렇지만 이를 기본 리소스를 제공하는 것은 원치 않는 경우), 같은 리소스를 하나 이상의 대체 리소스 디렉터리에 넣지 않아도 됩니다. 대신, 기본 리소스 디렉터리에 저장된 리소스에 대해 별명 역할을 하는 대체 리소스를 만들면 됩니다(경우에 따라).
참고: 모든 리소스가 다른 리소스에 대한 별명을 생성할 수 있는 메커니즘을 제공하는 것은 아닙니다. 특히, {@code xml/} 디렉터리의 애니메이션, 메뉴, 원시 및 기타 지정되지 않은 리소스는 이 기능을 제공하지 않습니다.
예를 들어, 애플리케이션 아이콘 {@code icon.png}이 있고 서로 다른 로케일에서 이 아이콘의 고유 버전이 필요한 경우가 있습니다. 그러나 두 로케일, English-Canadian과 French-Canadian은 같은 버전을 사용해야 합니다. 같은 이미지를 English-Canadian과 French-Canadian 양쪽 모두에 대한 리소스 디렉터리에 복사해야 한다고 생각할 수 있지만, 실은 그렇지 않습니다. 대신, 두 로케일에서 사용하는 이미지를 {@code icon_ca.png}( {@code icon.png} 이외에 어떤 이름이든 가능)로 저장하고 이를 기본 {@code res/drawable/} 디렉터리에 넣으면 됩니다. 그런 다음 {@code icon.xml} 파일을 {@code icon_ca.png} 리소스를 참조하는 {@code res/drawable-en-rCA/} 및 {@code res/drawable-fr-rCA/}로 생성합니다. 이때, {@code <bitmap>} 요소를 사용하면 됩니다. 이렇게 하면 PNG 파일 버전 하나와 그것을 가리키는 작은 XML 파일 두 개만 저장할 수 있습니다. (XML 파일 예시는 아래와 같습니다.)
기존 드로어블에 별명을 생성하려면 {@code <bitmap>} 요소를 사용합니다. 예를 들면 다음과 같습니다.
<?xml version="1.0" encoding="utf-8"?> <bitmap xmlns:android="http://schemas.android.com/apk/res/android" android:src="@drawable/icon_ca" />
파일을 ( {@code res/drawable-en-rCA/}와 같은 대체 리소스 디렉터리에) {@code icon.xml}로 저장하면, {@code R.drawable.icon}으로 참조할 수 있지만 실제로는 {@code R.drawable.icon_ca} 리소스({@code res/drawable/}에 저장됨)의 별명인 리소스로 컴파일링됩니다.
기존 레이아웃에 별명을 생성하려면 {@code <merge>}로 래핑되어 있는 {@code <include>} 요소를 사용합니다. 예:
<?xml version="1.0" encoding="utf-8"?> <merge> <include layout="@layout/main_ltr"/> </merge>
파일을 {@code main.xml}로 저장하면, {@code R.layout.main}으로 참조할 수 있지만 실제로는 {@code 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>
이제 {@code R.string.hi} 리소스는 {@code R.string.hello}의 별명입니다.
기타 단순 값도 같은 방식으로 동작합니다. 예를 들면 색상은 다음과 같습니다.
<?xml version="1.0" encoding="utf-8"?> <resources> <color name="yellow">#f00</color> <color name="highlight">@color/red</color> </resources>
애플리케이션이 여러 기기 구성을 지원하게 하려면, 언제나 애플리케이션이 사용하는 각 유형의 리소스에 기본 리소스를 제공하는 것이 매우 중요합니다.
예를 들어 애플리케이션이 여러 언어를 지원할 경우, 항상 언어 및 지역 한정자 없이 {@code values/} 디렉터리(여기에 문자열 저장)를 포함시켜야 합니다. 그렇게 하지 않고 언어와 지역 한정자가 있는 디렉터리에 모든 문자열을 넣으면, 문자열이 지원하지 않는 언어로 설정된 기기에서 애플리케이션을 실행하면 작동이 중단됩니다. 그러나 기본 {@code values/} 리소스를 제공하는 한은 애플리케이션이 제대로 실행됩니다(사용자가 이해하지 못하는 언어로라도 작동합니다. 작동 중단보다 낫습니다.)
마찬가지로 화면 방향에 기초하여 여러 가지 레이아웃 리소스를 제공하는 경우 하나의 방향을 기본값으로 선택해야 합니다. 예를 들어 가로 방향에는 {@code layout-land/}로, 세로 방향에는 {@code layout-port/}로 레이아웃 리소스를 제공하는 대신 하나를 기본으로 남겨두십시오. 가로 방향에 {@code layout/}, 세로 방향에 {@code layout-port/}와 같은 식으로 하면 됩니다.
애플리케이션이 예상치 못한 구성에서 실행될 수 있을 뿐만 아니라 Android의 새 버전에서 이전 버전에서는 지원하지 않는 구성 한정자를 추가할 수도 있으므로, 기본 리소스를 제공하는 것이 중요합니다. 새 리소스 한정자를 사용하지만, Android 이전 버전과 코드 호환성은 유지한 경우, 그 후 Android 이전 버전이 애플리케이션을 실행하면 새로운 한정자로 이름을 지정한 리소스를 사용할 수 없으므로 기본 리소스를 제공하지 않으면 애플리케이션 작동이 중단됩니다. 예를 들어, {@code minSdkVersion}이 4로 설정되고 야간 모드(API 레벨 8에서 추가된 {@code night} 또는 {@code notnight})를 사용하는 모든 드로어블 리소스를 한정할 경우, API 레벨 4 기기는 드로어블 리소스에 액세스하지 못하고 사용이 중단됩니다. 이 경우, {@code notnight}를 기본 리소스로 제공하는 것이 좋습니다. 그래야 해당 한정자를 배제하고 드로어블 리소스가 {@code drawable/} 또는 {@code drawable-night/}이 됩니다.
그러므로 최선의 기기 호환성을 제공하려면 언제나 애플리케이션에서 반드시 제대로 수행해야 하는 리소스에 대해 기본 리소스를 제공하십시오. 그런 다음 구성 한정자를 사용하여 특정 기기 구성에 대해 대체 리소스를 생성하면 됩니다.
이 규칙에는 한 가지 예외가 있습니다. 애플리케이션의 {@code minSdkVersion} 이 4 이상이면 화면 밀도 한정자로 대체 드로어블 리소스를 제공할 때 기본 드로어블 리소스가 없어도 됩니다. 기본 드로어블 리소스가 없더라도 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는 기기 구성을 이용 가능한 대체 리소스와 비교하여, {@code drawable-en-port}에서 드로어블을 선택합니다.
시스템은 다음과 같은 논리에 따라 어느 리소스를 사용할지 결정합니다.
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/
를 제거하지 않습니다.
자세한 정보는 다중 화면
지원 문서에서 이용하실 수 있습니다.
drawable/drawable-en/ drawable-en-port/ drawable-en-notouch-12key/drawable-port-ldpi/drawable-port-notouch-12key/
예외: 문제의 한정자가 화면 픽셀 밀도라면, Android는 기기 화면 밀도와 가장 가깝게 일치하는 옵션을 선택합니다. 일반적으로, Android는 작은 원본 이미지를 확대하는 것보다 큰 원본 이미지를 축소하는 것을 선호합니다. 다중 화면 지원을 참조하십시오.
drawable-en/drawable-en-port/drawable-en-notouch-12key/
남은 디렉터리는 {@code drawable-en-port}입니다.
이 절차는 요청된 각 리소스에 대해 실행하지만, 시스템이 몇 가지 측면을 추가로 최적화합니다. 그러한 최적화 가운데에는 일단 기기 구성을 알게 되고 나면 절대 일치할 가능성이 없는 대체 리소스를 시스템이 제거할 수 있다는 점도 있습니다. 예를 들어, 구성 언어가 영어("en")이고 영어 이외의 다른 언어 한정자로 설정된 리소스 디렉터리는 절대 확인된 리소스 풀에 포함되지 않습니다( 언어 한정자가 포함되지 않는 리소스 디렉터리는 여전히 포함됩니다).
화면 크기 한정자에 기초하여 리소스를 선택할 때 시스템은 가장 잘 일치하는 리소스가 없다면 현재 화면보다 작은 화면에 지정된 리소스를 사용합니다 (예를 들어, 큰 화면은 필요에 따라 일반 크기 화면 리소스를 사용합니다). 그러나 이용 가능한 리소스가 현재 화면보다 큰 리소스뿐이라면, 시스템은 이를 사용하지 않고, 기기 구성에 일치하는 리소스가 없으면 애플리케이션 사용이 중단됩니다 (예를 들어 모든 레이아웃 리소스가 {@code xlarge} 한정자에 태그되어 있지만, 기기가 보통 크기 화면일 경우).
참고: 한정자의 우선 순위(표 2 참조)가 기기와 정확하게 일치하는
한정자 수보다 더 중요합니다. 예를 들어 위의 4단계에서
목록의 마지막 선택에 기기와 정확히 일치하는 한정자가 세 개 포함되어 있지만(방향, 터치 스크린
유형 및 입력 메서드), drawable-en
에는 일치하는 매개변수가
하나뿐입니다(언어). 다만, 언어가 이러한 다른 한정자보다 우선 순위가 높기 때문에
drawable-port-notouch-12key
는 탈락합니다.
애플리케이션에서 리소스를 사용하는 것에 대한 자세한 정보는 리소스 액세스로 계속 진행하여 알아보십시오.