スケーラビリティ

複数の異なるモバイルデバイスプラットフォーム向けにアプリケーションを開発する場合、次のような課題に直面します。

モバイルデバイスプラットフォームは、画面サイズ、アスペクト比、向き、密度など、さまざまな画面構成のデバイスに対応しています。
プラットフォームごとに UI の慣例が異なり、各プラットフォームにおけるユーザーの期待に応える必要があります。

Qt Quick QML を使用することで、タブレットや携帯電話など、さまざまな種類のデバイスで動作するアプリケーションを開発できます。特に、異なる画面構成にも対応可能です。ただし、各ターゲットプラットフォームで最適なユーザー体験を実現するには、常に一定程度の修正や調整が必要となります。

以下の場合には、スケーラビリティを考慮する必要があります：

Android や iOS など、複数のデバイスプラットフォーム、あるいは複数の画面構成のデバイスにアプリケーションを展開したい場合。
初期展開後に市場に登場する可能性のある新しいデバイスに備えておきたい場合。

スケーラブルなアプリケーションを実装するには、 Qt Quick：

Qt Quick コントロールを使用して UI を設計します。これらはUI コントロールのセットを提供します。
項目のサイズ変更が可能なQt Quick のレイアウトを使用して、レイアウトを定義します。
プロパティバインディングを使用して、レイアウトでは対応できないユースケースを実装します。たとえば、ピクセル密度の低い画面と高い画面で異なるバージョンの画像を表示したり、現在の画面の向きに応じてビューの内容を自動的に調整したりする場合などです。
参照デバイスを選択し、実際の画面サイズに合わせて画像やフォントのサイズ、余白を調整するためのスケーリング比率を計算します。
ファイルセレクタを使用して、プラットフォーム固有のアセットを読み込みます。
Loader を使用して、必要に応じてコンポーネントを読み込みます。

アプリケーションを設計する際は、以下のパターンを検討してください：

ビューの内容は、すべての画面サイズで非常に似ているものの、コンテンツ領域が拡大されている場合があります。Qt Quick ControlsのApplicationWindow QMLタイプを使用すると、コンテンツ項目のサイズに基づいてウィンドウサイズが自動的に計算されます。Qt Quick レイアウトを使用してコンテンツ項目の配置を行うと、レイアウトはそこに配置された項目のサイズを自動的に調整します。
小型デバイスにおけるページ全体のコンテンツは、大型デバイスではレイアウトの構成要素となる場合があります。そのため、それを独立したコンポーネント（つまり、別の QML ファイルで定義されたもの）とし、小型デバイスではビューにそのコンポーネントのインスタンスを単純に含めるようにすることを検討してください。画面の大きなデバイスでは、ローダーを使用して追加の項目を表示するのに十分なスペースがある場合があります。たとえば、メールビューアの場合、画面が十分に大きければ、メールのリストビューとメールの閲覧ビューを並べて表示できる可能性があります。
ゲームの場合、画面の大きいユーザーに不公平な優位性を与えないよう、通常は拡大縮小しないゲームボードを作成することが望ましいでしょう。 1つの解決策として、サポートされている最小のアスペクト比（通常は3:2）の画面に収まるセーフゾーンを定義し、4:3や16:9の画面では非表示になる領域に、装飾のみのコンテンツを追加する方法があります。

アプリケーションウィンドウの動的なサイズ変更

Qt Quick Controlsは、Qt Quick でユーザーインターフェースを作成するための一連のUIコントロールを提供します。通常、ApplicationWindow コントロールをアプリケーションのルートアイテムとして宣言します。ApplicationWindow は、MenuBar 、ToolBar 、StatusBarなどの他のコントロールを、プラットフォームに依存しない方法で配置するための利便性を提供します。ApplicationWindow は、実際のウィンドウの有効なサイズ制約を計算する際、コンテンツ項目のサイズ制約を入力として使用します。

アプリケーションウィンドウの標準的な部分を定義するコントロールに加え、ビューやメニューの作成、およびユーザーからの入力の提示や受信を行うためのコントロールも用意されています。Qt Quick のコントロールスタイルを使用すると、定義済みのコントロールにカスタムスタイルを適用できます。

Qt Quick ToolBar などのコントロールは、独自のレイアウトを提供せず、ユーザーがコンテンツを配置する必要があります。このために、のレイアウトを使用できます。Qt Quick

画面コントロールの動的なレイアウト設定

