App-Sperrung für Ihre Registerkarten-App

Wenn ein Benutzer von einer App weg navigiert, kann die App entweder angehalten oder beendet werden. Sperrung bedeutet, dass sich die App im Hintergrund befindet und für den Benutzer nicht sichtbar ist. Beendigung bedeutet, dass die App vollständig geschlossen und aus dem Arbeitsspeicher entfernt wird. Das Anhalten einer App verbessert die nachfolgende Startzeit der Apps in Teams oder anderen Microsoft 365-Produkten, indem Sie einige Ressourcen und Assets im Arbeitsspeicher beibehalten können, die Sie verwenden können, wenn Sie Ihre App reaktivieren.

Bisher wurde die App-Sperrung als zwischengespeicherte App bezeichnet und nur in Teams unterstützt, aber jetzt wird sie für Teams-Apps unterstützt, die so erweitert wurden, dass sie auch auf andere Microsoft 365-Anwendungen ausgeführt werden.

Innerhalb von Teams wird die App-Unterbrechung für die folgenden Bereiche und Clients unterstützt:

Umfang   Desktop iOS Android
Personal ✔️ Cachelebensdauer: 30 Minuten ✔️ ❌
Chat ✔️ Cachelebensdauer: 30 Minuten ✔️ ❌
Kanal ✔️ Cachelebensdauer: 30 Minuten ✔️ ❌
Registerkarte "Besprechung" ✔️ Cachelebensdauer: 30 Minuten ✔️ ❌
Besprechungs-Seitenbereich oder Besprechungs-Apps ✔️ Cachelebensdauer: 20 Minuten ❌ ❌

Aktivieren der App-Unterbrechung

Gehen Sie wie folgt vor, um die App-Sperrung zu aktivieren:

  1. Rufen Sie die APIs app.lifeCycle.registerBeforeSuspendOrTerminate und app.lifeCycle.registerOnResumeHandler auf. Diese Handler sind erforderlich, um die App-Sperrung zu aktivieren. Weitere Informationen finden Sie im Lebenszyklusmodul , das in der TeamsJS-Referenz verfügbar ist.

    Der app.lifecycle.registerBeforeSuspendOrTerminate Handler gibt Ihnen die Möglichkeit, einige Aufgaben auszuführen, bevor Ihre App angehalten oder beendet wird, während der app.lifecycle.registerOnResumeHandler aufgerufen wird, wenn ein Benutzer zurück zu Ihrer App navigiert.

    Durch die Registrierung beider Handler wird eine App für die App-Sperrung aktiviert, aber es ist wichtig zu verstehen, dass durch die Registrierung nicht garantiert ist, dass die App nicht im Hintergrund beendet wird. Ob eine App beendet wird, hängt von anderen Faktoren ab, z. B. vom verfügbaren Arbeitsspeicher.

    Hinweis

    Zuvor teamsCore.registerBeforeUnloadHandler wurden sie teamsCore.registerOnLoadHandler verwendet, um das Zwischenspeichern von Apps zu ermöglichen, sind aber jetzt veraltet.

  2. Verwenden contentUrl und entityId an den resume-Handler übergeben, um zur richtigen Seite in Ihrer App zu leiten und den Host aufzurufen notifySuccess oder notifyFailure zu benachrichtigen, dass der App-Initialisierungsfluss abgeschlossen ist.

    • contentUrl: URL der Inhaltsseite hinzufügen.
    • entityId: Fügen Sie einen eindeutigen Bezeichner hinzu.
  3. Entsorgen Sie Ressourcen, und führen Sie alle erforderlichen Bereinigungen im beforeSuspendOrTerminate Handler durch.

Das folgende Flussdiagramm zeigt den ersten Start einer App, die sich für die App-Sperre entscheiden möchte (registrieren Sie die resume oder-Handler beforeSuspensionOrTerminate beim ersten Start der App):

Der Screenshot zeigt den Ablauf des ersten Starts der App im Besprechungs-Seitenbereich.

Das folgende Flussdiagramm zeigt den Start angehaltener Apps:

Der Screenshot zeigt den Ablauf des ausgesetzten Starts der App im Besprechungsseitenbereich.

Wenn Sie die App-Sperrung aktivieren, wird der iframe oder die Webansicht, die zum Hosten der eingebetteten App verwendet wird, wiederverwendet, während Benutzer zu verschiedenen Instanzen der App innerhalb eines Fensters navigieren. Der iframe oder die Webansicht, die zum Hosten der App verwendet wird, wird ausgeblendet, wenn die Benutzer die App verlassen, und angezeigt, wenn die Benutzer zur App zurückkehren.

Hinweis

