UE5相机震动完全指南：CameraShake新架构与蓝图/C++实战调优

1. CameraShake在UE5里到底解决了什么问题

做游戏这么多年，我越来越觉得“手感”这个东西是最玄学也最值钱的。玩家为什么会觉得一个射击游戏“爽”、一个恐怖游戏“吓人”、一个跑酷游戏“带劲”？画面、音效当然占大头，但真正让玩家在潜意识层面产生共鸣的，往往是那些一帧两帧的细节，而相机震动就是这几帧细节里性价比最高的一个。

我最早接触CameraShake是从UE4开始的，当时项目里做爆炸和开枪反馈，把相机稍微晃一晃，游戏质感立刻就不一样了。到了UE5，老接口还在，但官方在底层重构了一套基于UCameraShakeBase的新方案。这导致网上很多资料、旧视频里的教程其实已经过时了，新手照着一抄，经常在蓝图里找不到对应的节点，或者在C++里死活编译不过。我写这篇东西，就是想把新老两套方案、蓝图和C++两条路线、参数和手感之间那层窗户纸捅破。

这套东西适合谁看？主要两类人：一类是做单人沉浸式项目、想把操作反馈做扎实的独立开发者；另一类是刚进团队、被分到“把打击感调一下”这种任务的新人策划或技美。别觉得它只是加几个节点的事，真正让CameraShake有价值的地方在于你对“震动粒度”的理解——怎么让轻攻击和重攻击震感不一样，怎么让爆炸的距离感通过衰减体现出来，怎么在长时间奔跑时用微小震动加强地面材质差异而不让玩家晕。这些全是细节，而UE5恰恰给了你把这些细节拆开控制的自由。

我们要聊的不是“怎么加一个镜头抖动”这种五分钟教程，而是把相机震动当成一个有输入、有输出、有性能预算、有手感阈值的完整系统来理解。

2. 两代CameraShake系统的技术选型

2.1 UE5里结构早已变化

很多从UE4项目迁到UE5的人，第一反应是去找“Camera Shake”这个类。你会发现UE5里确实保留了Legacy Camera Shake这个旧类，也就是UE4时代继承自CameraShake的那个对象，它仍然能跑。但从UE5开始，官方更推荐的继承对象是CameraShakeBase，字面上就差一个“Base”，实际用起来差别还挺大。

UE5的新方案把震动分成了两层：一层是震动“宿主”，也就是CameraShakeBase，它本身定义了这个晃动由谁驱动、持续多久、循环还是不循环、附带哪些混合逻辑；另一层是震动“模式”，也就是CameraShakePattern，它是实际产生位移和旋转数据的源头。官方默认提供的是一个叫Perlin Noise Camera Shake Pattern的子类，底层用的是Perlin噪声算法，能产生连续、平滑又带有随机感的抖动轨迹，比老版本里那种单纯的正弦波叠加正弦波自然得多。

为什么要这么设计？我理解官方是想把“震动策略”和“播放方式”解耦。过去你要做一种“先剧烈后衰减”的地震效果，得去改CameraShake内部逻辑或者硬编码，复用性很差。现在你可以在项目里做一个“距离衰减Pattern”和一个“固定强度Pattern”，然后挂到不同的Shake宿主上；同一个宿主还能在运行时替换不同的Pattern，代码层面只需要改一个引用，不需要大动干戈。

2.2 旧方案Legacy CameraShake还有没有存在的必要

我见过很多团队在做UE5项目时还用老的CameraShake，因为它简单，尤其在做单机原型验证时。你新建一个蓝图类继承CameraShake，设置一下震荡间隔和幅度，然后在蓝图里PlayWorldCameraShake或PlayerController的ClientPlayCameraShake一切，效果就出来了。这套流程在网上有大量现成案例。

但我还是建议新项目尽量别用了。原因有两个：第一，UE5对老类的支持虽然在，我自己实测的部分功能在某些子模块下会出现兼容性提醒，而且官方文档里关于它的描述几乎处于“不再主动维护”的状态，谁也不知道未来某个版本会不会直接移除；第二，新方案在自定义能力上没有上限，老的振荡方式本质上是固定波形组合，想做“踩到粘液地面时轻晃、踩到钢板时高频微震”这种差异化效果，老方案很难做到波形级别的控制。

