Megosztás a következőn keresztül:

Űrlapok tervezése a modellvezérelt alkalmazások teljesítményéhez

  • Cikk

A felhasználók elégedettsége szempontjából alapvető fontosságú az olyan tapasztalatok kiépítése, amelyeknél a feladatok gyors és hatékony végrehajtásához elengedhetetlenek. A modellvezérelt alkalmazások nagymértékben testreszabhatók, hogy a felhasználók igényeinek megfelelő kezelőfelületet hozzanak létre, de fontos, hogy tudja, hogyan lehet hatékonyan programokat programozni, létrehozni és futtatni a modellvezérelt alkalmazásokat, amelyek gyorsan betöltenek, amikor a felhasználó megnyitja az alkalmazást, és a napi feladatokon dolgozik. A teljesítmény az alkalmazások elégedetlenségének egyik fő hajtóereje, ha nem a teljesítményre van optimalizálva.

Az intelligens testreszabások és az előadói űrlapok a nagy hatékonyságú és hatékony űrlapok építésének fontos szempontjai. Emellett fontos, hogy nagyon hatékony űrlapokat készítsen, a felhasználói felület kialakításával és elrendezésével kapcsolatos gyakorlati tanácsok szerint. A hatékonyság és a hatékonyság érdekében űrlaptervezéssel kapcsolatos információkért lásd: Hatékony fő űrlapok tervezése a modellvezérelt alkalmazásokban.

Emellett fontos annak biztosítása is, hogy a felhasználók a javasolt és támogatott eszközökön és a szükséges minimális specifikációkon vannak. További információk: Támogatott webböngészők és mobileszközök

Adatok és lapok használata

Ez a szakasz azt tartalmazza, hogy az adatokat és lapokat megjelenítő vezérlőelemek hogyan befolyásolják az űrlap teljesítményét.

Az alapértelmezett lap jelentősége

Az alapértelmezett lap az űrlap első kibontott lapja. Ez különleges szerepet játszik az űrlapoldalak betöltésében. A program alapértelmezés szerint mindig az alapértelmezett lap vezérlőit rendereli, amikor megnyit egy bejegyzést. A vezérlőelemek inicializációs logikáját, például az adatkeresést, a lap minden vezérlőjére meghívja a rendszer.

Ezzel szemben a másodlagos lap nem végzi el ezt az inicializációt a vezérlőin az űrlap első betöltésekor. Ehelyett a vezérlő inicializálása a másodlagos lap megnyitásakor vagy a felhasználói interakción keresztül, vagy a(z) setFocus ügyfél API-módszerének hívásával történik. Ez lehetőséget ad arra, hogy az alapértelmezett lap helyett a másodlagos lapokon helyezzen el bizonyos vezérlőket a túlzott mértékű ellenőrzéstől. Így a vezérlőelhelyezés stratégiája tehát jelentős hatással lehet az űrlap első terhelésének kiszabadlottságán. A visszatetszető alapértelmezett lap jobb általános élményt nyújt a fontos mezők módosításához, a parancssávhoz való kapcsolathoz, illetve más lapok és szakaszok felfedezéséhez.

Az alapértelmezett lap tetején mindig a leggyakrabban használt vezérlőelemeket helyezze el. Az elrendezés és az információs architektúra nem csak a teljesítmény számára fontos, hanem a termelékenységet is javítja, amikor a felhasználók az űrlapon adatokat kommunikálnak. További információk: Hatékony fő űrlapok tervezése modellvezérelt alkalmazásokban

Adatalapú vezérlők

Azok a vezérlők, amelyek az elsődleges rekordon túl további adatokat igényelnek, a legnagyobb igénybevételt jelentik az űrlap reagálására és a betöltési sebességre. Ezek a vezérlők a hálózaton keresztül beolvasásra használják az adatokat, és gyakran várakozási időt is tartalmaznak (folyamatjelzőnek stb.), mivel az adatok továbbításához sok időt is el tud venni.

Az adatalapú vezérlők közé tartoznak többek között a következők:

Az alapértelmezett lapon csak a leggyakrabban használt vezérlőelemeket tartsa meg. A fennmaradó adatközpontú vezérlőket el kell terjeszteni másodlagos lapokra annak érdekében, hogy az alapértelmezett lap gyorsan betölthető legyen. Ez az elrendezési stratégia csökkenti annak az esélyét, hogy olyan adatokat hozzon be, amelyek végül nem használtak.

