#22 楼 @addison 549149857

#20 楼 @r551 不能完全区分开来，是会互相影响的，要结合场景，观察某个时间区间内 FPS 值的变化

#14 楼 @sandman 我明白你的意思了，你是说如果在一段时间内，某一帧相对其他帧渲染时间有明显的增加，这种 “单帧突出” 的问题会更影响流畅性，即突出的差异比普遍的稳定更能被用户感知

我和你的想法吻合，觉得不能以掉帧数来计算，所以我的计算方法是：如果某一帧超时了，先计算它到底占用了多少个脉冲，不是仅仅 +1（这个 1 代表掉帧数），比如占用了 10 个，其实应该 +10（这个 10 代表脉冲数）。我最后算的不是掉帧数，而是计算 （在一段时间内已渲染的帧数 / 这段时间内应该渲染的帧数）这个比例（其实就等于 1 - 丢帧比例），然后用这个比例去乘以 60。

这种方法，我认为 “不以掉帧数来计算” 这个方向是对的，但依然有问题，比如 128 帧中有 127 帧都正常，只有 1 帧超时，它用掉了额外的 10 个脉冲，这时我的方法计算出来的 FPS 应为 ： 128 /（128 + 10）* 60 = 56，这个值也算很高了，这个结果很容易让人以为它是正常的，从而忽略掉了那个 “单帧突出” 的问题。到这里我也明白了 @vigossjjj 说的 “FPS 的的高低和界面卡顿并不是成正比” 了

多谢二位 @sandman @vigossjjj

更科学的计算方法应该是时刻检测在某些区间内的丢帧比例以及最大单帧渲染时间，去发现 “突出” 的问题，但这个怎么应用到代码中，我还需要再研究一下

#12 楼 @sziitash 39~41 这么精确的值？还是你的意思是稳定的低 fps 比跳跃的高 fps，页面效果更好？

#10 楼 @unbug https://github.com/ymsheng/MNFrameRate

#6 楼 @vigossjjj 恩，好的，我会再去试试

#2 楼 @vigossjjj 所以我最后采用的是 m /（m + 额外的垂直同步脉冲）* 60， 这种方法其实就是（1-jankness）* 60 的换算

#2 楼 @vigossjjj 我觉得 FPS 的高低和界面是否卡顿就是成正比的，只不过 Android 系统 60 的 FPS 标准是比较高的，而人眼只要 FPS 大于等于 30 就基本分辨不出是一帧帧图片还是连续的动画了。jank 数量确实不能反映 FPS，因为一次 jank 可能延搁的 vsync 数不一定，但 jankness 还是比较有说服力的

#1 楼 @sandman 请问一下，你说的同一帧先后间隔被用两次，是它的 vsync 时间戳一样，但出现过两次吗？这种情况我还真没碰见过

#10 楼 @lose 你是要解决啥？

#8 楼 @zsx10110 你好，这一篇主要不是讲解那个库的使用方法，如果想了解可以见 https://testerhome.com/topics/2232（虽然这篇已经比较久远啦。。），那个库还是有点冗长的，而且代码上有变更，你自己理解它的意思之后，得根据需要做改动，我之后会再贴一篇我现在使用的方法

#37 楼 @quqing 你好楼主，有几个关于 FPS 的问题：
1.执行一次命令会得到最近 128 帧的渲染情况，怎么决定采样间隔？比如 1 秒后再次执行命令，可能只有 30 帧是新的（在输出的底部），其他 98 帧都是旧数据，那这种情况怎么处理？又如果间隔太大，那中间其实已经过去很多帧，FPS 统计本来是一个连贯的过程，那这样的数据还有意义吗？
2.最后面那张报表，我看帧数已经超过了 128，如果报表是静态的（数据全在一个 list 里，只画一次图，那么还是问题 1），如果报表是动态的，要怎么实现？

脚本赞

为什么

如果时间间隔差出现大于刷新周期的情况的话，就是一次 jank，加起来就是 jank_count

按照 Android VSync 机制，既然中间一列代表该帧开始加载时垂直脉冲到来的时间，应该只要【每 2 帧之间的时间间隔】大于 refresh_period 就代表有 jank 啊，为什么还要调用_GetNormalizedDeltas 函数，用【每 2 帧之间的时间间隔差】来计算，这个值有什么意义？

学习了

#4 楼 @neyo 比较直白。。

#2 楼 @seveniruby 哈哈，听起来就很支付

下面这个屏蔽用户的示例看得我怕怕的

#7 楼 @runaway_girl UI 呈现（二）里有更详细的说明

#1 楼 @sunhao 多谢浩哥

已报名！！期待！