Godot引擎性能优化实战：内存管理与帧率提升全攻略-开发者社区

1. 项目概述：为什么Godot性能优化是开发者的必修课

做游戏开发，尤其是用Godot引擎，你肯定遇到过这种情况：项目跑起来挺流畅，一上真机，特别是安卓或者低配PC，帧率直接掉到30以下，甚至卡成PPT。或者场景稍微复杂一点，内存占用就蹭蹭往上涨，玩一会儿手机就开始发烫。这背后，往往就是内存管理和帧率优化没做到位。

我做了十多年游戏，从独立小游戏到商业项目，踩过无数性能的坑。Godot是个好引擎，上手快、灵活，但它的“自由”也是一把双刃剑。你不去主动管理，引擎默认的行为很可能在移动端或者复杂场景里给你“埋雷”。内存泄漏、GC（垃圾回收）卡顿、过度绘制、无效的物理计算……这些问题不会在开发机上立刻暴露，但会在玩家手里集中爆发。

这篇内容，就是把我这些年用Godot做性能调优的核心经验，特别是针对内存和帧率这两个最要命的部分，系统地拆解给你。它不是简单的API罗列，而是告诉你“为什么”要这么做，以及在不同场景下“怎么选”。无论你是刚入门的新手，还是已经做过几个项目的老鸟，相信都能找到立刻能用上的实战技巧。我们的目标很明确：让你的游戏在各种设备上都能稳定、流畅地跑起来，把玩家因为卡顿、闪退而流失的风险降到最低。

2. 性能优化的核心思路：从“感觉卡”到“数据说话”

在动手优化之前，最关键的一步是建立正确的优化思路。很多开发者一上来就想着“我这里用个对象池”、“那里少new点对象”，这是本末倒置。优化必须始于测量，终于验证。

2.1 建立性能基准与监控体系

你不能优化一个你无法测量的东西。在Godot里，你需要建立自己的性能监控仪表盘。

第一步：启用并看懂内置分析器。在编辑器里运行项目时，打开“调试器”面板的“分析器”选项卡。这里面的数据是金矿。你要重点关注这几列：

Frame Time（帧时间）：核心指标。理想情况下每帧应在16.6ms（60FPS）或33.3ms（30FPS）以内。要区分CPU时间和GPU时间，这决定了你的瓶颈在哪。
Physics Process（物理处理时间）：如果这个值异常高，说明你的物理世界太复杂，或者有大量动态物体在持续计算。
Object Count（对象计数）和Resource Count（资源计数）：这是观察内存增长的第一道防线。如果它们随着游戏进行只增不减，几乎可以肯定存在内存泄漏。
Script Function（脚本函数耗时）：点击“脚本函数”标签，它会按耗时排序所有被调用的函数。优化就从最顶上的那几个开始。

第二步：在关键代码路径手动打点。内置分析器粒度不够细？用OS.get_ticks_msec()或Time.get_ticks_usec()进行手动计时。

func _process(delta): var start_time = Time.get_ticks_usec() # ... 你的核心逻辑代码 ... var end_time = Time.get_ticks_usec() print(“核心逻辑耗时: %d 微秒” % (end_time - start_time))

把这段代码封装成一个工具函数，用字典来统计不同标签的平均耗时、最大耗时，在游戏里用Label实时显示出来。这是定位性能热点的最直接方法。

第三步：区分“持续低帧率”和“卡顿峰值”。这是两种完全不同的问题：

持续低帧率：通常由每帧都执行的昂贵操作导致，比如复杂的着色器、过多的绘制调用、错误的算法复杂度。优化策略是“降本增效”，减少每帧的工作量。
卡顿峰值（Stuttering）：帧时间突然飙升，画面卡住一下。这通常是突发性、间歇性的操作引起的，比如：瞬间加载大量资源、一帧内创建/销毁大量对象触发GC、复杂的物理碰撞检测突然发生。优化策略是“平滑化”，将大任务拆散到多帧完成，或预加载、对象池化。

