In meinem letzten Blog habe ich darüber gesprochen, wie ich meine App-Größe in nur 2 Wochen von 75 MB auf 34 MB reduziert habe (Ansehen!). Aber das ist noch nicht alles, ich habe auch die Gesamtleistung unserer App um bis zu 80 % verbessert?.
Lassen Sie uns herausfinden, WIE!!
Nach einem einfachen Rundgang entdeckte ich einige der wichtigsten Probleme in unserer App, die im Alleingang zu einer schlechten Benutzererfahrung und Leistung führten. Was für ein Tag!
Hauptschurke – gesamte App-Benutzeroberfläche eingefroren, während Echtzeitantwort generiert wird
Side Villain – Langsame Reaktionszeit und keine Bildraten
Villain's Lover – Zu viele API-Aufrufe
The Undead Army – Schlechte Fehlerbehandlung und Abstürze
Probleme – Mehr CPU-Auslastung und Serverkosten
The Tarnished - ME !
Damit beginnt ein lebloser Kampf um die Wiederherstellung des Universums mit der Hoffnung auf eine bessere Welt.
Also begann ich damit, zuerst die einfacheren Probleme anzugehen, da es einfacher ist, die große Depression zu ignorieren, als sie sofort zu bekämpfen.
Die Weisheit und der Fluch von ReactJs sind Zustände. Wenn wir in React älter werden, stellen wir fest, dass die Anwendung umso besser ist, je weniger Zustände sie haben. Daher verwendete dieses besondere Kunstwerk 22 (ja, verdammt 22 UseStates) in einem einzigen Chat-Bildschirm, in dem Sie nur Nachrichten senden und Nachrichten empfangen können.
Das Sahnehäubchen!
Wir haben die serverseitige Ereignisimplementierung verwendet, um Chunk-by-Chunk-Daten vom Server abzurufen, was in diesem Fall Wort für Wort geschah. Wenn Sie also eine Anfrage hätten, deren Antwort 100 Wörter umfasst (DAS IST DIE GERINGSTE ANTWORT). Es werden tatsächlich 100 Ereignisse empfangen.
Wenn Sie sich also mit der Mathematik auskennen, 100*22 = 2200 Neu-Renderingsjedes Mal, wenn wir eine Antwort erhalten.
Muss ich das noch näher erläutern? (NEIN)
Also habe ich damit begonnen, den gesamten Bildschirm neu zu erstellen und die Anzahl auf jetzt 6 Zustände reduziert. Mit besserer und reibungsloser Funktionalität als zuvor.
Das ist 72 % leistungsfähiger als zuvor!!
Jetzt, nachdem wir das Radahn von React miterlebt haben, können wir leicht zu dem Schluss kommen, dass die App ziemlich stark einfrieren wird, oder?
Selbst bei 6 Staaten bleibt das Hauptproblem dasselbe, es ist 100*6. Wir hängen immer noch, aber mit weniger Staaten.
Die Hauptursache war, dass React Dom bei jedem Block aktualisiert wurde. Um dieses Problem anzugehen, haben wir „Stapelverarbeitung und Generierung von Frameraten“ verwendet.
Hölle ja!
Anstatt das DOM jedes Mal zu aktualisieren, wenn wir einen Block erhalten, haben wir stattdessen Stapel von Blöcken erstellt und diese mit einer festen dynamischen Bildrate aktualisiert. Diese Bildraten wurden vom Betriebssystem abgerufen, sodass jedes Gerät je nach Systemkapazität unterschiedliche FPS hat, was der App eine robustere und kompatiblere Leistung verleiht.
Wir haben eine begrenzte Anzahl von Chunks in einem Stapel erfasst und die Antwort zurückgehalten, bis der Frame freigegeben wird, und das Gleiche wiederholt, bis alle Chunks verarbeitet sind.
Anstatt DOM 100 Mal zu aktualisieren, haben wir DOM daher nur 3-4 Mal aktualisiert.
Rechnen Sie jetzt nach und berechnen Sie die Leistungssteigerung für die Hausaufgaben!
Es hat bei mir nicht funktioniert, eine Freundin zu finden, aber es hat auf jeden Fall dazu beigetragen, die App viel besser zu machen.
APIs sind eine coole und nette Möglichkeit, Daten zu erhalten, aber der kluge Umgang mit ihnen ist eine eigene Fähigkeit! Jetzt nutzte diese App diese API, um den Benutzerstatus vom Backend abzurufen. Aber das Beste daran ist, dass es alle 3 Sekunden verwendet wurde!!
Ich verstehe, der Entwickler hatte Unsicherheiten, aber das ist nicht das, was er mit der Vereinbarkeit von Beruf und Privatleben meinte.
Um die Benutzerdaten jedes Mal abzurufen, wenn der Benutzer die App verwendet, muss der Anruf beim Start der App oder bei jedem Aufruf der App von einem aktuellen Aufruf (App-Status-Listener) durchgeführt werden. Der Aufruf alle 3 Sekunden verbraucht nicht nur mobile Ressourcen in einem unendlichen Stream, sondern verursacht auch Server-Overhead.
Anstatt 100 Anfragen von 100 Benutzern zu erhalten, erhält Serve 100 Anfragen von einem Benutzer. Klingt für mich nicht sehr skalierbar und zuverlässig.
Außerdem führt es zu nicht auffindbaren Speicherlecks und Nutzungen, was bei längerer Nutzung zu Problemen führt.
Nachdem ich diesen internen DDOS-Angriff behoben hatte, stellte ich fest, dass diese App viele APIs verwendete, deren Daten sich in Luft auflösten (schlechte Datenverarbeitung). Anstatt Daten zwischenzuspeichern und im selben Ablauf erneut zu verwenden, rief die App erneut APIs auf.
Ich habe dafür gesorgt, dass Daten zwischengespeichert und linear an den Datenfluss weitergeleitet werden und die API nur dann aufgerufen wird, wenn sie für eine neue Instanz benötigt wird.
주의사항!
이로 인해 너무 많은 API 요청으로 인한 백엔드의 서버 상태가 향상되고 가동 중지 시간이 단축되었습니다. 백엔드를 실행하는 데는 회사의 비용이 들기 때문에 API를 필요할 때만 효과적으로 사용하는 것이 중요합니다
백엔드뿐만 아니라 프런트엔드에서도 API를 추가로 호출하면 호출할 때마다 더 많은 HTTP 핸드셰이크와 프로토콜을 수행해야 하므로 시스템 소모가 늘어납니다.
API를 처리할 때 중요한 것 중 하나는 오류입니다. 로그로 위로하는 것만으로는 사용자의 좋은 사용법보다 사용자의 경험이 훨씬 나빠지기 때문에 충분하지 않습니다.
일종의 피드백 시스템을 사용하여 모든 작업에서 발생하는 오류를 처리하는 것이 중요합니다. 경고, 팝업, 토스트 등 무엇이든 될 수 있습니다. 하지만 사용자는 문제가 발생한 이유와 방법을 알아야 다시 신고하거나 적어도 자신이 무엇을 잘못했는지 알 수 있습니다!
알았어 homie! 그녀는 돌아오지 않을 것이지만 기억누수로 인해 돌아올 것입니다. 리스너 또는 Api 호출을 연결할 때 잊어버린 주요 사항 중 하나는 해당 활동을 닫은 후 해당 인스턴스를 제거하는 것입니다.
이 앱에는 활동이 종료된 후에도 또는 백그라운드에서 API 호출이 호출되는 경향이 있었습니다. 불필요한 CPU 사용과 리소스 낭비로 인해 앱이 더 느려지고 사용하기 어려워집니다.
이를 적절하게 정리하면 앱이 더 빨라지고 제목에 대한 오버헤드가 줄어듭니다.
이제 자산을 사용하는 기본 방법은 자산을 가져와서 올바르게 사용하는 것입니다.
그런데 어떻게 작동하는지 아시나요? 항목을 기본적으로 가져올 때마다 초기화를 통해 메모리에 할당됩니다. 그래서 이렇게 5개의 파일로 이미지나 컴포넌트를 가져와서 선언하면
import Profile from '../../profile'
동일한 항목에 대해 5개의 인스턴스가 생성됩니다!
대신 하나의 인덱스 파일에서 모든 자산을 호출하고 여기에서 개체를 가져와야 합니다. 이렇게 하면 해당 자산은 한 번만 선언되고 참조에서 모든 곳에서 사용됩니다.
따라서 메모리 사용량을 4/5로 줄입니다.
당신은 좋은 사람입니다. 아르토르! (죄송합니다. 방금 RDR2를 완료했는데 정말 훌륭한 게임이었습니다.)
이러한 변경으로 모바일 측 상태가 향상되었을 뿐만 아니라 서버 측 최적화도 향상되어 앱 성능이 엄청나게 향상되었습니다.
사용 1주일 만에 스토어 평점이 3.5에서 4.1로 올랐습니다!!!
단순한 코드가 아니라 사용자가 코드와 어떻게 상호작용하는지에 대한 스토리라는 점을 기억하세요.
프런트엔드 개발자로서 전체 제품은 우리에게 달려 있습니다. 백엔드의 확장성이 아무리 뛰어나더라도 사용자가 사용할 최종 제품은 생성이며 사용자가 결정을 내리는 유일한 제품입니다. 따라서 회사 전체의 더 나은 비즈니스로 이어지는 원활한 상호 작용을 제공하는 것이 가장 중요합니다.
? 블로그가 마음에 들면 댓글을 남기거나 친구들과 공유하여 친구들도 즐길 수 있도록 하세요!
Das obige ist der detaillierte Inhalt vonWie ich meine App-Leistung um bis zu gesteigert habe. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!
![[Web-Frontend] Node.js-Schnellstart](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
