Partager via

Virtualisation des données ListView et GridView

Remarque
Pour plus d’informations, consultez la session //build/ considérablement augmenter les performances lorsque les utilisateurs interagissent avec de grandes quantités de données dans GridView et ListView.

Améliorez les performances de ListView et GridView et le temps de démarrage par le biais de la virtualisation des données. Pour la virtualisation de l’interface utilisateur, la réduction des éléments et la mise à jour progressive des éléments, consultez Optimiser les performances ListView et GridView pour WinUI.

Une méthode de virtualisation des données est nécessaire pour un jeu de données si volumineux qu’il ne peut pas ou ne doit pas tous être stocké en mémoire à la fois. Vous chargez une partie initiale en mémoire (à partir du disque local, du réseau ou du cloud) et appliquez la virtualisation de l’interface utilisateur à ce jeu de données partiel. Vous pouvez charger ultérieurement des données de manière incrémentielle ou à partir de points arbitraires dans le jeu de données master (accès aléatoire), à la demande. Si la virtualisation des données est appropriée pour vous dépend de nombreux facteurs.

  • Taille de votre jeu de données
  • Taille de chaque élément
  • Source du jeu de données (disque local, réseau ou cloud)
  • Consommation globale de mémoire de votre application WinUI

Note N’oubliez pas qu’une fonctionnalité est activée par défaut pour ListView et GridView qui affiche des visuels d’espace réservé temporaires pendant que l’utilisateur effectue un panoramique ou un défilement rapide. À mesure que les données sont chargées, ces visuels d’espace réservé sont remplacés par votre modèle d’élément. Vous pouvez désactiver la fonctionnalité en définissant ListViewBase.ShowsScrollingPlaceholders sur false, mais si vous le faites, nous vous recommandons d’utiliser l’attribut x :Phase pour afficher progressivement les éléments dans votre modèle d’élément. Consultez Mettre à jour les éléments ListView et GridView progressivement.

Voici plus d’informations sur les techniques de virtualisation des données d’accès incrémentiel et aléatoire.

Virtualisation des données incrémentielles

La virtualisation des données incrémentielles charge les données de manière séquentielle. Un ListView qui utilise la virtualisation des données incrémentielles peut être utilisé pour afficher une collection d’un million d’éléments, mais seuls 50 éléments sont chargés initialement. À mesure que l’utilisateur effectue un panoramique ou un défilement, les cinquante éléments suivants sont chargés. À mesure que les éléments sont chargés, le curseur de la barre de défilement diminue de taille. Pour ce type de virtualisation de données, vous écrivez une classe de source de données qui implémente ces interfaces.

Une source de données comme celle-ci est une liste en mémoire qui peut être étendue en permanence. Le contrôle d'éléments demandera des éléments à l’aide de l’indexeur IList standard et des propriétés de comptage. Le nombre doit représenter le nombre d’éléments localement, et non la taille réelle du jeu de données.

Lorsque le contrôle éléments se rapproche de la fin des données existantes, il appelle ISupportIncrementalLoading.HasMoreItems. Si vous retournez true, il appelle ISupportIncrementalLoading.LoadMoreItemsAsync, en passant un nombre conseillé d’éléments à charger. Selon l’endroit où vous chargez des données à partir de (disque local, réseau ou cloud), vous pouvez choisir de charger un nombre différent d’éléments que ce qui est recommandé. Par exemple, si votre service prend en charge les lots de 50 éléments, mais que le contrôle d’éléments demande seulement 10, vous pouvez charger 50. Chargez les données de votre serveur principal, ajoutez-les à votre liste et déclenchez une notification de modification via INotifyCollectionChanged ou IObservableVector<T> afin que le contrôle d’éléments sache les nouveaux éléments. Retournez également le nombre d’éléments que vous avez réellement chargés. Si vous chargez moins d’éléments que indiqué, ou si le contrôle d’éléments a été endommagé ou fait défiler encore plus loin dans l’intervalle, votre source de données sera appelée à nouveau pour plus d’éléments et le cycle se poursuit. ISupportIncrementalLoading reste disponible dans le Kit de développement logiciel (SDK) d’application Windows. Vous pouvez donc utiliser le même modèle de chargement incrémentiel dans une application WinUI.

Virtualisation des données d’accès aléatoire