实操心得：不要相信“感觉”。我见过太多案例，开发者觉得“这里可能慢”，花大力气优化，结果分析器一开，瓶颈完全在另一个地方。优化前，务必用数据定位到真正的瓶颈函数或节点。

2.2 理解Godot的渲染与逻辑线程模型

Godot 4.x 默认使用多线程渲染。这意味着你的主线程（运行GDScript逻辑、物理计算）和渲染线程（提交指令给GPU）是分开的。这能提升性能，但也引入了新的考量：

主线程阻塞渲染线程：如果你的_process或_physics_process逻辑耗时太长，主线程没处理完，渲染线程就得等着，导致GPU闲置，帧率下降。这时优化CPU逻辑是首要任务。
渲染线程本身成为瓶颈：即使主线程很快，但如果一帧内提交了太多绘制指令（Draw Calls），或者GPU着色器计算太重，渲染线程也会忙不过来。这时需要优化渲染设置、合并绘制调用、简化着色器。

在项目设置的“渲染”>“线程”里，你可以调整线程模型。对于简单的2D游戏，尝试“单线程”模式有时反而更稳定，因为它避免了线程间同步的开销。但对于复杂的3D场景，多线程通常是更好的选择。

如何判断瓶颈在CPU还是GPU？一个简单的方法：在项目设置里把“渲染”>“缩放模式”改为“2D”或“3D”，然后大幅降低“缩放”值（比如降到0.5）。如果帧率显著提升，说明瓶颈很可能在GPU（填充率或像素着色器）；如果帧率没什么变化，那瓶颈就在CPU。

3. 内存管理深度解析：告别泄漏与GC卡顿

内存问题在Godot里尤为隐蔽，因为GDScript有自动垃圾回收（GC）。但自动不代表你可以高枕无忧，不当的使用模式会导致内存持续增长或GC引发卡顿。

3.1 资源（Resource）的生命周期与泄漏排查

Godot中，一切继承自Resource的类型（如Texture,PackedScene,Material）都是引用计数的。这是内存管理的核心。

核心原则：显式加载，及时卸载。

# 错误做法：在_process里反复加载 func _process(delta): var tex = load(“res://assets/texture.png”) # 每帧都新建一个Resource！ $Sprite.texture = tex # 正确做法1：预加载并复用 const BULLET_TEXTURE = preload(“res://assets/bullet.png”) # 正确做法2：按需加载，但用成员变量持有引用 var level_scene: PackedScene func load_level(): if level_scene == null: level_scene = load(“res://levels/level_1.tscn”) var instance = level_scene.instantiate() add_child(instance)

preload会在脚本加载时就把资源读进内存，适合小且频繁使用的资源。load是运行时加载，适合大资源或不确定是否用到的资源。

如何排查资源泄漏？

使用“调试器”>“对象”面板。运行你的游戏，进行一通操作（比如进入退出某个场景多次），然后观察Resource类型的实例数量是否只增不减。
关注PackedScene。如果你instantiate()了一个场景，但之后没有正确queue_free()其根节点，那么整个场景树及其所有子资源都会泄漏。
小心循环引用。虽然Godot的引用计数能处理大部分情况，但如果你通过weakref()或者自定义的引用逻辑弄乱了，还是可能漏。确保删除节点时，其上的脚本不再持有对其他大型资源（如大纹理）的强引用。

3.2 节点（Node）的创建、销毁与对象池实践

动态创建和销毁节点（尤其是带有复杂子节点和资源的场景）是性能杀手，也是卡顿峰值的主要来源。

问题根源：

new()或instantiate()不仅分配内存，还可能触发磁盘I/O（如果场景包未预加载）。
queue_free()并不会立即释放内存，节点会在当前帧结束后标记为删除，真正的释放要等到垃圾回收周期，这可能引起卡顿。

解决方案：对象池（Object Pooling）。对于频繁生成/销毁的对象，如子弹、敌人、特效粒子，一定要用池。

