Suspension de l’application pour votre application d’onglet

Lorsqu’un utilisateur quitte une application, celle-ci peut être suspendue ou arrêtée. La suspension signifie que l’application est en arrière-plan et n’est pas visible par l’utilisateur. L’arrêt signifie que l’application est complètement fermée et supprimée de la mémoire. La suspension d’une application améliore le temps de lancement ultérieur des applications dans Teams ou d’autres produits Microsoft 365, en vous permettant de conserver en mémoire certaines ressources et ressources que vous pouvez utiliser lorsque vous réalimentez votre application.

Auparavant, la suspension d’application était appelée application mise en cache et était prise en charge uniquement dans Teams, mais elle est désormais prise en charge pour les applications Teams étendues pour s’exécuter également sur d’autres applications Microsoft 365.

Dans Teams, la suspension d’application est prise en charge pour les étendues et les clients suivants :

Activer la suspension de l’application

Pour activer la suspension de l’application, procédez comme suit :

1. Appelez les API app.lifeCycle.registerBeforeSuspendOrTerminate et app.lifeCycle.registerOnResumeHandler . Ces gestionnaires sont nécessaires pour activer la suspension de l’application. Pour plus d’informations, consultez le module de cycle de vie disponible dans la référence TeamsJS.

   Le app.lifecycle.registerBeforeSuspendOrTerminate gestionnaire vous donne la possibilité d’effectuer certaines tâches avant la suspension ou l’arrêt de votre application, tandis que le app.lifecycle.registerOnResumeHandler est appelé lorsqu’un utilisateur revient à votre application.

   L’inscription des deux gestionnaires permet à une application de suspendre l’application, mais il est important de comprendre que l’inscription ne garantit pas que l’application ne se termine pas en arrière-plan. La fin ou non d’une application dépend d’autres facteurs, tels que la mémoire disponible.

   Remarque

   Auparavant teamsCore.registerBeforeUnloadHandler , et teamsCore.registerOnLoadHandler étaient utilisés pour activer la mise en cache des applications, mais ils sont désormais déconseillés.

2. Utilisez et entityId passez contentUrl dans le gestionnaire de reprise pour acheminer vers la page appropriée dans votre application et appeler notifySuccess ou notifyFailure pour informer l’hôte que le flux d’initialisation de l’application est terminé.

   • contentUrl : ajouter l’URL de la page de contenu.
   • entityId : ajoutez un identificateur unique.

3. Supprimer les ressources et effectuer tout nettoyage nécessaire dans le beforeSuspendOrTerminate gestionnaire.

Le diagramme de flux suivant montre le premier lancement d’une application qui souhaite accepter la suspension de l’application (inscrire les resume gestionnaires ou beforeSuspensionOrTerminate lors du premier lancement de l’application) :

Le diagramme de flux suivant montre le lancement d’applications suspendues :

Lorsque vous optez pour la suspension de l’application, l’iframe ou l’affichage web utilisé pour héberger l’application incorporée est réutilisé lorsque les utilisateurs accèdent à différentes instances de l’application dans une fenêtre. L’iframe ou la vue web utilisée pour héberger l’application est masqué lorsque les utilisateurs quittent l’application et s’affiche quand les utilisateurs reviennent à l’application.

Il existe plusieurs raisons pour lesquelles une application n’est pas suspendue ou pour qu’une application soit supprimée du cache. Voici quelques raisons générales pour les applications Microsoft 365 :

• La charge mémoire totale est élevée.
• Le nombre total d’applications suspendues dépasse la taille maximale du cache. Dans ce cas, l’application suspendue la plus ancienne est supprimée.
• L’application est arrêtée si la mémoire disponible de l’ordinateur est insuffisante.
• L’application est suspendue pendant une longue période sans être reprise.
• Le chargement de l’application échoue et se termine.

Dans l’application Teams, certaines des raisons sont (les nombres ici sont susceptibles d’être modifiés) :

• Si la charge de mémoire système est élevée, l’application est supprimée du cache.
• L’application est arrêtée si Teams ne reçoit pas le readyToUnload signal de TeamsJS dans les 30 secondes suivant l’envoi de la beforeUnload notification.
• La suspension de l’application est désactivée si la mémoire système est inférieure à 4 Go ou si la mémoire disponible est inférieure à 1 Go sur Windows ou 512 Mo sur Mac.
• Le panneau latéral est le seul frameContext pris en charge pour la suspension d’application dans les réunions.
• La suspension de l’application n’est pas prise en charge pour les réunions où le nombre d’utilisateurs invités est supérieur à 20.
• Sur iOS, lorsque l’application Teams est arrêtée, l’application est supprimée du cache.

Exemple de code

L’extrait de code suivant est un exemple d’API app.lifecycle.registerOnResumeHandler et 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 

}); 

