Kongsi melalui

Borang reka bentuk untuk prestasi dalam aplikasi berpandukan model

  • Artikel

Membina pengalaman yang tugas boleh diselesaikan dengan pantas dan efisien adalah penting untuk kepuasan pengguna. Aplikasi berpandukan model sangat boleh disesuaikan untuk mencipta pengalaman yang memenuhi keperluan pengguna anda, tetapi ia amat penting untuk mengetahui cara untuk mengekod, membina dan menjalankan aplikasi berpandukan model secara efektif yang dimuatkan dengan pantas apabila pengguna membuka dan menavigasi dalam aplikasi anda semasa melakukan tugas harian. Prestasi telah ditunjukkan sebagai pemacu utama ketidakpuasan hati aplikasi apabila ia tidak dioptimumkan untuk prestasi.

Penyesuaian pintar dan borang prestasi adalah aspek penting untuk membina borang yang amat efisien dan produktif. Ia juga penting untuk memastikan bahawa anda sedang membina borang yang sangat produktif dengan amalan terbaik dalam reka bentuk antara muka pengguna dan susun atur. Untuk maklumat mengenai mereka bentuk borang untuk kecekapan dan produktiviti, lihat Reka bentuk borang utama yang produktif dalam aplikasi berpandukan model.

Ia juga penting untuk memastikan pengguna menggunakan peranti yang disyorkan dan disokong dan spesifikasi minimum yang diperlukan. Maklumat lanjut: Pelayar web dan peranti mudah alih yang disokong

Bekerja dengan data dan tab

Bahagian ini meliputi cara kawalan yang memaparkan data dan tab prestasi borang kesan.

Kepentingan tab lalai

Tab lalai ialah tab pertama yang dikembangkan pada borang. Ia memainkan peranan khas dalam memuatkan halaman borang. Mengikut reka bentuk, kawalan tab lalai sentiasa ditunjukkan apabila membuka rekod. Secara khusus, logik pengawalan kawalan, seperti dapatan semula data, telah digunakan untuk setiap kawalan pada tab.

Sebaliknya, tab sekunder tidak melaksanakan pengawalan ini ke atas kawalannya apabila borang itu dimuat pada awalnya. Sebaliknya, pengawalan kawalan berlaku pada masa tab sekunder dibuka sama ada melalui interaksi pengguna atau memanggil kaedah API klien setFocus. Ini memberikan peluang untuk melindungi muatan borang awal daripada pemprosesan kawalan berlebihan dengan meletakkan kawalan tertentu dalam tab sekunder dan bukannya tab lalai. Oleh itu, strategi penempatan kawalan boleh memberikan kesan yang ketara ke atas tindak balas muatan borang awal. Tab lalai yang lebih responsif menyediakan pengalaman keseluruhan yang lebih baik untuk mengubah suai medan penting, berinteraksi dengan bar perintah dan menerokai tab dan bahagian lain.

Sentiasa letak kawalan yang paling banyak digunakan pada bahagian atas tab lalai anda. Susun atur dan seni bina maklumat bukan hanya penting untuk prestasi tetapi juga untuk meningkatkan produktiviti apabila pengguna berinteraksi dengan data pada borang. Maklumat lanjut: Reka bentuk borang utama yang produktif dalam aplikasi berpandukan model

Kawalan berpandukan data

Kawalan yang memerlukan data tambahan melampaui rekod utama menghasilkan terikan terbanyak pada tindak balas borang dan kelajuan muatan. Kawalan ini mengambil data melalui rangkaian dan sering melibatkan tempoh menunggu (dilihat sebagai penunjuk perkembangan) kerana ia boleh mengambil masa untuk menghantar data.

Sesetengah kawalan berpandukan data termasuk:

Hanya simpan yang paling kerap digunakan untuk kawalan ini pada tab lalai. Baki kawalan berpandukan data mesti diedarkan ke dalam tab sekunder untuk membolehkan tab lalai dimuatkan dengan pantas. Tambahan pula, strategi susun atur ini mengurangkan peluang pengambilan data yang akhirnya tidak digunakan.

