XAML の概要

2025-09-11

この記事では、Windows ランタイムアプリ開発者に XAML 言語と XAML の概念を紹介し、Windows ランタイムアプリの作成に使用される XAML でオブジェクトを宣言し、属性を設定するさまざまな方法について説明します。

XAML とは

拡張アプリケーションマークアップ言語 (XAML) は宣言型言語です。具体的には、XAML では、複数のオブジェクト間の階層関係を示す言語構造と、型の拡張をサポートするバッキング型規則を使用して、オブジェクトを初期化し、オブジェクトのプロパティを設定できます。宣言型 XAML マークアップで表示される UI 要素を作成できます。その後、イベントに応答し、XAML で最初に宣言したオブジェクトを操作できる XAML ファイルごとに個別の分離コードファイルを関連付けることができます。

XAML 言語では、設計ツールと対話型開発環境 (IDE) 間の XAML ソースの交換、または主要開発者とローカリゼーション開発者との間での 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 から継承される規則である Uniform Resource Identifier (URI) です。
XAML では、宣言でプレフィックスを使用して既定以外の名前空間を宣言し、要素と属性のプレフィックス使用法はその名前空間を参照します。
XAML には、既定の名前空間の概念があります。これは、使用法または宣言にプレフィックスが存在しない場合に使用される名前空間です。既定の名前空間は、XAML プログラミングフレームワークごとに異なる方法で定義できます。
名前空間定義は、親要素から子要素へとXAMLファイルや構築物内で継承されます。たとえば、XAML ファイルのルート要素で名前空間を定義すると、そのファイル内のすべての要素がその名前空間定義を継承します。ページ内の要素がさらに名前空間を再定義すると、その要素の子孫は新しい定義を継承します。
要素の属性は、要素の名前空間を継承します。 XAML 属性にプレフィックスが表示されるのはかなり一般的ではありません。

XAML ファイルは、ほとんどの場合、ルート要素で既定の XAML 名前空間を宣言します。既定の XAML 名前空間は、プレフィックスで修飾せずに宣言できる要素を定義します。一般的な Windows ランタイムアプリプロジェクトの場合、この既定の名前空間には、UI 定義に使用される Windows ランタイムのすべての組み込み XAML ボキャブラリ (既定のコントロール、テキスト要素、XAML グラフィックスとアニメーション、データバインドとスタイル設定のサポートの種類など) が含まれます。 Windows ランタイムアプリ用に記述する XAML のほとんどは、一般的な UI 要素を参照するときに XAML 名前空間とプレフィックスの使用を回避できます。

アプリの最初のページのテンプレートで作成されたページルートを示すスニペットを次に示します (開始タグのみを表示し、簡略化されています)。既定の名前空間と 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 名前空間の 1 つは、XAML 言語の名前空間です。この名前空間には、XAML 言語仕様によって定義される要素と概念が含まれます。慣例により、XAML 言語の XAML 名前空間はプレフィックス "x" にマップされます。 Windows ランタイムアプリプロジェクトの既定のプロジェクトテンプレートとファイルテンプレートでは、ルート要素の一部として、既定の XAML 名前空間 (プレフィックスなし、 xmlns=のみ) と XAML 言語 XAML 名前空間 (プレフィックス "x") の両方が常に定義されます。

"x" プレフィックス/XAML 言語 XAML 名前空間には、XAML で頻繁に使用するいくつかのプログラミングコンストラクトが含まれています。最も一般的なものは次のとおりです。

任期	Description
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 組み込みデータ型	これらの型は、属性またはリソースに必要な単純な値型の値を指定できます。これらの組み込み型は、通常、各プログラミング言語の組み込み定義の一部として定義される単純な値型に対応します。たとえば、true のブール値を表すオブジェクトが、ObjectAnimationUsingKeyFrames ストーリーボードの表示状態で使用するために必要な場合があります。 XAML のその値では、次のように、オブジェクト要素として x:Boolean 組み込み型を使用します。 `<x:Boolean>True</x:Boolean>`

XAML 言語 XAML 名前空間の他のプログラミングコンストラクトは存在しますが、一般的ではありません。

XAML 名前空間へのカスタム型のマッピング

言語としての XAML の最も強力な側面の 1 つは、Windows ランタイムアプリの XAML ボキャブラリを簡単に拡張できる点です。アプリのプログラミング言語で独自のカスタム型を定義し、XAML マークアップでカスタム型を参照できます。カスタム型による拡張のサポートは、XAML 言語のしくみに基本的に組み込まれています。フレームワークまたはアプリ開発者は、XAML が参照するバッキングオブジェクトを作成する必要があります。フレームワークもアプリ開発者も、ボキャブラリ内のオブジェクトが基本的な XAML 構文規則を超えて何を表すか、または実行するかの仕様に制約されません。 (XAML 言語の XAML 名前空間の型で何を行うべきかについていくつかの期待がありますが、Windows ランタイムは必要なすべてのサポートを提供します)。

