Android Transition Framework实战：场景切换动效原理与踩坑指南

当你在列表里点击“展开”按钮，子项瞬间出现、没有一丝丝过渡，整个界面像跳帧一样生硬——我最初接手某个模块时，面对的正是这种体验。后来我把android_transition_framework吃透，用它重构了整个场景切换动效，这才体会到这套框架真正的价值：它不只是一个动画工具，而是用“场景”思维帮你把复杂的View状态变化自动转成动画。这篇博文我会从框架的核心设计讲起，包含原理、完整实操案例、以及我实际踩过的坑和排查记录，适合刚接触过渡动画、也在RecyclerView和Fragment切换中被卡住的Android开发者。

1. 内容整体设计与思路拆解

1.1 为什么选TransitionFramework而不是直接写Animator

很多人在做界面切换动画时，第一反应是拿到目标View，然后手动调用ObjectAnimator去移动、缩放、改变透明度。这个思路简单直接，但问题也很明显：一旦界面里不止一个View要动，一旦View的位置依赖布局参数而不是绝对坐标，一旦需要同时处理布局变化和显示隐藏，手写Animator的代码量就会迅速膨胀，而且极易出现“动画和实际布局状态不同步”的Bug。

Transition Framework的核心思路是“只声明起点和终点，动画过程交给框架”。你不需要关心中间每一帧具体怎么算，只需要告诉它：界面在当前状态，界面在目标状态，框架会自己对比两个状态下各个View的属性差异，然后生成一组Animator去平滑过渡。

这个思路的价值在于：它天然契合Android的视图层级模型。View的位置、大小、透明度、背景色、裁剪区域、滚动位置——这些信息都可以作为“场景状态”的一部分被记录下来。框架对比前后状态时，本质就是在做Diff，这一点和我们在列表里做DiffUtil去刷新Item是同一个哲学。

我实际用下来，最舒服的一点是它和布局天然解耦。举个例子：我负责的一个搜索页面里，输入框聚焦后要带动筛选栏展开、历史记录区域上移、按钮淡入，三个容器、六七个View一起动。如果用传统的Animator方案，我需要手动计算每个View在新布局中的位置偏移，还要考虑软键盘弹出对根布局高度的影响，稍不留神就会跑位。而用Transition，我只需要调整布局参数，然后把过渡动画声明成一组规则，剩下的全部交给框架。

1.2 核心模块划分与工作流程

理解这套框架，只需要抓三条线：Scene（场景）、Transition（过渡规则）、TransitionManager（调度者）。

• Scene负责描述界面在某个时刻的完整状态。一个Scene持有两个东西：一个ViewGroup作为场景根节点，以及一个代表“进入该场景时如何布置孩子”的View对象或布局文件。实际开发中，很多人会用一个xml布局文件来声明场景内容。
• Transition负责描述“从场景A变到场景B时，属性发生变化的所有View应该播放什么样的动画”。它内部维护着一组CaptureData，分别是起始值、终值、动画映射关系。
• TransitionManager则负责把整个流程串起来。最核心的底层流程是：保存当前场景状态、把新场景的布局安装到根容器、强制触发layout、等下一帧记录终态、对比生成Animator、播放。

很多人在代码里没见过Scene类，因为90%的场景你不需要直接写new Scene()。你只要调TransitionManager.go()传一个场景，或者更简单地调TransitionManager.beginDelayedTransition(container)——前者是“显式场景切换”，后者是“延迟过渡”，也就是在当前容器里改完布局后，框架自动对比前后状态。

这里有个重要的执行细节：beginDelayedTransition调用之后，它会先把当前容器里的状态作为起始态记录下来，然后注册一个OnPreDrawListener。你在调用beginDelayedTransition之后修改View属性（比如visible、坐标、尺寸），下一帧绘制前框架就会拿到终态，然后自动生成动画。也就是说，关键不是“声明时机”，而是“修改属性的时机必须在beginDelayedTransition和下一帧之间”。

