XAML 개요
이 문서에서는 Windows 런타임 앱 개발자에게 XAML 언어와 XAML 개념을 소개하고, XAML에서 Windows 런타임 앱을 만드는 데 사용되는 개체를 선언하고 특성을 설정하는 다양한 방법을 설명합니다.
XAML이란?
XAML(Extensible Application Markup Language)을 선언형 언어로 사용. 구체적으로 XAML은 여러 개체 간의 계층 구조 관계를 보여 주는 언어 구조와 형식 확장을 지원하는 백업 입력 규칙을 사용하여 개체를 초기화하고 개체 속성을 설정할 수 있습니다. 선언형 XAML 태그에 표시되는 UI 요소를 만들 수 있습니다. 그런 다음 이벤트에 응답하고 XAML에서 원래 선언한 개체를 조작할 수 있는 각 XAML 파일에 대해 별도의 코드 숨김 파일을 연결할 수 있습니다.
XAML 언어는 개발 프로세스에서 다른 도구와 역할 간에 원본 교환을 지원합니다(예: 디자인 도구와 IDE(대화형 개발 환경) 간에 또는 기본 개발자와 지역화 개발자 간에 XAML 원본 교환). XAML을 교환 형식으로 사용하면 디자이너 역할과 개발자 역할을 별도로 유지하거나 함께 가져올 수 있으며, 디자이너와 개발자는 앱을 제작하는 동안 반복할 수 있습니다.
Windows 런타임 앱 프로젝트의 일부로 표시되는 경우 XAML 파일은 .xaml 파일 이름 확장명을 가진 XML 파일입니다.
기본 XAML 구문
XAML에는 XML을 기반으로 하는 기본 구문이 있습니다. 정의에 따라 유효한 XAML도 유효한 XML이어야 합니다. 그러나 XAML은 XML 1.0 사양의 XML에서 유효한 반면 다른 더 완전한 의미가 할당된 구문 개념을 사용합니다. 예를 들어 XAML은 속성 요소 구문을 지원합니다. 속성 값은 특성의 문자열 값이나 콘텐츠가 아닌 요소 내에서 설정할 수 있습니다. 일반 XML의 경우 XAML 속성 요소는 이름에 점이 있는 요소이므로 일반 XML에는 유효하지만 의미는 동일하지 않습니다.
XAML 및 Visual Studio
Microsoft Visual Studio를 사용하면 XAML 텍스트 편집기와 보다 그래픽 지향적인 XAML 디자인 화면에서 유효한 XAML 구문을 생성할 수 있습니다. Visual Studio를 사용하여 앱에 대한 XAML을 작성할 때는 키 입력 방식 구문에 대해서는 크게 걱정할 필요가 없습니다. IDE는 자동 완성 힌트를 제공하거나, Microsoft IntelliSense 목록 및 드롭다운에 텍스트 제안을 표시하거나, 도구 상자 창에 UI 요소 라이브러리를 표시하거나, 다른 기술을 제공하여 유효한 XAML 구문을 작성하는 데 도움을 줍니다. XAML을 처음 사용하는 경우 참조 또는 다른 항목에서 XAML 구문에 대해 설명할 때 구문 규칙 특히, 제한 사항이나 선택 옵션을 설명하는 데 사용되는 용어에 대해 알아두면 좋습니다. XAML 구문에 대한 이러한 세부 요점에 대해서는 XAML 구문 가이드 항목에서 별도로 설명합니다.
XAML 네임스페이스
일반 프로그래밍에서 네임스페이스는 프로그래밍 엔터티의 식별자를 해석하는 방법을 결정하는 구성 개념입니다. 프로그래밍 프레임워크는 네임스페이스를 사용하여 사용자 선언 식별자를 프레임워크 선언 식별자와 분리하고, 네임스페이스 자격을 통해 식별자를 구분하고, 이름 범위 지정 규칙을 적용할 수 있습니다. XAML에는 XAML 언어에 이 용도로 사용되는 자체 XAML 네임스페이스 개념이 있습니다. XAML이 XML 언어 네임스페이스 개념을 적용하고 확장하는 방법은 다음과 같습니다.
- XAML은 네임스페이스 선언에 예약된 XML 특성 xmlns 를 사용합니다. 특성 값은 일반적으로 XML에서 상속되는 규칙인 URI(Uniform Resource Identifier)입니다.
- XAML은 선언의 접두사를 사용하여 기본이 아닌 네임스페이스를 선언하고 요소 및 특성의 접두사 사용은 해당 네임스페이스를 참조합니다.
- XAML에는 기본 네임스페이스의 개념이 있습니다. 이 네임스페이스는 사용 또는 선언에 접두사가 없을 때 사용되는 네임스페이스입니다. 기본 네임스페이스는 각 XAML 프로그래밍 프레임워크에 대해 다르게 정의할 수 있습니다.
- 네임스페이스 정의는 부모 요소에서 자식 요소로 XAML 파일 또는 구문에서 상속됩니다. 예를 들어 XAML 파일의 루트 요소에서 네임스페이스를 정의하는 경우 해당 파일 내의 모든 요소가 네임스페이스 정의를 상속합니다. 페이지에 추가된 요소가 네임스페이스를 재정의하는 경우 해당 요소의 하위 항목은 새 정의를 상속합니다.
- 요소의 특성은 요소의 네임스페이스를 상속합니다. XAML 특성에 접두사를 보는 것은 매우 드문 일입니다.
XAML 파일은 거의 항상 루트 요소에서 기본 XAML 네임스페이스를 선언합니다. 기본 XAML 네임스페이스는 접두사로 한정하지 않고 선언할 수 있는 요소를 정의합니다. 일반적인 Windows 런타임 앱 프로젝트의 경우 이 기본 네임스페이스에는 기본 컨트롤, 텍스트 요소, XAML 그래픽 및 애니메이션, 데이터 바인딩 및 스타일 지정 지원 형식 등 UI 정의에 사용되는 Windows 런타임 대한 모든 기본 제공 XAML 어휘가 포함됩니다. 따라서 Windows 런타임 앱에 대해 작성할 대부분의 XAML은 일반적인 UI 요소를 참조할 때 XAML 네임스페이스 및 접두사를 사용하지 않도록 할 수 있습니다.
다음은 앱의 초기 페이지에 대해 템플릿으로 만든 Page 루트를 보여 주는 코드 조각입니다(여는 태그만 표시하여 간소화함). 기본 네임스페이스 및 x 네임스페이스도 선언합니다(다음에 설명하겠습니다).
<Page
x:Class="Application1.BlankPage"
xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
>
XAML 언어 XAML 네임스페이스
거의 모든 Windows 런타임 XAML 파일에서 선언되는 특정 XAML 네임스페이스 중 하나는 XAML 언어 네임스페이스입니다. 이 네임스페이스에는 XAML 언어 사양으로 정의된 요소 및 개념이 포함되어 있습니다. 규칙에 따라 XAML 언어 XAML 네임스페이스는 접두사 "x"에 매핑됩니다. Windows 런타임 앱 프로젝트에 대한 기본 프로젝트 및 파일 템플릿은 항상 기본 XAML 네임스페이스(접두사 없음, 그냥xmlns=)와 XAML 언어 XAML 네임스페이스(접두사 "x")를 루트 요소의 일부로 정의합니다.
"x" 접두사/XAML 언어의 XAML 네임스페이스에는 XAML에서 자주 사용하게 될 여러 프로그래밍 구문이 들어 있습니다. 가장 일반적인 방법은 다음과 같습니다.
| 용어 | 설명 |
|---|---|
| x:Key | XAML ResourceDictionary의 각 리소스에 대해 고유한 사용자 정의 키를 설정합니다. 키의 토큰 문자열은 StaticResource 태그 확장에 대한 인수이며 나중에 이 키를 사용하여 앱의 XAML에 있는 다른 XAML 사용량에서 XAML 리소스를 검색합니다. |
| x:Class: | 코드 네임스페이스 및 XAML 페이지에 대한 코드 숨김을 제공하는 클래스의 코드 클래스 이름을 지정합니다. 앱을 빌드할 때 빌드 작업에서 만들거나 조인하는 클래스의 이름을 지정합니다. 이러한 빌드 작업은 XAML 태그 컴파일러를 지원하고 앱이 컴파일될 때 태그와 코드 숨김을 결합합니다. XAML 페이지에 대한 코드 숨김을 지원하려면 이러한 클래스가 있어야 합니다. 기본 Windows 런타임 활성화 모델의 Window.Content |
| x:Name | XAML로 정의한 개체 요소가 처리된 후 런타임 코드에 있는 인스턴스에 대한 런타임 개체 이름을 지정합니다. XAML에서 x:Name을 설정하는 것은 코드에서 명명된 변수를 선언하는 것과 같다고 생각할 수 있습니다. 나중에 알아보겠으므로 XAML이 Windows 런타임 앱의 구성 요소로 로드될 때 정확히 발생합니다. 참고 Name 는 프레임워크에서 비슷한 속성이지만 모든 요소가 지원하는 것은 아닙니다. 해당 요소 형식에서 FrameworkElement.Name이 지원되지 않는 경우 요소 식별을 위해 x:Name을 사용합니다. |
| x:Uid | 일부 속성 값에 대해 지역화된 리소스를 사용해야 하는 요소를 식별합니다. x:Uid를 사용하는 방법에 대한 자세한 내용은 빠른 시작: UI 리소스 번역을 참조하세요. |
| XAML 기본 데이터 형식 | 이러한 형식은 특성 또는 리소스에 필요한 경우 단순 값 형식에 대한 값을 지정할 수 있습니다. 이러한 내장 형식은 일반적으로 각 프로그래밍 언어의 내장 정의의 일부로 정의되는 단순 값 형식에 해당합니다. 예를 들어 스토리보드 시각적 상태에서 사용할 trueObjectAnimationUsingKeyFrames 부울 값을 나타내는 개체가 필요할 수 있습니다. XAML 해당 값의 경우 x:Boolean 내부 형식을 다음과 같이 개체 요소로 사용합니다. <x:Boolean>True</x:Boolean> |
XAML 언어 XAML 네임스페이스의 다른 프로그래밍 구문은 존재하지만 일반적이지는 않습니다.
XAML 네임스페이스에 사용자 지정 형식 매핑
언어로 XAML의 가장 강력한 측면 중 하나는 Windows 런타임 앱에 대한 XAML 어휘를 쉽게 확장할 수 있다는 것입니다. 앱의 프로그래밍 언어로 사용자 고유의 사용자 지정 형식을 정의한 다음 XAML 태그에서 사용자 지정 형식을 참조할 수 있습니다. 사용자 지정 형식을 통한 확장 지원은 기본적으로 XAML 언어의 작동 방식에 기본 제공되어 있습니다. 프레임워크 또는 앱 개발자는 XAML에서 참조하는 지원 개체를 만들어야 합니다. 프레임워크와 앱 개발자 모두 해당 어휘의 개체가 나타내는 사양으로 제한되지 않으며 기본 XAML 구문 규칙을 어기고 작업하지도 않습니다. (XAML 언어 XAML 네임스페이스 형식에는 몇 가지 요건이 충족되어야 하지만 Windows 런타임은 필요한 모든 지원을 제공합니다.)
Windows 런타임 핵심 라이브러리 및 메타데이터 이외의 라이브러리에서 제공되는 형식에 XAML을 사용하는 경우 접두사를 사용하여 XAML 네임스페이스를 선언하고 매핑해야 합니다. 요소 사용에서 해당 접두사를 사용하여 라이브러리에 정의된 형식을 참조합니다. 접두사 매핑은 일반적으로 다른 XAML 네임스페이스 정의와 함께 루트 요소에서 xmlns 특성으로 선언합니다.
사용자 지정 형식을 참조하는 고유한 네임스페이스 정의를 만들려면 먼저 키워드(keyword) xmlns:를 지정한 다음 원하는 접두사를 지정합니다. 해당 특성의 값에는 값의 첫 번째 부분으로 사용하는 키워드(keyword)가 포함되어야 합니다. 값의 re기본der는 사용자 지정 형식을 포함하는 특정 코드 지원 네임스페이스를 이름으로 참조하는 문자열 토큰입니다.
접두사는 해당 XAML 파일에서 남은 태그에서 해당 XAML 네임스페이스를 참조하는 데 사용되는 태그 토큰을 정의합니다. 콜론 문자(:)는 XAML 네임스페이스 내에서 참조할 접두사와 엔터티 사이를 이동합니다.
예를 들어 myTypes 접두사를 myCompany.myTypes 네임스페이스에 매핑하는 특성 구문은 xmlns:myTypes="using:myCompany.myTypes"이며 대표적인 요소의 사용 예는 다음과 같습니다. <myTypes:CustomButton/>
Visual C++ 구성 요소 확장(C++/CX)에 대한 특별한 고려 사항을 포함하여 사용자 지정 형식에 대한 XAML 네임스페이스 매핑에 대한 자세한 내용은 XAML 네임스페이스 및 네임스페이스 매핑을 참조하세요.
기타 XAML 네임스페이스
접두사 "d"(디자이너 네임스페이스의 경우) 및 "mc"(태그 호환성용)를 정의하는 XAML 파일이 자주 표시됩니다. 일반적으로 이러한 파일은 인프라를 지원하거나, 디자인 타임 도구의 시나리오를 가능하게 하기 위한 것입니다. 자세한 내용은 XAML 네임스페이스 항목의 "기타 XAML 네임스페이스" 섹션을 참조하세요.
태그 확장
태그 확장은 Windows 런타임 XAML 구현에서 자주 사용되는 XAML 언어 개념입니다. 태그 확장은 종종 XAML 파일이 단순히 지원 형식에 따라 요소를 선언하지 않는 값이나 동작에 액세스할 수 있도록 하는 일종의 "바로 가기"를 나타냅니다. 일부 태그 확장은 구문을 간소화하거나 다른 XAML 파일 간의 팩터링을 목표로 일반 문자열 또는 추가로 중첩된 요소를 사용하여 속성을 설정할 수 있습니다.
XAML 특성 구문에서 중괄호 "{" 및 "}"는 XAML 태그 확장 사용을 나타냅니다. 이 사용에서는 특성 값의 일반적인 처리를 리터럴 문자열이나 문자열 변환 가능 값으로 이스케이프하도록 XAML에 지시합니다. 대신 XAML 파서는 특정 태그 확장에 대한 동작을 제공하는 코드를 호출하고, 해당 코드는 XAML 파서에 필요한 대체 개체 또는 동작 결과를 제공합니다. 태그 확장에는 태그 확장 이름을 따르는 인수가 있을 수 있으며 중괄호 안에도 포함됩니다. 일반적으로 평가된 태그 확장은 개체 반환 값을 제공합니다. 구문 분석하는 동안 해당 반환 값은 태그 확장 사용이 원본 XAML에 있었던 개체 트리의 위치에 삽입됩니다.
Windows 런타임 XAML은 기본 XAML 네임스페이스 아래에 정의되고 Windows 런타임 XAML 파서에서 인식되는 이러한 태그 확장을 지원합니다.
- {x:Bind}: 컴파일 타임에 생성하는 특수 용도의 코드를 실행하여 런타임까지 속성 평가를 지연하는 데이터 바인딩을 지원합니다. 이 태그 확장은 광범위한 인수를 지원합니다.
- {Binding}: 범용 런타임 개체 검사를 실행하여 런타임까지 속성 평가를 지연하는 데이터 바인딩을 지원합니다. 이 태그 확장은 광범위한 인수를 지원합니다.
- {StaticResource}: ResourceDictionary에 정의되는 참조 리소스 값을 지원합니다. 이러한 리소스는 다른 XAML 파일에 있을 수 있지만 궁극적으로 로드 시 XAML 파서에서 찾을 수 있어야 합니다.
{StaticResource}사용 인수는 ResourceDictionary의 키가 지정된 리소스의 키(이름)를 식별합니다. - {ThemeResource}: {StaticResource}이지만 런타임 테마 변경에 응답할 수 있습니다. {ThemeResource}는 Windows 런타임 기본 XAML 템플릿에 자주 나타납니다. 이러한 템플릿의 대부분은 앱이 실행되는 동안 테마를 전환하는 사용자와의 호환성을 위해 설계되었기 때문입니다.
- {TemplateBinding}: XAML의 컨트롤 템플릿과 런타임에 최종 사용을 지원하는 {Binding}의 특수한 경우입니다.
- {RelativeSource}: 템플릿이 있는 부모에서 값이 제공되는 특정 형식의 템플릿 바인딩을 사용하도록 설정합니다.
- {CustomResource}: 고급 리소스 조회 시나리오입니다.
Windows 런타임 {x:Null} 태그 확장도 지원합니다. XAML에서 Nullable 값을 null로 설정하는 데 사용합니다. 예를 들어 CheckBoxnull을 결정할 수 없는 확인 상태로 해석하는 에 대한 컨트롤 템플릿에서 이 태그 확장을 사용할 수 있습니다(“결정할 수 없는” 시각적 상태 트리거).
태그 확장은 일반적으로 앱에 대한 개체 그래프의 일부 다른 부분에서 기존 인스턴스를 반환하거나 값을 런타임까지 지연합니다. 태그 확장을 특성 값으로 사용할 수 있으며 일반적인 사용법이므로 태그 확장에서 속성 요소 구문이 필요할 수 있는 참조 형식 속성에 대한 값을 제공하는 경우가 많습니다.
예를 들어, Style에서 재사용 가능한 ResourceDictionary를 참조하기 위한 구문은 다음과 같습니다. <Button Style="{StaticResource SearchButtonStyle}"/>. Style은 단순 값이 아니라 참조 형식이므로 {StaticResource}를 사용하지 않을 경우 <Button.Style> 속성을 설정하려면 XAML 내부에 <Style> 속성 요소 및 FrameworkElement.Style 정의가 필요합니다.
태그 확장을 사용하면 XAML에서 설정할 수 있는 모든 속성은 특성 구문에서 설정할 수 있습니다. 특성 구문을 사용하여 직접 개체 인스턴스화에 대한 특성 구문을 지원하지 않더라도 속성에 대한 참조 값을 제공할 수 있습니다. 또는 XAML 속성이 값 형식 또는 새로 만든 참조 형식으로 채워지는 일반적인 요구 사항을 지연시키는 특정 동작을 사용하도록 설정할 수 있습니다.
To illustrate, the next XAML example sets the value of the FrameworkElement.Style property of a Border by using attribute syntax. FrameworkElement.Style 속성은 기본적으로 특성 구문 문자열을 사용하여 만들 수 없는 참조 형식인 Windows.UI.Xaml.Style 클래스의 인스턴스를 가져옵니다. 하지만 이 경우 특성은 특정 태그 확장인 StaticResource를 참조합니다. 해당 태그 확장이 처리되면 이전에 리소스 사전에서 키가 지정된 리소스로 인스턴스화된 스타일에 대한 참조를 반환합니다.
<Canvas.Resources>
<Style TargetType="Border" x:Key="PageBackground">
<Setter Property="BorderBrush" Value="Blue"/>
<Setter Property="BorderThickness" Value="5"/>
</Style>
</Canvas.Resources>
...
<Border Style="{StaticResource PageBackground}">
...
</Border>
태그 확장을 중첩할 수 있습니다. 가장 안쪽의 태그 확장이 먼저 계산됩니다.
태그 확장으로 인해 특성의 리터럴 "{" 값에 대한 특수 구문이 필요합니다. 자세한 내용은 XAML 구문을 참조하세요.
이벤트
XAML은 개체 및 해당 속성에 대한 선언적 언어이지만 태그의 개체에 이벤트 처리기를 연결하는 구문도 포함합니다. 그런 다음 XAML 이벤트 구문은 Windows 런타임 프로그래밍 모델을 통해 XAML로 선언된 이벤트를 통합할 수 있습니다. 이벤트 이름을 이벤트가 처리되는 개체의 특성 이름으로 지정합니다. 특성 값의 경우 코드에서 정의하는 이벤트 처리기 함수의 이름을 지정합니다. XAML 프로세서는 이 이름을 사용하여 로드된 개체 트리에서 대리자 표현을 만들고 지정된 처리기를 내부 처리기 목록에 추가합니다. 거의 모든 Windows 런타임 앱은 태그 및 코드 숨김 소스 모두에 의해 정의됩니다.
다음은 간단한 예제입니다. Button 클래스는 Click라는 이벤트를 지원합니다. 사용자가 단추를 클릭한 후 호출해야 하는 코드를 실행하는 Click에 대한 처리기를 작성할 수 있습니다. XAML에서 Click을 단추의 특성으로 지정합니다. 특성 값의 경우 처리기의 메서드 이름인 문자열을 제공합니다.
<Button Click="showUpdatesButton_Click">Show updates</Button>
컴파일할 때 컴파일러는 이제 XAML 페이지의 showUpdatesButton_Clickx:Class 값에 선언된 네임스페이스에 코드 숨김 파일에 정의된 메서드가 있을 것으로 예상합니다. 또한 이 메서드는 Click 이벤트의 위임 계약을 충족해야 합니다. 예시:
namespace App1
{
public sealed partial class MainPage: Page {
...
private void showUpdatesButton_Click (object sender, RoutedEventArgs e) {
//your code
}
}
}
' Namespace included at project level
Public NotInheritable Class MainPage
Inherits Page
...
Private Sub showUpdatesButton_Click (sender As Object, e As RoutedEventArgs e)
' your code
End Sub
...
End Class
namespace winrt::App1::implementation
{
struct MainPage : MainPageT<MainPage>
{
...
void showUpdatesButton_Click(Windows::Foundation::IInspectable const&, Windows::UI::Xaml::RoutedEventArgs const&);
};
}
// .h
namespace App1
{
public ref class MainPage sealed {
...
private:
void showUpdatesButton_Click(Object^ sender, RoutedEventArgs^ e);
};
}
프로젝트 내에서 XAML은 .xaml 파일로 작성되며 원하는 언어(C#, Visual Basic, C++/CX)를 사용하여 코드 숨김 파일을 작성합니다. XAML 파일이 빌드 액션의 일부로 태그 컴파일될 때 XAML 파일에 대한 XAML 코드 숨김 파일의 위치는 네임스페이스와 클래스를 XAML 루트 요소의 x:Class 특성으로 지정하여 식별합니다. XAML에서 이러한 메커니즘이 작동하는 방식 및 프로그래밍 및 애플리케이션 모델과 관련된 방법에 대한 자세한 내용은 이벤트 및 라우트된 이벤트 개요를 참조하세요.
참고 항목
C++/CX의 경우 두 개의 코드 숨김 파일이 있습니다. 하나는 헤더(.xaml.h)이고 다른 하나는 구현(.xaml.cpp)입니다. 구현은 헤더를 참조하며, 기술적으로 코드 숨김 연결의 진입점을 나타내는 헤더입니다.
리소스 사전
ResourceDictionary를 만드는 것은 일반적으로 XAML 페이지의 영역 또는 개별 XAML 파일로 리소스 사전을 작성하여 수행하는 일반 작업입니다. 리소스 사전 및 사용 방법은 이 항목의 범위를 벗어나는 더 큰 개념 영역입니다. 자세한 내용은 ResourceDictionary 및 XAML 리소스 참조를 확인하세요.
XAML 및 XML
XAML 언어는 기본적으로 XML 언어를 기반으로 합니다. 그러나 XAML은 XML을 크게 확장합니다. 특히 지원 형식 개념과의 관계 때문에 스키마의 개념을 매우 다르게 처리하고 연결된 멤버 및 태그 확장과 같은 언어 요소를 추가합니다. xml:lang 은 XAML에서 유효하지만 구문 분석 동작이 아닌 런타임에 영향을 미치며 일반적으로 프레임워크 수준 속성에 별칭이 지정됩니다. 자세한 내용은 FrameworkElement.Language를 참조하세요. xml:base는 태그에 유효하지만 파서에서는 무시됩니다. xml:space는 유효하지만 XAML 및 공백 항목에 설명된 시나리오에만 해당됩니다. 인코딩 특성은 XAML에서 유효합니다. UTF-8 및 UTF-16 인코딩만 지원됩니다. UTF-32 인코딩은 지원되지 않습니다.
XAML에서의 대/소문자 구분
XAML은 대/소문자를 구분합니다. 이는 대/소문자를 구분하는 XML을 기반으로 하는 XAML의 또 다른 결과입니다. 요소 및 특성 이름은 대/소문자를 구분합니다. 특성 값은 대/소문자를 구분할 수 있습니다. 이는 특성 값이 특정 속성에 대해 처리되는 방식에 따라 달라집니다. 예를 들어 특성 값이 열거형의 멤버 이름을 선언하는 경우 열거형 멤버 값을 반환하도록 멤버 이름 문자열을 형식 변환하는 기본 제공 동작은 대/소문자를 구분하지 않습니다. 반면 Name 속성의 값과 Name 속성이 선언하는 이름을 기반으로 개체 작업을 위한 유틸리티 메서드는 이름 문자열을 대/소문자를 구분하는 것으로 처리합니다.
XAML 이름 범위
XAML 언어는 XAML 이름 범위의 개념을 정의합니다. XAML 이름 범위 개념은 XAML 프로세서가 XAML 요소에 적용된 x:Name 또는 Name 값을 처리하는 방법, 특히 이름을 고유 식별자로 사용해야 하는 범위에 영향을 줍니다. XAML 이름 범위는 별도의 항목에서 자세히 설명합니다. XAML 이름 스코프를 참조 하세요.
개발 프로세스에서 XAML의 역할
XAML은 앱 개발 프로세스에서 몇 가지 중요한 역할을 합니다.
- C#, Visual Basic 또는 C++/CX를 사용하여 프로그래밍하는 경우 XAML은 앱의 UI 및 해당 UI의 요소를 선언하는 기본 형식입니다. 일반적으로 프로젝트에서 하나 이상의 XAML 파일은 처음에 표시된 UI에 대한 앱의 페이지 은유를 나타냅니다. 추가 XAML 파일은 탐색 UI에 대한 추가 페이지를 선언할 수 있습니다. 다른 XAML 파일은 템플릿 또는 스타일과 같은 리소스를 선언할 수 있습니다.
- 앱의 컨트롤 및 UI에 적용된 스타일 및 템플릿을 선언하는 데 XAML 형식을 사용합니다.
- 기존 컨트롤의 템플릿을 사용하거나 기본 템플릿을 컨트롤 패키지의 일부로 제공하는 컨트롤을 정의하는 경우 스타일 및 템플릿을 사용할 수 있습니다. 스타일 및 템플릿을 정의하는 데 사용하는 경우 ResourceDictionary 루트를 사용하여 관련 XAML을 별개의 XAML 파일로 선언하는 경우가 많습니다.
- XAML은 앱 UI를 만들고 다른 디자이너 앱 간에 UI 디자인을 교환하는 디자이너 지원의 일반적인 형식입니다. 특히 앱용 XAML은 다른 XAML 디자인 도구(또는 도구 내 디자인 창) 간에 교환할 수 있습니다.
- 다른 여러 기술은 XAML의 기본 UI도 정의합니다. WPF(Windows Presentation Foundation) XAML 및 Microsoft Silverlight XAML과 관련하여 Windows 런타임 XAML은 공유 기본 XAML 네임스페이스에 대해 동일한 URI를 사용합니다. Windows 런타임 대한 XAML 어휘는 Silverlight에서 사용되는 XAML for-UI 어휘와 크게 겹치며 WPF에서 약간 더 적은 범위로 사용됩니다. 따라서 XAML은 XAML을 사용한 전구체 기술에 대해 원래 정의된 UI에 대한 효율적인 마이그레이션 경로를 촉진합니다.
- XAML은 UI의 시각적 모양을 정의하고 연결된 코드 숨김 파일은 논리를 정의합니다. 코드 숨김에서 논리를 변경하지 않고도 UI 디자인을 조정할 수 있습니다. XAML은 디자이너와 개발자 간의 워크플로를 간소화합니다.
- XAML 언어에 대한 시각적 디자이너 및 디자인 화면 지원이 풍부하기 때문에 XAML은 초기 개발 단계에서 신속한 UI 프로토타입 생성을 지원합니다.
개발 프로세스에서 사용자 고유의 역할에 따라 XAML과 상호 작용하지 않을 수 있습니다. XAML 파일과 상호 작용하는 정도는 사용 중인 개발 환경, 도구 상자 및 속성 편집기와 같은 대화형 디자인 환경 기능을 사용하는지 여부, Windows 런타임 앱의 범위 및 목적에 따라 달라집니다. 그럼에도 불구하고 앱을 개발하는 동안 텍스트 또는 XML 편집기를 사용하여 요소 수준에서 XAML 파일을 편집할 가능성이 높습니다. 이 정보를 사용하여 텍스트 또는 XML 표현에서 XAML을 자신 있게 편집하고 도구, 태그 컴파일 작업 또는 Windows 런타임 앱의 런타임 단계에서 사용할 때 해당 XAML 파일의 선언 및 목적의 유효성을 확인할 기본 있습니다.
부하 성능을 위해 XAML 최적화
다음은 성능 모범 사례를 사용하여 XAML에서 UI 요소를 정의하기 위한 몇 가지 팁입니다. 이러한 팁의 대부분은 XAML 리소스 사용과 관련이 있지만 편의를 위해 일반적인 XAML 개요에 나와 있습니다. XAML 리소스에 대한 자세한 내용은 ResourceDictionary 및 XAML 리소스 참조를 참조하세요 . XAML에서 피해야 하는 성능 저하 사례를 의도적으로 보여주는 XAML을 비롯한 성능에 대한 몇 가지 추가 팁은 XAML 태그 최적화를 참조하세요.
- XAML에서 같은 색 브러시를 자주 사용하는 경우에는 매번 명명된 색을 특성 값으로 사용하지 말고 SolidColorBrush를 리소스로 정의합니다.
- 여러 UI 페이지에서 같은 리소스를 사용하는 경우에는 각 페이지가 아니라 Resources에서 리소스를 정의하는 것이 좋습니다. 반대로 한 페이지만 리소스를 사용하는 경우 Application.Resources에서 정의하지 말고 필요한 페이지에 대해서만 정의합니다. 이는 앱을 디자인하는 동안 XAML 팩터링과 XAML 구문 분석 중 성능 모두에 적합합니다.
- 앱이 패키지하는 리소스의 경우 사용되지 않는 리소스(키가 있지만 앱에서 사용하는 StaticResource 참조가 없는 리소스)에 대해 검사. 앱을 릴리스하기 전에 XAML에서 제거합니다.
- 디자인 리소스(MergedDictionaries)를 제공하는 별도의 XAML 파일을 사용하고 있다면 사용되지 않는 리소스를 주석으로 처리하거나 이 파일에서 제거하는 것이 좋습니다. 둘 이상의 앱에서 사용 중이거나 모든 앱에 공통 리소스를 제공하는 공유 XAML 시작 지점이 있더라도 항상 XAML 리소스를 패키지하고 잠재적으로 로드해야 하는 앱입니다.
- 컴퍼지션에 필요하지 않은 UI 요소를 정의하지 말고 가능하면 기본 컨트롤 템플릿을 사용합니다(이러한 템플릿은 이미 부하 성능을 테스트하고 확인됨).
- UI 요소를 의도적으로 과도하게 그리지 말고 Border와 같은 컨테이너를 사용합니다. 기본적으로 동일한 픽셀을 여러 번 그리지 마세요. 과도하게 그리기 및 테스트 방법에 대한 자세한 내용은 DebugSettings.IsOverdrawHeatMapEnabled를 참조하세요.
- ListView 또는 GridView에 대한 기본 항목 템플릿을 사용하세요. 여기에는 많은 목록 항목에 대해 시각적 트리를 빌드할 때 성능 문제를 해결하는 특수한 Presenter 논리가 있습니다.
XAML 디버그
XAML은 태그 언어이므로 Microsoft Visual Studio 내에서 디버깅하기 위한 일반적인 전략 중 일부는 사용할 수 없습니다. 예를 들어 XAML 파일 내에서 중단점을 설정할 수 있는 방법은 없습니다. 그러나 앱을 개발하는 동안 UI 정의 또는 기타 XAML 태그와 관련된 문제를 디버그하는 데 도움이 되는 다른 기술이 있습니다.
XAML 파일에 문제가 있는 경우 가장 일반적인 결과는 일부 시스템 또는 앱에서 XAML 구문 분석 예외를 throw하는 것입니다. XAML 구문 분석 예외가 있을 때마다 XAML 파서에서 로드한 XAML이 유효한 개체 트리를 만들지 못했습니다. XAML이 루트 시각적 개체로 로드된 애플리케이션의 첫 번째 "페이지"를 나타내는 경우와 같은 경우에 XAML 구문 분석 예외는 복구할 수 없습니다.
XAML은 Visual Studio 및 해당 XAML 디자인 화면 중 하나와 같은 IDE 내에서 편집되는 경우가 많습니다. Visual Studio는 편집할 때 XAML 원본의 디자인 타임 유효성 검사 및 오류 검사 제공할 수 있습니다. 예를 들어 잘못된 특성 값을 입력하는 즉시 XAML 텍스트 편집기에서 "물결선"을 표시할 수 있으며, XAML 컴파일 패스가 UI 정의에 문제가 있는지 확인하기 위해 기다릴 필요가 없습니다.
앱이 실제로 실행되면 디자인 타임에 XAML 구문 분석 오류가 검색되지 않은 경우 CLR(공용 언어 런타임)에서 XamlParseException으로 보고됩니다. 런타임 XamlParseException에 대해 수행할 수 있는 작업에 대한 자세한 내용은 C# 또는 Visual Basic의 Windows 런타임 앱에 대한 예외 처리를 참조하세요.
참고 항목
코드에 C++/CX를 사용하는 앱의 경우 특정 XamlParseException이 발생하지 않습니다. 그러나 예외의 메시지는 오류의 원본이 XAML 관련임을 명확히 하고 XamlParseException과 마찬가지로 XAML 파일의 줄 번호와 같은 컨텍스트 정보를 포함합니다.
Windows 런타임 앱 디버깅에 대한 자세한 내용은 디버그 세션 시작을 참조하세요.