[064]微信越滑越卡（补充篇）
前言
发了[063]微信越滑越卡这个文章以后，有好多小伙伴私信我，为什么他们项目上没有出现这个问题？是否有必要集成我这个修复方案？我就来继续分析补充一下。
一、1加8T为什么并没有出现这个BUG
我再1加8T上抓了一个trace，来分析一下为什么1加8T为什么并没有出现这个BUG，而且这个手机是120hz的屏幕。
通过Trace可以发现：
1.第一个Move之前remove了所有的callback。
2.Up发生的时候，又会重新post一个callback，符合代码的逻辑。
二、为什么第一个Move之前remove了所有的callback
还记得[063]微信越滑越卡中介绍的down事件发生会postdelay一个mCheckFlywheel，delay的时间正好是40ms。
通过Trace可以发现：
1.Down和第一个Move的时间间隔是大于40ms，虽然这个手机的触控采样率大于180hz
2.因为1的条件满足，mCheckFlywheel被有效的执行了，所以第一个Move之前remove了所有的callback。
三、什么样的设备下可以复现这个问题
Down和第一个Move的时间间隔永远小于40ms
这个永远很重要，因为一旦在持续的滑动中，有一次大于40ms，就会remove了所有的callback。
四、是否需要打这个Fix Patch
1.这个Patch是没有副作用的，因为假如在1加8T上打了这个patch，只不过在Up事件发生的时候，remove callback，本来就是空的，空的情况下清理一下也没事。
2.如果你的设备Down和第一个Move的时间间隔是永远小于40ms，我建议你打这个Patch，不需要等到Android的官方释放。
总结
我觉得大家不要过分的纠结要不要打patch，大家可以按照我这个分析。
在你们项目上在微信中持续滑动一个很长的列表，抓一个trace看看，试着像我一样的分析，在考虑一下要不要打patch。
本文中Trace都是自带的trace，不是我额外添加的trace。
尾巴
图中的trace是用perfetto抓的，perfetto的教程大家可以参考一下。
腾讯云开发者