1.3 项目中最常见的三个应用模式

我拆过不少项目里的过渡动画需求，它们表面上千奇百怪，实际上都能归到三个模式里：

第一个模式是状态切换。典型场景是搜索框展开筛选栏、点击卡片展开详情浮层、设置项点击收起子面板。这类需求的特点是同一个容器里的ViewVisibility、位置、尺寸会发生变化，但View本身不会跨容器移动。用beginDelayedTransition就是标准解法。

第二个模式是页面流转。比如Tab切换、页面堆叠切换、或者同一个区域内两个功能模块互换。这类需求我习惯用TransitionManager.go()配合预设的Scene来写，因为场景之间的差异比较清晰，且经常要用TransitionSet组合多个动画（淡入淡出+位移+缩放一起上）。

第三个模式是数据驱动刷新。列表数据变化后，Item内部的子View需要平滑调整位置。这个在用RecyclerView时特别常见，因为Item内部状态变化后，RecyclerView并不会自动给你做过渡动画，它只会重新绑定布局。但如果你在局部刷新前包一层beginDelayedTransition，Item内部的子项就会自动“飘”到新位置。

2. 核心细节解析与实操要点

2.1 Transition的生命周期——想不踩坑必须先懂它

Transition框架运行的核心单位是Transition对象，它有三个关键回调方法：captureStartValues、captureEndValues、createAnimator。整个生命周期大概是：

1. 框架开始过渡时，遍历场景根容器下的子View，为每个View调用captureStartValues，把当前属性存进TransitionValues对象。
2. 新场景的布局安装、执行完layout之后，框架再次遍历容器，为每个View调用captureEndValues。
3. 框架把start和end两个Map传给你写的createAnimator（如果是内置Transition，则是内置逻辑在处理），你用它生成Animator并返回。返回的Animator会被塞进AnimatorSet里统一播放。
4. 动画结束后框架回调onTransitionEnd，然后清理过渡相关的状态。

这里最核心的认知是：你把“过渡想要什么动画”的定义和“具体每个属性怎么变化”的实现分开。框架负责收集和匹配，你负责决定动画形式。

自定义Transition时你真正要实现的，其实就是：在captureStartValues和captureEndValues里存你感兴趣的值，在createAnimator里根据start和end的差集去创建属性动画。

我见过不少刚接触的人在这里直接把动画写在createAnimator里，但实际上createAnimator可能压根不会被调用——如果某个View在start和end中都没有被捕获到，或者它不在Target范围内，框架根本不给你创建动画的机会。这个要记住：createAnimator不是“每个View都调”，而是只有“前后都有值且确实有差异”的View才会被处理。

2.2 场景切换时状态是怎么被捕获的——onPreDraw和布局时序

很多人疑惑：我明明在beginDelayedTransition之后立刻改了View的位置，为什么动画没生效？原因要回到“什么时候捕获终态”这个问题上。

代码大概是这样：

TransitionManager.beginDelayedTransition(rootView, fadeAndMove); childView.setVisibility(View.VISIBLE); ((ViewGroup.MarginLayoutParams) childView.getLayoutParams()).topMargin = 200;

beginDelayedTransition执行后，框架通过ViewTreeObserver.OnPreDrawListener挂了一个监听，而这个回调是在下一帧绘制前才触发的。所以你在同一帧同步修改布局参数，下一帧来的时候，框架看到的就已经是新布局了。关键就是：所有修改操作必须在同一帧内完成，不能用一个postDelayed把属性修改推迟到下一帧，那样终态捕获时看到的还是旧值，Diff结果为0，自然没有动画。

另外有个容易忽略的点：captureEndValues时依赖容器完成layout。如果你的根容器尺寸为0，或者View还没被正确attach，终态捕获的值都是0，动画表现就会很奇怪，最常见的是“View从左上角飞出来”或者“透明度直接变成0”。