Wenn die App-Sperre nicht aktiviert ist, wird der iframe oder die Webansicht jedes Mal neu erstellt, wenn der Benutzer die App startet.

Es gibt mehrere Gründe dafür, dass eine App nicht angehalten oder aus dem Cache entfernt wird. Einige allgemeine Gründe für Microsoft 365 Apps sind:

  • Die Gesamtspeicherauslastung ist hoch.
  • Die Gesamtzahl der angehaltenen Apps überschreitet die maximale Cachegröße. In diesem Fall wird die älteste angehaltene App entfernt.
  • Die App wird beendet, wenn der verfügbare Speicher des Computers niedrig ist.
  • Die App wird für lange Zeit angehalten, ohne fortgesetzt zu werden.
  • Die App kann nicht geladen werden und wird beendet.

Innerhalb der Teams-App sind einige der Gründe (die Zahlen hier können sich ändern):

  • Wenn die Auslastung des Systemspeichers hoch ist, wird die App aus dem Cache entfernt.
  • Die App wird beendet, wenn Teams das readyToUnload Signal von TeamsJS nicht innerhalb von 30 Sekunden nach dem Senden der beforeUnload Benachrichtigung empfängt.
  • Die App-Unterbrechung ist deaktiviert, wenn der Systemspeicher kleiner als 4 GB ist oder der verfügbare Arbeitsspeicher unter Windows kleiner als 1 GB bzw. unter Mac 512 MB ist.
  • Der Seitenbereich ist der einzige unterstützte frameContext für das Anhalten von Apps in Besprechungen.
  • Die App-Sperre wird für Besprechungen, in denen die Anzahl der eingeladenen Benutzer höher als 20 ist, nicht unterstützt.
  • Wenn die Teams-App unter iOS beendet wird, wird die App aus dem Cache entfernt.

Code example

Der folgende Codeausschnitt ist ein Beispiel für app.lifecycle.registerOnResumeHandler und-APIs app.lifecycle.registerBeforeSuspendOrTerminateHandler :

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 

}); 

Hinweis

Zuvor wurden APIs im teamsCore Modul verwendet, um das Zwischenspeichern von Apps zu ermöglichen. Wenn sich eine App sowohl für beide als auch app.lifecycleteamsCore für Paare von Handlern registriert, überschreiben die app.lifecycle Handler die teamsCore Handler.

Debugtool für zwischengespeicherte Apps

Hinweis

Das Debugtool für zwischengespeicherte Apps ist in der öffentlichen Entwicklervorschau für Teams-Apps verfügbar.

Sie können Proto Task Manager in Teams aktivieren, ein Debugtool, das den Status Ihrer zwischengespeicherten Apps anzeigt. Wählen Sie in Ihrem Teams-Client die Tasten CTRL+UMSCHALT+ALT+8 (Windows) oder BEFEHL+UMSCHALT+OPTION+8 (Mac), um den Proto Task-Manager zu öffnen.

Screenshot: Registerkarte

Die Registerkarte "AppCaching " enthält die folgenden Details:

  • Status: Zeigt den zwischengespeicherten oder nicht zwischengespeicherten Zustand der App an.
  • isActive: Zeigt den aktiven oder inaktiven Status der zwischengespeicherten App an.
  • timeElapsed: Zeigt die Zeit an, die seit dem Zwischenspeichern der App verstrichen ist.
  • supportsLoad: Zeigt an, ob die App den Load Handler registriert hat, wenn das App-Caching aktiviert ist.
  • supportsBeforeUnload: Zeigt an, ob die App den BeforeUnload Handler registriert hat, wenn das App-Caching aktiviert ist.
  • totalFrameMemory: Zeigt die Speicherauslastung der App an.
  • totalFrameCommitMemory: Zeigt die CPU-Auslastung der App an.

Registerkarten-Apps vor dem Zwischenspeichern

Hinweis

Das Precaching von Registerkarten-Apps wird nur in Web- und Desktopclients von Teams unterstützt.

Während die Zwischenspeicherung die nachfolgenden Ladezeiten einer App reduziert, optimiert die Vorabzwischenspeicherung die anfängliche Ladezeit einer App, indem Teams die App vorab laden kann. Teams lädt Apps im Hintergrund nach dem Start oder im Leerlauf, basierend auf den jüngsten App-Nutzungsmustern der Benutzer und dem Cacheverlauf der Apps. Die vorab geladenen Apps bleiben zwischengespeichert, bis der Benutzer sie öffnet, was zu einer schnelleren Ladezeit führt.