Terdapat kawalan lain yang kurang kesan daripada kawalan berpandukan data tetapi masih boleh mengambil bahagian dalam strategi susun atur di atas untuk mencapai prestasi yang terbaik. Kawalan ini termasuk:

Pelayar web.

Bahagian ini meliputi amalan terbaik untuk digunakan dengan pelayar web.

Jangan buka tetingkap baharu

Kaedah API klien openForm membolehkan pilihan parameter untuk memaparkan borang dalam tetingkap baharu. Jangan gunakan parameter ini atau tetapkan kepada palsu. Tetapkannya kepada palsu akan memastikan kaedah openForm melaksanakan tingkah laku lalai untuk memaparkan borang yang menggunakan tetingkap sedia ada. Ia mungkin juga untuk memanggil secara langsung fungsi window.open JavaScript daripada skrip tersuai atau aplikasi lain; walau bagaimanapun, ini juga perlu dielakkan. Membuka tetingkap baharu bermaksud semua sumber halaman perlu diambil dan dimuatkan dari awal kerana halaman tidak dapat memanfaatkan keupayaan pengagregatan data memori dalam antara borang yang dimuatkan sebelum ini dan borang dalam tetingkap baharu. Sebagai alternatif untuk membuka tetingkap baharu, pertimbangkan untuk menggunakan pengalaman berbilang sesi yang membenarkan rekod untuk dibuka dalam berbilang tab tetapi masih memaksimumkan faedah prestasi pengagregatan klien.

Gunakan pelayar moden

Menggunakan pelayar web terkini adalah kunci untuk memastikan aplikasi berpandukan model anda berjalan sepantas mungkin. Sebab untuk ini adalah banyak peningkatan prestasi hanya boleh digunakan dalam pelayar moden yang baharu.

Sebagai contoh, jika organisasi anda mempunyai versi Firefox lebih lama, pelayar tidak berasaskan Chromium, dan sebagainya, kebanyakan keuntungan prestasi yang dibina ke dalam aplikasi berpandukan model tidak akan tersedia dalam versi pelayar lebih lama kerana ia tidak menyokong ciri aplikasi bergantung kepada untuk berjalan dengan pantas dan lancar.

Dalam kebanyakan kes, anda boleh mengharapkan untuk melihat peningkatan muatan halaman dengan hanya bertukar kepada Microsoft Edge, mengemas kini kepada versi pelayar terkini terkini daripada versi lebih lama atau berpindah kepada pelayar berasaskan Chromium yang moden.

Penyesuaian JavaScript

Bahagian ini meliputi cara untuk membuat penyesuaian pintar apabila anda menggunakan JavaScript yang membantu anda membina borang dan halaman prestasi dalam aplikasi berpandukan model.

Menggunakan JavaScript dengan borang

Keupayaan borang untuk disesuaikan oleh JavaScript menyediakan pembangun profesional fleksibiliti besar ke atas cara borang kelihatan dan berfungsi. Penggunaan tak wajar fleksibiliti ini boleh memberi kesan secara negatif kepada prestasi borang. Pembangun harus menggunakan strategi berikut untuk memaksimumkan prestasi borang apabila melaksanakan penyesuaian JavaScript.

Gunakan permintaan rangkaian tidak segerak apabila meminta data

Meminta data secara tidak segerak dan bukannya secara disegerakkan apabila lebihan data diperlukan untuk penyesuaian. Untuk peristiwa yang menyokong menunggu kod tidak segerak seperti peristiwa OnLoad borang dan OnSave borang, pengendali peristiwa harus mengembalikan Promise untuk platform menunggu sehingga Promise diselesaikan. Platform akan menunjukkan UI yang sesuai manakala pengguna menunggu peristiwa untuk diselesaikan.