如果是维护老项目，旧方案继续用完全没问题，稳定省事。如果是UE5新项目，尤其是蓝图新手，我建议一步到位学新的，因为你未来想接C++自定义Pattern时，不用再把旧代码翻出来重写一遍。这其实是技术债的问题——第一版觉得省了事，第二版就开始痛苦，到第三版你已经不想碰那段代码了。

2.3 随手就能建出来的Perlin噪声Pattern

新流程里出现频率最高的默认模式就是Perlin噪声。具体到项目里，它的参数分为几群：控制位置晃动的有X轴幅度、Y轴幅度、Z轴幅度，每一轴各自有频率；控制旋转晃动的同样也是Pitch、Yaw、Roll三路，频率可以分别设置。加上时序上的Duration、Blend In Time、Blend Out Time，密密麻麻一排浮点数。

新手很容易在这里被劝退，觉得参数太多记不住。其实用熟了就会发现，你真正需要调的核心就三个：幅度、频率、持续时间。幅度决定震得多厉害，频率决定震动是什么质感——低频让你感觉像船在晃动，中频是重物撞击，高频才是武器后坐力那种细碎抖动。持续时间决定一次反馈的节奏感。

实际调参时我记得一个比较合理的手感区间：武器开火类的高频抖动，Pitch和Yaw幅度控制在0.3度到0.8度之间，频率12到20Hz；爆炸类的大位移，X和Y轴位置幅度给到3到8个单位，频率放到4到8Hz。这只是起步值，不同游戏的主视角镜头参数会影响最终体感，你必须在自己的项目里反复试。每次改完参数后至少跑三遍实机验证，因为人眼和身体的疲劳度会影响主观感受。

3. 蓝图流程里CameraShake怎么落地实操

3.1 从零创建第一个可用的震动资源

用蓝图做新方案的Shake很简单，但顺序有讲究。第一步不是直接建“Blueprint Class”，而是先想清楚你要哪种Pattern。默认是Perlin噪声，如果简单做一版就直接用这个；想自定义，可以在新建蓝图时父类选CameraShakePattern，这样你做出来的东西本身就是一个可复用的模式。

常规做法是在内容浏览器里右键，选择蓝图类，父类搜索CameraShakeBase，命名类似“BP_ExplosionShake”。打开蓝图后你会发现界面上没有老版本那种震荡波形配置了，取而代之的是一个CameraShakePattern的引用。此时你需要在细节面板把它指定成一个默认的Perlin噪声Pattern实例，或者在事件图表里动态加载一个。直接新建一个CameraShakePattern的蓝图子类资产，会更方便，因为编辑时可以实时看到这个振动模式的属性面板。

想省事的话也可以直接在创建CameraShakeBase时把底层Pattern属性的默认对象指定为Perlin噪声，这样资源一建好就能直接用。我通常是先用默认方式做第一版，把整体手感锁住之后，再考虑要不要单独拆出Pattern资产去精细调曲线。

创建完成之后，检查一下这个Shake资产的Duration是否设成了0。有很多人在这一步踩坑，因为“0”在UE5里往往代表无限循环。如果真是这样设计的，那么播放时就得手动停止，否则整个游戏过程画面都在抖。

3.2 在关卡蓝图和角色蓝图里触发震动

触发方式新旧都不太一样。旧版最经典的是Spawn Actor节点选择Camera Shake，或者用Get Player Camera Manager节点里的Play Camera Shake。新版在Player Camera Manager上也提供了播放接口，具体节点是“Play Camera Shake”或者更精确的“Start Camera Shake”——名称略有混淆，我建议直接搜英文节点名再对照。

从行为树、动画通知、伤害事件、武器开火事件、游戏状态切换等各个入口怎么触发呢？最通用的方法是拿到本地玩家控制器，再由它去拿PlayerCameraManager，然后调用PlayCameraShake。这样能保证震动挂载的是本地控制的相机，也不需要在关卡蓝图里做一个公共引用满天飞的全局对象。

