Il existe déjà de nombreuses façons d'optimiser NG en ligne. Le noyau est tout au sujet des attributs internes de la portée des observateurs $$. Aujourd'hui, je vais parler d'autre chose, l'essence reste inchangée parce que c'est un défaut de NG. Cependant, je crois que tant que vous utilisez des méthodes appropriées, ces problèmes peuvent encore être évités.
Introduction
AngularJS est abrégé en NG, qui est un cadre MVVM produit par Google. Cela améliore l'efficacité de développement des projets frontaux (dans la pratique, il peut en effet améliorer l'efficacité du développement). Il utilise des contrôleurs, des instructions et des services pour tourner autour de l'ensemble du projet et utilise un DI unique pour résoudre les problèmes d'appel avant la troisième couche. Pour plus de détails, veuillez vous référer à l'analyse du code source NG que j'ai écrit auparavant.
La blessure dure
En ce qui concerne les défauts, nous devons d'abord parler de son principe simple de liaison des données
Le modèle défini sur chaque page de NG ajoutera en fait un auditeur à la portée actuelle. Le conteneur interne est le tableau Wachers $$. Tant que tout modèle de la page change, la méthode $ digest à l'intérieur de la portée sera déclenchée. Il recherchera à son tour tous les modèles de la portée actuelle pour s'assurer que les modèles de la page peuvent obtenir une synchronisation des données, donc cela prend beaucoup de temps. La déclaration officielle est que lorsque 2 000 auditeurs apparaissent sur la page, les performances de la page baisseront considérablement. Par conséquent, pour améliorer les performances de NG, vous devez commencer à partir de cet aspect.
TIP1: liaison unique
En fait, quelqu'un d'autre l'a déjà dit en ligne. Voici une nouvelle utilisation. La version 1.3.0+ de NG a déjà fourni une syntaxe intégrée pour prendre en charge la situation où le modèle n'est lié qu'une seule fois. Voir l'exemple suivant:
vieux code
La copie de code est la suivante:
Bonjour
nouveau code
La copie de code est la suivante:
Bonjour
Vous pouvez voir que la nouvelle syntaxe doit ajouter :: devant le modèle. Je crois que cette syntaxe est beaucoup plus pratique que les plug-ins tiers utilisés en ligne.
La copie de code est la suivante:
TIP2: $ Scope. $ Digest vs $ Scope. $ Appliquer
Je crois que beaucoup de gens connaissent la méthode $ appliquer. Il est généralement utilisé lors de l'exécution du code dans l'environnement NG, afin de garantir la synchronisation des données de la page, appelant la méthode $ applique après l'exécution du code déclenchera le digest interne pour vérifier tous les modèles dans la portée. En fait, cela s'appelle à l'intérieur, et seuls certains extraits de code sont écrits ci-dessous.
La copie de code est la suivante:
...
...
$ rootscope. $ digest
...
...
Tous appellent réellement $ digest sous la portée racine de $ Rootscope. Alors, quelle est la différence entre $ digest sous différentes lunettes? En fait, la différence la plus importante est que
La copie de code est la suivante:
$ digest uniquement recherche tous les modèles sous l'appelant
Par conséquent, par rapport à $ Scope, $ Rootscope, il fait gagner beaucoup de temps pour trouver des modèles.
Cependant, si vous souhaitez assurer la synchronisation de toutes les données du modèle sur la page, vous devez toujours appeler $ Rootscope, il est donc préférable de réfléchir aux données doit être synchronisée avant d'écrire le code.
TIP3: Appelez Ng-Repeat le moins possible
NG-Repeat créera de nombreux auditeurs par défaut, donc lorsque le volume de données est grand, cela consomme des performances de page. Je pense que NG-Repeat n'est nécessaire que lorsque vous devez mettre à jour la liste des données fréquemment, sinon ce serait un gaspillage d'y mettre autant d'auditeurs. À l'heure actuelle, vous pouvez utiliser le propre service Interpolate de NG pour analyser un extrait de code, similaire à un moteur de modèle statique, qui s'appuie principalement sur le service d'analyse de base de NG $ Parse, puis attribuer directement ces extraits de code après avoir rempli les données à un modèle unique.
TIP4: Essayez d'écrire la syntaxe native dans la commande
Bien que NG fournit de nombreuses instructions telles que NG-Show et Ng-Hide, leur fonction est d'afficher ou de masquer un extrait de code basé sur le vrai et le faux du modèle. Bien qu'il puisse rapidement implémenter les exigences de l'entreprise, ces instructions ajouteront toujours des auditeurs par défaut. Si ces extraits de code existent dans une grande instruction, la meilleure façon est d'écrire des méthodes JQ similaires telles que .show () et .hide () dans le lien d'instructions pour le contrôler, ce qui peut enregistrer le nombre d'auditeurs et des instructions d'événements similaires. Ceux-ci peuvent réellement lier des événements dans des instructions périphériques en utilisant AddeveventListener. Quoi qu'il en soit, avant d'écrire du code, il est préférable de réfléchir à la façon de minimiser le nombre d'auditeurs, afin que les performances de la page puissent être améliorées.
TIP5: Utilisez les filtres le moins possible sur la page
Lors de l'ajout de filtres derrière le modèle de la page, cela entraînera l'exécution du modèle actuel deux fois dans $ digest, provoquant des déchets de performances inutiles. La première fois, c'est quand la tâche de détection des observateurs $$ change; La deuxième fois se produit lorsque la valeur du modèle est modifiée, alors essayez d'utiliser la syntaxe du filtre lorsque vous en lignez le moins possible. Comme ce qui suit affecte considérablement les performances de la page
Il est recommandé d'utiliser le service de filtre $ pour appeler une fonction de filtre en arrière-plan, ce qui peut améliorer considérablement les performances de la page. Le code est le suivant
La copie de code est la suivante:
$ filtre ('filtre') (tableau, expression, comparateur);
Résumer
Ce qui précède est quelques conseils pour améliorer les performances des projets NG. Bien que NG soit très puissant, le code irrégulier détruira également ses performances. Par conséquent, il est préférable de réfléchir à l'endroit où les auditeurs ne sont pas nécessaires avant d'écrire du code.