extends Node class_name ObjectPool var _pool: Array = [] var _prefab: PackedScene var _initial_size: int func _init(prefab: PackedScene, initial_size: int): _prefab = prefab _initial_size = initial_size for i in range(initial_size): var obj = prefab.instantiate() obj.hide() # 先隐藏，不加入场景树 obj.set_process_mode(Node.PROCESS_MODE_DISABLED) # 彻底禁用处理 _pool.append(obj) func acquire() -> Node: if _pool.is_empty(): # 池空了，动态扩容（尽量避免，说明初始容量设小了） var obj = _prefab.instantiate() return obj else: var obj = _pool.pop_back() obj.show() obj.set_process_mode(Node.PROCESS_MODE_INHERIT) return obj func release(obj: Node): obj.hide() obj.set_process_mode(Node.PROCESS_MODE_DISABLED) # 可选：重置对象状态（如位置、血量） _pool.append(obj) # 使用示例（在某个生成器脚本中） var bullet_pool: ObjectPool func _ready(): bullet_pool = ObjectPool.new(preload(“res://bullet.tscn”), 20) func spawn_bullet(): var bullet = bullet_pool.acquire() add_child(bullet) bullet.global_position = $Muzzle.global_position bullet.direction = Vector2.RIGHT.rotated(rotation) # ... 其他初始化 # 在子弹脚本的_on_visible_on_screen_notifier_screen_exited或命中后 func _on_body_entered(body): get_parent().bullet_pool.release(self) # 假设池挂在父节点 queue_free() # 或者由池的release方法调用

注意事项：对象池中的对象，在“休眠”时一定要禁用其_process、_physics_process和输入处理，否则它们仍在消耗CPU周期。使用set_process_mode(Node.PROCESS_MODE_DISABLED)是最彻底的方法。

3.3 垃圾回收（GC）策略与卡顿平滑化

GDScript的GC是自动触发的，你无法直接控制时机。当可用内存不足或经过一定时间后，GC会运行，遍历所有不再引用的对象并释放它们。这个过程是“停止世界”的，会阻塞主线程，造成明显的卡顿。

减少GC压力的关键：

避免在循环或_process中创建临时数组/字典。特别是Array和Dictionary的+、+=操作，会创建新对象。

# 差 func _process(delta): var new_array = some_array + [new_item] # 每帧都新建一个数组！ # 好 var _temp_array: Array = [] func _process(delta): _temp_array.clear() # 复用已有的数组 _temp_array.append_array(some_array) _temp_array.append(new_item) # 使用 _temp_array ...

谨慎使用字符串连接。在循环中频繁使用+=连接字符串会产生大量临时字符串对象。对于复杂的字符串构建，使用StringBuilder模式（Godot里可以用PackedStringArray或Array收集部分，最后用””.join(array)）。

# 差 var log = “” for i in range(1000): log += “Log entry ” + str(i) + “\n” # 产生大量临时字符串 # 好 var parts: PackedStringArray = [] parts.resize(1000) # 预分配大小（可选，可减少扩容开销） for i in range(1000): parts[i] = “Log entry ” + str(i) # 直接赋值 var log = “\n”.join(parts)

对大块数据的操作，考虑使用Packed*Array（如PackedByteArray,PackedVector2Array）。它们在内存中是连续存储的，处理速度更快，且GC开销更小。

主动管理GC时机（高级技巧）：虽然不能直接调用GC，但你可以通过控制内存分配节奏来间接影响它。在加载界面、过场动画等非实时操作时段，主动进行一些可能触发GC的操作（比如释放一批不再需要的资源），比让它在战斗高潮时突然触发要好。

4. CPU端帧率优化实战技巧

CPU要做的事情太多了：脚本逻辑、物理模拟、动画计算、场景树遍历、输入处理等等。任何一环慢了，帧率就上不去。

4.1 脚本与逻辑优化：从GDScript到C#

