⌛ おさらい時間

前回のブログでは、アプリのサイズをわずか 2 週間で 75MB から 34MB に削減した方法について話しました (表示!)。しかし、それだけではありません。アプリの全体的なパフォーマンスも最大 80% 向上しました?.

その方法を発見しましょう !!

?伝承

簡単なウォークスルーの後、ユーザー エクスペリエンスとパフォーマンスの低下につながるアプリの最上位の問題をいくつか発見しました。なんて日だ！

• 主な悪役 - リアルタイム応答の生成中にアプリ全体の UI がフリーズ

• サイドヴィラン - 応答時間が遅く、フレームレートがありません

• 悪役の恋人 - API 呼び出しが多すぎます

• The Undead Army - 不十分なエラー処理とクラッシュ

• 問題 - CPU 使用率とサーバーコストの増加

• 汚れた - 私 !

こうして、より良い世界の希望を持って宇宙を再創造するという命懸けの戦いが始まる。

タヒチ計画 (しかし、今回はうまくいきます)

そこで私は、大恐慌と当面戦うよりも無視するのが簡単なので、まず簡単な問題に取り組むことから始めました。

1. ⚛️ Reactの呪い

ReactJ の知恵と呪いは状態です。 React を使いこなすにつれて、ステートが少ないほどアプリケーションが優れていることがわかります。したがって、この特定のアート作品では、単一のチャット画面で 22 (はい、なんと 22 の useStates) が使用されており、できることはメッセージの送信とメッセージの受信だけです。

チェリー・オン・ザ・トップ !
私たちはサーバー側のイベント実装を使用して、サーバーからチャンクごとのデータを取得していました (場合によってはワードごと)。したがって、100 ワードの応答を持つクエリがあるとします (これは応答が最小です)。実際には 100 個のイベントを受信します。

計算がわかっていれば、応答を受け取るたびに 100*22 = 2200 回再レンダリングが行われます。

これ以上説明する必要はありますか? （ いいえ ）

そこで、画面全体の再作成を開始し、その数を 6 つの状態に減らしました。以前と同様に、より優れたスムーズな機能を備えています。

これは、以前よりも

パフォーマンスが 72% 向上しました !!

2. ❄️ 凍った砂漠

React の Radahn を目撃した後、アプリがかなりフリーズするだろうと簡単に結論付けることができますよね?

6 つの州があっても、主な問題は 100*6 であることに変わりはありません。私たちはまだハングアップしていますが、州は少なくなります。

主な原因は、React dom が各チャンクで更新されることでした。そこで、これに取り組むために、

「バッチ処理とフレーム レートの生成」を使用しました。

まあまあ!

基本的には、チャンクを取得するたびに DOM を更新する代わりに、チャンクのバッチを作成し、固定の動的フレーム レートで更新していました。これらのフレーム レートは OS から呼び出されるため、すべてのデバイスはシステム容量に応じて異なる FPS を持ち、アプリの堅牢性と互換性のあるパフォーマンスを実現します。

バッチ内の限られたチャンクのセットをキャプチャし、フレームが解放されるまで応答を保持し、すべてのチャンクが処理されるまで同じことを繰り返しました。

したがって、DOM を 100 回更新する代わりに、DOM を 3 ～ 4 回更新するだけで済みました。

それでは、宿題のパフォーマンス向上を計算して計算してみましょう !

3.?良い聞き手になりましょう！

ガールフレンドを作ることはうまくいきませんでしたが、アプリをより良くするためには確かに役に立ちました。

API はデータを取得するクールで優れた方法ですが、賢く使用するのはあなた自身のスキルです。このアプリはこの API を使用してバックエンドからユーザーのステータスを取得していました。しかし、一番良かったのは 3 秒ごとに使用したことです !!

わかりました、開発者は不安を抱えていましたが、これは彼らがワークライフ バランスをもたらすという意味ではありません。

a) フェッチ

ユーザーがアプリを使用するたびにユーザーデータを取得するには、アプリの起動時、またはアプリが最近（アプリ状態リスナー）から呼び出されるたびに呼び出しを行います。 3 秒ごとに呼び出すと、モバイル リソースが無限のストリームに使用されるだけでなく、サーバーのオーバーヘッドが発生します。

