“高性能网络应用程序”或“前端”到底是什么？
自从 Internet Explorer 时代衰落以来，JavaScript 生态系统变得越来越强大，“前端”一词已成为高性能、现代 Web 客户端的代名词。这个“前端”世界的核心是 React。事实上，在前端开发中不使用 React 常常会让一个人看起来像个异类。
但正如并非所有游戏都是 AAA 级一样，我们在讨论网络应用程序时也必须仔细考虑“高性能”的含义。这种区别对于今天的主题至关重要。
1。高性能 Web 应用程序的范围
在大多数情况下，术语“高性能 Web 应用程序”是指使用基于 JavaScript 的框架（如 React、Vue 或 Angular）构建的交互式动态 Web 客户端。这些应用程序通常拥有快速加载时间和客户端路由，而 React 的虚拟 DOM 在提高渲染速度方面发挥着重要作用。
但是，有些 Web 应用程序利用了 WASM 模块的全部 4GB 内存限制，在构建时考虑了系统内存管理，并旨在实现与 Blender 或 3Ds Max 等本机程序相当的性能。这些应用程序更符合利用浏览器选项卡的所有资源的“程序”概念，而不是针对 SEO 优化的传统“网页”。
尽管由于内存限制和开销，当前的浏览器环境可能仍难以提供类似本机的性能，但此类应用程序的目标根本不同。他们处理大型数据集，目标是使用完整的 2-4GB 内存，同时追求最高的渲染速度。
鉴于这些类型的网络应用程序面临的问题与典型的“高性能”应用程序面临的问题不同，它们追求的方向也有所不同。
一开始提到的“高性能 Web 应用程序”和我在这里描述的“高性能 Web 应用程序”在路径上有根本的不同。将它们归为一个术语是有问题的。我们需要不同的术语来反映这些差异。
这就是为什么我建议我们停止将后者称为“高性能网络应用程序”或“前端”，而是使用以下术语：
我相信这些术语清楚地定义了前端和 HPSE 之间的要求差异。并非所有基于浏览器的客户端都是前端；有些是 HPSE。考虑以下示例以了解为什么这种区别很重要：
[对话 1]
A：“我正在开发一个前端应用程序，但没有使用 React。”
B：“没有 React 的前端应用？React 在前端市场占有率超过 60%！你为什么不使用它？”
[对话2]
答：“我正在开发 HPSE 应用程序，但没有使用 React。”
B：“这对 HPSE 来说是有道理的。游戏公司经常广泛定制他们的引擎，但 React 的内部功能和渲染管道无法修改。它从来不是为此目的而设计的。”
现在，我们来讨论 HPSE 必须具备的基本组件。
2-1。内存管理
不谈内存就谈不上高性能程序。无论是使用垃圾收集器还是手动释放动态分配的内存，都必须始终释放未使用的内存。
考虑一个基于浏览器的游戏，玩家移动到新地图。游戏需要从服务器异步获取新的地图数据，创建新的网格物体，并删除旧的网格物体。用于生成旧网格的数据也必须被释放。
如果对旧数据的引用没有正确释放，内存使用量将随着每次地图转换而不断增长。一旦达到 2GB 左右，您可能会遇到“内存不足”错误，并且浏览器将崩溃。
确实，JavaScript 并不是为低级内存控制而设计的——无论是语言还是其开发人员的理念都没有优先考虑它。我并不是说内存管理始终至关重要，但正如他们所说，“天下没有免费的午餐”。如果需要内存管理，就一定要做。
2-2。灵活满足要求
我曾经听到有人说，“当你从初级开发人员转变为中级开发人员时，你应该能够构建任何你要求的东西。”
JavaScript 已经是一种令人印象深刻的语言，几乎没有固有的限制（除了内存限制）。如果你想构建一些东西，它很可能可以完成。
진짜 질문은 현재 프로젝트가 실제로 다양한 요구 사항을 수용할 수 있는지 여부입니다.
공장의 기계가 계속 작동하다 고장이 나듯이, 고성능, 맞춤형 기능을 추구하다 보면 예상치 못한 난제에 부딪힐 수밖에 없습니다. 이런 일이 발생하면 고유한 요구 사항을 충족할 수 있는 유연성과 능력이 필수적입니다.
예를 들어, 로스트아크가 언리얼 엔진 3를 기반으로 제작됐다는 소식을 들어보신 적이 있나요? 언리얼 엔진 5가 출시되었지만 그들은 여전히 2004년에 제작된 언리얼 엔진 3를 사용하고 있습니다. 지금까지 프로젝트를 유지하려면 엔진을 대대적으로 수정해야 했습니다. 사실상 완전한 점검이 필요했습니다. 게임의 특성으로 인해 성능 및 미적 요구 사항을 충족하기 위해 지연 렌더링, 인스턴싱, 컬링 및 화면 공간 반사와 같은 기술을 사용하여 렌더링 파이프라인과 루프를 지속적으로 맞춤화해야 했습니다.
엔진의 소스 코드를 수정하는 기능이 매우 중요했습니다. 엔진이 닫혀 있거나 개조가 불가능할 정도로 너무 단단하게 결합되어 있었다면 로스트아크는 개발되지 않았을 수도 있습니다.
HPSE도 마찬가지입니다. 환경은 브라우저 기반으로 바뀌었지만, 맞춤형 기능과 유연한 수정에 대한 필요성은 그대로입니다. 따라서 HPSE에 사용되는 라이브러리와 외부 모듈은 수정 가능해야 하며, 브라우저의 렌더링 파이프라인이나 내부 모듈 결합이 너무 경직되어 이러한 변경을 허용할 수 없는 경우 심각한 문제가 됩니다.
2-3. 필연적인 객체지향적 접근
대규모 프로그램을 다룰 때 피할 수 없는 것이 하나 있는데 바로 객체지향 프로그래밍(OOP)입니다.
JavaScript는 다중 패러다임 언어이며, 함수형 프로그래밍(FP)이 널리 사용됩니다. 그러나 FP는 웹 클라이언트에 적합하지만 FP의 인스턴스에는 내부 상태가 부족하기 때문에 여러 개체가 복잡한 방식으로 상호 작용하는 대규모 프로그램에서는 거의 사용되지 않습니다.
React는 전역 상태 관리 및 useEffect로 이를 보완하지만 각 인스턴스가 자체 상태를 유지하고 공개 메서드를 통해 메서드 호출을 제어하는 것만큼 직관적이지는 않습니다.
OOP가 항상 최선의 선택은 아니지만 HPSE의 고도로 맞춤화된 개발 요구 사항을 고려할 때 더 나은 대안을 생각하기는 어렵습니다. 운영 체제 및 게임을 포함한 많은 대규모 프로그램은 OOP 원칙을 사용하여 구축됩니다. 가장 인기 있는 엔진 소스도 객체 지향적이며 방법론이 약간 다릅니다.
대규모 프로젝트에 참여한 개발자라면 OOP에 익숙할 것입니다. 이는 OOP 기반 개발이 협업에 도움이 되도록 만듭니다.
그렇다고 JavaScript의 장점을 버릴 필요는 없습니다. JavaScript는 함수와 const 선언을 지원하므로 인스턴스가 필요하지 않은 간단한 모듈 함수는 const 또는 함수를 사용하여 객체 리터럴로 정의할 수 있습니다. 이를 통해 생산성을 높이고 JavaScript의 다양성을 활용할 수 있습니다.
결론적으로, 객체지향 원칙을 통합한 다중 패러다임 접근 방식이 HPSE에 이상적이라고 생각합니다.
以上是（高性能 Web 应用程序的要求的详细内容。更多信息请关注PHP中文网其他相关文章！
