简介面向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、它们初始层级顺序是什么、动画结束或取消时分别要恢复成什么样再开始写任何动画代码。希望你在这套推演给你带来同样的确定性。本文还有配套的精品资源点击获取