Qt Quick レイアウト機能では、RowLayout 、ColumnLayout 、およびGridLayout といったQMLタイプを使用して、画面コントロールを行、列、またはグリッド状に配置することができます。これらのQMLタイプのプロパティには、レイアウトの方向やセル間の間隔が保持されています。

Qt Quick のレイアウト用QML型を使用すると、レイアウトに追加されたアイテムに追加のプロパティを割り当てることができます。たとえば、アイテムの高さ、幅、サイズについて、最小値、最大値、および推奨値を指定できます。

これらのレイアウトにより、ウィンドウや画面のサイズが変更された際にも UI が適切にスケーリングされ、常に利用可能なスペースを最大限に活用できるようになります。

GridLayout タイプの具体的な使用例としては、画面の向きに応じて行または列として使用することが挙げられます。

上部または左側、下部または右側を表示する縦向きおよび横向きのレイアウト

以下のコードスニペットでは、flow プロパティを使用して、画面の幅が画面の高さより大きい場合はグリッドの流れを左から右（行として）に、それ以外の場合は上から下（列として）に設定しています：

ApplicationWindow {
    id: root
    visible: true
    width: 480
    height: 620

    GridLayout {
        anchors.fill: parent
        anchors.margins: 20
        rowSpacing: 20
        columnSpacing: 20
        flow:  width > height ? GridLayout.LeftToRight : GridLayout.TopToBottom
        Rectangle {
            Layout.fillWidth: true
            Layout.fillHeight: true
            color: "#5d5b59"
            Label {
                anchors.centerIn: parent
                text: "Top or left"
                color: "white"
            }
        }
        Rectangle {
            Layout.fillWidth: true
            Layout.fillHeight: true
            color: "#1e1b18"
            Label {
                anchors.centerIn: parent
                text: "Bottom or right"
                color: "white"
            }
        }
    }
}

画面のサイズ変更や再計算を頻繁に行うと、パフォーマンスの低下を招きます。たとえば、モバイルデバイスや組み込みデバイスでは、アニメーションオブジェクトのサイズや位置をフレームごとに再計算するのに必要な処理能力が不足している場合があります。レイアウトの使用中にパフォーマンスの問題が発生した場合は、代わりにバインディングなどの他の手法を検討してください。

レイアウトを使用する際に避けるべき事項を以下に示します：

レイアウト内のアイテムの x、y、width、または height プロパティにバインディングを設定しないでください。これはレイアウトの目的と矛盾するだけでなく、バインディングループを引き起こす原因となります。
定期的に評価される複雑な JavaScript 関数を定義しないでください。これにより、特にアニメーションの遷移中にパフォーマンスが低下します。
コンテナのサイズや子アイテムのサイズについて、あらかじめ仮定を立ててはいけません。利用可能なスペースの変化に対応できる、柔軟なレイアウト定義を心がけてください。
デザインをピクセル単位で正確に合わせたい場合は、レイアウトを使用しないでください。コンテンツアイテムは、利用可能なスペースに応じて自動的にサイズ変更され、配置されます。

バインディングの使用

Qt Quick のレイアウトがニーズに合わない場合は、プロパティバインディングの使用に切り替えることができます。バインディングを使用すると、他のオブジェクトの属性が変更されたり、外部イベントが発生したりしたことに応じて、オブジェクトのプロパティが自動的に更新されます。

オブジェクトのプロパティに値が割り当てられる際、静的な値を割り当てるか、JavaScript 式にバインドすることができます。前者の場合、そのプロパティに新しい値が割り当てられない限り、プロパティの値は変化しません。後者の場合、プロパティバインディングが作成され、評価された式値が変化するたびに、QMLエンジンによってプロパティの値が自動的に更新されます。

この種の配置は、最も動的なものです。ただし、JavaScript 式を絶えず評価することには、パフォーマンス上のコストが伴います。

バインディングを使用することで、Android、macOS、iOSのように自動的にサポートされていないプラットフォームでも、低ピクセル密度と高ピクセル密度に対応できます。次のコードスニペットでは、Screen.pixelDensity というアタッチドプロパティを使用して、低、高、または標準のピクセル密度の画面で表示する画像を指定しています:

Image {
    source: {
        if (Screen.pixelDensity < 40)
        "image_low_dpi.png"
        else if (Screen.pixelDensity > 300)
        "image_high_dpi.png"
        else
        "image.png"
        }
    }

