タブ アプリのアプリの中断

ユーザーがアプリから離れると、アプリを中断または終了できます。 一時停止とは、アプリがバックグラウンドにあり、ユーザーに表示されていないことを意味します。 終了は、アプリが完全に閉じられ、メモリから削除されていることを意味します。 アプリを一時停止すると、アプリのリハイドレート時に使用できる一部のリソースと資産をメモリに保持できるため、Teams 内のアプリやその他の Microsoft 365 製品の以降の起動時間が短縮されます。

以前は、アプリの中断はキャッシュされたアプリと呼ばれ、Teams でのみサポートされていましたが、他の Microsoft 365 アプリケーション間で実行するように拡張された Teams アプリでもサポートされるようになりました。

Teams 内では、アプリの中断は次のスコープとクライアントでサポートされています。

アプリの中断を有効にする

アプリの中断を有効にするには、次の手順に従います。

1. app.lifeCycle.registerBeforeSuspendOrTerminate および app.lifeCycle.registerOnResumeHandler API を呼び出します。 これらのハンドラーは、アプリの中断を有効にするために必要です。 詳細については、TeamsJS リファレンスで使用できる ライフサイクル モジュール を参照してください。

   app.lifecycle.registerBeforeSuspendOrTerminate ハンドラーを使用すると、アプリが中断または終了する前にいくつかのタスクを実行し、ユーザーがアプリに戻ったときにapp.lifecycle.registerOnResumeHandlerが呼び出されます。

   両方のハンドラーを登録すると、アプリの中断が可能になりますが、登録してもアプリがバックグラウンドで終了しないという保証はないことを理解することが重要です。 アプリが終了するかどうかは、使用可能なメモリなどの他の要因によって異なります。

   注:

   以前は teamsCore.registerBeforeUnloadHandler と teamsCore.registerOnLoadHandler を使用してアプリのキャッシュを有効にしていましたが、現在は非推奨になりました。

2. contentUrlとentityIdを使用して、アプリ内の正しいページにルーティングし、notifySuccessまたはnotifyFailureを呼び出して、アプリの初期化フローが完了したことをホストに通知します。

   • contentUrl: コンテンツ ページ URL を追加します。
   • entityId: 一意の識別子を追加します。

3. リソースを破棄し、 beforeSuspendOrTerminate ハンドラーで必要なクリーンアップを実行します。

次のフロー図は、アプリの中断をオプトインするアプリの最初の起動 (アプリの初回起動時に resume または beforeSuspensionOrTerminate ハンドラーを登録する) を示しています。

次のフロー図は、中断されたアプリの起動を示しています。

アプリの中断を選択すると、ユーザーがウィンドウ内のアプリのさまざまなインスタンスに移動するときに、埋め込みアプリをホストするために使用される iframe または Webview が再利用されます。 アプリをホストするために使用される iframe または Webview は、ユーザーがアプリを離れると非表示になり、ユーザーがアプリに戻ったときに表示されます。

アプリが中断されない理由や、アプリがキャッシュから削除される理由は複数あります。 Microsoft 365 アプリ全体の一般的な理由は次のとおりです。

• メモリ負荷の合計が大きい。
• 中断されたアプリの合計数が最大キャッシュ サイズを超えています。 この状況では、最も古い中断されたアプリが削除されます。
• コンピューターの使用可能なメモリが不足している場合、アプリは終了します。
• アプリは再開されずに長い間中断されます。
• アプリの読み込みに失敗し、終了します。

Teams アプリ内には、いくつかの理由があります (ここでの数値は変更される可能性があります)。

• システム メモリの負荷が高い場合、アプリはキャッシュから削除されます。
• Teams がbeforeUnload通知を送信した後 30 秒以内に TeamsJS からreadyToUnloadシグナルを受け取らない場合、アプリは終了します。
• システム メモリが 4 GB 未満の場合、または使用可能なメモリが Windows の場合は 1 GB 未満、Mac では 512 MB 未満の場合、アプリの中断は無効になります。
• サイド パネルは、会議でのアプリの中断に対してサポートされている唯一の frameContext です。
• 招待されたユーザー数が 20 を超える会議では、アプリの中断はサポートされていません。
• iOS では、Teams アプリが終了すると、アプリはキャッシュから削除されます。

コード例

次のコード スニペットは、 app.lifecycle.registerOnResumeHandler API と app.lifecycle.registerBeforeSuspendOrTerminateHandler API の例です。

MicrosoftTeams.app.lifecycle.registerOnResumeHandler((data) => {  

   console.log("got resume call" , data.contentUrl, data.entityId);  

   // use contentUrl to route to correct page  
   // invoke notifySuccess when ready  

   app.notifySuccess();  

}); 

