游戏性能优化之AOI方案简介

游戏引擎技术分享

一、问题背景：为什么需要AOI

在大型多人在线游戏中，一个场景可能同时存在数百个NPC和交互实体。传统的全量同步模型面临严峻的性能挑战：

在这个模型下，服务端每个entity的变化都要广播给所有在线玩家；客户端需要处理所有entity的逻辑运算、网络消息解析和渲染开销。当场景entity数量达到数百个时，网络带宽、CPU Tick、GPU渲染三方面同时承压。

AOI（Area of Interest，感兴趣区域）正是解决这一问题的核心方案。

二、AOI核心原理

2.1 基本概念

AOI的核心思路：以玩家为中心，划定一个圆形区域，只同步该区域内的entity数据。圈外的entity对该玩家"不存在"。

关键术语：

• AOI半径：以玩家为圆心的同步范围，单位为米
• 进AOI（Enter）：entity进入玩家的AOI范围，服务端开始同步该entity数据到客户端，客户端创建entity及其关联的system、模型等
• 出AOI（Leave）：entity离开玩家的AOI范围，服务端停止同步，客户端销毁entity及相关资源

2.2 不同玩家的AOI互相独立

每个玩家都有自己独立的AOI区域，所能"看到"的entity集合各不相同：

三、性能提升效果分析

AOI从根本上减少了客户端需要处理的entity数量，带来了网络同步、逻辑运算、渲染开销三个层面的性能收益：

实测数据

数据表明，AOI可以将客户端可见NPC数量降低60%~90%。对于大场景（如开放世界、多人战场），性能收益尤其显著。

四、AOI系统架构设计

4.1 Entity类型分层策略

这一决策基于以下考量：

• NPC数量占比最高：场景中NPC通常占entity总数的80%以上，是性能瓶颈的主要来源
• 玩家之间不能有AOI：多人协作/对抗场景中，玩家之间必须始终互相可见
• 关键交互物件必须可见：门、交互点等功能性entity不能因AOI而消失，否则影响玩法

4.2 服务端-客户端AOI交互架构

五、适配AOI：核心编程规则

Entity在进出AOI时需要在代码层面做相应处理来保证状态正确恢复，这些处理统称为"适配AOI"。整个适配工作围绕两条核心规则展开：

六、适配实例详解

6.1 成功适配案例

NPC表演动画

电击手机（可交互物件）

手机的逻辑全部运行在服务端，客户端只有动画表现。NPC的动画和逻辑都由服务端数据控制，天然符合"逻辑独立"原则——无需额外适配。

QTE交互

QTE是较为复杂的适配案例，因为涉及两个entity的交互：

• UI相关操作和客户端动画/逻辑都写在状态机内，已适配on_reconnect
• 交互双方不依赖彼此，只受服务端数据控制，符合逻辑独立

6.2 未适配的反面案例

七、客户端新增API

为支持AOI机制，客户端Python层新增了以下接口，方便业务逻辑感知和响应AOI事件：

# ClientEntity 和 SystemBase 新增通知函数

class ClientEntity:
    def on_aoi_enter(self):
        """entity进入玩家AOI时被调用"""
        # 在此恢复表现、启动逻辑
        pass

    def on_aoi_leave(self):
        """entity离开玩家AOI时被调用"""
        # 在此清理状态、停止逻辑
        pass

# Area 新增成员变量
class Area:
    is_aoi_enter: bool
    # True  → 当前area在自己的AOI范围内
    # False → 当前area不在自己的AOI范围内

通过这组接口，业务层可以精确控制entity在进出AOI时的行为——比如进入时恢复动画、加载特效，离开时暂停不必要的计算。

八、引入AOI后的实战问题与解决方案

问题1：Entity创建卡顿

现象：entity进入AOI时需要创建entity对象及其关联的system、模型、特效等，这个创建过程造成明显卡顿。

问题2：高速移动时entity涌入卡顿

现象：被勾中、冲撞等高速移动场景下，短时间内大量entity进入AOI，即使有对象复用，集中创建仍然造成卡顿。

限流规则：

• 服务端每100ms只允许下发1个entity的进AOI数据
• 按距离排序作为优先级，优先下发最近的entity
• 玩家感知上是entity从近到远逐步出现，而不是瞬间全部弹出

问题3：技能状态不可恢复

现象：部分技能在断线重连时客户端不会恢复，还会打断当前技能。进入AOI触发entity的on_reconnect，同样存在不恢复问题。

解决：将客户端实现改为可恢复方案——使用状态机或Property驱动。参照QTE案例的做法，确保：

• 技能状态由Property持久化，不依赖一次性RPC
• 状态机可以从任意状态正确恢复
• 客户端不依赖"技能是从头开始播放"的假设

九、AOI扩展机制

除了基础的圆形AOI筛选外，引擎还提供了一系列高级机制，用于应对更复杂的业务场景：

十、已知遗留问题

十一、未来优化方向