Android、macOS、iOS では、アイコンや画像に対して対応する識別子（例:@2x、@3x、@4x）を使用し、リソースファイルに高解像度の代替リソースを配置することで、画面のピクセル密度に合致するバージョンが自動的に選択されて使用されます。

たとえば、次のコードスニペットは、Retina ディスプレイ上でartwork@2x.png を読み込もうとします：

Image {
    source: "artwork.png"
}

ピクセル密度の処理

Image 、BorderImage 、Text などの一部の QML タイプは、それらに対して指定されたプロパティに従って自動的にスケーリングされます。Image の幅と高さが指定されていない場合、source プロパティで指定されたソース画像のサイズが自動的に使用されます。デフォルトでは、幅と高さを指定すると、画像はそのサイズにスケーリングされます。この動作は、fillMode プロパティを設定することで変更でき、代わりに画像を伸縮させたりタイル状に並べたりすることが可能になります。ただし、高DPIディスプレイでは、元の画像サイズが小さすぎて表示される場合があります。

BorderImage は、各画像の一部をスケーリングまたはタイル化することで、画像からボーダーを作成するために使用されます。これは、ソース画像を9つの領域に分割し、プロパティの値に従ってスケーリングまたはタイル化を行います。ただし、角の部分はまったくスケーリングされないため、高DPIディスプレイでは結果が最適とはならない場合があります。

Text のQML型は、明示的に設定されていない限り、必要なスペースを推定し、それに応じてwidth およびheight プロパティを設定しようとします。fontPointSize プロパティは、デバイスに依存しない方法でポイントサイズを設定します。しかし、フォントをポイント単位で指定し、その他のサイズをピクセル単位で指定すると、ポイントは表示密度に依存しないため、問題が発生します。低DPIディスプレイでは正しく表示される文字列の周囲の枠も、高DPIディスプレイでは小さくなりすぎて、テキストが切り取られてしまう可能性があります。

高DPIのサポートレベルや、サポートされているプラットフォームで使用される技術は、プラットフォームごとに異なります。以下のセクションでは、高DPIディスプレイでの画面コンテンツのスケーリングに関するさまざまなアプローチについて説明します。

Qt における高 DPI サポートおよびサポート対象プラットフォームの詳細については、「高 DPI」を参照してください。

高 DPI スケーリング

ターゲットデバイスが高 DPI スケーリングをサポートしている場合、オペレーティングシステムは、グラフィック出力のスケーリングに使用されるスケーリング比率を Qt に提供します。

このアプローチの利点は、ベクターグラフィックスやフォントが自動的にスケーリングされ、既存のアプリケーションを修正せずに動作させることができる点です。ただし、ラスターコンテンツの場合は、高解像度の代替リソースが必要となります。

スケーリングは、Qt Quick およびQt Widgets スタックで実装されているほか、Qt GUI でも一般的にサポートされています。

低レベルのグラフィックス API は、デバイスピクセル単位で動作します。これには、OpenGL API を使用するコードや、QRhi API を使用するコードが含まれます。たとえば、size() が 1280x720、QWindow::devicePixelRatio() が 2 のQWindow の場合、レンダリングターゲット（スワップチェーン）のデバイスピクセルサイズは 2560x1440 になります。

OS は、ウィンドウ、イベント、およびデスクトップのジオメトリをスケーリングします。Cocoa プラットフォームプラグインは、QWindow::devicePixelRatio() またはQScreen::devicePixelRatio() として、またバッキングストア上でも、スケーリング比率を設定します。

Qt Widgets の場合、QPainter はバッキングストアから `devicePixelRatio() ` を取得し、それをスケーリング比率として解釈します。

しかし、OpenGL では、ピクセルは常にデバイスピクセルです。たとえば、glViewport() に渡されるジオメトリは、devicePixelRatio() によってスケーリングされる必要があります。

指定されたフォントサイズ（ポイントまたはピクセル単位）は変化せず、文字列は UI の他の部分に対する相対的なサイズを維持します。フォントは描画の一環としてスケーリングされるため、ポイントまたはピクセルのいずれで指定されているかに関係なく、サイズ 12 のフォントは 2 倍のスケーリングにより、実質的にサイズ 24 のフォントになります。px単位は、高 DPI ディスプレイでフォントが小さく表示されないように、デバイス非依存ピクセルとして解釈されます。

スケーリング比の計算

1 台の高 DPI デバイスを基準デバイスとして選択し、画像やフォントのサイズ、余白を実際の画面サイズに合わせて調整するためのスケーリング比率を計算できます。

