ฟอร์มการออกแบบสำหรับประสิทธิภาพการทำงานในแอปแบบจำลอง

การสร้างประสบการณ์ที่สามารถทำงานให้เสร็จได้อย่างรวดเร็วและมีประสิทธิภาพเป็นสิ่งสำคัญต่อความพึงพอใจของผู้ใช้ แอปแบบจำลองสามารถปรับแต่งได้อย่างมากเพื่อสร้างประสบการณ์ที่ตรงกับความต้องการของผู้ใช้ของคุณ แต่สิ่งสำคัญคือต้องรู้วิธีเขียนโค้ด สร้าง และเรียกใช้แอปแบบจำลองอย่างมีประสิทธิภาพ ซึ่งจะโหลดได้อย่างรวดเร็วเมื่อผู้ใช้เปิดและนำทางในแอปของคุณขณะทำงานประจำวัน ประสิทธิภาพได้รับการแสดงว่าเป็นตัวขับเคลื่อนหลักของความไม่พอใจของแอปเมื่อไม่ได้รับการปรับให้เหมาะสมสำหรับประสิทธิภาพ

การปรับแต่งอย่างชาญฉลาดและฟอร์มที่มีประสิทธิภาพเป็นส่วนสำคัญในการสร้างฟอร์มที่มีประสิทธิภาพและมีประสิทธิผลสูง สิ่งสำคัญคือต้องแน่ใจว่าคุณกำลังสร้างฟอร์มที่มีประสิทธิผลสูงด้วยแนวทางปฏิบัติที่ดีที่สุดในการออกแบบและเค้าโครงส่วนติดต่อผู้ใช้ สำหรับข้อมูลเกี่ยวกับการออกแบบฟอร์มเพื่อประสิทธิภาพและประสิทธิผล โปรดดูที่ ออกแบบฟอร์มหลักที่มีประสิทธิผลในแอปแบบจำลอง

สิ่งสำคัญคือต้องแน่ใจว่าผู้ใช้ใช้อุปกรณ์ที่แนะนำและรองรับและมีคุณสมบัติขั้นต่ำที่จำเป็น ข้อมูลเพิ่มเติม: เว็บเบราว์เซอร์และอุปกรณ์เคลื่อนที่ที่รองรับ

การทำงานกับข้อมูลและแท็บ

ส่วนนี้ครอบคลุมถึงวิธีที่ตัวควบคุมที่แสดงข้อมูลและแท็บส่งผลต่อประสิทธิภาพของฟอร์ม

ความสำคัญของแท็บเริ่มต้น

แท็บเริ่มต้นคือแท็บขยายแรกในฟอร์ม ซึ่งมีบทบาทพิเศษในการโหลดหน้าฟอร์ม ตามการออกแบบ ตัวควบคุมของแท็บเริ่มต้นจะแสดงเสมอเมื่อเปิดเรกคอร์ด โดยเฉพาะอย่างยิ่ง ตรรกะการเริ่มต้นการควบคุม เช่น การดึงข้อมูล จะถูกเรียกใช้สำหรับการควบคุมทั้งหมดบนแท็บ

ในทางตรงกันข้าม แท็บรองไม่ได้ดำเนินการเตรียมใช้งานนี้บนตัวควบคุมเมื่อโหลดฟอร์มในขั้นต้น แต่การเริ่มต้นการควบคุมจะเกิดขึ้นในขณะที่เปิดแท็บรองผ่านการโต้ตอบของผู้ใช้หรือการเรียกใช้วิธีการ API ไคลเอ็นต์ของ setFocus สิ่งนี้ให้โอกาสในการปกป้องการโหลดฟอร์มเริ่มต้นจากการประมวลผลการควบคุมที่มากเกินไปโดยการวางการควบคุมบางอย่างในแท็บรองแทนที่จะเป็นแท็บเริ่มต้น ดังนั้น กลยุทธ์การจัดตำแหน่งการควบคุมสามารถมีผลอย่างมากต่อการตอบสนองของการโหลดฟอร์มเริ่มต้น แท็บเริ่มต้นที่ตอบสนองมากขึ้นจะมอบประสบการณ์โดยรวมที่ดีขึ้นสำหรับการแก้ไขฟิลด์ที่สำคัญ การโต้ตอบกับแถบคำสั่ง และการสำรวจแท็บและส่วนอื่นๆ

