지난 블로그에서 단 2주 만에 앱 크기를 75MB에서 34MB로 줄인 방법에 대해 이야기했습니다(보기! ). 하지만 그게 다가 아닙니다. 저희 앱의 전반적인 성능도 최대 80%까지 향상되었습니다.
그 방법을 알아봅시다!!
간단한 조사 끝에 저는 우리 앱에서 일방적으로 사용자 경험과 성능을 저하시키는 주요 문제 몇 가지를 발견했습니다. 정말 좋은 하루였습니다!
메인 빌런 - 실시간 응답 생성 중 전체 앱 UI 정지
Side Villain - 응답 속도가 느리고 프레임 속도가 없음
악당의 연인 - API 호출이 너무 많습니다
The Undead Army - 잘못된 오류 처리 및 충돌
고통 - CPU 사용량 증가 및 서버 비용 증가
The Tarnished - ME !
더 나은 세상을 희망하며 우주를 재창조하는 생명 없는 싸움이 시작된다.
그래서 대공황은 당장 맞서 싸우기보다 무시하기 쉽기 때문에 쉬운 문제부터 먼저 해결하기 시작했습니다.
ReactJ의 지혜와 저주는 상태입니다. React에서 나이가 들수록 상태가 적을수록 애플리케이션이 더 좋아진다는 것을 깨닫게 됩니다. 따라서 이 특별한 예술 작품은 단일 채팅 화면에서 메시지를 보내고 받는 것뿐인 22개(예 빌어먹을 useStates 22개)를 사용하고 있었습니다.
위에 체리!
우리는 서버에서 청크 단위 데이터를 가져오기 위해 서버 측 이벤트 구현을 사용하고 있었는데, 이 경우에는 단어 단위였습니다. 따라서 응답이 100단어인 쿼리가 있는 경우(이것은 응답이 가장 적습니다). 실제로 100개의 이벤트를 받게 됩니다.
그래서 수학을 안다면 응답을 받을 때마다 100*22 = 2200번 다시 렌더링합니다.
더 이상 설명해야 하나요? (아니요)
그래서 전체 화면을 다시 만들기 시작하고 이제 숫자를 6개 상태로 줄였습니다. 이전보다 더 좋고 부드러운 기능을 제공합니다.
이전 제품보다 72% 더 성능이 향상되었습니다!!
이제 React의 Radahn을 보고 나면 앱이 꽤 많이 멈출 것이라는 결론을 쉽게 내릴 수 있겠죠?
이제 6개 주에서도 주요 문제는 100*6으로 동일하게 유지됩니다. 우리는 여전히 매달리고 있지만 상태는 더 적습니다.
주된 원인은 React DOM이 각 청크에서 업데이트된다는 것입니다. 그래서 이 문제를 해결하기 위해 "일괄 처리 및 프레임 속도 생성을 사용했습니다.
맙소사!
기본적으로 청크를 얻을 때마다 DOM을 업데이트하는 대신 청크 배치를 만들고 고정된 동적 프레임 속도로 업데이트했습니다. 이러한 프레임 속도는 OS에서 호출되었으므로 모든 기기는 시스템 용량에 따라 서로 다른 FPS를 갖게 되어 앱이 더욱 강력하고 호환되는 성능을 갖게 됩니다.
제한된 청크 세트를 일괄적으로 캡처하고 프레임이 해제될 때까지 응답을 유지하고 모든 청크가 처리될 때까지 동일한 작업을 반복합니다.
따라서 DOM을 100번 업데이트하는 대신 DOM을 3~4번만 업데이트했습니다.
이제 숙제에 대한 성능 향상을 계산하고 계산해 보세요!
여자친구를 사귀는 것은 효과가 없었지만 확실히 앱을 훨씬 더 좋게 만드는 데는 효과가 있었습니다.
Api는 데이터를 얻는 멋지고 좋은 방법이지만 이를 현명하게 사용하는 것은 여러분 자신의 기술입니다! 이제 이 앱은 이 API를 사용하여 백엔드에서 사용자 상태를 가져왔습니다. 하지만 가장 좋은 점은 3초마다 사용한다는 점!!
알겠습니다. 개발자들이 불안감을 느꼈지만 일과 삶의 균형을 추구한다는 것은 그런 의미가 아닙니다.
사용자가 앱을 사용할 때마다 사용자 데이터를 가져오려면 앱 시작 시 또는 최근 앱이 호출될 때마다 호출하는 것입니다(앱 상태 리스너). 3초마다 호출하면 모바일 리소스가 무한 스트림으로 소모될 뿐만 아니라 서버 오버헤드도 발생합니다.
serve는 100명의 사용자로부터 100개의 요청을 받는 대신 1명의 사용자로부터 100개의 요청을 받습니다. 확장성이 뛰어나고 안정적이지는 않은 것 같습니다.
또한 추적할 수 없는 메모리 누수 및 사용을 발생시켜 장기간 사용 시 문제를 일으킵니다.
이제 사내 DDOS 공격을 해결한 후 이 앱이 데이터가 허공에 떠 있는 많은 API를 사용하고 있음을 발견했습니다(데이터 처리 불량). 데이터를 캐싱하고 동일한 흐름에서 다시 사용하는 대신 앱이 API를 다시 호출했습니다.
데이터가 캐시되어 흐름에 선형적으로 흐르도록 하고 새로운 인스턴스에 필요할 때만 API가 호출되도록 했습니다.
注意事項 !
これにより、サーバーの健全性が向上し、API リクエストが多すぎることによるバックエンドのダウンタイムが減少しました。バックエンドの実行にはコストがかかるため、必要な場合にのみ API を効果的に使用することが重要です
バックエンドだけでなくフロントエンドでも、追加の API 呼び出しを行うと、呼び出しを行うたびにより多くの HTTP ハンドシェイクとプロトコルを実行する必要があるため、システムの消費量が増加します。
API を処理する上で重要なことの 1 つは、エラーです。ユーザーをログに慰めるだけでは、ユーザーの経験値が良い使い方よりもはるかに悪くなってしまうため十分ではありません。
何らかのフィードバック システムを使用して、あらゆるアクションからのエラーを処理することが重要です。アラート、ポップアップ、トーストなど何でも構いません。ただし、ユーザーは報告できるように、または少なくとも何が間違っていたのかを知るために、それがなぜ起こったのか、どのように起こったのかを知っておく必要があります!
やったね、相棒！彼女は戻ってこないが、メモリリークは戻ってくるだろう。リスナーまたは API 呼び出しをアタッチする際に忘れがちな主な点の 1 つは、アクティビティを閉じた後にそのインスタンスを削除することです。
このアプリにはその傾向があり、アクティビティが閉じられた後、またはバックグラウンドであった後でも API 呼び出しが呼び出されていました。不必要な CPU 使用率とリソースの占有を引き起こし、アプリの動作が遅くなり、使いにくくなります。
これらを適切にクリーニングすると、アプリがより高速になり、オーバーヘディングが少なくなります。
アセットを使用する基本的な方法は、アセットをインポートして正しく使用することです?
しかし、それがどのように機能するか知っていますか?項目をデフォルトでインポートするたびに、初期化によって項目がメモリに割り当てられます。したがって、次のように 5 つのファイルでイメージまたはコンポーネントをインポートして宣言すると
import Profile from '../../profile'
同じものに対して 5 つのインスタンスが作成されます !
代わりに、1 つのインデックス ファイル内のすべてのアセットを呼び出し、そこからオブジェクトをインポートする必要があります。そうすれば、アセットは 1 回だけ宣言され、どこでも Reference によって使用されます。
したがって、メモリ使用量が 4/5 に削減されます。
アーサーさんは良い人ですね！ (申し訳ありませんが、RDR2 をクリアしたばかりですが、とても素晴らしいゲームでした)。
これらの変更により、モバイル側の健全性が向上しただけでなく、サーバー側の最適化も向上し、アプリのパフォーマンスが大幅に向上しました。
わずか 1 週間の使用で、ストアの評価が 3.5 から 4.1 に上がりました !!!
これは単なるコードではなく、ユーザーがコードをどのように操作するかについてのストーリーであることを忘れないでください。
フロントエンド開発者として、製品全体は私たちに依存しています。バックエンドがどれほどスケーラブルであっても、ユーザーが使用する最終製品は作成されたものであり、それがユーザーが決定を下す唯一のものです。したがって、会社全体のビジネスの向上につながるスムーズなやり取りを提供することが私たちにとって最も重要です。
?ブログが気に入ったらコメントをドロップするか、友達と共有して楽しんでもらいましょう!
以上がアプリのパフォーマンスを向上させた方法の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。
![[Web フロントエンド] Node.js クイック スタート](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