Untuk peristiwa yang tidak menyokong menunggu kod tidak segerak, seperti peristiwa OnChange borang, anda boleh menggunakan penyelesaian untuk berhenti interaksi dengan borang sementara kod melakukan permintaan tidak segerak dengan menggunakan showProgressIndicator. Ini lebih baik daripada menggunakan permintaan segerak kerana pengguna masih akan dapat berinteraksi dengan bahagian lain aplikasi dan penunjuk kemajuan dipaparkan.

Ini adalah contoh menggunakan kod tidak segerak dalam titik sambungan segerak.

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

Anda harus berhati-hati apabila menggunakan kod tidak segerak dalam pengendali peristiwa yang tidak menyokong menunggu kod tidak segerak. Ini adalah benar bagi kod yang memerlukan tindakan untuk diambil atau diuruskan pada penyelesaian kod tidak segerak. Kod tidak segerak boleh menyebabkan isu jika pengendali penyelesaian menjangkakan konteks aplikasi untuk kekal sama seperti itu apabila kod tidak segerak telah dimulakan. Kod anda perlu menyemak bahawa pengguna berada dalam konteks yang sama selepas setiap titik berterusan tidak segerak.

Sebagai contoh, mungkin terdapat kod dalam pengendali peristiwa untuk membuat permintaan rangkaian dan mengubah kawalan untuk dinyahdaya berdasarkan data tindak balas. Sebelum tindak balas daripada permintaan diterima, pengguna mungkin sudah berinteraksi dengan kawalan atau menavigasi ke halaman yang berbeza. Oleh kerana pengguna berada pada halaman yang berbeza, konteks borang mungkin tidak tersedia, yang mungkin membawa kepada ralat atau mungkin terdapat tingkah laku lain yang tidak diingini.

Sokongan tak segerak dalam acara OnLoad borang dan OnSave borang

OnLoad borang dan peristiwa OnSave menyokong pengendali yang mengembalikan janji. Peristiwa akan menunggu sebarang janji yang dikembalikan oleh pengendali untuk selesaikan, sehingga tamat tempoh masa. Sokongan ini boleh didayakan melalui tetapan aplikasi.

Maklumat lanjut:

Hadkan amaun data yang diminta semasa muatan borang

Hanya meminta amaun minimum data yang perlu untuk melaksanakan logik perniagaan pada borang. Cache data yang diminta sebanyak mungkin, terutamanya bagi data yang jarang berubah atau tidak semestinya segar. Sebagai contoh, bayangkan terdapat borang yang data yang diminta daripada jadual tetapan. Berdasarkan data di dalam jadual tetapan, borang mungkin memilih untuk menyembunyikan bahagian borang. Dalam kes ini, JavaScript boleh cache data dalam sessionStorage supaya data tersebut hanya diminta sekali setiap sesi (onLoad1). Strategi basi semasa dikaji semula mungkin boleh digunakan yang JavaScript menggunakan data daripada sessionStorage semasa meminta data untuk navigasi seterusnya kepada borang (onLoad2). Akhir sekali, strategi nyapendua boleh digunakan jika pengendali dipanggil berbilang kali dalam baris (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   
    }
}

Gunakan maklumat yang tersedia dalam API klien daripada membuat permintaan. Sebagai contoh, daripada meminta peranan keselamatan pengguna pada muatan borang, anda boleh menggunakan getGlobalContext.userSettings.roles.

Muatkan kod hanya apabila ia diperlukan

Muatkan seberapa banyak kod yang diperlukan untuk peristiwa bagi borang tertentu. Jika anda mempunyai kod yang hanya untuk borang A dan borang B, ia tidak boleh dimasukkan ke dalam pustaka yang dimuatkan untuk borang C. Ia sepatutnya berada dalam pustaka sendiri.

Elakkan daripada memuatkan dalam peristiwa OnLoad jika ia hanya digunakan untuk peristiwa OnChange atau OnSave. Sebaliknya, muatkannya dalam peristiwa tersebut. Cara ini platform boleh menangguh memuatkannya sehingga selepas borang dimuatkan. Maklumat lanjut: Optimumkan prestasi borang