วางตัวควบคุมที่ใช้บ่อยที่สุดไว้ที่ด้านบนสุดของแท็บเริ่มต้นเสมอ เค้าโครงและสถาปัตยกรรมข้อมูลไม่เพียงมีความสำคัญต่อประสิทธิภาพเท่านั้น แต่ยังช่วยปรับปรุงประสิทธิภาพการทำงานเมื่อผู้ใช้โต้ตอบกับข้อมูลในฟอร์มด้วย ข้อมูลเพิ่มเติม: ออกแบบฟอร์มหลักที่มีประสิทธิผลในแอปแบบจำจอง

ตัวควบคุมที่ขับเคลื่อนด้วยข้อมูล

ตัวควบคุมที่ต้องใช้ข้อมูลเพิ่มเติมนอกเหนือจากเรกคอร์ดหลักทำให้เกิดการตอบสนองของฟอร์มและความเร็วในการโหลดมากที่สุด ตัวควบคุมเหล่านี้ดึงข้อมูลผ่านเครือข่ายและมักเกี่ยวข้องกับระยะเวลารอ (ถือเป็นตัวบ่งชี้ความคืบหน้า) เนื่องจากอาจใช้เวลาในการส่งข้อมูล

ตัวควบคุมที่ขับเคลื่อนด้วยข้อมูลบางส่วน ได้แก่:

• ฟอร์มแสดงผลแบบด่วน
• Sub-Grid
• ไทม์ไลน์
• ผู้ช่วย (ต้องใช้ Dynamics 365 Sales Insights)

เก็บเฉพาะตัวควบคุมที่ใช้บ่อยที่สุดบนแท็บเริ่มต้น ตัวควบคุมที่ขับเคลื่อนด้วยข้อมูลที่เหลือควรถูกแจกจ่ายไปยังแท็บรองเพื่อให้โหลดแท็บเริ่มต้นได้อย่างรวดเร็ว นอกจากนี้ กลยุทธ์การจัดวางนี้ยังช่วยลดโอกาสในการดึงข้อมูลที่ไม่ได้ใช้งานด้วย

มีตัวควบคุมอื่น ๆ ที่ส่งผลกระทบน้อยกว่าตัวควบคุมที่ขับเคลื่อนด้วยข้อมูล แต่ยังคงสามารถเข้าร่วมในกลยุทธ์การจัดวางด้านบนเพื่อให้ได้ประสิทธิภาพที่ดีที่สุด ตัวควบคุมเหล่านี้ได้แก่:

• การค้นหา
• iFrame
• ทรัพยากรบนเว็บ

เว็บเบราว์เซอร์

ส่วนนี้ครอบคลุมแนวปฏิบัติที่ดีในการใช้งานกับเว็บเบราว์เซอร์

อย่าเปิดหน้าต่างใหม่

วิธีการ API ไคลเอ็นต์ของ openForm อนุญาตให้ตัวเลือกพารามิเตอร์แสดงฟอร์มในหน้าต่างใหม่ อย่าใช้พารามิเตอร์นี้หรือตั้งค่าเป็นเท็จ การตั้งค่าเป็นเท็จจะทำให้วิธีการ openForm ดำเนินการการทำงานเริ่มต้นของการแสดงฟอร์มโดยใช้หน้าต่างที่มีอยู่ นอกจากนี้ยังสามารถเรียกใช้ฟังก์ชัน JavaScript window.open ได้โดยตรงจากสคริปต์ที่กำหนดเองหรือแอปพลิเคชันอื่น อย่างไรก็ตามควรหลีกเลี่ยงสิ่งนี้ด้วย การเปิดหน้าต่างใหม่หมายความว่าต้องดึงทรัพยากรของหน้าทั้งหมดและโหลดตั้งแต่เริ่มต้น เนื่องจากหน้าไม่สามารถใช้ประโยชน์จากความสามารถในการแคชข้อมูลในหน่วยความจำระหว่างฟอร์มที่โหลดก่อนหน้านี้และฟอร์มในหน้าต่างใหม่ได้ เพื่อเป็นทางเลือกในการเปิดหน้าต่างใหม่ ให้พิจารณาใช้ประสบการณ์แบบหลายเซสชันที่อนุญาตให้เปิดเรกคอร์ดในหลายแท็บในขณะที่ยังเพิ่มประโยชน์ด้านประสิทธิภาพของการแคชไคลเอนต์ให้สูงสุด