MicrosoftTeams.app.lifecycle.registerBeforeSuspendOrTerminateHandler(() => {  

   // dispose resources and resolve promise 

}); 

キャッシュされたアプリのデバッグ ツール

キャッシュされたアプリの状態を示すデバッグ ツールである Teams で Proto タスク マネージャーを有効にすることができます。 Teams クライアントで、Windows で Control + Shift + Alt + 8 キーを選択するか、Mac で Command + Shift + Option + 8 キーを選択して Proto タスク マネージャーを開きます。

[ AppCaching ] タブには、次の詳細が含まれています。

• state: アプリのキャッシュされた状態またはキャッシュされていない状態を表示します。
• isActive: キャッシュされたアプリのアクティブまたは非アクティブな状態を表示します。
• timeElapsed: アプリがキャッシュされてからの経過時間を示します。
• supportsLoad: アプリキャッシュが有効になっている場合に、アプリが Load ハンドラーを登録したかどうかを示します。
• supportsBeforeUnload: アプリキャッシュが有効になっている場合、アプリが BeforeUnload ハンドラーを登録したかどうかを示します。
• totalFrameMemory: アプリのメモリ使用量を表示します。
• totalFrameCommitMemory: アプリの CPU 使用率を表示します。

タブ アプリのプリキャッシング

キャッシュを使用すると、アプリの後続の読み込み時間が短縮されますが、プリキャッシングでは、Teams がアプリを事前読み込みできるようにすることで、アプリの初期読み込み時間が最適化されます。 Teams では、ユーザーの最近のアプリの使用パターンとアプリのキャッシュ履歴に基づいて、起動後またはアイドル時にバックグラウンドでアプリをプリロードします。 事前に読み込まれたアプリは、ユーザーがアプリを開くまでキャッシュされたままになります。その結果、読み込み時間が短縮されます。

プリキャッシングを有効にした場合、アプリはリソースを利用し、事前キャッシュされた状態の間にテレメトリ データが追跡されます。 プリキャッシング用にアプリを最適化する方法については、 ベスト プラクティスに関するページを参照してください。

タブ アプリのプリキャッシングを有効にする

タブ アプリのプリキャッシングを有効にするには、次の手順に従います。

1. アプリのキャッシュを有効にします。

2. アプリ マニフェストを次のように更新します。

   1. showLoadingIndicatorの値を true に設定します。 このアクションにより、アプリが notifySuccess を送信するまで Teams が待機し、プリキャッシング中にアプリの読み込みシーケンスが終了します。 詳細については、「 showLoadingIndicator」を参照してください。

   2. backgroundLoadConfiguration オブジェクトを追加し、contentUrlを定義します。

      {
      "backgroundLoadConfiguration": {
          "tabConfiguration": {
              "contentUrl": "https://www.contoso.com/content?host=msteams&isBackgroundLoad=true"
              }
          }
      }
      

      注:

      • contentUrlには、チーム サイトの URL やスレッド ID などのコンテキスト固有のパラメーターを含めることはできません。これは、Teams が起動中に事前のコンテキストを持たないアプリを読み込むためです。
      • contentUrlは、ユーザー操作なしでバックグラウンドで読み込むのに十分な汎用である必要があります。

      詳細については、「 backgroundLoadConfiguration」を参照してください。

バックグラウンド読み込みを監視する

isBackgroundLoad プロパティを監視する場合、ユーザー操作なしで Teams がアプリをバックグラウンドで読み込んだかどうかを確認できます。 プロパティの状態が trueされている場合は、Teams がアプリをバックグラウンドで読み込み、ユーザーと対話できないことを示します。 そのため、アプリはサインイン プロンプトなどの UI 要素をレンダリングする必要はありません。

アプリ コンテキストの isBackgroundLoad プロパティを監視して、アプリを最適化して、効果的な事前キャッシュの読み込みとレンダリングを行います。 詳細については、「 isBackgroundLoad」を参照してください。

ベスト プラクティス

アプリの中断とプリキャッシングのベスト プラクティスを次に示します。

• データまたは Webview をローカルに格納するには、Web ストレージまたはサービス ワーカー機能を実装することをお勧めします。 この方法は、以降の起動でアプリの読み込みを高速化するのに役立ちます。

• app.initializeを呼び出した直後やアプリがnotifySuccessを送信する前など、起動シーケンスの早い段階でアプリの中断ハンドラーを登録します。 ユーザーがアプリを離れる前に Teams クライアントにこれらの登録が表示されない場合、アプリはキャッシュされません。

• app.lifecycle.onBeforeSuspendOrTerminateHandler ハンドラーが呼び出され、アプリが中断されようとしているときに、メモリ占有領域を減らしてみてください。 たとえば、リリース参照、eventListeners の削除、同期呼び出しの一時停止、ネットワーク要求の停止などです。

