fivem-redm-performance-network

FiveM / RedM 性能与网络优化

专注于 resmon CPU 和 网络字节数。不是通用实现指南，也不是原生函数百科全书。

仅在任务需要时加载参考资料。不要预先加载全部三个文件。

文件	打开时机
references/profiling.md	测量、卡顿类型、resmon、性能分析器、neteventlog、验证
references/fivem-networking.md	事件、latent、首次 GET 缓存、msgpack/JSON、路由/-1、状态包、回调、带宽计算
references/lua-hotpaths.md	线程、Wait、原生函数、对象池、分配、NUI、GetPlayers、启动时加载 SQL 缓存

遇到不确定的原生函数签名 → 查阅原生函数参考资料；不要猜测。验证网络 ID，绝不信任客户端。本技能不涵盖通用脚手架或 OneSync 漏洞百科全书。

---

目标

在同步正确、玩法不变的前提下，降低 CPU 和 网络流量 和 事件频率 和负载大小。

资源即使显示 0.00ms，但仍在大量触发事件，也不算优化。网络日志安静，但仍在用 Wait(0) 扫描对象池，也不算优化。

不要盲目优化。不要捏造测量结果。不要为了节省字节而削弱服务器验证。

---

工作流

1. 确认游戏（FiveM / RedM / 共用）和侧别（客户端 / 服务器 / NUI）。
2. 进行测量，或标注为估算值。打开 references/profiling.md。
3. 对照下方清单进行 grep。将每个命中项分类为 CPU、网络或两者；并标注 Critical / High / Medium / Low。
4. 提出修复方案之前，打开相应参考资料。
5. 保留玩法、同步、路由桶、权限、导出、NUI 和框架状态。
6. 报告优化前后的情况，并标明实测还是估算。

---

默认规则（始终适用）

• 使用安全范围内最长的休眠时间。只有确实需要逐帧处理时才使用 Wait(0)。
• 状态可观察时，优先使用事件驱动，而不是轮询。
• 只发送给最小的有效接收者范围。只有每个客户端都必须接收时才使用 -1。
• 完整负载只发送一次（加入 / 首次 GET / 资源启动时），之后在客户端或服务器上缓存。后续只发送增量。
• 在资源启动或玩家加入时，将数据库行加载到服务器内存缓存中。只有数据实际发生变化时才查询或写入数据库。
• 首次快照之后发送增量，而不是完整的玩家/物品栏数据块。
• 网络事件使用 msgpack。额外调用 json.encode 会增加 CPU 开销（如果发送出去，还会产生很长的字符串）。
• 仅对较大且对延迟不敏感的负载使用 Latent 事件。
• 缓存当前 tick 内的原生函数结果；必须保持实时更新的值不要缓存。
• 任何性能优化之后，服务器仍须验证 source、权限、数量、所有权、距离、路由桶和冷却时间。
• 在任何可能让出执行权的操作之前，先保存 local src = source。

---

grep 清单

搜索整个资源，包括两侧：

• CreateThread / Citizen.CreateThread / while true
• Wait(0) / Wait(1) / Wait(5) / Wait(10)
• TriggerServerEvent / TriggerClientEvent / TriggerLatent
• 使用 -1 的 TriggerClientEvent
• RegisterNetEvent / AddEventHandler / TriggerEvent
• GetGamePool / GetActivePlayers / GetPlayers
• json.encode / json.decode
• SendNUIMessage
• MySQL / oxmysql / .query / .query.await
• GlobalState / .state / AddStateBagChangeHandler
• lib.callback / emitNet

逐个检查事件：本地事件还是 C→S 或 S→C；触发频率；负载结构；接收者范围；是否位于循环内。

---

优先级

Critical — 逐帧触发 Trigger*Event、每帧调用 GetGamePool、每 tick 发送大型 JSON、使用 -1 广播大量数据。

High — 高频循环、不必要的广播、大型负载、开销大的原生函数、循环中的同步 SQL。

Medium — 重复分配、冗余计算、低效的表扫描。

Low — resmon 无法显示的微优化。

Critical 问题尚未解决时，不要纠结 Low 级优化。

---

编辑前

1. 了解架构、事件使用方以及客户端／服务端边界。
2. 删除事件前，搜索整个资源及其依赖项。事件可能在其他文件或资源中使用。
3. 检查导出、回调、NUI、框架集成和状态袋。
4. 除非用户提出要求，否则不要更改背包、金钱、权限、实体所有权或路由桶的行为。

如果优化必须改变行为，请明确说明。

---

报告格式

摘要

用一段简短文字说明主要瓶颈。

性能

Before:   (measured | estimate)
After:    (measured | estimate)
Expected: ...

网络

Event:
Frequency:
Payload:
Recipients:
Estimated bandwidth:

更改

说明每项重要更改及原因。

风险

同步、游戏玩法或验证方面的风险。

剩余瓶颈

接下来需要测量的内容。

验证

说明如何使用 resmon / profiler / neteventlog（references/profiling.md）进行确认。