联想 Y700 五代这类游戏平板真正让人纠结的指标往往不是峰值性能而是帧率和触控延迟能否在长时间游戏里维持稳定。无加速模式下测试意味着不开启插帧、超分、性能调节之类的辅助功能让设备用自己的渲染链路跑游戏这样得到的帧率曲线和触控延迟数据才最能反映设备真实体验。这篇文章不打算只给一个“好或差”的结论而是把测试思路、工具、步骤、数据解读和排错方法完整拆开。即使手边不是 Y700 五代这套流程也可以直接套用到安卓平板、手机或掌机上。你会看到帧率从 60 掉到 45、再到 30 的过程中触控延迟并不是匀速变长的它和垂直同步、渲染完成时机、系统输入采样、游戏逻辑帧率都有关。理解了这些再回头看“要不要开插帧”“画质能不能拉满”“触控跟不跟手”这类问题就能自己判断了。1. 为什么无加速测试能暴露帧率与触控延迟的真实关系很多评测只报平均帧率但平均帧率掩盖了掉帧的分布。反过来只看触控延迟也不够因为触控延迟会随渲染负载变化。无加速测试的价值在于它把插帧、超分、功耗调度这些增强功能全部关闭让设备在原始渲染链路下工作。这样测出的帧率曲线和触控延迟才能说明设备本身的能力边界而不是厂商调校后的“包装结果”。1.1 触控延迟由哪几段组成触控延迟不是一个单点时间而是一整条链路从手指按下到屏幕画面更新的总耗时。在安卓平板上大致可以分为四段触摸采样与上报触摸屏驱动以固定频率采样触控点比如 120Hz 或 240Hz 触摸采样率。采样率越高手指刚接触就被捕捉到的概率越大这一段时间通常为 4ms 到 8ms。系统输入分发驱动上报后输入事件进入 InputDispatcher再投递给当前前台应用。系统负载高时分发延迟会被拉长。应用处理与渲染游戏逻辑线程根据触摸事件更新角色或视角然后 CPU 提交渲染指令GPU 完成绘制。这一段受帧率影响最大。合成与屏幕刷新SurfaceFlinger 合成各图层通过垂直同步信号送给屏幕面板。这一段又分为合成耗时、队列等待和像素响应时间。所以当你说“触控延迟变大了”只可能是以上某一段变长了。无加速测试时插帧不会改变前三段而帧率下降主要影响第三段和第四段。1.2 帧率如何影响触控延迟游戏通常按照“逻辑更新渲染”的方式按帧循环。假设游戏目标帧率为 60FPS那么理想情况下 16.7ms 完成一次逻辑更新、渲染和呈现。触控事件处理器会在帧循环里轮询输入事件帧率越低每帧时间越长输入事件被处理的等待时间就越长。这里有一个关键现象触控延迟并不仅仅取决于平均帧率还取决于帧耗时分布的稳定性。如果帧耗时稳定在 16.7ms触控延迟大约等于“半帧等待时间 一帧渲染时间 屏幕刷新等待”总体会比较平稳。如果帧耗时在 10ms 到 30ms 之间剧烈抖动那么有时候触摸事件刚好赶上帧开始反应快有时候事件刚错过帧边界要等下一帧反应就慢。这种不稳定的“拖手”或“跳变”体感甚至比稳定 45 帧更难接受。如果帧率直接锁到 30FPS每帧 33.3ms触控事件几乎错过了当前帧处理窗口大多数操作都要跨帧执行延迟会明显增加。也就是说帧率下降并不是简单地把延迟从 50ms 变成 70ms 这种线性增长而是通过帧边界排队机制把延迟分布整体拉大。1.3 无加速测试的意义与局限无加速测试的意义在于建立基准。开启插帧后屏幕刷新率可能是 120Hz但内容逻辑刷新率仍然可能是 60Hz甚至更低。插帧只能让画面更流畅不会让触控事件的处理间隔变短。无加速测试能把这个差异暴露出来显示帧率和触控响应所依赖的逻辑帧率必须分开看。同时也要说明局限。无加速测试不代表实际游戏体验全部因为很多设备提供性能模式、游戏插帧、超分等功能这些功能确实能改善画面流畅度。问题是这些功能会让帧率数据变得不真实比如 PerfDog 里可能显示 120FPS但它实际采集的是显示帧率而不是游戏逻辑帧率。此时再看触控延迟如果你没有把插帧关闭可能得出“帧率很高但触控依然不稳定”的错误结论。注意无加速测试并不比有加速测试“更高级”。它是为了做对照实验。先把无加速基线测清楚再逐步开启插帧、超分、性能模式看每一步对帧率和触控延迟产生了什么影响。2. 测试前要统一设备和系统环境帧率和触控测试最怕变量失控。如果不同人测出的数据差异很大往往不是设备差异而是环境没统一。下面这套准备流程尽量减少干扰因素。2.1 设备、线材和拍摄环境设备联想 Y700 五代确认系统版本和已安装软件。不同系统版本可能存在调度策略差异。充电状态建议接入稳定电源或保持相同电量区间。部分设备在低电量会主动降频影响帧率表现。表面温度测试前先静置一段时间避免刚跑完大型游戏就接着测发热降频会导致第二组数据比第一组差很多。拍摄设备需要支持 120FPS 或更高帧率的慢动作录像用来测量手指接触屏幕到画面变化的时间。手机、运动相机都可以只要能看清画面变化点。环境光避免强光反射保证慢动作视频中屏幕画面清晰可见。2.2 软件工具选择常用工具有三类工具用途说明PerfDog帧率、Jank、CPU、GPU、温度采集需要注册服务安卓端通过 USB 连接目前是移动端性能测试常用工具DevEco Profiler鸿蒙或安卓设备帧分析如果是平板系统可以用它看渲染链路各阶段耗时Android Studio Profiler帧渲染时间、CPU/GPU 耗时偏开发场景适合定位掉帧发生在渲染还是逻辑adb shell dumpsys SurfaceFlinger查看 SurfaceFlinger 合成帧率免费适合简单验证显示帧率慢动作相机触控延迟测量需要配合时间轴逐帧播放如果只是复现报告PerfDog 加慢动作相机就够用了。如果想深入分析掉帧原因再引入 DevEco 或 Android Studio Profiler。2.3 系统设置统一进入开发者选项后建议统一如下设置关闭“自动亮度”和“自动亮度优化”避免屏幕亮度波动影响视觉判断。关闭“HarmonyOS 或安卓的动画缩放”中的“窗口动画缩放、过渡动画缩放、动画程序时长缩放”减少系统动画干扰。设置-显示-屏幕刷新率根据测试目标选择 60Hz 或 120Hz。默认建议先测 120Hz因为这是游戏平板的主推体验再做一组 60Hz 对照。设置-电池-高性能模式如果测试目标是“无加速下的原生帧率”建议开启高性能模式因为性能受限不是本测试的重点。游戏应用内关闭“插帧”“超分”“画质增强”等增强功能这就是“无加速”含义。这些设置看起来琐碎但漏掉任何一个都会让结论失真。比如动画缩放没关触控延迟可能被系统动画多算了 100ms自动亮度触发亮度跳变时屏幕响应时间也会发生变化。3. 帧率数据采集从命令行到性能工具帧率采集最重要的是区分“显示帧率”和“应用渲染帧率”。大多数游戏会通过 SurfaceFlinger 以固定刷新率呈现内容即使应用内部只有 30FPS显示端也可能补帧到 60Hz 或 120Hz。这就是为什么单看系统显示帧率不可靠。3.1 用 adb 快速采集基础帧信息没有 PerfDog 时可以先通过 adb 获取简单信息adb shell dumpsys SurfaceFlinger --latency这个命令会列出当前 Surface 的帧时间戳但是输出内容不够直观适合用于验证设备是否在以目标刷新率工作。更好的方式是使用 PerfDog 或 DevEco Profiler 这类工具它们已经封装了帧时间戳解析、Jank 计算和 CPU/GPU 时间线。PerfDog 命令行方式适合自动化场景一个最小命令示例perfdog -deviceY700 -packagecom.example.game -duration180 -outputresult.csv这里-package换成实际游戏包名-duration是测试时长-output是导出文件路径。如果使用图形界面则创建测试任务后选择设备、应用开始记录即可。注意PerfDog 抓到的帧率是设备实际显示的帧率不一定等同于游戏内部逻辑帧率。当你开启插帧后这个数字会虚高。无加速测试时因为没有任何补帧介入显示帧率基本可以代表渲染帧率。3.2 关键指标解读不要只盯 FPS 平均值重点关注以下几项指标含义参考判断FPS平均帧率一帧耗时倒数的平均越高不代表越流畅Jank掉帧次数单帧耗时超过预期阈值的次数数值越小越稳定BigJank严重掉帧次数通常帧耗时翻倍以上直接影响触控稳定性JankRate每分钟掉帧次数对比不同场景的稳定性帧耗时曲线每帧渲染时间的分布观察是否存在周期性尖峰CPU / GPU 占用判断瓶颈在逻辑还是渲染结合掉帧时间点判断举个例子帧耗时曲线如果每隔 1 秒出现一次 100ms 尖峰尽管平均 FPS 依然有 55 左右但触控体感会很差。因为尖峰所在的那一帧输入事件被拖到下一帧处理玩家会感觉“点了一下角色过了一会才动”。3.3 测试场景要固定测试场景是数据可比的基石。用 Y700 五代测试时至少要确定游戏内选哪个地图、哪个关卡、哪个 Boss 阶段。人物是站在原地不动还是持续移动、放技能、转动视角。同一场景测试 3 次每次 3 到 5 分钟取中间值或平均值。推荐使用“固定路线固定连招”的方式。比如在某张地图从 A 点跑到 B 点沿途放指定技能避免过快结束战斗导致渲染负载不足。这样测出的帧率曲线才有稳定的负载分布。4. 触控延迟量化慢动作拍摄与软件标记触控延迟的严格测量需要软硬件配合。手机触控测试的常见做法有固定延迟测试仪、高速摄影和软件时间戳三种。个人开发者通常用慢动作拍摄就够了。4.1 慢动作拍摄法拍摄过程把平板固定在支架上记录屏幕和手指落点在同一画面中。打开慢动作录像帧率越高越好建议 120FPS 以上。用一根手指快速点击屏幕固定按钮比如射击按钮或技能键。录完后用视频剪辑工具逐帧播放记录手指接触屏幕的时间点以及画面出现开火或技能效果的时间点。计算两者帧数差再除以视频帧率得到触控延迟。例如慢动作视频为 240FPS手指接触屏幕出现在第 120 帧画面反馈出现在第 129 帧则延迟约为 9 帧 / 240FPS 37.5ms。拍摄时要注意无法保证手指触屏那一帧恰好被拍到。手指下落过程中可能是第 119 帧只差 1mm第 120 帧已经接触。这个误差通常在 1 到 2 帧范围内足够判断趋势但不能当作精密仪器数据。4.2 软件标记法补充慢动作拍摄测的是“手指到画面”的端到端延迟但如果想定位延迟发生在系统输入还是游戏逻辑还缺一层数据。可以用 adb 注入触摸事件来做时间戳验证adb shell input tap x y这个命令会注入一次触摸事件然后通过应用日志或帧时间戳记录响应时间。不过它测的是系统注入路径和真正手指触摸的驱动路径还有差异只能作为辅助手段。更专业的方法是在应用内加埋点。比如在游戏 OnTouchEvent 回调里记录时间戳在下一帧渲染完成时记录时间戳两者差值就是“事件处理渲染”的耗时。但这需要游戏代码可控制大多数第三方游戏无法这样改所以实际测试仍以慢动作拍摄为主。4.3 帧率与触控延迟如何同步对比真正有意义的测试不是单独拿一个平均值而是看同一条时间轴上的对应关系。建议的做法是PerfDog 导出帧率曲线 CSV。慢动作视频中记录各时间点的触控延迟。把两者按时间对齐比如“第 60 秒附近帧率掉到 30FPS此时测到触控延迟为 60ms第 120 秒附近帧率恢复 60FPS触控延迟回落到 40ms”。如果测试条件允许也可以采用“固定时间间隔采样”的方法每 10 秒做一次连点操作然后从 PerfDog 时间轴上截取对应时段的帧率数据。这样至少可以把触控延迟区间和帧率区间对应起来。5. 帧率与触控延迟的关系分析以下分析基于无加速测试得到的常见规律具体数据会因游戏类型和系统调度不同而波动。这里用表格示意“帧率状态与触控延迟的对应关系”实际项目中需要填上自己的测量数值。5.1 稳定 60FPS 区间的触控表现稳定 60FPS 时每帧 16.7ms。以射击类游戏为例常见情形手指点击到鼠标或准星产生反馈端到端延迟可以在 45ms 到 60ms 之间。其中触摸采样约 8ms输入分发约 5ms应用渲染等待约 16.7ms合成显示约 10 到 15ms。60FPS 下触控表现已经比较跟手大多数人正常玩游戏不会察觉到明显拖拽。无加速测试中如果 Y700 五代在复杂场景也能稳定 60FPS那么触控延迟表现为“均匀且短”。这里的判断重点不是单纯延迟数值小而是多次重复测试之间延迟波动很小。5.2 掉帧和波动区间触控延迟变化帧率状态帧耗时触控延迟表现体感稳定 60FPS16.7ms时延波动小跟手轻微波动 50-60FPS16.7-20ms偶发延迟增加 5-10ms偶有挑帧感明显掉帧 40-50FPS20-25ms延迟波动增加帧边界排队明显移动视角时有拖慢稳定 30FPS33.3ms延迟比 60FPS 高 10-20ms明显迟滞波动 25-40FPS25-40ms延迟忽高忽低最难受的状态操作不可预测需要特别提到“波动 25-40FPS”这个状态。它并不是 30FPS 的平均体验而是某些帧耗时 25ms某些帧耗时 40ms。触控事件如果落在长帧之后体感就像是“点了一下没反应然后突然跳出去”。这种延迟的离散程度比延迟平均值更能影响玩家评价。5.3 120Hz 刷新率下的变化Y700 五代支持高刷新率屏幕。无加速模式下如果游戏目标帧率是 60FPS而屏幕刷新率是 120Hz画面每帧会被扫描两次显示延迟会略有下降但游戏逻辑和触控处理仍以 60FPS 为周期运行。因此刷新率提高并不能解决逻辑帧率低造成的触控延迟问题。只有当游戏本身支持 120FPS 输出或者帧率能达到 90FPS 以上时60Hz 和 120Hz 刷新率对触控延迟的差异才会明显体现。对比测试时建议固定使用 120Hz 刷新率分别测试游戏锁 60、游戏锁 90、游戏不锁帧三种情况观察帧率升高后触控延迟的下降趋势。6. 测试中的常见问题和排查链路数据对不上、现象和帧率矛盾往往不是设备问题而是测试方法或工具理解有误。下面按现象给出排查思路。6.1 帧率稳定 60FPS但触控依然感觉拖手可能原因游戏逻辑帧率不是 60FPS显示合成器在补帧。屏幕刷新率与游戏帧率不匹配垂直同步导致等待。触摸采样率过低比如 60Hz 触摸采样那么手指移动本身就有一拍一跳。系统输入分发被后台进程阻塞输入事件不能及时投递。排查方式在开发者选项中开启“指针位置”观察手指轨迹是否连续。用 PerfDog 查看 CPU 占用确认应用主线程没有进入繁忙状态。查看游戏内是否有帧率限制选项比如锁 30 或锁 60。6.2 帧率掉到 30FPS 时延迟激增这是正常现象但不只是“因为帧率低”。帧率从 60 掉到 30意味着两帧之间的时间从 16.7ms 变成 33.3ms。输入事件如果恰好在帧处理窗口之后到达就要多等一整帧才能被处理。如果场景中还存在 GPU 争抢、内存抖动延迟会进一步上升。排查方式看帧耗时曲线确认是 CPU 瓶颈还是 GPU 瓶颈。检查温度曲线。如果温度升高后掉帧说明需要清理后台应用或优化散热。检查是否有周期性 GC 日志在无加速测试下应用主线程 GC 会造成长帧。6.3 数据对不上PerfDog 显示高帧率但拍摄看起来不流畅这个现象最容易出现在开启补帧或超分的情况下。PerfDog 采集的是 SurfaceFlinger 合成后的显示帧率如果厂商插帧在合成层生效显示帧率会变成 90 或 120FPS但游戏内部逻辑更新可能仍然只有 30 或 60FPS。这时画面虽然流畅触控响应对应的是逻辑帧率仍然会慢。排查方式确认无加速测试中是否关闭了游戏内所有增强选项。如果系统级游戏助手有插帧开关也要关闭。对比显示帧率和 PerfDog 中的应用帧率字段两者不一致就是补帧在工作。6.4 慢动作拍摄的延迟数值每次相差很大慢动作拍摄的误差来源主要是“手指接触帧”的选取。手指下落速度很快视频帧率不够高时接触瞬间的判定可能偏差 1 到 2 帧。如果视频只有 120FPS单帧 8.3ms误差就能达到 16ms这已经足以干扰延迟趋势判断。处理建议用 240FPS 或更高帧率拍摄。每个场景重复 10 次点击去掉最大最小值后取平均值。不要只注意平均延迟还要记录延迟分布。如果 10 次结果在 40ms 到 70ms 之间说明系统稳定性不佳。7. 测试报告整理与可复用检查清单有了测试数据还要整理成能说服自己的报告。写报告时明确区分“事实数据”和“体感结论”避免把主观感受写成设备缺陷。7.1 测试报告结构推荐按以下字段记录字段填写示例设备型号联想 Y700 五代系统版本写明实际版本屏幕刷新率120Hz性能模式高性能游戏名称示例某射击游戏游戏画质档位高清高帧率是否开启加速关闭插帧、关闭超分测试场景地图A固定路线测试时长3 分钟 x 3 组平均 FPS填入实测数据Jank 次数填入实测数据触控延迟均值填入实测数据触控延迟波动范围填入实测数据温度测试结束温度表格越细致越容易复现和对比。写结论时优先使用“稳定区间”而不是“平均数值”比如“在场景 A 中帧率稳定在 58-60FPS触控延迟集中在 45-55ms”这比写“平均帧率 59.5 平均延迟 50ms”更有参考价值。7.2 游戏内设置建议结合无加速测试结果不同画质档位下触控延迟表现会有差异。一般建议按以下方式选择如果追求最跟手的竞技体验优先保证帧率稳定达到目标刷新率再考虑画质。如果帧率无法稳定在 60可以把画质降低一档而不是开启插帧来“骗眼睛”。大多数游戏里抗锯齿和阴影对 GPU 压力较大关闭它们通常能减少长帧尖峰。尽量关闭动态模糊和景深这类效果对触控延迟没有增益但会加重渲染负担。无加速测试的意义在于帮你找到“画质和跟手度”的平衡点。测试数据就是决策依据。7.3 测试前检查清单检查项状态平板电量大于 60% 或接入稳定电源是/否设备静置降温未在强热环境下测试是/否系统动画缩放已关闭是/否自动亮度已关闭亮度固定是/否屏幕刷新率固定为目标档位是/否游戏内插帧、超分、动态模糊已关闭是/否游戏助手类应用未开启补帧开关是/否后台应用已清空测试期间不弹通知是/否PerfDog 或其他工具已连接成功是/否慢动作相机帧率已设置到 120FPS 以上是/否每个场景计划测试 3 次以上是/否这些检查项看着基础但任何一项缺失都可能导致后续所有数据无效。8. 对无加速测试的最终判断与扩展方向无加速测试是移动设备性能与交互体验评估的基准层。它能把“帧率”和“触控延迟”放在同一条真实渲染链路上观察排除插帧、补帧、超分带来的假流畅让设备和游戏的原始能力被看到。如果接下来要往深了做可以从三个方向扩展。第一个方向是引入更多帧级别分析工具用 Android Studio Profiler 定位单帧内 CPU 和 GPU 耗时把“掉帧”拆成“逻辑慢”“渲染慢”“合成慢”三种原因。第二个方向是做有加速和无加速的对照实验在 Y700 五代上开启插帧后再测一遍触控延迟记录显示帧率升高但触控延迟变化不明显的数据用数据说明增强功能的边界。第三个方向是增加更多游戏类型射击、MOBA、开放世界类型的渲染负载分布完全不同帧率曲线和触控延迟的关系也会不同。新手如果只想复现这篇文章的流程建议从一款自选游戏开始先跑 3 组无加速测试记录表格里的所有字段。只要耐心做完这一遍你就会对“帧率与触控延迟的关系”有完全不同于只看评测数字的认知。这个认知比任何现成结论都值钱。