XAML の概要

[アーティクル]
07/04/2024

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

XAML とは

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

XAML 言語では、開発プロセスにおけるさまざまなツールや役割の間でソースを交換できます。たとえば、デザインツールと対話型開発環境 (IDE) の間や、メインの開発者とローカライズを担当する開発者の間で XAML ソースを交換できます。 XAML をインターチェンジ形式として使用することで、デザイナーロールと開発者ロールを分離またはまとめることができ、デザイナーと開発者はアプリの運用中に反復処理を行うことができます。

Windows ランタイムアプリプロジェクトの一部として表示される XAML ファイルは、.xaml ファイル名拡張子を持つ XML ファイルです。

基本的な XAML 構文

XAML には、XML に基づく基本的な構文があります。定義上、有効な XAML も有効な XML である必要があります。しかし、XAML には、XML 1.0 仕様に基づいて有効な XML でありつつも、別のより完全な意味が割り当てられた構文概念もあります。たとえば、XAML では property 要素構文をサポートしています。プロパティ値は、属性の文字列値やコンテンツとしてではなく、要素内で設定できます。通常の XML では、XAML プロパティ要素は名前にドットが含まれる要素であるため、プレーン XML に対して有効ですが、同じ意味はありません。

XAML と Visual Studio

Microsoft Visual Studio は、XAML テキストエディターと、よりグラフィカルに指向された XAML デザインサーフェイスの両方で、有効な XAML 構文を生成するのに役立ちます。 Visual Studio を使ってアプリの XAML を作成するときは、キー入力のたびに構文を気にかける必要はありません。 IDE は有効な XAML 構文を記述できるように支援してくれます。たとえば、オートコンプリートによるヒント、Microsoft IntelliSense でのドロップダウンリストによる候補の表示、ツールボックス ウィンドウでの UI 要素ライブラリの表示などの機能があります。それでも、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 名前空間とプレフィックスの使用を回避できます。

次のスニペットは、テンプレートを使って作成された、アプリの開始ページの 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 名前空間の 1 つは、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 の使用方法の詳細については、「Quickstart: UI リソースの翻訳」を参照してください。
XAML 固有のデータ型	これらの型は、属性またはリソースに必要な単純な値型の値を指定できます。これらの組み込み型は、通常、各プログラミング言語の組み込み定義の一部として定義される単純な値型に対応します。たとえば、ObjectAnimationUsingKeyFrames のストーリーボードに設定された表示状態で使うブール値 true を表すオブジェクトが必要になることがあります。 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:、次にプレフィックスを指定します。その属性の値には、キーワード using: を値の最初の部分として含める必要があります。値の残りの部分は、カスタム型を含む特定のコードバッキング名前空間を名前で参照する文字列トークンです。

プレフィックスは、その 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 パーサーによって認識されるマークアップ拡張機能がサポートされています。

{{xBind}}: コンパイル時に生成される特定用途のコードを実行することで、プロパティの評価が実行時まで遅延されるデータバインディングをサポートします。このマークアップ拡張機能は、さまざまな引数をサポートしています。
{Binding}: 汎用ランタイムオブジェクト検査を実行することで、プロパティの評価を実行時まで延期するデータバインディングをサポートします。このマークアップ拡張機能は、さまざまな引数をサポートしています。
{StaticResource}: ResourceDictionary で定義されているリソース値の参照をサポートします。これらのリソースは別の XAML ファイルに含めることができますが、最終的には読み込み時に XAML パーサーが検索できる必要があります。 {StaticResource} の使用時の引数は、ResourceDictionary 内のキーを持つリソースのキー (名前) を識別します。
{ThemeResource}: {StaticResource} に似ていますが、実行時のテーマの変更に対応できます。 {ThemeResource} は、既定の XAML テンプレートWindows ランタイムに非常に頻繁に表示されます。これらのテンプレートのほとんどは、アプリの実行中にテーマを切り替えるユーザーとの互換性のために設計されているためです。
{TemplateBinding}: {Binding}の特殊なケースであり、XAML でのコントロールテンプレートとその実行時の最終的な使用方法をサポートします。
{RelativeSource}: テンプレート化された親から値が取得される特定の形式のテンプレートバインドを有効にします。
{CustomResource}: 高度なリソース参照シナリオ用。

