次の方法で共有

ヒントとベスト プラクティスを使用して、キャンバス アプリのパフォーマンスを向上させる

  • [アーティクル]

以前の記事では、キャンバス アプリの 実行フェーズとデータ呼び出しフロー、パフォーマンス低下の一般的な原因、一般的なパフォーマンスの問題/解決策 について学びました。 この記事のヒントとベスト プラクティスに従って、作成するアプリのパフォーマンスを向上させることもできます。

データ接続の制限

1 つのアプリに 30 を超える接続を追加しない。 アプリからは、各追加コネクタにサインインするように新しいユーザーにも止められます。そのため、コネクタが追加されるたびに、アプリの起動に必要な時間が増えます。 アプリの実行中、アプリがソースからのデータを要求する場合、各コネクタで CPU リソース、メモリ、ネットワーク帯域幅が必要になります。

アプリの実行中に、Microsoft Edge または Google Chrome で開発者ツールをオンにすることで、アプリのパフォーマンスを簡単に測定できます。 30 を超える接続からのデータを頻繁に要求する場合、アプリがデータを返すまでに 15 秒以上かかる可能性があります。 追加された各接続は、接続されたデータ ソース タイプ—Microsoft Dataverse または SQL Server テーブル、または Microsoft Lists を使用して作成されたリストなど、に関係なくこの制限で個別にカウントされます。

コントロール数の制限

1 つのアプリに 500 を超えるコントロールを追加しない。 Power Apps は、各コントロールをレンダリングするための HTML ドキュメント オブジェクト モデルを生成します。 コントロールを追加すると、Power Apps に必要な生成時間が増えます。

個別コントロールではなく、ギャラリーを使用することで、場合によっては同じ結果を得たり、アプリを速く起動したりできることもあります。 また、同じ画面でコントロールの種類の数を減らすことができます。 一部のコントロール (PDF ビューアー、データ テーブル、コンボ ボックスなど) は大きな実行スクリプトを取り込み、表示に時間がかかります。

OnStart プロパティを最適化する

ユーザー セッション中にデータが変わらない場合は、ClearCollect 関数を使用し、データをローカルでキャッシュします。 また、データソースを同時にロードする Concurrent 関数を使用して、これにより、アプリがデータを読み込むのに必要な時間を半分に短縮できます。 詳細情報: Power Apps の並行機能

Concurrent 関数なしでは、次の数式は 4 つのテーブルを一度に 1 つずつ読み込みます。

ClearCollect( Product, '[SalesLT].[Product]' );
ClearCollect( Customer, '[SalesLT].[Customer]' );
ClearCollect( SalesOrderDetail, '[SalesLT].[SalesOrderDetail]' );
ClearCollect( SalesOrderHeader, '[SalesLT].[SalesOrderHeader]' )

次の図に示すように、この動作はブラウザの開発ツールで確認できます。

次々に読み込まれる 4 つのテーブルを示す図。

Concurrent 関数で同じ数式を囲むと、操作に必要な全体の時間を減らすことができます。

Concurrent( 
    ClearCollect( Product, '[SalesLT].[Product]' ),
    ClearCollect( Customer, '[SalesLT].[Customer]' ),
    ClearCollect( SalesOrderDetail, '[SalesLT].[SalesOrderDetail]' ),
    ClearCollect( SalesOrderHeader, '[SalesLT].[SalesOrderHeader]' ))

この変更により、次の図に示すように、アプリはテーブルを並行してフェッチします。

同時に読み込まれる 4 つのテーブルを示す図。

注意

OnStart に関連するパフォーマンスの問題と解決策の詳細については、チューニングが必要な OnStart イベント をお読みください。

ヒント

アプリの起動を簡素化し、アプリのパフォーマンスを向上させることができるため、App.StartScreen プロパティの使用をお勧めします。

検索データのキャッシュ

Set 関数を使用して検索テーブルからのデータをローカルでキャッシュし、ソースからデータを繰り返し取得するのを回避します。 この方法により、セッション中にデータが変更されなければ、パフォーマンスが最適化されます。 次の例で示されているように、データはソースから 1 回取得され、ユーザーがアプリを終了するまで、ローカルで参照されます。

Set(CustomerOrder, Lookup(Order, id = “123-45-6789”));
Set(CustomerName, CustomerOrder.Name);
Set(CustomerAddress, CustomerOrder.Address);
Set(CustomerEmail, CustomerOrder.Email);
Set(CustomerPhone, CustomerOrder.Phone);