ใช้เบราว์เซอร์ที่ทันสมัย

การใช้เว็บเบราว์เซอร์ที่อัปเดตล่าสุดเป็นกุญแจสำคัญในการทำให้แอปแบบจำลองของคุณทำงานได้อย่างรวดเร็วที่สุด เหตุผลก็คือการปรับปรุงประสิทธิภาพหลายอย่างสามารถใช้ได้ในเบราว์เซอร์รุ่นใหม่ ๆ เท่านั้น

ตัวอย่างเช่น หากองค์กรของคุณมี Firefox รุ่นเก่า เบราว์เซอร์ที่ไม่ใช้ Chromium และอื่น ๆ ประสิทธิภาพที่เพิ่มขึ้นมากมายที่สร้างขึ้นในแอปแบบจำลองจะไม่สามารถใช้ได้ในเบราว์เซอร์รุ่นเก่า เนื่องจากไม่รองรับคุณสมบัติที่แอปต้องพึ่งพาเพื่อให้ทำงานได้อย่างรวดเร็ว และราบรื่น

ในกรณีส่วนใหญ่ คุณสามารถคาดหวังได้ว่าจะเห็นการปรับปรุงการโหลดหน้าเว็บโดยเพียงแค่เปลี่ยนไปใช้ Microsoft Edge อัปเดตเป็นเบราว์เซอร์รุ่นล่าสุดจากรุ่นเก่า หรือย้ายไปยังเบราว์เซอร์ที่ใช้ Chromium รุ่นใหม่

การปรับแต่ง JavaScript

ส่วนนี้ครอบคลุมถึงวิธีการปรับแต่งอย่างชาญฉลาดเมื่อคุณใช้ JavaScript ที่ช่วยคุณสร้างฟอร์มและหน้าที่มีประสิทธิภาพในแอปแบบจำลอง

การใช้ JavaScript กับฟอร์ม

ความสามารถในการปรับแต่งฟอร์มโดย JavaScript ทำให้นักพัฒนามืออาชีพมีความยืดหยุ่นอย่างมากในรูปลักษณ์และการทำงานของฟอร์ม การใช้ความยืดหยุ่นนี้อย่างไม่เหมาะสมอาจส่งผลเสียต่อประสิทธิภาพของฟอร์ม นักพัฒนาควรใช้กลยุทธ์ต่อไปนี้เพื่อเพิ่มประสิทธิภาพฟอร์มสูงสุดเมื่อใช้การปรับแต่ง JavaScript

ใช้คำขอเครือข่ายแบบอะซิงโครนัสเมื่อร้องขอข้อมูล

ควรขอข้อมูลแบบอะซิงโครนัสมากกว่าแบบซิงโครนัสเมื่อจำเป็นต้องมีข้อมูลเพิ่มเติมสำหรับการปรับแต่ง สำหรับเหตุการณ์ที่รองรับการรอโค้ดแบบอะซิงโครนัส เช่น เหตุการณ์ฟอร์ม OnLoad และฟอร์ม OnSave ตัวจัดการเหตุการณ์ควรส่งคืน Promise เพื่อให้แพลตฟอร์มรอจนกว่า Promise ได้รับการดำเนินการ แพลตฟอร์มจะแสดง UI ที่เหมาะสมในขณะที่ผู้ใช้รอให้เหตุการณ์เสร็จสิ้น

สำหรับเหตุการณ์ที่ไม่รองรับการรอโค้ดแบบอะซิงโครนัส เช่น เหตุการณ์ฟอร์ม OnChange คุณสามารถใช้วิธีแก้ปัญหาเพื่อหยุดการโต้ตอบกับฟอร์มในขณะที่โค้ดกำลังทำการร้องขอแบบอะซิงโครนัสโดยใช้ showProgressIndicator วิธีนี้ดีกว่าการใช้คำขอแบบซิงโครนัสเนื่องจากผู้ใช้จะยังสามารถโต้ตอบกับส่วนอื่น ๆ ของแอปพลิเคชันได้เนื่องจากมีการแสดงตัวบ่งชี้ความคืบหน้า