Windows ランタイムでは、{x:Null} マークアップ拡張もサポートされています。これを使用して、XAML で Nullable 値を null に設定します。たとえば、CheckBox のコントロールテンプレートでこれを使うと、null は不確定なチェック状態として解釈されます ("Indeterminate" 表示状態がトリガーされます)。

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

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

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

次の XAML の例では、属性構文を使って、Border の FrameworkElement.Style プロパティの値を設定します。 FrameworkElement.Style プロパティは、Windows.UI.Xaml.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 構文ガイドを参照してください。

Events

XAML はオブジェクトとそのプロパティの宣言型言語ですが、マークアップ内のオブジェクトにイベントハンドラーをアタッチするための構文も含まれています。その後、XAML イベント構文は、Windows ランタイムプログラミングモデルを通じて XAML で宣言されたイベントを統合できます。イベントの名前は、イベントが処理されるオブジェクトの属性名として指定します。属性値には、コードで定義するイベントハンドラー関数の名前を指定します。 XAML プロセッサはこの名前を使用して、読み込まれたオブジェクトツリーにデリゲート表現を作成し、指定されたハンドラーを内部ハンドラーリストに追加します。ほぼすべてのWindows ランタイムアプリは、マークアップソースと分離コードソースの両方によって定義されます。

次に単純な例を示します。 Button クラスは Click という名前のイベントをサポートします。ユーザーが Button をクリックした後に呼び出す必要があるコードを実行する、Click のハンドラーを記述できます。 XAML では、Button の属性として Click を指定します。属性値には、ハンドラーのメソッド名である文字列を指定します。

<Button Click="showUpdatesButton_Click">Show updates</Button>

コンパイル時に、コンパイラは、XAML ページの x:Class 値で宣言された名前空間に、分離コードファイルで定義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 でどのように機能するか、およびプログラミングモデルとアプリケーションモデルとの関係の詳細については、「 Events とルーティングイベントの概要を参照してください。

Note

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 と空白」のトピックで説明されているシナリオ以外では使われません。 encoding 属性は XAML で有効です。 UTF-8 および UTF-16 エンコードのみがサポートされています。 UTF-32 エンコードはサポートされていません。

XAML での大文字と小文字の区別

XAML では大文字と小文字が区別されます。これは、XML に基づく XAML のもう 1 つの結果であり、大文字と小文字が区別されます。 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 ページに同じリソースを使う場合は、各ページではなく Resources に定義することをお勧めします。逆に、リソースを使用するページが 1 つだけの場合は、リソースを 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 解析例外をスローすることです。 XAML 解析例外が発生するたびに、XAML パーサーによって読み込まれた XAML は、有効なオブジェクトツリーを作成できませんでした。場合によっては、XAML がルートビジュアルとして読み込まれたアプリケーションの最初の "ページ" を表す場合など、XAML 解析例外は回復できません。

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

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

Note

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

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

次の方法で共有

XAML の概要

XAML とは

基本的な XAML 構文

XAML と Visual Studio

XAML 名前空間

XAML 言語の XAML 名前空間

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

その他の XAML 名前空間

マークアップ拡張機能

Events

リソースディクショナリ

XAML と XML

XAML での大文字と小文字の区別

XAML 名前スコープ

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

読み込みパフォーマンスのために XAML を最適化する

XAML のデバッグ

フィードバック

その他のリソース

次の方法で共有

XAML の概要

XAML とは

基本的な XAML 構文

XAML と Visual Studio

XAML 名前空間

XAML 言語の XAML 名前空間

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

その他の XAML 名前空間

マークアップ拡張機能

Events

リソース ディクショナリ

XAML と XML

XAML での大文字と小文字の区別

XAML 名前スコープ

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

読み込みパフォーマンスのために XAML を最適化する

XAML のデバッグ

フィードバック

その他のリソース

リソースディクショナリ