我自己的项目里更喜欢把触发封装成一个自定义事件，挂在玩家角色蓝图上。比如角色收到伤害时，调用“Event_PlayHitShake”，内部根据伤害量的大小决定播放哪个Shake资源。这时要用到“Evaluate"选择，实际上蓝图里的分支逻辑就够了，打if分支判断伤害值范围。这样设计的好处是后续如果某个敌人攻击想做成特殊震动，只需在事件里加一个枚举分支，而不是在十几个被伤害的地方分别改逻辑。

动画通知也是常用入口。近战攻击动画在命中帧加一个AnimNotify，在这个Notify的蓝图里直接拿到OwningActor，然后往Pawn上广播。比在攻击碰撞回调里触发要精准得多，因为Animation Notify天然和你看到的画面同步，不会出现动画已经砍过去但因为延迟范围判定还没触发导致震动比特效慢了半拍的问题。

3.3 附带”衰减“的距离爆炸效果

我们做一个最常见的玩法：手雷近处爆炸，远处玩家也会感受到轻微震感。如果直接给全局的玩家相机播放强烈震动，那么在百米外也会看到屏幕像被卡车撞一样，显然不合理。解决方式有两个套路。

第一个是使用PlayWorldCameraShake，它在播放时会检测场景中所有玩家，并且有一个衰减半径参数。如果你在做单机，可以用。另一个是通用的做法：在手雷爆炸位置算一下与本地玩家的距离，然后按距离对Shake里的幅度做缩放。实际在蓝图中需要拿到玩家的位置，用VectDist或Distance Vector计算长度，再把对比例的浮点数作为一个参数传到某个“用自定义参数生成Shake”的流程里。

听起来有点麻烦，但这是做出手感专业感的关键。不考虑距离衰减的CameraShake，和直接播放一个固定闪烁动画的特效一样，所有距离下表现完全一样，玩家会觉得你是把一个震动文件硬怼到他脸上——很多人说某种“震感很假”，原因往往就在这里。真实世界里的震动能量是随距离指数衰减的，但游戏里我们用线性或简单的二次衰减即可，没必要上物理模型，线性在10米到30米范围内视觉上最舒服。

3.4 判定“本地玩家”的那几个坑

多人联机时新手最常碰到的问题不是没震动，而是别人机器上震了，自己没震；或者是自己震了，但所有人都能看到你的屏幕在抖——后者一般发生在客户端通过RPCServer或Multicast去播放Shake时。所谓CameraShake必须只发生在拥有视口的本地客户端上，用Multicast把所有客户端都震一遍意义不大，反而会让其他玩家看到自己的画面在不受控制地晃。

所以在触发前如果条件允许，先确认“本地是否控制这个角色”，常用节点GetLocalRole或IsLocallyControlled。当你在角色蓝图内部播放时，直接加一个IsLocalPlayerController的判断即可。在纯蓝图的客户端切换场景后，CameraManager会重建，如果你保存了旧的Player Camera Manager引用，那就会莫名失效，报引用空错误。这里不需要复杂优化，规则就是“所有震动触发都从PlayerController或PlayerCameraManager开始拿”，任何跨关卡缓存下来的CameraManager引用都要警惕。

4. C++自定义震动的进阶技巧

4.1 用C++写一个自己的震动模式类

蓝图能覆盖90%的任务场景，但如果你做的是以手感闻名的动作游戏，早晚会碰到“这套默认的Perlin噪声不够味”的情况。比如你想实现一个“镜头先被击中后仰，再快速回中，同时伴随轻微随机抖动”的复合运动。Perlin模式能把随机做了，但那一下有方向的后仰，是它难以表达的东西。

这时可以在C++里继承UCameraShakePattern。你需要重写一个核心方法，大概思路是在Update模式里拿到镜头当前位置和目标位置，叠加你算出来的偏移，最后把它写回Output。初始相位要先置零，接着在这个函数里每帧根据DeltaTime推进内部随机时间种子，再用自定义函数计算位置和旋转偏量，然后输出，核心逻辑几十行就完成了。