以下のコードスニペットでは、Nexus 5 Android デバイスの DPI、高さ、幅の参照値、QRect クラスが返す実際の画面サイズ、およびqApp グローバルポインタが返す画面の論理 DPI 値を使用して、画像サイズと余白のスケーリング比率（m_ratio ）と、フォントサイズのスケーリング比率（m_ratioFont ）をそれぞれ計算しています：

qreal refDpi = 216.;
qreal refHeight = 1776.;
qreal refWidth = 1080.;
QRect rect = QGuiApplication::primaryScreen()->geometry();
qreal height = qMax(rect.width(), rect.height());
qreal width = qMin(rect.width(), rect.height());
qreal dpi = QGuiApplication::primaryScreen()->logicalDotsPerInch();
m_ratio = qMin(height/refHeight, width/refWidth);
m_ratioFont = qMin(height*refDpi/(dpi*refHeight), width*refDpi/(dpi*refWidth));

適切なスケーリング比率を得るためには、参照デバイスのデフォルトの向き（この場合は縦向き）に合わせて、高さと幅の値を設定する必要があります。

以下のコードスニペットは、フォントのスケーリング比が 1 未満となり、フォントサイズが小さくなりすぎる場合、その値を1 に設定します：

int tempTimeColumnWidth = 600;
int tempTrackHeaderWidth = 270;
if (m_ratioFont < 1.) {
    m_ratioFont = 1;

対象デバイスで実際に試行錯誤を行い、追加の計算を必要とするエッジケースを見つけ出す必要があります。画面によっては、計画したコンテンツをすべて収めるには高さが低すぎたり幅が狭すぎたりする場合があり、その場合は独自のレイアウトが必要になります。例えば、1:1のような非標準のアスペクト比を持つ画面では、一部のコンテンツを非表示にしたり置き換えたりする必要があるかもしれません。

QQmlPropertyMap 内のすべてのサイズにスケーリング比率を適用することで、画像、フォント、余白をスケーリングできます：

m_sizes = new QQmlPropertyMap(this);
m_sizes->insert(QLatin1String("trackHeaderHeight"), QVariant(applyRatio(270)));
m_sizes->insert(QLatin1String("trackHeaderWidth"), QVariant(applyRatio(tempTrackHeaderWidth)));
m_sizes->insert(QLatin1String("timeColumnWidth"), QVariant(applyRatio(tempTimeColumnWidth)));
m_sizes->insert(QLatin1String("conferenceHeaderHeight"), QVariant(applyRatio(158)));
m_sizes->insert(QLatin1String("dayWidth"), QVariant(applyRatio(150)));
m_sizes->insert(QLatin1String("favoriteImageHeight"), QVariant(applyRatio(76)));
m_sizes->insert(QLatin1String("favoriteImageWidth"), QVariant(applyRatio(80)));
m_sizes->insert(QLatin1String("titleHeight"), QVariant(applyRatio(60)));
m_sizes->insert(QLatin1String("backHeight"), QVariant(applyRatio(74)));
m_sizes->insert(QLatin1String("backWidth"), QVariant(applyRatio(42)));
m_sizes->insert(QLatin1String("logoHeight"), QVariant(applyRatio(100)));
m_sizes->insert(QLatin1String("logoWidth"), QVariant(applyRatio(286)));

m_fonts = new QQmlPropertyMap(this);
m_fonts->insert(QLatin1String("six_pt"), QVariant(applyFontRatio(9)));
m_fonts->insert(QLatin1String("seven_pt"), QVariant(applyFontRatio(10)));
m_fonts->insert(QLatin1String("eight_pt"), QVariant(applyFontRatio(12)));
m_fonts->insert(QLatin1String("ten_pt"), QVariant(applyFontRatio(14)));
m_fonts->insert(QLatin1String("twelve_pt"), QVariant(applyFontRatio(16)));

m_margins = new QQmlPropertyMap(this);
m_margins->insert(QLatin1String("five"), QVariant(applyRatio(5)));
m_margins->insert(QLatin1String("seven"), QVariant(applyRatio(7)));
m_margins->insert(QLatin1String("ten"), QVariant(applyRatio(10)));
m_margins->insert(QLatin1String("fifteen"), QVariant(applyRatio(15)));
m_margins->insert(QLatin1String("twenty"), QVariant(applyRatio(20)));
m_margins->insert(QLatin1String("thirty"), QVariant(applyRatio(30)));

以下のコードスニペットの関数は、フォント、画像、余白にスケーリング比率を適用します：

int Theme::applyFontRatio(const int value)
{
    return int(value * m_ratioFont);
}

int Theme::applyRatio(const int value)
{
    return qMax(2, int(value * m_ratio));
}

この手法は、対象デバイスの画面サイズに大きな差がない場合に、妥当な結果が得られます。差が著しい場合は、基準値の異なる複数のレイアウトを作成することを検討してください。

プラットフォームに応じたファイルの読み込み

QQmlFileSelector を使用すると、QML ファイルの読み込みにQFileSelector を適用できます。これにより、アプリケーションが実行されるプラットフォームに応じて、代替リソースを読み込むことが可能になります。たとえば、+android ファイルセレクタを使用して、Android デバイスで実行する際に異なる画像ファイルを読み込むことができます。

ファイルセレクタをシングルトンオブジェクトと組み合わせて使用することで、特定のプラットフォーム上のオブジェクトの単一インスタンスにアクセスできます。

ファイルセレクタは静的であり、プラットフォーム固有のファイルがプラットフォームの名前にちなんで名付けられたサブフォルダに格納されるというファイル構造を強制します。UIの一部をオンデマンドで読み込むためのより動的なソリューションが必要な場合は、Loaderを使用できます。

ターゲットプラットフォームによっては、さまざまな表示密度に対応した代替リソースの読み込みを、さまざまな方法で自動化している場合があります。AndroidおよびiOSでは、@2xというファイル名サフィックスを使用して、高DPI版の画像を示します。Image QML型およびQIcon クラスは、@2x版の画像やアイコンが提供されている場合、それらを自動的に読み込みます。QImage およびQPixmap クラスは、@2xバージョンの画像のdevicePixelRatio を自動的に2 に設定しますが、実際に@2xバージョンを使用するには、コードを追加する必要があります：

if ( QGuiApplication::primaryScreen()->devicePixelRatio() >= 2 ) {
    imageVariant = "@2x";
} else {
    imageVariant = "";
}

Android では、汎用的な画面サイズ（small、normal、large、xlarge）および密度（ldpi、mdpi、hdpi、xhdpi、xxhdpi、xxxhdpi）が定義されており、これらに対応した代替リソースを作成することができます。 Androidは実行時に現在のデバイス構成を検出し、アプリケーションに適したリソースを読み込みます。ただし、Android 3.2（APIレベル13）以降では、これらのサイズグループは非推奨となり、利用可能な画面幅に基づいて画面サイズを管理する新しい手法が採用されています。

オンデマンドでのコンポーネントの読み込み

Loader は、QMLファイル（source プロパティを使用）またはComponentオブジェクト（sourceComponent プロパティを使用）を読み込むことができます。これは、コンポーネントが必要になるまでその生成を遅延させる場合に役立ちます。たとえば、コンポーネントをオンデマンドで生成すべき場合や、パフォーマンス上の理由から不必要にコンポーネントを生成すべきでない場合などです。

また、特定のプラットフォームで一部の機能がサポートされていないために、UIの一部が不要となる状況に対処するためにもローダーを使用できます。アプリケーションが実行されているデバイス上で不要なビューを表示する代わりに、そのビューを非表示と判定し、ローダーを使用してその場所に別のものを表示させることができます。

画面の向きを切り替える

Screen.orientation アタッチドプロパティには、加速度センサー（利用可能な場合）から取得した画面の現在の向きが含まれます。デスクトップコンピュータでは、通常、この値は変化しません。

primaryOrientation がorientation に従っている場合、デバイスの持ち方に応じて、画面に表示されているすべてのコンテンツが自動的に回転することを意味します。primaryOrientation が変化しないにもかかわらず向きが変わった場合、デバイス自体がディスプレイを回転させていない可能性があります。その場合は、Item.rotation またはItem.transform を使用してコンテンツを回転させる必要があるかもしれません。

アプリケーションのトップレベルページ定義および再利用可能なコンポーネント定義では、レイアウト構造に 1 つの QML レイアウト定義を使用する必要があります。この単一の定義には、異なるデバイスの向きやアスペクト比に対応したレイアウト設計を含める必要があります。その理由は、向きが切り替わった際のパフォーマンスが極めて重要であるためであり、向きが変更された際に、両方の向きで必要となるすべてのコンポーネントが確実に読み込まれるようにすることが望ましいからです。

逆に、Loader を使用して、異なる向きで必要となる追加の QML を読み込む場合は、向きの変更時のパフォーマンスに影響を与えるため、徹底的なテストを行う必要があります。

向き間のレイアウトアニメーションを有効にするには、アンカー定義が同じ親コンポーネント内に存在する必要があります。したがって、ページまたはコンポーネントの構造は、共通の子コンポーネントのセット、共通のアンカー定義のセット、およびコンポーネントがサポートするさまざまなアスペクト比を表す状態のコレクション（StateGroup で定義）で構成されるべきです。

ページ内に含まれるコンポーネントが、多数の異なるフォームファクタ定義でホストされる必要がある場合、ビューのレイアウト状態はページ（その直近のコンテナ）のアスペクト比に依存する必要があります。同様に、コンポーネントの異なるインスタンスが UI 内の多数の異なるコンテナ内に配置される可能性があるため、そのレイアウト状態は親コンテナのアスペクト比によって決定されるべきです。結論として、レイアウト状態は常に直接のコンテナのアスペクト比に従うべきであり（現在のデバイス画面の「向き」に従うべきではありません）。

各レイアウトState 内では、ネイティブのQMLレイアウト定義を使用してアイテム間の関係を定義する必要があります。詳細については以下を参照してください。状態間の遷移（最上位レベルの向き変更によってトリガーされる）において、アンカーレイアウトの場合は、AnchorAnimation 要素を使用して遷移を制御できます。場合によっては、項目の幅などにNumberAnimation を適用することも可能です。アニメーションの各フレームで複雑なJavaScript計算を行わないよう注意してください。ほとんどの場合、単純なアンカー定義とアンカーアニメーションを使用することで、この問題を回避できます。

他にも考慮すべきケースがいくつかあります：

横向きと縦向きで外観が完全に異なり、つまりすべての子アイテムが異なる単一のページがある場合はどうすればよいでしょうか？各ページについて、別々のレイアウト定義を持つ2つの子コンポーネントを用意し、各状態においてどちらか一方のアイテムの不透明度をゼロにします。不透明度にNumberAnimation トランジションを適用するだけで、クロスフェードアニメーションを実現できます。
縦向きと横向きでレイアウトコンテンツの30％以上が共通している単一のページの場合はどうでしょうか？その場合は、横向きと縦向きの状態を持つ1つのコンポーネントと、向き状態に応じて不透明度（または位置）が変化する個別の子アイテムのコレクションを用意することを検討してください。これにより、向き間で共有されるアイテムにはレイアウトアニメーションを使用しつつ、その他のアイテムはフェードイン／フェードアウトさせたり、画面への表示／非表示をアニメーションさせたりすることが可能になります。
例えば、より大きなフォームファクタのデバイスなど、ハンドヘルドデバイス上で2つのページを同時に画面に表示する必要がある場合はどうでしょうか？この場合、ビューコンポーネントがもはや画面全体を占有しなくなることに注意してください。したがって、すべてのコンポーネント（特にリストデリゲートアイテム）は、画面の幅ではなく、包含するコンポーネントの幅に依存するように設計することが重要です。この場合、値が設定される前にリストアイテムデリゲートが確実に構築されるよう、Component.onCompleted() ハンドラ内で幅を設定する必要があるかもしれません。
2つの向きに対応したビューを同時にメモリ内に保持するにはメモリ消費が大きすぎる場合はどうすればよいでしょうか？必要に応じてLoader を使用してください。ただし、レイアウト切り替え時のクロスフェードアニメーションのパフォーマンスには注意が必要です。 1つの解決策として、Pageの子として2つの「スプラッシュスクリーン」アイテムを用意し、回転中にそれらをクロスフェードさせることができます。その後、Loader を使用して、実際のモデルデータを別の子Itemに読み込むコンポーネントをロードし、Loader が完了したら、そのアイテムへクロスフェードさせることができます。

Qt Quick の「レスポンシブレイアウト」も参照してください 。

QML コーディング規約パフォーマンス

© 2026 The Qt Company Ltd. Documentation contributions included herein are the copyrights of their respective owners. The documentation provided herein is licensed under the terms of the GNU Free Documentation License version 1.3 as published by the Free Software Foundation. Qt and respective logos are trademarks of The Qt Company Ltd. in Finland and/or other countries worldwide. All other trademarks are property of their respective owners.