Vannak olyan vezérlők is, amelyek kevésbé hatékonyak az adatalapú vezérlőknél, de továbbra is részt vehetnek a fenti elrendezési stratégiában a legjobb teljesítmény érdekében. Ilyen vezérlőelemek többek között a következők:

Webböngésző

Ez a rész a böngészőkben használható gyakorlati eljárásokat tartalmazza.

Ne nyisson új ablakokat

Az openForm ügyfél API metódusa lehetővé teszi, hogy egy paraméter használatával egy űrlap megjeleníthető egy új ablakban. Ne használja ezt a paramétert, vagy állítsa hamisra. Ha hamisra van állítva, ezzel biztosíthatja, hogy a openForm módszer az űrlap alapértelmezett viselkedését a meglévő ablakban jelenítse meg. A window.open JavaScript függvényt egyéni parancsfájlból vagy másik alkalmazásból is közvetlenül meg lehet hívni, ennek azonban ennek is meg kell lennie elégedve. Az új ablak megnyitása azt jelenti, hogy az összes oldalerőforrást nulláról be kell olvasni és be kell tölteni, mivel az oldal nem tudja használni a korábban betöltött űrlapot és az űrlap közötti, memóriában található adatok gyorsítótárazási lehetőségeit egy új ablakban. Az új ablakok megnyitásának alternatívaként érdemes megfontolni a többértékű használatot, amely lehetővé teszi a bejegyzések több lapon történő megnyitását, miközben továbbra is maximalizálja az ügyfél gyorsítótárazásának teljesítménybeli előnyeit.

Modern böngészők használata

A legújabb böngésző használata kulcsfontosságú a modellvezérelt alkalmazás lehető gyors használatának biztosításához. Ennek oka, hogy a teljesítmény további javításai csak az újabb, modern böngészőkben használhatók.

Ha például szervezete nem a Firefox, Chromium-alapú böngészők stb. korábbi verzióival rendelkezik, a modellalapú alkalmazásokba beépített teljesítményszabadítók nagy része a régebbi böngészős verziókban nem lesz elérhető, mivel nem támogatják az alkalmazás gyors és zökkenőmentes futtatásához használt szolgáltatásokat.

A legtöbb esetben arra lehet számítani, hogy a weblapok terhelésének javításai csupán a Microsoft Edge alkalmazásra vált, a jelenlegi böngésző legújabb verziójára frissít, vagy áttérnek a modern Chromium alapú böngészőre.

JavaScript-testreszabás

Ez a szakasz azt tartalmazza, hogyan lehet intelligens testreszabásokat végezni olyan JavaScript-kód használata esetén, amelyek segítségével modellvezérelt alkalmazásban lehet teljesítményalapú űrlapokat és oldalakat felépíteni.

JavaScript használata űrlapokon

A JavaScript segítségével testre szabható űrlapok lehetősége a professzionális fejlesztők számára nagy rugalmasságot biztosít az űrlapok megjelenésével és viselkedésével. Ennek a rugalmasságnak a használata negatív hatással lehet az űrlap teljesítményére. A JavaScript-testreszabások végrehajtásakor a következő stratégiák alkalmazásával maximalizálható az űrlap teljesítménye.

Aszinkron hálózati kérelmek használata adatok igénylésekor

A testreszabáshoz szükséges további adatok szinkronizálása helyett aszinkron módon kérjen adatokat. Az aszinkron kódra, például az OnLoad űrlap és az OnSave űrlapeseményre való várakozást támogató események esetén az Promise eseménykezelőnek vissza kell térnie egy eseménykezelőnek annak érdekében, hogy a platform megvárja, amíg a Promise le nem áll. A platformon a megfelelő felhasználói felület lesz elérhető, amíg a felhasználó az esemény befejezésére vár.

Olyan események esetén, amelyek nem támogatják az aszinkron kódra való várakozást, mint például az OnChange űrlapesemény, a kerülő megoldás segítségével leállíthatja az űrlapokkal való kommunikációt, miközben a kód aszinkron kérést tesz a showProgressIndicator használatával. Ez jobb, mint a szinkronizált kérelmek használata, mert a felhasználók továbbra is képesek lesznek az alkalmazás egyéb részeivel együttműködni, amint a folyamatjelző látható.