ต่อไปนี้คือตัวอย่างการใช้โค้ดอะซิงโครนัสในจุดส่วนขยายแบบซิงโครนัส

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

คุณควรระมัดระวังเมื่อใช้โค้ดแบบอะซิงโครนัสในตัวจัดการเหตุการณ์ที่ไม่สนับสนุนการรอโค้ดแบบอะซิงโครนัส โดยเฉพาะอย่างยิ่งสำหรับโค้ดที่ต้องการการดำเนินการหรือจัดการกับความละเอียดของโค้ดแบบอะซิงโครนัส รหัสแบบอะซิงโครนัสอาจทำให้เกิดปัญหาได้หากตัวจัดการความละเอียดคาดว่าบริบทของแอปพลิเคชันจะยังคงเหมือนเดิมเมื่อเริ่มต้นรหัสแบบอะซิงโครนัส รหัสของคุณควรตรวจสอบว่าผู้ใช้อยู่ในบริบทเดียวกันหลังจากจุดต่อเนื่องแบบอะซิงโครนัสแต่ละจุด

ตัวอย่างเช่น อาจมีรหัสในตัวจัดการเหตุการณ์เพื่อส่งคำขอเครือข่ายและเปลี่ยนตัวควบคุมที่จะปิดใช้งานตามข้อมูลการตอบสนอง ก่อนได้รับการตอบสนองจากคำขอ ผู้ใช้อาจโต้ตอบกับตัวควบคุมหรือนำทางไปยังหน้าอื่น เนื่องจากผู้ใช้อยู่ในหน้าอื่น บริบทของฟอร์มอาจไม่พร้อมใช้งาน ซึ่งอาจนำไปสู่ข้อผิดพลาด หรืออาจมีลักษณะการทำงานที่ไม่ต้องการอื่นๆ

การสนุบสนุนแบบอะซิงโครนัสในเหตุการณ์ฟอร์ม OnLoad และฟอร์ม OnSave

เหตุการณ์ฟอร์ม OnLoad และ OnSave สนับสนุนตัวจัดการที่ส่งคืนคำสัญญา เหตุการณ์จะรอให้คำสัญญาใด ๆ ที่ตัวจัดการส่งคืนเพื่อแก้ไข จนถึงช่วงหมดเวลา การสนับสนุนนี้สามารถเปิดใช้งานได้ผ่านการตั้งค่าแอป

ข้อมูลเพิ่มเติม:

• ฟอร์ม OnLoad
• ฟอร์ม OnSave
• โต้ตอบกับทรัพยากร HTTP และ HTTPS แบบอะซิงโครนัส

จำกัดจำนวนข้อมูลที่ร้องขอระหว่างการโหลดฟอร์ม

ขอเฉพาะจำนวนข้อมูลขั้นต่ำที่จำเป็นต่อการใช้ตรรกะทางธุรกิจในฟอร์มเท่านั้น แคชข้อมูลที่ร้องขอให้มากที่สุด โดยเฉพาะอย่างยิ่งสำหรับข้อมูลที่ไม่เปลี่ยนแปลงบ่อยหรือไม่จำเป็นต้องใหม่ ตัวอย่างเช่น สมมติว่ามีฟอร์มที่ขอข้อมูลจากตาราง การตั้งค่า ตามข้อมูลในตารางการตั้งค่า ฟอร์มอาจเลือกที่จะซ่อนส่วนของฟอร์ม ในกรณีนี้ JavaScript สามารถแคชข้อมูลใน sessionStorage เพื่อให้มีการขอข้อมูลเพียงครั้งเดียวต่อเซสชัน (onLoad1) อาจมีการใช้กลยุทธ์เก่าในขณะตรวจสอบใหม่โดยที่ JavaScript ใช้ข้อมูลจาก sessionStorage ขณะขอข้อมูลสำหรับการนำทางถัดไปไปยังฟอร์ม (onLoad2) สุดท้าย สามารถใช้กลยุทธ์การลบข้อมูลซ้ำซ้อนในกรณีที่มีการเรียกตัวจัดการหลายครั้งติดต่อกัน (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   
    }
}