この方法は、連絡先情報、規定値、または頻繁に変更されないユーザー情報などのデータに役立ちます。 また、規定 関数や ユーザー 関数でもこの手法を使用できます。

画面間のコントロール依存を回避する

パフォーマンスを向上させるために、アプリの画面は必要なときにのみメモリに読み込まれます。 たとえば、スクリーン 1 が読み込まれ、その式の 1 つがスクリーン 2 のコントロールのプロパティを使用している場合、この最適化は妨げられる可能性があります。 次に、画面 1 を表示する前に、画面 2 を読み込んで依存関係を満たす必要があります。 画面 2 が画面 4 など別の依存関係がある画面 3 に依存しているとします。 この依存関係チェーンにより、多くの画面が読み込まれる可能性があります。

このため、画面間の数式の依存関係は避けてください。 場合によっては、グローバル変数またはコレクションを使用して、画面間で情報を共有できます。

例外があります: 前述の例で、スクリーン 1 を表示する唯一の方法はスクリーン 2 から移動させることでした。 次に、スクリーン 1 がロードされるときに、スクリーン 2 はすでにメモリにロードされています。 スクリーン 2 の依存関係を満たすために追加の作業は必要ないため、パフォーマンスへの影響はありません。

委任の使用

ローカル デバイスの処理のためにデータを取得する代わりに、可能な場合、データ処理をデータ ソースに委任する関数を使用します。 アプリでデータをローカル処理する必要がある場合、操作にはたくさんの処理能力、メモリ、ネットワーク帯域幅が必要になります。これは特にデータ セットが大きい場合に当てはまります。

ヒント

特定のコネクタでサポートされている委任可能な機能については、コネクタのドキュメント を参照してください。

委任可能な関数の例として、Microsoft Lists を使用して作成されたリストの数値データ型として定義された ID 列について考えてみます。 次の例の数式は、期待どおりの結果を返します。 ただし、最初の式は委任可能ですが、2 番目の式は委任できません。

