Share via

Noformēt veidlapas veiktspējai modeļa vadītās programmās

  • Raksts

Lai nodrošinātu lietotāju apmierinātību, ir svarīgi veidot pieredzi, kur uzdevumus var izpildīt ātri un efektīvi. Modeļa vadītas programmas var īpaši pielāgot, lai izveidotu pieredzi, kas atbilst jūsu lietotāju vajadzībām, taču ir svarīgi zināt, kā efektīvi kodēt, veidot un palaist modeļa vadītas programmas, kuras ātri ielādējas, kad lietotājs atver un pāriet uz jūsu programmu, strādājot ar ikdienas uzdevumiem. Ir pierādīts, ka veiktspēja ir galvenais iemesls negatīvai attieksmei pret programmu, ja tā nav optimizēta veiktspējai.

Viedi pielāgojumi un veiktspējas veidlapas ir svarīgi aspekti, kas saistīti ar īpaši efektīvu un produktīvu veidlapu veidošanu. Svarīgi ir arī pārliecināties, vai veidojat produktīvas veidlapas, izmantojot labākās metodes lietotāja interfeisa noformējumā un izkārtojumā. Papildinformāciju par veidlapu noformēšanu, nodrošinot efektivitāti un produktivitāti, skatiet rakstā Veidot produktīvas galvenās veidlapas modeļa vadītās programmās.

Svarīgi ir arī nodrošināt, ka lietotāji izmanto ieteicamās un atbalstītās ierīces, kā arī minimālās nepieciešamās specifikācijas. Papildinformācija: Atbalstītās tīmekļa pārlūkprogrammas un mobilās ierīces

Darbs ar datiem un cilnēm

Šajā sadaļā ir aprakstīts, kā vadīklas, kurās tiek parādīti dati un cilnes, ietekmē veidlapu veiktspēju.

Noklusējuma cilnes nozīmīgums

Noklusējuma cilne ir pirmā izvērstā cilne veidlapā. Tajai ir nozīmīga loma veidlapas lapas ielādē. Programma izstrādāta tā, ka noklusējuma cilnes vadīklas vienmēr tiek atveidotas, atverot ierakstu. Kā arī vadīklas inicializācijas loģika, piemēram, datu izgūšana, tiek izsaukta katrai cilnē esošajai vadīklai.

Savukārt sekundāra cilne neveic šo inicializāciju tās vadīklās, kad veidlapa sākotnēji tiek ielādēta. Tā vietā vadīklas inicializēšana notiek brīdī, kad tiek atvērta sekundārā cilne, izmantojot lietotāja mijiedarbību vai izsaucot setFocus klienta API metodi. Tas sniedz iespēju atvieglot sākotnējo veidlapas ielādi no pārmērīgas vadīklu apstrādes, novietojot noteiktas vadīklas sekundārajās cilnēs, nevis noklusējuma cilnē. Tādējādi vadīklu izvietojuma stratēģija var būtiski ietekmēt sākotnējo veidlapas ielādes reaģētspēju. Adaptīvāka noklusējuma cilne nodrošina labāku vispārējo pieredzi svarīgu lauku modificēšanā, mijiedarbībā ar komandjoslu un citu ciļņu un sadaļu izpētē.

Vienmēr novietojiet vadīklas, kas tiek izmantotas visbiežāk, jūsu noklusējuma cilnes augšpusē. Izkārtojuma un informācijas arhitektūra ir svarīga ne tikai veiktspējai, bet arī produktivitātes uzlabošanai, kad lietotāji mijiedarbojas ar datiem veidlapā. Papildinformācija: Veidot produktīvas galvenās veidlapas modeļa vadītās programmās

No datiem atkarīgas vadīklas

Vadīklas, kurām nepieciešami papildu dati, kas pārsniedz primārā ieraksta apjomu, rada vislielāko noslodzi uz veidlapu reaģētspēju un ielādes ātrumu. Šīs vadīklas ienes datus tīklā un bieži ietver gaidīšanas periodu (redzams kā progresa indikatori), jo datu pārsūtīšanai var būt nepieciešams laiks.

Dažas no datiem atkarīgās vadīklas:

Noklusējuma cilnē paturiet tikai visbiežāk izmantotās vadīklas. Pārējās no datiem atkarīgās vadīklas ievietojiet sekundārajās cilnēs, tādējādi ļaujot ātri ielādēt noklusējuma cilni. Turklāt šī izkārtojuma stratēģijas ietvaros tiek samazināta iespēja, ka tiks ienesti dati, kas galu galā netiks izmantoti.

Pastāv arī citas vadīklas, kas ir ar mazāku ietekmi nekā no datiem atkarīgās vadīklas, bet tās joprojām var izmantot iepriekšminētajā izkārtojuma stratēģijā, lai sasniegtu vislabāko veiktspēju. Šīs vadīklas ir:

Tīmekļa pārlūkprogramma

Šī sadaļa attiecas uz labu praksi, ko izmantot tīmekļa pārlūkprogrammās.

Neatveriet jaunus logus

Klienta openForm API metode ļauj parametra opcijai parādīt veidlapu jaunā logā. Nelietojiet šo parametru un neiestatiet to kā nepatiesu. Iestatot to kā nepatiesu, tiks nodrošināts, ka openForm metode veiks veidlapas parādīšanu pēc noklusējuma, izmantojot esošo logu. Var arī varat tieši izsaukt window.open JavaScript funkciju no pielāgota skripta vai citas lietojumprogrammas; tomēr no tā arī būtu jāizvairās. Jauna loga atvēršana nozīmē, ka visi lapas resursi ir jāienes un jāielādē no nulles, jo lapa nespēj piesaistīt atmiņā esošās datu kešatmiņas iespējas no iepriekš ielādētas veidlapas uz veidlapu jaunā logā. Kā alternatīvu jaunu logu atvēršanai, apsveriet vairāksesiju pieredzes izmantošanu, kas ļauj atvērt ierakstus vairākās cilnēs, vienlaikus maksimizējot klienta kešdarbes veiktspējas priekšrocības.

Izmantot modernās pārlūkprogrammas

Visjaunākās tīmekļa pārlūkprogrammas izmantošana ir svarīgs komponents, nodrošinot, ka jūsu modeļa vadītā programma darbojas pēc iespējas ātrāk. Iemesls tam fakts, ka daudzus no veiktspējas uzlabojumiem var izmantot tikai jaunākajās modernajās pārlūkprogrammās.

Piemēram, ja jūsu uzņēmumā izmanto vecākas Firefox versijas vai chromium nebāzētas pārlūkprogrammas utt., daudzas veiktspējas priekšrocības, kas iebūvētas modeļa vadītā programmā, vecākās pārlūkprogrammas versijās nebūs pieejamas, jo tās neatbalsta līdzekļus, no kuriem ir atkarīgs programmas ātrums un veiktspēja.

Vairumā gadījumu var sagaidīt, ka lapas ielādes uzlabojumi būs redzami, vienkārši pārslēdzoties uz Microsoft Edge, jauninot pašreizējo pārlūkprogrammas versiju uz jaunāku versiju vai pārejot uz modernu chromium bāzētu pārlūkprogrammu.

JavaScript pielāgošana

Šajā sadaļā paskaidrots, kā ieviest viedus pielāgojumus, izmantojot JavaScript, kas palīdz veidot veiktspējīgas veidlapas un lapas modeļa vadītā programmā.

Izmantot JavaScript ar veidlapām

Iespēja pielāgot veidlapas, izmantojot JavaScript, nodrošina profesionāliem izstrādātājiem lielāku rīcībspēju attiecībā uz veidlapas izskatu un darbību. Šīs rīcībspējas neatbilstoša izmantošana var negatīvi ietekmēt veidlapas veiktspēju. Izstrādātājiem ir jāizmanto tālāk norādītās stratēģijas, lai maksimizētu veidlapas veiktspēju JavaScript pielāgojumu ieviešanas laikā.

Izmantot asinhronos tīkla pieprasījumus datu pieprasījumos

Ja pielāgojumiem ir nepieciešami papildu dati, pieprasiet datus asinhroni, nevis sinhroni. Notikumiem, kas atbalsta asinhronā koda gaidīšanu, piemēram, veidlapa OnLoad un veidlapas OnSave notikumiem, notikumu apdarinātājiem ir jāatgriež Promise, lai platforma gaidītu, līdz Promise tiek veikts. Platforma parādīs atbilstošu lietotāja interfeisu, kamēr lietotājs gaidīs notikuma pabeigšanu.

