Deli z drugimi prek

Oblikovanje obrazcev za učinkovitost delovanja v aplikacijah, ki temeljijo na modelu

  • Članek

Ustvarjanje izkušenj, v okviru katerih je opravila mogoče dokončati hitro in učinkovito, je ključnega pomena za zadovoljstvo uporabnika. Aplikacije, ki temeljijo na modelu, so lahko izredno prilagodljive, saj tako omogočajo izkušnje, ki zadovoljijo potrebe vaših uporabnikov. Vseeno je pomembno vedeti, kako učinkovito kodirati, ustvariti in izvajati aplikacije, ki temeljijo na modelu in ki se, medtem ko uporabnik opravlja vsakodnevna opravila in aplikacijo odpre ter se po njej pomika, hitro naložijo. Učinkovitost delovanja se je izkazala za poglavitni razlog nezadovoljstva z aplikacijo, takrat ko ta ni optimizirana za učinkovito delovanje.

Preudarne prilagoditve in efektivni obrazci imajo pomembno vlogo pri ustvarjanju izjemno učinkovitih in produktivnih obrazcev. Prav tako je pomembno zagotoviti, da izjemno učinkovite obrazce ustvarjate z najboljšimi praksami v zasnovi in postavitvi uporabniškega vmesnika. Za informacije o oblikovanju obrazcev za učinkovitost delovanja in produktivnost si oglejte Oblikovanje učinkovitih glavnih obrazcev v aplikacijah, ki temeljijo na modelu.

Prav tako je pomembno zagotoviti, da uporabniki uporabljajo priporočene in podprte naprave ter da imajo minimalne zahtevane specifikacije. Več informacij: Podprti spletni brskalniki in mobilne naprave

Delo s podatki in zavihki

Ta razdelek vsebuje informacije o tem, kako kontrolniki, ki prikazujejo podatke, in zavihki vplivajo na učinkovitost delovanja obrazcev.

Pomen privzetega zavihka

Privzeti zavihek je prvi razširjeni zavihek na obrazcu. Ta zavihek ima pomembno vlogo pri nalaganju strani obrazca. Kar zadeva zasnovo, se kontrolniki privzetega zavihka upodobijo ob vsakem odprtju zapisa. Logika inicializacije kontrolnika, npr. pridobivanje podatkov, se torej sproži za vsak kontrolnik na zavihku.

Sekundarni zavihek po drugi strani ob prvotnem nalaganju obrazca za svoje kontrolnike ne izvede inicializacije. Namesto tega do inicializacije kontrolnika pride takrat, ko je sekundarni zavihek odprt bodisi s komunikacijo uporabnikov bodisi s klicem metode API-ja odjemalca setFocus. To nalaganje prvotnega obrazca ščiti pred prekomerno obdelavo kontrolnika, in sicer tako, da so nekateri kontrolniki pomaknjeni na sekundarni, ne pa na privzeti zavihek. Na tak način lahko strategija pomikanja kontrolnikov pomembno vpliva na odzivnost nalaganja prvotnega obrazca. Privzeti zavihek, ki je bolj odziven, zagotavlja boljšo splošno izkušnjo spreminjanja pomembnih polj, interakcije z ukazno vrstico in raziskovanja drugih zavihkov ter razdelkov.

Najpogosteje uporabljeni kontrolniki naj bodo vedno na vrhu vašega privzetega zavihka. Arhitektura postavitve in informacij ni pomembna samo za učinkovito delovanje, ampak tudi za izboljšanje produktivnosti ob interakciji uporabnikov s podatki na obrazcu. Več informacij: Oblikovanje učinkovitih glavnih obrazcev v aplikacijah, ki temeljijo na modelu

Kontrolniki, ki temeljijo na podatkih

Odzivnost obrazca in hitrost nalaganja najbolj ogrožajo kontrolniki, ki zahtevajo dodatne podatke, in sicer tiste, ki niso del primarnega zapisa. Ti kontrolniki podatke pridobivajo v omrežju in pogosto vključujejo obdobje čakanja (v obliki kazalnikov napredka), saj lahko prenos podatkov traja nekaj časa.