GDScript的优化守则：

使用静态类型：这是提升GDScript性能最简单有效的一步。为变量、函数参数和返回值声明类型。
```
var health: int = 100 # 好 var position: Vector2 # 好 func calculate_damage(attack_power: float, defense: float) -> float: # 好
```
静态类型能让Godot的虚拟机生成更高效的字节码，避免运行时类型检查和转换。
减少每帧的函数调用开销：避免在_process里调用大量小型函数，特别是那些需要参数传递和返回的。如果逻辑简单，直接内联。
缓存节点引用：绝对不要在_process里用$NodePath或get_node()查找节点。
```
# 差 func _process(delta): $Sprite.position.x += speed * delta # 好 @onready var _sprite: Sprite2D = $Sprite func _process(delta): _sprite.position.x += speed * delta
```
@onready装饰器会在节点进入场景树后、_ready调用前赋值，是缓存引用的最佳实践。

善用信号（Signal）而非轮询：不要每帧去检查“按钮是否被按下”、“敌人是否死亡”。用信号来通知状态变化。

# 差 func _process(delta): if enemy.health <= 0: handle_enemy_died() # 好 # 在敌人脚本中 signal died func take_damage(amount: int): health -= amount if health <= 0: died.emit() # 在管理者脚本中 func _ready(): enemy.died.connect(_on_enemy_died)

何时考虑C#或GDExtension (C++)？当你的游戏有极其密集的计算逻辑（如寻路算法、大规模粒子模拟、复杂的数学运算）时，纯GDScript可能力不从心。

C#：Godot对C#的支持很好，性能远超GDScript，接近原生代码。如果你的团队熟悉C#，或者项目逻辑非常复杂，用C#重写热点模块是值得的。注意，移动平台（iOS/Android）发布时需要包含.NET运行时，会增大包体。
GDExtension (C++)：这是性能的终极选择。用于编写引擎扩展或对性能有极致要求的核心模块（如自定义渲染后端、物理引擎交互）。但开发复杂度最高，调试也更麻烦。

一个简单的性能对比实验：用GDScript和C#分别实现一个计算100万次向量点积的循环，在编辑器里跑一下，你会对性能差距有直观的认识。

4.2 物理与碰撞性能调优

物理引擎是另一个CPU大户，尤其是3D项目。

简化碰撞形状：永远不要用高精度的网格（Mesh）作为CollisionShape3D。对于角色，用胶囊体（Capsule）或圆柱体；对于墙壁和地面，用盒体（Box）或凸包（ConvexPolygon）；对于复杂静态物体，使用多个简单形状组合。Godot的ConvexPolygonShape3D可以自动从网格生成简化的凸包，在导入模型时勾选“创建碰撞体”并选择“凸包分解”是个好习惯。
善用碰撞层与遮罩：精确设置collision_layer和collision_mask。不要让不需要相互碰撞的物体进行检测计算。比如，子弹不需要和子弹碰撞，特效粒子不需要和任何东西碰撞。
静态物体用StaticBody，动态物体用RigidBody或CharacterBody：StaticBody一旦加入场景，其碰撞数据就被优化，查询成本极低。不要用RigidBody并设置freeze = true来模拟静态物体，效率差很多。
控制物理更新频率：在项目设置的“物理”>“公共”里，可以调整Physics FPS（默认60）。对于非快节奏游戏，降到30或50可以显著减少CPU开销。但注意，这会影响物理模拟的精度和响应性。
避免每帧查询物理世界：raycast、intersect_shape等查询是有成本的。如果不需要每帧都知道结果（比如敌人的视野检测可以每几帧做一次），就用一个计时器来节流。
警惕“隧道效应”：高速运动的物体（如子弹）可能因为在一帧内穿过了薄墙，导致碰撞检测失败。对于高速物体，要么增加其碰撞形状的safe_margin属性，要么使用连续碰撞检测（CCD），或者在代码中自己用射线投射来预测碰撞。