Wenn Sie Precaching aktivieren, nutzt Ihre App Ressourcen, und Telemetriedaten werden nachverfolgt, während sie sich im vorgespeicherten Zustand befinden. Wie Sie Ihre App für Precaching optimieren können, erfahren Sie unter "Bewährte Methoden".

Vorabcaching für Registerkarten-Apps aktivieren

Führen Sie die folgenden Schritte aus, um Precaching für Ihre Registerkarten-App zu aktivieren:

  1. Aktivieren Sie die App-Zwischenspeicherung.

  2. Aktualisieren Sie Ihr App-Manifest wie folgt:

    1. Legen Sie den Wert von showLoadingIndicator auf fest.true Diese Aktion stellt sicher, dass Teams wartet, bis Ihre App gesendet notifySuccess wird, um die Ladesequenz der App während des Vorspeicherns abzuschließen. Weitere Informationen finden Sie unter showLoadingIndicator.

    2. Fügen Sie das backgroundLoadConfiguration Objekt hinzu, und definieren Sie das contentUrl.

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

      Hinweis

      • Sie contentUrl dürfen keine kontextspezifischen Parameter wie die Teamwebsite-URL oder die Thread-ID enthalten, da Teams beim Start Apps ohne vorherigen Kontext lädt.
      • Sie contentUrl müssen generisch genug sein, um im Hintergrund ohne jegliche Benutzerinteraktion geladen zu werden.

      Weitere Informationen finden Sie unter backgroundLoadConfiguration.

Laden im Hintergrund überwachen

Sie können erkennen, ob Teams die App im Hintergrund ohne Benutzerinteraktion geladen hat, wenn Sie die isBackgroundLoad Eigenschaft überwachen. Wenn der Zustand der Eigenschaft lautet true, weist dies darauf hin, dass Teams die App im Hintergrund geladen hat und nicht mit dem Benutzer interagieren kann. Daher muss die App keine Benutzeroberflächenelemente wie Anmeldeaufforderungen rendern.

Überwachen Sie die isBackgroundLoad Eigenschaft im App-Kontext, um die App für effektives Laden und Rendern vor dem Cache zu optimieren. Weitere Informationen finden Sie unter isBackgroundLoad.

Bewährte Methoden

Im Folgenden finden Sie die bewährten Methoden für das Anhalten und Zwischenspeichern von Apps:

  • Es wird empfohlen, Webspeicher- oder Service Worker-Funktionen zu implementieren, um die Daten oder Webansicht lokal zu speichern. Diese Strategie hilft, die App bei nachfolgenden Starts schneller zu laden.

  • Registrieren Sie die App-Suspensionshandler frühzeitig in Ihrer Startsequenz, z. B. direkt nach dem Aufruf app.initialize und bevor die App gesendet wird notifySuccess. Wenn der Teams-Client diese Registrierungen nicht sieht, bevor der Benutzer die App verlässt, wird die App nicht zwischengespeichert.

  • Versuchen Sie, den Speicherbedarf zu verringern, wenn der app.lifecycle.onBeforeSuspendOrTerminateHandler Handler aufgerufen wird und die App angehalten wird. Geben Sie beispielsweise Verweise frei, entfernen Sie eventListener, halten Sie Synchronisierungsaufrufe an oder halten Sie Netzwerkanforderungen an.

  • Das Precaching erhöht zusätzlich zu den vom Benutzer initiierten Anforderungen den Datenverkehr zu Ihrer App. Stellen Sie sicher, dass der Endpunkt, den Sie als Endpunkt contentUrl bereitstellen, Hintergrundanforderungen für jeden Benutzer mehrmals pro Tag verarbeiten kann. Stellen Sie sicher, dass Sie die Telemetrieeinstellungen vornehmen, die erforderlich sind, um das Laden der App im Hintergrund zu ermöglichen.

  • Stellen Sie sicher, dass Ihre App im vorgespeicherten Zustand maximal 130 MB Arbeitsspeicher verwendet.

Allgemeine Einschränkungen