Alih keluar penggunaan konsol API dalam kod pengeluaran

Jangan gunakan kaedah konsol API seperti console.log dalam kod pengeluaran. Data pengelogan pada konsol boleh meningkatkan permintaan memori secara ketara dan mungkin mengelakkan data daripada dikosongkan dalam memori. Ini boleh menyebabkan aplikasi menjadi lebih perlahan dari masa ke masa dan akhirnya ranap.

Elakkan daripada kebocoran memori

Kebocoran memori dalam kod anda boleh menyebabkan prestasi lebih perlahan dari masa ke masa dan akhirnya menyebabkan aplikasi anda ranap. Kebocoran memori berlaku apabila aplikasi gagal untuk mengeluarkan memori apabila tidak diperlukan lagi. Dengan semua penyesuaian dan komponen kod dalam borang anda, anda haruslah:

  • Mempertimbangkan dan menguji senario dengan teliti untuk apa-apa yang bertanggungjawab untuk mengosongkan memori, seperti kelas yang bertanggungjawab untuk menguruskan kitaran hayat objek.
  • Kosongkan semua pendengar dan langganan peristiwa, terutamanya jika ia berada dalam objek window.
  • Kosongkan semua pemasa seperti setInterval.
  • Elakkan, hadkan dan kosongkan rujukan ke objek global atau statik.

Untuk komponen kawalan tersuai, pembersihan boleh dilakukan dalam kaedah musnah.

Untuk maklumat lanjut tentang pembetulan masalah memori, pergi ke dokumentasi pembangun Edge ini.

Alat yang anda boleh gunakan untuk menjadikan aplikasi berfungsi dengan baik

Bahagian ini menerangkan alat yang boleh membantu anda memahami isu prestasi dan memberi pengesyoran tentang cara mengoptimumkan penyesuaian anda dalam aplikasi berpandukan model.

Cerapan prestasi

Wawasan prestasi ialah alat layan diri untuk pembuat aplikasi perusahaan yang menganalisis data telemetri masa jalan dan menyediakan senarai keutamaan pengesyoran untuk membantu meningkatkan prestasi aplikasi berpandukan model. Ciri ini menyediakan set wawasan analisis harian yang berkaitan dengan prestasi Power Apps berpandukan model atau aplikasi customer engagement, seperti Dynamics 365 Sales atau Perkhidmatan Dynamics 365, dengan pengesyoran dan item yang boleh diambil tindakan. Pembuat aplikasi perusahaan boleh melihat wawasan prestasi terperinci pada peringkat aplikasi dalam Power Apps. Maklumat lanjut: Apakah wawasan prestasi? (pratonton)

Penyemak penyelesaian

Penyemak penyelesaian ialah alat yang berkuasa yang boleh menganalisis penyesuaian klien dan pelayan untuk isu prestasi atau kebolehpercayaan. Ia boleh menghuraikan JavaScript bahagian klien, XML borang dan pasang masuk bahagian pelayan .NET dan memberi wawasan yang disasarkan punca yang mungkin melambatkan pengguna akhir. Kami mengesyorkan anda menjalankan penyemak penyelesaian setiap kali anda menerbitkan perubahan dalam persekitaran pembangunan, supaya sebarang kebimbangan prestasi timbul sebelum menjangkau pengguna akhir. Maklumat lanjut: Gunakan penyemak penyelesaian untuk mengesahkan aplikasi dipacu model anda dalam Power Apps

Beberapa contoh isu berkaitan dengan prestasi yang ditemui dengan penyemak penyelesaian:

Penyemak objek

Penyemak objek menjalankan diagnostik masa nyata pada objek komponen dalam penyelesaian anda. Jika isu dikesan, pengesyoran dikembalikan yang menerangkan cara untuk membetulkan isu. Maklumat lanjut: Gunakan penyemak objek untuk mendiagnosis komponen penyelesaian (pratonton)

Langkah-langkah berikutnya

Reka bentuk borang utama yang produktif dalam aplikasi berpandukan model