Notikumiem, kas neatbalsta asinhronā koda gaidīšanu, piemēram, veidlapas OnChange notikums, varat izmantot risinājumu, kas pārtrauktu mijiedarbību ar veidlapu, kamēr kods veic asinhrona pieprasījuma apstrādi, izmantojot showProgressIndicator. Tas ir labāk, nekā izmantot sinhronos pieprasījumus, jo lietotāji joprojām varēs mijiedarboties ar citām lietojumprogrammas daļām, kamēr progresa indikators darbojas fonā.

Šeit parādīts piemērs, izmantojot asinhronu kodu sinhronos paplašinājuma punktos.

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

Jums ir jābūt piesardzīgam, izmantojot asinhrono kodu notikumu apdarinātājā, kas neatbalsta asinhronā koda gaidīšanu. Tas jo īpaši attiecas uz kodu, kam jāveic vai jāapstrādā asinhronā koda atrisinājums. Asinhronais kods var radīt problēmas, ja atrisinājuma apdarinātājs paredz, ka lietojumprogrammas konteksts paliks tāds pats kā asinhronā koda startēšanas laikā. Kodam ir jāpārbauda, vai lietotājs atrodas vienā un tajā pašā kontekstā pēc katra asinhronā turpinājuma punkta.

Piemēram, notikumu apdarinātājā var būt kods, lai izveidotu tīkla pieprasījumu un mainītu vadīklu, kas veic atspējošanu, pamatojoties uz atbildes datiem. Pirms tiek saņemta atbilde no pieprasījuma, lietotājs var būt mijiedarbojies ar vadīklu vai pārvietojies uz citu lapu. Tā kā lietotājs atrodas citā lapā, veidlapas konteksts var nebūt pieejams, kas, savukārt, var izraisīt kļūdas vai citu nevēlamu uzvedību.

Asinhronais atbalsts veidlapā OnLoad un veidlapā OnSave notikumi

Veidlapa OnLoad un OnSave notikumi atbalsta apdarinātājus, kas atgriež solījumus. Notikumi gaidīs, kad tiks izpildīts jebkurš apdarinātāja solījums, līdz pat taimauta perioda beigām. Šo atbalstu var iespējot, izmantojot programmas iestatījumus.

Papildinformācija:

Ierobežot veidlapas ielādes laikā pieprasīto datu apjomu

Pieprasīt tikai minimālo datu apjomu, kas nepieciešams, lai veidlapā veiktu biznesa loģiku. Ievietojiet kešatmiņā pēc iespējas vairāk datu, kas tiek bieži pieprasīti, it īpaši to datus, kas tiek reti mainīti vai kuriem nav jābūt jauniem. Piemēram, iedomājieties veidlapu, kas pieprasa datus no iestatījumu tabulas. Pamatojoties uz iestatījumu tabulas datiem, veidlapa var izvēlēties paslēpt kādu veidlapas sadaļu. Šajā gadījumā JavaScript var saglabāt datus kešatmiņas sessionStorage, lai katrā sesijā dati tiktu pieprasīti tikai vienreiz (onLoad1). Kad JavaScript izmanto datus no sessionStorage un vienlaikus pieprasa datus nākamajai navigācijai uz veidlapu (onLoad2), var tikt izmantota novecojusi un atkārtoti validēta stratēģija. Visbeidzot, dedublikācijas stratēģiju var izmantot, ja apdarinātājs tiek izsaukts vairākas reizes pēc kārtas (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   
    }
}

Izmantojiet informāciju, kas pieejama klienta API, nevis veiciet pieprasījumus. Piemēram, tā vietā, lai pieprasītu lietotāja drošības lomas veidlapas ielādes laikā, jūs varat izmantot getGlobalContext.userSettings.roles.

Ielādēt kodu tikai kad nepieciešams

Ielādējiet tik daudz koda, cik nepieciešams notikumiem konkrētajā veidlapā. Ja jums ir kods, kas paredzēts tikai veidlapai A un veidlapai B, to nevajadzētu iekļaut bibliotēkā, kas ir ielādēta veidlapas C vajadzībām. Šajā gadījumā ir jāizveido atsevišķa bibliotēka.

