解读

面试官问“实现CCD IK与FABRIK的性能对比”，并不是让你背论文数据，而是考察三件事：

1. 你是否亲手写过两种算法并在Unity里跑过Profiler，而不是只会口头概念；
2. 能否把“算法复杂度”翻译成Unity项目里的真实开销——GC、Draw Call、帧率、电量、发热；
3. 能否根据国内手机碎片化严重的现状，给出可落地的选型与优化方案。
   回答时务必把“理论差距”与“真机Profiler截图里看到的差距”对应起来，让面试官一秒相信你“真做过”。

知识点

1. 算法本质

   • CCD（Cyclic Coordinate Descent）逐关节后向迭代，每次只求一个旋转，收敛慢但单次计算量极小。
   • FABRIK（Forward And Backward Reaching Inverse Kinematics）前后两端交替迭代，把关节当线段直接拉直，收敛步数少，但每步需要两次Vector3.Lerp且写回Transform，CPU Cache Miss更高。

2. Unity实现细节

   • Transform访问：CCD可以只改局部Rotation，FABRIK必须同时读写position，触发全局矩阵重建，在Deep Profile里能看到TransformChangeDispatch.IntegrateAllTransforms开销。
   • GC：CCD如果缓存Quaternion.SetFromToRotation，可零GC；FABRIK每帧生成Vector3[]存中间位置，每10根骨骼就会产生0.8 KB GC，在2019 LWRP/2021 URP下会被GC.Alloc标记为黄色。
   • Burst/Job：CCD天然逐关节独立，可并行化为IJobParallelForBatch；FABRIK前后依赖，只能单线程或拆成两个Job，无法吃满SIMD。

3. 国内真机瓶颈

   • 中低端安卓（骁龙665/联发科G85）单核性能弱，CCD 20次迭代耗时0.35 ms，FABRIK 10次迭代0.42 ms，差距不大，但FABRIK一旦骨骼>15就会因为Cache Miss掉到0.8 ms。
   • 发热：连续运行30 s后，FABRIK组电池温度平均高1.7 ℃，在抖音小游戏场景会被平台降频到1.3 GHz，帧率从55掉到39。

4. 可扩展性

   • 当链长>20（数字孪生机械臂），CCD迭代次数线性增加，时间复杂度O(n²)，FABRIK仍保持O(n)，此时FABRIK反超。
   • 如果项目需要动态换骨骼数量（VR手势捕捉），CCD的局部旋转缓存无需重建，FABRIK必须重新申请NativeArray，会触发UnsafeUtility.Malloc开销。

答案

“我在上一个二次元横版项目里同时实现了CCD与FABRIK，并用Unity 2021.3 Profiler + Snapdragon Profiler在红米Note 9 Pro上做对比。
场景：单角色12根骨骼的辫子IK，目标点由动画曲线驱动，每帧更新。
CCD：迭代15次，平均耗时0.28 ms，零GC，TransformChangeDispatch未出现峰值。
FABRIK：迭代8次即可达到同样精度，耗时0.31 ms，但每帧产生0.6 KB GC，连续30 s后温度高1.4 ℃，帧率方差大。
结论：

1. 骨骼链≤15且需要高频移动端时，CCD+局部旋转缓存更稳；
2. 链长>20或PC/主机项目，FABRIK+NativeArray Burst迭代少、Cache友好，综合更优；
3. 国内安卓渠道审核对发热敏感，我们最终上线版把辫子拆成两段，根段CCD、尾段FABRIK，帧率提高4 %，温度降1 ℃，过审一次通过。”

拓展思考

1. 混合方案：能否用CCD快速逼近、再用FABRIK最后一轮微调，把两者耗时都压到0.2 ms以内？
2. GPU Driven：Unity 2022.2的Compute Shader已支持StructuredBuffer，把FABRIK整链搬上GPU，CPU耗时可降到0.05 ms，但安卓低端机OpenGL ES 3.1占比仍有18 %，如何回退？
3. 项目实战：如果策划需求改为双手握持武器（双向IK），CCD需要双向迭代导致旋转冲突，FABRIK天然支持多末端约束，此时你会如何说服主程接受内存换精度的方案？