Dela via

Datavirtualisering för ListView och GridView

Anmärkning
Mer information finns i sessionen //build/ Dramatiskt öka prestanda när användare interagerar med stora mängder data i GridView och ListView.

Förbättra Prestanda och starttid för ListView och GridView via datavirtualisering. Information om virtualisering av användargränssnitt, minskning av element och progressiv uppdatering av objekt finns i Optimera ListView- och GridView-prestanda för WinUI.

En metod för datavirtualisering krävs för en datauppsättning som är så stor att den inte kan eller inte bör lagras i minnet samtidigt. Du läser in en första del i minnet (från lokal disk, nätverk eller moln) och tillämpar virtualisering av användargränssnittet på den här partiella datauppsättningen. Du kan senare läsa in data stegvis eller från godtyckliga punkter i huvuddatauppsättningen (slumpmässig åtkomst) på begäran. Om datavirtualisering är lämplig för dig beror på många faktorer.

  • Storleken på datauppsättningen
  • Storleken på varje objekt
  • Datamängdens källa (lokal disk, nätverk eller moln)
  • Den totala minnesförbrukningen för din WinUI-app

Observera Tänk på att en funktion är aktiverad som standard för ListView och GridView som visar tillfälliga visuella platshållarobjekt medan användaren panorerar eller rullar snabbt. När data läses in ersätts dessa visuella platshållarobjekt med objektmallen. Du kan inaktivera funktionen genom att ange ListViewBase.ShowsScrollingPlaceholders till false, men om du gör det rekommenderar vi att du använder attributet x:Phase för att progressivt återge elementen i objektmallen. Se Uppdatera ListView- och GridView-objekt progressivt.

Här följer mer information om inkrementella datavirtualiseringstekniker och datavirtualisering med slumpmässig åtkomst.

Inkrementell datavirtualisering

Inkrementell datavirtualisering läser in data sekventiellt. En ListView som använder inkrementell datavirtualisering kan användas för att visa en samling med en miljon objekt, men endast 50 objekt läses in från början. När användaren panorerar eller rullar, laddas de nästa 50 in. När objekt läses in minskar rullningslistens tumme i storlek. För den här typen av datavirtualisering skriver du en datakällaklass som implementerar dessa gränssnitt.

En datakälla som denna är en minnesintern lista som kan utökas kontinuerligt. Objektkontrollen frågar efter objekt med hjälp av standardegenskaperna för IList-indexerare och antal. Antalet ska representera antalet objekt lokalt, inte datamängdens verkliga storlek.

När objektkontrollen kommer nära slutet av befintliga data anropas ISupportIncrementalLoading.HasMoreItems. Om du returnerar true anropas ISupportIncrementalLoading.LoadMoreItemsAsync och skickar ett rekommenderat antal objekt som ska läsas in. Beroende på var du läser in data från (lokal disk, nätverk eller moln) kan du välja att läsa in ett annat antal objekt än vad som rekommenderas. Om din tjänst till exempel stöder batchar med 50 objekt, men objektkontrollen bara begär 10, kan du läsa in 50. Läs in data från serverdelen, lägg till dem i listan och skapa ett ändringsmeddelande via INotifyCollectionChanged eller IObservableVector<T> så att objektkontrollen känner till de nya objekten. Returnera också antalet objekt som du faktiskt laddade in. Om du läser in färre objekt än vad som rekommenderas, eller om objektkontrollen har panorerats eller rullats ännu längre under tiden, anropas datakällan igen för fler objekt och cykeln fortsätter. ISupportIncrementalLoading är fortfarande tillgängligt i Windows App SDK, så du kan använda samma inkrementella inläsningsmönster i en WinUI-app.

Datavirtualisering med slumpmässig åtkomst