Outil de débogage pour les applications mises en cache

Vous pouvez activer le Gestionnaire des tâches Proto dans Teams, un outil de débogage qui montre les status de vos applications mises en cache. Dans votre client Teams, sélectionnez les touches Ctrl+Maj+Alt+8 sur Windows ou Commande+Maj+Option+8 sur Mac pour ouvrir le Gestionnaire des tâches Proto.

L’onglet AppCaching contient les détails suivants :

• state : affiche l’état mis en cache ou non mis en cache de l’application.
• isActive : affiche le status actif ou inactif de l’application mise en cache.
• timeElapsed : indique le temps écoulé depuis la mise en cache de l’application.
• supportsLoad : indique si l’application a inscrit le gestionnaire si la Load mise en cache de l’application est activée.
• supportsBeforeUnload : indique si l’application a inscrit le gestionnaire si la BeforeUnload mise en cache de l’application est activée.
• totalFrameMemory : affiche l’utilisation de la mémoire de l’application.
• totalFrameCommitMemory : affiche l’utilisation du processeur de l’application.

Applications d’onglet de précaching

Bien que la mise en cache réduise les temps de chargement suivants d’une application, le précaching optimise le temps de chargement initial d’une application en permettant à Teams de précharger l’application. Teams précharge les applications en arrière-plan après le lancement ou en cas d’inactivité, en fonction des modèles d’utilisation récents des applications des utilisateurs et de l’historique du cache des applications. Les applications préchargées restent mises en cache jusqu’à ce que l’utilisateur ouvre l’application, ce qui entraîne un temps de chargement plus rapide.

Si vous activez le précaching, votre application utilise des ressources et les données de télémétrie sont suivies dans un état précached. Pour savoir comment optimiser votre application pour le précaching, consultez les meilleures pratiques.

Activer le précaching pour les applications d’onglet

Pour activer le précaching pour votre application d’onglet, procédez comme suit :

1. Activer la mise en cache des applications.

2. Mettez à jour le manifeste de votre application comme suit :

   1. Définissez la valeur de showLoadingIndicator sur true. Cette action garantit que Teams attend que votre application envoie notifySuccess pour conclure la séquence de chargement de l’application pendant le précaching. Pour plus d’informations, consultez showLoadingIndicator.

   2. Ajoutez l’objet backgroundLoadConfiguration et définissez le contentUrl.

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

      Remarque

      • Le ne peut pas contenir de paramètres spécifiques au contexte, tels que l’URL contentUrl du site d’équipe ou l’ID de thread, car Teams charge des applications sans contexte antérieur au lancement.
      • Le contentUrl doit être suffisamment générique pour être chargé en arrière-plan sans aucune interaction de l’utilisateur.

      Pour plus d’informations, consultez backgroundLoadConfiguration.

Surveiller le chargement en arrière-plan

Vous pouvez déterminer si Teams a chargé l’application en arrière-plan sans interaction de l’utilisateur si vous surveillez la isBackgroundLoad propriété. Si l’état de la propriété est true, cela indique que Teams a chargé l’application en arrière-plan et n’est pas en mesure d’interagir avec l’utilisateur. Par conséquent, l’application n’a pas besoin de restituer des éléments d’interface utilisateur tels que des invites de connexion.

Surveillez la isBackgroundLoad propriété dans le contexte de l’application pour optimiser l’application pour un chargement et un rendu de précache efficaces. Pour plus d’informations, consultez isBackgroundLoad.

Meilleures pratiques

Voici les meilleures pratiques pour la suspension et le précaching des applications :

• Nous vous recommandons d’implémenter des fonctionnalités de stockage web ou de service worker pour stocker les données ou la vue web localement. Cette stratégie permet de charger l’application plus rapidement lors des lancements suivants.

• Inscrivez les gestionnaires de suspension d’application au début de votre séquence de lancement, par exemple juste après l’appel app.initialize et avant que l’application envoie notifySuccess. Si le client Teams ne voit pas ces inscriptions avant que l’utilisateur quitte l’application, l’application n’est pas mise en cache.

• Essayez de réduire votre empreinte mémoire lorsque le app.lifecycle.onBeforeSuspendOrTerminateHandler gestionnaire est appelé et que l’application est sur le point d’être suspendue. Par exemple, libérer des références, supprimer eventListeners, suspendre les appels de synchronisation ou arrêter les demandes réseau.

• Le précaching augmente le trafic vers votre application en plus des demandes lancées par l’utilisateur. Assurez-vous que le point de terminaison que vous fournissez en tant que contentUrl peut gérer les demandes en arrière-plan plusieurs fois pour chaque utilisateur dans une journée. Veillez à effectuer les ajustements de télémétrie nécessaires pour prendre en charge le chargement en arrière-plan de l’application.