Windows ランタイムコアライブラリとメタデータ以外のライブラリから取得された型に XAML を使用する場合は、プレフィックスを持つ XAML 名前空間を宣言してマップする必要があります。ライブラリで定義された型を参照するには、要素の使用法でそのプレフィックスを使用します。プレフィックスマッピングは xmlns 属性として宣言します。通常はルート要素で、他の XAML 名前空間定義と共に宣言します。

カスタム型を参照する独自の名前空間定義を作成するには、最初にキーワード xmlns:、次に必要なプレフィックスを指定します。その属性の値には、値の最初の部分として 次を使用 するキーワードが含まれている必要があります。値の残りの部分は、カスタム型を含む特定のコードバッキング名前空間を名前で参照する文字列トークンです。

プレフィックスは、その 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 で Null 許容 値を null に設定します。たとえば、Null を不確定なチェック状態として解釈する CheckBox のコントロールテンプレートでこれを使用できます ("不確定" 表示状態をトリガーします)。

マークアップ拡張機能は、通常、アプリのオブジェクトグラフの他の部分から既存のインスタンスを返すか、実行時に値を延期します。マークアップ拡張は属性値として使用できるため、これが一般的な使用法です。多くの場合、マークアップ拡張は、通常ならプロパティ要素構文が必要となるかもしれない参照型プロパティに対して値を提供します。

たとえば、ResourceDictionary から再利用可能なスタイルを参照するための構文を次に示します:<Button Style="{StaticResource SearchButtonStyle}"/>。 Style は単純な値ではなく参照型であるため、{StaticResource}の使用がない場合は、<Button.Style> プロパティ要素と、その中に<Style>定義を使用して FrameworkElement.Style プロパティを設定する必要があります。

マークアップ拡張を使用すると、XAML で設定可能なすべてのプロパティが属性構文で設定できる可能性があります。属性構文を使用すると、直接オブジェクトのインスタンス化の属性構文がサポートされていない場合でも、プロパティの参照値を指定できます。または、XAML プロパティが値型または新しく作成された参照型によって入力されるという一般的な要件を延期する特定の動作を有効にすることもできます。

次の XAML の例では、属性構文を使用して Border の FrameworkElement.Style プロパティの値を設定します。 FrameworkElement.Style プロパティは Style クラスのインスタンスを受け取ります。これは、既定では属性構文文字列を使用して作成できなかった参照型です。ただし、この場合、属性は特定のマークアップ拡張機能 StaticResource を参照します。そのマークアップ拡張機能が処理されると、リソースディクショナリのキー付きリソースとして以前に定義された Style 要素への参照が返されます。