Nekateri kontrolniki, ki temeljijo na podatkih, vključujejo naslednje:

Na privzetem zavihku ohranite samo najpogosteje uporabljene kontrolnike. Preostale kontrolnike, ki temeljijo na podatkih, razvrstite na sekundarne zavihke, saj boste tako omogočili hitro nalaganje privzetega zavihka. S to strategijo postavitve boste prav tako zmanjšali možnost pridobivanja podatkov, ki na koncu niso uporabljeni.

Obstajajo še drugi kontrolniki, ki nimajo tako velikega vpliva kot tisti, ki temeljijo na podatkih, vendar so lahko z namenom zagotovitve največje učinkovitosti delovanja vseeno vključeni v zgoraj omenjeno strategijo postavitve. Gre za naslednje kontrolnike:

Spletni brskalnik

V ta razdelek so vključene dobre prakse, ki so uporabne za spletne brskalnike.

Neodpiranje novih oken

Metoda API-ja odjemalca openForm omogoča, da možnost parametra obrazec prikaže v novem oknu. Tega parametra ne uporabljajte ali pa ga nastavite na »false«. S tem, ko ga boste nastavili na »false«, boste zagotovili, da bo metoda openForm obrazec privzeto prikazala v obstoječem oknu. Čeprav je omogočeno tudi, da iz skripta po meri ali druge aplikacije neposredno pokličete funkcijo JavaScript window.open, se tej metodi izogibajte. To, da se odpre novo okno, pomeni, da morajo biti na novo pridobljeni in preneseni vsi viri strani, saj stran med predhodno naloženim obrazcem in obrazcem v novem oknu ne more izkoristiti zmogljivosti predpomnjenja podatkov znotraj pomnilnika. Namesto da odpirate nova okna, lahko uporabite večsejno izkušnjo, ki omogoča odpiranje zapisov na več zavihkih, pri čemer so ugodnosti učinkovitega delovanja pri predpomnjenju odjemalca še vedno maksimalne.

Uporaba sodobnih brskalnikov

Uporaba najnovejšega spletnega brskalnika je ključ do zagotovitve, da se vaša aplikacija, ki temelji na modelu, izvaja z največjo možno hitrostjo. Tako je zato, ker je velik del izboljšav učinkovitosti delovanja mogoč samo v novejših, sodobnejših brskalnikih.

Če ima vaša organizacija npr. starejšo različico brskalnika Firefox, ki ne temelji na Chromiumu, velik del ugodnosti, ki jih pridobite z izboljšanjem učinkovitosti delovanja in ki so omogočene v aplikacijah, ki temeljijo na modelu, v taki različici ne bo na voljo, saj starejši brskalniki ne podpirajo funkcij, od katerih je odvisno hitrejše in lažje izvajanje aplikacij.

V večini primerov si lahko izboljšave nalaganja strani zagotovite tako, da preklopite na Microsoft Edge ali da starejšo verzijo brskalnika posodobite na tisto, ki je trenutno najnovejša, ali pa tako, da izberete sodoben brskalnik, ki temelji na Chromiumu.

Prilagajanje za JavaScript

V tem razdelku je opisano, kako preudarno prilagajati, ko uporabljate JavaScript, s pomočjo katerega lahko v aplikaciji, ki temelji na modelu, ustvarite učinkovite obrazce in strani.

Uporaba jezika JavaScript z obrazci

Prilagoditve obrazcev, za katere je uporabljen JavaScript, profesionalnim razvijalcem omogočajo, da v veliki meri spreminjajo videz in delovanje obrazcev. Nepravilna uporaba te možnosti lahko negativno vpliva na učinkovitost delovanja obrazca. Če želijo razvijalci, ko uvajajo prilagoditve tako, da uporabljajo JavaScript, doseči čim večjo učinkovitost delovanja obrazca, morajo uporabiti naslednje strategije.

