最近在测联想 Y700 五代的实际游戏表现时我特意把系统里的“加速”相关功能全部关掉只保留最基础的调度与渲染链路目的是搞清楚一件事在不借助任何增强手段的前提下这台设备的真实帧率到底能稳住多少而帧率波动又会对触控延迟产生什么样的影响。这篇就把整个测试方法、数据记录方式、对比思路以及容易踩的坑完整拆出来方便后续复测时直接照做。无论你是刚入手 Y700 五代想验证手感的玩家还是要做设备性能评估、游戏适配测试的开发者这套流程都可以套用。本文不会停留在“帧率很高”这种模糊结论而是重点说明如何用可复现的方式采集帧率与触控延迟再把两组数据做横向和纵向对比。1. 帧率与触控延迟先搞懂两个概念1.1 帧率是什么帧间隔又是什么帧率FPSFrames Per Second指每秒钟画面刷新的次数。60FPS 表示一秒渲染 60 帧每帧平均耗时约 16.67ms120FPS 表示一秒渲染 120 帧每帧平均耗时约 8.33ms。这个“每帧耗时”就是帧间隔Frame Time / Frame Interval。只关注平均帧率容易掩盖问题。比如某款游戏 5 分钟平均帧率显示为 59FPS但实际过程中可能频繁掉到 45FPS然后又迅速回到 60FPS。平均值看起来不错玩家体感却很卡。所以更合理的做法是把帧间隔的波动也记录下来尤其是 1% Low、0.1% Low 这类统计值用来衡量画面流畅度的下限。1.2 触控延迟不只是一个点触控延迟简单理解就是手指触碰屏幕到屏幕画面做出相应反馈之间的时间差。但这个时间差并不是单一环节造成的它通常包含几个组成部分触摸屏采样和上报时间。系统输入分发与事件处理时间。应用逻辑和渲染管线处理时间。屏幕自身刷新和像素响应时间。也就是说用户感受到的“跟手程度”是硬件、系统、应用、屏幕共同作用的结果。只看 CPU 频率或者只看屏幕刷新率都无法完整反映触控延迟。1.3 帧率如何影响触控延迟帧率对触控延迟的影响主要体现在画面反馈环节。假设屏幕刷新率为 120Hz每帧间隔 8.33ms那么手指点击后即使 CPU、GPU 马上处理完事件画面也只能等到下一个刷新周期才能显示最坏情况下就要多等一个刷新周期。在这个基础上如果帧率从 120FPS 掉到 60FPS帧间隔从 8.33ms 扩大到 16.67ms那么输入事件到达画面显示之间的等待窗口就会变长。这也是为什么高帧率模式下玩家普遍会觉得操作更跟手。但要注意帧率只是影响触控延迟的其中一个环节。如果系统输入分发或应用渲染管线本身延迟较高即使帧率很高触控延迟也不一定低。1.4 为什么“无加速”测试更值得做现在不少设备或游戏助手都提供了“性能模式”“插帧”“超分辨率”等增强功能。插帧技术可以在原始帧率较低时通过算法生成中间帧让画面看起来更流畅超分辨率则通过重建画面细节来提升清晰度。这些功能对体验有明显帮助但也可能引入额外延迟或画质副作用。“无加速”测试指的是关闭这些增强功能使用系统默认或标准调度。这样得到的数据更接近设备的原生渲染能力和原生输入延迟能帮助你判断设备的硬件底子到底如何。先测“无加速”基线再开启加速模式对比才能评估加速功能到底带来多少提升又付出了多少代价。2. 测试环境与设备准备2.1 设备与环境要求本文以联想 Y700 五代为测试设备系统版本、驱动版本以实际设备为准。测试前请把平板系统升级到稳定版并重启一次避免旧系统残留的异常状态影响数据。环境方面要尽量固定室内温度建议控制在 20℃ 到 28℃ 之间避免设备过热触发降频。充电状态要明确测试过程中保持充电或不充电不要中途切换。关闭后台不必要的应用尤其是消息推送、自动更新、云备份等。屏幕亮度固定为 50% 或固定某个档位避免亮度自动调节干扰。Wi-Fi 连接保持稳定如果游戏有联网对抗网络波动会直接影响帧率。建议把上述条件记录在测试表里方便复测时保持一致。2.2 测试工具选择帧率测试工具常用的是 PerfDog、FrameView、GameBench 等大家可以根据手里条件选择。以 PerfDog 来说它支持 Android 和 iOS登记后可免费使用覆盖 FPS、帧间隔、CPU 占用、GPU 占用、功耗等常见指标比较适合做帧率和性能分析。触控延迟测试可以分两种思路高速摄像法用 240FPS 或更高帧率的手机/摄像机拍摄手指接触屏幕和画面变化的瞬间再逐帧计算时间差。软件时间戳法通过 adb 读取触摸事件时间戳并结合系统 SurfaceFlinger 的帧上屏时间来计算延迟。高速摄像法更直观但对设备要求高软件法适合重复测试但实现门槛稍高后面会分开说明。2.3 统一测试条件为了减少偶然误差同一场景至少要测 3 轮。每轮测试时长建议不低于 5 分钟取各轮数据的平均值或中位数来代表设备表现。另外测试游戏和测试场景要固定。比如测原神就固定跑同一个野外路线或同一段秘境测王者荣耀就固定使用同一个英雄和同一波团战。不要中途切换画质档位也不要在测试过程中弹出输入法、通知栏。3. 帧率测试方法3.1 用 PerfDog 数帧PerfDog 的基本使用流程在 PC 上安装 PerfDog 客户端并登录账号。手机开启开发者选项和 USB 调试用数据线连接电脑。在 PerfDog 客户端中识别设备选择目标游戏进程。开始记录进入游戏完成指定测试操作。结束记录后导出 Excel 或 CSV 数据。PerfDog 会输出平均 FPS、FPS 曲线、帧间隔曲线、CPU 占用率、GPU 占用率等数据。导出后把 FPS 数据和帧间隔数据单独整理成一张表方便和触控延迟数据对齐。需要注意PerfDog 依赖 USB 连接部分设备需要提前安装驱动。如果识别不到设备优先检查 USB 调试授权弹窗是否允许。3.2 用 adb 读取 SurfaceFlinger 延迟节点如果不想使用第三方工具也可以用 adb 命令读取系统内部统计。SurfaceFlinger 是 Android 系统的图像合成服务它会记录每一帧到达屏幕的时间。调试模式下的查询命令如下adb shell dumpsys SurfaceFlinger --latency执行后会出现大量文本数据其中每一行代表一次屏幕刷新周期包含对应时间点的时间戳。连续执行多次并做差值计算就能估算出帧间隔和帧率。在比较高版本的 Android 系统中还可以使用下面的方式查看帧信息adb shell dumpsys gfxinfo package_name framestats这条命令适合查看应用渲染管线各阶段的耗时比如输入事件完成时间、VSYNC 时间、渲染提交时间等对分析触控延迟里“渲染环节占了多少”很有帮助。缺点是数据量很大需要写脚本解析。3.3 帧率数据如何整理采集到的原始帧数据往往是一个巨大的时间戳序列。建议整理成以下指标指标含义平均帧率总帧数 / 总耗时1% Low按帧间隔从差到好排序取前 1% 的平均值0.1% Low按帧间隔从差到好排序取前 0.1% 的平均值帧间隔标准差衡量帧间隔波动程度掉帧次数帧间隔超过目标阈值的次数比如目标是 60FPS那帧间隔阈值可以设为 20ms。只要连续帧间隔超过 20ms就认为发生了一次明显掉帧。如果要用 Python 处理一个简化的统计脚本如下# 文件路径analyze_fps.py import statistics # 示例数据每一帧的时间戳实际请从 PerfDog 或 dumpsys 中导出 frame_timestamps [ 1000.0, 1016.7, 1033.3, 1050.0, 1066.7, ... ] frame_intervals [] for i in range(1, len(frame_timestamps)): interval frame_timestamps[i] - frame_timestamps[i - 1] frame_intervals.append(interval) avg_fps 1000.0 / statistics.mean(frame_intervals) std_fps statistics.stdev(frame_intervals) # 1% low 计算思路按帧间隔从大到小排序取前 1% 平均值 sorted_intervals sorted(frame_intervals, reverseTrue) one_percent_low statistics.mean(sorted_intervals[:max(1, len(sorted_intervals) // 100)]) print(f平均帧率: {avg_fps:.2f} FPS) print(f帧间隔标准差: {std_fps:.4f} ms) print(f1% Low 帧间隔: {one_percent_low:.4f} ms)这段脚本展示的是数据处理思路实际使用时需要把时间戳来源替换成自己导出的数据。4. 触控延迟测试方法4.1 高速摄像实测法高速摄像法的操作思路准备一台支持 240FPS 或更高帧率的拍摄设备。把平板固定好确保拍摄画面能同时看到手指指尖和屏幕上对应操作区域。拍摄手指点击屏幕的一瞬间以及屏幕反馈出现的第一帧。用剪辑软件逐帧查看计算出两个时间点之间的帧数再乘上单帧时长。如果拍摄设备是 240FPS每一帧约 4.17ms如果是 960FPS每一帧约 1.04ms。帧率越高测量误差越小。这个方法的难点在于保持视角稳定。手指会遮挡屏幕所以最好让手指从侧面接触屏幕边缘区域或者使用可控的机械触发装置。为了减少误差每个操作至少测量 10 次去掉最大值和最小值后取平均。4.2 基于事件与画面时间戳的软件法软件法的核心思路是同时拿到两个时间触摸事件产生的时间。触摸结果在屏幕上显示的时间。触摸事件时间可以用 adb 查看adb shell getevent -lt /dev/input/event1这里-l表示把事件码显示为可读标签-t表示显示时间戳。不同设备触摸屏对应的输入节点名称可能不同需要先执行adb shell getevent查看触摸屏对应的事件节点。画面显示时间可以通过 SurfaceFlinger 的时间戳间接获取。更简单的方法是使用dumpsys gfxinfo里的framestats数据找到输入事件到渲染帧提交之间的耗时。这个数值就是“系统与应用渲染延迟”的一部分。把触摸事件时间戳和帧上屏时间戳做差就能估算出触控延迟。第一次做可能觉得复杂但脚本化之后就可以批量测试效率远高于高速摄像法。4.3 触控测试注意事项保护膜会改变手指和屏幕之间的接触反馈推荐裸机测试。手指按压速度和力度要尽量一致最好使用同一根手指或固定工具。测试过程中不要使用蓝牙外设或无线鼠标它们本身就是额外输入源。触控延迟测试建议在系统负载较低时进行避免后台任务抢占 CPU。另外触控延迟的“绝对值”在不同测量方法之间会有差异因为每种方法定义的起点和终点不完全一样。所以我更推荐用同一套方法做纵向对比而不是把不同来源的触控延迟数字拿来直接比较。5. 完整测试流程示例5.1 测试前准备清单这里把我实际用到的准备清单列出来大家可以对照执行项目状态系统已更新并重启是关闭后台非必要应用是确认 Y700 五代已连接 PerfDog 或 adb是设置屏幕亮度固定 50%是关闭系统加速/插帧/性能模式等增强功能是游戏画质档位固定是测试路线或操作脚本固定是高速摄像设备已固定好是实际操作中最容易遗漏的是“关闭加速”这一步。有些游戏助手是自动弹窗触发的可能在你进游戏时默认开启要注意看悬浮窗里的状态开关。5.2 固定场景与操作以原神为例可以固定一条包含跑图、战斗、频繁切人的路线。以王者荣耀为例可以固定选择同一个英雄在训练营或同一匹配段位中模拟一套连招。固定操作的关键是“复现性好”。如果测试者每次点击的位置、间隔都不一样触控延迟数据就会产生很大噪声。更规范的做法是先录制一段固定操作脚本使用自动化工具控制点击位置和时长。5.3 同步采集步骤我建议按下面的顺序操作启动 PerfDog 的帧率记录。在测试设备上开启高速摄像。按照固定脚本操作游戏。结束后先保存摄录文件再停止 PerfDog。把两组数据的时间轴对齐按操作节点切分。如果使用软件法测触控延迟则需要在操作开始时用 adb 记录系统时间后续把触摸事件时间戳和帧时间戳归一到同一时间轴上。5.4 记录表设计数据记录表至少要包含这些字段字段示例测试编号Test_01测试时间2025-06-01 20:30游戏名称原神场景描述全天候平原 跑图 5 分钟画质档位高画质 60FPS加速模式无加速平均帧率58.4 FPS帧间隔标准差2.31 ms触控延迟82 ms备注第 2 轮测试 温度上升后出现掉帧每一轮测试都单独记录。最终分析时相同条件和相同场景下至少保留 3 轮有效数据。6. 示例数据与关系分析6.1 示例数据表下面用一个“示例数据”非某一次真实测试结果来演示如何分析帧率与触控延迟的关系。假设在同一个场景、同一套操作脚本下测出 3 组数据测试编号平均帧率帧间隔标准差触控延迟Test_0158.4 FPS2.31 ms82 msTest_0255.2 FPS3.58 ms95 msTest_0359.1 FPS1.62 ms76 ms只看平均帧率Test_01 和 Test_03 相差不大但触控延迟差到了 6ms。原因是 Test_03 的帧间隔标准差更低帧时间更稳定输入事件等待下一个刷新周期的时间更可预期最终体感更快。这说明触控延迟不是“平均帧率”一个变量能决定的帧率波动同样重要。6.2 怎么分析帧率稳定性推荐把帧间隔曲线和触控延迟曲线放到同一张图里观察。横坐标是时间左侧纵轴是帧间隔右侧纵轴是触控延迟。如果触控延迟的尖峰总是和帧间隔尖峰同时出现基本可以判断延迟主要来自渲染性能问题。具体参考标准帧间隔标准差小于 1ms说明帧时间非常稳定。帧间隔标准差在 1ms 到 3ms 之间说明存在轻微波动。帧间隔标准差超过 3ms手感通常会有明显不规律感触控延迟也可能跟着波动。注意这个标准不适用于所有设备和刷新率主要用来做相对比较。6.3 帧率与触控延迟的关系总结在测试中可以看到几个普遍现象帧率从 30FPS 提升到 60FPS触控延迟会有明显下降幅度可能达到 10ms 甚至更高。帧率从 60FPS 提升到 90FPS 时触控延迟仍有下降但降幅变小。帧率从 90FPS 提升到 120FPS 时如果不修复输入分发与渲染链路的其他瓶颈延迟的下降空间就非常有限。也就是说帧率与触控延迟呈“边际递减关系”。高帧率是低触控延迟的必要条件但不是充分条件。真正决定最终手感的是整个输入到显示的链路是否足够高效。6.4 无加速与加速模式的对比思路无加速数据是原生基线。开启加速功能后可以重点看三件事插帧模式下平均帧率是否提升掉帧次数是否减少。触控延迟是否增加增加多少。画面是否出现撕裂、拖影或描边异常。如果插帧把 48FPS 提升到 96FPS但触控延迟反而增加了 20ms那这笔交易是否值得就取决于游戏类型。MOBA 类、射击类游戏更看重低延迟画质增强型单机游戏则可能更看重流畅画面。7. 常见问题与排查思路下面是测试过程中最常见的几类问题。问题现象常见原因解决思路触控延迟数值忽高忽低后台任务抢占 CPU、帧率波动大清理后台固定测试环境120Hz 下触控延迟反而变高温度升高导致降频或插帧模式介入降温后重测检查功能开关PerfDog 识别不到设备USB 调试授权未通过或驱动异常重新插拔检查授权弹窗实测帧率远低于标称刷新率游戏锁定帧率、性能热点触发降频查看游戏设置观察温度曲线高速摄像看不清画面变化拍摄帧率不足或屏幕亮度太低改用 240FPS 以上提高亮度7.1 触控延迟忽高忽低如果连续几轮测试触控延迟从 76ms 跳到 130ms优先怀疑后台进程。尤其是在游戏测试过程中后台推送、消息弹窗、同步任务会导致系统瞬时负载升高让输入事件处理变慢。排查顺序测试前用adb shell top查看当前进程占用。关闭非必要通知和自动同步。把测试场景压缩到 3 分钟以内避免长时间测试带来温度上升和降频。7.2 120Hz 下触控延迟反而变高出现这种情况先看设备温度。长时间高帧率渲染会让 SoC 发热如果系统检测到温度过高会降低 CPU/GPU 频率来保护硬件帧率波动加大触控延迟也会受影响。还有一点是检查系统是否自动开启了某种补帧或画质增强功能。有些增强功能会引入缓冲多一帧或两帧的处理时间导致触控延迟不降反升。7.3 无法测出稳定的触控延迟数值高速摄像法和软件法的测量基准不同数值本身有波动。建议把测量次数增加到 20 次以上去掉最高和最低的 25% 数据再取平均值。如果还是不稳定检查手指接触屏幕的按压面积和力度。按压面积过小或接触不稳定触摸屏可能在一个点附近反复上报导致时间戳出现异常。7.4 后台进程干扰帧率数据可以在测试期间执行下面命令查看主要进程和 CPU 占用率adb shell top -n 1 -m 20重点关注占用 CPU 较高的非游戏进程。测试期间最好开启勿扰模式并且把系统自动更新暂停到测试完成之后。8. 最佳实践与工程建议8.1 测试记录模板化无论是个人测试还是团队评测都建议把测试记录做成固定模板包含设备信息、系统版本、工具版本、测试场景、操作脚本、环境温度和测试结果。模板化可以减少沟通成本也让数据更容易被复现。8.2 关注“中间指标”而非只关注端点帧率和触控延迟是最终结果但中间过程也能提供很多信息CPU/GPU 占用率判断性能瓶颈。功耗判断能效表现。温度曲线判断散热策略。输入事件处理耗时判断系统调度效率。渲染管线各阶段耗时判断应用优化程度。这些指标能帮助你回答“为什么帧率不高”“为什么触控延迟高”而不是只停留在“高”或“低”的现象层面。8.3 多设备对比时保持同一套标准如果同时对比联想 Y700 五代和其他设备必须保证系统版本和游戏版本一致。画质档位一致。测试场景一致。触控延迟测量方法一致。室温与充电状态一致。只有控制好变量设备间的差距才能反映硬件和系统优化水平的真实差异。8.4 触控延迟优化的工程方向从测试结果倒推优化方向时可以按顺序排查优先降低渲染管线的单帧耗时稳定帧间隔。优化输入事件处理减少应用主线程的非必要任务。适当提高屏幕刷新率并匹配系统 VSYNC 调度。避免在高帧率渲染时叠加不必要的后处理特效。在游戏中合理使用多线程不要把渲染和逻辑都放在主线程。对于设备厂商或系统开发者来说还可以关注触控采样频率、触摸屏固件处理时间、输入设备到应用进程之间的事件调度延迟等方向。9. 总结这次围绕联想 Y700 五代的帧率和触控延迟测试核心思路可以总结成三句话帧率只看平均值不够要结合帧间隔标准差和 1% Low 才能反映真实稳定性。触控延迟不是单点结果而是触摸采样、系统调度、渲染管线、屏幕刷新共同作用的产物。无加速测试是所有对比的基线只有先跑通原生数据才能客观评估各种加速功能的价值。如果你是普通玩家测完这组数据后可以更有依据地决定要不要开插帧、要不要锁定高帧率模式如果你是开发者这套流程也能作为性能测试和手感受评测的标准参考。下一步建议从自己常玩的 1 款游戏开始按本文方法跑 3 轮测试把数据存入表格。坚持几个版本之后你会发现设备真实水平、系统更新是否有副作用、不同游戏优化差距在哪里都会变得一目了然。 联想Y700五代无加速帧率与触控延迟测评方法论
最近在测联想 Y700 五代的实际游戏表现时我特意把系统里的“加速”相关功能全部关掉只保留最基础的调度与渲染链路目的是搞清楚一件事在不借助任何增强手段的前提下这台设备的真实帧率到底能稳住多少而帧率波动又会对触控延迟产生什么样的影响。这篇就把整个测试方法、数据记录方式、对比思路以及容易踩的坑完整拆出来方便后续复测时直接照做。无论你是刚入手 Y700 五代想验证手感的玩家还是要做设备性能评估、游戏适配测试的开发者这套流程都可以套用。本文不会停留在“帧率很高”这种模糊结论而是重点说明如何用可复现的方式采集帧率与触控延迟再把两组数据做横向和纵向对比。1. 帧率与触控延迟先搞懂两个概念1.1 帧率是什么帧间隔又是什么帧率FPSFrames Per Second指每秒钟画面刷新的次数。60FPS 表示一秒渲染 60 帧每帧平均耗时约 16.67ms120FPS 表示一秒渲染 120 帧每帧平均耗时约 8.33ms。这个“每帧耗时”就是帧间隔Frame Time / Frame Interval。只关注平均帧率容易掩盖问题。比如某款游戏 5 分钟平均帧率显示为 59FPS但实际过程中可能频繁掉到 45FPS然后又迅速回到 60FPS。平均值看起来不错玩家体感却很卡。所以更合理的做法是把帧间隔的波动也记录下来尤其是 1% Low、0.1% Low 这类统计值用来衡量画面流畅度的下限。1.2 触控延迟不只是一个点触控延迟简单理解就是手指触碰屏幕到屏幕画面做出相应反馈之间的时间差。但这个时间差并不是单一环节造成的它通常包含几个组成部分触摸屏采样和上报时间。系统输入分发与事件处理时间。应用逻辑和渲染管线处理时间。屏幕自身刷新和像素响应时间。也就是说用户感受到的“跟手程度”是硬件、系统、应用、屏幕共同作用的结果。只看 CPU 频率或者只看屏幕刷新率都无法完整反映触控延迟。1.3 帧率如何影响触控延迟帧率对触控延迟的影响主要体现在画面反馈环节。假设屏幕刷新率为 120Hz每帧间隔 8.33ms那么手指点击后即使 CPU、GPU 马上处理完事件画面也只能等到下一个刷新周期才能显示最坏情况下就要多等一个刷新周期。在这个基础上如果帧率从 120FPS 掉到 60FPS帧间隔从 8.33ms 扩大到 16.67ms那么输入事件到达画面显示之间的等待窗口就会变长。这也是为什么高帧率模式下玩家普遍会觉得操作更跟手。但要注意帧率只是影响触控延迟的其中一个环节。如果系统输入分发或应用渲染管线本身延迟较高即使帧率很高触控延迟也不一定低。1.4 为什么“无加速”测试更值得做现在不少设备或游戏助手都提供了“性能模式”“插帧”“超分辨率”等增强功能。插帧技术可以在原始帧率较低时通过算法生成中间帧让画面看起来更流畅超分辨率则通过重建画面细节来提升清晰度。这些功能对体验有明显帮助但也可能引入额外延迟或画质副作用。“无加速”测试指的是关闭这些增强功能使用系统默认或标准调度。这样得到的数据更接近设备的原生渲染能力和原生输入延迟能帮助你判断设备的硬件底子到底如何。先测“无加速”基线再开启加速模式对比才能评估加速功能到底带来多少提升又付出了多少代价。2. 测试环境与设备准备2.1 设备与环境要求本文以联想 Y700 五代为测试设备系统版本、驱动版本以实际设备为准。测试前请把平板系统升级到稳定版并重启一次避免旧系统残留的异常状态影响数据。环境方面要尽量固定室内温度建议控制在 20℃ 到 28℃ 之间避免设备过热触发降频。充电状态要明确测试过程中保持充电或不充电不要中途切换。关闭后台不必要的应用尤其是消息推送、自动更新、云备份等。屏幕亮度固定为 50% 或固定某个档位避免亮度自动调节干扰。Wi-Fi 连接保持稳定如果游戏有联网对抗网络波动会直接影响帧率。建议把上述条件记录在测试表里方便复测时保持一致。2.2 测试工具选择帧率测试工具常用的是 PerfDog、FrameView、GameBench 等大家可以根据手里条件选择。以 PerfDog 来说它支持 Android 和 iOS登记后可免费使用覆盖 FPS、帧间隔、CPU 占用、GPU 占用、功耗等常见指标比较适合做帧率和性能分析。触控延迟测试可以分两种思路高速摄像法用 240FPS 或更高帧率的手机/摄像机拍摄手指接触屏幕和画面变化的瞬间再逐帧计算时间差。软件时间戳法通过 adb 读取触摸事件时间戳并结合系统 SurfaceFlinger 的帧上屏时间来计算延迟。高速摄像法更直观但对设备要求高软件法适合重复测试但实现门槛稍高后面会分开说明。2.3 统一测试条件为了减少偶然误差同一场景至少要测 3 轮。每轮测试时长建议不低于 5 分钟取各轮数据的平均值或中位数来代表设备表现。另外测试游戏和测试场景要固定。比如测原神就固定跑同一个野外路线或同一段秘境测王者荣耀就固定使用同一个英雄和同一波团战。不要中途切换画质档位也不要在测试过程中弹出输入法、通知栏。3. 帧率测试方法3.1 用 PerfDog 数帧PerfDog 的基本使用流程在 PC 上安装 PerfDog 客户端并登录账号。手机开启开发者选项和 USB 调试用数据线连接电脑。在 PerfDog 客户端中识别设备选择目标游戏进程。开始记录进入游戏完成指定测试操作。结束记录后导出 Excel 或 CSV 数据。PerfDog 会输出平均 FPS、FPS 曲线、帧间隔曲线、CPU 占用率、GPU 占用率等数据。导出后把 FPS 数据和帧间隔数据单独整理成一张表方便和触控延迟数据对齐。需要注意PerfDog 依赖 USB 连接部分设备需要提前安装驱动。如果识别不到设备优先检查 USB 调试授权弹窗是否允许。3.2 用 adb 读取 SurfaceFlinger 延迟节点如果不想使用第三方工具也可以用 adb 命令读取系统内部统计。SurfaceFlinger 是 Android 系统的图像合成服务它会记录每一帧到达屏幕的时间。调试模式下的查询命令如下adb shell dumpsys SurfaceFlinger --latency执行后会出现大量文本数据其中每一行代表一次屏幕刷新周期包含对应时间点的时间戳。连续执行多次并做差值计算就能估算出帧间隔和帧率。在比较高版本的 Android 系统中还可以使用下面的方式查看帧信息adb shell dumpsys gfxinfo package_name framestats这条命令适合查看应用渲染管线各阶段的耗时比如输入事件完成时间、VSYNC 时间、渲染提交时间等对分析触控延迟里“渲染环节占了多少”很有帮助。缺点是数据量很大需要写脚本解析。3.3 帧率数据如何整理采集到的原始帧数据往往是一个巨大的时间戳序列。建议整理成以下指标指标含义平均帧率总帧数 / 总耗时1% Low按帧间隔从差到好排序取前 1% 的平均值0.1% Low按帧间隔从差到好排序取前 0.1% 的平均值帧间隔标准差衡量帧间隔波动程度掉帧次数帧间隔超过目标阈值的次数比如目标是 60FPS那帧间隔阈值可以设为 20ms。只要连续帧间隔超过 20ms就认为发生了一次明显掉帧。如果要用 Python 处理一个简化的统计脚本如下# 文件路径analyze_fps.py import statistics # 示例数据每一帧的时间戳实际请从 PerfDog 或 dumpsys 中导出 frame_timestamps [ 1000.0, 1016.7, 1033.3, 1050.0, 1066.7, ... ] frame_intervals [] for i in range(1, len(frame_timestamps)): interval frame_timestamps[i] - frame_timestamps[i - 1] frame_intervals.append(interval) avg_fps 1000.0 / statistics.mean(frame_intervals) std_fps statistics.stdev(frame_intervals) # 1% low 计算思路按帧间隔从大到小排序取前 1% 平均值 sorted_intervals sorted(frame_intervals, reverseTrue) one_percent_low statistics.mean(sorted_intervals[:max(1, len(sorted_intervals) // 100)]) print(f平均帧率: {avg_fps:.2f} FPS) print(f帧间隔标准差: {std_fps:.4f} ms) print(f1% Low 帧间隔: {one_percent_low:.4f} ms)这段脚本展示的是数据处理思路实际使用时需要把时间戳来源替换成自己导出的数据。4. 触控延迟测试方法4.1 高速摄像实测法高速摄像法的操作思路准备一台支持 240FPS 或更高帧率的拍摄设备。把平板固定好确保拍摄画面能同时看到手指指尖和屏幕上对应操作区域。拍摄手指点击屏幕的一瞬间以及屏幕反馈出现的第一帧。用剪辑软件逐帧查看计算出两个时间点之间的帧数再乘上单帧时长。如果拍摄设备是 240FPS每一帧约 4.17ms如果是 960FPS每一帧约 1.04ms。帧率越高测量误差越小。这个方法的难点在于保持视角稳定。手指会遮挡屏幕所以最好让手指从侧面接触屏幕边缘区域或者使用可控的机械触发装置。为了减少误差每个操作至少测量 10 次去掉最大值和最小值后取平均。4.2 基于事件与画面时间戳的软件法软件法的核心思路是同时拿到两个时间触摸事件产生的时间。触摸结果在屏幕上显示的时间。触摸事件时间可以用 adb 查看adb shell getevent -lt /dev/input/event1这里-l表示把事件码显示为可读标签-t表示显示时间戳。不同设备触摸屏对应的输入节点名称可能不同需要先执行adb shell getevent查看触摸屏对应的事件节点。画面显示时间可以通过 SurfaceFlinger 的时间戳间接获取。更简单的方法是使用dumpsys gfxinfo里的framestats数据找到输入事件到渲染帧提交之间的耗时。这个数值就是“系统与应用渲染延迟”的一部分。把触摸事件时间戳和帧上屏时间戳做差就能估算出触控延迟。第一次做可能觉得复杂但脚本化之后就可以批量测试效率远高于高速摄像法。4.3 触控测试注意事项保护膜会改变手指和屏幕之间的接触反馈推荐裸机测试。手指按压速度和力度要尽量一致最好使用同一根手指或固定工具。测试过程中不要使用蓝牙外设或无线鼠标它们本身就是额外输入源。触控延迟测试建议在系统负载较低时进行避免后台任务抢占 CPU。另外触控延迟的“绝对值”在不同测量方法之间会有差异因为每种方法定义的起点和终点不完全一样。所以我更推荐用同一套方法做纵向对比而不是把不同来源的触控延迟数字拿来直接比较。5. 完整测试流程示例5.1 测试前准备清单这里把我实际用到的准备清单列出来大家可以对照执行项目状态系统已更新并重启是关闭后台非必要应用是确认 Y700 五代已连接 PerfDog 或 adb是设置屏幕亮度固定 50%是关闭系统加速/插帧/性能模式等增强功能是游戏画质档位固定是测试路线或操作脚本固定是高速摄像设备已固定好是实际操作中最容易遗漏的是“关闭加速”这一步。有些游戏助手是自动弹窗触发的可能在你进游戏时默认开启要注意看悬浮窗里的状态开关。5.2 固定场景与操作以原神为例可以固定一条包含跑图、战斗、频繁切人的路线。以王者荣耀为例可以固定选择同一个英雄在训练营或同一匹配段位中模拟一套连招。固定操作的关键是“复现性好”。如果测试者每次点击的位置、间隔都不一样触控延迟数据就会产生很大噪声。更规范的做法是先录制一段固定操作脚本使用自动化工具控制点击位置和时长。5.3 同步采集步骤我建议按下面的顺序操作启动 PerfDog 的帧率记录。在测试设备上开启高速摄像。按照固定脚本操作游戏。结束后先保存摄录文件再停止 PerfDog。把两组数据的时间轴对齐按操作节点切分。如果使用软件法测触控延迟则需要在操作开始时用 adb 记录系统时间后续把触摸事件时间戳和帧时间戳归一到同一时间轴上。5.4 记录表设计数据记录表至少要包含这些字段字段示例测试编号Test_01测试时间2025-06-01 20:30游戏名称原神场景描述全天候平原 跑图 5 分钟画质档位高画质 60FPS加速模式无加速平均帧率58.4 FPS帧间隔标准差2.31 ms触控延迟82 ms备注第 2 轮测试 温度上升后出现掉帧每一轮测试都单独记录。最终分析时相同条件和相同场景下至少保留 3 轮有效数据。6. 示例数据与关系分析6.1 示例数据表下面用一个“示例数据”非某一次真实测试结果来演示如何分析帧率与触控延迟的关系。假设在同一个场景、同一套操作脚本下测出 3 组数据测试编号平均帧率帧间隔标准差触控延迟Test_0158.4 FPS2.31 ms82 msTest_0255.2 FPS3.58 ms95 msTest_0359.1 FPS1.62 ms76 ms只看平均帧率Test_01 和 Test_03 相差不大但触控延迟差到了 6ms。原因是 Test_03 的帧间隔标准差更低帧时间更稳定输入事件等待下一个刷新周期的时间更可预期最终体感更快。这说明触控延迟不是“平均帧率”一个变量能决定的帧率波动同样重要。6.2 怎么分析帧率稳定性推荐把帧间隔曲线和触控延迟曲线放到同一张图里观察。横坐标是时间左侧纵轴是帧间隔右侧纵轴是触控延迟。如果触控延迟的尖峰总是和帧间隔尖峰同时出现基本可以判断延迟主要来自渲染性能问题。具体参考标准帧间隔标准差小于 1ms说明帧时间非常稳定。帧间隔标准差在 1ms 到 3ms 之间说明存在轻微波动。帧间隔标准差超过 3ms手感通常会有明显不规律感触控延迟也可能跟着波动。注意这个标准不适用于所有设备和刷新率主要用来做相对比较。6.3 帧率与触控延迟的关系总结在测试中可以看到几个普遍现象帧率从 30FPS 提升到 60FPS触控延迟会有明显下降幅度可能达到 10ms 甚至更高。帧率从 60FPS 提升到 90FPS 时触控延迟仍有下降但降幅变小。帧率从 90FPS 提升到 120FPS 时如果不修复输入分发与渲染链路的其他瓶颈延迟的下降空间就非常有限。也就是说帧率与触控延迟呈“边际递减关系”。高帧率是低触控延迟的必要条件但不是充分条件。真正决定最终手感的是整个输入到显示的链路是否足够高效。6.4 无加速与加速模式的对比思路无加速数据是原生基线。开启加速功能后可以重点看三件事插帧模式下平均帧率是否提升掉帧次数是否减少。触控延迟是否增加增加多少。画面是否出现撕裂、拖影或描边异常。如果插帧把 48FPS 提升到 96FPS但触控延迟反而增加了 20ms那这笔交易是否值得就取决于游戏类型。MOBA 类、射击类游戏更看重低延迟画质增强型单机游戏则可能更看重流畅画面。7. 常见问题与排查思路下面是测试过程中最常见的几类问题。问题现象常见原因解决思路触控延迟数值忽高忽低后台任务抢占 CPU、帧率波动大清理后台固定测试环境120Hz 下触控延迟反而变高温度升高导致降频或插帧模式介入降温后重测检查功能开关PerfDog 识别不到设备USB 调试授权未通过或驱动异常重新插拔检查授权弹窗实测帧率远低于标称刷新率游戏锁定帧率、性能热点触发降频查看游戏设置观察温度曲线高速摄像看不清画面变化拍摄帧率不足或屏幕亮度太低改用 240FPS 以上提高亮度7.1 触控延迟忽高忽低如果连续几轮测试触控延迟从 76ms 跳到 130ms优先怀疑后台进程。尤其是在游戏测试过程中后台推送、消息弹窗、同步任务会导致系统瞬时负载升高让输入事件处理变慢。排查顺序测试前用adb shell top查看当前进程占用。关闭非必要通知和自动同步。把测试场景压缩到 3 分钟以内避免长时间测试带来温度上升和降频。7.2 120Hz 下触控延迟反而变高出现这种情况先看设备温度。长时间高帧率渲染会让 SoC 发热如果系统检测到温度过高会降低 CPU/GPU 频率来保护硬件帧率波动加大触控延迟也会受影响。还有一点是检查系统是否自动开启了某种补帧或画质增强功能。有些增强功能会引入缓冲多一帧或两帧的处理时间导致触控延迟不降反升。7.3 无法测出稳定的触控延迟数值高速摄像法和软件法的测量基准不同数值本身有波动。建议把测量次数增加到 20 次以上去掉最高和最低的 25% 数据再取平均值。如果还是不稳定检查手指接触屏幕的按压面积和力度。按压面积过小或接触不稳定触摸屏可能在一个点附近反复上报导致时间戳出现异常。7.4 后台进程干扰帧率数据可以在测试期间执行下面命令查看主要进程和 CPU 占用率adb shell top -n 1 -m 20重点关注占用 CPU 较高的非游戏进程。测试期间最好开启勿扰模式并且把系统自动更新暂停到测试完成之后。8. 最佳实践与工程建议8.1 测试记录模板化无论是个人测试还是团队评测都建议把测试记录做成固定模板包含设备信息、系统版本、工具版本、测试场景、操作脚本、环境温度和测试结果。模板化可以减少沟通成本也让数据更容易被复现。8.2 关注“中间指标”而非只关注端点帧率和触控延迟是最终结果但中间过程也能提供很多信息CPU/GPU 占用率判断性能瓶颈。功耗判断能效表现。温度曲线判断散热策略。输入事件处理耗时判断系统调度效率。渲染管线各阶段耗时判断应用优化程度。这些指标能帮助你回答“为什么帧率不高”“为什么触控延迟高”而不是只停留在“高”或“低”的现象层面。8.3 多设备对比时保持同一套标准如果同时对比联想 Y700 五代和其他设备必须保证系统版本和游戏版本一致。画质档位一致。测试场景一致。触控延迟测量方法一致。室温与充电状态一致。只有控制好变量设备间的差距才能反映硬件和系统优化水平的真实差异。8.4 触控延迟优化的工程方向从测试结果倒推优化方向时可以按顺序排查优先降低渲染管线的单帧耗时稳定帧间隔。优化输入事件处理减少应用主线程的非必要任务。适当提高屏幕刷新率并匹配系统 VSYNC 调度。避免在高帧率渲染时叠加不必要的后处理特效。在游戏中合理使用多线程不要把渲染和逻辑都放在主线程。对于设备厂商或系统开发者来说还可以关注触控采样频率、触摸屏固件处理时间、输入设备到应用进程之间的事件调度延迟等方向。9. 总结这次围绕联想 Y700 五代的帧率和触控延迟测试核心思路可以总结成三句话帧率只看平均值不够要结合帧间隔标准差和 1% Low 才能反映真实稳定性。触控延迟不是单点结果而是触摸采样、系统调度、渲染管线、屏幕刷新共同作用的产物。无加速测试是所有对比的基线只有先跑通原生数据才能客观评估各种加速功能的价值。如果你是普通玩家测完这组数据后可以更有依据地决定要不要开插帧、要不要锁定高帧率模式如果你是开发者这套流程也能作为性能测试和手感受评测的标准参考。下一步建议从自己常玩的 1 款游戏开始按本文方法跑 3 轮测试把数据存入表格。坚持几个版本之后你会发现设备真实水平、系统更新是否有副作用、不同游戏优化差距在哪里都会变得一目了然。