Share via

Σχεδίαση φορμών για επιδόσεις σε εφαρμογές που καθορίζονται από μοντέλα

  • Άρθρο

Η δημιουργία εμπειριών όπου οι εργασίες μπορούν να ολοκληρωθούν γρήγορα και αποτελεσματικά είναι ιδιαίτερα σημαντική για την ικανοποίηση των χρηστών. Οι εφαρμογές που καθορίζονται από μοντέλο μπορούν να προσαρμοστούν σε μεγάλο βαθμό για να δημιουργήσουν εμπειρίες που ανταποκρίνονται στις ανάγκες των χρηστών σας, αλλά είναι σημαντικό να γνωρίζετε πώς να δημιουργείτε κώδικα αποτελεσματικά, να δημιουργείτε και να εκτελείτε εφαρμογές που καθοδηγούνται από μοντέλο, οι οποίες φορτώνονται γρήγορα όταν ένας χρήστης ανοίγει και μεταβαίνει στην εφαρμογή σας ενώ εργάζεται σε καθημερινές εργασίες. Η απόδοση έχει αποδειχθεί ότι αποτελεί βασικό κριτήριο δυσαρέσκειας από μια εφαρμογή όταν δεν είναι βελτιστοποιημένη για τις επιδόσεις.

Οι ευφυείς προσαρμογές και οι φόρμες με τις επιδόσεις είναι σημαντικές πτυχές για τη δημιουργία εξαιρετικά αποτελεσματικών και παραγωγικών φορμών. Επίσης, είναι σημαντικό να βεβαιωθείτε ότι δημιουργείτε εξαιρετικά παραγωγικές φόρμες με τις βέλτιστες πρακτικές στη σχεδίαση και τη διάταξη του περιβάλλοντος εργασίας χρήστη. Για πληροφορίες σχετικά με το σχεδιασμό φορμών για αποτελεσματικότητα και παραγωγικότητα, ανατρέξτε στο θέμα Σχεδίαση παραγωγικών κύριων φορμών σε εφαρμογές που καθορίζονται από μοντέλο.

Είναι επίσης σημαντικό να εξασφαλίσετε ότι οι χρήστες χρησιμοποιούν συνιστώμενες και υποστηριζόμενες συσκευές και τις ελάχιστες απαιτούμενες προδιαγραφές. Περισσότερες πληροφορίες: Υποστηριζόμενα προγράμματα περιήγησης και κινητές συσκευές

Εργασία με δεδομένα και καρτέλες

Αυτή η ενότητα καλύπτει τον τρόπο με τον οποίο τα στοιχεία ελέγχου που εμφανίζουν δεδομένα και καρτέλες, επηρεάζουν την απόδοση των φορμών.

Σημασία της προεπιλεγμένης καρτέλας

Η προεπιλεγμένη καρτέλα είναι η πρώτη αναπτυγμένη καρτέλα σε μια φόρμα. Παίζει ειδικό ρόλο στη φόρτωση μιας σελίδας φόρμας. Από σχεδίαση, τα στοιχεία ελέγχου της προεπιλεγμένης καρτέλας αποδίδονται πάντα κατά το άνοιγμα μιας καρτέλας. Συγκεκριμένα, η λογική προετοιμασίας του στοιχείου ελέγχου, όπως η ανάκτηση δεδομένων, καλείται για κάθε στοιχείο ελέγχου στην καρτέλα.

