Delen via

ListView- en GridView-gegevensvirtualisatie

Opmerking
Zie de sessie //build/ Aanzienlijk verbeteren van de prestaties wanneer gebruikers werken met grote hoeveelheden gegevens in GridView en ListView voor meer informatie.

Verbeter de prestaties en opstarttijd van ListView en GridView via gegevensvirtualisatie. Zie voor virtualisatie van de gebruikersinterface, elementreductie en progressief bijwerken van items ListView- en GridView-prestaties optimaliseren voor WinUI.

Er is een methode voor gegevensvirtualisatie nodig voor een gegevensset die zo groot is dat deze niet of niet allemaal tegelijk in het geheugen mag worden opgeslagen. U laadt een eerste gedeelte in het geheugen (van lokale schijf, netwerk of cloud) en past UI-virtualisatie toe op deze gedeeltelijke gegevensset. U kunt gegevens later incrementeel laden of van willekeurige punten in de hoofdgegevensset (willekeurige toegang), op aanvraag. Of gegevensvirtualisatie geschikt is voor u, is afhankelijk van veel factoren.

  • De grootte van uw gegevensset
  • De grootte van elk item
  • De bron van de gegevensset (lokale schijf, netwerk of cloud)
  • Het totale geheugenverbruik van uw WinUI-app

Opmerking Houd er rekening mee dat er een functie standaard is ingeschakeld voor ListView en GridView die tijdelijke aanduidingen voor visuals weergeeft terwijl de gebruiker snel aan het scrollen is. Wanneer gegevens worden geladen, worden deze tijdelijke aanduidingen vervangen door uw itemsjabloon. U kunt de functie uitschakelen door ListViewBase.ShowsScrollingPlaceholders in te stellen op false, maar als u dit doet, raden we u aan om het kenmerk x:Phase te gebruiken om de elementen in uw itemsjabloon geleidelijk weer te geven. Zie Items in ListView en GridView geleidelijk bijwerken.

Hier vindt u meer informatie over de incrementele en random access-technieken voor gegevensvirtualisatie.

Incrementele gegevensvirtualisatie

Incrementele gegevensvirtualisatie laadt gegevens opeenvolgend. Een ListView die gebruikmaakt van incrementele gegevensvirtualisatie kan worden gebruikt om een verzameling van een miljoen items weer te geven, maar in eerste instantie worden slechts 50 items geladen. Terwijl de gebruiker in- of uitzoomt of verschuift, worden de volgende 50 geladen. Wanneer items worden geladen, neemt de duim van de schuifbalk in grootte af. Voor dit type gegevensvirtualisatie schrijft u een gegevensbronklasse die deze interfaces implementeert.

Een gegevensbron zoals deze is een in-memory lijst die voortdurend kan worden uitgebreid. Het items-besturingselement vraagt om items met behulp van de standaard IList indexeerfunctie en de eigenschap voor tellen. Het aantal moet het aantal items lokaal vertegenwoordigen, niet de werkelijke grootte van de gegevensset.

Wanneer het itembesturingselement dicht bij het einde van de bestaande gegevens komt, wordt ISupportIncrementalLoading.HasMoreItems aanroepen. Als u waar retourneert, roept het ISupportIncrementalLoading.LoadMoreItemsAsync aan, waarbij een aanbevolen aantal items wordt doorgegeven om te laden. Afhankelijk van waar u gegevens laadt (lokale schijf, netwerk of cloud), kunt u ervoor kiezen om een ander aantal items te laden dan aanbevolen. Als uw service bijvoorbeeld batches van 50 items ondersteunt, maar het itembeheer slechts 10 vraagt, kunt u 50 laden. Laad de gegevens van uw back-end, voeg deze toe aan uw lijst en dien een wijzigingsmelding in via INotifyCollectionChanged of IObservableVector<T> , zodat het itembesturingselement weet wat de nieuwe items zijn. Retourneert ook een telling van de items die u daadwerkelijk hebt geladen. Als u minder items laadt dan aanbevolen, of als de itemscontrole in de tussentijd is gepand of verder geschoven, wordt uw gegevensbron opnieuw aangeroepen voor meer items en wordt de cyclus voortgezet. ISupportIncrementalLoading blijft beschikbaar in Windows App SDK, zodat u hetzelfde incrementele laadpatroon in een WinUI-app kunt gebruiken.

Gegevensvirtualisatie voor willekeurige toegang

