Android MotionLayout 深度解析：从 Scene 约束切换到 KeyFrame 插值的动画状态机工程实践
做复杂交互动画时，很多人一开始用 ObjectAnimator 或 ViewPropertyAnimator，简单场景完全够用。但一旦交互里混进拖拽、中断、回退、状态恢复，代码很快就会散掉——位置在改，透明度在改，手势还在改，最后没人说得清界面此刻到底处于哪个状态。
MotionLayout 的价值不在于让 View 动起来，而在于把动画建模成状态机。你定义的是一组 ConstraintSet 状态，以及状态之间如何过渡；插值、拖拽映射、进度同步都交给引擎处理。这一点，正是它比传统属性动画更适合工程化落地的原因。
ConstraintSet 本质上是离散状态
ConstraintSet 可以理解成某个界面的完整姿态：位置、尺寸、约束关系、部分属性值全在里面。MotionScene 描述状态图：有哪些节点，节点之间怎么走，哪条边能被手势驱动。
关键在于，MotionLayout 不直接操作 View，而是在 start/end 两个约束解之间推进 progress。UI 不再是”一堆属性被分别改动”，而是”一个状态沿着过渡边连续移动”。在中断恢复、旋转重建、深链路回跳等场景下，这种建模稳定得多。
<MotionScene xmlns:android="http://schemas.android.com/apk/res/android"
xmlns:motion="http://schemas.android.com/apk/res-auto">
<ConstraintSet android:id="@+id/list" />
<ConstraintSet android:id="@+id/detail" />
<Transition
motion:constraintSetStart="@id/list"
motion:constraintSetEnd="@id/detail"
motion:duration="320">
<OnSwipe
motion:touchAnchorId="@id/card"
motion:touchAnchorSide="top"
motion:dragDirection="dragUp" />
<KeyFrameSet>
<KeyPosition motion:target="@id/card"
motion:framePosition="50"
motion:percentX="0.5"
motion:percentY="0.2" />
<KeyAttribute motion:target="@id/title"
motion:framePosition="70"
android:alpha="0.0" />
</KeyFrameSet>
</Transition>
</MotionScene>这段配置表达很清楚：list 和 detail 是两个稳定状态，用户上滑时沿这条 Transition 前进。framePosition 不是时间戳，而是 0 到 100 的归一化进度点。
KeyFrame 改的不是结果，而是路径和曲线
很多文章讲到这里就停了，好像 MotionLayout 只是”两个布局之间自动补间”。实际并非如此。没有 KeyFrame 时，引擎只知道起点和终点，插值路径通常比较机械。复杂交互之所以自然，靠的是中间控制点。
最常用的三类 KeyFrame：
KeyPosition：控制空间路径。决定控件在某个进度点应该偏向哪里，适合做卡片上抛、头像绕行、FAB 避让这类几何运动。
KeyAttribute：控制属性曲线。alpha、scale、rotation 不必跟位置同步，可以延后、提前，甚至在局部加速。
KeyCycle：叠加周期变化。适合微抖动、回弹感，不适合拿来堆主动画。
从实现角度看，MotionLayout 会为每个目标 View 的每类属性建立插值器，KeyFrame 相当于往样条曲线里插控制点。所以它更像一套声明式动画求解器，而不是 XML 版补间动画。
在实际项目中踩过这样一个坑：只改了 ConstraintSet，没加任何 KeyPosition，结果卡片从列表飞到详情页时路径是直的，视觉上像”平移 + 放大”的生硬拼接。补一个 40% 或 50% 的中间点后，动线立刻自然很多。
工程落地：先设计状态图，再写 Scene
MotionScene 一大就容易失控。最常见的问题不是不会写动画，而是把业务状态和视觉状态混在一起——“已登录""已收藏""展开详情""正在拖拽”被塞进同一个 Scene，转场数量会指数增长。
更合理的拆分方式：
- 视觉状态独立建模：列表态、详情态、半展开态。
- 业务状态单独管理：登录、权限、数据加载交给
ViewModel。 - 转场只描述视觉演进：不要把业务判断写进一堆
KeyTrigger回调。
KeyTrigger 适合做轻量副作用，比如超过某个阈值打点、触发一次震动。它不适合承载核心业务逻辑，因为 progress 在拖拽时会来回穿越阈值，副作用很容易重复触发。
另一条经验：不要让一个 Transition 承担太多语义。 列表到详情、详情到编辑、编辑到关闭，最好是三条边，不是一条边上堆满条件。这样排查问题时，能明确知道是哪一段插值出了偏差。
调试重点：状态一致性优先于动画时长
MotionLayout 的手感问题，多数时候不是 duration 设错了，而是约束和路径不一致。调试时通常先看三件事：
- 起终态是否完整：两个
ConstraintSet都要能独立成立，不能依赖运行时残留属性。 - 路径是否符合交互预期：打开
motionDebug看轨迹，确认控件走的不是直线抄近路。 - 拖拽锚点是否合理：
touchAnchorId选错，progress 和手势位移就会脱节，用户会觉得”黏手”。
代码侧只做状态同步，不在监听器里补动画：
motionLayout.setTransitionListener(object : TransitionAdapter() {
override fun onTransitionCompleted(layout: MotionLayout, currentId: Int) {
viewModel.onUiStateSettled(currentId) // 只同步状态，不补属性动画
}
})这类监听器的职责是”记录状态已经稳定”，不是”动画结束后再手动修一点”。一旦开始在回调里补 translationY、补 alpha，基本说明 Scene 建模已经歪了。
实践建议
把 MotionLayout 用好，有三条最实用的原则：
- 先画状态图，再写 XML。把节点和边想清楚，Scene 会简单很多。
- 优先用
KeyPosition调路径，用KeyAttribute调节奏。别上来就靠时长和插值器硬拧手感。 - 让
ConstraintSet保持语义化。一个状态对应一个稳定界面，不要让它依赖”上一次动画停在哪”。
MotionLayout 最强的地方，不是它能做出多炫的动画，而是它把复杂交互压缩成了可推理、可调试、可维护的状态机。在页面越来越重、交互越来越碎的 Android 项目里，这一点比动画本身更值钱。