这类自定义模式写法上不止一种风格，有的项目里甚至在TimeLine上直接推进一段提前设计好的震动曲线，类似于动画曲线那样完全手动编排。但用代码计算的一个优势是可以实时响应参数，比如玩家持有的枪械口径、玩家当前血量比例、玩家是否在瞄准状态，可以直接体现在偏移幅度上。

4.2 在C++里触发一次完整Shake

代码触发点其实很干净，核心是先拿PlayerCameraManager。很多引擎派生的写法会写成从Controller拿。实际项目里如果你在PlayerController里面触发，可以写成这样：

cpp复制// 在某个武器类或技能类里触发
APlayerController* PC = UGameplayStatics::GetPlayerController(this, 0);
if (PC && PC->PlayerCameraManager)
{
    UCameraShakeBase* Shake = PC->PlayerCameraManager->StartCameraShake(
        ShakeClass,
        Scale
    );
}

StartCameraShake返回的是一个UCameraShakeBase实例的指针，你可以保存到Actor上。之后如果想提前结束或动态调整Scale，就能持有这个指针来操作。需要注意的是，这个函数是“快速播放”路径，它默认按Shake类里定义的Duration和Blend时间去走。

如果想在C++里更精细地控制“从某个特定的Pattern实例播放”，那通常要使用StartCameraShakeFromSource或通过CameraManager内部的ActiveShakes列表来操作。这些接口在不同UE5小版本里可能会改名称，但思路没变：ShakeBase是宿主，Pattern是数据源，你只要找对容器和接口去调用即可。

4.3 把自定义波形写在C++里的收益

纯蓝图去做特殊波形不是不能做，但蓝图里处理每帧大量浮点运算和临时结构数组，节点图会变得非常笨重。而且蓝图在每帧更新Kill/存活状态、计算目标值上的性能也不如C++直觉。最关键的问题是调试——你想看波形函数的输出曲线，C++里可以在生成点时打印到日志或者用VisualDebugger画一条线，蓝图里想在细节面板逐帧看这些数值，得加一堆Print String临时节点，看完还得删，反复折腾浪费时间。

我在做过一次“受击顿帧+震屏”联动效果后就彻底转向C++了。那段逻辑在蓝图里需要同时处理时间缩放、循环计数、按血量比例插值三个流程，节点连线长了后自己都判断不出哪里执行顺序有问题。换成C++后，一个Tick函数加三个条件分支就把事情说明白了，逻辑清晰度和可维护性都上一个台阶。

如果你目前是纯蓝图项目，我建议也不要有心理负担，不是必须转C++才能做这种效果。你可以在CustomEvent里做同样的事，只是代码执行效率上比较玄学，蓝图层执行速度在低端移动设备上的开销还是很敏感的，尤其你已经同时跑着物理模拟、大量特效、音效时，震动脚本那部分CPU消耗能省就省。

5. 手感调优的实战心法

5.1 幅度、频率、持续时间的协调关系

调手感没有公式，但有经验族。我不止一次见过新人拿着一套手感很好的震动参数套用在自己的项目里，却总觉得非常违和，原因在于相机震动是相对相机视野的经验值，FOV越宽，感觉越轻微；而FOV越小，比如狙击步枪开镜时，同样幅度会看起来格外夸张。很多人忘了这一点，在两种武器之间复制同一个Shake资产，导致开镜时晃到头晕。

基础参数可以参考下面这个表，来自我之前射击项目的实测，仅供参考：

这个表的逻辑是高频配小幅度，低频配大幅度，这样生理上才说得通。如果你用幅度很大的同时再加上每秒20Hz的频率，那画面基本就是在跳舞，玩家必晕。别问我怎么知道的，都是拿测试员的眩晕投诉换来的教训。

5.2 不要忽略Blend In和Blend Out

过渡时间是新手最容易留空的参数。很多人做开枪震动，Duration设0.1秒，Blend In和Blend Out都保持0，结果每次开枪的画面都像是被硬生生推了一下，没有那种“柔和地顶到手上再松开”的弹性感。

