Améliorer les performances avec les sources de données
Dans l’unité précédente, vous avez découvert que les sources de données sont souvent la raison principale du ralentissement des performances dans votre application. Dans cette unité, vous allez découvrir quelques-unes des techniques courantes que vous pouvez appliquer pour limiter ces problèmes de performance.
Mettre en cache les données à l’aide de collections
Dans votre application, vous interrogez souvent les mêmes données à plusieurs reprises, par exemple pour extraire les listes des départements pour vos menus déroulants. Dans ce cas, vous pouvez interroger les données une seule fois, puis réutiliser ces données dans toute l’application. Les appels répétitifs à la source de données sur le réseau sont ainsi réduits. Voici un exemple de ce processus.
Dans votre application, plusieurs écrans permettent d’afficher un menu déroulant permettant de sélectionner le département. La liste des départements est conservée dans Microsoft Dataverse, dans une table nommée DepartmentList. Sur chaque instance du menu, vous utilisez la formule suivante :
Filter(DepartmentList, Status = "Active")
Ceci fonctionne correctement.
Une fois que vous avez terminé l’application, vous vous rendez compte que vous interrogez la table DepartmentList plusieurs fois, même s’il s’agit d’informations statiques. Vous pouvez modifier votre application et créer une collection avec la propriété OnStart de l’application, qui stocke les informations à l’aide de la formule suivante :
Collect(collectDepartmentList, Filter(DepartmentList, Status = "Active"))
Après avoir stocké ces informations, vous pouvez redéfinir la propriété Items des contrôles déroulants sur collectDepartmentList au lieu de Filter(DepartmentList, Status = "Active"). Ces petites modifications permettent au final d’améliorer les performances de votre application. De plus, comme vous maîtrisez de mieux en mieux la technique, vous pouvez créer votre application de cette façon dès le début, ce qui réduit le nombre de formules que vous devez écrire et maintenir.
Soyez prudent avec la délégation
Gardez à l’esprit que la fonction Collect n’est pas délégable. Par défaut, cela signifie que seuls les 500 premiers éléments sont renvoyés depuis votre source de données et stockés dans la collection. Veillez à bien prévoir cette limitation lors de l’implémentation de l’utilisation de collections dans votre application.
La délégation affecte également les performances
Quand vous avez découvert la délégation, l’accent a été mis sur la façon de retourner le bon nombre de lignes pour votre source de données. Il est également important de se rappeler que la délégation, en particulier pour les applications mobiles, peut affecter les performances.
Quand une formule délègue à la source de données, tout le traitement est géré par la source de données, et seules les lignes correspondantes sont retournées au moyen du réseau à l’application pour l’affichage. Si une fonction n’est pas délégable, il est courant de redéfinir la limite de délégation sur 2 000 lignes. Autrement dit, les 2 000 premières lignes sont téléchargées sur le réseau, puis traitées localement. Dans les scénarios où vous êtes sur une connexion mobile lente ou un sur un appareil mobile bas de gamme, ce traitement peut prendre un temps considérable, aboutissant à une mauvaise expérience pour l’utilisateur.
Essayez autant que possible d’utiliser seulement des fonctions délégables. Si votre fonction n’est pas délégable, prévoyez l’impact sur l’utilisateur final.
Utiliser la fonction Concurrent pour charger plusieurs sources de données
Vous avez découvert comment utiliser des collections pour mettre en cache des données dans votre application. Quand vous implémentez cette fonctionnalité dans votre application, il n’est pas rare que plusieurs collections se chargent au moment du démarrage de l’application. Votre propriété OnStart peut se présenter comme suit.
Collect(collectDepartmentList, Filter(DepartmentList, Status =
"Active")); Collect(collectCompanyList,
CompanyList);Collect(collectRegions, RegionList)
Dans cet exemple, vous créez trois collections, mais elles sont traitées chacune leur tour. Ainsi, si le traitement de chacune d’elles prend 3 secondes, votre utilisateur doit attendre 9 secondes pour que l’application démarre.
La fonction Concurrent vous permet de traiter tous ces appels en même temps. Vous pouvez modifier votre code comme suit.
Concurrent(
Collect(collectDepartmentList, Filter(DepartmentList, Status = "Active")),
Collect(collectCompanyList, CompanyList),
Collect(collectRegions, RegionList)
)
Désormais, les trois formules s’exécutent simultanément. Votre temps de chargement est réduit à trois secondes. Concurrent est un excellent moyen d’éviter des délais importants pour les appels asynchrones.
Fonctionnalités d’évaluation et expérimentales
Dans Power Apps, vous pouvez implémenter d’autres fonctionnalités avancées dans votre application. Vous pouvez y accéder en sélectionnant Fichier sur la barre de menus, puis en choisissant Paramètres de l’application et Paramètres avancés. La liste des options que vous voyez est en constante évolution, mais une ou plusieurs fonctionnalités liées aux performances sont souvent présentes.
Fonctionnalités d’évaluation
Les fonctionnalités d’évaluation sont des fonctionnalités bien testées et dont la publication officielle est proche. Elles seront bientôt disponibles pour toutes les applications. Le fait de tester et de comprendre ces fonctionnalités vous permet de vous préparer pour le moment où elles deviendront standard ; la plupart sont activées par défaut dans les nouvelles applications.
« Chargement différé » est un exemple de fonctionnalité d’évaluation actuelle qui permet d’améliorer les performances. Cette fonctionnalité « accélère le temps de démarrage de votre application en définissant des appels d’expression d’écran à la demande ». Autrement dit, les écrans ne sont pas traités tant que l’utilisateur n’accède pas à l’écran, ce qui accélère le démarrage et l’exécution de l’application.
Fonctionnalités expérimentales
Les fonctionnalités expérimentales sont des fonctionnalités qui peuvent changer, s’interrompre ou disparaître à tout moment. Ces fonctionnalités sont désactivées par défaut. Vous pouvez parfois trouver ici aussi des fonctionnalités liées aux performances : cela vaut donc la peine d’y jeter un coup d’œil. Gardez cependant à l’esprit que vous prenez un risque en les intégrant à des applications en production, car elles peuvent évoluer, changer complètement ou disparaître.
Parfois, vous verrez peut-être une fonctionnalité expérimentale liée aux performances d’une application. Vous pouvez toujours l’activer et la tester, puis revenir dans Paramètres pour la désactiver.
OnStart ou OnVisible
OnStart et OnVisible font partie de votre kit de ressources pour la création d’applications de qualité : du point de vue des performances, elles peuvent avoir un impact majeur.
OnStart : il s’agit d’une propriété au niveau de l’application. Les formules placées dans cette propriété sont exécutées une seule fois quand l’application démarre, et jamais après cela. Toutes les formules doivent être traitées avant l’ouverture de l’application. Ceci permet souvent d’initialiser les données dont vous avez besoin dans toute l’application.
OnVisible : il s’agit d’une propriété au niveau d’un écran. Les formules placées dans cette propriété sont exécutées chaque fois qu’un utilisateur accède à l’écran. L’écran s’affiche avant la fin du traitement de la formule.
Du point de vue des performances, la principale considération est le moment où le code s’exécute. Une seule fois, quand l’application démarre, ou chaque fois qu’un écran s’affiche. La collection destinée aux départements évoquée plus haut dans ce module en est un bon exemple. Ce code se charge dans la propriété OnStart de l’application. Cela signifie qu’il a été chargé une seule fois, puis qu’il reste disponible. Si vous avez déplacé ce code de OnStart à OnVisible, vous perdez l’avantage de la collection. Si la formule se trouvait dans la propriété OnVisible, chaque fois que l’utilisateur a accédé à l’écran, la source de données a été interrogée. Dans ce cas, cela fonctionnerait de la même façon que si vous laissiez le code dans la liste déroulante.
Cela ne signifie pas que vous ne devez pas utiliser OnVisible. OnVisible convient bien pour les formules qui se rapportent à l’écran actuel que vous devez exécuter. De plus, OnVisible est non bloquante. Par conséquent, vos utilisateurs n’ont pas à attendre que l’exécution de la formule se termine pour voir l’écran, ce qui réduit le temps pendant lequel un écran blanc est montré à l’utilisateur.
Dans la plupart des applications, vous utilisez un mélange de OnStart et de OnVisible pour obtenir une expérience optimale.
Résumé
Comme vous pouvez le voir, il existe de nombreuses options pour la création de votre application et l’interaction avec les sources de données. La liste de cette unité est loin d’être exhaustive. Les conseils donnés ici sont destinés à vous guider pour obtenir de meilleures performances, mais vos résultats peuvent varier. C’est en appliquant ces techniques à vos applications que vous découvrirez ce qui fonctionne le mieux pour vous et pour votre environnement.
Dans l’unité suivante, vous allez découvrir les techniques de test et de résolution des problèmes.