4.3 场景树管理与节点处理优化

Godot的场景树很强大，但遍历整棵树是有成本的。

禁用不可见或远离摄像头的节点：使用VisibilityNotifier（2D）或VisibleOnScreenNotifier3D。当节点离开屏幕时，自动将其process_mode设为PROCESS_MODE_DISABLED，甚至queue_free()（如果是临时对象）。
使用process_mode精细控制：除了全局的process_mode，每个节点都可以单独设置。对于背景装饰物、不重要的AI，可以设为PROCESS_MODE_WHEN_PAUSED或PROCESS_MODE_DISABLED，在需要时再启用。
扁平化场景树：过深的节点层级会增加遍历开销。如果不是出于逻辑或组织必要，尽量让节点结构扁平一些。例如，一堆同类型的静态障碍物，可以直接作为根节点的子节点，而不是每个都放在一个单独的Node下。
减少_process和_physics_process的空转：如果一个节点暂时不需要做任何事情，就把它的process_mode改掉，或者直接在脚本里用条件判断尽早return。
```
func _process(delta): if not is_active: # 用一个标志位控制 return # ... 实际逻辑 ...
```

5. GPU端与渲染性能优化

当CPU已经很快，但帧率还是上不去时，瓶颈很可能就在GPU。优化GPU的关键在于减少其工作量。

5.1 绘制调用合并与批处理

绘制调用（Draw Call）是CPU命令GPU绘制一个东西的指令。每次调用都有开销。Godot会自动对使用相同材质、相同纹理的2D精灵或3D网格进行批处理，减少Draw Call。但你需要帮助引擎更好地进行批处理：

使用图集（Texture Atlas）：将多个小纹理打包到一张大图里。这样，使用这张大图上不同部分的精灵就可以被批量渲染。Godot的Sprite2D的Region属性或AtlasTexture资源可以方便地使用图集。
在2D中，使用YSort节点要谨慎：YSort会根据节点的Y坐标动态排序渲染顺序，这会打断批处理。如果可能，手动设置节点的z_index来固定渲染顺序，或者将不需要深度排序的节点放在YSort节点之外。
在3D中，使用相同的材质实例：确保多个MeshInstance3D使用的是同一个Material资源实例，而不是每个实例都duplicate()一份。共享材质是批处理的前提。

利用MultiMeshInstance2D/3D：这是绘制大量相同物体的终极武器。它用一个Draw Call就能渲染成千上万个实例（如草地、人群、子弹）。你需要通过脚本动态更新MultiMesh里每个实例的变换（位置、旋转、缩放）。

# 创建MultiMeshInstance3D的示例 var mmi = $MultiMeshInstance3D var mm = mmi.multimesh mm.instance_count = 1000 for i in range(1000): var transform = Transform3D().translated(Vector3(randf_range(-50, 50), 0, randf_range(-50, 50))) mm.set_instance_transform(i, transform)

5.2 纹理、着色器与后处理优化