Im Folgenden sind allgemeine Einschränkungen für die App-Sperrung aufgeführt:

  • Es gibt keine Garantie, dass eine App angehalten wird. Es gibt Gründe, die zum Beenden einer App führen können, obwohl eine App die erforderlichen Handler registriert hat.

  • Eine App wird nur angehalten, wenn der Benutzer von der App weg navigiert. Wenn eine App über mehrere statische Registerkarten verfügt und der Benutzer zwischen Registerkarten wechselt, wird die Registerkarte nicht angehalten. Der Handler app.lifecycle.onBeforeSuspendOrTerminate, wird weiterhin aufgerufen.

  • Die angehaltene App kann im selben Fenster verwendet werden. Die App, die in einem Popupfenster angehalten wird, kann im Hauptfenster nicht wiederverwendet werden.

  • Wenn eine App angehalten wird, werden alle registrierten Handler gelöscht. Wenn die App fortgesetzt wird, müssen alle Handler, z. B themeChange . oder focusEnter, erneut registriert werden. Bei Unterbrechung werden keine Benachrichtigungen an die App gesendet. Wenn Ihre App Benachrichtigungen benötigt, auch wenn sie angehalten ist, ist die Sperrung möglicherweise nicht die richtige Lösung.

  • Nur Single-Page-Apps, die clientseitiges Routing für die Seitennavigation verwenden, können von der App-Sperrung und dem Fortsetzen profitieren. Es wird empfohlen, dieselbe Domäne für alle Kontexte Ihres App-Starts zu verwenden.

  • Es wird erwartet, dass eine App in den Ruhezustand wechselt, wenn sie angehalten wird. Wenn die App angehalten wird, sind keine SDK-Anforderungen zulässig.

  • Die Host-App ruft den resume Handler erst auf, wenn die suspendOrTerminate App-Sequenz abgeschlossen ist. Wenn ein Benutzer beispielsweise Registerkarte A Ihrer App startet und dann Registerkarte B derselben App startet, erhält Registerkarte B das resume Signal erst, wenn der suspendOrTerminate Handler auf Registerkarte A die Ausführung abgeschlossen hat.

  • Apps werden auf Fensterbasis zwischengespeichert. Das Zwischenspeichern von Apps erfolgt pro App (nicht pro Tab) innerhalb desselben Fensters.

  • Die Tabelle im Einführungsabschnitt " App-Suspension für Ihre Registerkarten-App" enthält Informationen dazu, was frameContext Teams für die Zwischenspeicherung unterstützt. Bei Nicht-Teams-Hubs wird nur FrameContext.Content zwischengespeichert, d. h., FrameContext.Task dass dies darin Dialog nicht unterstützt wird.

  • Registrieren Sie den beforeSuspendOrTerminate Handler nur, wenn Ihre App keine App-Unterbrechung erfordert, aber Zeit benötigt, um den Status sicher zu speichern (da das Verlassen der App dazu führen kann, dass der App-Inhalt abrupt aus dem Dokumentobjektmodell (DOM) entfernt wird). Wenn sich die App noch nicht für das resume Ereignis registriert hat, wird sie nach Abschluss des suspendOrTerminate Flusses aus dem DOM entfernt.

Einschränkungen innerhalb von Teams

Im Folgenden finden Sie die Einschränkungen für die App-Suspendierung innerhalb der Teams-App:

  • Der Teams-Client ruft den resume Handler erst auf, wenn die suspendOrTerminate App-Sequenz abgeschlossen ist. Wenn ein Benutzer beispielsweise Registerkarte A Ihrer App und dann Registerkarte B derselben App startet, erhält Registerkarte B das resume Signal erst, wenn der suspendOrTerminate Handler auf Registerkarte A die Ausführung abgeschlossen hat.

  • Die App-Unterbrechung wird für die Besprechungsphasen- oder Dialogkontexte (in TeamsJS v1.x als Aufgabenmodul bezeichnet) nicht unterstützt, da diese oben auf der Registerkarte geöffnet werden können und derselbe iframe oder dieselbe Webansicht nicht zum Rendern des Inhalts auf der Registerkarte und im Dialogfeld verwendet werden kann.

  • Befolgen Sie die Richtlinien in diesem Abschnitt, um Ihre App in die Teams-Besprechung zu integrieren. Registrieren Sie für die Unterstützung der App-Unterbrechung nur in Besprechungen die resume oder-Handler beforeSuspendOrTerminate , wenn der Kontext sidePanelist.

Problembehandlung

Apps werden nicht angehalten? Warum wird der Resume-Handler bei der nachfolgenden Navigation nicht aufgerufen?

  • Überprüfen Sie, ob die System- und verfügbaren Speicherbeschränkungen erfüllt sind.

  • Verringern Sie Ihren Speicherbedarf im Cache. Verwenden Sie den beforeSuspendOrTerminate Handler, um Ressourcen zu verwerfen, z. B. Releaseverweise und Entfernen von Ereignislistenern, die im Cache möglicherweise nicht benötigt werden.

Codebeispiel

Beispielname Beschreibung Node.js
Zwischenspeicherung von Apps Dieses Beispiel zeigt, wie Sie die Ladezeiten von Apps während Besprechungen mit Sidepanel Caching verbessern können, um die Benutzererfahrung in Microsoft Teams zu verbessern. Anzeigen

Siehe auch