Αντίθετα, μια δευτερεύουσα καρτέλα δεν εκτελεί αυτήν την προετοιμασία στα στοιχεία ελέγχου της κατά την αρχική φόρτωση της φόρμας. Αντ' αυτού, η προετοιμασία του στοιχείου ελέγχου πραγματοποιείται τη στιγμή που η δευτερεύουσα καρτέλα ανοίγει είτε μέσω αλληλεπίδρασης χρήστη είτε καλώντας τη μέθοδο setFocus του API του προγράμματος-πελάτη. Αυτό παρέχει την ευκαιρία να αποφορτίσει το αρχικό φόρτο εργασίας της φόρμας από την υπερβολική επεξεργασία ελέγχου, τοποθετώντας ορισμένα στοιχεία ελέγχου σε δευτερεύουσες καρτέλες αντί για την προεπιλεγμένη καρτέλα. Κατά συνέπεια, η στρατηγική τοποθέτησης ελέγχου μπορεί να επηρεάσει σημαντικά το φόρτο εργασίας του αρχικού φόρτου φόρμας. Μια προεπιλεγμένη καρτέλα με μεγαλύτερη απόκριση πρόσβασης παρέχει μια καλύτερη συνολική εμπειρία για την τροποποίηση σημαντικών πεδίων, την αλληλεπίδραση με τη γραμμή εντολών και την εξερεύνηση άλλων καρτελών και ενοτήτων.

Τοποθετείτε πάντα τα στοιχεία ελέγχου που χρησιμοποιούνται περισσότερο στην κορυφή της προεπιλεγμένης καρτέλας σας. Η αρχιτεκτονική διάταξης και πληροφοριών δεν είναι σημαντική μόνο για την απόδοση αλλά και για τη βελτίωση της παραγωγικότητας, όταν οι χρήστες αλληλεπιδρούν με δεδομένα στη φόρμα. Περισσότερες πληροφορίες: Σχεδίαση παραγωγικών κύριων φορμών σε εφαρμογές που καθορίζονται από μοντέλο

Στοιχεία ελέγχου που καθορίζονται από δεδομένα

Τα στοιχεία ελέγχου που απαιτούν επιπλέον δεδομένα εκτός από την κύρια καρτέλα παράγουν τη μεγαλύτερη επιβάρυνση ως προς τη διαμόρφωση και την ταχύτητα φόρτωσης. Αυτά τα στοιχεία ελέγχου λαμβάνουν δεδομένα μέσω του δικτύου και περιλαμβάνουν συχνά μια περίοδο αναμονής (που φαίνεται ως δείκτες προόδου), επειδή μπορεί να διαρκέσει η μεταφορά των δεδομένων.

Ορισμένα από τα στοιχεία ελέγχου που καθορίζονται από δεδομένα περιλαμβάνουν:

Διατηρήστε μόνο τα πιο συχνά χρησιμοποιούμενα από αυτά τα στοιχεία ελέγχου στην προεπιλεγμένη καρτέλα. Τα υπόλοιπα στοιχεία ελέγχου που καθορίζονται από δεδομένα πρέπει να κατανέμονται σε δευτερεύουσες καρτέλες, ώστε να είναι δυνατή η γρήγορη φόρτωση της προεπιλεγμένης καρτέλας. Επιπλέον, αυτή η στρατηγική διάταξης μειώνει τις πιθανότητες λήψης δεδομένων που στο τέλος δεν θα χρησιμοποιούνται.

Υπάρχουν άλλα στοιχεία ελέγχου που επηρεάζουν λιγότερο από τα στοιχεία ελέγχου που καθορίζονται από τα δεδομένα, αλλά μπορούν ακόμα να συμμετάσχουν στην παραπάνω στρατηγική διάταξης προκειμένου να πετύχετε τη βέλτιστη απόδοση. Αυτά τα στοιχεία ελέγχου περιλαμβάνουν τα εξής:

Πρόγραμμα περιήγησης στο Web

Αυτή η ενότητα καλύπτει βέλτιστες πρακτικές για χρήση με προγράμματα περιήγησης στο Web.

Μην ανοίγετε νέα παράθυρα