Itt egy példa, amely szinkronizált kiterjesztési pontokban használja az aszinkron kódot.

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

Legyen óvatos, ha olyan eseménykezelőben használ aszinkron kódot, amely nem támogatja az aszinkron kódra való várakozást. Ez különösen igaz azokra a kódokra, amelyeknél az aszinkron kód felbontásával kapcsolatban valamilyen intézkedést kell végrehajtani vagy kezelni. Az aszinkron kód problémákat okozhat, ha a megoldáskezelő elvárja, hogy az alkalmazáskörnyezet ugyanaz maradjon, mint az aszinkron kód elkezdődöttkor. A kódnak ellenőriznie kell, hogy a felhasználó ugyanabban a környezetben van-e minden egyes aszinkron időpont után.

Például előfordulhat, hogy az eseménykezelőben kód van, amely hálózati kérést küld, és a válaszadatok alapján letiltható vezérlőelemet változtat. A kérelem válaszának bekérése előtt a felhasználó kapcsolatba léphetett a vezérlővel, vagy másik oldalra léphetett. Mivel a felhasználó másik oldalon van, előfordulhat, hogy az űrlapkörnyezet nem érhető el, ami hibához vezethet, vagy előfordulhat, hogy más nem kívánatos viselkedés lehet.

aszinkron támogatás az OnLoad űrlap és az OnSave űrlap eseményeken

Az OnLoad űrlap és az OnSave események olyan kezelőket támogatnak, amelyek visszahoznak a visszahozatalhoz. Az események minden, a kezelő által visszaadott eseményre várni fognak, amely egy adott időszakig megoldódik. A támogatás az alkalmazásbeállításokon keresztül engedélyezhető.

További információ:

Az űrlap betöltése során kért adatok mennyiségének korlátozása

Csak az űrlapon az üzleti logika végrehajtásához szükséges minimális mennyiségű adatot kérje. Gyorsítótárazza a lehető legnagyobb mértékben a kért adatokat, különösen az olyan adatok esetén, amelyek nem változnak gyakran, illetve nem kell frissnek lennie. Tegyük fel például, hogy van egy űrlap, amely adatokat kér egy beállítási táblázatból. A beállítási táblázatban található adatok alapján az űrlap elrejtheti az űrlap egy szakaszát. Ebben az esetben a JavaScript képes gyorsítótárazni az sessionStorage adatait olyan környezetben, hogy munkamenetenként (onLoad1) csak egyszer kérjen adatokat. Elavult és újraérvényesedő stratégia használható ott is, ahol a JavaScript az sessionStorage adatait használja, amikor adatokat kér az űrlap (onLoad2) következő navigációs lépéséhez. Végül egy deduplikáció-stratégia használható arra az esetre, ha egy kezelőt többször is többször neveznek egy sorban (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   
    }
}

Kérések helyett használja az ügyfél API-ban rendelkezésre álló adatokat. A felhasználó biztonsági szerepköreit nem az űrlap betöltésekor kell kérni, használhatja például a getGlobalContext.userSettings.roles lehetőséget.

Kód betöltése csak akkor, ha szükséges

Az egyes űrlap eseményeihez szükséges kódot töltse be. Ha olyan kódot tartalmaz, amely csak az A űrlaphoz és a B űrlaphoz van betöltve, nem szabad a C űrlaphoz betöltésű függvénytárban szerepelni. Ennek a saját könyvtárában kell lennie.

Kerülje az OnLoad függvénytárak betöltését abban az esetben, ha a függvénytárakat csak az OnChange vagy OnSave eseményekhez használják. Ehelyett töltse be őket az ilyen eseményekbe. Így a platform az űrlap betöltése utánig elhalaszthatja a betöltést. További információk: Az űrlap teljesítményének optimalizálása

Konzol API-k használatának mellőzése a termelési kódban

Ne használja a termelési kódban az olyan konzol API-metódusokat mint például a console.log. Az adatoknak a konzolba történő naplózása jelentősen növelheti a memóriaigényt, továbbá megakadályozhatja az adatoknak a memóriából történő törlését. Ennek következtében az alkalmazás idővel lelassulhat, végül pedig összeomolhat.