ใช้ข้อมูลที่มีอยู่ใน API ไคลเอนต์ แทนที่จะส่งคำขอ ตัวอย่างเช่น แทนที่จะขอบทบาทความปลอดภัยของผู้ใช้ในการโหลดฟอร์ม คุณสามารถใช้ getGlobalContext.userSettings.roles

โหลดโค้ดเมื่อจำเป็นเท่านั้น

โหลดโค้ดได้มากเท่าที่จำเป็นสำหรับเหตุการณ์สำหรับฟอร์มเฉพาะ หากคุณมีโค้ดสำหรับ ฟอร์ม A และ ฟอร์ม B เท่านั้น ไม่ควรรวมไว้ในไลบรารีที่โหลดไว้สำหรับ ฟอร์ม C ควรอยู่ในไลบรารีของตัวเอง

หลีกเลี่ยงการโหลดไลบรารี่ในเหตุการณ์ OnLoad ถ้าใช้สำหรับเหตุการณ์ OnChange หรือ OnSave เท่านั้น ให้โหลดในเหตุการณ์เหล่านั้นแทน วิธีนี้ทำให้แพลตฟอร์มสามารถเลื่อนเวลาโหลดได้จนกว่าจะโหลดฟอร์ม ข้อมูลเพิ่มเติม: เพิ่มประสิทธิภาพฟอร์ม

ลบการใช้งานคอนโซล API ในรหัสการผลิต

อย่าใช้ วิธีการ API ของคอนโซล เช่น console.log ในรหัสการผลิต การบันทึกข้อมูลไปยังคอนโซลสามารถเพิ่มความต้องการหน่วยความจำได้อย่างมาก และอาจป้องกันไม่ให้ข้อมูลถูกล้างข้อมูลในหน่วยความจำ การทำเช่นนี้อาจทำให้แอปทำงานช้าลงเมื่อเวลาผ่านไปและหยุดทำงานในที่สุด

หลีกเลี่ยงหน่วยความจำรั่ว

หน่วยความจำรั่วในโค้ดของคุณอาจทำให้ประสิทธิภาพการทำงานช้าลงเมื่อเวลาผ่านไป และทำให้แอปของคุณขัดข้องในที่สุด หน่วยความจำรั่วเกิดขึ้นเมื่อแอปพลิเคชันล้มเหลวในการปล่อยหน่วยความจำเมื่อไม่ต้องการอีกต่อไป สำหรับการปรับแต่งและส่วนประกอบโค้ดทั้งหมดในฟอร์มของคุณ คุณควร:

• พิจารณาและทดสอบสถานการณ์อย่างถี่ถ้วนสำหรับสิ่งใดก็ตามที่มีหน้าที่ทำความสะอาดหน่วยความจำ เช่น คลาสที่รับผิดชอบในการจัดการวงจรชีวิตของออบเจ็กต์
• ล้างตัวรอรับเหตุการณ์และการสมัครใช้งานทั้งหมด โดยเฉพาะอย่างยิ่งหากอยู่ในออบเจ็กต์ window
• ล้างตัวจับเวลาทั้งหมด เช่น setInterval
• หลีกเลี่ยง จำกัด และล้างข้อมูลอ้างอิงไปยังออบเจ็กต์ส่วนกลางหรือแบบคงที่

สำหรับส่วนประกอบตัวควบคุมแบบกำหนดเอง การล้างสามารถทำได้ด้วยวิธีการ ทำลาย

สำหรับข้อมูลเพิ่มเติมเกี่ยวกับการแก้ไขปัญหาหน่วยความจำ ไปที่ คู่มือสำหรับนักพัฒนา Edge นี้

เครื่องมือที่คุณสามารถใช้เพื่อช่วยให้แอปทำงานได้อย่างมีประสิทธิภาพ