Η μέθοδος API του προγράμματος-πελάτη openForm επιτρέπει σε μια επιλογή παραμέτρου την εμφάνιση μιας φόρμας σε ένα νέο παράθυρο. Μην χρησιμοποιείτε αυτήν την παράμετρο ή ορίζετέ την σε false. Ο ορισμός της σε false θα εξασφαλίσει ότι η μέθοδος openFormεκτελεί την προεπιλεγμένη συμπεριφορά εμφάνισης της φόρμας χρησιμοποιώντας το υπάρχον παράθυρο. Επίσης, είναι δυνατό να καλέσετε απευθείας τη συνάρτηση JavaScript window.open από μια προσαρμοσμένη δέσμη ενεργειών ή άλλη εφαρμογή. Ωστόσο, και αυτό θα πρέπει να αποφεύγεται. Εάν ανοίξετε ένα νέο παράθυρο, θα πρέπει να γίνει ανάκτηση και φόρτωση όλων των πόρων της σελίδας από την αρχή, καθώς η σελίδα δεν μπορεί να χρησιμοποιήσει τις δυνατότητες προσωρινής μνήμης των δεδομένων στη μνήμη μεταξύ μιας φόρμας που φορτώνεται προηγουμένως και της φόρμας σε ένα νέο παράθυρο. Ως εναλλακτική λύση για το άνοιγμα νέων παραθύρων, εξετάστε το ενδεχόμενο να χρησιμοποιήσετε την εμπειρία πολλαπλής αποθήκευσης που επιτρέπει το άνοιγμα καρτελών σε πολλές καρτέλες, ενώ παράλληλα να μεγιστοποιείται η απόδοση των πλεονεκτημάτων από την προσωρινή αποθήκευση των προγραμμάτων-πελατών.

Χρήση σύγχρονων προγραμμάτων περιήγησης

Η χρήση του πιο ενημερωμένου προγράμματος περιήγησης web είναι σημαντική για να διασφαλιστεί ότι η εφαρμογή που καθορίζεται από το μοντέλο θα εκτελείται το συντομότερο δυνατό. Ο λόγος για αυτό είναι ότι πολλές από τις βελτιώσεις απόδοσης μπορούν να χρησιμοποιηθούν μόνο στα νεότερα σύγχρονα προγράμματα περιήγησης.

Για παράδειγμα, εάν ο οργανισμός σας διαθέτει παλαιότερες εκδόσεις προγραμμάτων περιήγησης Firefox που δεν βασίζονται σε Chromium κ.λπ., πολλές από τις δυνατότητες απόδοσης που είναι ενσωματωμένες σε μια εφαρμογή που καθορίζεται από μοντέλο δεν θα είναι διαθέσιμες στις παλαιότερες εκδόσεις του προγράμματος περιήγησης, επειδή δεν υποστηρίζουν δυνατότητες από τις οποία εξαρτάται η εφαρμογή για να εκτελείται γρήγορα και ομαλά.

Στις περισσότερες περιπτώσεις, μπορείτε να περιμένετε να δείτε βελτιώσεις φόρτου σελίδας απλώς μεταβαίνοντας στο Microsoft Edge, ενημερώνοντας στην πιο πρόσφατη τρέχουσα έκδοση του προγράμματος περιήγησης από μια παλαιότερη έκδοση ή μεταβαίνοντας σε ένα σύγχρονο πρόγραμμα περιήγησης που βασίζεται σε Chromium.

Προσαρμογή JavaScript

Αυτή η ενότητα καλύπτει τον τρόπο με τον οποίο μπορείτε να κάνετε έξυπνες προσαρμογές όταν χρησιμοποιείτε JavaScript που σας βοηθούν να δημιουργείτε φόρμες και σελίδες με επιδόσεις σε μια εφαρμογή που καθορίζεται από μοντέλο.

Χρήση της JavaScript με φόρμες

Η δυνατότητα προσαρμογής των φορμών μέσω JavaScript παρέχει στους επαγγελματίες προγραμματιστές μεγάλη ευελιξία ως προς την εμφάνιση και τη συμπεριφορά μιας φόρμας. Η εσφαλμένη χρήση αυτής της ευελιξίας μπορεί να επηρεάσει αρνητικά την απόδοση των φορμών. Οι προγραμματιστές θα πρέπει να χρησιμοποιήσουν τις παρακάτω στρατηγικές για να μεγιστοποιήσουν την απόδοση των φορμών κατά την υλοποίηση προσαρμογών JavaScript.

Χρήση ασύγχρονων αιτήσεων δικτύου κατά την αίτηση δεδομένων