Kerülje el a memóriaszivárgásokat

A kódban lévő memóriaszivárgások idővel lassabb teljesítményhez vezethetnek, végül pedig az alkalmazás összeomlását eredményezhetik. Memóriaszivárgás akkor fordul elő, ha az alkalmazás nem szabadítja fel a használatban nem lévő memóriát. Az űrlapjában jelen lévő testreszabásokon és kódösszetevőkön kívül a következőkre is érdemes odafigyelnie:

  • Alaposan nézze át és tesztelje a memóriatisztításért felelős forgatókönyveket, például az objektumok életciklusának kezeléséért felelős osztályokat.
  • Törölje az összes eseményfigyelőt és -előfizetőt, különösen akkor, ha az a window objektumon van.
  • Törölje az összes időzítőt (pl. setInterval).
  • Mellőzze, korlátozza és törölje a globális és statikus objektumokra mutató hivatkozásokat.

Az egyéni vezérlő összetevők esetében a tisztítás a megsemmisítés módszerrel is elvégezhető.

A memóriával kapcsolatos problémák kijavításáról további információkat ebben az Edge fejlesztői dokumentációban talál.

Az alkalmazások teljesítményének végrehajtásához használható eszközök

Ez a rész olyan eszközöket ismertet, amelyek segítségével jobban érthetők a teljesítmény problémái, és javaslatot tehetnek a modellvezérelt alkalmazások testreszabásának optimalizálására.

Teljesítményre vonatkozó információk

A Performance Insights egy önkiszolgáló eszköz a nagyvállalati alkalmazáskészítők számára, amely elemzi a futásidejű telemetria adatait, és rangsorol egy rangsorban található javaslatokat, amelyek segítenek a modellvezérelt alkalmazások teljesítményének javításában. Ez a funkció a Power Apps modellvezérelt vagy ügyfélkapcsolati alkalmazások (például a Dynamics 365 Sales vagy Dynamics 365 Service) teljesítményével kapcsolatos, napi elemzési információkat biztosít javaslatokkal és használható elemekkel. A vállalati alkalmazáskészítői a részletes teljesítményadatokat az alkalmazás szintjén megtekinthetik a Power Apps-ban. További információk: Mik az előzetes verziós példányok? (előzetes verzió)

Megoldás-ellenőrző

A megoldás-ellenőrző egy hatékony eszköz, amely elemezheti az ügyfelek és a kiszolgálók teljesítmény- és megbízhatósági kérdéseinek testreszabását. Elemezheti az ügyféloldali JavaScript-kódot, XML-formátumú és .NET-kiszolgálóoldali beépülő modulokat, és célzott információkhoz juthat arról, hogy mi lassíthatja le a végfelhasználókat. Azt javasoljuk, hogy a fejlesztési környezetben végrehajtott módosítások minden közzétételekor futtassa a megoldás-ellenőrzőt annak érdekében, hogy a teljesítmény változásai a végfelhasználók elérése előtt megváltoztassanak. További információ: Megoldás-ellenőrző használata a modellalapú alkalmazások ellenőrzéséhez a Power Appsszolgáltatásban

Néhány példa a megoldás-ellenőrzővel kapcsolatban teljesítményével kapcsolatos problémákra:

  • il-specify-column. Ne válassza ki az összes oszlopot a Dataverse lekérdezési API-kban.
  • web-use-async. Kommunikáljon a HTTP- és HTTPS-erőforrásokkal aszinkron módon.
  • web-avoid-ui-refreshribbon. Ne használja a refreshRibbon lehetőséget az OnLoad és az EnableRule űrlapon.

Objektum-ellenőrző

Az objektumellenőrző valós idejű diagnosztikát futtat a megoldásban lévő összetevő-objektumokon. Ha problémák észlelhetők, a rendszer egy, a probléma megoldását leíró javaslatot ad vissza. További információ: Az objektum-ellenőrző funkcióval megszabadhatja a megoldás-összetevőt (előzetes verzió)

További lépések

Hatékony fő űrlapok tervezése a modellvezérelt alkalmazásokban