ピーク パフォーマンスのためにアプリまたはページの負荷を最適化する

アプリに対するユーザーの認識を形成する重要な要素の 1 つは、アプリが開いて機能するまでの速さです。 したがって、パフォーマンスの高いアプリを構築するには、この目標に優先順位を付けることが重要です。 アプリの最適なパフォーマンスを達成するには、3 つの主な領域に注意が必要です。

  1. データの高速読み込み
  2. 効率的な計算
  3. 必要なリソースの最小化

これらの各領域には、いくつか共通のアンチパターンがあります。

データの高速読み込み

アプリの高速データ読み込みを達成するには、次のガイドラインに従ってください。

大量のデータのあるコレクションの直接入力を回避する

場合によって、作成者は ClearCollect() を使用して、サーバーからアプリ内のコレクションにデータをコピーすることがあります。 この演習は、ソースの委任制限のための回避策、またはアプリ内のコレクションを他の目的で使用する予定があるためです。 ClearCollect() を使用すると、後でコレクションを使用するときにアプリの速度が向上する可能性があります。 ただし、実装する際には注意してください。 このように ClearCollect を使用すると、アプリの読み込み時間やページ間のナビゲーションが遅くなる可能性があります。 ClearCollect() は、ギャラリーまたはテーブルにデータを表示する前に終了する必要があります。 大量のデータがある場合、または多すぎるデータ ソースに対してこのアプローチを使用する場合、このステップに時間がかかることがあります。 コレクションは、データが小さく、コレクションに多くの計算を行う必要がある場合に最適です。 たとえば、コレクションの良い使用に、オンライン注文バスケットがあります。 顧客は、注文のコミットを選択する前に数回、アイテムを更新および削除することがあります。 さらに、潜在的な割引やハイライトなど、より多くのデータ項目でコレクションを増やすこともできます。「読み取り専用」のデータは、コレクションに含めずにネイティブでアクセスする必要があります。

コレクションを入力するための Power Automate 呼び出しを回避することを検討してください

この問題は、前のセクションを少し変更したものです。 場合によっては、作成者が Power Automate を使用して Power Apps のコレクションを入力することもあります。 Power Automate のインスタンスを作成するには約 0.6 秒のパフォーマンス コストがかかります。 Power Automate は、呼び出されるたびに独立して起動する必要があります。 メモリを割り当て、適切なコンポーネントを配置し、実行する準備ができている必要があります。 上記のアドバイスのように、アプリによっては、1 回または 2 回の Power Automate への呼び出しは問題にならないことがあります。 しかし、ほぼ例外なく、パフォーマンスが悪いアプリはこの方法を過度に使用します。 パフォーマンス コストが急に増加し、アプリのパフォーマンスが損なわれる可能性があります。

完全なオフライン シナリオとして SaveData() とLoadData() を使用することは避けてください

一部の作成者は ClearCollect() を使用してから SaveData() を使用して、汎用のオフライン使用のためにデータを保存します。 SaveData() を使用してコレクションをデバイスに保存し、LoadData() を使用してオフライン時に読み込みます。 ただし、この方法は、大量のデータがあるインスタンスやデータが複雑な場合にはお勧めできません。 データを表示するまで ClearCollect() が完了するのを待機する必要があるため、アプリの速度が遅くなります。 設定や短いリストなど、小規模恵シンプルなデータ シナリオには SaveData() と LoadData() のみを使用する必要があります。 大量のオフライン データを操作する良い方法は、Dataverse と連携する Power Apps オフライン機能を使用することです。 この機能により、より効率的に大規模で複雑なデータを処理できます。

明示的な列の選択を使用する

明示的な列の選択は既定でオンになっています。 ただし、この機能をオフにしている作成者もいます。 問題は、明示的な列の選択 (ECS) をオンにすると、データが最初にコレクションに取得された場合に、列がデータ ソースから取得されない場合があることです。 テーブルによっては多くの列が含まれる場合があるため、ECS はコントロール (ギャラリーやフォームなど) での使用状況に基づいて、どの列を取得する必要があるかを自動的に計算します。テーブルによっては多くの列があるため、ダウンロードのサイズを小さくするとパフォーマンスが向上します。 一部のテーブルには 100 以上の列があります。 アプリが 10 列のみを使用する必要があり、100 列のテーブルからすべての列を削除すると、実際に必要なデータの 10 倍のデータを削除することになります。

ほとんどの問題は、データをコレクションに取り込むときに発生します。 列がコントロールで明示的に参照されている場合、ECS は適切に機能します。 また、ECS は通常、コレクションに対して機能します。 ただし、データがコレクションや変数を移動するときに、列の系列が失われることがあります。 そして、そのため Power Apps は取得すべき列を見失う可能性があります。 この問題を解決するには、ShowColumns 関数を使用して、Power Apps に列を強制的に "記憶" させることができます。 例:

    ClearCollect(
        MyColTable, 
        ShowColumns(Filter(BankAccounts, AcountNo = 32),
        "Col1", 
        "Col2", 
        "Col3")
    );