式 委任可能?
Filter ('List data source', ID = 123 ) はい
Filter(`List data source', ID ="123") いいえ

SharePoint の ID 列は定義されていると想定しているので、数値 のデータ型で定義されている場合、右側の値は文字列変数ではなく数値変数である必要があります。 そうしないと、このような不一致により、数式が委任できなくなる可能性があります。

委任できない関数や委任できないクエリに対する不適切なデータ行の制限 の使用は、このアプリのパフォーマンスに悪影響を与える可能性があります。 詳細情報: キャンバス アプリでの委任を理解する

遅延読み込みの使用

アプリにスクリーンが 10 個以上あり、ルールがなく、(複数の画面にあり、データ ソースに直接バインドされた) たくさんのコントロールがある場合、遅延読み込みの プレビュー機能 をオンにしてください。 この種類のアプリを作成するとき、この機能を有効にしない場合、開いていないスクリーンも含め、すべてのスクリーンのコントロールにデータを入力する必要があるため、アプリのパフォーマンスが低下することがあります。 また、ユーザーがレコードを追加するときなどデータ ソースが変わる場合は、必ずアプリのすべての画面を更新する必要があります。

大きなデータ セットで作業する

委任できるデータ ソースと数式を使用してアプリのパフォーマンスを維持することによって、ユーザーが必要とするあらゆる情報にアクセスできるようにして、委任できないクエリのために、データ行の制限である 2000 に到達しないようにします。 ユーザーがデータを検索、フィルタリング、または並べ替えることができるデータレコード列の場合、SQL サーバー または SharePoint のようなデータソースで説明されている列のインデックスを使用します。

注意

大きなデータセットがさまざまなプラットフォームで一般的なパフォーマンスの問題を引き起こす可能性がある方法の詳細については、異なるプラットフォームでの読み込みが遅い大規模なデータセット をお読みください。

アプリの定期再発行

メーカーは定期的に自分たちのアプリを公開することをお勧めします。 Power Apps プラットフォームは継続的に最適化およびデプロイされるため、アプリを再公開すると、最新のプラットフォーム最適化内でアプリが再生成されます。

同じ数式を複数の場所で繰り返さないでください

複数のプロパティが同じ数式を実行する場合 (特に複雑な場合)、一度設定してから、後続のプロパティで最初のプロパティの出力を参照することを検討してください。 たとえば、コントロール A、B、C、D、E の 表示モード プロパティを同じ複雑な数式に設定しないでください。 代わりに、A の DisplayMode プロパティを複雑な式に設定し、B の DisplayMode プロパティを A の DisplayMode プロパティの結果に設定します。C、D、E についても同様に設定します。

すべてのテキスト入力コントロールで DelayOutput の有効化

テキスト入力 コントロールの値を参照する複数の数式またはルールがある場合、そのコントロールの DelayedOutput プロパティを true に設定します。 そのコントロールの テキスト プロパティは、すばやく連続して入力されたキーストロークが停止した後にのみ更新されます。 数式またはルールは何度も実行されず、アプリのパフォーマンスが改善します。

ルールと数式で Form.Updates を使用しないでください

ルールまたは数式で Form.Updates 変数を使用してユーザー入力値を参照する場合は、フォームのすべてのデータカードを反復処理し、毎回レコードを作成します。 アプリをより効率的にするには、データ カードまたはコントロール値から直接値を参照します。

DelayItemLoading と 読み込み中スピンを使用して、ギャラリーのパフォーマンスを向上させます

構成によっては、ギャラリーが表示されている行をレンダリングするのに時間がかかる場合があります。 パフォーマンスを向上させる方法はいくつかあります。

  • テンプレートを簡素化します。 たとえば、コントロールの数、検索への参照を減らすことを検討してください。
  • 複雑なテンプレートを使用するギャラリーでは、DelayItemLoading を true に設定し、LoadingSpinner を LoadingSpinner.Controls に設定することでメリットが得られます。 この変更により、レンダリング時間が長くなったときに認識されるエクスペリエンスが向上します。 DelayItemLoading は、テンプレートのレンダリングも延期します。これにより、画面とギャラリーの両方がリソースを奪い合うことがないため、画面の残りの部分をより迅速にレンダリングできます。

アプリの事前読込みを有効にしてパフォーマンスを向上させる

オプションで、アプリを事前に読み込み、パフォーマンスを向上させることができます。

  1. Power Apps にサインインして、メニューでアプリを選択します。

  2. 共有するアプリのその他のアクション (...) を選択し、設定を選択します。

  3. 設定パネルで、アプリをプリロードしてパフォーマンスを向上をはいに切り替えます。 その後、アプリが事前読込されます。

アプリを事前に読み込んでパフォーマンスを向上させる。

  1. Teams に埋め込まれているアプリの変更を有効にするには、アプリを削除して再度 Teams に追加します。

    注意

    これにより、コンパイルされたアプリ資産は認証されていないエンドポイントからアクセスできるようになり、認証前に読み込むことができるようになります。 ただし、ユーザーは、認証と承認が完了した後でのみ、アプリを使用してコネクタ経由でデータにアクセスできます。 この動作により、アプリがデータソースから取得したデータを、認証されていないユーザーが利用できないようになります。 コンパイルされたアプリ資産には、アプリコントロール (PCF コントロールなど) で作成されたテキスト、メディア資産 (画像など)、アプリ名、アプリが存在する環境 URL などを含む JavaScript ファイルの集合が含まれます。

    一般的に、アプリは接続を介してデータ ソースからメディアと情報を取得する必要があります。 接続からではなく、メディアと情報をアプリに追加する必要があり、機密情報であると見なされる場合は、この設定を無効にすることをお勧めします。 この設定を無効にすると、ユーザーがアプリにアクセスするまでの待ち時間が長くなることに注意してください。

デバイスに格納されたアプリ データ

ユーザーがアプリの起動時にアプリの詳細をすばやく取得できるようにするため、特定のデータはデバイスのブラウザー キャッシュにローカルに保存されます。 保存される情報には、アプリ、環境、接続の詳細が含まれます。 このデータは、各ブラウザーのストレージ制限に基づいてブラウザーに保存されたままになります。 保存されているデータを消去するには、各ブラウザの手順 を参照してください。

次の手順

アプリのパフォーマンスを最大化し、アプリ管理を維持しやすくするために、コーディング標準 を確認します。

関連項目

キャンバス アプリの実行フェーズとデータの呼び出しフローを理解する
一般的なキャンバス アプリのパフォーマンスの問題と解決策
キャンバス アプリのパフォーマンス低下の一般的な原因
Power Apps の一般的な問題と解決方法
Power Apps のスタートアップに関する問題のトラブルシューティング

注意

ドキュメントの言語設定についてお聞かせください。 簡単な調査を行います。 (この調査は英語です)

この調査には約 7 分かかります。 個人データは収集されません (プライバシー ステートメント)。