Del via


Bygg store og komplekse lerretsapper

De fleste artiklene i denne delen av dokumentasjonen dekker kjøretidsytelsen til apper som brukerne har opplevd. Denne artikkelen dekker appytelsen som utviklerne opplever.

Etter hvert som apper blir større og mer komplekse, må Power Apps Studio laste inn og administrere et større antall kontroller, formler og datakilder, alt med gjensidige avhengigheter som vokser eksponentielt. Det kan ta lengre tid å laste inn Power Apps Studio, og du kan oppleve forsinkelse ved funksjoner som IntelliSense og fargekoding. Bruk anbefalingene nedenfor til å arbeide bedre med store og komplekse apper i Power Apps Studio. De kan også bidra til å forbedre appenes kjøretidsytelse.

Eksemplene i denne artikkelen bruker eksempelløsningen for sykehusberedskap.

Bruk App.Formulas i stedet for App.OnStart

Tips

Du kan bruke With-funksjonen og egendefinerte egenskaper for utdata for lerretskomponent som et alternativ til navngitte formler.

Du kan best redusere innlastingstiden for både Power Apps Studio og appen din ved å erstatte variabel- og innsamlingsinitialisering i App.OnStart med navngitte formler i App.Formulas.

La oss se på eksemplet nedenfor, der App.OnStart brukes.

// 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
    );
);

Siden de er en sekvens av setninger, må appen evaluere disse Set- og Collect-oppkallene i rekkefølge før den første skjermen kan vises, som gjør at det tar lengre tid å laste inn appen. Siden hele App.OnStart må betraktes som en helhet, rekkefølgen bevares og feil aggregeres før det endelige resultatet kan returneres, er formelen kompleks å analysere for Power Apps Studio.

Det finnes en bedre måte. Bruk App.Formulas i stedet, og definer disse variablene og samlingene som navngitte formler, slik som i eksemplet nedenfor.

// 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()
    );

Denne endringen kan virke liten, men den kan ha stor innvirkning. Siden hver navngitte formel er uavhengig av de andre, kan Power Apps Studio analysere dem uavhengig av hverandre og dele opp en stor App.OnStart i mindre deler. Vi har sett at innlastingstiden til Power Apps Studio har blitt redusert med hele 80 % bare med denne endringen.

Appen lastes også raskere fordi den ikke trenger å evaluere disse formlene før den trenger resultatet. Den første skjermen i appen vises umiddelbart.

Navngitte formler kan ikke brukes i alle situasjoner, fordi du kan ikke endre dem eller bruke dem med Set. I enkelte situasjoner må du bruke en tilstandsvariabel som kan endres. Set er perfekt i disse situasjonene, og du bør fortsette å bruke den. Men som oftest bruker du globale variabler i OnStart til å konfigurere statiske verdier som ikke endres. I slike tilfeller er en navngitt formel det beste valget.

Siden navngitte formler er uforanderlige, passer ikke lenger prefikset var (forkortelse for «variabel») som navnekonvensjon. Vi endret ikke navnene i dette eksemplet, fordi vi måtte ha foretatt endringer i resten av appen for å oppnå samsvar.

Det er fristende å legge en navngitt formel i App.OnStart, men ikke gjør dette. De hører ikke til der. Som en On-funksjonalitetsegenskap evaluerer App.OnStart hver av setningene i appen i rekkefølge, oppretter globale variabler og kommuniserer med databaser bare én gang når appen lastes inn. Navngitte formler er formler som definerer hvordan noe skal beregnes når det er nødvendig, og er alltid sanne. Det er denne formelvirkemåten som gjør at de kan være uavhengige, og gjør at appen kan fullføre lastingen før de evalueres.

Del opp lange formler

App.OnStart er en av de med lengst formler og der du bør starte, men det er ikke det eneste tilfellet.

Studiene våre har vist at nesten alle apper med lang innlastingstid for Power Apps Studio har minst én formel med flere enn 256 000 tegn. Noen apper med den lengste innlastingstiden har formler med flere enn 1 million tegn. Formler som er så lange, legger en betydelig belastning på Power Apps Studio.