所以我做过渡动画前会习惯性检查一件事：触发动画的容器是否已经完成了初始化布局。如果是在Activity的onCreate里立刻调beginDelayedTransition，然后在下一帧之前修改布局参数，往往会有问题，因为此时布局还没完成。可靠做法是把过渡放到布局完成之后再触发，比如用View.post()或者观察一次布局回调。

2.3 内置Transition能力对照表——直接用别重复造轮子

框架自带了一批实现好的Transition类，覆盖了绝大多数的UI变化场景。我把它们整理成一张表，方便你按需求查：

如果你只是做“显示/隐藏”的动画，直接用Fade即可；做卡片平移展开，ChangeBounds是主力；需要位移和缩放一起的，优先组合ChangeBounds和ChangeTransform。这里有个经验之谈：很多新手会自己写一个Transition去处理位置变化，其实ChangeBounds已经帮你处理好了，它内部对View设置了圆角裁剪、硬件层等优化，自己写很难做得比它更稳。

要注意的是，ChangeBounds对“跨父容器移动”是无效的。一个View从父容器A移动到父容器B，ChangeBounds捕获到的start和end是两个不同对象状态，如果不做额外处理，动画会乱套。框架里解决这个问题的途径是“Reparent”逻辑，但它的实现比较有限，需要配合手动处理，我后面会详细说这个坑。

2.4 TransitionSet的编排策略与Target约束

TransitionSet就是“一组Transiton按规则编排”。最核心的是它的ordering属性，有两个值：orderingTogether表示所有子Transition同时播放，orderingSequential表示逐个播放。实际项目中我一般这么用：页面级切场用Sequential（先淡入后移动，有层次感），局部展开收起用Together（同时移动和缩放，更紧凑）。

另一个极其重要的能力是addTarget和removeTarget。它可以限定Transition参与作用的View范围，避免动画作用于全容器导致无关View闪烁。

举个例子：你的页面上有一个列表和一个标题栏，当你只想让列表区域做缩放过渡，而标题栏纹丝不动时，Target机制非常好用。用代码写是这样的：

Fade fade = new Fade(); fade.addTarget(listView);

也可以加TransitionName，这个方法比Target更常见，因为它可以跨场景匹配同一个View：在两个场景中给同一个View设置同样的transitionName，框架就会自动认为它们是同一个View，从而进行动画过渡。类似共享元素的效果，但在Framework层是通用的View匹配机制。

我把这个特性用在搜索页到结果页的切换里：用户点搜索词后，搜索输入框携带文字内容，平滑移动到结果页的搜索框位置上，视觉上非常连贯。

2.5 XML声明方式与代码方式的选择

Transition框架官方支持XML声明过渡规则，放在res/transition目录下。比如这样声明一个组合过渡：

<transitionSet xmlns:android="http://schemas.android.com/apk/res/android" android:transitionOrdering="together" android:duration="300"> <fade android:fadingMode="fade_in" /> <changeBounds /> <changeTransform /> </transitionSet>

然后在代码里加载：

TransitionInflater.from(context).inflateTransition(R.transition.search_expand)

XML方式的好处是规则集中管理、便于替换和参数调整，适合“规则比较固定”的场景。代码方式适合动态创建、或需要根据业务逻辑动态组合的过渡。我个人的习惯是：静态组合用XML，动态逻辑用代码，两者搭配使用。

3. 实操过程与核心环节实现

3.1 案例一：用beginDelayedTransition实现列表Item展开收起

这是最典型的场景。某应用的信息流列表里，点击一条卡片会展开操作按钮区域，再点一下收起。我之前直接setVisibility的时候，界面瞬间跳变，毫无过渡感。后来改成过渡方案，效果立刻自然很多。

首先在RecyclerView的ViewHolder里点击事件中套上过渡：

final ViewGroup itemRoot = holder.itemView; TransitionManager.beginDelayedTransition(itemRoot, new TransitionSet() .addTransition(new ChangeBounds()) .addTransition(new Fade()) .setDuration(260)); actionPanel.setVisibility(isVisible ? View.GONE : View.VISIBLE);

