Dela via


Skapa stora och komplexa arbetsyteappar

De flesta artiklar i det här avsnittet av dokumentet handlar om körtidsprestationer för appar, vilket människor som använder dem har erfarenhet av. Den här artikeln handlar om apprestanda vilket människor som använder dem har erfarenhet av.

När appar blir stora och mer komplexa måste Power Apps Studio läsa in och hantera ett stort antal kontroller, formler och datakällor med beroenden som växer exponentialt. Det kan ta längre tid att ladda Power Apps Studio och funktioner som IntelliSense och färgkodning kan bli eftersläpande. Använd rekommendationerna nedan för att arbeta bättre med stora och komplexa appar i Power Apps Studio. De kan också hjälpa till att förbättra apparnas körtidsprestanda.

Exemplen i denna artikel använder exempellösningen beredskapsplan för sjukhus.

Använd App.Formulas i stället för App.OnStart

Dricks

Du kan använda Med funktion och arbetsytekomponentens anpassade utdataegenskaper som ett alternativ till namngivna formler.

Det bästa sättet att minska inläsningstiden för både Power Apps Studio och din app är att byta ut variabel- och samlingsinitiering i App.OnStart med namngivna formler i App.Formulas.

Vi ska titta på följande exempel som använder App.OnStart.

// Get the color of text on a dark background.
Set(varColorOnDark,RGBA(0, 0, 0, 1));

// Get the color of the menu icons.
Set(varColorMenuIcon,"#0070a9");

// Get the styles for a form.
Set(varFormStyle,
    {
        DataCard: { Height: 50 },
        Title: { Height: 50, Size: 21, Color: varColorOnDark },
        Control: { Height: 50, Size: 18 },
        Label: { Size: 18, Color: varColorOnDark }
    }
);

ClearCollect(
    FacilitiesList,
    ForAll(
        Facilities,
        { Name: 'Facility Name', Id: Facility }
    )
);
If(
    Not IsBlank(Param("FacilityID")),
    Set(ParamFacility,
        LookUp(
            FacilitiesList,
            Id = GUID(Param("FacilityID"))
        ).Name
    );
);

Eftersom de är en sekvens av uttalanden måste din app utvärdera dessa Ange och Samla in anrop i ordning innan den kan visa den första skärmen vilket gör att appen blir mycket mer långsam. Och på grund av att hela App.OnStart ska ses som en hel, orderbevarad och felaggregerad innan slutresultatet returneras är formeln komplex för Power Apps Studio att analysera.

Det finns ett bättre sätt. Använd App.Formulas i stället för och definiera dessa variabler och samlingar som namngivna formeln, som i följande exempel.

// Get the color of text on a dark background.
varColorOnDark = RGBA(0, 0, 0, 1);

// Get the color of the menu icons.
varColorMenuIcon = "#0070a9";

// Get the styles for a form.
varFormStyle = 
    {
        DataCard: { Height: 50 },
        Title: { Height: 50, Size: 21, Color: varColorOnDark },
        Control: { Height: 50, Size: 18 },
        Label: { Size: 18, Color: varColorOnDark }
    };

FacilitiesList =
    ForAll(
        Facilities,
        { Name: 'Facility Name', Id: Facility }
    );

ParamFacility = 
    If( Not IsBlank(Param("FacilityID")),
        LookUp(
            FacilitiesList,
            Id = GUID(Param("FacilityID"))
        ).Name,
        Blank()
    );

Den här förändringen kan se liten ut, men den kan få stora effekter. Eftersom varje namngiven formel är oberoende av de andra kan Power Apps Studio analysera dem självständigt och effektivt dela en stor App.OnStarti mindre delar. Vi har sett inläsningstiden för Power Apps Studio minska med upp till 80 % enbart med den här förändringen.

Appen läses också in snabbare eftersom den inte behöver utvärdera de här formeln förrän resultatet är i behov av det. Den första skärmen i appen visas direkt.

