纯代码实现UIViewController push跳转时动画卡顿掉帧问题

纯代码实现UIViewController出现默认push动画卡顿，本质都是push动画执行的300-500ms时间窗口内，主线程被阻塞、或者GPU渲染压力过载掉帧，和是否使用Storyboard没有直接关系，常见诱因分几类：

• 目标控制器生命周期方法阻塞主线程：在viewDidLoad、viewWillAppear甚至push前的代码里，执行了同步耗时操作，比如同步查询本地大量数据库数据、同步加载/解码大尺寸图片、同步做复杂JSON/文件解析、同步执行大量计算逻辑，直接占满主线程时间片，动画没有足够资源执行就会卡顿。
• 首屏UI渲染压力过载：一次性创建过多视图、视图层级嵌套过深、大量透明层触发图层混合、大量视图触发离屏渲染（比如同时设置圆角+裁剪、阴影、毛玻璃效果）、列表未复用、直接加载未压缩的高清原图、Auto Layout约束过于复杂嵌套过多导致布局计算量爆炸，都会让GPU在动画期间渲染压力过载，出现掉帧。
• 非业务逻辑抢占主线程：push触发的时间点刚好撞上全局定时器触发、通知回调执行、其他后台任务完成后批量切主线程更新UI、或者之前Hook了UINavigationController的push方法、实现了导航控制器代理，在跳转流程里插入了同步埋点、日志、自定义逻辑，都会抢占动画所需的主线程资源。
• 内存压力过大：当前页面之前已经存在内存泄漏、加载了过多未释放的资源，触发系统内存警告甚至开始回收资源，也会导致跳转瞬间卡顿。

• 真机环境用Time Profiler抓栈：别用模拟器测试，模拟器硬件性能和真机差异极大，结果没有参考价值。在真机上触发push的同时用Time Profiler录制主线程调用栈，筛选动画执行时间段内耗时占比最高的函数，直接定位阻塞点，不要靠猜。
• 开启渲染调试选项定位渲染瓶颈：打开Xcode的视图调试渲染选项，勾选Color Blended Layers（红色区域代表存在图层混合，开销高）、Color Offscreen-Rendered Yellow（黄色区域代表触发离屏渲染，开销高），跳转后看页面红黄区域占比，占比越高渲染压力越大。
• 最小场景隔离验证：把目标控制器viewDidLoad、viewWillAppear里的所有自定义逻辑、自定义视图全部注释，只留一个设置了纯色背景的根视图，再次触发push。如果此时动画流畅，就说明卡顿来自自定义实现的业务/UI逻辑，逐段恢复代码，恢复到哪段出现卡顿，问题点就在哪段。
• 生命周期耗时打点：在viewDidLoad、viewWillAppear、viewDidAppear的入口和出口分别打时间戳，统计每个方法的执行耗时，单段逻辑执行如果超过16ms（对应60fps刷新率的单帧时间），必然会造成动画掉帧。

• 主线程只做UI相关的轻量操作：所有IO操作、数据解析、图片解码、复杂计算全部放到后台队列执行，处理完成后再切回主线程更新UI，绝对不要在首屏生命周期方法里执行同步耗时任务。
• 首屏UI轻量化：首屏只加载用户可见区域的视图，非首屏视图放到viewDidAppear（也就是push动画完全结束）之后再懒加载；视图尽量设置opaque = true，减少透明图层避免不必要的图层混合；尽量减少动画期间的离屏渲染，圆角、阴影等效果可以提前异步绘制生成图片，不要在动画期间实时触发离屏计算；图片加载使用和展示尺寸匹配的缩略图，不要直接加载全尺寸原图。
• 降低布局计算开销：复杂页面尽量减少Auto Layout的嵌套层级，避免冗余约束；列表页提前计算好Cell高度，不要在动画期间动态重复计算布局；性能敏感场景可以直接用Frame布局，减少布局计算开销。
• 错峰执行非紧急逻辑：埋点上报、非首屏资源预加载、次要视图初始化这类不影响首屏展示的逻辑，全部延后到viewDidAppear之后再执行，不要和push动画抢主线程和GPU资源。
• 清理跳转链路冗余逻辑：检查是否有Swizzle UINavigationController跳转方法、导航代理中插入的同步耗时逻辑，能异步执行的全部异步化，不必要的逻辑直接移除。

核心跳转参考代码：

baseNavigationController.pushViewController(vc, animated: true)

内容的提问来源于stack exchange，提问作者Mehmet Baykar