Blend In/Out本质是一个斜坡时间，它让震动幅度从0插值到目标值再插值回0。合理的Blend值能极大提升质感：霰弹枪开火时Blend In设置0.01秒，表示这枪顶得非常快；而爆炸震动Blend In给0.1秒左右，因为冲击波传到面前是需要一个极其微小过程的。最后结束时Blend Out时间一定不能是0，否则震动在最后一帧直接卡断，视觉上会“顿一下”，正确做法是留一个0.05到0.2秒的淡出窗口。

5.3 用自定义曲线做强烈性格的震动

Perlin噪声模式里参数虽然是随机的，但它的总体统计特征像白噪声经过滤波，长时间看会很“平均”。想要有明确“节奏感”的震动，比如“大-小-大-小”或者是“先大后小再回弹一下”，就得用自定义的振动曲线。

UE5和UR4一样支持“波形”的另一种做法：在Pattern的位置和旋转参数部分使用CurveFloat或CurveVector资产。你可以用曲线编辑器画一条从1到0的衰减直线，但它能做成驼峰形、双段式、阶梯衰减等任意形状。我最常用的是“双峰衰减”，就是震动起来到最大，短暂回落不到0，再冲一个更小的峰，然后迅速归零。这在表现连续爆炸或连击时非常真实。

编辑曲线时要用真实时间做横轴，单位为秒，不要用归一化时间。原因是你后续换不同的Shake时长，只需要改Duration，曲线不需改。很多模板自带的归一化会让你的波形被拉伸变形，换个Duration就是另一种手感，在调参时四处漏风。

5.4 避免玩家晕眩的几个红线

相机震动不是越大越好，长时间高幅度的晃动对很多玩家会造成3D眩晕，这会直接影响体验和口碑。在开放世界探索类游戏里，连续震动关卡不要超过3秒，否则玩家会觉得恶心。如果你必须在某些剧情演出或环境效果中持续震很久，那就把幅度降得非常低。

移动端的震动尤其要收敛，手机画面比显示器小，距离眼睛更近，对晃动敏感度反而更高。我在手机平台项目里会把所有幅度乘一个0.6的全局衰减系数，再重新进游戏测试。另外，游戏中如果有大量UI界面操作时，尽量避免让相机震动，比如拾取道具、打开装备菜单瞬间，画面一抖，按钮位置瞬间变掉，玩家点错几次就会放弃这个游戏。震动就留给动作场景，菜单和交互面板里全禁掉，这是我对“克制”二字的理解。

6. 多人同步、Timeline与关卡蓝图里的常见坑

6.1 震动只在一台机器上生效是为什么？

这是联机项目里最高频出现的问题。CameraShake本质是渲染侧的反馈，它操作的是PlayerCameraManager这个对象，该对象只存在于本地客户端。所以你如果用服务器RPC去触发，但没在客户端执行播放逻辑，那就完全没反应。反过来，如果在服务器上对所有Pawn去做Multicast并强行播放，哪怕你只是写了个短Shake，也可能让所有客户端的摄像机同时震荡，连带观战者也会被晃，体验会很廉价。

正确信息流是：逻辑事件发生时（服务器权威），通过带FRepNotify的属性复制或客户端RPC通知到对应客户端，在客户端调用StartCameraShake。这里强调是两个层级，不是一步到位的。Server是判定“发生伤害”的地方，但“如何在本机展示反馈”属于表现层，这段逻辑应当是客户端自决的。把所有表现层都放到服务器执行，才是这个坑的根源。

6.2 Timeline和CameraShake同时用会互相打架吗？

Timeline在蓝图里很常见，很多新手就顺手用它自己做一个震屏：把Pitch或World Offset从0瞬间调到某值，再在一段Timeline里拉回0。这样也可以实现简单震动，但和真正的CameraShake冲突起来时，会演变成最后一帧谁覆盖谁的问题。

如果你自己用Timeline更新相机相对位置，同时又让CameraShake去修改相机的位置和旋转，那在底层它们操作的是同一个最终输出。不同的实现顺序、不同的插值方式，结果不是你想要的叠加，而是一方覆盖另一方。实践建议是：不要两种方法同时控制相机位置和旋转。要么用纯粹的手动Timeline做镜头动画（比如写演出脚本），要么用CameraShake做反馈型震动，它们二者承担不同的设计职责，不该在一个镜头里反复横跳。

