屏幕写着120Hz，动画为何仍会卡：刷新率、帧率与帧节奏分别决定什么

120Hz只提供更多更新机会

120Hz表示屏幕一秒有120次更新时机，单次周期约8.3毫秒。它没有承诺应用每个周期都能准备一幅新画面。

Android的显示文档说明，到更新时间仍没有新帧时，系统会再次显示上一帧。屏幕完成了刷新，用户看到的内容却没有前进。

因此，硬件标称值回答面板能多频繁更新。应用帧率回答一秒提交多少个新画面，帧节奏则回答这些画面是否按均匀间隔出现。

三项只看其一，都无法完整解释滚动或动画是否顺滑。

60fps在120Hz上可以很均匀

Android以60fps内容配合120Hz屏幕为例，每个新帧可对应两次屏幕更新。若应用每16.7毫秒稳定提交一次，画面仍可保持均匀。

这不是120个独立新帧，却也不必然卡顿。每幅画面停留相同时间，物体移动的步长便相对一致。

相反，平均60fps也可能由5毫秒、28毫秒、9毫秒和25毫秒等间隔组成。总帧数看似相同，画面却会先急促前进，再停住等待。

所以平均值适合概括产量，不适合单独描述节奏。诊断需要保留每帧间隔或至少查看分布与长尾。

节奏不匹配会重复旧帧

Android文档以30fps内容运行在60Hz显示上为例，指出不合适的同步可能形成49、16、33毫秒等间隔。数字不规律时，人眼更容易感到抖动。

短帧接长帧也会造成同样问题。一帧过早提交，下一帧又赶不上显示周期，某幅画面只出现一次，另一幅则被重复多次。

帧节奏控制会把应用逻辑、渲染循环与显示系统对齐。呈现时间戳帮助画面在合适时刻出现，同步机制则避免队列不断塞满。

只追求尽快提交并不总是更快。队列塞满会产生反压，应用等待显示系统腾出空间，输入到画面的路径还可能多出一帧。

主线程阻塞会拖过多个周期

网页滚动和动画不只依赖显示面板。输入事件、脚本回调、样式计算、布局与部分渲染工作会在浏览器的执行队列中等待。

W3C长动画帧草案说明，长任务占用UI线程时，点击、滚动和其他关键任务都可能被挡在后面。页面已经显示完整，也可能暂时无法响应输入。

草案把超过50毫秒的相关任务或渲染序列记为长动画帧。50毫秒在60Hz约跨过三次周期，在120Hz约跨过六次周期。

这个阈值用于报告明显阻塞，不是流畅度及格线。一个20毫秒任务不会被记为长动画帧，却已经错过120Hz的一次8.3毫秒窗口。

长帧要看发生在哪个阶段

W3C接口提供duration、renderStart和styleAndLayoutStart等字段。它们帮助判断时间主要消耗在脚本之前、渲染开始后，还是样式与布局附近。

若输入后出现长脚本，网络请求已经结束，滚动停顿更接近主线程工作。若每次都等待新内容下载，画面空缺则可能含有网络与服务器时间。

两类问题可以同时存在。请求完成后，大量数据解析和页面更新仍会占用处理时间。只看下载速度，会遗漏接收后的执行成本。

来源归因也有边界。W3C为降低跨来源泄露限制部分信息，未知脚本不一定能完整定位；而且这份接口仍是工作草案。

峰值帧率不是稳定性

Android关于FPS限制的文档指出，未做节奏控制的内容可能拥有更高峰值，却也有更大的帧时间方差。主观流畅度会因此下降。

稳定40fps的单帧约25毫秒。它在120Hz上可与三个刷新周期形成规则关系。若60fps不断在短帧与长帧之间跳动，平均值更高，移动节奏却可能更乱。

这不是说低帧率总比高帧率好。条件相同且节奏稳定时，更高帧率能提供更短更新间隔。关键是应用能否持续交付，而不是偶尔达到峰值。

功耗也是条件之一。更高刷新与更多渲染会增加工作量，系统可能因电量、温度或模式改变目标。关闭节能并不保证瓶颈消失。

网络等待和滚动卡顿要分开

首次载入图片或下一段内容前停住，可能涉及网络。内容已经全部在屏幕上，连续滚动仍周期性顿挫，则更接近本地执行、合成或显示节奏。

一个简单对照是使用已经完整载入的同一页面，重复相同滚动距离。网络请求面板若没有新传输，停顿便不能只归因于带宽。

再观察输入发生时刻与长帧记录。输入后立即出现长脚本或长布局，可把问题缩小到网页执行。没有长帧却出现周期性重复，则还要查看合成与显示帧间隔。

网络稳定不代表本地渲染稳定，反过来也一样。两条时间线需要分别保存，再看它们是否在同一停顿处重合。

用帧间隔完成受控比较

固定同一设备、同一刷新模式、同一页面和相同动画。记录帧间隔分布、超过目标周期的比例、最长帧和输入到下一次画面变化的时间。

在120Hz模式下，可同时标出8.3、16.7和50毫秒。前两项对应一次与两次刷新周期，50毫秒则对应W3C长动画帧的报告门槛。

稳定60fps在120Hz上可每个新帧显示两次，交替短帧与长帧的平均60fps却可能明显抖动。显示硬件没有新帧时会重复上一帧，所以120Hz不等于应用输出120个新画面。

W3C接口仍是工作草案，Android帧节奏资料主要面向游戏。它们能解释机制，却不能替每个浏览器和设备给出固定结论。

固定设备、刷新模式和同一动画，记录帧间隔分布、长动画帧、输入时刻与网络请求，再定位停顿阶段。这样才能判断缺的是新帧、稳定节奏，还是及时响应。

一秒平均值如何掩盖停顿

设想两段动画都在一秒内提交60帧。甲每16.7毫秒交一帧，乙先在半秒内快速提交45帧，后半秒只交15帧。两者平均值相同，乙的后半段却会出现更长停留。

把记录窗口缩短到每一帧，就能看到差异。甲的间隔聚集在16.7毫秒附近，乙会同时出现很短与很长的间隔。峰值帧率只描述最快片段，最长帧和高分位间隔更接近偶发停顿。

应用交帧间隔忽长忽短或主线程被长任务占用，会造成重复帧、输入排队和不均匀移动。W3C把超过50毫秒的相关任务或渲染序列记为长动画帧，但50毫秒仍远长于120Hz约8.3毫秒的单次周期。

因此，没有长动画帧记录不表示120Hz已经被充分利用。它只表示观察窗口内没有达到该接口报告门槛的长序列。

跨设备比较必须保留条件

两台设备即使都标称120Hz，也可能选择不同实际刷新模式。系统可随电量、温度、内容类型或应用请求调整更新节奏，显示管线也可能不同。

比较时要固定页面版本、动画进度、屏幕模式和输入动作。若一台设备处于自动刷新，另一台锁定60Hz，所得差异不能只归因于处理器或浏览器。

记录结果时，把“平均fps”“最长帧”“超过16.7毫秒的比例”和“输入后首帧时间”分栏。四项分别描述产量、极端停顿、节奏稳定性和响应速度。

网络请求仍应单列。资料尚未到达时，渲染等待网络是合理解释；资料早已载入，停顿却随相同动作重复，证据会更支持本地执行或显示节奏。

资料来源

• W3C Web Performance Working Group：《Long Animation Frames API》，发布或更新于 2026-04-28
• Android Developers：《Frame Pacing library》，发布或更新于 2026-02-26
• Android Developers：《FPS throttling》，发布或更新于 2026-02-26