Dreamer寻如果你在 Unity 里折腾过 DOTS，一定体验过那种“传统方案到处碰壁”的滋味。模型加载出来了、物理能跑了，结果角色动画一上来就卡壳——Animator 跑在 GameObject 上，DOTS 跑在 Entity 上，两套数据根本不在一个频道。很长一段时间里，社区里对 DOTS 动画的共识就是：要么用 Unity 官方那套仍处于 preview 阶段的 Animation 包，要么自己拿 Transform 数据硬算。两条路都不好走。直到我换了 Rukhanka Animation System 2，才算是真正把“ECS 角色动起来”这件事做顺了。
这篇文章不是官方文档翻译，是我用 Rukhanka 2 完整接了一个多角色战斗 Demo 之后的复盘。内容覆盖为什么要选它、数据怎么转、底层任务怎么组织、遇到的那些坑怎么排。如果你正在评估 DOTS 动画方案，或者已经从官方 Animator 切到 ECS 但卡在了动画这一步，这篇应该能帮你省掉不少弯路。
1. 为什么 DOTS 环境下动画系统是个老大难，Rukhanka 解决了什么
聊 Rukhanka 之前，先说清楚 DOTS 动画的痛点到底在哪。很多刚接触 ECS 的人会想当然地认为，DOTS 就是把 GameObject 换成 Entity，那 Animator 是不是也能直接换？答案是否定的。Unity 内置的 Animator 系统从架构上就绑定在 GameObject、Transform、MonoBehaviour 这套东西上，它依赖 AnimatorController 在游戏主线程上执行状态机和混合逻辑，输出结果直接写进骨骼 Transform。这套流程在纯 DOTS 项目里几乎没法用，因为你没法把一个 Entity 塞进 Animator 的输入，Animator 也不会把结果写到 ECS 的 ComponentData 里。
你可能会说，那用官方新的 Entities Animation 包不就行了？它确实把动画采样挪到了 Job 里，但问题在于它直到我写这篇文章时，功能完整度还处于“能用但别深挖”的阶段。比如它对 AnimationClip 的支持有严格限制，Blend Tree、IK、Root Motion 这些在传统项目中习以为常的功能，它要么没做，要么做得很浅。我在一个项目里试过用它跑普通的人物动画，光是处理多个动画片段之间的平滑过渡就折腾了两周，最后还是放弃了。
Rukhanka 2 的出现，其实就是冲着这个空白来的。它是一个完全跑在 DOTS 框架下的动画系统，核心思路是把 AnimationClip 的采样、骨骼层级变换、动画状态机全部拆成可并行的 Job，交给 Unity 的 Job System 和 Burst 去跑。它的输入是 Entity 上挂载的 AnimatorController 数据，输出会被写到一个骨骼 Entity 矩阵里。这套架构带来的直接好处是，动画计算不再依赖主线程，角色数量越多，和传统 Animator 的差距就越明显。
我实际测过一个场景，100 个角色同时播放不同的动画片段。原生 Animator 方案在主线程上的开销大概占用了 8 到 10 毫秒，换到 Rukhanka 2 之后，Burst 编译后的采样 Job 在 8 核机器上大概只花了 2 毫秒左右，而且是分布在工作线程里的，主线程几乎感知不到这段计算。
不过要提醒一下，Rukhanka 2 不是“一键迁移”的工具。它需要你做数据转换，把 AnimatorController 的运行时状态用 Baker 转成 ECS Component，把 SkinnedMeshRenderer 相关的骨骼数据转成 Entity 层级。这部分有学习成本，但一旦转过去，后续的灵活性是传统方案完全比不了的。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 从下载到跑通 Demo：Rukhanka 2 的环境要求与安装步骤
先别急着写代码，环境没配对，后面全是坑。Rukhanka 2 对 Unity 版本有硬性要求，我用的是 Unity 2022.3 LTS，官方推荐的最低版本是 2021.3 LTS，2020.3 也能跑但部分新特性不支持。如果你还在用 2019 版本，那基本不用考虑这个插件了，先把工程升级到 LTS 再说。
2.1 包依赖和推荐安装方式
Rukhanka 2 依赖以下几个核心包，缺一不可：
- Entities 1.0 及以上：这是 DOTS 的基础包，低于 1.0 的话 API 对不上，Baker 和 System 的写法会有大量报错。
- Graphics 1.0 及以上：负责 Entity 的渲染，Rukhanka 会把骨骼矩阵写到 Entity 的 ComponentData 里，再由 Graphics 渲染管线的 SkinMatrix 读取。
- Burst 1.8 及以上：没有 Burst，Rukhanka 的采样 Job 性能会大打折扣。
- Mathematics：数学库，这个一般随 Entities 自动引入，不用手动装。
安装方式有两种。第一种是直接从 Asset Store 下载，导入后 Unity 会自动拉取依赖包，这种方式最省心。第二种是从 Git URL 安装，适合你已经有一份 Rukhanka 的源码仓库，或者想手动管理版本的情况。我建议第一次用第一种，把节奏放稳一点。
导入完成之后，你会在 Project 窗口看到 Rukhanka 的目录，里面带了好几个官方 Demo 场景。这是最好的起步点，别一上来就动自己项目的模型，先把 Demo 跑通，理解它的数据流，再迁移到自己的资源上。
2.2 首次运行 Demo 常见的失败点
我最初导入 Demo 场景后直接点 Play，结果角色完全没反应，控制台报了一堆 FilterOut 相关的错误。折腾了半天才发现原因：Rukhanka 2 需要你在 Player Settings 里启用 unsafe code，否则 Burst 编译会失败。开启路径是 Edit -> Project Settings -> Player -> Other Settings -> Allow Unsafe Code，勾上之后还是不加，再回来跑 Demo 就没有基础问题了。
另一个容易忽略的是场景里必须有 AnimatorComponent。Rukhanka 2 不会自动给所有带 Animator 的 GameObject 创建对应 Entity，你得在场景里放一个有 Animator 的模型，并且确认 Baker 已经正确把它转成了 Entity。Demo 场景之所以能跑，是因为模型上的 AnimatorCulling 组件已经被预设好了。如果你是从空场景开始，记得手动挂一个 AnimatorController，且 Animator 的 CullingMode 不能是 Based On Renderers，否则角色可能被 culling 逻辑提前剔除掉。Rukhanka 2 文档里明确写了这一点。
把 Demo 跑通之后，先别急着追求功能，打开 Profiler 看一眼。你会注意到主线程上已经几乎没有动画相关开销了，动画采样相关的耗时都集中在 Worker Thread 的 Job 里。这一步确认完毕，你对后面要做的数据迁移也会有信心。
3. 核心架构拆解：Rukhanka 2 的动画数据流与任务管线
Rukhanka 2 之所以能跑出高性能，核心不在于哪个单一功能多“黑科技”，而在于它把整个动画计算链条彻底重构了。这一步里我从数据流开始讲，逐步拆到实际运行的 Job 管线。
3.1 从 AnimatorController 到 ECS Component：数据如何“搬”进 Entity
传统项目中，AnimatorController 是一份运行时的资产，Animator 组件会读取它并根据状态机逻辑计算出当前应该播放哪个 Clip、权重是多少、参数怎么变化。这套逻辑在 DOTS 下没法直接复用，所以 Rukhanka 2 用了 Baker 来做转换。
当你在场景里放置一个带 AnimatorController 的 GameObject 并标记为 Convert To Entity，Rukhanka 的 Baker 会生成一套 ECS Component：
| ECS Component | 作用 |
|---|---|
| AnimatorComponent | 持有 AnimatorController 的引用，记录当前状态、层信息、参数值 |
| AnimatorStateMachineComponent | 存状态机切换所需的数据，包含各状态对应的 AnimationClip 引用 |
| BoneEntityReferenceComponent | 保存骨骼层级的 Entity 索引，指向每一个骨骼位置 |
这套数据转换在一次 Baking 时完成，之后的运行阶段不再访问 AnimatorController 原资产，而是使用已经转换好的 ComponentData 和 BlobAsset。这一点非常关键，因为它彻底解耦了运行时对主线程资产的依赖。Baking 完成后，AnimatorController 资产本身甚至可以卸载，不影响运行。
BlobAsset 用得多是 Rukhanka 2 的一个明显特征。动画曲线数据、状态机转换条件、混合权重等都被打包成 Blob，这样 Job 访问数据时能做到零 GC 分配，也方便 Burst 编译后的代码直接从 Native 内存读取。
3.2 采样与骨骼计算的 Job 分工
运行时，Rukhanka 2 内部会启动多个 Job 来协作完成一帧的动画计算。整体链路大致是这样的：
- 动画状态机更新 Job：根据当前 AnimatorStateMachineComponent 的状态、参数、过渡条件，推算出这一帧每个层应该播放哪个 Clip 以及各自权重。
- 动画采样 Job：拿到需要播放的 AnimationClip 的动画曲线数据，根据当前时间和播放速度，在对应的时间点上采样出每个骨骼节点的局部变换。
- 骨骼层级融合 Job：把不同层的采样结果按照权重做混合。比如基础层播放“跑步”，动作层叠加“射击”，这两个 Clip 对同一个骨骼的局部旋转会有不同的输出，这个 Job 会按照配置好的 AvatarMask 和层权重把它们合成一个结果。
- 骨骼层级变换计算 Job：合成后的局部旋转、位置、缩放，需要从根骨骼开始一层层乘出每个骨骼的世界矩阵。这个 Job 是 Rukhanka 2 并行化做得最好的部分，因为它能按骨骼树的深度分层并行，同一层的骨骼没有依赖关系。
这四条链路是流水线式执行的，前一个 Job 的输出作为后一个 Job 的输入。因为全部是 Job 结构，Unity 的 Scheduler 会尽量把它们分配到多个工作线程上并行处理。
3.3 和传统 Animator 的关键差异：主线程 vs 多线程
我画过一张对比表，方便团队里新人理解两者差别：
| 维度 | 传统 Animator | Rukhanka 2 |
|---|---|---|
| 状态机计算 | 主线程代码，无法并行 | Job 内完成，可多线程 |
| 动画曲线采样 | 每帧通过本地缓存查曲线 | BlobAsset 直接读取，Burst 加速 |
| 骨骼层级矩阵计算 | Transform 层级遍历，依赖 Transform 组件 | 纯数学计算，输出到 NativeArray |
| 多角色扩展 | 开销线性叠加在主线程上 | 核数允许下近乎线性扩展的性能优势 |
这个差异不是简单地把代码从主线程挪到工作线程那么浅，它背后是一种不同的架构哲学：传统方案以 Animator 组件为单元组织计算，一个角色一个单元，单元之间天然并行不了太多；Rukhanka 2 则是把整个系统的计算当成一个流水线工厂，所有角色的状态机更新、采样、融合、骨骼计算分别集中到同一个 Job 里做。角色数量多的时候，Job 内部的批次处理效率远比逐角色串行处理要高。
4. 实战接入：把我的 RPG Demo 角色迁移到 Rukhanka 2 的完整流程
安装和原理都聊完了，实际操作才是最关键的。我拿一个真实场景举例：一个 RPG Demo，里面有 3 个角色，分别使用不同的 SkinnedMeshRenderer 和 AnimatorController，角色身上有简单的人物移动、攻击、受击状态切换，还有一根武器骨骼需要在攻击时动态旋转。
4.1 步骤一：把美术资源转换成 Rukhanka 可用的 Entity 预制体
首先你需要一个实体预制体（Entity Prefab）。可以在场景里拖一个角色模型，挂上 AnimatorController 和对应的 SkinnedMeshRenderer，给它加上 Rukhanka 提供的 Baker。右键 Convert To Entity 之后，角色的骨架层级会变成一长串 Entity，每个骨骼生成一个子 Entity，并且每个骨骼 Entity 上都会挂一个 BoneEntityReferenceComponent。这一步成功的话，你在 Entity Inspector 里能看到从根骨骼到手指末端的完整骨架树。
这里我想强调一个经验：转换之前先去检查模型的骨骼命名是否合规。Rukhanka 2 内部会用骨骼名字作为索引的一部分，名字里如果带了非法字符或者和别的骨骼重名，Baker 阶段容易产生重复索引。我有一次遇到一个模型，左右手臂的骨骼名都叫 “arm_01”，结果转换后整个骨架错位，动画播放时手臂直接飞了。后来在 Blender 里重命名成 arm_L_01 和 arm_R_01 才解决问题。
4.2 步骤二：配置 AnimatorController 状态机
Rukhanka 2 支持从原生 AnimatorController 资产直接读取状态机配置。你不用重写状态机编辑器，还是用 Unity 自带的 Animator 窗口设计状态和过渡。唯一要注意的是，Transition 里的 Has Exit Time 最好设为 false，用动画参数来控制切换，因为 Rukhanka 2 对 Has Exit Time 的实现是基于播放进度查询的，某些平台上的精度不如自定义参数准确。我实际测试下来，用 Has Exit Time 做有等待时间的过渡时，偶尔会出现过渡不触发或提前切换的情况，改成直接根据当前 Clip 时间判断就稳定多了。
参数支持方面，整数、浮点数、布尔类型都能正常读写。在运行时修改参数的方式，不是通过 Animator.SetFloat 这种 API，而是直接修改 Entity 上的 AnimatorComponent 的 AnimatorParameters 字段。这一点和传统开发习惯差异极大，需要适应。
csharp复制// 通过 ECS 修改动画参数的示例
SystemAPI.Query(ref AnimatorComponent ac).WithAll<PlayerTag>().ForEach((ref AnimatorComponent ac) =>
{
ac.SetFloat("Speed", currentSpeed);
ac.SetTrigger("Attack");
});
4.3 步骤三：处理 IK 和 Root Motion 的特殊情况
Rukhanka 2 对 IK 的支持分两档：基础版支持系统内置的 IK Pass 采样，也就是 Animator 里 OnAnimatorIK 那种方式，但性能一般；如果你用的是 FinalIK 这类第三方 IK 方案，就得用 Pro 版本，Pro 版本专门做了接口来对接 IK 解算结果。我 Demo 里的武器骨骼旋转用的是 FinalIK，所以直接上了 Pro 版本，把 FinalIK 的 IK 结果写到一个 NativeArray 里，Rukhanka 在骨骼融合阶段直接用这个数组覆盖对应骨骼的局部旋转。这样 IK 计算和动画采样都跑在工作线程上，整体没有额外的主线程负担。
Root Motion 这里要单独提醒。Rukhanka 2 对 Root Motion 的支持不是开箱即用的，你需要手动处理。做法是在 Animator 组件里勾选 Apply Root Motion，Rukhanka 会把 Root 骨骼的增量位置/旋转写到 AnimatorComponent 里，然后你的移动系统需要读取这个增量并施加到角色的 Translation 组件上。官方文档里推荐的做法是，在动画状态机里给 Root 骨骼单独做一个动画通道，或者你在移动系统里直接计算增量。
csharp复制// 读取 Root Motion 增量的示意
float3 deltaPos = animator.rootMotionDeltaPosition;
float3 deltaRot = animator.rootMotionDeltaRotation;
// 应用到角色 Entity 的位移组件
localTransform.Position += deltaPos;
localTransform.Rotation *= quaternion.Euler(deltaRot);
如果你不做这一步，角色会表现出“跑步但位置不动”的诡异行为。这个坑我踩过，排查了半天。
4.4 步骤四：多角色实例化和性能实测
所有配置完成之后，我就开始压测角色生成。写了一段简单的 Spawn System，每帧生成若干角色 Entity，让它们随机播放不同动画。前面提过 100 个角色的测试结果，我再补充一个对照组：同一个 Demo 场景，用原生 Animator 的方式同样生成 100 个角色，其他代码不动，主线程耗时 9.3ms，Rukhanka 版本主线程耗时 1.8ms。这 1.8ms 里大部分还是 Update 里我自己的逻辑，跟动画本身关系不大。工作线程上 Rukhanka 花掉的 2ms 和主线程的 1.8ms 是重叠的，所以实际对帧耗时的影响只有 2ms 左右。这个结果在意料之中，也让我下定决心把所有演出类动画都迁到 Rukhanka 上。
5. 性能数据与底层原理：为什么它能比原生 Animator 快出数量级
性能对比这件事，如果只看刚才的 9.3ms vs 1.8ms，你可能觉得“Rukhanka 只不过是把主线程耗时转移到了工作线程”。这么说也没错，但限制了理解它的真正潜力。它快的原因并不只是并行化，而是数据布局和计算方式的彻底重写。
5.1 Burst 编译后的代码和 AoS/SoA 内存布局
传统 Animator 在采样动画曲线时，动画数据是存为 AnimationCurve 对象的，每个曲线对象都是一个托管对象，访问的时候有 GC 压力，而且在 CPU Cache 层面，曲线对象散布在堆里，访问不连续。Rukhanka 2 把动画曲线烘焙成一个紧实的 BlobArray，按骨骼索引和曲线类型顺序排列。这样采样 Job 在遍历骨骼曲线时，内存访问模式基本是线性的，CPU Cache 命中率远高于传统方案。专业点讲，这就是典型的 SoA（Structure of Arrays）布局优化的效果。
简单类比，传统方案是每本书各放一个文件柜，你写论文的时候要跑二十个文件柜去拿二十本书；Rukhanka 是把这二十本书按顺序摞在一个文件柜里，你从头走到尾一次全拿完。数据密集型计算的性能差距，很大程度上就是这么拉开的。
5.2 Job 调度开销和批处理收益
很多人担心 Job 数量多会不会导致调度开销过大。Rukhanka 2 的做法不是为每个角色生成几十个 Job，而是把同类型的计算放进同一个 ParallelJob 里。比如角色 A 的骨骼层级计算和角色 B 的骨骼层级计算，会被 Batch 到同一个骨架计算 Job 中处理，只是按 Entity 索引分成多个批次。这样 Job 总数不会随角色数量线性膨胀，Unity 的 Job Scheduler 也不需要频繁切换上下文。这也是为什么角色数量多的时候，Rukhanka 的优势越来越明显。
5.3 和官方 Entities Animation 的对比结论
官方 Entities Animation 包我实测过一版，它的核心思路也是 Job 采样，但它在 BlendTree 和动画层级的支持上明显落后。Rukhanka 2 用和 Unity 官方相同的 AnimatorController 资产格式，却实现了更多的运行时功能。比如多图层、AvatarMask 遮罩、IO 混合这些，官方包要么不支持要么体验残缺，Rukhanka 2 基本能直接兼容。当然这不是说官方包没有价值，它的代码更简洁，适合深入学习的场景，但你要快速出商业方案，Rukhanka 2 的省心程度高得多。
6. 踩坑排错的完整链路：从角色 T-Pose 到动画异常跳变
最后这部分专门讲问题排查。Rukhanka 2 虽然解决了 DOTS 动画方案缺失的问题，但它毕竟是一个复杂的插件，踩坑是难免的。我把自己碰到的高频问题整理成了排查链路，按图索骥能省大量时间。
6.1 角色 T-Pose 不动：从 Baking 到 Runtime 的完整排查路径
有一次我把一个新模型换进项目，跑到场景里角色呈 T-Pose，动画完全没反应。这种问题表面看像是动画状态机没驱动，但实际原因有很多种。我当时的排查顺序是：
- 先确认 Baking 阶段是否成功：打开 Entity Inspector，查看角色 Entity 上有没有 AnimatorComponent、AnimatorStateMachineComponent 和 BoneEntityReferenceComponent。如果三个都在，说明 Baker 阶段没大问题。
- 检查动画片段是否被正确引用：打开 AnimatorWindow 里的每个状态，确认 Motion 字段确实绑定了 AnimationClip。如果 Motion 为空，状态机推不出任何动画数据，角色自然保持绑定姿势。这一步我发现我的新模型绑定的 Clip 全是空的，原因是在模型导入时动画资源没有被自动拆出来。
- 检查骨骼 Entity 的层级和索引：用 Entities 的 Hierarchy 窗口展开角色骨架树，看根骨骼和子骨骼的 Entity 关系是否完整。如果有骨骼没生成独立 Entity，说明骨骼的 Transform 没有被正确识别为可动画骨骼。这一步排查时我发现，只有挂了 SkinnedMeshRenderer 的骨骼才会被 Rukhanka 的 Baker 处理，单纯挂着普通 Transform 的物体是不参与计算的。
- 检查运行时 System 是否有报错：Rukhanka 的 System 会把异常信息打印到 Console，比如“Bone index out of range”这类。如果看到这类错误，说明骨骼索引和动画采样结果对不上，多数原因是模型重新导入时骨骼顺序变了，但旧配置还指向旧索引。解决办法是重新 Baking。
这一套流程走下来，T-Pose 问题基本能在 10 分钟内定位到根因。
6.2 动画跳变或者错位：权重混合和过渡条件的问题
另一个高频问题是动画播放到一半突然跳到另一段，或者身体的某个部位扭曲错位。
跳变问题我先检查过渡条件。Rukhanka 2 对 Has Exit Time 的处理在前面提过不够顺滑，所以优先排查所有 Transition 是否把 Has Exit Time 关掉了。如果确认还是跳变，下一步把 AnimatorParameters 的日志打开，看是哪个参数的突然变化导致状态切换。有一次我遇到攻击动画反复跳变，检查后发现是一个 Bool 参数在攻击状态下被攻击恢复逻辑重置了，导致状态机以为自己还在待机状态，从而强制切回待机。
错位问题多半出在动画混合权重上。Rukhanka 2 支持多图层和 AvatarMask，但如果你在某个层上配置了 Mask，而 Mask 选中的骨骼和 Clip 实际修改的骨骼不一致，就会产生错位。比如你的 Clip 修改了 Spine 的旋转，但 Mask 把 Spine 给屏蔽了，结果动画层的权重再高也不会影响视觉。解决方法是打开 Mask 编辑器，逐个骨骼检查是否真正包含了你想要动画的骨骼。
6.3 动画与物理系统互动的顺序问题
Rukhanka 2 的动画计算发生在 ECS 的 LateSimulationSystemGroup 之前，具体在 TransformSystemGroup 之后。如果你在自定义 System 里读取骨骼位置来驱动物理或者伤害判定，需要保证你的 Update 时机在动画之后。最简单的方法是把你的 System 放入 SimulationSystemGroup 的后期，或者在代码里用 [UpdateAfter(typeof(RukhankaAnimationSystemGroup))] 显式标记。
我在做武器碰撞检测时遇到过这个问题，判定一直发生在上一帧的骨骼位置，导致攻击判空。定位到原因后加了一行 UpdateAfter，问题立刻解决。这种 System 顺序问题在纯 ECS 项目里很常见，不是 Rukhanka 特有的，但因为它把动画计算挪到了 Job 里，导致这个时序边界更容易被忽略。
6.4 性能回归排查：如果你的角色数量增加后反而变卡
最后提一个性能排查建议。如果角色数量上去之后，Rukhanka 的 Job 耗时没有按预期线性增长，而是突然跳高，第一件事打开 Profiler 看是不是有 Burst 编译未命中的情况。第一次运行新动画 Clip 时，Burst 需要把对应采样代码编译成原生指令，这个过程会有一次性开销。你可以在项目启动阶段预载所有动画片段，或者用 [BurstCompile] 的预热机制提前调用一次采样。我实测预载之后，第一次正式 Play 时的卡顿从 200ms 降到了 10ms 以内。
另一个常见的性能问题来自 GameObject 和 Entity 的混用。如果你的角色是用 Hybrid ECS 的方式，部分逻辑还是 GameObject 驱动，那角色数量的增长依然会拖累主线程。Rukhanka 2 能优化的只是动画这一段，你不能指望它把 Transform 同步和 MonoBehaviour 更新也一并提升。迁到 DOTS 动画系统这一步，就该把 GameObject 部分彻底断干净，否则性能瓶颈会转移到别处。
7. 一些总结性的使用建议
写到最后，整理几个基于 Rukhanka 2 实际使用下来的建议，方便你做个整体判断。
如果是纯 DOTS 项目，或者你正在把现有项目往 ECS 迁移，Rukhanka 2 几乎是目前性价比最高的动画方案。它和 Unity 内置 Animator 的编辑器工作流兼容，团队切换成本低，运行性能又足够撑起大规模角色场景。如果你的项目还是传统 GameObject 架构，那就没必要硬上 Rukhanka，传统 Animator 在几十个角色以内的场景里完全够用。
如果你已经决定上 Rukhanka 2，要注意版本锁定。这个插件的迭代速度不算慢，我遇到过一次从 2.1 升到 2.2 之后，部分 Baker API 变了，需要重新改一遍场景的转换逻辑。建议是在项目初期锁定一个稳定版本，不要频繁追新。
另外一个小技巧：Rukhanka 2 官方 Discord 社区值得常逛。很多骨骼命名、BlendTree 权重、Baker 报错的解决方案，官方文档里没有写全，但社区里已经有人贴出了完整排查过程。我在里面找到过两个骨骼名冲突导致动画错位的案例，处理思路比我自己瞎猜高效得多。
希望这篇解析能帮你少走点弯路。动画系统这种东西，不实际跑一遍很难体会出好坏，建议你拿一个自己的 Demo 模型试一下，跑完对比性能数据，再决定要不要全面切过去。