Uporaba asinhronih zahtev omrežja pri zahtevanju podatkov

Če so za prilagoditve potrebni dodatni podatki, slednje raje zahtevajte asinhrono kot sinhrono. Za dogodke, ki podpirajo čakanje na asinhrono kodo, kot so npr. dogodki OnLoad ali OnSave za obrazce, morajo rutine za obravnavo dogodka vrniti Promise, da lahko platforma počaka, dokler Promise ni urejen. Medtem ko uporabnik čaka, da se dogodek zaključi, platforma prikaže ustrezen uporabniški vmesnik.

Za dogodke, ki ne podpirajo čakanja na asinhrono kodo, kot je npr. dogodek OnChange za obrazec, lahko uporabite rešitev za prekinitev interakcije z obrazcem v času, ko koda ob uporabi elementa showProgressIndicator izvaja asinhrono zahtevo. To je bolje, kot če bi uporabili sinhrone zahteve, saj uporabnikom ob prikazu kazalnika napredka omogoči nadaljnjo interakcijo z drugimi deli aplikacije.

To je primer uporabe asinhrone kode v sinhronih točkah razširitve.

//Only do this if an extension point does not yet support asynchronous code
try {
    await Xrm.WebApi.retrieveRecord("settings_entity", "7333e80e-9b0f-49b5-92c8-9b48d621c37c");
    //do other logic with data here
} catch (error) {
    //do other logic with error here
} finally {
    Xrm.Utility.closeProgressIndicator();
}

// Or using .then/.finally
Xrm.Utility.showProgressIndicator("Checking settings...");
Xrm.WebApi.retrieveRecord("settings_entity", "7333e80e-9b0f-49b5-92c8-9b48d621c37c")
    .then(
        (data) => {
            //do other logic with data here
        },
        (error) => {
            //do other logic with error here
        }
    )
    .finally(Xrm.Utility.closeProgressIndicator);

Pri uporabi asinhrone kode v rutini za obravnavo dogodkov, ki ne podpira čakanja na asinhrono kodo, morate biti previdni. To še posebej velja za kodo, za katero je potrebno ukrepanje glede razrešitve asinhrone kode. Asinhrona koda lahko povzroči težave, če rutina za obravnavo rešitve pričakuje, da bo kontekst aplikacije ostal enak kontekstu ob zagonu asinhrone kode. Vaša koda mora preveriti, ali je uporabnik po vsaki asinhroni točki nadaljevanja v enakem kontekstu.

V rutini za obravnavo dogodkov je lahko npr. koda za ustvarjanje zahteve omrežja in za spremembo kontrolnika z namenom onemogočenja na podlagi podatkov o odzivu. Pred prejemom odziva zahteve lahko pride do interakcije med uporabnikom in kontrolnikom, prav tako pa se lahko uporabnik pomakne na drugo stran. Ker je uporabnik na drugi strani, kontekst obrazca morda ni na voljo, zaradi česar lahko pride do napak ali kakršnega koli drugega neželenega delovanja.

Asinhrona podpora v dogodkih OnLoad in OnSave za obrazec

Dogodka OnLoad in OnSave za obrazec podpirata rutine za obdelavo, ki vračajo obljube. Dogodka bosta do nastopa časovne omejitve čakala na vse obljube, ki jih bo rutina za obravnavo vrnila z namenom razrešitve. To podporo lahko omogočite v nastavitvah aplikacije.

Več informacij:

Omejitev količine podatkov, ki so zahtevani med nalaganjem obrazca

