1. 为什么坚持做“无加速”测试
在聊联想拯救者 Y700 五代之前，先说一个我自己的真实经历。
有一阵子我拿平板玩游戏，游戏内置帧率显示一直稳定在 120 上下，画面也确实顺滑，但我总感觉操作有点“隔着一层东西”：手指已经划过去了，角色好像慢了那么一丁点才做出反应。这种体感很微妙，不是掉帧那种明显的卡顿，而是反馈不够干净利落。后来我把设备上所有“性能增强”“超帧”“插帧”之类的开关全部关掉，再跑同一局，帧率确实降了一截，但操作的“跟手度”反而回来了。
这个经历让我意识到一个问题：很多设备评测里经常把帧率和触控延迟混在一起说，好像帧率越高操作就一定越跟手，但实际情况根本不是这么简单。
先说清楚一个关键定义：这里的“无加速”，指的是不开启设备自带或游戏里提供的插帧、超帧、性能增强这类额外处理。简单理解，就是让设备用原生渲染能力去跑，而不是靠算法“补”出更多画面。很多人测帧率时会默认打开各种加速开关，觉得这样能体现设备上限，但如果你的目标是判断“这台设备打游戏到底跟不跟手”，无加速测试反而更值得做。
为什么？
因为插帧类功能处理的是“显示端”的画面数量，它可以让屏幕上的画面看起来更流畅，但不会让“手指触摸 → 系统处理 → 游戏逻辑响应 → 画面更新”这条链路变快。在某些情况下，它甚至会因为额外的处理步骤，让触控反馈的延迟略微变大。换句话说，你看到的是“多出来的画面”，但你按下去之后，游戏什么时候响应你，本质上是另一套逻辑。
所以这次围绕 Y700 五代做帧率与触控延迟的对照测试，我坚持一个原则：先把所有加速相关功能关掉，测出设备原生状态下的帧率曲线和触控响应，再考虑开加速去对比。原生状态才是判断设备真实水平的基线。
1.1 加速功能掩盖了什么
先解释一下，移动端常见的“加速”至少有三种：
- 展示端的插帧：在原有帧之间插入中间帧，提高屏幕上的刷新观感。
- 渲染端的超分/超帧：通过算法辅助渲染，让设备以更低的内部负载获得更高的输出。
- 系统级的性能调度：比如强制满频、拉高 GPU 频率、解锁温度墙。
这三种功能都会影响帧率数据，但都不会改变输入链路的时间开销。更关键的是，它们会影响“帧率数字”的真实含义。比如插帧后平均帧从 60 变成 120，但游戏逻辑本身可能仍然只有 60 帧，触控采样、事件处理、游戏逻辑更新周期都没有变快。你看到的是 120 的画面，体验到的却是 60 的逻辑响应，甚至因为插帧引入的延迟，体感上还更钝。
这就是为什么很多玩家会困惑：“明明帧率很高，为什么总是觉得不跟手？” 因为看到的帧率只是显示层，而触控延迟是整条链路的结果。
1.2 无加速测试的价值不只是“跑分低一点”
无加速测试的好处，是让设备回到一个“可解释”的状态。
当你看到 Y700 五代在无加速状态下跑某一款游戏是 58 帧、偶尔掉到 45 帧，并且配合触控测试发现手指点击到画面反应的间隔在某个区间内波动，这组数据就能真正说明问题：性能够不够、渲染稳不稳定、输入链路有没有明显延后。
而一旦打开加速，帧率可能变成 90、120，但触控延迟未必变好，这时你再测数据，就很难判断问题出在渲染能力、调度策略还是输入链路上。所有变量混在一起，没法定位。
所以我的判断是：无加速测试的目的，不是证明设备“原生跑不到高帧率”，而是获得一个稳定的参照系，后续所有加速功能的对比都基于这个参照系去评估。没有这个基线，后面的所有数据都没有对照意义。
1.3 谁需要这套测试流程
这套流程并不是给专业评测机构准备的，普通玩家同样用得上：
- 想确定某台平板玩某款游戏到底顺不顺手的玩家。
- 做完系统更新后，感觉设备“变慢了”或“触控不跟手”的玩家。
- 打算在买设备前，用同样的方法在预算价位里横向比较几台设备的玩家。
- 想弄清楚“帧率到底是多少才算流畅”这个问题的人。
2. 帧率测试：别只记平均帧
先承认一个现实：绝大多数普通玩家没有专门的测试设备，所以帧率测试能选的方法有限，但有限不代表没用。
我的建议是把测试拆成两个阶段：先用最简单的工具拿到整体数据，再用更细的指标去定位问题。
2.1 工具准备：内置帧率显示与外部监测
Y700 这一类平板通常会在游戏模式或开发者工具里提供帧率显示选项。系统级帧率显示适合做初步确认，比如看某个游戏是不是锁帧、掉帧严重不严重。但如果要记录一整局游戏的帧率曲线，系统内置显示就不够用了，因为你不一定能导出历史数据。
常见的替代方案是使用第三方性能监测工具。PC 端很多人会直接开 Steam 自带的帧率检测，或者用游戏加加、微星小飞机之类；移动端则可以考虑使用开发者工具里的 GPU 渲染配置文件，或者第三方监软件。需要留意的是，部分监测工具本身会占用一定资源，对测试结果存在轻微影响。最好是先在空闲场景里验证一下工具占用，确认它对帧率的影响可以接受后再开始正式记录。
如果你只是想日常判断游戏的流畅程度，其实还有一个更简单的办法：观察游戏里镜头移动是否平滑，再配合系统级帧率显示，把“数值”和“体感”对应起来。但要注意，帧率数字高不代表帧生成时间就稳定，这一点后面会专门讲。
2.2 核心指标：平均帧、1% Low 帧、帧生成时间
很多玩家只看平均帧。比如一局游戏平均 85 帧，看起来不低，但如果实际体验卡顿明显，问题往往出在“最低帧”或“1% Low 帧”上。
- 平均帧：整局游戏的平均帧率，适合大致了解性能水平。
- 1% Low 帧：最差的那 1% 时间的帧率表现，反映卡顿严重程度。
- 帧生成时间：每帧从渲染到显示所花的时间，单位为毫秒，这个指标对“跟手度”的判断尤其重要。
哪怕平均帧很高，如果帧生成时间的曲线经常出现尖峰，比如某段时间每帧要 30 毫秒甚至更多，体感就会是一顿一顿的。这种波动对触控体验的影响，比平均帧降低 10 帧还要明显。
所以在记录数据时，不要只写 “平均 85 帧”，要记录两部分：
- 平均帧率和最低帧率。
- 帧生成时间是否稳定，大体在什么区间波动、有没有明显尖峰。
如果工具能生成曲线图，那就更好，可以直观看到掉帧发生在什么阶段。
2.3 测试场景：固定路线与真实对战分开测
测试游戏场景的选择，决定了你的数据有多大的参考价值。
比较通用的做法，是把测试分成两类：
- 固定路线测试：在游戏里选择一段相对固定的路线，比如跑图、打固定副本、过固定剧情关卡，重复三次。这能保证每次测试的负载基本一致，适合判断设备在不同画质设置下的性能差异。
- 真实对战测试：选择日常游玩最常见的方式，例如竞技模式或多人副本。这类场景负载波动大，更能反映实际体验，但因为每局不太一样，建议至少打三局，并且记录每一局的数据。
如果你要比较“开加速”和“无加速”的差异，操作方法更严格一些：用同一款游戏，选同一段固定路线，在相同画质设置下分别测试，再对比曲线。否则变量不唯一，对比结果没有说服力。
3. 触控延迟测试：三种可落地的方法
触控延迟比帧率难测得多，因为它是从“手指接触屏幕”到“画面发生对应变化”之间的时间差。中间涉及触摸屏采样、系统事件分发、游戏逻辑处理、画面渲染、屏幕刷新等多个环节。任何一个环节变慢，都会体现为触控不跟手。
虽然没有专业仪器，但用常见设备也能得到有参考价值的结论。
3.1 高速摄像法：最直观，但门槛高
如果你有支持 240 帧甚至更高帧率的手机，可以试试高速摄像法。
操作思路很简单：把被测平板放在桌上，屏幕里打开停表应用，然后用手指快速点击屏幕上的某个按钮，同时用另一台手机以高帧率模式录像，最后回放视频，数一下从手接触到屏幕的那一帧，到画面出现对应变化的那一帧，中间隔了多少帧，再换算成毫秒。
这种方法比较直观，但有两个问题：
- 需要另一台支持高帧率录像的设备。
- 手按到屏幕的瞬间，在视频里不一定会拍得很清楚，尤其是接触速度很快的时候。
不过如果你只是想测一个大概范围，比如“是从 60 毫秒变成 120 毫秒的变化，还是从 10 毫秒变成 30 毫秒的变化”，这个方案完全够用。重点是看“相对变化”，不是绝对精度。
3.2 屏幕录制加时间戳：最省设备的方案
没有高速摄像设备时，可以用屏幕录制加时间戳的方法。
把平板开启屏幕录制，在测试中用手指或者导电笔点击屏幕，录一段时间。录制文件里会包含屏幕画面变化的时间序列，再配合外部计时事件做对照。这个方法精度不如高速摄像，但至少能看出某个操作在画面上的响应是否出现在合理时间窗内。
另一种更简单的替代方案，是在游戏中找一个“可重复触发、表现明显”的操作，比如点击某个图标弹出菜单、按攻击键触发特效，然后在多轮测试中记录主观感受到的“迟滞感”。不是特别精确，但至少能暴露明显的异常，比如某次点击后画面延迟了明显一段时间才响应。
3.3 体感加数据：最容易被误解
说实话，很多玩家测试触控延迟，最终是靠体感——也就是“我觉得跟不跟手”。
体感确实能反映问题，但它有两个坑：
- 人很容易被画面流畅度带偏。画面流畅时，即使触控延迟略大，你也会觉得体验不错；画面卡顿时，哪怕触控本身没有变慢，你也会觉得是触控问题。
- 不同人对延迟的感知差异很大，有人对 20 毫秒的变化都很敏感，有人 60 毫秒体感也差别不大。
所以我给出的建议是：体感只能作为辅助判断，不能作为唯一依据。如果你想验证“换了某个设置后触控是不是变好了”，一定要同时记录帧率数据和触控测试数据，用多条证据来印证，而不是只听当下的感觉。
3.4 关注输入链路而不是采样率数字
很多人看到一个设备宣称“触控采样率 240Hz 甚至 300Hz”，会觉得触控延迟一定很低。但采样率高只代表屏幕能高频率获取触点位置，并不代表系统每次都能及时处理并反馈到画面中。如果游戏逻辑被锁在 30 帧，触控采样率再高也没用，因为游戏逻辑更新周期限制了响应频率。
所以触控测试真正要关注的，不是“宣称的采样率”，而是“从触摸到画面变化的整体时间”。采样率是其中一个因素，远不是全部。
4. 帧率与触控延迟的真实关系
到这里可以回到标题最核心的问题：帧率和触控延迟到底是什么关系？
我的结论是：帧率是影响触控延迟的关键因素之一，但绝不是唯一因素；二者相关，但不是简单的正比关系。
4.1 不是帧率越高延迟就越低
理论上，帧率越高，每一帧的时间间隔越短，那么触控事件被游戏逻辑处理的等待时间上限就越低。如果游戏跑 30 帧，一帧是 33.3 毫秒，那么触控事件平均要等约 16.7 毫秒才会被处理；跑到 120 帧，一帧是 8.3 毫秒，平均等待约 4.2 毫秒。所以单看这个部分，帧率越高，触控到逻辑响应的延迟确实越低。
但实际情况要复杂很多。设备在帧率提高时，系统负载也上升，CPU 和 GPU 的处理时间都在增加，事件分发和渲染管线可能产生额外排队。如果系统为了保持帧率强行拉高频，发热增加后还会降频，反而让触控处理线程受到影响。更极端一点，如果某个加速功能插入了额外处理流程，触控事件从产生到画面响应的路径反而更长。
所以你会看到一种奇怪的现象：帧率从 60 提升到 120，触控延迟却没有相应减少，甚至略有增加。这就是为什么只看帧率无法判断触控体验。
4.2 帧生成时间波动比平均帧更影响跟手
对于触控体验来说，帧生成时间的稳定性，比平均帧率更重要。
你可以想象一个场景：一个人以均匀速度走路，你可以在准确的时间点接到他。但如果这个人忽快忽慢，你接到他的时间就变得不可预测。帧生成时间也一样，如果每帧间隔都在 8 毫秒到 30 毫秒之间剧烈波动，那么触控事件被响应的时间也有很大不确定性，体感就是“有时候快有时候慢”。
恰恰是这种“不稳定”，最容易让人觉得设备不跟手。因为人的手指动作和视觉反馈之间需要稳定、可预期的时间间隔，否则大脑就会感觉到迟滞。无加速状态下，如果帧生成时间稳定，即使平均帧率是 50，体感也可能比开了加速但帧生成时间剧烈波动的 90 帧更顺滑。
4.3 垂直同步与缓冲策略的干预
这个环节很多人会忽略，但它对触控延迟的影响很大。
垂直同步会把游戏的输出帧率与屏幕刷新率对齐，消除画面撕裂，但代价是可能引入额外的缓冲延迟。如果设备同时开了垂直同步和多重缓冲，触控事件从产生到画面显示，中间可能会多等一个甚至两个刷新周期。屏幕刷新率越高，这个额外延迟越短，但总归是在原延迟基础上加了一段。
所以如果你在做无加速测试时发现了触控变慢的情况，先检查垂直同步、帧率限制和缓冲相关的设置，再判断是不是设备本身的触控采样有问题。两种原因的处理方式完全不同。
4.4 把数据摊开：稳定曲线、卡顿点、触控错位
在实际测试中，我建议把帧率数据和触控表现放在同一个时间轴上看。
比如边跑游戏边录制屏幕，同时让监测工具记录帧生成时间，然后回放录像。当你在录像里看到某个操作触发不够及时时，去对照同一时间点的帧生成时间。如果帧生成时间恰好有个尖峰，说明原因可能出在渲染侧；如果帧生成时间稳定，但触控反馈仍然显得慢，那就要朝输入链路方面排查。
这个方法不需要特别复杂的设备，只要一款能记录帧生成时间的工具和一部手机录像，就能完成多数场景下的链路定位。
5. Y700 五代实测流程设计
下面给出一套可以直接照搬的实测流程。这套流程不以“测出某个绝对数字”为目的，而是为了回答这样一个问题：这台设备在无加速状态下，帧率表现如何，触控延迟处于什么水平，二者之间有没有明显的不匹配。
5.1 测试前准备：环境与设备状态
先确保设备处于一个可控状态：
- 清掉后台不需要的应用，避免后台进程干扰性能。
- 关闭自动亮度，将屏幕亮度固定在一个常用等级。屏幕亮度会影响功耗和发热，进而影响性能表现。
- 关闭动态刷新率等自适应功能，把刷新率固定为测试目标值。
- 连接稳定的 Wi-Fi，避免网络波动干扰在线游戏的数据记录。
- 将设备充满电或至少保持电量在 80% 以上，避免低电量模式降频。
- 在系统设置中关闭所有“性能增强”“插帧”“超帧”类功能，保持无加速状态。
另外要注意，如果设备刚更新系统或者刚恢复到出厂状态，建议先正常使用一天再测试。系统在刚部署完系统更新后，后台会有索引、优化等任务，测出来的数据并不代表长期表现。
5.2 测试矩阵：画质、刷新率、加速开关
测试不能只跑一个场景，建议做一个小矩阵，至少包含以下对照：
| 测试项 | 无加速 | 开启加速 |
|---|---|---|
| 默认画质 + 标准刷新率 | 记录完整数据 | 记录完整数据 |
| 最高画质 + 高刷新率 | 记录完整数据 | 记录完整数据 |
| 低画质 + 稳定性优先 | 观察帧生成时间变化 | 观察帧生成时间变化 |
如果你要对比“加速对触控的影响”，同一款游戏、同一画质设置下，无加速和开启加速各跑三局，分别记录数据。注意，这里的“加速”指设备或游戏提供的具体功能，不要同时叠加多个加速设置，否则无法定位变量。
5.3 记录模板：帧率、帧时间、触控表现
在测试时，我一般会按下面这个模板记录：
- 游戏名称与版本。
- 画质设置。
- 设备刷新率设置。
- 加速功能是否开启。
- 平均帧率。
- 1% Low 帧率。
- 帧生成时间的大致范围和尖峰情况。
- 触控体感：流畅、轻微迟滞、明显迟滞、偶发不响应。
- 录像对应时间段标记。
数据不要求特别专业，但一定要保持一致性。比如“轻微迟滞”这个判断，要在多局测试中使用同样标准，而不是凭第一局的印象随意变化。
6. 数据解读与排查链路
拿到数据后，你可能会遇到几种情况，每一种都需要不同的分析和处理方式。
6.1 数据异常的判断顺序
如果你发现触控不跟手，但又说不清楚原因，按下面的顺序排查：
- 先看帧生成时间曲线。如果有明显尖峰或整体偏高，优先怀疑是渲染负载太高，先降低画质或开启垂直同步，再看触控体感是否恢复。
- 再看画面是否撕裂。如果存在撕裂，说明输出帧率与屏幕刷新率不匹配，这会影响视觉流畅感，可能被错认为触控问题。
- 再排除系统干扰。检查后台是否运行大量应用，尤其是输入法、壁纸动态效果、后台下载这类容易被忽略的程序。
- 再看系统更新或功能开关。如果最近升级过系统，或者开启了某些防误触功能，可能会影响触控判定。
- 最后才是硬件链路。如果以上都排除后触控仍然不快，再考虑触控采样率、屏幕贴膜、设备发热等物理层面的问题。
6.2 常见误判
这里列举几个在社区讨论里非常常见的误判：
- 误判一：平均帧高等于流畅。实际上，帧生成时间波动大会导致明显的“一顿一顿”，平均帧看不出来。
- 误判二：触控采样率高等于延迟低。采样率只是输入链路的一部分，整体延迟才是关键。
- 误判三：插帧带来更高帧率，所以操作会更跟手。这个在部分场景下成立，但在游戏逻辑帧率较低时会失效。
- 误判四：掉帧多就一定卡。有些掉帧发生在镜头快速转动时，表现为画面模糊或轻微顿挫，但并不一定影响操作精确性。
我在做了很多组对照后，有一个比较深的感受是：对于游戏平板这类设备，触控延迟的稳定程度，往往比峰值的触控响应时间更能决定日常体验。一台设备可能有时响应很快，但有更多情况下响应不稳定；另一台设备绝对响应速度不是最快，但每次都在一个很小的范围内波动。长期玩下来，后者的体验通常更好。
6.3 触控异常排查链路
如果你在实际使用中遇到了“屏幕点按没有反应”或“滑动有拖影”的情况，排查路径建议按以下步骤走：
- 先在系统自带的画图或笔记应用里测试，排除游戏本身的问题。
- 更换手指或触控笔测试，排除手汗、手套、屏幕污渍的影响。
- 撕掉贴膜或更换新贴膜测试，排除贴膜导致的电容变化。
- 关闭“防误触”等系统功能，再跑一次游戏测试。
- 若问题复现，再确认是否与某个系统版本、某个游戏版本或某个画质选项绑定。
- 最后，记录下问题出现的频率、时间段和操作类型，作为申请售后或联系开发团队的参考依据。
这套链路的关键思路是：从最边缘、最容易排除的因素开始，逐步向核心硬件和系统收敛，不要一上来就怀疑是设备屏幕坏了。
7. 其实你不需要追求“极限高帧率”
很多玩家在拿到新设备以后，第一反应是“把画质拉满，把帧率拉满”，然后发现设备又是发热又是掉电，最后还要说一句“这设备不行”。但我的看法是：对于游戏平板这类产品，真正值得追求的并不是极限帧率，而是“能稳定运行的帧率”和“可预期、可接受的触控延迟”。
按我自己的经验，如果一款游戏在无加速状态下能稳定保持帧数 45 到 60，并且帧生成时间没有频繁尖峰，那么开启高刷新率后，画面的顺滑度已经足够大多数游戏场景使用。相比追求 90、120 这样的数字，更重要的是画面始终稳定。因为画面一旦出现周期性卡顿，你的操作节奏会被打乱，那才是对游戏体验最伤的地方。
如果有条件，用前面说的流程做一次 20 分钟的无加速测试：记录三局同一游戏的帧生成时间曲线，同时记录触控体感。做完你就会发现，对这台设备“行不行、跟不跟手”的判断，会比之前准确很多。
最后想提醒一点：帧率也好，触控延迟也好，这些测试的目的是帮你建立对设备真实表现的认知基线，而不是让你陷入参数焦虑。每一档画质有相应的帧率和延迟表现，不代表画质越高体验就越好。找到适合自己游戏的设置平衡点，比一味追求高帧率更现实。
如果你准备测试 Y700 五代，或者任何一台游戏平板，都建议从无加速状态开始测起。先把这条基线数据留在手里，后面无论是调画质、开加速，还是对比新一代设备，都有据可依。