Forholdene blir verre hvis du kopierer og limer inn en kontroll med en lang formel, siden formelen dupliseres i egenskapen for kontrollen uten at du er klar over det. Power Apps er modellert etter Excel, der flere kopier av en formel er vanlig. I Excel er imidlertid formler begrenset til ett uttrykk på 8000 tegn. Power Apps-formler kan vokse mye lengre med innføringen av imperativ logikk og sammenkjedingsoperatoren (; eller ;; avhengig av nasjonale innstillinger).

Den generelle løsningen er å dele opp lange formler i mindre deler og bruke delene på nytt, slik vi gjorde i forrige del da vi endret Set-/Collect-setninger i App.OnStart til navngitte formler i App.Formulas. I andre programmeringsspråk blir deler som kan brukes på nytt, ofte kalt delrutiner eller brukerdefinerte funksjoner. Du kan forestille deg navngitte formler som en enkel form for brukerdefinert funksjon uten parametere eller bivirkninger.

Bruk navngitte formler overalt

I det tidligere eksemplet brukte vi navngitte formler som erstatning for App.OnStart. Du kan imidlertid bruke dem til å erstatte en beregning hvor som helst i en app.

En av skjermene i eksempelløsningen for sykehusberedskap omfatter for eksempel denne logikken 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
    }
); 

Denne formelen kan deles opp i et sett med navngitte formler. Den gjør også formelen lettere å lese.

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 trakk ut ParamFacility som en navngitt formel tidligere da vi flyttet de fleste Set-oppkallene fra App.OnStart til navngitte formler i App.Formulas.

Navngitte formler evalueres bare når verdiene er nødvendige. Hvis den opprinnelige hensikten med å bruke Screen.OnVisible var å utsette arbeidet til skjermen vises, blir arbeidet likevel utsatt som globale navngitte formler i App.Formulas.

Bruk With-funksjonen

Du kan også bruke With-funksjonen i en formel til å dele opp logikk. Opprett en oppføring i den første parameteren med verdiene du vil bruke som felter, og bruk deretter disse feltene i den andre parameteren til å beregne returverdien fra With. Det forrige eksemplet kan for eksempel skrives som bare én navngitt 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 ulempe ved å bruke With på denne måten er at MyFacility ikke kan bruke MyRegion fordi de er definert i samme With-funksjon, et problem som ikke finnes med navngitte formler. Én løsning er å neste With-funksjoner og bruke As-nøkkelordet til å gi oppføringen et navn for hver av dem for å gi enkel tilgang til alle With-variablene.

Bruk lerretskomponenter

Lerretskomponenter brukes oftest til å opprette en brukergrensesnittkontroll som kan plasseres på lerretet akkurat som en kontroll. Du kan også bruke dem uten å plassere dem i brukergrensesnittet for å utføre beregninger med egendefinerte utdataegenskaper som et alternativ til navngitte formler. Lerretskomponenter er enkle å dele på tvers av apper med komponentbiblioteker og støttes fullt ut, i motsetning til navngitte formler. De er imidlertid vanskeligere å konfigurere og bruke enn navngitte formler.

Slik deler du logikk:

  1. Bytt til fanen Komponenter i Trevisning i Power Apps Studio.
  2. Opprett en ny komponent.
  3. Aktiver Få tilgang til appområde i ruten Egenskaper.
  4. Legg til en egendefinert egenskap.
  5. Sett egenskapstypen til Utdata og datatypen etter behov.
  6. Velg Opprett.
  7. Velg den nye egenskapen i egenskapsvelgeren ved siden av formellinjen øverst på skjermen.
  8. Skriv formelen for logikken for å dele den opp og bruke den på nytt.

Slik bruker du logikken:

  1. Bytt til fanen Skjermer i trevisningen.
  2. Utvid Egendefinert i Sett inn-ruten, og sett inn komponenten.
  3. Bruk ComponentName.PropertyName til å beregne en verdi med egenskapen.