纹理尺寸与格式：
- 永远不要使用比显示尺寸大得多的纹理。一个在屏幕上显示为100x100像素的精灵，用1024x1024的纹理就是巨大的浪费。在导入设置中，根据目标平台设置合理的“最大尺寸”限制。
- 使用合适的压缩格式。移动端用ETC2/ASTC，桌面端用S3TC/BPTC。在Godot的导入设置中为纹理选择正确的“压缩”模式，可以大幅减少VRAM占用和带宽。
- 启用Mipmap。对于3D纹理，Mipmap能减少远处物体的纹理采样开销和锯齿。在2D中，如果纹理会被缩放，启用Mipmap也有助于减少闪烁。
着色器优化：
- 减少条件分支（if/else）。GPU的并行架构不擅长分支预测，复杂的条件判断会显著降低着色器执行效率。尽量用数学函数（如step(),smoothstep(),mix()）来替代。
- 减少纹理采样次数。采样纹理是很慢的操作。如果可能，将多个贴图（如粗糙度、金属度、环境光遮蔽）打包到一张纹理的不同通道（RGBA）中，一次采样读取所有信息。
- 避免在片段着色器中进行复杂的循环或数学运算。将能移到顶点着色器的计算就移上去。
- 对于移动平台，使用Godot的“移动端”渲染器，它提供了简化版的着色器语言和功能，效率更高。
谨慎使用后处理与特效：
- 屏幕空间环境光遮蔽（SSAO）、屏幕空间反射（SSR）、景深（DOF）、动态模糊（Motion Blur）等效果非常消耗性能。在项目设置的“渲染”>“环境”中，根据目标平台酌情关闭或降低质量。
- 抗锯齿（AA）：TAA（时间性抗锯齿）效果最好但开销大，FXAA（快速近似抗锯齿）开销小但有模糊感，MSAA（多重采样抗锯齿）对几何边缘效果好但对性能影响大且不处理着色器锯齿。移动端通常建议用FXAA或干脆不用。

5.3 LOD、遮挡剔除与视锥裁剪

对于3D大世界，这些技术是保帧率的关键。

细节层次（LOD）：为远处的模型使用面数更少的简化版本。Godot 4.x 支持自动生成LOD（在网格导入设置中），也支持手动设置LOD节点。关键是设置好不同LOD级别切换的距离阈值。
遮挡剔除（Occlusion Culling）：防止GPU渲染被摄像机前方物体完全挡住的物体。Godot 4.x 的渲染器支持基于软件光栅化的遮挡剔除。你需要为可能遮挡他物的较大静态物体（如墙壁、山体）创建简化的遮挡网格（Occluder）。在OccluderInstance3D节点中设置。这是一个“投入一次，受益全程”的优化，对室内场景或城市景观提升巨大。
视锥裁剪（Frustum Culling）：Godot默认开启。确保你的场景根节点是World3D的一部分，并且摄像机设置正确。对于自己通过脚本大量生成的对象，确保它们的AABB（轴对齐包围盒）设置正确，否则裁剪会失效。

6. 移动端专项优化策略

移动设备（手机、平板）的硬件限制比PC严格得多，内存小、GPU弱、散热差。针对移动端的优化需要更狠。

渲染器选择：在项目设置的“渲染”>“渲染器”中，优先选择“移动端（Mobile）”渲染器。它移除了许多桌面端的高级特性，着色器模型更简单，能带来显著的性能提升和功耗降低。
分辨率与缩放：不要以设备的原生分辨率渲染。在项目设置的“显示”>“窗口”>“拉伸”中，设置一个较低的“基础大小”（如1280x720），然后让Godot拉伸到屏幕大小。这能极大降低GPU的填充率压力。使用“视口（Viewport）”节点渲染UI到另一个分辨率，可以保证UI清晰的同时降低3D场景的渲染负荷。
减少透明与混合：半透明物体（Alpha Blend）需要从后往前排序并混合，非常消耗性能。尽量减少半透明物体的数量，能用Alpha Test（镂空）替代的就用Alpha Test（在材质中设置Transparency > Alpha Scissor）。
压缩所有资源：音频用MP3或Ogg Vorbis（降低比特率），纹理用ASTC压缩格式，考虑将背景音乐从流式播放改为在内存中解码的小段循环。
监控发热与功耗：长时间高负载运行会导致设备降频，帧率越来越低。设计游戏时要有“喘息之机”，比如在菜单界面、过场动画时主动降低逻辑更新频率或渲染负荷。
使用性能分析工具：Android的Profiler或Android GPU Inspector，iOS的Instruments。连接真机进行性能分析，查看CPU/GPU/内存的实时曲线，比在编辑器里模拟更准确。

7. 常见性能问题排查与实战案例

理论说了这么多，我们来点实际的。下面是我在项目中真实遇到并解决过的一些典型性能问题。

案例一：场景切换时的长时间卡顿