Met gegevensvirtualisatie voor willekeurige toegang kunt u laden vanaf een willekeurig punt in de gegevensset. Een ListView die gebruikmaakt van gegevensvirtualisatie met willekeurige toegang om een verzameling van een miljoen items weer te geven, kan items 100.000-100.050 laden. Als de gebruiker vervolgens naar het begin van de lijst wordt verplaatst, laadt het besturingselement items 1-50. De duim van de schuifbalk geeft altijd aan dat de ListView een miljoen items bevat. De positie van de duim van de schuifbalk is relatief ten opzichte van waar de zichtbare items zich in de volledige gegevensset van de verzameling bevinden. Dit type gegevensvirtualisatie kan de geheugenvereisten en laadtijden voor de verzameling aanzienlijk verminderen. Als u dit wilt inschakelen, moet u een gegevensbronklasse schrijven waarmee gegevens op aanvraag worden opgehaald, een lokale cache wordt beheerd en deze interfaces worden geïmplementeerd.

IItemsRangeInfo biedt informatie over welke items het besturingselement actief gebruikt. Het items-besturingselement roept deze methode aan wanneer de weergave wijzigt en omvat deze twee sets bereiken.

  • De set van items die zich in het weergavegebied bevinden.
  • Een set niet-gevirtualiseerde items die door het besturingselement worden gebruikt die mogelijk niet in de viewport staan.
    • Een buffer van items rond de viewport die door het itembeheer wordt bewaard, zodat het pannen met aanraakscherm soepel verloopt.
    • Het item met prioriteit.
    • Het eerste item.

Door IItemsRangeInfo te implementeren, weet uw gegevensbron welke items moeten worden opgehaald en in de cache moeten worden opgeslagen en wanneer gegevens uit de cache moeten worden verwijderd die niet meer nodig zijn. IItemsRangeInfo maakt gebruik van ItemIndexRange-objecten om een set items te beschrijven op basis van hun index in de verzameling. Hiermee voorkomt u itempointers, die mogelijk niet juist of stabiel zijn. IItemsRangeInfo is ontworpen voor gebruik door slechts één exemplaar van een itembesturingselement, omdat het afhankelijk is van statusinformatie voor dat itembesturingselement. Als multiple itembesturingselementen toegang tot dezelfde data nodig hebben, hebt u voor elk een afzonderlijk exemplaar van de gegevensbron nodig. Ze kunnen een gemeenschappelijke cache delen, maar de logica voor het opschonen van de cache is ingewikkelder. IItemsRangeInfo blijft beschikbaar in Windows App SDK, dus dezelfde technieken voor het opslaan in cachen van willekeurige toegang zijn van toepassing op WinUI-besturingselementen.

Hier volgt de basisstrategie voor uw gegevensvirtualisatiebron voor willekeurige toegang.

  • Wanneer u om een item wordt gevraagd
    • Als het in het geheugen beschikbaar is, geeft u het terug.
    • Als u deze niet hebt, retourneer dan ofwel null of een tijdelijke aanduiding.
    • Gebruik de aanvraag voor een item (of de bereikgegevens van IItemsRangeInfo) om te weten welke items er nodig zijn en om gegevens op te halen voor items van uw back-end asynchroon. Nadat u de gegevens hebt opgehaald, dient u een wijzigingsmelding in via INotifyCollectionChanged of IObservableVector<T> , zodat het itembesturingselement over het nieuwe item weet.
  • (Optioneel) als de viewport van het itembesturingselement wordt gewijzigd, identificeert u welke items er nodig zijn vanuit uw gegevensbron via uw implementatie van IItemsRangeInfo.

Bovendien is de strategie voor het laden van gegevensitems, het aantal te laden items en welke items in het geheugen moeten worden bewaard, aan uw toepassing toe. Enkele algemene overwegingen waarmee u rekening moet houden:

  • Asynchrone aanvragen voor gegevens maken; de UI-thread niet blokkeren.
  • Zoek het optimale punt voor de batchgrootte waarin u items ophaalt. Geef de voorkeur aan chunky om te chatten. Niet zo klein dat u te veel kleine aanvragen doet; niet zo groot dat ze te lang duren om op te halen.
  • Houd rekening met het aantal aanvragen dat u tegelijk in behandeling wilt hebben. Het uitvoeren van een voor een is eenvoudiger, maar het kan te traag zijn als de doorlooptijd hoog is.
  • Kunt u aanvragen voor gegevens annuleren?
  • Als u een gehoste service gebruikt, zijn er kosten per transactie?
  • Welk soort meldingen worden door de service verstrekt wanneer de resultaten van een query worden gewijzigd? Weet u of een item is ingevoegd bij index 33? Als uw service query's ondersteunt op basis van een sleutel-plus-offset, is dat mogelijk beter dan het gebruik van alleen een index.
  • Hoe slim wilt u zijn in het voorspellen van items? Wilt u de richting en snelheid van schuiven bijhouden om te voorspellen welke items er nodig zijn?
  • Hoe agressief wilt u de cache leegmaken? Dit is een compromis tussen geheugen en ervaring.
  • Last updated on