你好 
自 UX: improve touch, swipe, panning performance on mobile menus by featheredtoast · Pull Request #23775 · discourse/discourse · GitHub 更新以来，在较旧的移动 Android 设备上，菜单面板（用户和侧边栏）的移动感觉比以前慢了很多。这可能是因为这些设备的 CPU 性能不足以使其平滑移动。
在我的设备 Huawei P20 Pro 上。
不过，我在 iPhone X上也进行了测试，它非常流畅和快速，所以我认为 CPU 是问题所在。有没有办法在旧设备上提高性能？
谢谢 
谢谢 @Don，我们会看看！
嘿 Don，感谢你的反馈！
我会尽快进行测试；我怀疑旧设备可能仍然需要（略显笨拙的）性能优化，将菜单中的项目数量减少到 20 个才能感觉流畅——我会尽快研究这个问题。
@Don - 进一步研究以了解要测试的内容，您是否注意到这是通过点击（在菜单上/菜单外）或滑动（按住并滑动）来打开/关闭菜单？
菜单首次打开时似乎很流畅。我认为这是因为面板元素尚未加载。当我第一次打开时，顶部会出现加载动画。我认为这是一个很好的行为，也许以后一直使用加载动画会很酷。
此后的打开没有动画。关闭是随机的（有时流畅，有时卡顿）
打开后我点击外面，菜单按钮通常会卡顿。但那些是先滑出的🤔也许这是因为整个菜单面板是 reverse-row，当它关闭时，类在完全滑出并改回 row 之前被移除？
编辑：那不是菜单面板按钮（标签），只是通知之前的图标。但通常在那条线上会出现卡顿。
当我使用手势关闭菜单时，它似乎很流畅。
更新：在 Firefox 浏览器中，菜单移动似乎很流畅。我在 Edge 浏览器上也进行了测试，结果与 Chrome 相同。
Firefox
据我所知，“卡顿”是由于标题重新渲染造成的，而不是动画本身。
我引入的一个可能导致新卡顿感知的东西是滑出动画（在我们重构新标题时，此动画被无意中删除了）。
在动画和挂件菜单正在进行的重新渲染工作之间设置一些 setTimeout 延迟，似乎能让事情运行得更顺畅，所以不是动画本身慢，我怀疑是打开/关闭时重新渲染网站标题周围的工作。
我实际上在想 Firefox 对动画结束承诺的处理是否在动画真正绘制之后才触发（我在编写原始更改时就假设是这种情况），这或许可以解释为什么它看起来比 Chrome 更流畅，而 Chrome 允许在动画计算完成后、但在动画结束绘制之前开始重新计算工作。
编辑：我正在使用我们的 runloop 添加一个暂停，以便在动画之前添加必要的延迟，这应该会让动画感觉更流畅：UX: call discourseLater on menu animations by featheredtoast · Pull Request #24168 · discourse/discourse · GitHub
太感谢你了！抓得好！