Namngivna formeln kan inte användas i alla situationer eftersom du inte kan ändra dem eller använda dem med Ange. Vissa situationer kräver att en tillståndsvariabel används som kan ändras. Ange är inställt på dessa situationer och du bör fortsätta använda det. Men oftast använder du globala variabler i OnStart för att konfigurera statiska värden som inte ändras. I så fall är en namngiven formel det bättre valet.

Eftersom den namngivna formeln är oföränderlig är prefixet var (kort för "variabel") eftersom en namnkonvention inte längre är lämpligt. Vi ändrade inte namnen i det här exemplet eftersom det skulle kräva ändringar i resten av appen för att matcha.

Det är frestande att placera en namngiven formel i App.OnStart, men gör inte det.. De hör inte hemma där. Som en funktionsegenskap , utvärderar App.OnStart varje uttryck i ordning och skapar globala variabler och pratar med databaser endast när appen är laddad. Namngivna formler är de som definierar hur någonting beräknas när det behövs och alltid är sant. Det är denna formel som gör att de kan vara oberoende och som gör att appen kan avsluta inläsningen innan de utvärderas.

Dela upp långa formeln

App.OnStart är ett av de sämsta sätten att använda långa formler och definitivt var du ska börja men det är inte det enda fallet.

Våra studier har visat att nästan alla appar med lång laddningstid för Power Apps Studio har minst en formel som är mer än 256 000 tecken. Vissa appar med de längsta laddningstiderna har formeln som är mer än 1 miljoner tecken. Formler som länge har lagt en hög belastning på Power Apps Studio.

För att göra saken värre, kopiera och klistra av en kontroll med en lång formel duplicerar formeln i kontrollens egenskaper utan att den realiseras. Power Apps modelleras efter Excel, där flera kopior av en formel är vanliga. I Excel är emellertid formeln begränsad till ett uttryck och är maximerade till 8 000 tecken. Power Apps-formeln kan växa mycket längre med introduktionen av imperativ logik och den inledande operatorn (; eller ;; beroende på språk).

Den allmänna lösningen är att dela upp långa formeln i mindre delar och återanvända delar i tidigare avsnitt när vi ändrade uttryck för Ange/Samla in i App.OnStart till namngivna formler App.Formulas ovan. I andra programmeringsspråk kallas dessa återanvändbara delar ofta för underrutiner eller användardefinierade funktioner. Du kan tänka på namngivna formler som en enkel form av användardefinierad funktion utan parametrar eller bieffekter.

Använd namngivna formeln överallt

I det tidigare exemplet använde vi namngivna formeln som ersättning för App.OnStart. Men du kan använda dem för att ersätta en beräkning var som helst i en app.

Till exempel inkluderar en av skärmarna i exempellösningen beredskapsplan för sjukhus denna logik i Screen.OnVisible:

ClearCollect(
    MySplashSelectionsCollection,
    {
        MySystemCol: First(
            Filter(
                Regions,
                Region = MyParamRegion
            )
        ).System.'System Name',
        MyRegionCol: First(
            Filter(
                Regions,
                Region = MyParamRegion
            )
        ).'Region Name',
        MyFacilityCol: ParamFacility,
          MyFacilityColID:  LookUp(
            FacilitiesList,
            Id = GUID(Param("FacilityID"))
        ).Id
    }
); 

Formeln kan delas upp i en uppsättning med namngivna formeln. Det gör också formeln lättare att läsa.

MyRegion = LookUp(
                    Regions,
                    Region = MyParamRegion
           );

