前回のブログでは、アプリのサイズをわずか 2 週間で 75MB から 34MB に削減した方法について話しました (表示!)。しかし、それだけではありません。アプリの全体的なパフォーマンスも最大 80% 向上しました?
その方法を発見しましょう !!
簡単なウォークスルーを行った後、ユーザーエクスペリエンスとパフォーマンスの悪化につながるアプリの最上位の問題をいくつか発見しました。なんて日だ!
主な悪役 - リアルタイム応答の生成中にアプリ UI 全体がフリーズします
サイドヴィラン - 応答時間が遅く、フレームレートがありません
悪役の恋人 - API 呼び出しが多すぎます
The Undead Army - 不十分なエラー処理とクラッシュ
問題 - CPU 使用率とサーバーコストの増加
汚れたもの - 私!
こうして、より良い世界の希望を持って宇宙を再創造するという命懸けの戦いが始まる。
そこで私は、大恐慌と当面戦うよりも無視するのが簡単なので、まず簡単な問題に取り組むことから始めました。
ReactJ の知恵と呪いは状態です。 React を使いこなすにつれて、状態が少ないほどアプリケーションが優れていることがわかります。したがって、この特定のアート作品は、単一のチャット画面で 22 (はい、なんと 22 の useStates) を使用しており、できることはメッセージの送信とメッセージの受信だけです。
チェリー・オン・ザ・トップ!
私たちはサーバー側のイベント実装を使用して、サーバーからチャンクごとのデータを取得していました (場合によってはワードごと)。したがって、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 的关键之一是错误。将它们安慰到日志是不够的，因为它使用户的体验比他们的良好使用情况差得多。
使用某种反馈系统处理任何操作中的错误非常重要。它可以是警报、弹出窗口、Toast 或任何东西。但用户应该知道为什么以及如何发生，以便他们可以报告或至少知道他们做错了什么！
哥们儿！她不会回来，但记忆泄漏会回来。在附加任何侦听器或 Api 调用时我们忘记的主要事情之一是在关闭该活动后删除其实例。
这个应用程序有它的基调，即使活动关闭或在后台，API 调用也会被调用。导致不必要的 CPU 使用和资源占用，使应用程序更加滞后且难以使用。
正确清理这些可以使应用程序更快、更少的开销。
现在使用任何资源的基本方法就是导入它并正确使用它？
但是你知道它是如何运作的吗？每次默认导入一个项目时，它都会通过初始化分配到内存中。因此，如果您在像这样的 5 个文件中导入并声明图像或组件
import Profile from '../../profile'
它将为同一件事创建它的 5 个实例！
相反，您应该调用一个索引文件中的所有资源并从中导入对象，这样它只会被声明一次，并且将被到处引用使用。
因此将内存使用量减少到 4/5。
你是个好人阿瑟！ （抱歉，我刚刚完成了 RDR2，这是一款非常棒的游戏）。
通过这些更改，应用程序性能得到了极大的提升，不仅有更好的移动端运行状况，还有更好的服务器端优化。
使用短短 1 周，商店评分从 3.5 上升到 4.1 !!!
记住，它不仅仅是一个代码，而是一个关于用户如何与其交互的故事。
作为前端开发人员，整个产品取决于我们。无论后端的可扩展性如何，用户将要使用的最终产品都是创建出来的，这是他们做出决定的唯一事情。因此，对我们来说最重要的是为他们提供顺畅的互动，从而为整个公司带来更好的业务。
？如果您喜欢该博客，请发表评论，或与您的朋友分享，让他们也喜欢它！
以上是我如何将应用程序性能提高到的详细内容。更多信息请关注PHP中文网其他相关文章！
