简介：面向iOS开发者的自定义转场动画示例工程，内容围绕UIViewController转场时如何实现个性动画展开，适合中高级iOS开发者学习或直接复用。资源涵盖CAAnimation与UIView Animation两种动画基础，并给出UIViewControllerAnimatedTransitioning、UIViewControllerTransitioningDelegate等核心协议的实际用法，还涉及Storyboard中UIStoryboardSegue的改写、UIPercentDrivenInteractiveTransition交互式转场以及transitionCoordinator协调器，知识面较完整。压缩包共24个文件，以Objective-C源码为主，含8个.m、5个.h，另有工程配置plist、pbxproj、xcworkspacedata等，并附带storyboard、测试用例与json文件，整体仅51KB，结构紧凑，便于在Xcode中直接打开查看关键代码。目前已有493人学习下载，适合想通过实例快速理解自定义转场原理的开发者。示例中包含转场动画器、导航控制器与目标控制器的完整实现，可对照学习非交互与交互式转场的实现细节，为实际项目添加过渡动画提供可直接参考的模板，其中还梳理了动画时长、方向与控制方式等可配置参数，便于按需调整。
1. 转场动画：为什么它比你在 view 上随便加动画难那么多
绝大多数人第一次接触 iOS 转场动画时，直觉反应是：把 fromVC 的 view 和 toVC 的 view 放进一个容器里，然后做位移、缩放、透明度变化，最后把旧的移除——听上去跟普通 UIView 动画没什么两样。可一旦你真去写，立刻会发现一堆问题：目标控制器的 view 明明已经 appear 了却一闪就消失，转场结束后返回按钮失灵，横竖屏切换时层级乱掉，手势拖动时动画进度完全对不上手指。这些不是你代码写错了，而是因为你还在用「动画 UIView」的心智模型去理解一个「编排 UIViewController 生命周期」的系统。转场动画本质上是系统在管理完整生命周期，它复杂程度远超给一个 view 做动画。
要真正搞懂 iOS 转场动画，必须理解这套设计的三个支柱：转场上下文（UIViewControllerContextTransitioning）、动画器（UIViewControllerAnimatedTransitioning），以及协调器（UIViewControllerTransitionCoordinator）。三者谁负责什么、在什么时候被调用、回调里能拿到什么，决定了你写的动画是稳稳跑完——还是纯粹靠「试到不崩为止」这种玄学在维持。这篇就从现象切入，一步步拆到实现层。
2. 转场的结构：动画的不是 view，而是整个生命周期
2.1 转场上下文：为什么 target 控制器的 view 会出现在一个“神秘容器”里
任何转场发生的最底层事实是：iOS 并不会真的把 fromVC 和 toVC 的 view 在屏幕上做一次“交接”，而是在两者之间插入一个全屏的临时容器视图（containerView），让两个控制器的 view 都成为这个容器的子视图，然后在容器里完成整个动画过程。动画结束后，系统再决定哪个 view 应该留在视图层级里。听起来简单，但这个容器从哪来、谁创建、动画过程中两个控制器的状态如何，全部由转场上下文协议 UIViewControllerContextTransitioning 来决定。
常见的实现思路是：App 的窗口或导航控制器内部准备好一个容器视图，把即将参与转场的两个控制器的 view 放进去。同时，上下文对象会把这一整套转场的“临时状态”存起来，包括：转场发生的容器视图、参与转场的两个控制器、动画是否被取消、以及 fromView / toView 这两个关键时刻的视图引用。你写的动画器代码里所有操作都发生在这个容器之中，动画结束后由容器配合上下文完成最终的清理。
需要特别注意的是 fromView 和 toView 的获取方式。在大多数转场场景里，它们分别等于 fromViewController.view 和 toViewController.view，但在某些容器控制器（比如 UITabBarController 的 tab 切换转场）里，系统会返回快照视图而不是原视图。在很多实际项目中，开发者会因为拿不到“真正的 view”而感到困惑，其实系统是为了避免在转场动画期间破坏正常的视图层级。你不需要过分纠结返回的是不是原始视图，你只需要知道：fromView 和 toView 是系统在动画期间给你准备的“演员”，它们在动画结束后可能会被移除、替换或恢复原状。
2.2 动画器的两个核心方法：duration 只是开门，animateTransition 才是主场
动画器协议 UIViewControllerAnimatedTransitioning 里，有四个关键方法，其中两个是必须实现的。第一个是 transitionDuration(using:)，返回转场动画的时长，系统会在需要知道动画时间的地方调用它，比如驱动交互式转场的进度计算。要注意这个返回值必须是固定的、在转场开始前就能确定的数值，你不能在里面做耗时计算或依赖某个 view 的尺寸来推断时长，因为交互式转场需要用它来构建底层的时间线。
第二个是 animateTransition(using:)，这是动画真正执行的地方，整个动画期间发生的一切都应该在这个方法同步完成，包括添加视图、添加动画、设置完成状态。关键点在于：必须调用transitionContext.completeTransition(!transitionContext.transitionWasCancelled)来通知系统动画已经结束。这个调用不是可有可无的礼仪，它触发了整套生命周期回调：协调器开始清理；系统会将 fromVC / toVC 的视图层级做最终整理；如果转场被取消，还涉及视图的恢复问题。
第三个可选方法是 animationEnded(_:)，无论动画成功还是取消都会调用。第四个是 interruptibleAnimator(using:)，它在 iOS 10 后引入，用于返回一个可中断的 animator（通常是 UIViewPropertyAnimator），让交互式转场的进度控制从原来的“百分比驱动的 CA 动画”升级为“真正可逆向的动画对象”。后面讲手势驱动时会展开。
2.3 生命周期回调：转场协调器把 appear/disappear 交给了谁
转场协调器（UIViewControllerTransitionCoordinator）是一套配合使用的协议，它在转场动画进行的同时，允许你挂载额外的动画或完成回调。它本身并不是动画的执行者，而是一个调度枢纽：当一次转场开始时，它会把动画器、容器视图、上下文都协调起来，并在这个枢纽上播报整个转场的生命周期事件。
协调器和动画器最本质的区别是：动画器负责“执行动画”，协调器负责“广播生命周期”。你可以在协调器的 animate(alongsideTransition:completion:) 方法里挂载与主转场动画并行的附加动画，比如目标控制器里的一个元素跟随整体转场而移动；也可以用 notifyWhenInteractionChanges 监听交互式转场的进度变化。这套设计让转场动画不再是动画器一家的独角戏，而是整个控制器树上的所有对象都能参与进来的协作机制。
转场协调器并非所有转场都有。present / dismiss 转场和导航控制器的 push / pop 转场会提供协调器，而某些自定义容器转场或部分系统转场可能不提供。所以严谨的代码写法是先问一句transitionCoordinator是否为 nil，如果为 nil 就退化为普通动画。很多人在自定义容器里写转场时发现附加动画不执行，就是因为容器没有对外提供协调器。
3. 一次转场的完整生命周期：从 delegate 被询问到 completeTransition 触发清理
3.1 起点：Transitioning Delegate 是怎么被追问的
整个转场链条的开端不在动画器里，而在 UIViewControllerTransitioningDelegate 的方法被系统调用之时。present 一个转场目标控制器时，系统会先拿着目标控制器去询问它的 transitioningDelegate 是否存在；nil 则走系统的默认转场，非 nil 则走自定义转场链路。这条链路上的问答是有顺序的：
- 先问
animationController(forPresented:presenting:source:)：要不要给一次出现动画，返回 nil 就使用默认样式； - 再问
interactionControllerFor(using:)：这次转场是否由手势驱动，返回 nil 表示非交互式； - 最后是 presentationController 相关的询问，用于自定义目标控制器的展示样式和容器层级。
这个问答顺序决定了你可以在不同阶段介入。之前不少开发者为了做手势和动画的统一入口，把两个方法混在一起写，结果出现手势可拖但动画永远只跑一半的情况。正确理解是：动画器负责“动起来”，交互控制器负责“跟踪手势并驱动进度”，两者是独立的组件，只在转场上下文里通过同一个协调器发生关系。
3.2 fromView 和 toView 的入席顺序：toView 为什么在容器的最下面
当 animateTransition 被调用时，系统的容器视图里其实已经有两个视图了。但这两个视图的层级顺序可能有反直觉之处：toView 往往被放在 fromView 的下面。也就是说，动画开始前，目标控制器的 view 已经存在于容器中，但被旧视图压住，所以你无法直接看到它。转场动画的“进入”效果，本质上是把 toView 从 fromView 底下移动或变换到覆盖住 fromView 的过程。
层级顺序的具体安排由系统在转场上下文内部决定：present 转场默认把 toView 插到 fromView 下面；而一般情况下，如果你自己不调整层级，动画开始时 toView 是看不见的。很多转场动画看起来由白屏到亮起，其实是在 toView 添加到层级之前做了一次透明度从 0 到 1 的动画。弄清楚这点，你才好解释“为什么我用 addSubview 把 toView 放在最上面以后，撕扯和遮挡效果反而乱了”。
3.3 completeTransition 是扳机：转场结束后的清理机制
animateTransition 里所有动画代码执行完后，必须调用completeTransition(_:)。这行代码是整个转场机制的扳机：它触发系统清理转场相关的临时状态，执行协调器上挂载的 completion 回调，让 fromVC 和 toVC 走完正常的生命周期（viewWillAppear、viewDidAppear 或反过来的消失流程），并决定容器视图里哪个 view 可以保留，哪个要移除。
如果没有调用 completeTransition，转场不会崩，也不会报错——你看到的现象是：目标控制器的 view 永久卡在屏幕上，状态栏无法响应，返回按钮事件失效，仿佛整个页面被冻结了。造成这种情况的一个常见原因是动画代码里某个 return 语句提前退出，或者因为某个条件判断把 completeTransition 放进了永远不会执行的分支里。调试转场问题的时候，第一步永远是确认这行代码是否在每一种路径上都会执行。
3.4 动画结束不等于转场结束：animationEnded 与错误的补救
动画执行完毕只代表“视觉过程”结束了，而转场机制本身（生命周期、视图层级整理）还需要系统完成。动画器的 animationEnded 方法在所有动画和生命周期的最后被调用，但它不携带任何参数表示“成功或失败”，只通知你“动画流程走完了”。如果需要知道结果，你在 animateTransition 的 completion block 里拿到的transitionContext.transitionWasCancelled才是可靠判断。
这里容易翻车的地方在于：在 animationEnded 里做视图清理或控制器移除。因为系统自己都会做一遍，你的清理可能让视图层级出现双重释放或提前消失。实操里的做法是：把需要最终处理的逻辑写在 animateTransition 的闭包里，把只需要观测的逻辑写在 animationEnded 里。
4. 手势与交互式转场：进度条与动画时间线的对齐艺术
4.1 百分比驱动控制器怎么把手指位移换算成动画进度
UIPercentDrivenInteractiveTransition 是一个预先帮我们做好所有协调的类，专门用于让转场跟随手势进度。它提供的 update / finish / cancel 三个方法，把所有与动画进程相关的复杂细节向下做了封装。你在手势回调里把 translation 换算成百分比，然后调用update(with:)传入，系统会调整正在进行的动画到相应的进度位置。
听起来不复杂，但它的实现机制里有相当关键的内部细节：传入的百分比被映射到一个 CA 动画的时间线上，这个时间线原本由动画器返回的 duration 决定，百分比本质上就是“时间线被拨到百分之几”。所以动画时长的返回值对交互式转场很重要——如果这个值返回了 0，那么系统的百分比更新就会完全失效，这可能导致手势拖动时目标控制器完全不动。这类问题排查时先看 duration 返回值。
4.2 手势取消和完成的分岔路：为什么取消也要走完整个生命周期
手势从半途松开时，需要判定是继续完成转场还是回滚到原始状态。系统的判定规则很简单：进度超过某个阈值（默认是 50%）且没有反向手势，则调用 finish，转场完成；否则调用 cancel，转场回滚。
回滚并非把视图瞬间变回去，系统会自动做一次反向动画，让视图从当前位置回到起始状态。这也意味着原本的 fromView 和 toView 的关系会反转过来，生命周期也会被完整地反向执行。这个反向过程同样需要 completeTransition 被触发，由系统把状态恢复到转场发生前的样子。从用户视角看，“取消”是一个动画过程；从机制视角看，取消就是一次反向转场。
代码实现上通常会在手势结束的 isCancelled 判断后调用 finish 或 cancel，并把结果传给 completeTransition。一个常见的坑是：在手势 cancel 之后仍然更新进度或重新添加视图，导致动画系统二次驱动，画面出现跳动或闪烁。
4.3 可中断动画器：UIViewPropertyAnimator 为什么更适合交互式转场
针对交互式转场，iOS 10 之后推荐返回 interruptibleAnimator 的结果，通常是 UIViewPropertyAnimator 实例。它是可暂停和可反向的，所以交互式转场时，系统不仅可以通过进度更新来“拨动画时间线”，还可以直接翻转动画方向，使取消的回滚更平滑。相比传统基于 CA 的时间线映射，UIViewPropertyAnimator 的优势是动效可直接控制、可逆、可暂定，适合做更细腻的手指跟随效果。
使用 propertyAnimator 作为动画器时，注意不要手动启动它，因为系统会在转场流程中自动处理它的开始状态；而你在动画结束后的 completion 处理中，需要小心处理 state 为 .active 或 .stopped 分支，避免重复触发 completeTransition。值得提醒的是：一旦自定义动画器返回了 interruptibleAnimator，后续的 animateTransition 将不再被调用，转场完全由这个 animator 驱动。从这种机制来理解，它是一次行为主体的替换——旧实现里“计算式”的时间线控制让位给“对象式”的动画控制。
4.4 延迟与削波：手势驱动时 why 帧率骤降
手势驱动的转场会逐帧更新进度，而整条链路里既有视图层级操作、又有动画对象状态变更，还有生命周期回调，每帧都在做大量的状态同步工作。一旦把过多视图加载进容器或者动画器实现里多次创建快照，帧率会明显下降。快照是其中一个高频瓶颈：每次snapshotView(afterScreenUpdates:)都会触发一次离屏渲染，如果每个 frame 都创建新快照，直接后果就是主线程拥堵。
常见的实现思路是动画过程里只使用最初的快照，避免反复创建；转场结束后再丢弃快照引用。如果一定要实时反映控制器内容变化，宁可先给 toVC 的 view 做一次 pre-render，再开始动画，也比每帧做快照表现好。
5. 转场避坑：快照、白屏、层级错乱与返回失灵的排查记录
5.1 现象：转场结束后目标控制器白屏
转场动画执行完的瞬间，目标控制器的 view 白屏并持续存在。原因是 toView 没有被正确加入到容器视图层级中，或者 toView 虽然被添加了，但动画结束时进度被标记为 cancelled，而你的代码又没有把视图恢复到 raw 状态。另一种常见的路径是：开发者为了防止动画开始时目标页面闪烁，提前把 toView 的 alpha 设为了 0，但动画结束时没有恢复成 1，于是它一直“透明地”存在于层级里。
解决的方法是严格遵循上下文给的宿主关系：动画开始后，把 toView 插入容器视图层级，并确保动画完成或取消的回调里，把所有临时改过的视图属性（alpha、frame、transform）恢复到最终状态。如果采用快照方式，记得移除临时快照恢复原视图。更稳妥的说法：把状态恢复逻辑统一放进 completeTransition 之后的 finishing 闭包里，让系统通知你去恢复，而不是靠巧合。
5.2 现象：present 的转场完成后，目标页面无法点击
交互式转场执行完成后，目标控制器页面虽然显示正常，但按钮或 table view 无响应。原因是视图层级里有残留层，一个不可交互的透明 view 覆盖在内容之上，事件分发完全被它拦截。这种情况经常会在自定义容器转场里发生，某个控制器在转场过程中被添加的临时 view（比如用于制造阴影或模糊效果的 overlay）没有被从层级中移除。
解决的方法是确认所有临时 view 在动画结束后立即移除。比较可靠的套路是：把临时 view 的移除动作放在转场上下文 context 的 completion 处理里，或者放在协调器的 animate(alongsideTransition:) 的 completion 闭包中。调试时可以使用视图层级调试器查一下最上层遮挡物是谁，再根据这条链去清理。
5.3 现象：手势取消后，页面重叠或闪烁
手势拖到一半，松开并取消，结果源页面和目标页面同时在屏幕上，视觉上出现闪烁。原因通常是没有正确处理转场取消后的视图归位，系统为你执行了反向动画，但反向动画完成后视图所处的初始位置与你预期不一致。触发这种情况的常见场景是两个：一是动画里修改了 toView 的 frame，二是取消路径下视图状态没有恢复。
解决方式是彻底理解「取消不等于消失」：取消后 fromView 应该回到原始层级位置，toView 应该被移除。如果你在动画里对 fromView 做了缩放或平移，需要在取消分支里把它恢复；如果使用了快照，直接丢弃快照即可，但不要再次插入快照。在这类问题上，宁可把动画写简单一点，也不能让状态恢复链路含糊。
5.4 现象：push 转场里使用自定义动画导致侧滑返回手势失效
实际开发中，设置导航控制器的 delegate 并自定义 pop 动画之后，自带的侧滑返回手势会突然失灵。原因是导航控制器的交互式转场与自定义 pop 动画发生冲突，或者返回手势的回调不再触发。基于常见的实现思路，保留侧滑返回的同时要做的是：让系统的 interactivePopGestureRecognizer 继续工作，同时你的 delegate 只在非交互式场景返回自定义动画器，而交互式场景返回 nil 或交给系统的交互控制器。
这里的取舍比较微妙：全自定义则手势失效，全系统则无法深度控制动画。多数高质量项目的策略是「动画自定义 + 手势放行」，也就是在animationControllerFor:保持返回自定义，但把interactionControllerFor:在交互式触发时返回 nil，让系统继续接管手势。这种做法能让动画保持你的风格，同时不破坏系统提供的手势交互。
5.5 现象：横竖屏切换时转场动画错位
转场动画正在运行时用户旋转了屏幕，结果动画中的视图坐标全部错乱。根源在于：动画进行中视图布局被打断，但你的动画代码使用的是旧的方向尺寸。解决这类问题，常见的做法是：在动画开始前用transitionContext.finalFrame(for:)明确计算最终 frame，不要依赖 view 的当前 bounds；转场动画中尽量让视图使用 Auto Layout 并让布局主动适应尺寸变化，避免硬编码 frame。如果你的动画是在自定义容器里做，还要保证容器视图的 autoresizing 行为正确。
这类问题的本质是“转场的动画坐标必须以 final frame 为基准，而不是以当前 frame 为基准”。原则很简单：所有动画路径上涉及的位置计算都从上下文提供的最终 frame 拿到，没有例外。
6. 设计取舍的思考：为什么 iOS 把“转场”抽象成了一套生命周期机制
回顾整套转场 API 设计：动画器、转场上下文、协调器、百分比驱动、可中断动画器——这种抽象一度被认为过分复杂，但其实它是被问题本身推着走的。核心的设计动机在于：iOS 的转场不只是让一个 view 移动到另一个 view，而是要承担两个控制器的全部生命周期切换、系统级手势的接入、以及系统返回手势与自定义动画的并存问题。如果做得过于通用，比如只提供一个“在容器里换 view”的简单 API，那么所有复杂业务里的边缘情况（取消、打断、旋转、嵌套容器）会变成开发者各自补丁的混乱源头。
所以我一般会这么理解这套机制：转场 API 真正想给你的是“同一次事件流的多角色参与能力”。动画器只负责动画，协调器只负责广播状态，交互控制器只负责进度，三个角色各司其职。这个思路与 UIView 动画的最大的不同在于，它不是一步到位的动画工具，而是一个可编排的事件框架。想让开发者写出的动画不只是好看，而是能在系统机制里正确运行，就必须要求你理解这套抽象。放弃理解它，靠反复试错来写，就等于把这套精密的机制降级成了“在渐变上瞎猜”。
我自己第一次写自定义转场时，也曾在 present 完成前的 opacity 恢复上栽过跟头，当时无数次想直接把临时 view 塞回去。直到我完整理解协调器与动画器的责任边界后，才彻底摆脱盲区。从那以后，我每次写转场动画都会强制走一遍同样的推演：上下文里 now 谁是 from、谁是 to、它们初始层级顺序是什么、动画结束或取消时分别要恢复成什么样，再开始写任何动画代码。希望你在这套推演给你带来同样的确定性。
本文还有配套的精品资源，点击获取