这段代码的核心逻辑是：让itemRoot作为场景根，在下一帧绘制前把actionPanel的Visibility改掉，框架自动对比前后状态，给actionPanel生成淡入淡出+位置变化的动画。因为ChangeBounds会监听layout变化，当itVisible翻转后，其他子View会因为面板的挤压而移动，这些移动也会被自动过渡。

这里有几个细节很关键。第一，beginDelayedTransition的根容器越小越好，作用范围只包含需要动画的区域，不要用整个RecyclerView当作根容器，否则框架会遍历所有可见Item的View做捕获，列表刷新时很容易卡顿。第二，不要在RecyclerView的Adapter里直接对itemView做beginDelayedTransition，那会干扰RecyclerView自身的复用逻辑，最好在点击事件的ViewHolder内部处理。

第三，duration不宜太长。列表场景中，260毫秒左右是比较舒服的区间，太长会让用户觉得列表卡顿。

这个方案我实测下来，对Item局部展开的动效已经完全够用，不需要引入额外动画库。一个可能的改进是配合硬件加速，但列表场景中要慎重，因为硬件层会占用内存，如果页面里同时有大量的Item在做动画，反而会OOM，后面我会细说。

3.2 案例二：用TransitionManager.go实现页面级场景切换

另一种常见需求是页面内容整体切换。比如首页点击分类Tab，下方内容区域从推荐流切换到关注流，效果可以是整体淡入淡出加轻微位移。用Scene可以这样写：

先准备两个布局，一个home_scene.xml代表推荐流，一个follow_scene.xml代表关注流，然后在代码中创建Scene并触发切换：

Scene scene = Scene.getSceneForLayout(content, R.layout.follow_scene, this); Transition transition = new AutoTransition(); transition.setDuration(400); TransitionManager.go(scene, transition);

这个方法每次切换时会自动把旧的布局移除，安装新的布局，并在过渡过程中做新View的淡入、位置平滑移动。非常省事，因为你不必手动处理View的add、remove。

这里有个必须注意的点：TargetView和TransitionName的搭配。当两个Scene里各自有相似功能的View（比如列表标题），如果你希望它们之间做位置联动，需要给它们设置相同的transitionName。否则框架会认为这是两个完全不同的View，动画就会退化成“旧View淡出、新View淡入”的默认效果，视觉感受差一截。

场景切换中，过渡动画与Fragment事务结合是另一个高频玩法。虽然现在很多页面切换已经改用Fragment自带的动画了，但TransitionManager.go在“单Activity多布局切换”这种场景里还是更轻量。如果你需要的是真正的Fragment共享元素过渡，还是建议用官方在Fragment里提供的setSharedElementEnterTransition方案，它们两个在原理上是相通的，只是入口不同。

3.3 案例三：自定义一个圆角裁剪的Transition

内置Transition虽然覆盖广，但总有特殊情况匹配不上。我做过一个需求：卡片从方形渐渐变圆角，然后尺寸缩为一个小圆点，最后消失。这个效果ChangeBounds做不了，因为圆角是控件内部的绘制逻辑，不能靠普通属性动画直接搞定。这时候就得写自定义Transition了。

这个自定义Transition我命名为RoundCornerTransition，它会提取View的背景色和圆角半径，然后在动画过程中不断重绘圆角轮廓。核心思路：

• captureStartValues里记录起始圆角半径、背景色、位置。
• captureEndValues里记录终态圆角半径。
• createAnimator里创建ObjectAnimator，动画过程中根据插值更新圆角和背景色，并触发view.invalidate()。

伪代码大致如下：