• Vérifiez que votre application utilise moins de 130 Mo de mémoire dans l’état précached.

Limitations générales

Voici les limitations générales relatives à la suspension de l’application :

• Il n’existe aucune garantie qu’une application sera suspendue. Il existe des raisons qui peuvent entraîner l’arrêt de l’application, même si une application a inscrit les gestionnaires requis.

• Une application est suspendue uniquement lorsque l’utilisateur quitte l’application. Si une application a plusieurs onglets statiques, lorsque l’utilisateur bascule entre les onglets, l’onglet n’est pas suspendu. Le gestionnaire, app.lifecycle.onBeforeSuspendOrTerminate, sera toujours appelé.

• L’application suspendue peut être utilisée dans la même fenêtre. L’application suspendue dans une fenêtre contextuelle ne peut pas être réutilisée dans la fenêtre principale.

• Lorsqu’une application est suspendue, tous les gestionnaires inscrits sont supprimés. Lorsque l’application reprend, tous les gestionnaires, tels que themeChange ou focusEnter, doivent être réinscrits. Aucune notification n’est envoyée à l’application en cas de suspension. Si votre application nécessite des notifications même en cas de suspension, la suspension peut ne pas être la bonne solution.

• Seules les applications monopages qui utilisent le routage côté client pour la navigation de page peuvent bénéficier de la suspension et de la reprise des applications. Il est recommandé d’utiliser le même domaine dans tous les contextes du lancement de votre application.

• Une application est censée être en veille lorsqu’elle est suspendue. Aucune demande de KIT de développement logiciel (SDK) n’est autorisée lorsque l’application est suspendue.

• L’application hôte appelle le resume gestionnaire uniquement une fois la suspendOrTerminate séquence de l’application terminée. Par exemple, si un utilisateur lance l’onglet A de votre application, puis lance l’onglet B de la même application, l’onglet B n’obtient pas le resume signal tant que le gestionnaire de l’onglet suspendOrTerminate A n’est pas exécuté.

• Les applications sont mises en cache par fenêtre. La mise en cache des applications se produit par application (et non par onglet) dans la même fenêtre.

• Le tableau de la section d’introduction, Suspension de l’application pour votre application d’onglet, fournit des informations sur ce que frameContext Teams prend en charge pour la mise en cache. Pour les hubs non-Teams, seul FrameContext.Content est mis en cache, FrameContext.Task ce qui signifie que l’intérieur Dialog n’est pas pris en charge.

• Inscrivez uniquement le beforeSuspendOrTerminate gestionnaire si votre application ne nécessite pas de suspension de l’application, mais qu’elle a besoin de temps pour enregistrer l’état en toute sécurité (car quitter l’application peut entraîner la suppression abrupte du contenu de l’application du modèle DOM (Document Object Model)). Si l’application n’est pas inscrite pour l’événement resume , elle est supprimée du DOM une fois le suspendOrTerminate flux terminé.

Limitations dans Teams

Voici les limitations de la suspension de l’application dans l’application Teams :

• Le client Teams appelle le resume gestionnaire uniquement une fois la suspendOrTerminate séquence de l’application terminée. Par exemple, si un utilisateur lance l’onglet A de votre application, puis l’onglet B de la même application, l’onglet B ne reçoit pas le resume signal tant que l’exécution du gestionnaire de l’onglet suspendOrTerminate A n’est pas terminée.

• La suspension d’application n’est pas prise en charge pour les contextes de la phase de réunion ou de la boîte de dialogue (appelé module de tâche dans TeamsJS v1.x), car ceux-ci peuvent être ouverts au-dessus de l’onglet et le même iframe ou vue web ne peut pas être utilisé pour afficher le contenu dans l’onglet et la boîte de dialogue.

• Suivez les instructions de cette section pour intégrer votre application à la suspension de l’application dans une réunion Teams. Pour la prise en charge de la suspension d’application uniquement dans les réunions, inscrivez les resume gestionnaires ou beforeSuspendOrTerminate si le contexte est sidePanel.

Résolution des problèmes

Les applications ne sont pas suspendues ? Pourquoi le gestionnaire de reprise n’est-il pas appelé lors de la navigation suivante ?

• Vérifiez si les contraintes système et mémoire disponible sont respectées.

• Réduisez l’empreinte mémoire lors de la mise en cache. Utilisez le beforeSuspendOrTerminate gestionnaire pour supprimer les ressources, par exemple libérer des références et supprimer les écouteurs d’événements qui peuvent ne pas être nécessaires lorsqu’ils sont mis en cache.

Exemple de code

Voir aussi

• Créer un onglet personnel
• Créer un onglet de canal ou un onglet de groupe
• Onglets générer pour la réunion