100 人のユーザーから 100 件のリクエストを取得する代わりに、serve は 1 人のユーザーから 100 件のリクエストを取得します。私には、あまりスケーラブルで信頼できるとは思えません。

また、追跡できないメモリ リークや使用量が発生し、長時間使用すると問題が発生します。

b) データの流れ

社内 DDOS 攻撃を解決した後、このアプリが多くの API を使用していて、そのデータが空中に隠れていた (データ処理が不十分) ことがわかりました。データをキャッシュして同じフローで再度使用する代わりに、アプリは API を再度呼び出していました。

データがキャッシュされてフローに直線的に流れるようにし、新しいインスタンスに必要な場合にのみ API が呼び出されるようにしました。

注意事項 !

これにより、サーバーの健全性が向上し、API リクエストが多すぎることによるバックエンドのダウンタイムが減少しました。バックエンドの実行にはコストがかかるため、必要な場合にのみ API を効果的に使用することが重要です

バックエンドだけでなくフロントエンドでも、追加の API 呼び出しを行うと、呼び出しを行うたびにさらに多くの HTTP ハンドシェイクとプロトコルを実行する必要があるため、システムの消費量が増加します。

3.?私たちがそれを認めなくても、それはエラーではありません。

API を処理する上で重要なことの 1 つはエラーです。ログに記録するだけでは十分ではありません。ユーザーの経験値が、良い使い方よりもはるかに悪くなるからです。

何らかのフィードバック システムを使用して、あらゆるアクションからのエラーを処理することが重要です。アラート、ポップアップ、トーストなど何でも構いません。ただし、ユーザーは報告できるように、または少なくとも何が間違っていたのかを知るために、それがなぜ起こったのか、どのように起こったのかを知っておく必要があります !

4.?彼女の思い出

ガッタチャ・ホーミー！彼女は戻ってこないが、メモリリークは戻ってくるだろう。リスナーまたは API 呼び出しをアタッチするときに忘れる主な点の 1 つは、アクティビティを閉じた後にそのインスタンスを削除することです。

このアプリにはその傾向があり、アクティビティが閉じられた後、またはバックグラウンドであった後でも API 呼び出しが呼び出されていました。不必要な CPU 使用率とリソースの占有を引き起こし、アプリの動作が遅くなり、使いにくくなります。

これらを適切にクリーニングすると、アプリがより高速になり、オーバーヘディングが少なくなります。

5. パフォーマンスの宣言

アセットを使用する基本的な方法は、アセットをインポートして正しく使用することです?

でも、それがどのように機能するか知っていますか？項目をデフォルトでインポートするたびに、初期化によって項目がメモリに割り当てられます。したがって、次のように 5 つのファイルでイメージまたはコンポーネントをインポートして宣言すると

「../../profile」からプロファイルをインポート

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

同じものに対して 5 つのインスタンスが作成されます !

代わりに、1 つのインデックス ファイル内のすべてのアセットを呼び出し、そこからオブジェクトをインポートする必要があります。そうすれば、アセットは 1 回だけ宣言され、どこでも Reference によって使用されます。

したがって、メモリ使用量が 4/5 に削減されます。

✅ 結論 -

アーサー君はいい人だよ！ (申し訳ありませんが、RDR2 をクリアしたばかりですが、とても素晴らしいゲームでした)。

これらの変更により、モバイル側の健全性が向上しただけでなく、サーバー側の最適化も向上し、アプリのパフォーマンスが大幅に向上しました。

使用してわずか 1 週間で、ストアの評価が 3.5 から 4.1 に上がりました !!!

これは単なるコードではなく、ユーザーがコードをどのように操作するかについてのストーリーであることを忘れないでください。

フロントエンド開発者として、製品全体は私たちに依存しています。バックエンドがどれほどスケーラブルであっても、ユーザーが使用する最終製品は作成されたものであり、それがユーザーが決定を下す唯一のものです。したがって、会社全体のビジネスの向上につながるスムーズなやり取りを提供することが私たちにとって最も重要です。

?ブログが気に入ったらコメントをドロップするか、友達と共有して一緒に楽しんでもらいましょう!