去年年底帮一个卡牌类移动项目做性能体检中低端机帧率常年在三十帧上下晃Profiler 打开一看渲染线程还算安分问题全压在主线程上——TweenManager.Update一个方法吃掉将近 4msGC Alloc 每帧往上冒几百字节。这就是最典型的 DOTween 性能优化场景项目本身逻辑没写错动画也没做错但只要同时活着的 tween 数量上去主线程就开始喘。DOTween 用起来实在太顺手一行DOLocalMove就能让 UI 动起来顺手到绝大多数人根本没兴趣去看它内部在干什么等到发现卡了往往已经有一千多条 tween 散落在几十个脚本里改起来牵一发动全身。这篇东西想聊的就是这件事DOTween 的性能到底花在哪儿、哪些开关是一行代码就能见效的、哪些写法看着没问题其实是隐形的开销大户、以及怎么在不推翻现有代码结构的前提下把动画系统收拾干净。适合已经用过 DOTween 但没深究过它内部机制的初中级 Unity 开发者也适合正在做包体或帧率优化的同学。所有内容都基于我在实际项目里踩过的坑和测出来的数据参数和结论你可以直接拿去对号入座。1. DOTween 性能问题的真实面貌1.1 为什么用起来最舒服的插件最容易失控DOTween 的设计哲学是极致的易用性链式 API 让任何一个刚学 Unity 两周的人都能写出transform.DOMove(target, 0.3f).SetEase(Ease.OutQuad)这样的代码。这种便利性带来一个副作用创建 tween 的成本在写代码的人眼里几乎是零。没人会在写这一行之前想我现在是不是已经有八十条 tween 在跑了因为它在语法上和一句普通的赋值没有区别。问题在于运行时的成本并不为零。每一个 tween 都是一个实实在在的对象需要被管理、被遍历、被更新、被回收。一个按钮的点击反馈动画可能只有 0.15 秒但如果你在一个列表里有 20 个这样的按钮用户快速滑动点击几下瞬间就能堆出几十条 tween它们全部挂在同一个全局管理器上被逐帧遍历。单条开销确实很小但这是乘法关系不是加法。更要命的是失控的隐蔽性。CPU 占用不会因为你多写一行 tween 就立刻报警它是一点点涨上来的。等到有人反馈切到这个界面会卡一下回头去查发现是半年前某个同事在列表项的OnEnable里加了一个呼吸灯效果每帧都在创建新的 tween旧的靠 AutoKill 自然消亡但消亡和创建之间的时间差里池子一直在被撑大。1.2 三种典型的性能症状与它们背后的成因我在项目里反复见到的症状基本可以归成三类每一类的成因完全不同处理方式也完全不一样。第一类是持续性的帧率下滑表现为任何界面都有个两三毫秒的固定开销Profiler 里TweenManager.Update常年占着一块。这通常意味着活跃 tween 的绝对数量太大或者有无限循环的 tween 忘了关。无限循环SetLoops(-1)是最阴险的一种因为 AutoKill 对它完全无效对象永远不会被回收你在线程池里就永远多了一个租客。第二类是周期性的卡顿尖峰表现为每隔一两秒掉一次帧Profiler 里能看到 GC Alloc 突然冲高。这类问题基本都出在闭包回调上。OnComplete(() { ... })这种写法在编译后会生成一个闭包类每次执行到这一行就 new 一个对象出来攒够一波就触发 GC。项目里如果有几十个这样的回调在频繁触发GC 压力会非常可观。第三类是特定交互时的顿挫比如打开背包、翻页、弹窗出现的那一瞬间。这类往往不是 DOTween 本身慢而是它和 UGUI 的布局系统、Canvas 重建撞在了一起。你改一次RectTransform.sizeDeltaCanvas 就要重建一次网格如果这个元素恰好还在LayoutGroup底下那还要再触发一次布局重算。这时候 DOTween 只是那个扣动扳机的人真正干活的是 UI 系统。注意分不清这三类症状就开始改代码是最常见的浪费时间的做法。先看 Profiler 是持续占用还是尖峰再决定往哪个方向优化。2. 先把运行模型摸清楚DOTween 到底每帧在做什么2.1 TweenManager 的单循环与对象池DOTween 内部有一个全局的TweenManager它维护着一个活跃 tween 的集合。每帧或者按你指定的UpdateType它会遍历这个集合对每一条 tween 做三件事推进时间、计算插值、把结果写回目标。这个遍历是单线程的、线性的没有任何空间换时间的优化空间所以活跃数量直接决定了这一帧的成本。也就是说DOTween 的性能模型是 O(n) 的n 是同时活着的 tween 数。理解这一点之后所有优化手段就都能归到两类要么把 n 压下去要么降低单条 tween 的常数开销。对象池的部分经常被忽略。DOTween 会复用 Tween 对象但池子初始容量是有限的默认几百个当你的峰值需求超过容量时内部数组会扩容扩容意味着一次内存分配加数组拷贝。这个动作不会每帧发生但会在动画集中爆发的时刻比如一个华丽的界面入场序列发生表现出来就是第一次打开这个界面会卡一下之后再打开就好了。有些同学会误以为这是资源加载问题其实加载早就完成了卡的是 tween 池子的扩容。这个坑我在三个不同的项目里都见过。2.2 一次完整的 Tween 生命周期里有哪些开销点把一条 tween 从生到死拆开看至少有五个花钱的地方。创建阶段构造 Tween 对象、解析参数、注册到管理器。如果你用了TweenParams之外的写法比如每次都要重新计算一遍缓动曲线这里还会有额外开销。启动阶段tween 第一次被 Update 时会做一次初始化包括计算起始值、设置插值所需的上下文。这个首次启动是有成本的官方文档里也提到过。所以大量 duration 极短比如 0.02 秒的 tween 是性价比最差的用法——启动成本还没摊薄tween 就结束了。逐帧更新阶段这是主要成本包括时间推进、缓动函数求值、值的插值、写回目标。写回目标这一步在 UGUI 里尤其贵因为它会触发SetDirty。完成阶段触发回调、执行 AutoKill、如果启用了回收则归还池子。清理阶段如果没开回收对象进入 GC 视野如果开了回收对象回到池子但需要重置状态。这五个阶段里逐帧更新是唯一一个随帧数线性增长的其他四个都只在关键节点发生一次。所以如果你的 tween 数量不多但每帧开销大问题可能不在 tween 数量上而在 tween 的时长设置上——太短的 tween 就是纯启动开销太长的 tween 就是纯逐帧开销。2.3 Sequence 是省钱还是费钱Sequence 是 DOTween 里最容易被误用的东西。很多人觉得把多个动画打包进一个 Sequence 肯定比分开写更省这个结论只在特定条件下成立。Sequence 本身也是一个 Tween它有自己的更新开销内部还要管理一组子 tween 的时间轴。如果你把三个本来可以完全并行的动画塞进一个 Sequence 里用Join串起来你得到的是一个 Sequence 的开销 三个子 tween 各自的开销比直接跑三个独立 tween 还多一层。它真正省钱的地方在于逻辑管理一个 Sequence 可以一次性 Kill 掉所有子项减少你在业务代码里到处找 tween 引用的麻烦间接降低了泄漏风险。反过来说Sequence 的嵌套成本要格外小心。我见过有项目把 Sequence 嵌套到三四层每层都在做时间轴换算Profiler 里那一段的耗时比同样数量的独立 tween 高出 30% 以上。嵌套超过两层的 Sequence基本都应该重新设计。// 不推荐三层嵌套每层都在做时间轴换算 var outer DOTween.Sequence(); var inner DOTween.Sequence(); var innermost DOTween.Sequence(); innermost.Append(transform.DOScale(Vector3.one, 0.2f)); inner.Append(innermost); outer.Append(inner); // 推荐同一层的动画用 Join 并行不要为了结构清晰而嵌套 var seq DOTween.Sequence(); seq.Append(transform.DOScale(Vector3.one, 0.2f)) .Join(image.DOFade(1f, 0.2f)) .Join(canvasGroup.DOFade(1f, 0.15f));3. 初始化与全局参数的调优清单3.1 Init 与 SetTweensCapacity 怎么给数DOTween.Init()和DOTween.SetTweensCapacity()是最该在项目启动时就处理好的两件事但绝大多数项目里这两行压根不存在全靠默认值跑。默认容量是几百条 tween 加几十条 sequence对小型项目够用对中大型项目基本一定会触发扩容。我的做法是在游戏启动流程里根据项目实际峰值给一个偏保守但有余量的值。public static class TweenBootstrap { public static void Init() { // recycleAllByDefault: 默认开启对象回收 // useSafeMode: 是否开启安全检查关闭可提升性能但要自己保证正确性 // logBehaviour: 只记录错误避免日志本身成为开销 DOTween.Init(true, false, LogBehaviour.ErrorsOnly); // 容量给到实测峰值的 1.5 倍左右避免运行期扩容 DOTween.SetTweensCapacity(800, 120); // 全局默认值收敛避免每个脚本各写一套 DOTween.defaultAutoKill true; DOTween.defaultRecyclable true; DOTween.defaultEaseType DG.Tweening.Ease.OutQuad; DOTween.defaultTimeScaleIndependent false; } }关于容量怎么估我的经验是跑一遍项目里动画最密集的那个场景通常是主界面进场、抽卡、结算弹窗在OnGUI或者调试面板里实时打印活跃数量取峰值。这个数值在不同项目之间差异极大休闲游戏可能几十条SLG 的战场可能上千条没有通用答案。提示SetTweensCapacity不是越大越好。它会在启动时预分配数组给太多会白白吃掉内存而且数组遍历的缓存友好性也会变差。给到峰值的 1.5 倍是相对稳妥的经验值。3.2 AutoKill、Recyclable、SafeMode 三个开关的真实代价这三个开关的名字都很朴素但它们对性能的影响非常直接值得单独拎出来说。AutoKill控制 tween 完成后是否自动销毁。开着是对的关着几乎总是错的——除非你要反复Restart同一条 tween。关掉 AutoKill 意味着 tween 完成后依然留在管理器里被遍历虽然它不再推进时间但遍历本身还是要花时间。我见过为了复用方便全局关掉 AutoKill 的项目最后活跃列表里挂着一堆已完成的僵尸 tween白白浪费遍历开销。Recyclable控制 tween 结束后是否回收到对象池。开着能显著减少 GC因为不用反复 new。但要注意一点回收后的对象会被重置如果你在外部还持有它的引用之后调用的行为可能不是你预期的。所以任何需要后续操作的 tween都应该先Pause或者保存引用并禁止回收。SafeMode是这仨里最容易被误解的。开启后 DOTween 会在每次调用时做额外的空引用和状态检查好处是能防住很多低级错误比如对已经销毁的对象操作代价是每条 tween 的常数开销上升。我的做法是开发期打开出包前关掉但前提是项目里的 tween 都用SetLink做了绑定否则关了 SafeMode 很容易在场景切换时炸出一堆空引用。三个开关的组合建议可以直接抄场景AutoKillRecyclableSafeMode开发阶段调试truetruetrue正式包tween 全部 SetLinktruetruefalse需要反复 Restart 的常驻 tweenfalsetrue按需一次性过场动画量极大truetruefalse3.3 全局默认值统一收敛DOTween.defaultXXX这一系列静态属性是最省力的优化入口。项目的 UI 动画里 90% 都是Ease.OutQuad或Ease.OutBack如果每次都单独SetEase那不仅代码啰嗦还容易在某处漏写导致风格不一致。把默认值设成团队约定好的那一个剩下 10% 特殊情况再单独覆盖代码干净性能上也没有额外损耗。同样值得收敛的还有defaultTimeScaleIndependent。这个属性控制 tween 是否受Time.timeScale影响。UI 动画通常应该跟着时间缩放走暂停游戏时 UI 也该暂停但血条、CD 转圈这类必须受到独立时间控制。全局默认设成false需要独立的场合单独SetUpdate(true)比反过来要安全得多——因为漏写SetUpdate顶多是动画跟着暂停而漏写SetUpdate(false)会导致暂停时动画还在跑那个视觉上的诡异程度会让你被策划追着问。4. 单条 Tween 的写法优化4.1 SetUpdate 的四种模式与选型SetUpdate决定了这条 tween 挂在哪个更新循环下。它有四种模式NormalUpdate、LateUpdate、FixedUpdate、以及手动模式。默认的Normal适合绝大多数场景因为它在逻辑更新阶段执行能保证动画数据和游戏逻辑在同一帧内是一致的。但有一个例外跟随相机或跟随物理对象的 tween如果放在Normal里会出现一帧的滞后感表现为物体动完了相机慢半拍。这类应该走LateUpdate。// 跟随类动画放 LateUpdate避免和相机更新产生一帧错位 transform.DOMove(followTarget.position, 0.1f) .SetUpdate(UpdateType.LateUpdate) .SetEase(Ease.Linear);FixedUpdate用在需要在物理步长里保持一致性的场合比如某些和刚体联动的位移。但这个模式要小心Time.timeScale变化时的表现物理步长本身是固定的tween 按固定步长推进可能会导致视觉上不够平滑。手动模式UpdateType.Manual是最容易被忽略的高性能选项。开启后 DOTween 不会自己更新需要你在合适的时机主动调用DOTween.ManualUpdate(deltaTime, unscaledDeltaTime)。这个模式的价值在于你可以把 tween 更新从主循环里挪到一个受控的位置比如和 UI 刷新同步或者干脆在低帧率模式下降低更新频率。对性能敏感的项目这是一个很有效的手段。4.2 SetEase 与曲线采样缓动函数是每条 tween 每帧都要调用一次的东西它的实现成本直接乘到总开销上。DOTween 内置的Ease枚举走的是预计算或简单的数学公式成本很低。但如果你用SetEase(AnimationCurve)每次求值都是一次AnimationCurve.Evaluate这个调用内部是 C# 实现的曲线插值比数学公式慢不少。我的建议很直接能用枚举就用枚举。确实需要自定义曲线比如美术给的那种带弹性的手感曲线的时候把它烘焙成采样表比如 128 个点然后自己用数组做线性插值或者干脆用Ease枚举组合出接近的效果。我做过一次对比测试用AnimationCurve的 200 条 tween 和用枚举的 200 条 tween前者每帧多出大概 0.3ms在 60 帧的预算里这不是小数目。还有一点常被忽略Ease.Unset和Ease.Linear的区别。Unset表示不设置会去取全局默认值中间多一层判断Linear是明确的线性插值直接走最简路径。如果你确实要线性明确写Linear而不是留空。4.3 回调、闭包与 GC这是我在项目里改得最多的一类问题也是最容易产生收益的一类。// 问题写法每次执行都生成闭包对象产生 GC for (int i 0; i items.Count; i) { var item items[i]; var index i; item.transform.DOScale(Vector3.one, 0.2f).OnComplete(() { item.SetInteractable(true); Debug.Log(index); }); }这段代码在每次循环里都会创建一个闭包对象捕获了item和index。如果这个循环在列表刷新时被反复调用那就是持续的 GC 来源。改法有三种按推荐程度排序。第一种改用不需要闭包的回调。DOTween 支持OnComplete(TweenCallback)传入方法组但方法组本身如果不带参数也是可以缓存成静态字段的。private static readonly TweenCallback EnableInteractable () { /* 共享逻辑 */ };第二种用SetLink或者外部状态机代替回调。很多回调的用途只是动画播完后做下一件事这类完全可以改成在Update里检查 tween 是否完成虽然不那么优雅但零 GC。第三种把需要在回调里做的事挪到统一的一个列表里用一个集中的调度器来处理避免每条 tween 各自持有闭包。还有一个更隐蔽的 GC 来源DOTween.To的 getter/setter 版本。// 如果 getter 或 setter 捕获了外部变量同样会产生闭包 DOTween.To(() slider.value, x slider.value x, 1f, 0.3f);这个写法本身是为了绕开属性没有直接支持的 tween但代价是每次调用都会创建两个委托。对于需要高频创建的场合把委托提取成字段缓存起来能省掉这部分开销。4.4 SetLink 与内存安全SetLink是 1.2.x 之后加入的功能作用是让 tween 跟随某个 GameObject 的生命周期——目标销毁时tween 自动被杀掉。这个功能看着只是方便实际上对内存安全至关重要。没有SetLink的情况下如果你对一个 UI 元素启动了 tween然后在 tween 执行过程中把这个元素销毁了比如切换界面DOTween 在下一帧更新时会访问一个已经销毁的 Transform轻则报错重则空引用崩溃。开了 SafeMode 的话会被拦住但拦截本身有成本不开的话就等着收崩溃日志。// 推荐所有和 GameObject 绑定的 tween 都挂上 Link transform.DOMove(targetPos, 0.3f) .SetLink(gameObject, LinkBehaviour.KillOnDestroy) .SetEase(Ease.OutQuad);这里有个实操细节SetLink的第二个参数控制销毁时的行为KillOnDestroy是直接杀掉CompleteOnDestroy是强制完成再杀PauseOnDisable是在禁用时暂停。大多数场合用KillOnDestroy就行但如果你有元素被禁用后重新启用要接着播完的需求就得用PauseOnDisable注意这个模式在多对象共享 tween 的情况下行为会比较绕。注意SetLink只对 tween 的主目标有效如果你在一个 tween 里用了多个目标比如同时对两个对象做动画要确保每个都做了绑定或者手动在销毁流程里 Kill。5. 大批量动画的架构级优化5.1 合并、节流与假的动画当动画数量到了几百条的量级单条优化已经救不了你了必须从架构上想办法。我常用的三个手段是合并、节流、和直接用假的。合并的意思是把同一个视觉效果的多个 tween 合成一条。最典型的例子是列表项的入场动画。如果你有 20 个列表项每个都要淡入加位移直觉写法是 20 条 tween或者 20 条 Sequence。但实际上你可以只用一个float值做 tween范围从 0 到 1然后在OnUpdate里遍历这 20 个元素统一设置 alpha 和位置。这样活跃 tween 从 20 条降到 1 条遍历成本几乎为零。// 一条 tween 驱动 20 个元素 float progress 0f; DOTween.To(() progress, x { progress x; for (int i 0; i items.Count; i) { float p Mathf.Clamp01(x * 1.5f - i * 0.05f); items[i].alpha p; items[i].offsetY (1f - p) * 80f; } layoutRoot.SetAllDirty(); }, 1f, 0.4f).SetEase(Ease.OutQuad);这个写法的关键点是元素的错峰效果通过i * 0.05f这种偏移量在OnUpdate里算出来而不是靠SetDelay错开时间。延迟是每条 tween 独立持有的状态意味着每条都占一个槽位而偏移量只是数学计算零成本。节流指的是控制动画的触发频率。比如滚动列表里的视差效果、血条的实时更新、跟随文字的动态字号这类动画的更新频率其实不需要每帧一次。60Hz 和 15Hz 在视觉上差别不大但 CPU 开销差四倍。做法是用一个统一的计时器每 4 帧才推进一次或者干脆按Time.deltaTime累积到阈值才更新。假的动画是指在能接受的前提下用更便宜的手段伪造视觉效果。最简单的例子是透明度动画如果你的元素本来就在一个CanvasGroup下直接 tweenCanvasGroup.alpha比 tween 每个Image.color便宜得多因为前者不触发Image的网格重建只影响渲染时的混合系数。同理缩放动画如果能用Animator的 transform 动画代替有时候反而更划算因为它在原生层执行。5.2 手写插值替代 Tween 的边界我不是那种什么都要自己写的人DOTween 的易用性值得付出那点开销。但有几类场景我确实会毫不犹豫地手写。第一类是超高频、超短时的动画比如每帧都在变的数值滚动、跟随手指的拖拽反馈。这类动画的生命周期可能只有几帧用 tween 的启动成本完全划不来直接Mathf.Lerp加一个时间累积就完事了。第二类是需要精确控制更新顺序的动画。DOTween 的更新时机是全局统一的如果你有必须在某个系统之后、另一个系统之前更新的需求手写反而更清晰。第三类是数量极大且同质的动画比如几百个粒子的位置更新。这种情况下根本不应该用 tween应该是自己维护一个数组每帧统一遍历更新这样数据是连续内存的缓存友好性比一个个独立的 tween 对象好太多。// 自己维护的批量插值零 GC、内存连续 public class ValueAnimator { private float[] _start; private float[] _end; private float[] _current; private float _elapsed; private float _duration; public void Update(float dt) { if (_elapsed _duration) return; _elapsed dt; float t Mathf.Clamp01(_elapsed / _duration); float eased t * t * (3f - 2f * t); // 平滑插值 for (int i 0; i _current.Length; i) _current[i] _start[i] (_end[i] - _start[i]) * eased; } }这段代码看着土但在批量场景下比 DOTween 快一个数量级因为它没有任何对象开销、没有委托调用、没有遍历分散的对象。5.3 UI 与 Canvas 重建的联动这一节值得单独拿出来说因为很多动画卡的锅其实不该 DOTween 背。UGUI 的 Canvas 有合批机制同一个 Canvas 下的元素会被合并成少量 DrawCall。但一旦有任何元素的几何信息变化位置、大小、颜色整个 Canvas 就会被标记为 dirty在下一帧重建网格。一个 500 个元素的 Canvas 重建一次成本可能比一帧的所有 tween 加起来还高。所以把频繁变化的元素和静态元素分开放到不同的 Canvas 下是一个非常有效的优化。做法是给动态元素单独挂一个子 Canvas不带 GraphicRaycaster避免多余的事件检测这样重建范围就缩小到了那个子 Canvas 内部。// 动态动画元素单独挂 Canvas隔离重建范围 var subCanvas animationRoot.gameObject.AddComponentCanvas(); subCanvas.overrideSorting false; // 注意不要加 GraphicRaycaster除非真的需要点击另外LayoutGroup和ContentSizeFitter是动画的两个天敌。任何在它们底下的尺寸变化都会触发布局重算而布局重算的成本和子元素数量成正比。如果必须给LayoutGroup里的元素做缩放动画用localScale而不是sizeDeltalocalScale不会触发布局。6. 一次完整的优化实录6.1 数据采集先量再改这个项目的主界面是一个卡片列表加上各种入场、翻转、选中、飘字效果。改造前我在手机上抓了一段 30 秒的样本数据大概是这样主界面停留时活跃 tween 数在 180 到 320 之间波动TweenManager.Update耗时平均 2.8ms峰值 5.2msGC Alloc 每帧 420B 左右低端机上平均帧率 34。采集手段很简单一个实时面板 一段自动录制。实时面板挂在OnGUI上打印当前活跃数量录制则是在关键交互前后打Profiler.BeginSample标记方便在 Profiler 里定位。// 简单的活跃数量监控只在开发期挂上 void OnGUI() { if (!Debug.isDebugBuild) return; GUILayout.Label($Active Tweens: {DOTween.TotalPlayingTweens()}); }这里要说明一下TotalPlayingTweens()这类静态查询在每帧调用时本身也有开销所以只在调试构建里开正式包一定要关掉。6.2 分批改造每一步的收益我没有一次性全改而是分四批做每批改完都测一次这样能清楚知道每项改动的实际收益。第一批加 Init 和容量预设。这是最小改动只在启动脚本里加了两行。效果是消除了界面首次打开时的扩容卡顿峰值耗时从 5.2ms 降到 4.6ms。这一批的收益主要体现在消除尖峰而不是降低均值用户感知很明显。第二批全局排查无限循环 tween。写了个小工具在开发构建里遍历所有活跃 tween把IsLooped且Loops -1的打印出来。结果找出来 7 处其中 3 处是真正的 bug呼吸灯效果在界面关闭时没 kill。改完之后主界面的活跃数量上限从 320 降到了 210 左右。第三批批量入场动画合并。这是收益最大的一批。列表入场原来每项一条 tween20 项就是 20 条改成一个驱动进度值之后活跃数量直接少了一个数量级。同时把入场时的sizeDelta动画全部换成了localScale消除了布局重算。这一批做完TweenManager.Update的均值从 2.8ms 降到了 0.9ms帧率从 34 提到了 52。第四批清理闭包回调。把列表里所有的OnComplete(() ...)改成了方法组 一个字典查表的方式。GC Alloc 从 420B/帧降到了 60B/帧左右卡顿尖峰基本消失。6.3 优化前后对照指标优化前优化后变化活跃 tween 均值25042-83%TweenManager.Update 均值2.8ms0.9ms-68%峰值耗时5.2ms1.6ms-69%GC Alloc 每帧420B60B-86%低端机平均帧率345253%需要说明的是帧率的提升不能全归功于 DOTween 优化因为第三批里顺手修掉的布局重算也贡献了相当一部分。但主线程耗时的下降是实打实的这部分数据我反复验证过。7. 排查速查表与踩坑记录7.1 常见症状与定位路径下面这张表是我这几年攒下来的基本覆盖了 DOTween 相关的绝大多数异常表现。遇到问题先按症状对号入座能省掉大量瞎猜的时间。症状最可能的原因定位手段处理方式帧率持续偏低活跃 tween 数量过多打印活跃计数合并、节流、Kill 无用 tween周期性掉帧闭包回调产生 GCProfiler 看 GC Alloc改方法组或缓存委托首次打开界面卡顿tween 池扩容在 Init 前后打点预设合理的 SetTweensCapacity动画播不完就停目标被禁用或销毁检查 SetLink 配置用 KillOnDestroy 而非默认暂停游戏后动画还在跑SetUpdate(true) 漏改全局搜 SetUpdate统一默认值按需覆盖动画结束后对象不回收AutoKill 被关闭检查全局配置只对需要 Restart 的关闭反复播放越来越卡tween 被重复创建没清理看活跃计数是否只增不减保存引用并 Kill 旧的报空引用目标销毁时 tween 还在跑崩溃堆栈看 TweenManager全部加 SetLink动画有拖影或抖动Update 时机与相机不同步换 SetUpdate 模式跟随类用 LateUpdate播放结束后位置有微小偏移浮点精度累积对比目标值与实际值结束回调里做一次硬赋值关于最后一条这个坑我踩过。某些长距离的位移 tween 在低帧率下最后几帧的插值可能因为浮点精度问题留下一丁点误差视觉上看不出来但如果你的逻辑依赖精确位置比如碰撞检测或吸附对齐就会出问题。解决办法是在OnComplete里把目标值硬赋一次。transform.DOMove(targetPos, 0.5f).OnComplete(() { // 兜底确保最终位置精确 transform.position targetPos; });7.2 几个反直觉的坑坑一Kill不等于立即释放。Kill(false)只是把 tween 标记为结束并从活跃列表移除它不会触发OnComplete。如果你在OnComplete里做了状态清理用Kill(false)就会漏掉这些清理逻辑。反过来Kill(true)会先完成再杀但完成可能带来额外的视觉跳变。这两个行为要分清楚别指望一个方法解决所有场景。坑二DOTween.KillAll不要放在 Update 里。它会遍历所有 tween在数量大的时候本身就是一个开销点。更稳妥的做法是维护一个目标集合用DOTween.Kill(target)定向清理。场景切换时调一次KillAll是可以的但别把它当成日常清理手段。坑三Restart会重置时间轴但不重置目标值。如果你对一个已经移动到一半的对象调Restart它会从起点重新开始但起点值是 tween 创建时记录的那个不是对象当前位置。如果对象在 tween 期间被其他逻辑改过位置Restart之后的表现会很怪。正确做法是Rewind之后再Play或者干脆重建一条。坑四无限循环 SetLink的组合会泄漏。如果一条无限循环的 tween 绑定了KillOnDestroy但绑定的对象直到关卡结束才销毁那这条 tween 就会在整个关卡期间常驻。加上SetLoops(-1)本身就不会被 AutoKill这类 tween 是活跃列表里的钉子户。我的做法是给所有无限循环的 tween 强制加一个管理容器在合适的业务节点主动 Kill不完全依赖SetLink。坑五OnUpdate里的操作可能引发递归更新。如果你在OnUpdate里又去修改了正在被 tween 驱动的属性可能会触发一次额外的脏标记在某些情况下导致同一帧内重复计算。这类问题的表现是动画看起来是对的但 CPU 占用莫名偏高。避免方法很简单OnUpdate里只做纯计算不要反向修改被驱动的东西。实际操作里我个人的体会是 DOTween 的性能优化并不需要什么高深技巧绝大部分收益来自三件事把数量压下去、把闭包干掉、把池子喂饱。真正难的不是技术手段而是你得先有一套能量化的观测方式否则改了半天只会得到感觉好像快了一点这种结论。我在每个项目里都会在开发期保留一个活跃 tween 的实时计数和一个 Profiler 采样脚本成本很低但排查问题时能省掉大量时间。另外分享一个小技巧给 tween 加 id 或者用SetId打标签配合一个简单的静态管理器可以在需要的时候按类别批量暂停、恢复、销毁比到处找引用靠谱得多。这个习惯我从第二个项目开始坚持后面接手别人代码的时候第一步也是先看看有没有类似的机制没有就先补一个。