ここで、Col1Col2、および Col3 は、データ ソース (例: Account データ ソース) から取得されると想定される列です。

あるいは、列を参照する非表示コントロールをフォームに追加することもできます。 これにより、Power Apps に列を強制的に "記憶" します。

高速計算

高速 (または効率的な) 計算は、それ自体がパフォーマンスの目標です。 詳細については、高速 (効率的な) 計算を参照してください。 ただし、アプリの負荷にも影響を与える可能性のある一般的なアンチパターンがあるため、ここで説明します。 以下は、アプリの起動やページ ナビゲーションに影響を与えることがある、考慮が必要な最適化のリストです。

App.Formulas を使用する

これまで、多くの作成者は OnStart 時に多数の計算を入れてきました。 OnStart 時に式を配置すると、Power Apps はアプリの起動時および他のすべての前に、正確にその式を強制的に実行します。 ただし、App.Formulas の導入により、式を実行するときを Power Apps に決定させることができます。 Power Apps は、必要になる前の「Just-in-time」で式を実行できます。 詳細については、アプリの数式を参照してください。 App.Formulas を使用して数式をピースに分割すると、Power Apps は実行のために効率的に整理されます。

同時実行を使用する

Concurrent 関数を使用すると、数式を同時に実行できるようになります。 一般的に、並列実行が可能になるため、この関数を使用してコレクションを入力します。 ある程度速度は向上しますが、多くのデータ ソースを追加すると、タイミングや調整の問題が発生する可能性があります。

非表示コントロールのパフォーマンスの強化を使用する

2022 年 12 月以降に作成されたすべての新しいアプリにおいて既定で有効になっている場合、Power Apps は最初に表示されていないコントロールはレンダリングしません。

必要なリソースを最小にする

アプリや画面の起動に必要なリソースを最小限にします。 この取り組みには、アプリや画面に必要なリソースを慎重にスコーピングまたは分割することが含まれます。 以下に、役立ついくつかのアプローチを示します。

依存関係の低い開始画面を使用し、未使用の画面を排除します。

アプリケーションのようこそなど、依存関係の低い最初の画面を使用します。 ギャラリー、テーブル、または参照データを読み込まない画面を作成します。 これにより、速度に対するユーザーの認識が管理され、Power Fx は一部の計算を適切に後に遅延できるようになります。 未使用の画面がある場合は、削除します。

画面間のクロス スクリーン依存関係を低くする

クロス ページ参照により、参照を介して追加のページが強制的に読み込まれます。たとえば、ページのコントロールを参照し、コレクションに追加します。 一部の参照は避けられないことがあります。 可能な場合、共通の参照を単一ページに一元管理し、ページのみが読み込まれるようにします。

埋め込みメディアを検討する

作成者は、高速に読み込むためにアプリにメディアを埋め込むことがあります。 埋め込みメディアがある場合、使用しているかどうかを検討してください。 ない場合は削除します。 .png ファイルを埋め込んだ場合、より小さい .svg ファイルを置き換えることを検討してください。 .svg を使用する場合、.svg のフォントがクライアント マシンに存在する必要があることに注意してください。 埋め込みメディアのソリューションを検討してください。 使用されるデバイスにとっては高度すぎますか?

App.StartScreen を忘れない

App.StartScreen を使用する場合、最初の画面を必ず空白画面にしてください。 アプリの現在のパッケージ化により、最初の論理画面は常にアプリの初期化ロジックにバンドルされていて、そこに移動するかどうかに関係なく初期化されます。

アプリの分割を検討する

アプリが大きい場合、小さいアプリに分割することを検討してください。 アプリのさまざまな部分で機能が十分に分離されている場合、この方法が機能することがあります。 このシナリオでは、最初の、または親アプリからのコンテキストを含むパラメーターを使用して起動する別のアプリを実際に作成します。

提案

高速なアプリとページの開始という目標を達成するには、次の質問と提案を考慮してください。

  1. 最初の画面で大量のデータを読み込んでいませんか? 別に最初の画面を使用できますか?
  2. アプリの読み込み開始時に多くのコマンドまたは Power Fx 式を実行していますか? アプリケーションでこれらのコマンドと式を後に延期できますか? アプリを開始するのに実際に必要なデータのみを取得していますか? 1 App.OnStart の式を App.Formulas を使用した名前付き式に変換できますか? これにより、ロード イベントやナビゲート イベントで式を強制的に実行するのではなく、実際にいつ式を実行するかを Power Fx が決定することができます。
  3. 別の Power Automate フローを使用し、Dataverse など、さまざまなソースからのデータを結合させるローカル データ ストアに一時テーブルを作成できますか? それから、Power App でそのデータにアクセスできますか?
  4. ビジネス プロセスを開始する場合、Power Automate フローを呼び出すのではなく、サーバー トリガー アクションを使用できますか?
  5. データを結合するビューをサーバーに作成できますか?
  6. アプリでオフライン データを使用する場合、Dataverse と連携する Power Apps オフライン機能を使用できますか? データが Dataverse にない場合、そこに移動できますか?