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 !!
Après une simple visite guidée, j'ai découvert quelques-uns des principaux problèmes de notre application, entraînant 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.
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.
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 !!
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 !
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.
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.
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.
주의사항!
이로 인해 너무 많은 API 요청으로 인한 백엔드의 서버 상태가 향상되고 가동 중지 시간이 단축되었습니다. 백엔드를 실행하는 데는 회사의 비용이 들기 때문에 API를 필요할 때만 효과적으로 사용하는 것이 중요합니다
백엔드뿐만 아니라 프런트엔드에서도 API를 추가로 호출하면 호출할 때마다 더 많은 HTTP 핸드셰이크와 프로토콜을 수행해야 하므로 시스템 소모가 늘어납니다.
API를 처리할 때 중요한 것 중 하나는 오류입니다. 로그로 위로하는 것만으로는 사용자의 좋은 사용법보다 사용자의 경험이 훨씬 나빠지기 때문에 충분하지 않습니다.
일종의 피드백 시스템을 사용하여 모든 작업에서 발생하는 오류를 처리하는 것이 중요합니다. 경고, 팝업, 토스트 등 무엇이든 될 수 있습니다. 하지만 사용자는 문제가 발생한 이유와 방법을 알아야 다시 신고하거나 적어도 자신이 무엇을 잘못했는지 알 수 있습니다!
알았어 homie! 그녀는 돌아오지 않을 것이지만 기억누수로 인해 돌아올 것입니다. 리스너 또는 Api 호출을 연결할 때 잊어버린 주요 사항 중 하나는 해당 활동을 닫은 후 해당 인스턴스를 제거하는 것입니다.
이 앱에는 활동이 종료된 후에도 또는 백그라운드에서 API 호출이 호출되는 경향이 있었습니다. 불필요한 CPU 사용과 리소스 낭비로 인해 앱이 더 느려지고 사용하기 어려워집니다.
이를 적절하게 정리하면 앱이 더 빨라지고 제목에 대한 오버헤드가 줄어듭니다.
이제 자산을 사용하는 기본 방법은 자산을 가져와서 올바르게 사용하는 것입니다.
그런데 어떻게 작동하는지 아시나요? 항목을 기본적으로 가져올 때마다 초기화를 통해 메모리에 할당됩니다. 그래서 이렇게 5개의 파일로 이미지나 컴포넌트를 가져와서 선언하면
import Profile from '../../profile'
동일한 항목에 대해 5개의 인스턴스가 생성됩니다!
대신 하나의 인덱스 파일에서 모든 자산을 호출하고 여기에서 개체를 가져와야 합니다. 이렇게 하면 해당 자산은 한 번만 선언되고 참조에서 모든 곳에서 사용됩니다.
따라서 메모리 사용량을 4/5로 줄입니다.
당신은 좋은 사람입니다. 아르토르! (죄송합니다. 방금 RDR2를 완료했는데 정말 훌륭한 게임이었습니다.)
이러한 변경으로 모바일 측 상태가 향상되었을 뿐만 아니라 서버 측 최적화도 향상되어 앱 성능이 엄청나게 향상되었습니다.
사용 1주일 만에 스토어 평점이 3.5에서 4.1로 올랐습니다!!!
단순한 코드가 아니라 사용자가 코드와 어떻게 상호작용하는지에 대한 스토리라는 점을 기억하세요.
프런트엔드 개발자로서 전체 제품은 우리에게 달려 있습니다. 백엔드의 확장성이 아무리 뛰어나더라도 사용자가 사용할 최종 제품은 생성이며 사용자가 결정을 내리는 유일한 제품입니다. 따라서 회사 전체의 더 나은 비즈니스로 이어지는 원활한 상호 작용을 제공하는 것이 가장 중요합니다.
? 블로그가 마음에 들면 댓글을 남기거나 친구들과 공유하여 친구들도 즐길 수 있도록 하세요!
위 내용은 앱 성능을 최대로 향상시킨 방법의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!
![[웹 프런트엔드] Node.js 빠른 시작](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
