Tips och metodtips för att förbättra prestanda för arbetsyteappar

I de tidigare artiklarna lärde du dig mer om körningsfaserna och datasamtalsflödet, vanliga källor till långsam prestanda och vanliga prestandafrågor/upplösningar i arbetsyteappar. Du kan också ha nytta av att följa tipsen och metodtipsen i den här artikeln för att öka prestandan för appar som du skapar.

Begränsa dataanslutningar

Anslut inte till mer än 30 datakällor från samma app. Appar uppmana nya användare att logga in på varje anslutning, så att varje ytterligare anslutningsprogram ökar mängden tid som appen behöver för att starta. Eftersom en app körs, kräver varje anslutningsapp CPU-resurser, minne och nätverksbandbredd när appen begär data från den källan.

Du kan snabbt mäta din apps prestanda genom att aktivera utvecklarverktyg i Microsoft Edge eller Google Chrome vid körning av appen. Din app tar antagligen längre tid än 15 sekunder att returnera data om det ofta begär data från mer än 30 datakällor, till exempel Microsoft Dataverse för appar, Azure SQL, SharePoint och Excel på OneDrive.

Begränsa antalet kontroller

Lägg inte till fler än 500 kontroller med samma app. Power Apps skapar en HTML-dokument objektmodell för rendering av varje kontroll. Ju fler kontroller som du lägger till, desto längre generationstid behöver Power Apps.

Du kan i vissa fall kan uppnå samma resultat och få appen att starta snabbare om du använder ett galleri istället för enskilda kontroller. Dessutom kan du minska antalet kontrolltyper på samma skärm. Vissa kontroller (som PDF-visningsprogram, datatabell och kombinationsruta) drar in stora körningsskript och tar längre tid att rendera.

Optimera OnStart-egenskapen

Använd funktionen ClearCollect för att cachelagra data lokalt om det inte ändras under användarens session. Du kan även använda funktionen Samtidig för att läsa datakällor samtidigt; detta kan minska den tid en app behöver för att ladda data i hälften. Mer information: Samtidig funktion i Power Apps

Utan funktionen samtidiga läser den här formeln in var och en av fyra tabeller en i taget:

ClearCollect( Product, '[SalesLT].[Product]' );
ClearCollect( Customer, '[SalesLT].[Customer]' );
ClearCollect( SalesOrderDetail, '[SalesLT].[SalesOrderDetail]' );
ClearCollect( SalesOrderHeader, '[SalesLT].[SalesOrderHeader]' )

Du kan bekräfta detta beteende i utvecklarverktygen för webbläsaren (se bilden nedan).

Du kan bädda in formeln i funktionen Samtidiga för att minska den totala tid som krävs för åtgärden:

Concurrent( 
    ClearCollect( Product, '[SalesLT].[Product]' ),
    ClearCollect( Customer, '[SalesLT].[Customer]' ),
    ClearCollect( SalesOrderDetail, '[SalesLT].[SalesOrderDetail]' ),
    ClearCollect( SalesOrderHeader, '[SalesLT].[SalesOrderHeader]' ))

Med den här förändringen hämtar appen tabellerna samtidigt, vilket du kan se i följande bild.

Cachedata för sökning

Använd funktionen Ange för att cachelagra data från söktabeller lokalt för att undvika upprepade datahämtningar från källan. Den här tekniken optimerar prestanda om data förmodligen inte kommer att ändras under en session. Som i följande exempel så hämtas data från källan en gång och refereras sedan till lokalt efter det, tills dess att användaren stänger appen.

Set(CustomerOrder, Lookup(Order, id = “123-45-6789”));
Set(CustomerName, CustomerOrder.Name);
Set(CustomerAddress, CustomerOrder.Address);
Set(CustomerEmail, CustomerOrder.Email);
Set(CustomerPhone, CustomerOrder.Phone);

Den här metoden är mer användbar för data som kontaktinformation, standardvärden eller användarinformation som inte ändras ofta. Så du kan generellt sätt använda den här tekniken med funktionerna Standardvärden och Användare.

Undvika kontrollberoende mellan skärmarna

För att förbättra prestanda läses skärmarna i en app in i minnet endast när de behövs. Den här optimeringen kan användas om till exempel skärm 1 läses in och en av dess formeln använder egenskapen för en kontroll från skärm 2. Nu måste skärm 2 vara inläst för att du ska kunna uppfylla beroendet innan skärm 1 kan visas. Anta att skärm 2 är beroende av skärm 3, som har ett annat beroende på skärm 4 och så vidare. Den här beroende kedjan kan orsaka att många skärmar läses in.

Därför undviker du formel beroenden mellan skärmar. I vissa fall kan du använda en global variabel eller samling för att dela information mellan skärmar.