La virtualisation des données d’accès aléatoire permet le chargement à partir d’un point arbitraire dans le jeu de données. ListView qui utilise la virtualisation des données d’accès aléatoire pour afficher une collection d’un million d’éléments peut charger des éléments de 100 000 à 100 050. Si l’utilisateur passe ensuite au début de la liste, le contrôle charge les éléments 1 à 50. À tout moment, le pouce de la barre de défilement indique que ListView contient un million d’éléments. La position du pouce de la barre de défilement est relative à l’emplacement où se trouvent les éléments visibles dans l’ensemble du jeu de données de la collection. Ce type de virtualisation des données peut réduire considérablement les besoins en mémoire et les temps de chargement de la collection. Pour l’activer, vous devez écrire une classe de source de données qui extrait des données à la demande, gère un cache local et implémente ces interfaces.

IItemsRangeInfo fournit des informations sur les éléments que le contrôle utilise activement. Le contrôle Éléments appelle cette méthode chaque fois que son affichage change et inclut ces deux ensembles de plages.

  • Ensemble d’éléments qui se trouvent dans la fenêtre d’affichage.
  • Ensemble d'éléments non virtualisés que le contrôle utilise mais qui peuvent ne pas être dans la fenêtre d'affichage.
    • Tampon d'éléments entourant la fenêtre d’affichage que le contrôle d’éléments maintient pour un défilement tactile fluide.
    • Élément ciblé.
    • Premier élément.

En implémentant IItemsRangeInfo, votre source de données sait quels éléments doivent être récupérés et mis en cache, et quand découper les données du cache qui n’est plus nécessaire. IItemsRangeInfo utilise des objets ItemIndexRange pour décrire un ensemble d’éléments en fonction de leur index dans la collection. Cela évite les pointeurs d’élément, qui peuvent ne pas être corrects ou stables. IItemsRangeInfo est conçu pour être utilisé par une seule instance d’un contrôle d’éléments, car il s’appuie sur des informations d’état pour ce contrôle d’éléments. Si plusieurs contrôles d’éléments ont besoin d’accéder aux mêmes données, vous avez besoin d’une instance distincte de la source de données pour chacune d’elles. Ils peuvent partager un cache commun, mais la logique de purge du cache sera plus compliquée. IItemsRangeInfo reste disponible dans le Kit de développement logiciel (SDK) d’application Windows, de sorte que les mêmes techniques de mise en cache à accès aléatoire s’appliquent aux contrôles WinUI.

Voici la stratégie de base pour votre source de données de virtualisation à accès aléatoire.

  • Lorsque vous êtes invité à indiquer un élément
    • Si vous l’avez disponible en mémoire, retournez-la.
    • Si vous ne l’avez pas, retournez soit null, soit un élément de remplacement.
    • Utilisez la demande d’un élément (ou les informations de plage d’IItemsRangeInfo) pour savoir quels éléments sont nécessaires et pour récupérer des données pour les éléments de votre serveur principal de manière asynchrone. Après avoir récupéré les données, déclenchez une notification de modification via INotifyCollectionChanged ou IObservableVector<T> afin que le contrôle d’éléments connaisse le nouvel élément.
  • (Si vous le souhaitez) lorsque la fenêtre d’affichage de la visualisation des éléments change, identifiez les éléments nécessaires à partir de votre source de données via votre implémentation de IItemsRangeInfo.

Au-delà de cela, la stratégie de chargement des éléments de données, le nombre d’éléments à charger et les éléments à conserver en mémoire est à votre application. Quelques considérations générales à prendre en compte :

  • Effectuez des requêtes asynchrones pour les données ; ne bloquez pas le thread d’interface utilisateur.
  • Trouvez le point idéal dans la taille des lots où vous obtenez des éléments. Préférez chunky à bavardage. Pas si petit que vous fassiez trop de petites demandes ; pas si volumineux qu'ils mettent trop de temps à récupérer.
  • Tenez compte du nombre de demandes que vous souhaitez avoir en attente en même temps. L’exécution d’un à la fois est plus facile, mais elle peut être trop lente si le temps de réponse est long.
  • Pouvez-vous annuler les demandes de données ?
  • Si vous utilisez un service hébergé, existe-t-il un coût par transaction ?
  • Quel type de notifications sont fournies par le service lorsque les résultats d’une requête changent ? Savez-vous si un élément est inséré à l’index 33 ? Si votre service prend en charge des requêtes basées sur une clé avec un offset, cela peut être préférable plutôt que d'utiliser uniquement un index.
  • À quel point souhaitez-vous être stratégique dans la pré-récupération des éléments ? Allez-vous essayer de suivre la direction et la vitesse de défilement pour prédire quels éléments sont nécessaires ?
  • À quel point souhaitez-vous agir agressivement pour purger le cache ? Il s’agit d’un compromis entre la mémoire et l’expérience.
  • Last updated on