キャンバス アプリの最適化

完了

開発には、命令型と宣言型の主な 2 つの方法があります。 命令型の開発は目標を達成する方法に焦点を当て、宣言型の開発は結果を得ることに焦点を当てています。 命令型の場合、プロセスのあらゆる手順を制御できるので柔軟性が高くなりますが、必要なコードが多くなり、より複雑になります。 宣言型の方がシンプルかつ扱いやすくなりますが、完全な制御が必要でもそれができません。

キャンバス アプリは、宣言型の "何" を扱い、"方法" を最適化します。"何" を正確に表現できない場合もあるので、命令型の開発を使用できる Power Apps は役立ちます。 作成者がよくする間違いは、宣言型の開発の方が使いやすく、パフォーマンスが高くなる場合に命令型の開発を使用してしまうことです。

キャンバス アプリは魅力的な外見にすることができます。魅力的なアプリは重要ですが、パフォーマンスが高いアプリの方がユーザーによる導入が増えます。

命令型および宣言型の開発手法の使用については、Power Apps のキャンバス アプリに命令型の開発手法を利用するを参照してください。

以降のセクションでは、キャンバス アプリのパフォーマンスを最適化するための手法について説明します。

アプリから処理をオフロードする

アプリ内の数式の規模と複雑さが増しているため、処理を他の場所で行うべきかどうかを検討できます。 処理は、Microsoft Power Automate クラウド フロー、ビジネス ルール、プラグイン、および Dataverse の他のサーバー側ロジックにオフロードできます。

メモ

一般的な方法は、Power Apps トリガーを使用する Power Automate クラウド フローにロジックをオフロードする方法です。 フローは、データをフローに渡してフローから結果を受け取る Power Apps式から呼び出すことができます。

また、Microsoft Azure Functions や他のカスタム ロジックに対するカスタム コネクタも作成できます。 アプリ内で命令型の開発を使用していることがわかっている場合は、このロジックをより適切な機能にオフロードすることを検討してください。

パフォーマンス

アプリのパフォーマンスに関する一般的な問題は次のとおりです。

  • データ アクセス - 最初に、アプリは大規模なデータ セットをデータ コレクションにまとめ、結合、並べ替え、列の追加、グループ化のようなクライアントに負荷のかかる操作に対して、複数の画面でデータを使用します。
  • OnStart の数式 - アプリが画面で不要なデータ呼び出しを多くトリガーし、それらのデータ呼び出しが大規模なデータ レコードを返します。
  • ソースからデータを繰り返し取得する - Set 関数を使用し、ルックアップ テーブルからデータをローカルにキャッシュします。

OnStart を使用する場合は、ClearCollect 関数を使用してデータをローカルにキャッシュし、Concurrent 関数を使用してキャッシュされたデータの読み込み時間を短縮するよう作成者に勧めてください。 1 つ目の図は、Concurrent 関数を使用しない 4 つのデータセットの読み込みを示しており、2 つ目の図は Concurrent 関数を使用したプロセスを示しています。

データセットの順次読み込みを示す図。

データセットの同時読み込みを示す図。

非常に多くのオプションがあるため、パフォーマンスについて頻繁に検討する必要があります。 分析と最適化の向上は継続的な作業です。 パフォーマンスの低下の原因一般的なパフォーマンスの問題パフォーマンスに関するヒント を参照して、ベスト プラクティスを検証してください。

ソリューション アーキテクトは、キャンバス アプリのパフォーマンスを調整戦略を導入する必要があります。

調整プロセス戦略を示す図。

調整戦略の内容は次のとおりです。

  • できない処理は回避する。
  • あまり必要でない処理は延期する。
  • 可能な限り処理を並列化する。
  • 動作中のアプリを監視する。処理は常に明確とは限りません。

実行時間の長い処理では、ユーザーに進捗状況インジケーターを表示してください。

Test Studio、Azure Monitor、Application Insights

キャンバス アプリは適切にテストしてください。 Microsoft では、キャンバス アプリの回帰テストを行うための Test Studio を用意しており、自動ビルド プロセスに含めることができます。

Test Studio には、次の機能が含まれています。

  • スイート - テスト スイートは、テスト ケースを整理したりまとめたりするために使用されます。
  • テスト - テスト ケースは、一連のテスト ステップで構成されます。 アプリまたはアプリの特定の機能が正常に動作することを検証するためにテスト ケースを実行します。
  • テスト ステップ - 手順またはアクション。 テスト ステップは、Power Apps 式の言語を使用して記述されます。
  • テスト アサーション - テストの期待される結果。

Test Studio スイート コンポーネントを示す図。

Microsoft Azure Monitor は、作成者がユーザーのセッションからイベントのストリームを参照して、問題を診断およびトラブルシューティングできるツールです。 キャンバス アプリ開発者は、Monitor を使用して、Power Apps Studio で新しいアプリを構築する際にイベントを参照し、実行時に公開済みアプリを監視できます。 モデル駆動型アプリ開発者は、ページ ナビゲーション、コマンド実装、フォーム関連の問題、他の主要なアクションを監視して、アプリの動作を理解し、改善することができます。

イベントの Monitor ツールを示すスクリーンショット。

キャンバス アプリを、Azure Monitor の機能である Application Insights に接続することができます。 Application Insights には、問題を診断して、ユーザーが実際にアプリで行う内容を理解するのに役立つ強力な分析ツールが含まれています。

アプリを Application Insights に接続すると、ユーザーが実際にアプリをどのように使用しているかに関するテレメトリを収集して、アプリの品質を向上できます。 この機能のセットアップすることで得られるテレメトリの例を次に示します。

  • アプリを使用しているアクティブ ユーザーの数。
  • アプリが使用されている場所。
  • 最も頻繁に使用されている画面。
  • ある画面から別の画面へのユーザー フロー。

インサイトを得るために使用される Monitor のスクリーンショット。

ソリューション アーキテクトは、作成したアプリに Application Insights を含めるかどうかを決定する必要があります。

詳細については、Application Insights を参照してください。