Ne zahtevajte več kot toliko podatkov, kot jih potrebujete za izvajanje poslovne logike na obrazcu. Za podatke, ki so zahtevani, predvsem za tiste, ki se ne spreminjajo pogosto ali za katere ni potrebe po tem, da bi bili najnovejši, čim več uporabljajte predpomnjenje. Predstavljajte si npr., da obstaja obrazec, ki zahteva podatke iz tabele za nastavitve. Na podlagi podatkov v tej tabeli se lahko obrazec odloči za skritje razdelka obrazca. V tem primeru lahko JavaScript zažene predpomnjenje podatkov v sessionStorage, tako da so podatki zahtevani samo enkrat na sejo (onLoad1). Strategija ponovnega preverjanja zastarelosti je lahko med zahtevanjem podatkov za naslednji pomik na obrazec (onLoad2) uporabljena na mestih, na katerih JavaScript uporablja podatke iz elementa sessionStorage. Strategija odstranjevanja podvajanj pa je lahko uporabljena v primerih, ko je rutina za obravnavo poklicana večkrat zapored (onLoad3).

const SETTING_ENTITY_NAME = "settings_entity";
const SETTING_FIELD_NAME = "settingField1";
const SETTING_VALUE_SESSION_STORAGE_KEY = `${SETTING_ENTITY_NAME}_${SETTING_FIELD_NAME}`;

// Retrieve setting value once per session
async function onLoad1(executionContext) {
    let settingValue = sessionStorage.getItem(SETTING_VALUE_SESSION_STORAGE_KEY);

    // Ensure there is a stored setting value to use
    if (settingValue === null || settingValue === undefined) {
        settingValue = await requestSettingValue();
    }

    // Do logic with setting value here
}

// Retrieve setting value with stale-while-revalidate strategy
async function onLoad2(executionContext) {
    let settingValue = sessionStorage.getItem(SETTING_VALUE_SESSION_STORAGE_KEY);

    // Revalidate, but only await if session storage value is not present
    const requestPromise = requestSettingValue();

    // Ensure there is a stored setting value to use the first time in a session
    if (settingValue === null || settingValue === undefined) {
        settingValue = await requestPromise;
    }
    
    // Do logic with setting value here
}

// Retrieve setting value with stale-while-revalidate and deduplication strategy
let requestPromise;
async function onLoad3(executionContext) {
    let settingValue = sessionStorage.getItem(SETTING_VALUE_SESSION_STORAGE_KEY);

    // Request setting value again but don't wait on it
    // In case this handler fires twice, don’t make the same request again if it is already in flight
    // Additional logic can be added so that this is done less than once per page
    if (!requestPromise) {
        requestPromise = requestSettingValue().finally(() => {
            requestPromise = undefined;
        });
    }

    // Ensure there is a stored setting value to use the first time in a session
    if (settingValue === null || settingValue === undefined) {
        settingValue = await requestPromise;
    }
    
    // Do logic with setting value here
}

async function requestSettingValue() {
    try {
        const data = await Xrm.WebApi.retrieveRecord(
            SETTING_ENTITY_NAME,
            "7333e80e-9b0f-49b5-92c8-9b48d621c37c",
            `?$select=${SETTING_FIELD_NAME}`);
        try {
            sessionStorage.setItem(SETTING_VALUE_SESSION_STORAGE_KEY, data[SETTING_FIELD_NAME]);
        } catch (error) {
            // Handle sessionStorage error
        } finally {
            return data[SETTING_FIELD_NAME];
        }
    } catch (error) {
        // Handle retrieveRecord error   
    }
}

Namesto da podajate zahteve, uporabite podatke, ki so na voljo v API-ju odjemalca. Namesto da ob nalaganju obrazca zahtevate uporabnikove varnostne vloge, uporabite getGlobalContext.userSettings.roles.

Nalaganje kode samo po potrebi

Za dogodke določenega obrazca naložite toliko kode, kot je potrebno. Če imate kodo, ki je primerna samo za obrazec A in obrazec B, je ne vključite v knjižnico, ki je naložena za obrazec C. Vsak obrazec naj bo v svoji knjižnici.

Izogibajte se nalaganju knjižnic v dogodek OnLoad, če so uporabljene samo za dogodek OnChange ali dogodek OnSave. Naložite jih v ustrezen dogodek. Tako bo lahko platforma njihovo nalaganje odložila, šele ko se obrazec naloži. Več informacij: Optimizacija učinkovitosti delovanje obrazca

Odstranite uporabo API-jev konzole v produkcijski kodi