• プリキャッシングにより、ユーザーが開始した要求に加えて、アプリへのトラフィックが増加します。 contentUrlとして指定したエンドポイントが、1 日にユーザーごとに複数回バックグラウンド要求を処理できることを確認します。 アプリのバックグラウンド読み込みに対応するために必要なテレメトリの調整を行っていることを確認します。

• アプリで、事前キャッシュされた状態で 130 MB 以下のメモリが使用されていることを確認します。

一般的な制限事項

アプリの中断に関する一般的な制限事項を次に示します。

• アプリが中断される保証はありません。 アプリが必要なハンドラーを登録した場合でも、アプリの終了につながる理由があります。

• アプリは、ユーザーがアプリから離れた場合にのみ中断されます。 アプリに複数の静的タブがある場合、ユーザーがタブを切り替えても、タブは中断されません。 ハンドラー app.lifecycle.onBeforeSuspendOrTerminateは引き続き呼び出されます。

• 中断されたアプリは、同じウィンドウ内で使用できます。 ポップアップ ウィンドウで中断されているアプリは、メイン ウィンドウで再利用できません。

• アプリが中断されると、登録されているすべてのハンドラーが削除されます。 アプリが再開されたら、 themeChange や focusEnterなど、すべてのハンドラーを再登録する必要があります。 一時停止時に通知はアプリに送信されません。 中断された場合でもアプリに通知が必要な場合は、中断が適切なソリューションではない可能性があります。

• ページ ナビゲーションにクライアント側ルーティングを使用する単一ページ アプリのみが、アプリの中断と再開のメリットを得ることができます。 アプリ起動のすべてのコンテキストで同じドメインを使用することをお勧めします。

• アプリは中断されたときにスリープ状態になると予想されます。 アプリが中断された場合、SDK 要求は許可されません。

• ホスト アプリは、アプリのsuspendOrTerminate シーケンスが完了した後にのみ、resume ハンドラーを呼び出します。 たとえば、ユーザーがアプリのタブ A を起動し、同じアプリのタブ B を起動した場合、タブ A のsuspendOrTerminate ハンドラーの実行が完了するまで、タブ B はresumeシグナルを取得しません。

• アプリはウィンドウごとにキャッシュされます。 アプリキャッシュは、同じウィンドウ内の (タブごとにではなく) アプリごとに行われます。

• 入門セクションの「 タブ アプリのアプリの中断」セクションの表は、Teams がキャッシュに対してサポートする frameContext に関する情報を提供します。 Teams 以外のハブの場合、FrameContext.Contentのみがキャッシュされます。つまり、Dialog内にあるFrameContext.Taskはサポートされていません。

• アプリがアプリの中断を必要としないが、状態を安全に保存する時間が必要な場合は、 beforeSuspendOrTerminate ハンドラーのみを登録します (アプリを離れると、アプリのコンテンツがドキュメント オブジェクト モデル (DOM) から突然削除される可能性があるため)。 アプリが resume イベントに登録されていない場合、 suspendOrTerminate フローが完了すると DOM から削除されます。

Teams 内の制限事項

Teams アプリ内でのアプリの中断の制限事項を次に示します。

• Teams クライアントは、アプリのsuspendOrTerminate シーケンスが完了した後にのみ、resume ハンドラーを呼び出します。 たとえば、ユーザーがアプリのタブ A を起動し、同じアプリのタブ B を起動した場合、タブ A のsuspendOrTerminate ハンドラーの実行が完了するまで、タブ B はresumeシグナルを取得しません。

• アプリの中断は、会議ステージまたはダイアログ (TeamsJS v1.x ではタスク モジュールと呼ばれます) コンテキストではサポートされていません。これは、タブの上で開くことができるため、同じ iframe または Webview を使用してタブとダイアログのコンテンツをレンダリングできないためです。

• このセクションのガイドラインに従って、Teams 会議でアプリをアプリの中断にオンボードします。 会議でのみアプリの中断サポートを行う場合は、コンテキストがsidePanelされている場合は、resumeまたはbeforeSuspendOrTerminate ハンドラーを登録します。

トラブルシューティング

アプリが中断されていませんか? 後続のナビゲーションで再開ハンドラーが呼び出されないのはなぜですか?

• システムと使用可能なメモリ制約が満たされているかどうかを確認します。

• キャッシュ時のメモリ 占有領域を減らします。 beforeSuspendOrTerminate ハンドラーを使用して、リソースを破棄します。たとえば、リリース参照や、キャッシュ時に不要な可能性があるイベント リスナーを削除します。

コード サンプル

関連項目

• プライベート タブを作成する
• チャネル タブまたはグループ タブを作成する
• 会議用のビルド タブ