Det finns ett undantag: I föregående exempel föreställer du dig att det enda sättet att visa skärm 1 är att navigera från skärm 2. Då har skärm 2 redan lästs in i minnet när skärm 1 ska läsas in. Det behövs inget extra arbete för att uppfylla beroendet för skärm 2 och därför påverkas inte prestandan.

Använd delegering

Om möjligt, använder du funktioner som delegerar databehandling till datakällan istället för att hämta data till den lokala enheten för bearbetning. Om en app måste bearbeta data lokalt, kräver åtgärden mycket mer processorkraft, minne och nätverksbandbredd, särskilt om datauppsättningen är stor.

Ett exempel på delegerbara funktioner kan vara en ID-kolumn som har definierats som Antal datatyp för SharePoint-listan. Formeln i följande exempel returnerar resultatet som förväntat. Den första formeln är emellertid delegerbar, medan den andra inte är det.

När vi antar att ID-kolumnen i SharePoint definieras med datatypen Antal ska värdet på höger sida vara numerisk variabel i stället för strängvariabel. Annars kan en sådan matchning leda till att formeln inte kan delegeras.

Användning icke-delegerbara funktioner och begränsning för icke-delegerade frågor kan påverka appens prestanda negativt. Mer information: Förstå delegering i en arbetsyteapp

Använd fördröjd inläsning

Aktivera den experimentella funktionen för fördröjd inläsning om din app har fler än 10 skärmar, inga regler och många kontroller som finns på flera skärmar och som är direkt kopplade till datakällan. Om du skapar den här typen av app och inte aktiverar den här funktionen så kan appens prestanda försämras eftersom kontrollerna i alla skärmar måste fyllas i även på skärmar som inte är öppna. Dessutom måste alla skärmar i appen uppdateras när datakällan ändras, till exempel när användaren lägger till en post.

Arbeta med stora datauppsättingar

Använd datakällor och formler som kan delegeras så att dina program fungerar bra medan användare kan komma åt den information de behöver och undvika att nå dataradsgränsen på 2000 för frågor som inte kan delegeras. För kolumner med dataposter som användarna kan söka i, filtrera eller sortera data på använder du index i kolumner enligt beskrivningen av datakällorna SQL Server or SharePoint.

Ompublicera appar regelbundet

Utvecklare uppmanas att publicera sina appar regelbundet. Eftersom Power Apps-plattformen kontinuerligt optimeras och distribueras återskapas appen inom de senaste plattformsoptimeringarna när du publicerar den på nytt.

Undvik att upprepa samma formel på flera platser

Om flera egenskaper kör samma formel (speciellt om den är komplex) bör du överväga att ange den en och sedan referera till resultatet av den första egenskapen i efterföljande fält. Ange till exempel inte egenskapen DisplayMode för kontrollerna A, B, C, D och E i samma komplexa formel. I stället kan du ange en egenskap DisplayMode för A till den komplexa formeln, ange B DisplayMode-egenskapen till resultatet för A DisplayMode-egenskapen och så vidare för C, D och E.

Aktivera DelayOutput för alla textinmatningskontroller

Om du har flera formler eller regler som refererar till värdet för en kontroll för Text input anger du värdet true för egenskapen DelayedOutput för den kontrollen. Egenskapen Text av den kontrollen kommer att uppdateras först efter att tangenttryckningar som angetts i snabb följd har stoppats. Formlerna eller reglerna körs inte så många gånger och programprestanda förbättras.

Undvik att använda Form.Updates i regler och formler

Om du refererar till ett användarinmatningsvärde i en regel eller en formel med hjälp av en Form.Updates variabel, itererar den över alla formulärets datakort och skapar en post varje gång. Om du vill göra appen mer effektiv refererar du till värdet direkt från datakortet eller kontrollvärdet.

Använda DelayItemLoading and Loading spinner för att förbättra prestandan i Galleriet

Beroende på konfigurationen kan det ta längre tid för Galleri att rendera de synliga raderna. Det finns några sätt att förbättra prestanda.

• Förenkla mallen. Du kan till exempel överväga att minska antalet kontroller, referenser till uppslag.
• Gallerier med komplexa mallar kan dra nytta av att ha DelayItemLoading anges till true och LoadingSpinner anges till LoadingSpinner.Controls. Ändringen förbättrar upplevelsen när återgivningstiden är längre. DelayItemLoading kommer också att skjuta upp rendering av mallar som gör att resten av skärmen kan renderas snabbare eftersom både skärm och galleri inte tävlar om resurser.

Nästa steg

Granska kodstandarder för att maximera apprestanda och hålla appar lättare att underhålla.

Se även

Förstå körningsfaser och datasamtalsflöde i arbetsyteappar
Vanliga prestandaproblem och lösningar för arbetsyteappar
Vanliga källor till långsamma prestanda för en arbetsyteapp
Vanliga problem och lösningar för Power Apps
Felsöker startproblem för Power Apps