Comment j'ai amélioré les performances de mon application jusqu'à

⌛ Temps de récapitulation

Dans mon dernier blog, j'ai expliqué comment j'avais réduit la taille de mon application de 75 Mo à 34 Mo en seulement 2 semaines ( Voir ! ). Mais ce n'est pas tout, j'ai également amélioré les performances globales de notre application jusqu'à 80 % ?.

Découvrez COMMENT !!

? La tradition

Après une simple visite guidée, j'ai découvert quelques-uns des principaux problèmes de notre application, conduisant à une mauvaise expérience utilisateur et à de mauvaises performances. Quelle journée !

• Méchant principal - Interface utilisateur de l'application entière gelée lors de la génération d'une réponse en temps réel

• Side Villain - Temps de réponse lent et pas de fréquence d'images

• Amant du méchant - Trop d'appels Api

• The Undead Army - Mauvaise gestion des erreurs et plantages

• Souffrances - Plus d'utilisations du processeur et de coûts de serveur

• Le Terni - MOI !

Ainsi commence une bataille sans vie pour recréer l’univers avec un espoir mondial meilleur.

Le Plan Tahiti ( Mais cette fois ça marche )

J'ai donc commencé par m'attaquer aux problèmes les plus faciles, car il est facile d'ignorer la grande dépression plutôt que de la combattre sur le moment.

1. ⚛️ Malédiction de React

La sagesse et la malédiction de ReactJs sont des états. À mesure que nous vieillissons dans React, nous réalisons que moins il y a d'états, plus l'application est meilleure. Par conséquent, cette œuvre d'art particulière utilisait 22 (oui, putain, 22 états d'utilisation) dans un seul écran de discussion où tout ce que vous pouvez faire est d'envoyer et de recevoir un message.

Cerise sur le gâteau !
Nous utilisions l'implémentation d'événements côté serveur pour obtenir des données morceau par morceau du serveur, qui, dans ce cas, étaient mot par mot. Donc, si vous aviez une requête qui a une réponse de 100 mots (C'EST LE MOINS DE RÉPONSE). Il recevra en réalité 100 événements.

Donc, si vous connaissez les calculs, 100*22 = 2200 rendus chaque fois que nous recevons une réponse.

Dois-je expliquer davantage ? ( NON )

J'ai donc commencé à recréer tout l'écran et j'ai réduit le nombre à 6 états maintenant. Avec une fonctionnalité meilleure et fluide comme avant.

C'est 72% plus performant que le précédent !!

2. ❄️ Le Désert Gelé

Maintenant, après avoir été témoin du Radahn de React, nous pouvons facilement conclure que l'application va beaucoup geler, n'est-ce pas ?

Maintenant, même avec 6 états, le problème principal reste le même : 100*6. Nous sommes toujours suspendus mais avec moins d'états.

La cause principale était de réagir en étant mis à jour sur chaque morceau. Donc, pour résoudre ce problème, nous avons utilisé "Traitement par lots et génération de fréquences d'images.

Enfer ouais !

Donc, fondamentalement, au lieu de mettre à jour le DOM à chaque fois que nous obtenions un morceau, nous créions des lots de morceaux et le mettions à jour à une fréquence d'images dynamique fixe. Ces fréquences d'images ont été appelées à partir du système d'exploitation, de sorte que chaque appareil aura un FPS différent en fonction de la capacité du système, ce qui donnera à l'application des performances plus robustes et compatibles.

Nous avons capturé un ensemble limité de morceaux dans un lot et avons conservé la réponse jusqu'à ce que la trame soit libérée et répété la même chose jusqu'à ce que tous les morceaux soient traités.

Par conséquent, au lieu de mettre à jour le DOM 100 fois, nous n'avons mis à jour le DOM que 3 à 4 fois.

Faites maintenant le calcul et calculez l'amélioration des performances pour les devoirs !

3. ? Soyez un bon auditeur !

Cela n'a pas fonctionné pour moi d'avoir une petite amie, mais cela a certainement contribué à rendre l'application bien meilleure.

Les API sont un moyen sympa et agréable d'obtenir des données, mais les utiliser judicieusement est une compétence qui vous est propre ! Maintenant, cette application utilisait cette API pour obtenir le statut de l'utilisateur depuis le backend. Mais le meilleur, c'est qu'il l'utilisait toutes les 3 secondes !!

Je comprends, le développeur avait des insécurités, mais ce n'est pas ce qu'il entendait par équilibre travail-vie personnelle.

a) Récupération