<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_Click 値で宣言された名前空間に、分離コードファイルに定義という名前のメソッドがあることを想定するようになりました。また、そのメソッドは、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 には、2 つの分離コードファイルがあります。1 つはヘッダー (.xaml.h) で、もう 1 つは実装 (.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 のもう一つの影響であり、大文字と小文字を区別する特性があります。 XAML 要素と属性の名前では、大文字と小文字が区別されます。属性の値は大文字と小文字が区別される可能性があります。これは、特定のプロパティに対する属性値の処理方法によって異なります。たとえば、属性値で列挙型のメンバー名が宣言されている場合、メンバー名文字列を型変換して列挙メンバーの値を返すプロセスは、大文字と小文字を区別しません。これに対し、 Name プロパティの値と、 Name プロパティが宣言する名前に基づいてオブジェクトを操作するためのユーティリティメソッドでは、名前文字列は大文字と小文字が区別されます。

XAML 名前スコープ

XAML 言語は、XAML 名前スコープの概念を定義します。 XAML 名前スコープの概念は、XAML プロセッサが XAML 要素に適用される x:Name または Name の値、特に名前を一意識別子に依存するスコープを処理する方法に影響します。 XAML 名前スコープについては、別のトピックで詳しく説明します。 XAML 名前スコープを参照してください。

開発プロセスにおける XAML の役割

XAML は、アプリ開発プロセスでいくつかの重要な役割を果たします。

XAML は、C#、Visual Basic、または C++/CX を使用してプログラミングする場合に、アプリの UI とその UI の要素を宣言するための主要な形式です。通常、プロジェクト内の少なくとも 1 つの XAML ファイルは、最初に表示された UI のアプリのページメタファーを表します。追加の XAML ファイルでは、ナビゲーション UI 用の追加ページが宣言される場合があります。その他の XAML ファイルでは、テンプレートやスタイルなどのリソースを宣言できます。
XAML 形式を使用して、アプリのコントロールと UI に適用されるスタイルとテンプレートを宣言します。
既存のコントロールをテンプレート化する場合や、コントロールパッケージの一部として既定のテンプレートを提供するコントロールを定義する場合は、スタイルとテンプレートを使用できます。スタイルとテンプレートを定義するために使用する場合、関連する XAML は、 ResourceDictionary ルートを持つ個別の XAML ファイルとして宣言されることがよくあります。
XAML は、デザイナーがアプリ UI を作成し、異なるデザイナーアプリ間で UI デザインを交換するための一般的な形式です。特に、アプリの XAML は、さまざまな XAML デザインツール (またはツール内のデザインウィンドウ) 間で交換できます。
他のいくつかのテクノロジでは、XAML の基本的な UI も定義されています。 Windows Presentation Foundation (WPF) 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 ページで同じリソースを使用する場合は、各ページではなく Application.Resources で定義することを検討してください。逆に、リソースを使用するページが 1 つだけの場合は、 Application.Resources で定義せず、必要なページに対してのみ定義してください。これは、アプリの設計時の XAML ファクターと、XAML 解析中のパフォーマンスの両方に適しています。
アプリがパッケージ化するリソースについては、未使用のリソース (キーを持つリソースですが、それを使用する StaticResource 参照がアプリに存在しないリソース) を確認します。アプリをリリースする前に、XAML からこれらを削除します。
デザインリソースを提供する別の XAML ファイル (MergedDictionaries) を使用している場合は、これらのファイルから未使用のリソースをコメント化または削除することを検討してください。複数のアプリで使用している共有 XAML の開始点がある場合や、すべてのアプリに共通のリソースを提供している場合でも、毎回 XAML リソースをパッケージ化するのはアプリであり、読み込む必要がある可能性があります。
コンポジションに必要のない UI 要素を定義し、可能な限り既定のコントロールテンプレートを使用しないでください (これらのテンプレートは既にテストされ、読み込みパフォーマンスのために検証されています)。
UI 要素の過剰な描画を意図的に行うのではなく、 Border などのコンテナーを使用します。基本的に、同じピクセルを複数回描画しないでください。オーバードローとそのテスト方法の詳細については、 DebugSettings.IsOverdrawHeatMapEnabledを参照してください。
ListView または GridView の既定の項目テンプレートを使用します。これらには、多数のリスト項目のビジュアルツリーを構築するときのパフォーマンスの問題を解決する特別な発表者ロジックがあります。

XAML のデバッグ

XAML はマークアップ言語であるため、Microsoft Visual Studio 内でデバッグするための一般的な戦略の一部は使用できません。たとえば、XAML ファイル内にブレークポイントを設定する方法はありません。ただし、アプリの開発中に UI 定義やその他の XAML マークアップに関する問題をデバッグするのに役立つ他の手法もあります。

XAML ファイルに問題がある場合、最も一般的な結果は、一部のシステムまたはアプリが XAML 解析例外をスローすることです。 XAML 解析例外が発生するたびに、XAML パーサーによって読み込まれた XAML は、有効なオブジェクトツリーを作成できませんでした。場合によっては、XAML がルートビジュアルとして読み込まれたアプリケーションの最初の "ページ" を表す場合など、XAML 解析例外は回復できません。

XAML は、多くの場合、Visual Studio やその XAML デザインサーフェイスの 1 つなどの IDE 内で編集されます。 Visual Studio では、多くの場合、XAML ソースを編集するときにデザイン時の検証とエラーチェックを行うことができます。たとえば、不適切な属性値を入力すると、XAML テキストエディターで"波線"がすぐに表示され、UI 定義に問題があることがわかります。XAML のコンパイル工程を待つ必要さえありません。

アプリが実際に実行されると、デザイン時に XAML 解析エラーが検出されなかった場合、これらは共通言語ランタイム (CLR) によって XamlParseException として報告されます。実行時 の XamlParseException でできることの詳細については、「 C# または Visual Basic での Windows ランタイムアプリの例外処理」を参照してください。

注

コードに C++/CX を使用するアプリは、特定の XamlParseException を取得しません。ただし、例外のメッセージでは、エラーの原因が XAML に関連していることを明確にし、 XamlParseException と同様に、XAML ファイル内の行番号などのコンテキスト情報が含まれています。

Windows ランタイムアプリのデバッグの詳細については、「デバッグセッションを開始する」を参照してください。