パフォーマンスについて考えることの重要性

  • 8 分

アプリのパフォーマンスは、ユーザーを満足させ続けるのに重要なものです。 アプリのレベルは、パフォーマンスに基づいて、中から高に代わる可能性があります。 また、コレクションでのデータのキャッシュやデータ ソースへの冗長な呼び出しの削除などの変更の場合と同じように単純であることもあります。

このモジュールでは、一般的なパフォーマンスの問題、その影響を軽減する方法、およびテストを行って問題を検出する方法について学習します。

最も一般的なパフォーマンスのボトルネック - データ ソース

最も一般的なアプリのパフォーマンスに関する問題は、データ ソースとのやり取りが原因となります。 ほとんどすべてのアプリに 1 つまたは複数のデータ ソースがあります。 Power Apps では、これらのデータ ソースへの 200 を超えるさまざまな接続がネイティブにサポートされ、これらの接続を使用することは、優れたアプリへの鍵となります。

アプリからのこれらのデータ ソースの呼び出しは、多くの場合、アプリでの最大のボトルネックとなります。これは、ネットワーク経由でデータ ソースを呼び出し、データ ソース側で要求を処理し、ネットワーク経由で Power Apps にデータを返してから、Power Apps でデータを処理して表示するのにかかる時間によるものです。 データ ソースとのこれらのやり取りを最適化することは、優れたパフォーマンスへの鍵となります。 以下のセクションでは、最も一般的ないくつかの間違いに重点を置きます。

更新が多すぎる

Refresh 関数を使用することで、特定のデータ ソースから収集されたデータを Power Apps で強制的に更新することができます。 これは、アプリで最新のデータを取得できるので、実行するのに優れた関数のように見えます。 しかし、Power Apps では多くの場合、この更新が自動的に処理されます。 たとえば、フォームを使用して、ギャラリー コントロールに表示されたデータ ソースに新しいレコードを送信する場合、Power Apps では自動的にその接続が更新されます。 ギャラリー画面に移動するときに Refresh 関数を含める場合、Power Apps で既に更新されたデータを更新することになります。 これは冗長であり、理由もなくアプリの速度を下げることになります。

メモ

必要であることを確信できるまで、Refresh 関数を使用しないでください。

参照が多すぎる

リレーショナル データ (ラーニング パス「Use advanced data options and connectors in Power Apps」 (Power Apps で詳細なデータ オプションとコネクタを使用する) - モジュール 1 「Work with relational data in a canvas app in PowerApps」 (Power Apps のキャンバス アプリでリレーショナル データを操作する) で説明されている) の使用を開始する際のよくある間違いは、ギャラリー内の LookUp 関数の影響を考慮しないことです。 ギャラリー内のラベルに LookUp 関数を配置すると、その LookUp が、ギャラリーのすべてのレコードに対して一度実行されます。 つまり、ギャラリーに 100 個のレコードがある場合、アプリでは、レンダリングするデータ ソースに対して、個別に 100 回の LookUp 呼び出しを行う必要があります。 データ ソースによっては、レンダリングに数分かかる場合があります。 詳細画面を使用して関連データのみを表示するか、コレクションを使用してデータ ソースからデータをキャッシュすることをお勧めします。そうすれば、LookUp をネットワーク経由で実行する必要はありません。

メモ

複数のレコードを表示するコントロールを使用する場合、リモート データ ソースをさらに呼び出すときは注意してください。

正しくないデータ ソースでのデータの格納

さまざまなデータ ソースがさまざまなワークロードに対して最適化されます。これは、データの格納場所を選ぶ際に考慮する必要があります。 一例として、イメージまたはファイルの格納があります。 Power Apps の一般的な用途は、カメラ コントロールまたはデバイスの組み込みカメラ アプリを使用して、イメージをキャプチャすることです。 ユーザーがイメージを取得した後、それを保存する必要があります。 1 つのオプションは、他のアプリ データと同じ SQL Server データベースにイメージを格納することです。 可能ではありますが、SQL Server はイメージを格納するのに効率が悪い点に注意することが重要です。 SQL データベースへのイメージ ファイルの書き込みと読み取りに時間がかかると、アプリの実行速度が低下します。 より適切なオプションは、Azure Blob Storage に Power Apps のイメージを格納すること です。 Azure Blob Storage は、SQL Server に同じデータを書き込むよりもはるかに高速です。 アプリの基になる構造に対するこの小さな変更が、ユーザーの満足度に有効な影響を与える可能性があります。

メモ

最大のパフォーマンスを得るために、ご利用のアプリに最適なデータ ソースを選択します。

パフォーマンスに関するその他の考慮事項

データ ソースは最大のボトルネックになる可能性がありますが、最適なパフォーマンスを得るために行うことができる変更は他にもあり、これらは見落とされがちです。 その他のいくつかの一般的な問題には、次のようなものがあります

  • 資産のサイズ - アプリを設計する際に、会社のロゴとその他のビジュアル資産を含めることをお勧めします。 アプリにこれらの資産を追加する場合は、資産がアプリのサイズに最適化されていることを確認してください。 ファイルの解像度が高いほど、ファイル サイズが大きくなり、アプリでイメージを格納して表示するのに使用するリソースが増えます。 アプリに必要なサイズにファイルのサイズを変更するには、イメージ編集ツールを使用します。

  • アプリを再発行する - Power Apps チームでは、新機能を提供し、パフォーマンスを向上させるために常に Power Apps を更新しています。 アプリでこうした進歩を活用する唯一の方法は、自動的にアプリを開き、再度発行することです。 これを行うまで、アプリでは発行されたバージョンが維持されます。 したがって、最新バージョンに移行するアプリを定期的に再検討することで、考えられる最高のパフォーマンスが得られます。

  • 重点を置いたアプリを構築する - Power Apps では、想像できる数の画面を含むアプリの構築がサポートされますが、画面が多すぎるのは好ましくありません。 特定の対象ユーザーとプロセスに重点を置いたアプリを構築する必要があります。 これにより、1 人の対象ユーザーのユーザー エクスペリエンスを最適化することができ、アプリをより簡単に構築してトラブルシューティングを行うことができ、アプリのサイズが小さくなります。 すべてのものに対してアプリが 1 つである場合、ロール別により小さいアプリに分割することを検討してください。

少しずつパフォーマンスを最適化する

このモジュールでは、パフォーマンスを最適化するためのさまざまな手法とオプションについて学習していきます。 アプリの最適化について詳しく確認する前に、最も重要なことはアプリの動作であることに注意してください。 ユーザーが使用するときにのみ、エラーをスローする高速パフォーマンス アプリには価値がありません。

目標を達成し、完全に機能するようにアプリを構築する方が簡単な場合が多いです。 アプリが動作した後、パフォーマンスを向上させるための変更を行うためにアプリを再確認できますが、これらの変更を一度に 1 つずつ行えば、機能が中断されることはありません。 小さな変更を行う、この方法での成功率が最も高くなります。 さまざまなパフォーマンスの概念に慣れてきたら、それらを最初から使用するアプリの構築について学習します。 しかし、それまでの間は、動作するアプリを構築してから最適化します。

追加情報

このモジュールの概念を補足するために、パフォーマンスへの意識を高めるのに役立つ 2 つの追加オプションがあります。

これで、パフォーマンスを最適化する利点と、注意すべき一般的ないくつかの問題について把握しました。このモジュールの残りの部分では、パフォーマンスを向上させる手法と、アプリのテストでさまざまな方法をどのように使用するかを示します。