6.3 关卡蓝图是方便，但别在这里写业务触发

我看到太多新人把CameraShake玩法触发写进关卡蓝图的某个触发盒体里。单机Demo里这样确实省事，人物一走进盒子就开始震，走出盒子就停止。但关卡蓝图本质上是在和关卡生命周期绑定的，一旦你想把这段触发逻辑复用到另一个关卡或另一张地图，就必须从头配置一遍。

我建议把震动触发尽量做到“行为”本身。例如伤害震动放进伤害处理逻辑里，爆炸震动放进爆炸Actor自己身上，交互震动放进可交互物件的蓝图里。这样你做模块化关卡时才不用反复加TriggerBox，改一处所有场景都能生效。

6.4 空引用和无效播放的那几个Debug思路

遇到“明明调用了播放但就是不震”的情况，我一般按这个顺序排查：先看PlayerCameraManager是不是空的，因为震动的播放必须经过它；再看Shake资产的Class有没有生效，蓝图里有没有误选成“ShakePattern”的父类而不是“CameraShakeBase”的子类；接着查看是否把播放写在了服务端控制流里而没有实际到客户端；最后检查场景里是否多个相机叠在同一位置，比如Cutscene用的CameraActor没有正确还原，导致你晃的是默认相机但PlayerCameraManager还挂在别的相机上。

多数情况下的问题集中在Class类型没对上。我一度创建成一个CameraShakePattern的子类，然后在代码里用StartCameraShake传了这个Class，编译器不报错，运行时无任何反应，但卡了很久才意识到类型不匹配。官方文档对这种区别的强调不够，建议在刚开始调试时，打印Log一下ShakeClass的类型名，比较稳妥。

7. 一个综合小Demo：表现“手雷在本地玩家附近爆炸”

说了这么多，来写一个实际能跑的设计流程，把这个例子里所有知识点穿起来。需求：手雷在距玩家5米处爆炸，玩家需要感受到一阵强烈冲击并伴随持续的耳鸣式高频微震。

第一步，创建震动资源。新建一个继承CameraShakeBase的蓝图BP_GrenadeShake，把它的Shake Pattern设置为一个Perlin噪声模式。位置振幅X、Y都设为8，Z接近0（不要乱震垂直轴，主要让镜头水平晃）；Rotation Pitch幅度设成4度，Yaw为1.5度，Roll设为0或极小的0.2度——真实爆炸滚转极少，Roll加太多会觉得人在太空翻跟头。频率按前面说的放在5Hz上下，Duration设为0.6秒，Blend In 0.1秒，Blend Out 0.3秒。

第二步，做爆炸Actor。在手雷爆炸后先算出距离，我用的C++逻辑里类似这样：

cpp复制float Dist = FVector::Dist(ExplosionLocation, GetPlayerPawnLocation());
float Normalized = 1.0f - FMath::Clamp(Dist / MaxRadius, 0.0f, 1.0f);
float Scale = FMath::Lerp(MinScale, MaxScale, Normalized);

最后Scale会落在0.2到1.0之间，与距离成线性关系。小于两米时是满Scale，四五米开外快速降低，超过范围就小于等于最小值。这个Scale直接传入到播放Shake的Scale参数里，不用生成多个震动变体资源，一套资产全局复用了。

第三步，把刚做的判断放客户端执行。假设服务器调用一个客户端Event，只通知“这里有爆炸”，然后由客户端自己计算并在本地播放CameraShake。不需要把震动参数精确到服务器RPC，因为不同客户端可能因为当前视口FOV或本地设置对同样震感有不同的设置选项。

第四步，在手雷爆炸现场还可以加一点Sound Effect的混响以及场景里的轻微粒子配合，这属于艺术向处理。但要注意的是视觉震动、音频低音、场景物件位移三者要在时间上契合，音频的低频最多领先画面30毫秒左右，超过50毫秒人就会觉得不同步。