V proizvodni kodi ne uporabljajte metod konzolnega API-ja kot npr. console.log. Beleženje podatkov v konzolo lahko znatno poveča povpraševanje po pomnilniku in lahko prepreči čiščenje podatkov v pomnilniku. To lahko povzroči, da aplikacija sčasoma postane počasnejša in se sčasoma zruši.

Izogibajte se izgubam pomnilnika

Izgube pomnilnika v vaši kodi lahko povzročijo počasnejše delovanje in sčasoma zrušijo vašo aplikacijo. Do izgube pomnilnika pride, ko aplikacija pomnilnika ne sprosti, ko ga ne potrebuje več. Z vsemi prilagoditvami in komponentami kode na obrazcu bi morali:

  • Temeljito preučiti in preizkusiti scenarije za vse, kar je odgovorno za brisanje pomnilnika, kot so razredi, odgovorni za upravljanje življenjskega cikla predmetov.
  • Počistiti vse poslušalce dogodkov in naročnine, še posebej, če so na predmetu window.
  • Počistite vsee časovnike, kot je setInterval.
  • Izogibati se, omejiti in očistiti sklicevanja na globalne ali statične predmete.

Za nadzorne komponente po meri je možno čiščenje izvesti v metodi uničiti.

Za več informacij o odpravljanju težav s pomnilnikom pojdite na to dokumentacijo za razvijalce Edge.

Orodja za izboljšanje učinkovitosti aplikacij

V tem razdelku so opisana orodja, s pomočjo katerih boste bolje razumeli težave z učinkovitostjo delovanja in ki vam ponujajo priporočila, kako v aplikacijah, ki temeljijo na modelu, optimizirati prilagoditve.

Vpogledi v učinkovitost delovanja

Vpogledi v učinkovitost delovanja so samopostrežno orodje za ustvarjalce aplikacij za podjetja, ki analizira telemetrične podatke o izvajanju in ponuja prednostni seznam priporočil za izboljšanje učinkovitosti delovanja aplikacij, ki temeljijo na modelu. Ta funkcija zagotavlja dnevni nabor analitičnih vpogledov, povezanih z delovanjem aplikacije Power Apps, ki temelji na modelu, ali aplikacije za interakcijo s strankami, kot je Dynamics 365 Sales ali Dynamics 365 Service, s priporočili in elementi, ki jih je mogoče izvesti. Ustvarjalci aplikacij za podjetja lahko v storitvi Power Apps vidijo podrobne vpoglede v učinkovitost delovanja na ravni aplikacije. Več informacij: Kaj so vpogledi v učinkovitost delovanja? (predogledna različica)

Preverjevalnik rešitev

Preverjevalnik rešitev je zmogljivo orodje, ki lahko analizira prilagoditve odjemalca in strežnika glede težav z učinkovitostjo delovanja ali z zanesljivostjo. Razčleni lahko strežniške vtičnike za odjemalski JavaScript, XML obrazca in .NET ter ponudi ciljne vpoglede v morebitne razloge za upočasnitev končnih uporabnikov. Priporočamo, da preverjevalnik rešitev zaženete vsakič, ko v razvojno okolje objavite spremembe, tako da bodo vsakršni pomisleki glede učinkovitosti delovanja znani, še preden dosežejo končne uporabnike. Več informacij: Uporaba pregledovalnika rešitev v storitvi Power Apps za preverjanje veljavnosti aplikacij, ki temeljijo na modelu

Nekaj primerov težav, povezanih z učinkovitostjo delovanja, ki jih zazna preverjevalnik rešitev:

Preverjevalnik predmeta

Preverjevalnik predmeta v vaši rešitvi sproti preverja predmete komponent. Če zazna težave, se vam prikaže priporočilo z napotki, kako jih rešiti. Več informacij: Uporaba preverjevalnika rešitev za diagnosticiranje komponente rešitve (predogledna različica)

Naslednji koraki

Oblikovanje produktivnih glavnih obrazcev v aplikacijah, ki temeljijo na modelih