Miglioramento delle prestazioni con le origini dati
Nell'unità precedente è stato descritto perché le origini dati sono spesso il motivo principale del rallentamento delle prestazioni nell'app. In questa unità si descriveranno alcune delle tecniche comuni che è possibile applicare per ridurre i problemi di prestazioni.
Uso delle raccolte per memorizzare i dati nella cache
Spesso nell'app si rischia di eseguire ripetutamente query sugli stessi dati, come nel caso del pull degli elenchi di reparti per i menu a discesa. In questi casi è possibile eseguire una query sui dati una volta e quindi riutilizzare i dati in tutta l'app. In questo modo, è possibile ridurre le chiamate ripetitive all'origine dati attraverso la rete. Di seguito viene mostrato un esempio di questo processo.
L'app include diverse schermate in cui è disponibile un menu a discesa per la selezione del reparto. L'elenco dei reparti è conservato in Microsoft Dataverse in una tabella denominata DepartmentList. In ogni istanza del menu viene usata la formula seguente.
Filter(DepartmentList, Status = "Active")
La formula funziona correttamente e ha prestazioni adeguate.
Dopo avere completato l'app, ci si rende conto di stare eseguendo più query sulla tabella DepartmentList, anche se si tratta di informazioni statiche. È possibile modificare l'app per creare una raccolta con la proprietà OnStart dell'app per l'archiviazione delle informazioni usando la formula seguente.
Collect(collectDepartmentList, Filter(DepartmentList, Status = "Active"))
Dopo avere archiviato le informazioni, è possibile modificare la proprietà Items dei controlli a discesa in collectDepartmentList invece di Filter(DepartmentList, Status = "Active"). Queste piccole modifiche contribuiscono a migliorare le prestazioni nell'app. Inoltre, acquisendo maggiore familiarità con questa tecnica, è possibile compilare l'app in questo modo sin dall'inizio, riducendo così il numero di formule da scrivere e gestire.
Attenzione alla delega
Un aspetto da tenere presente è che la funzione Collect non può essere delegata. Questo significa che, per impostazione predefinita, dall'origine dati vengono restituiti e archiviati nella raccolta solo i primi 500 elementi. Assicurarsi di prevedere questa limitazione quando si implementa l'uso di raccolte nell'app.
Anche la delega influisce sulle prestazioni
Quando è stata descritta la delega, ci si è concentrati sulla restituzione del numero corretto di righe per l'origine dati. Eppure è anche importante ricordare che la delega può influire sulle prestazioni, in particolare per le app per dispositivi mobili.
Quando una formula delega all'origine dati, tutta l'elaborazione viene gestita dall'origine dati e solo le righe corrispondenti vengono restituite all'app per la visualizzazione attraverso la rete. Se una funzione non può essere delegata, è una pratica comune modificare il limite di delega a 2.000 righe. Questo significa che le prime 2.000 righe vengono scaricate attraverso la rete e quindi elaborate in locale. Negli scenari in cui si usa una connessione a una rete cellulare lenta o un dispositivo mobile di fascia bassa, questa elaborazione può richiedere una notevole quantità di tempo, causando un'esperienza insoddisfacente per l'utente.
Provare a usare quanto più possibile solo funzioni che possono essere delegate. Se la funzione non può essere delegata, prevederne l'impatto sull'utente finale.
Uso della funzione Concurrent per caricare più origini dati
In precedenza è stato descritto come usare le raccolte per memorizzare nella cache i dati nell'app. Quando si implementa questa funzionalità nell'app, non è raro riscontrare il caricamento di diverse raccolte all'avvio dell'app. La proprietà OnStart può essere simile alla seguente.
Collect(collectDepartmentList, Filter(DepartmentList, Status =
"Active")); Collect(collectCompanyList,
CompanyList);Collect(collectRegions, RegionList)
In questo esempio si creano tre raccolte che, però, vengono elaborate una alla volta. Di conseguenza, se l'elaborazione di ognuna impiega 3 secondi, l'utente deve attendere 9 secondi prima che l'app venga avviata.
La funzione Concurrent permette di elaborare tutte le chiamate contemporaneamente. È possibile modificare il codice nel modo seguente.
Concurrent(
Collect(collectDepartmentList, Filter(DepartmentList, Status = "Active")),
Collect(collectCompanyList, CompanyList),
Collect(collectRegions, RegionList)
)
Tutte e tre le formule vengono ora eseguite contemporaneamente, riducendo il tempo di caricamento a tre secondi. La funzione Concurrent è un ottimo strumento per evitare lunghi ritardi nel caso di chiamate asincrone.
Funzionalità sperimentali e di anteprima
All'interno di Power Apps sono disponibili altre funzionalità avanzate che è possibile implementare nell'app. Per accedervi, selezionare File sulla barra dei menu, quindi scegliere Impostazioni app e Impostazioni avanzate. L'elenco delle opzioni visualizzate cambia continuamente, ma spesso include una o più funzionalità correlate alle prestazioni.
Funzionalità di anteprima
Le funzionalità di anteprima sono funzionalità che sono state adeguatamente testate e stanno per essere rese disponibili per tutte le app. Se si acquisisce familiarità con queste funzionalità e le si testa, è possibile prepararsi per quando diventeranno funzionalità standard e la maggior parte sarà abilitata per impostazione predefinita nelle nuove app.
Un esempio di una funzionalità di anteprima corrente che contribuisce a migliorare le prestazioni è il caricamento ritardato. Questa funzionalità "accelera i tempi di avvio dell'app attraverso l'impostazione di chiamate di espressioni per le schermate su richiesta". In altre parole, le schermate non vengono elaborate finché l'utente non vi accede, accelerando l'avvio e l'esecuzione dell'app.
Funzionalità sperimentali
Le funzionalità sperimentali sono funzionalità che possono cambiare, essere interrotte o non essere più disponibili in qualsiasi momento. Queste funzionalità sono disattivate per impostazione predefinita. Anche tra esse possono trovarsi funzionalità per le prestazioni, quindi può essere utile esaminarle. Tuttavia, tenere presente che l'integrazione di queste funzionalità nelle app di produzione rappresenta un rischio, in quanto possono evolvere, cambiare completamente o non essere più disponibili.
A volte, ci si potrebbe imbattere in una funzionalità sperimentale relativa alle prestazioni dell'app. È sempre possibile attivarla e testarla, quindi tornare alle Impostazioni per disabilitarla.
Confronto tra OnStart e OnVisible
Le proprietà OnStart e OnVisible sono incluse nel toolkit per lo sviluppo di app, ma dal punto di vista delle prestazioni possono avere un impatto significativo.
OnStart: si tratta di una proprietà a livello di app. Le formule in questa proprietà vengono eseguite una sola volta, all'avvio dell'app. Tutte le formule devono essere elaborate prima dell'avvio dell'app. Questa tecnica viene spesso usata per inizializzare i dati che saranno necessari in tutta l'app.
OnVisible: si tratta di una proprietà a livello di singola schermata. Le formule in questa proprietà vengono eseguite ogni volta che un utente visualizza la schermata. Viene eseguito il rendering della schermata prima del completamento dell'elaborazione della formula.
Dal punto di vista delle prestazioni, la considerazione più importante riguarda quando viene eseguito il codice: una volta, al momento dell'avvio dell'app, oppure ogni volta che viene visualizzata una schermata. La raccolta per i reparti descritta in precedenza in questo modulo è un ottimo esempio. Il codice viene caricato nella proprietà OnStart dell'app. Ciò significa che viene caricato una sola volta ed è quindi sempre disponibile. Spostando tale codice da OnStart in OnVisible, si perderebbero i vantaggi della raccolta. Se la formula fosse nella proprietà OnVisible, verrebbe eseguita una query sull'origine dati ogni volta che l'utente visualizza la schermata. A livello di prestazioni, questo equivarrebbe a lasciare semplicemente il codice nell'elenco a discesa.
Ciò non significa che non sia consigliabile usare OnVisible. OnVisible è molto utile per le formule che è necessario eseguire in relazione alla schermata corrente. Inoltre, OnVisible non è bloccante. Quindi gli utenti non devono attendere il completamento della formula per visualizzare la schermata. L'utente, pertanto, visualizza per meno tempo la schermata vuota.
Nella maggior parte delle app viene usata una combinazione di OnStart e OnVisible per ottenere un'esperienza ottimale.
Riepilogo
Come si può osservare, esistono numerose opzioni per la creazione dell'app e l'interazione con le origini dati. L'elenco riportato in questa unità non è esaustivo. Le indicazioni fornite sono utili per migliorare le prestazioni, ma i risultati ottenuti potrebbero variare. Iniziando ad applicare queste tecniche per le app, sarà possibile determinare la soluzione più adatta per la specifica situazione e l'ambiente in uso.
L'unità successiva fornisce informazioni sui test e le tecniche di risoluzione dei problemi.