」工欲善其事,必先利其器。「—孔子《論語.錄靈公》
首頁 > 程式設計 > 我如何將應用程式效能提高到

我如何將應用程式效能提高到

發佈於2024-11-08
瀏覽:825

⌛ 回顾时间

在我的上一篇博客中,我谈到了如何在短短 2 周内将应用程序大小从 75MB 减少到 34MB(查看!)。但这还不是全部,我还将我们应用程序的整体性能提高了 80%?.

让我们来看看如何!!

?传说

经过简单的一轮浏览后,我发现我们的应用程序中存在一些导致糟糕的用户体验和性能的顶级问题。多么美好的一天!

  • 主要恶棍 - 生成实时响应时整个应用程序 UI 冻结

  • 小人 - 响应时间慢且无帧速率

  • 反派情人-Api调用过多

  • 亡灵大军 - 糟糕的错误处理和崩溃

  • 痛苦 - 更多 CPU 使用率和服务器成本

  • 黯然失色 - 我!

How I boosted my App Performance up to
于是,一场带着更美好世界希望的宇宙重建之战开始了。

塔希提岛计划(但这一次有效)

所以我首先从解决更简单的问题开始,因为人们很容易忽视大萧条,而不是立即与之抗争。

1. ⚛️ React 的诅咒

ReactJs 的智慧和诅咒是状态。随着我们在 React 中年龄的增长,我们意识到状态越少,应用程序就越好。因此,这个特定的艺术作品在单个聊天屏幕中使用了 22(是的,该死的 22 useStates),您所能做的就是发送消息和接收消息。

樱桃在上面!
我们使用服务器端事件实现从服务器获取逐块数据,在这种情况下是逐字获取的。因此,如果您的查询有 100 个单词的响应(这是最少的响应)。它实际上会收到 100 个事件。

因此,如果您了解数学,每次我们收到响应时,100*22 = 2200 都会重新渲染

我还需要进一步解释吗? ( 不 )

所以我开始重新创建整个屏幕,并将数字减少到 6 个状态。与以前一样具有更好、更流畅的功能。

性能比之前提高了 72%
!!

2.❄️冰冻沙漠

现在,在见证了 React 的 Radahn 之后,我们可以很容易地得出结论,应用程序将会卡住很多,对吗?

现在即使有 6 个状态,主要问题仍然是 100*6。我们仍然悬而未决,但状态减少了。

How I boosted my App Performance up to

主要原因是,react dom 在每个块上都得到更新。因此,为了解决这个问题,我们使用了“批处理和帧速率生成

天哪!

所以基本上,我们每次获得一个块时都会更新 DOM,而是批量制作块并以固定的动态帧速率更新它。这些帧速率是从操作系统调用的,因此每个设备都会根据系统容量具有不同的 FPS,从而使应用程序具有更强大和兼容的性能。

我们批量捕获一组有限的块并保持响应直到帧被释放并重复相同的操作直到所有块都被处理。

因此,我们只更新了 DOM 3-4 次,而不是更新 DOM 100 次。


现在做数学计算并计算家庭作业的表现增强!

3. ?做一个好的倾听者!

这对我来说没能找到女朋友,但肯定能让应用程序变得更好。

API 是获取数据的很酷且很好的方式,但明智地使用它们是您自己的技能!现在这个应用程序正在使用这个 api 从后端获取用户状态。但最好的部分是它每 3 秒使用一次!!

我明白了,开发人员有不安全感,但这不是他们所说的实现工作与生活平衡的意思。

a) 获取

为了在用户每次使用应用程序时获取用户数据,请在应用程序启动时或每次从最近调用应用程序时进行调用(应用程序状态侦听器)。每3秒调用一次,不仅将Mobile资源消耗成无限流,还会造成服务器开销。

serve 不会从 100 个用户那里获取 100 个请求,而是从 1 个用户那里获取 100 个请求。对我来说听起来不太可扩展和可靠。

此外,它还会造成无法追踪的内存泄漏和使用情况,从而在较长的使用中产生问题。

b) 数据流

现在,在解决了内部 DDOS 攻击后,我发现这个应用程序使用了许多 api,其数据在稀薄的空气中消失(数据处理不佳)。应用程序不再缓存数据并在同一流程中再次使用它,而是再次调用 api。

我确保数据被缓存并线性地流动到流程中,并且仅在需要新实例时才调用 api。

一定要记住!

这使得服务器运行状况更好,并减少了由于 api 请求过多而导致的后端停机时间。由于公司运行后端的成本很高,因此仅在需要时有效使用 API 至关重要

不仅对于后端,对于前端也是如此,进行额外的 api 调用会增加系统消耗,因为每次调用时都必须执行更多的 HTTP 握手和协议。

3. ?如果我们不承认它就不是错误!

处理 api 的关键之一是错误。将它们安慰到日志是不够的,因为它使用户的体验比他们的良好使用情况差得多。

使用某种反馈系统处理任何操作中的错误非常重要。它可以是警报、弹出窗口、Toast 或任何东西。但用户应该知道为什么以及如何发生,以便他们可以报告或至少知道他们做错了什么!

4. ?她的回忆

哥们儿!她不会回来,但记忆泄漏会回来。在附加任何侦听器或 Api 调用时我们忘记的主要事情之一是在关闭该活动后删除其实例。

这个应用程序有它的基调,即使活动关闭或在后台,API 调用也会被调用。导致不必要的 CPU 使用和资源占用,使应用程序更加滞后且难以使用。

正确清理这些可以使应用程序更快、更少的开销。

5. 绩效声明

现在使用任何资产的基本方法就是导入它并正确使用它?

但是你知道它是如何工作的吗?每次默认导入一个项目时,它都会通过初始化分配到内存中。因此,如果您在 5 个文件中导入并声明一个图像或组件,如下所示

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


从“../../profile”导入配置文件

它将为同一件事创建它的 5 个实例!

相反,您应该调用一个索引文件中的所有资源并从中导入对象,这样它只会被声明一次,并且将被到处引用使用。


因此将内存使用量减少到 4/5。

✅ 结论 -

你是个好人阿瑟! (抱歉,我刚刚完成了 RDR2,这是一款非常棒的游戏)。

通过这些更改,应用程序性能得到了极大的提升,不仅有更好的移动端运行状况,还有更好的服务器端优化。

使用短短 1 周,商店评分从 3.5 上升到 4.1!!!

请记住,它不仅仅是一个代码,而是一个关于用户如何与其交互的故事。

作为前端开发人员,整个产品取决于我们。无论后端的可扩展性如何,用户将要使用的最终产品都是创建出来的,这是他们做出决定的唯一事情。因此,对我们来说最重要的是为他们提供顺畅的互动,从而为整个公司带来更好的业务。

?如果您喜欢该博客,请发表评论,或与您的朋友分享,让他们也喜欢它!

版本聲明 本文轉載於:https://dev.to/suyashdev/how-i-boosted-my-app-performance-up-to-80-334n?1如有侵犯,請聯絡[email protected]刪除
最新教學 更多>

免責聲明: 提供的所有資源部分來自互聯網,如果有侵犯您的版權或其他權益,請說明詳細緣由並提供版權或權益證明然後發到郵箱:[email protected] 我們會在第一時間內為您處理。

Copyright© 2022 湘ICP备2022001581号-3