Να ζητάτε δεδομένα ασύγχρονα και όχι σύγχρονα, όταν απαιτούνται επιπλέον δεδομένα για προσαρμογές. Για συμβάντα που υποστηρίζουν την αναμονή ασύγχρονου κώδικα, όπως τα συμβάντα φόρμας OnLoad και OnSave, τα πρόγραμμα χειρισμού συμβάντων θα πρέπει να επιστρέψουν μια Promise, προκειμένου η πλατφόρμα να περιμένει έως ότου τακτοποιηθεί η Promise. Η πλατφόρμα θα εμφανίζει ένα κατάλληλο περιβάλλον εργασίας χρήστη, ενώ ο χρήστης θα περιμένει να ολοκληρωθεί το συμβάν.

Για συμβάντα που δεν υποστηρίζουν την αναμονή για ασύγχρονη κώδικα, όπως το συμβάν φόρμας 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 φόρμας υποστηρίζουν χειρισμούς που επιστρέφουν υποσχέσεις. Τα συμβάντα θα περιμένουν έως την επίλυση τυχόν προβλημάτων που έχουν επιστραφεί από το δείκτη χειρισμού έως και ένα χρονικό όριο. Αυτή η υποστήριξη μπορεί να ενεργοποιηθεί μέσω των ρυθμίσεων της εφαρμογής.

Περισσότερες πληροφορίες:

Περιορισμός του ποσού των δεδομένων που ζητούνται κατά τη φόρτωση φορμών

Ζητήστε μόνο το ελάχιστο ποσό δεδομένων που είναι απαραίτητο για την εκτέλεση της επιχειρηματικής λογικής σε μια φόρμα. Να θέτετε σε cache τα δεδομένα που ζητούνται όσο το δυνατόν περισσότερο, ειδικά για δεδομένα που δεν αλλάζουν συχνά ή δεν χρειάζεται να είναι πρόσφατα. Για παράδειγμα, φανταστείτε ότι υπάρχει μια φόρμα που ζητά δεδομένα από έναν πίνακα ρύθμισης. Με βάση τα δεδομένα στον πίνακα ρύθμισης, η φόρμα μπορεί να επιλέξει να αποκρύψει μια ενότητα της φόρμας. Σε αυτή την περίπτωση, η 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 του προγράμματος-πελάτη αντί να κάνετε αιτήσεις. Για παράδειγμα, αντί να ζητήσετε τους ρόλους ασφαλείας ενός χρήστη κατά τη φόρτωση φορμών, μπορείτε να χρησιμοποιήσετε το getSettingtext.userSettings.roles.

Φόρτωση κώδικα μόνο όταν αυτό είναι απαραίτητο

Φόρτωση όσου κώδικα απαιτείται για συμβάντα για μια συγκεκριμένη φόρμα. Εάν έχετε κώδικα που είναι μόνο για τη φόρμα Α και τη φόρμα Β, δεν θα πρέπει να περιλαμβάνεται σε μια βιβλιοθήκη που φορτώνεται για τη φόρμα 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-specify-column. Αποφύγετε την επιλογή όλων των στηλών μέσω API ερωτήματος Dataverse.
  • web-use-async. Αλληλεπίδραση με πόρους HTTP και HTTPS ασύγχρονα.
  • web-avoid-ui-refreshribbon. Αποφύγετε τη χρήση refreshRibbon στη φόρμα OnLoad και στην EnableRule.

Έλεγχος αντικειμένων

Ο έλεγχος αντικειμένων εκτελεί διαγνωστικά σε πραγματικό χρόνο σε αντικείμενα στοιχείων στη λύση σας. Εάν εντοπιστούν ζητήματα, επιστρέφεται μια σύσταση που περιγράφει τον τρόπο διόρθωσης του ζητήματος. Περισσότερες πληροφορίες: Χρήση του εργαλείου ελέγχου αντικειμένων για τη διάγνωση ενός στοιχείου λύσης (προεπισκόπηση)

Επόμενα βήματα

Σχεδιάστε παραγωγικές κύριες φόρμες σε εφαρμογές που καθορίζονται από μοντέλα