Bruk Select med en skjult kontroll for imperativ logikk

Imperativ logikk brukes til å endre tilstand med Set og Collect, varsle brukeren med Notify, navigere til en annen skjerm eller app Navigate og Launch, og skrive verdier til en database med Patch, SubmitForm eller RemoveIf.

Navngitte formler og egendefinerte utdataegenskaper for lerretskomponenter støtter ikke imperativ logikk. Det er vanlig å dele opp imperativ logikk ved å bruke OnSelect-egenskapen for en skjult kontroll.

  1. Legg til en Knapp-kontroll på en skjerm.
  2. Sett egenskapen OnSelect til den imperative logikken du vil kjøre.
  3. Angi false for egenskapen Visible siden brukeren ikke trenger å se eller samhandle med den.
  4. Kall opp Select( Button ) når du vil kjøre den imperative logikken.

En av skjermene i eksemplet vårt har for eksempel følgende OnSelect-egenskap på en Knapp-kontroll. (Dette enkle eksemplet er bare til illustrasjon. Vanligvis bruker du bare denne teknikken til lengre formler.)

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)
    );

Hvis du vil dele denne logikken i deler, kan vi plassere deler på separate Knapp-kontroller og velge dem fra den opprinnelige:

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 );

Denne teknikken fungerer bare på samme skjerm. Andre teknikker som er litt mer komplisert, fungerer på tvers av skjermer, for eksempel når du bruker Vekslebryter-kontrollen, setter OnCheck til logikken du vil kjøre, og setter Default til en global variabel og deretter veksler den globale variabelen med Set( global, true ); Set( global, false ) der du vil kjøre logikken.

I dette eksemplet hadde en del logikkoppdeling allerede blitt utført. Kommentaren nevner at «Påfølgende handlinger finnes i OnSuccess». Denne hendelsen kjører imperativ logikk etter at oppføringen er sendt, en løsning som er spesifikk for SubmitForm-funksjonen.

Partisjoner appen

Noen apper vokser til flere tusen kontroller og hundrevis av datakilder, som gjør at Power Apps Studio går tregere. Som med lange formler kan store apper deles opp i mindre deler som samarbeider om å skape én brukeropplevelse.

Separate lerretsapper

En metode er å implementere deler i separate lerretsapper og bruke Launch-funksjonen til å navigere mellom de separate appene og sende nødvendig kontekst.

Denne metoden ble brukt i eksempelløsningen for sykehusberedskap. Separate apper administrerer hvert av hovedområdene i appen. Appene deler en felles sentralbordkomponent via et komponentbibliotek som hver app viser på oppstartsskjermen:

Skjermbilde av lerretsappen Eksempelløsning for sykehusberedskap som kjører på en telefon, der lerretskomponenten for sentralbordet vises.

Når brukeren velger et område, bruker komponenten metadata om appene som er tilgjengelige, og hvilken app som er vert for komponenten. Hvis den ønskede skjermen er i denne appen (det vil si at ThisItem.Screen ikke er tom), utføres det et Navigate-oppkall. Hvis den ønskede skjermen er i en annen app (det vil si at ThisItem.PowerAppID ikke er tom), brukes en Launch-funksjon med app-ID-en for målet og FacilityID-konteksten:

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
    )
);

Tilstanden i den opprinnelige appen går tapt når en annen app startes. Pass på at du lagrer enhver tilstand før du kaller opp Launch-funksjonen. Skriv den til en database, kall opp SaveData, eller send tilstand til målappen med parametere som leses med Param-funksjonen.

Modelldrevet app med egendefinerte sider

Deler kan også implementeres som egendefinerte sider. Egendefinerte sider fungerer som en minilerretsapp med en modelldrevet appbeholder for navigasjon.

Obs!

Kan du fortelle oss om språkinnstillingene for dokumentasjonen? Ta en kort undersøkelse. (vær oppmerksom på at denne undersøkelsen er på engelsk)

Undersøkelsen tar rundt sju minutter. Det blir ikke samlet inn noen personopplysninger (personvernerklæring).