这个例子做完之后，你真正需要考虑的是玩家血量影响反馈的阶段，比如濒死状态下即便是远处爆炸也会震得更狠，这种才见设计功力——不是把爆炸做得多细腻，而是在不同状态间组合出丰富层次。

8. 性能开销和使用策略

先给结论：绝大多数情况下没必要担心CameraShake的性能，它不是那种像体积光照、粒子系统一样会把你帧率从144砸到60的东西。但如果你是在低端移动平台上运行，它还是有一笔存在感的，尤其是同时播放多个震动时，CPU里做噪声采样和时间步进的那部分逻辑会线性增加。

CameraShake的性能策略有两条铁律。第一，控制同一时刻活跃的Shake数量。如果战场上同时有三颗手雷爆炸、自己又在开枪、还挨了一顿毒打，一瞬间可能会有十几个Shake叠加在一起，每个都要更新并产生对应偏移值再写入结果。遇到这种情况就设置“优先级”，当同时激活的Shake超过一定数量时，低优先级的自动让位或按权重混合。在UE5里，Shake播放有优先级机制，我们项目里让高优先级Shake直接盖掉低级的，而不是全部叠加。

第二，叠加混合的开销和持续时间成正比。一个无限循环的Perlin Shake每一帧都要计算新的随机样本，那是每帧都跑完整噪声计算。最好所有震动的Duration都有上限，哪怕它是循环的，也加一个定时器在N秒后自动削减幅度并结束。没必要让一个一秒就能展示完的震动循环到角色死亡为止。

我遇到过一次因为震屏导致移动平台发热的情况，起初不太相信它这么轻量的功能还会出问题，后来查了日志才发现是同一个冲击型震动在一个持续火焰伤害事件里每0.2秒触发一次，单个Shake很短，但反复生成导致GC和对象池回收频繁。后来把这些高频率重复触发的震动改为“在持续事件开始时启动一个循环震动，事件结束再停下来”，开销立刻降下来，发热曲线平滑，效果甚至更好。原因是重低频循环震动比高频间隔触发型震动要平滑得多，玩家并不觉得少了反馈。

9. 遇到震动“不生效”时我的排查思路实录

这里把一些实际处理过的问题汇总成一份可以直接对照的速查表。以前排查问题都是一个个条件去猜，容易漏掉最关键的一个点。现在遇到不生效会按顺序过：

有一点特别值得留意：Debug震动时，屏幕录制是看不出真实质感的。录屏帧率再高，也只能看到一个大概的模糊情况。想要准确判断震动手感，务必戴着耳机坐在显示器前直接体验，所有“这个幅度是不是合理”的判断都不能通过录屏视频或别人描述来获得，必须肉眼看、亲身试。

10. 更贴合实际项目的一组震动Release列表

分享一个我在动作射击项目里最终保留下来的震动事件清单。它不是什么标准规范，但对新人上手时很有参考价值。为每种事件单独建一个Asset，不要所有地方用一个通用震动。列表如下：

看起来资产很多，但每个的制作成本很低，调一次参数保存一遍即可。好处是后续你看到“狙击镜开枪”手感弱，只需要打开狙击枪对应的那个震动资产做微调，而不用担心改动全局影响了手枪和爆炸的表现。这也就是为什么我说CameraShake设计不该是“一个震动走天下”，它应该是项目里的一个细粒度系统。

我在项目维护中还发现一个规律：震动资产命名规范和碰撞体一样重要，最好统一前缀“Shake_”，并在用途描述里写明触发场景、目标FOV区间、特殊备注。团队变大的时候，一个人调节奏，另一个人接Asset，没有命名规范会造成很大的协作成本。这些在技术层面看不见，但越到后期越发关键。

真正用好了CameraShake，你对“手感”的掌控会从试错转变到设计——你能预判一个幅度放在某种场景里大概是什么体验，能从玩家反馈里直接猜出是哪个轴的频率导致了问题，也能在项目会议上说出“这里不该震，应该用不同衰减的Shake区分距离”。这些东西是无数个实测、回退、再尝试积累出来的手感数据库。UE5这套新系统给了我们很好的底层支持，但上限永远取决于你在编辑器里逐帧打磨了多少次。希望这篇能让你少走一些我绕过的弯路。