Med datavirtualisering med slumpmässig åtkomst kan du läsa in från en godtycklig punkt i datauppsättningen. En ListView som använder slumpmässig datavirtualisering för att visa en samling med en miljon objekt kan läsa in objekten 100 000–100 050. Om användaren sedan flyttas till början av listan läser kontrollen in objekten 1–50. Rullningslistens tumme indikerar hela tiden att ListView innehåller en miljon objekt. Positionen för rullningslistens tumme är relativ till var de synliga objekten finns i samlingens hela datauppsättning. Den här typen av datavirtualisering kan avsevärt minska minneskraven och inläsningstiderna för samlingen. För att aktivera den måste du skriva en datakällaklass som hämtar data på begäran, hanterar en lokal cache och implementerar dessa gränssnitt.

IItemsRangeInfo innehåller information om vilka objekt som kontrollen aktivt använder. Objektkontrollen anropar den här metoden när dess vy ändras och innehåller dessa två uppsättningar intervall.

  • Den uppsättning objekt som finns i visningsporten.
  • En uppsättning icke-virtualiserade objekt som kontrollen använder som kanske inte finns i visningsporten.
    • En buffert med objekt runt visningsområdet som objektkontrollen behåller så att pekpanorering blir smidig.
    • Det fokuserade objektet.
    • Det första objektet.

Genom att implementera IItemsRangeInfo vet datakällan vilka objekt som behöver hämtas och cachelagras och när data ska rensas från cacheminnet som inte längre behövs. IItemsRangeInfo använder ItemIndexRange-objekt för att beskriva en uppsättning objekt baserat på deras index i samlingen. Detta undviker objektpekare, som kanske inte är korrekta eller stabila. IItemsRangeInfo är utformat för att endast användas av en enda instans av en objektkontroll eftersom den förlitar sig på tillståndsinformation för objektkontrollen. Om kontroller för flera objekt behöver åtkomst till samma data behöver du en separat instans av datakällan för var och en. De kan dela en gemensam cache, men logiken för att rensa från cachen blir mer komplicerad. IItemsRangeInfo är fortfarande tillgängligt i Windows App SDK, så samma cachelagringstekniker för slumpmässig åtkomst gäller för WinUI-kontroller.

Här är den grundläggande strategin för datavirtualiseringsdatakällan för slumpmässig åtkomst.

  • När du tillfrågas om ett objekt
    • Om det är tillgängligt i minnet, returnera det.
    • Om du inte har det returnerar du antingen null eller ett platshållarobjekt.
    • Använd begäran om ett objekt (eller intervallinformationen från IItemsRangeInfo) för att veta vilka objekt som behövs och för att hämta data för objekt från serverdelen asynkront. När du har hämtat data skapar du ett ändringsmeddelande via INotifyCollectionChanged eller IObservableVector<T> så att objektkontrollen känner till det nya objektet.
  • (Valfritt) när objektkontrollens visningsport ändras identifierar du vilka objekt som behövs från datakällan via implementeringen av IItemsRangeInfo.

Utöver detta är strategin för när dataobjekt ska läsas in, hur många som ska läsas in och vilka objekt som ska sparas i minnet upp till ditt program. Några allmänna överväganden att tänka på:

  • Gör asynkrona begäranden för data. blockera inte användargränssnittstråden.
  • Hitta den söta punkten i storleken på de batchar som du hämtar objekt i. Föredra chunky framför chatty. Inte så liten att du gör för många små begäranden. inte så stor att de tar för lång tid att hämta.
  • Tänk på hur många begäranden du vill ha väntande samtidigt. Det är enklare att utföra en i taget, men det kan vara för långsamt om handläggningstiden är hög.
  • Kan du avbryta begäranden om data?
  • Finns det en kostnad per transaktion om du använder en värdbaserad tjänst?
  • Vilken typ av meddelanden tillhandahålls av tjänsten när resultatet av en fråga ändras? Vet du om ett objekt infogas vid index 33? Om din tjänst stöder frågor baserade på en nyckel och förskjutning kan det vara bättre än att bara använda ett index.
  • Hur smart vill du vara när det gäller förhämtning av element? Ska du försöka spåra riktningen och hastigheten för rullning för att förutsäga vilka objekt som behövs?
  • Hur aggressiv vill du vara när du rensar cacheminnet? Det här är en kompromiss mellan minne och upplevelse.
  • Last updated on