Android RenderThread空转：Frame skipped: NothingToDraw，脏区为空GPU放弃合成

摘要：Android渲染空转问题分析：当系统检测到界面无变化时会触发"Frameskipped:NothingToDraw"机制，此时GPU会放弃合成操作以节省资源。该问题通常表现为UI线程频繁执行doFrame但渲染线程发现脏区为空，导致CPU资源浪费。主要诱因包括：空跑动画、滚动视图惯性滑动、共享元素动画收尾以及无意义的帧回调。虽然不影响显示效果，但会占用CPU资源可能引发后续卡顿。通过性能分析工具可追踪具体原因，重点关注动画和滚动相关代码，及时取消不必要的动画和回调可解决此问题。

在 trace 中看到 Frame skipped: NothingToDraw ，原因：脏区为空 。为什么 UI 线程在 doFrame，为什么 RenderThread 走了 DrawFrames，但 GPU 却没有合成。

一、 `Frame skipped: NothingToDraw` 是什么意思？

这是 Android RenderThread（渲染线程）内部的一个极为重要的性能优化机制。

当 UI 主线程执行完 doFrame（完成了 Measure、Layout、Draw 记录）并把数据同步给 RenderThread 时，RenderThread 会做一次数学计算：

它会对比上一帧和这一帧的 RenderNode（渲染节点）树。
它会计算出**"脏区" (Damage Rect / Dirty Region)**，也就是屏幕上到底有哪几块区域的像素真正发生了改变。
如果计算结果发现脏区是 (0, 0, 0, 0)（没有任何像素需要改变），或者改变的区域完全在屏幕可见范围之外。

此时，RenderThread 就会打出 Frame skipped: NothingToDraw 的 trace，然后直接 return 。它故意不调用 OpenGL/Vulkan 的渲染指令，也不去 eglSwapBuffers。因为既然画面没变，提交给 GPU 纯粹是浪费电量和 GPU 算力。

二、为什么 UI 线程还在疯狂 `doFrame`？（核心矛盾点）

既然画面没变，为什么 UI 线程还要在 100ms 内连续跑 10 次 doFrame？这说明业务逻辑和渲染逻辑脱节了。UI 线程"以为"自己需要更新画面，不断向 Choreographer 申请下一帧，但 RenderThread 检查后发现都是"无效更新"。

在App滑动的场景中，通常是以下几种情况导致的"空转"：

动画在"空跑" (Invisible/No-op Animation)

代码中有 ValueAnimator、ObjectAnimator 或 ViewPropertyAnimator 正在运行（通常时长刚好是 100ms 左右的短动画）。

可能在改变一个不可见的 View ：比如某个控件的 alpha 正在从 0 变到 0，或者它已经被 View.GONE 了，但动画没 cancel()。
可能在改变一个不影响视觉的属性：动画在运行，但并没有触发任何可见元素的实际重绘。

ViewPager2 / RecyclerView 的滑动余震 (Settling/Fling)

当左右滑动松手后（ACTION_UP），列表会进入惯性滑动（Fling）或吸附（Settling）阶段。

底层的 Scroller 还在计算减速曲线，不断调用 postOnAnimation() 触发 doFrame。
但是，可能已经滑到了边界（Edge），或者计算出的位移（dx）不到 1 个像素（Sub-pixel），导致实际上 View 的位置并没有发生改变。
于是 UI 线程每帧都在算位置，RenderThread 却发现 View 根本没挪动，直接 NothingToDraw。

共享元素动画的收尾 (Shared Element Transition)

如果有共享元素动画。动画框架可能在最后 100ms 还在做状态同步，申请了帧，但实际的缩放和位移已经结束，或者被遮挡了。

业务层无意义的 postFrameCallback

代码里可能有人写了 Choreographer.getInstance().postFrameCallback(...) 来监听帧率或做某些延后操作，但回调里并没有真正去 invalidate 任何可见的 View，只是单纯地让主线程醒来。

三、这是一个 Bug 吗？需要修复吗？

从渲染结果来看： 这不是致命 Bug，屏幕没有花屏，GPU 也没有被过度消耗（RenderThread 成功拦截了它）。 从性能角度来看： 这是一个 CPU 资源的浪费。UI 主线程在这 100ms 内被唤醒了 10 次，执行了无意义的遍历，这可能会抢占其他重要任务（比如高清图解码、预加载）的 CPU 时间，进而导致后续的卡顿。

四、如何在 Trace 上揪出"真凶"？

既然已经锁定了是 NothingToDraw，下一步就是找出是谁在触发这 10 个无效的 doFrame。

回到 Perfetto/Systrace，放大这 10 个异常的 doFrame，重点查看 doFrame 内部的结构：

看 doCallbacks 的类型：
- 如果展开看到的是 doCallbacks: animation ：说明是动画在作祟。往下看通常能看到 ValueAnimator、ViewFlinger.run (RecyclerView 的滑动)、或 Choreographer.FrameCallback。
- 如果展开看到的是 doCallbacks: traversal ，但在 performTraversals 里没有看到 draw 被实际执行：说明有人调了 requestLayout()，但尺寸没变，没触发真实重绘。
顺藤摸瓜找代码：
- 如果是 ViewFlinger，说明是 ViewPager2 侧滑到边缘后的惯性计算没及时停下。
- 如果是 ValueAnimator，查一下页面有哪些动画是 100ms 左右的（比如淡入淡出、缩放回弹、或者滚动条隐藏），检查它们在不可见时是否忘记了 cancel()。

总结： Frame skipped: NothingToDraw 证明了 GPU 是清白的，系统也是正常的。问题出在App的 UI 线程上------有某段代码（很可能是动画或滑动 Scroller）在画面已经静止或不可见的情况下，依然孜孜不倦地运行了 100ms，申请了 10 个无效帧。

AI知识星球

Android RenderThread空转：Frame skipped: NothingToDraw，脏区为空GPU放弃合成