现象：从主菜单进入游戏关卡时，画面会卡住2-3秒。
排查：使用分析器，发现卡顿时ResourceLoader.load()调用耗时极高。
解决方案：
1. 异步加载：使用ResourceLoader.load_threaded_request()和ResourceLoader.load_threaded_get_status()在后台加载大资源（如场景、大型纹理）。
2. 进度条伪装：在加载场景前，先显示一个加载界面，然后在后台线程加载资源，同时在前台播放动画或显示提示文字，分散玩家注意力。
3. 分包加载：将关卡资源拆包，只加载当前区域必需的资源。其他资源在玩家接近时再动态加载。

案例二：游戏运行一段时间后越来越卡

现象：游戏开始时很流畅，玩了10分钟后，帧率明显下降，甚至出现间歇性卡顿。
排查：打开“调试器”>“对象”面板，发现Node和Resource的数量在持续缓慢增长。
解决方案：
1. 检查所有动态生成的对象（子弹、敌人、特效）是否都被正确销毁。确保queue_free()被调用，并且没有其他地方还持有对这些节点的引用（比如存储在某个全局数组里忘了移除）。
2. 检查是否有大量“游离”的Resource。比如，不断用Image.load()加载图片但没释放，或者不断new()一些自定义的Resource子类。
3. 使用WeakRef（弱引用）来持有可能被销毁的对象的引用，避免阻止GC。

案例三：敌人数量一多，帧率暴跌

现象：屏幕上同时出现20个敌人时，游戏还能跑60帧；出现50个时，直接掉到20帧。
排查：分析器显示_process中每个敌人的AI逻辑脚本耗时很高，且物理计算时间也增加了。
解决方案：
1. 降低AI更新频率：不是每个敌人都需要每帧思考。用一个随机或固定的时间间隔（如0.1-0.3秒）来更新AI状态。
```
# 在敌人脚本中 var _ai_timer: float = 0.0 func _process(delta): _ai_timer -= delta if _ai_timer <= 0.0: _update_ai() _ai_timer = randf_range(0.1, 0.3) # 随机间隔，避免所有敌人在同一帧更新
```
2. 简化AI逻辑：用状态机（State Machine）管理敌人行为，避免每帧进行复杂的路径计算或视野检测。将昂贵的计算（如A*寻路）结果缓存起来复用。
3. 使用MultiMeshInstance：如果敌人是相同的模型，将其替换为MultiMeshInstance3D，用一个脚本来统一管理所有实例的位置和状态，渲染性能会有数量级的提升。
4. 优化碰撞形状：将敌人的复杂碰撞体替换为简单的胶囊体或球体。

案例四：在低端安卓机上，游戏启动后立即卡顿

现象：游戏启动后的前几分钟非常卡，之后稍微好转。
排查：这是典型的“着色器编译卡顿”。Godot的Vulkan/GLES3后端在首次使用一个着色器变体时，需要在线编译，这会阻塞渲染线程。
解决方案：
1. 在项目设置的“渲染”>“着色器编译”中，启用着色器缓存。这会将编译好的着色器保存到磁盘，下次启动时重用。
2. 更激进的方法是使用预编译着色器管道。Godot 4.x 提供了rendering/pipeline_cache/save_chunk_size等设置。你可以在第一次启动时让玩家等待（比如在启动画面时），让引擎预编译所有可能用到的着色器变体并保存下来。
3. 减少材质和着色器的变体数量。合并相似的材质，减少使用if语句依赖运行时参数的复杂着色器。

性能优化是一场永无止境的战斗，但也是一门有章可循的艺术。核心思路永远是：测量 -> 定位 -> 假设 -> 验证 -> 迭代。不要试图一次性优化所有东西，抓住主要矛盾，解决最突出的瓶颈，你的游戏体验就会有立竿见影的提升。记住，稳定的30帧往往比波动在40-60帧之间体验更好。祝你开发顺利，做出流畅又精彩的游戏。