Afin d'obtenir les données utilisateur à chaque fois que l'utilisateur utilise l'application, il est nécessaire de passer l'appel au démarrage de l'application ou à chaque fois que l'application est appelée récemment (écouteur d'état de l'application). L'appeler toutes les 3 secondes utilise non seulement les ressources mobiles dans un flux infini, mais entraîne également une surcharge du serveur.

Au lieu de recevoir 100 requêtes de 100 utilisateurs, serve recevra 100 requêtes d'1 utilisateur. Cela ne me semble pas très évolutif et fiable.

De plus, cela crée des fuites de mémoire et des utilisations introuvables, ce qui crée des problèmes lors d'utilisations plus longues.

b) Flux de données

Maintenant, après avoir résolu cette attaque DDOS interne, j'ai découvert que cette application utilisait de nombreuses API dont les données étaient fantômes (mauvaise gestion des données). Au lieu de mettre en cache les données et de les utiliser à nouveau dans le même flux, l'application appelait à nouveau les API.

Je me suis assuré que les données étaient mises en cache et transmises de manière linéaire au flux et que l'API n'était appelée qu'en cas de besoin pour une nouvelle instance.

Point à retenir !

Cela a entraîné une meilleure santé du serveur et moins de temps d'arrêt pour notre backend en raison d'un trop grand nombre de requêtes API. Comme le fonctionnement du backend coûte cher à l'entreprise, il est crucial d'utiliser les API efficacement et uniquement en cas de besoin

Non seulement pour le backend mais aussi pour le frontend, effectuer des appels API supplémentaires rend le système plus consommateur car il doit effectuer plus de poignées de main et de protocoles HTTP à chaque fois que vous passez un appel.

3. ? Ce n'est pas une erreur si nous ne la reconnaissons pas !

L'une des choses cruciales pour la gestion des API est les ERREURS. Les consoler avec les journaux ne suffit pas car cela rend l'expérience de l'utilisateur bien pire que ses bonnes utilisations.

Il est important de gérer les erreurs liées à toute action en utilisant une sorte de système de feedback. Il peut s'agir d'une alerte, d'une fenêtre contextuelle, d'un toast ou de quoi que ce soit. Mais l'utilisateur doit savoir pourquoi et comment cela s'est produit afin de pouvoir le signaler ou au moins savoir ce qu'il a fait de mal !

4. ? Ses souvenirs

Je dois y aller, mon pote ! Elle ne reviendra pas mais les fuites de mémoire le feront. L'une des principales choses que nous oublions lors de l'attachement d'un écouteur ou d'un appel API est de supprimer son instance après la fermeture de cette activité.

Cette application avait le ton, les appels API étaient appelés même après la fermeture de l'activité ou en arrière-plan. Cela entraîne une utilisation inutile du processeur et une monopolisation des ressources, ce qui rend l'application plus lente et difficile à utiliser.

Un nettoyage approprié de ceux-ci rend l'application plus rapide et moins lourde.

5. Déclaration des performances

Maintenant, une façon simple d'utiliser n'importe quel actif est de l'importer et de l'utiliser, n'est-ce pas ?

Mais savez-vous comment ça marche ? Chaque fois que vous importez par défaut un élément, il est alloué en mémoire avec une initialisation. Donc si vous importez et déclarez une Image ou un composant dans 5 fichiers comme celui-ci

import Profile from '../../profile'

Il en créera 5 instances pour la même chose !

Au lieu de cela, vous devez appeler tous les actifs dans un seul fichier d'index et importer l'objet à partir de celui-ci, de cette façon, il ne sera déclaré qu'une seule fois et sera utilisé par Reference partout.

Réduisant ainsi l'utilisation de la mémoire à 4/5.

✅Conclusion -

Tu es un homme bien Arthor ! (Désolé, je viens de terminer RDR2 et c'était un très bon jeu).

Avec ces changements, les performances de l'application ont été considérablement améliorées, non seulement avec une meilleure santé côté mobile, mais également avec une meilleure optimisation côté serveur.

La note du magasin est passée de 3,5 à 4,1 en seulement 1 semaine d'utilisation !!!

N'oubliez pas qu'il ne s'agit pas simplement d'un code mais d'une histoire sur la façon dont les utilisateurs interagissent avec lui.

En tant que développeur Frontend, l'ensemble du produit dépend de nous. Quelle que soit l'évolutivité du backend, le produit final que l'utilisateur va utiliser est une création et c'est la seule chose sur laquelle il prend sa décision. Il est donc très important pour nous de leur offrir une interaction fluide qui conduit à de meilleures affaires pour l'ensemble de l'entreprise.

? Laissez des commentaires si vous aimez le blog, ou partagez-le avec vos potes pour qu'ils en profitent également !

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!