ส่วนนี้อธิบายเครื่องมือที่สามารถช่วยให้คุณเข้าใจปัญหาด้านประสิทธิภาพและเสนอคำแนะนำเกี่ยวกับวิธีการปรับแต่งของคุณให้เหมาะสมในแอปแบบจำลอง

ข้อมูลเชิงลึกด้านประสิทธิภาพ

ข้อมูลเชิงลึกด้านประสิทธิภาพเป็นเครื่องมือแบบบริการตนเองสำหรับผู้สร้างแอประดับองค์กรที่วิเคราะห์ข้อมูลการตรวจวัดระยะไกลรันไทม์และจัดเตรียมรายการคำแนะนำตามลำดับความสำคัญเพื่อช่วยปรับปรุงประสิทธิภาพของแอปแบบจำลอง คุณลักษณะนี้ให้ชุดข้อมูลเชิงลึกเกี่ยวกับการวิเคราะห์รายวันที่เกี่ยวข้องกับประสิทธิภาพของแอปแบบจำลอง Power Apps หรือแอปการมีส่วนร่วมกับลูกค้า เช่น Dynamics 365 Sales หรือ Dynamics 365 Service พร้อมคำแนะนำและรายการที่สามารถดำเนินการได้ ผู้สร้างแอประดับองค์กรสามารถดูข้อมูลเชิงลึกด้านประสิทธิภาพโดยละเอียดได้ที่ระดับแอปใน Power Apps ข้อมูลเพิ่มเติม: ข้อมูลเชิงลึกด้านประสิทธิภาพคืออะไร (ตัวอย่าง)

ตัวตรวจสอบโซลูชัน

ตัวตรวจสอบโซลูชันเป็นเครื่องมือที่ทรงพลังที่สามารถวิเคราะห์การปรับแต่งไคลเอนต์และเซิร์ฟเวอร์สำหรับปัญหาด้านประสิทธิภาพหรือความน่าเชื่อถือ ซึ่งสามารถแยกวิเคราะห์ JavaScript ฝั่งไคลเอ็นต์ ฟอร์ม XML และปลั๊กอินฝั่งเซิร์ฟเวอร์ .NET และให้ข้อมูลเชิงลึกที่ตรงเป้าหมายในสิ่งที่อาจทำให้ผู้ใช้ปลายทางช้าลง เราขอแนะนำให้คุณเรียกใช้ตัวตรวจสอบโซลูชันทุกครั้งที่คุณเผยแพร่การเปลี่ยนแปลงในสภาพแวดล้อมการพัฒนา เพื่อให้ข้อกังวลด้านประสิทธิภาพปรากฏขึ้นก่อนที่จะเข้าถึงผู้ใช้ปลายทาง ข้อมูลเพิ่มเติม: ใช้ตัวตรวจสอบโซลูชันเพื่อตรวจสอบความถูกต้องแอปแบบจำลองของคุณใน Power Apps

ตัวอย่างบางส่วนของปัญหาที่เกี่ยวข้องกับประสิทธิภาพที่พบในตัวตรวจสอบโซลูชัน:

• il-ระบุคอลัมน์ หลีกเลี่ยงการเลือกคอลัมน์ทั้งหมดผ่าน API การสอบถาม ของ Dataverse
• web-use-async โต้ตอบกับทรัพยากร HTTP และ HTTPS แบบอะซิงโครนัส
• web-avoid-ui-refreshribbon หลีกเลี่ยงการใช้ refreshRibbon ในฟอร์ม OnLoad และ EnableRule

ตัวตรวจสอบวัตถุ

ตัวตรวจสอบออบเจ็กต์เรียกใช้การวินิจฉัยแบบเรียลไทม์ในออบเจ็กต์ส่วนประกอบภายในโซลูชันของคุณ หากตรวจพบปัญหา ระบบจะส่งคืนคำแนะนำที่อธิบายวิธีแก้ไขปัญหา ข้อมูลเพิ่มเติม: ใช้ตัวตรวจสอบออบเจ็กต์เพื่อวินิจฉัยส่วนประกอบของโซลูชัน (พรีวิว)

ขั้นตอนถัดไป

ออกแบบฟอร์มหลักที่มีประสิทธิผลในแอปแบบจำลอง