public class RoundCornerTransition extends Transition { private static final String PROP_RADIUS = "pRadius"; private static final String PROP_COLOR = "pColor"; @Override public void captureStartValues(TransitionValues values) { View view = values.view; if (view instanceof RoundedView) { RoundedView rv = (RoundedView) view; values.values.put(PROP_RADIUS, rv.getCornerRadius()); values.values.put(PROP_COLOR, rv.getBackgroundColor()); } } @Override public void captureEndValues(TransitionValues values) { // 同样的读取逻辑，从目标属性取值 } @Override public Animator createAnimator(ViewGroup root, TransitionValues startValues, TransitionValues endValues) { if (startValues == null || endValues == null) return null; float startRadius = (float) startValues.values.get(PROP_RADIUS); float endRadius = (float) endValues.values.get(PROP_RADIUS); int startColor = (int) startValues.values.get(PROP_COLOR); int endColor = (int) endValues.values.get(PROP_COLOR); ValueAnimator animator = ValueAnimator.ofFloat(0f, 1f); // 新增监听，实时更新圆角和背景色 animator.addUpdateListener(valueAnimator -> { float fraction = valueAnimator.getAnimatedFraction(); RoundedView rv = (RoundedView) endValues.view; rv.setCornerRadius(startRadius + (endRadius - startRadius) * fraction); rv.setBackgroundColor(blendColor(startColor, endColor, fraction)); rv.invalidate(); }); animator.setDuration(400); return animator; } }

自定义Transition时，和框架的交互接口是固定的：start和end的匹配由框架根据View的transitionName或者位置来决定。这里要注意：如果你的自定义Transition对同一个View既捕获了旧值，也捕获了新值，但你没有实现对应属性的动画，那么框架在createAnimator返回null后，该View在动画期间就会处于“瞬间跳变”的状态，视觉上很突兀。所以写自定义Transition时，一定要把每个捕获属性都对应到动画上，或者明确让某个属性不参与动画。

另外，如果把captureStartValues和captureEndValues写成完全一样，createAnimator也不会被调用，这是一种自然的“动画跳过”机制。你可以在不需要动画时故意把值设置成一致，实现“某些View不动”的效果，这就相当于Target的一种轻量级替代。

3.4 实操中的参数选择过程——duration、插值器与延迟

在实践里，过渡动画的调参是门学问，直接影响最终体验是否高级。我项目的标准做法是先把核心Transition的duration设成300，然后根据场景“重量”调整。

页面级切场我一般给350～500毫秒，配合DecelerateInterpolator（先快后慢），模拟物理惯性。局部列表项展开收起给240～280毫秒，用FastOutSlowInInterpolator（Android插值器里最舒服的一个）。如果有多层动画，比如TransitionSet里同时有淡入和移动，我会给Fade设置一个短一点的duration，给ChangeBounds设置长一点的，这样视觉上有层次，不会所有东西同时戛然而止。

延迟（startDelay）我基本只在需要“等上一个动画结束后再动”时用，比如先让背景展开，再让子内容淡入，这比用orderingSequential更精细。但startDelay不宜超过150毫秒，否则用户会感受到明显的停顿。

有一些项目里，我还会用PathMotion自定义运动路径。内置的ChangeBounds默认走直线，而PathMotion允许你指定曲线路径，让View沿着贝塞尔曲线运动。这个一般在卡片飞入飞出时用，会让动效更柔和。自定义方法：

ChangeBounds changeBounds = new ChangeBounds(); changeBounds.setPathMotion(new PathMotion() { @Override public Path getPath(float startX, float startY, float endX, float endY) { Path path = new Path(); path.moveTo(startX, startY); path.quadTo((startX + endX) / 2, startY - 100, endX, endY); return path; } });

注意，PathMotion对所有使用ChangeBounds位移的View都会生效，如果页面上有多个移动的View，可能所有View都会走弧形路线，这时要考虑Target限制。

4. 常见问题与排查技巧实录

4.1 状态捕获失败：动画从0坐标跳动

症状：执行过渡时，目标View突然闪到屏幕左上角，然后再飞回目标位置。

原因：captureEndValues时布局尚未完成，或者被过渡的View还没挂载到容器上。常见触发时机是在onCreate中直接调用beginDelayedTransition，然后再改布局参数。此时当前View可能还是初始状态，布局数据不完整。

排查方法：在beginDelayedTransition前打印容器的getWidth()和getHeight()，看看是不是0。如果是，就需要把过渡推到layout完成之后，最简单的处理是：

container.post(() -> { TransitionManager.beginDelayedTransition(container, transition); // 修改属性 });

另一个相似问题是在RecyclerView滚动过程中触发过渡，某些Item处于复用状态，捕获到的left/top是缓存的旧值。这种情况我建议给过渡限定Target，只滚动当前可见区域，避免在滚动中的Item上做捕获。

4.2 RecyclerView复用环境下的动画混乱

症状：列表Item展开收起时，其他Item也跟着怪异地晃动，或者复用的Item在划出屏幕后再次滑入时，还保留上次动画的中间态。

原因：RecyclerView的View复用机制和Transition的状态捕获机制冲突。Transition捕获的对象是基于某个View实例的，而复用会导致同一个实例被用到不同位置。当你在复用时机加入过渡时，框架把旧位置的View和当前位置的View当成同一个View来处理，于是动画就被错误地迁移了。

解决办法有几条路。第一，不要在Adapter的onBindViewHolder里做beginDelayedTransition，要绑定到明确的事件里。第二，在动画执行期间，给ViewHolder的itemView设置一个tag或者禁止复用标志，动画结束时清掉。第三，如果必须在刷新Item内容时做动画，建议改用ItemAnimator，那是RecyclerView本身提供的动画扩展点，对复用机制的兼容性要好很多。

我记得有个同事遇到过一个诡异问题：滑动列表后再回来，其中一个Item的透明度永远是0.5。最后定位发现，就是过渡动画结束时，某个属性动画没有正确reset到最终值，被复用后又保留了这个中间态。修复方式是在TransitonListener的onTransitionEnd里强制把View属性reset到终值，并且确保重用了的View不会进入动画列表。代码判断可以这样：

transition.addListener(new TransitionListenerAdapter() { @Override public void onTransitionEnd(Transition transition) { view.setAlpha(1f); view.setTranslationY(0f); } });

4.3 Reparent问题：跨容器移动无法执行

症状：一个View从容器A移动到容器B，过渡动画不存在，或者它先从A里消失，然后再从B里冒出来。

原因：ChangeBounds对跨父容器的移动支持不佳。框架默认只匹配父子结构不变的情况，跨容器时起始容器里的View和结束容器里的View是两个不同对象，它不会自动建立关联。

解决方案之一是“手动记录位置”：

// 在移动视图之前记录相对屏幕位置 Rect startRect = new Rect(); targetView.getGlobalVisibleRect(startRect); // 执行真正的移动操作后，手动把View放到起始位置，再让它动画移动到实际位置 targetView.setX(startRect.left); targetView.setY(startRect.top); targetView.post(() -> { targetView.animate() .x(endRect.left) .y(endRect.top) .withLayer() .setDuration(300) .start(); });

这种“用获取全局坐标+手动Animator”的套路，是绕过跨容器限制最灵活的方式。另外一个思路是给目标View添加TransitionName，并在Scenario中保持同一个View对象引用，让它从旧容器移动到新容器，然后自己处理ViewGroup的add/remove。框架对Reparent的官方支持是从某个版本开始引入的，但我在实际项目中仍然更喜欢手动处理，因为它最可控。

4.4 setTransitionGroup的作用——避免每个子View都被捕获

在做复杂视图的过渡时，有时候你会看到整个组件像“爆炸”一样散开，似乎每个TextView、ImageView都被单独拉去做了动画。这个现象其实是框架把“一个容器”里的所有子View都当成了动画对象。虽然有时这是你想要的，但更多情况下，我们希望只把整个组件作为一个整体来移动。

解决方法是在那个容器上设置：

container.setTransitionGroup(true);

这个属性的含义是：告诉框架，在捕获时，这个容器本身就是一个过渡对象，不用递归去捕获它的子View。这样整个组件就可以作为一个单元参与过渡动画，内部逻辑保持不变。

这个属性我强烈建议在自定义复杂的控制项（比如带Label和Icon的组合按钮）后，手动设一下。否则默认情况下，框架会递归捕获所有子View的状态，导致动画数剧增、性能下降。

4.5 动画闪烁或者闪白

症状：过渡动画执行过程中，目标区域出现白块或黑块闪动。

原因：常见于View层级多变或者背景色不同的场景。当View在动画过程中发生尺寸变化时，系统在重绘过程中可能出现空白区域；另外，如果View在动画前后有硬件层切换，也可能出现闪烁。

解决办法首先考虑给动画中的View开启硬件层加速：

changeBounds.addListener(new TransitionListenerAdapter() { @Override public void onTransitionStart(Transition transition) { view.setLayerType(View.LAYER_TYPE_HARDWARE, null); } @Override public void onTransitionEnd(Transition transition) { view.setLayerType(View.LAYER_TYPE_NONE, null); } });

但要注意，硬件层在低端机上反而可能减慢速度，因为创建额外的缓冲纹理需要时间。这个优化只适合动画时间短、View数量少的场景，如果页面复杂，建议不要开太多硬件层。

另一个技巧是用android:animateLayoutChanges="true"，这是Activity/Fragment布局上非常简单的一个属性，本质就是调用了LayoutTransition。但它只覆盖简单的add/remove/显示隐藏场景，效果远不如Transition Framework精细。如果你只是想粗粒度的布局动画，可以用它，但追求细腻动效时还是回到Transition框架。

4.6 多动画并发时的卡顿

症状：执行页面级合体动画时，帧率明显下降，动画丢帧严重。

原因：TransitionSet里同时放了多个ChangeBounds，每个ChangeBounds内部又会对多个View的属性动画做处理，这些动画同时跑，加上主线程的布局计算，导致性能吃紧。

优化方向分为两个层面。第一个层面是通过addTarget精确控制动画对象，避免动画作用在大量不可见或无关的View上。第二个层面是把复杂的组合动画拆分成子步骤，利用orderingSequential让不同批次的动画错开执行，降低同一时刻的负载。

如果动画还是卡，再考虑把动画对象的绘制工作放到硬件层，或者使用RecyclerView的setItemAnimator去替代自定义Transition。实测下来，同时动画的View数量尽量控制在10个以内，超过这个数目时，框架自身的捕获和匹配开销会明显上升。

4.7 常见问题速查表

5. 一个进阶思路：把过渡抽象成页面交互协议

到这儿我多说一点实际体会。Transition Framework表面上看是动画方案，实际上它的“场景状态Diff”思想可以帮助你重新设计组件交互。我这边后来把常用过渡声明成一套枚举和配置，每一种页面状态切换对应一组Transition规则，UI层不关心具体动画细节，只负责描述“状态改成了什么”，由框架按规则播放。

这样一来，产品想调整动画风格时，我只需要改动配置中心，不用翻遍业务代码。后来我甚至把过渡规则按场景维度拆分，列表页的卡片展开用一种风格，设置页的面板滑入用另一种风格，两个风格之间互不干扰。这是动画工程化的方向，也是我在重构这个模块时觉得最有价值的事情。

最后分享一个小技巧：调试过渡动画时，把Animation Duration调整到原来的两到三倍。我用开发者选项里的动画缩放配合这个策略，每次都能快速定位出到底是捕获阶段的问题还是Animator阶段的问题。遇到动画不按预期走，先别急着看代码逻辑，打开开发者选项把动画速度调慢，观察View的起始状态和结束状态在屏幕上的位置，再反推是哪个时间点出了问题。这个方法在我排查自定义Transition的时候帮助很大，比打日志直观得多。