MyFacility = LookUp(
                    FacilitiesList,
                    Id = GUID(Param("FacilityID")
            );

MySplashSelectionsCollection = 
    {
        MySystemCol: MyRegion.System.'System Name',
        MyRegionCol: MyRegion.'Region Name',
        MyFacilityCol: ParamFacility,
        MyFacilityColID:  MyFacility.Id
    };

Vi extraherade ParamFacility som en namngiven formel tidigare när vi flyttade de flesta av Ange-anrop från App.OnStart till namngivna formeln i App.Formulas.

Namngivna formeln utvärderas endast när värdena behövs. Om den ursprungliga avsikten att använda Screen.OnVisible var att skjuta upp arbetet tills skärmen visades, då kommer arbetet fortfarande att skjutas upp som globala namngivna formler i App.Formulas.

Använd funktionen With

Du kan också dela upp logik med funktionen With i en formel. Skapa en post i den första parametern med de värden som du vill använda som fält, och sedan använda dessa fält i den andra parametern för att beräkna returvärdet från With. Exemplet ovan kan till exempel bara skrivas med en namngiven formel:

MySplashSelectionsCollection = 
    With( { MyRegion: LookUp(
                            Regions,
                            Region = MyParamRegion
                      ),
            MyFacility: LookUp(
                            FacilitiesList,
                            Id = GUID(Param("FacilityID")
                      ) 
           },
           {
                MySystemCol: MyRegion.System.'System Name',
                MyRegionCol: MyRegion.'Region Name',
                MyFacilityCol: ParamFacility,
                MyFacilityColID:  MyFacility.Id
           }
    )

En av baksidorna med att använda With på detta sätt kan MyFacility inte använda MyRegion eftersom de är definierade i samma funktion för With, ett problem som inte finns med namngivna formeln. En lösning är att kapsla funktioner With och använda nyckelordet As för att namnge posten för varje för att ge enkel åtkomst till alla With-variabler.

Använd arbetsytekomponenter

Arbetsytekomponenter används oftast för att skapa en UI-kontroll som kan placeras på arbetsytorna som en kontroll. Du kan också använda dem utan att placera dem i användargränssnittet för att utföra beräkningar med anpassade utdataegenskaper som ett alternativ till namngivna formler. Arbetsytekomponenter är enkla att dela i appar med komponentbibliotek och stöds helt, till skillnad från namngivna formler. Däremot är det inte bara de som konfigurerar och använder dem utan namngivna formeln.

Att dela upp logik:

  1. I Power Apps Studio, växla till fliken Komponenter i trädvyn.
  2. Skapa en ny komponent.
  3. I rutan Egenskaper, aktivera Åtkomst till appomfattning.
  4. Lägg till en anpassad egenskap
  5. Ange egenskapstyp till Utdata och Datatyp efter behov.
  6. Välj Skapa.
  7. Välj den nya egenskapen i egenskapsväljaren bredvid formelfältet högst upp på skärmen.
  8. Skriv formeln för logiken som ska delas och återanvändas.

För att använda logiken:

  1. Växla fliken Skärmar i trädvyn:
  2. I rutan Infoga expanderar du Anpassad och infogar komponenten.
  3. Om du vill beräkna ett värde med egenskapen använder du ComponentName.PropertyName.

Använd Välj med en dold kontroll för tvingande logik

Tvingande logik används för att ändra tillstånd med Set och Collect, meddela användaren med Notify, navigera till en annan skärm eller app med Navigate och Launch och skriva värden till en databas med Patch, SubmitForm eller RemoveIf.

Namngivna formler och arbetsytekomponentens anpassade utdataegenskaper tvingande logik. Ett vanligt sätt att dela upp imperativ logik är att använda egenskapen OnSelect för en dold kontroll.

  1. Lägg till en Knapp-kontroll på skärmen.
  2. Ange egenskapen OnSelect till den tvingande logik som du vill köra.
  3. Ange egenskapen Visible som falskt eftersom användaren inte behöver se eller interagera med den.
  4. Anropa Select( Button ) när du vill köra den tvingande logiken.

En av skärmarna i vårt exempel har till exempel följande egenskapen OnSelect på en Knapp-kontroll. (Det här enkla exemplet är endast för illustrationssyften. Vanligtvis använder du bara den här metoden för längre formeln.)

btnAction_17.OnSelect = 
    Trace("Feedback Screen: Submit Button",TraceSeverity.Information);
    If(
        // Proceed if all forms are validated.
        And(
            FormFeedback.Valid
        ),
    
        // Set the updates to static variables.
        Set(updatesFeedback,Patch(Defaults('App Feedbacks'), FormFeedback.Updates));
        // Submit the first form. Subsequent actions can be found in the OnSuccess.
        SubmitForm(FormFeedback);
        ,
    
        Notify("Please complete all fields before proceeding",
               NotificationType.Warning,2000)
    );

Om du vill dela upp logiken i delar kan vi lägga delar på separata Knapp-kontroller och välja dem från ursprungsversionen:

btnTrace.OnSelect = 
    Trace("Feedback Screen: Submit Button",TraceSeverity.Information);

btnSubmit.OnSelect = 
    If(
        // Proceed if all forms are validated.
        And(
            FormFeedback.Valid
        ),
    
        // Set the updates to static variables.
        Set(updatesFeedback,Patch(Defaults('App Feedbacks'), FormFeedback.Updates));
        // Submit the first form. Subsequent actions can be found in OnSuccess.
        SubmitForm(FormFeedback);
        ,
    
        Notify("Please complete all fields before proceeding",
               NotificationType.Warning,2000)
    );

btnAction_17.OnSelect = 
    Select( btnTrace );
    Select( btnSubmit );

Den här tekniken fungerar bara på samma skärm. Andra tekniker som är lite mer komplicerade fungerar över skärmarna, som att använda kontrollen Växla där OnCheck anges till den logik du vill köra och Standard anges till en global variabel och sedan växla den globala med Set( global, true ); Set( global, false ) när logiken ska köras.

I det här exemplet hade viss logikdelning redan gjorts. I kommentaren anges att "Efterföljande åtgärder finns i OnSuccess". Den här händelsen kör tvingande logik efter att posten har skickats, en lösning som är specifik för funktionen SubmitForm.

Dela appen

Vissa appar växer till tusentals kontroller och hundratals datakällor, som gör att Power Apps Studio går långsammare. Precis som med långa formler kan stora appar delas upp i mindre avsnitt som fungerar tillsammans för att skapa en användarupplevelse.

Separata arbetsyteappar

En metod är att implementera avsnitt i separata appar och använda funktionen Launch för att navigera mellan de separata apparna och skicka kontexten som behövs.

Den här metoden användes i exempellösningen Beredskapsplan för sjukhus. Separata appar hanterar de viktigaste områdena i appen. Apparna delar en gemensam växelkomponent via ett komponentbibliotek som varje app visar på startskärmen:

Skärmbild på exempellösningen Beredskapsplan för sjukhus körs på en telefon med växelkomponenten på arbetsytan.

När användaren väljer ett område använder komponenten metadata om de tillgängliga apparna och vilken app som är värd för komponenten. Om den skärm du vill använda finns i den här appen (ThisItem.Screen är inte tom), anropet Navigera görs. Men om den önskade skärmen finns i en annan app (ThisItem.PowerAppID är inte tomt) används funktionen starta med app-ID för målet och FacilityID-sammanhanget:

If(
    IsBlank(ThisItem.Screen),
    If(IsBlank(ThisItem.PowerAppID), 
        Launch(ThisItem.URL),           
        Launch("/providers/Microsoft.PowerApps/apps/" & ThisItem.PowerAppID, 
               "FacilityID", Home_Facility_DD.Selected.Id)
    ),
    Navigate(
        ThisItem.Screen,
        Fade
    )
);

Tillstånd i den ursprungliga appen går förlorade när en annan app startas. Spara alla tillstånd innan du anropar funktionen Launch. Skriv det till en databas, anropa SaveData eller skicka status till målprogrammet med parametrar som läses med funktionen Param.

Modellbaserade appar med anpassade sidor

Avsnitt kan också implementeras som anpassade sidor. Anpassade sidor fungerar som en miniarbetsyteapp med en modellbaserad appbehållare för navigering.

Anteckning

Kan du berätta om dina inställningar för dokumentationsspråk? Svara i en kort undersökning. (observera att undersökningen är på engelska)

Undersökningen tar ungefär sju minuter. Inga personuppgifter samlas in (sekretesspolicy).