Esiet uzmanīgi ielādējot bibliotēkas OnLoad notikumā, ja tās ir paredzētas tikai OnChange vai OnSave notikumiem. Tā vietā ielādējiet tās attiecīgajos notikumos. Tādējādi platforma var atlikt ielādi līdz brīdim, kad veidlapa tiek ielādēta. Papildinformācija: Veidlapu veiktspējas optimizēšana

Konsoles API lietojuma noņemšana ražošanas kodā

Nelietojiet konsoles API metodes, piemēram, console.log ražošanas kodā. Datu reģistrēšana konsolē var būtiski palielināt atmiņas pieprasījumu un traucēt datu tīrīšanu no atmiņas. Tas var izraisīt lietojumprogrammas ātruma samazināšanos un avarēšanu.

Atmiņas noplūžu novēršana

Koda atmiņas noplūdes var radīt lēnāku veiktspēju un likt programmai avarēt. Atmiņas kļūdas rodas, kad lietojumprogramma vairs neizlaiž atmiņu, kad tā vairs nav vajadzīga. Kad veidlapā ir visi pielāgojumi un koda komponenti, jums vajadzētu:

  • Rūpīgi izvērtēt un izmēģināt scenārijus saistībā ar jebko, kas varēja izraisīt atmiņas tīrīšanu, piemēram, klases, kas atbild par objektu dzīves cikla pārvaldību.
  • Notīrīt visus notikumu klausītājus un abonementus, īpaši, ja tie atrodas window objektā.
  • Notīrīt visus taimerus, piemēram, setInterval.
  • Izvairīties no, ierobežot un notīrīt atsauces uz globāliem vai statiskiem objektiem.

Pielāgotas vadības komponentiem tīrīšanu var veikt ar iznīcināšanas metodi.

Lai iegūtu papildinformāciju par atmiņas problēmu novēršanu, atveriet Edge izstrādātāja dokumentāciju .

Rīki, ko var izmantot, lai celtu programmu veiktspēju

Šajā sadaļā ir aprakstīti rīki, kas var palīdzēt izprast veiktspējas problēmas un sniegt ieteikumus, kā optimizēt pielāgojumus modeļa vadītās programmās.

Veiktspējas ieskati

Veiktspējas ieskati ir pašapkalpošanās rīks uzņēmumu programmu veidotājiem, kas analizē izpildlaika telemetrijas datus un nodrošina prioritizētu ieteikumu sarakstu, kas palīdz uzlabot modeļa vadīto programmu veiktspēju. Šis līdzeklis nodrošina ikdienas analītisko ieskatu kopu saistībā ar Power Apps modeļa vadītas vai Customer Engagement programmas, piemēram, Dynamics 365 Sales vai Dynamics 365 Service, veiktspēju kopā ar ieteikumiem un veicamām darbībām. Uzņēmumu programmu veidotāji var skatīt detalizētus veiktspējas ieskatus programmas līmenī Power Apps programmā. Papildinformācija: Kas ir veiktspējas ieskati? (priekšskatījums)

Risinājuma pārbaudītājs

Risinājumu pārbaudītājs ir efektīvs rīks, kas var analizēt klientu un servera pielāgojumus, lai nodrošinātu veiktspēju vai uzticamību. Tā var parsēt klienta puses JavaScript, veidlapu XML un .NET servera puses spraudņus un sniegt mērķtiecīgus ieskatus par to, kas var palēnināt gala lietotāju darbības. Ieteicams palaist risinājumu pārbaudītāju ikreiz, kad publicējat izmaiņas izstrādes vidē, lai visas ar veiktspēju saistītas problēmas tiktu konstatētas pirms tās sasniedz gala lietotāju. Papildinformāciju skatiet sadaļā Risinājumu pārbaudītāja izmantošana modeļa virzītu programmu apstiprināšanai platformā Power Apps

Izmantojot risinājumu pārbaudītāju, var novērst šādas ar veiktspēju saistītas problēmas:

Objektu pārbaudītājs

Objektu meklētājs risinājumā izpilda reāllaika diagnostiku komponentu objektiem. Ja tiek atrastas problēmas, tiek atgriezts ieteikums, kas apraksta, kā novērst problēmu. Papildinformācija: Izmantot objektu pārbaudītāju, lai diagnosticētu risinājuma komponentu (priekšskatījums)

Nākamās darbības

Produktīvs galvenais veidlapas dizains modeļa vadītās programmās