Chromium Blog（机翻） Android Chrome页面滚动将更顺滑
原文链接：https://blog.chromium.org/2023/08/smoothing-out-scrolling-experience-in.html?m=1让 Android 版 Chrome 中的滚动体验变顺滑
2023 年 8 月 8 日星期二
通过退后一步并调整您已有的内容，可以取得巨大的性能胜利。今天的“快速与好奇”帖子探讨了我们如何改进 Android 上 Chrome 的滚动体验，最终将缓慢滚动卡顿现象减少 2 倍。请继续阅读，了解我们如何发现和评估该问题，以及这如何帮助我们设计未来更好的浏览器体验。
在衡量浏览器的性能时，人们通常会想到页面加载速度或WebVitals。在触摸交互很常见的移动设备上，我们还会优先考虑您与 Chrome 的交互，以确保它始终流畅且响应灵敏，包括可折叠等新的外形尺寸。最近的一个重要焦点是减少滚动时的卡顿。
最近，我们通过过滤噪音和减少屏幕上呈现的内容的视觉跳跃，将 Android 上 Chrome 的滚动体验提高了 2 倍。为了得到这个结果，我们必须退后一步，弄清楚为什么 Android 上的 Chrome 落后于 iOS 上的 Chrome 的问题。
当我们跨平台比较 Chrome 时，我们得到了一个特殊的观察结果。iOS Chrome 的滚动流畅且一致，而在 Android 上，Chrome 的滚动并没有那么紧密地跟随您的手指。然而，我们的指标告诉我们，虽然偶尔会发生卡顿，但与 iOS 上的 Chrome 相比，它们并不像我们想象的那么常见。因此，我们自己有一个需要调查的谜团。
研究输入输出率
我们的指标表明我们经常以不一致的速度接收输入；但由于输入速率大于显示器的帧速率，因此我们通常至少有一个输入事件来触发生成要显示的帧。但是，该帧可能消耗了更少或更多的输入事件，这可能会导致屏幕上的内容移动不一致，即使以固定速度滚动也是如此。
输入速率与帧速率不同的问题是 Chrome 之前必须解决的问题。在内部，我们对输入进行重新采样，以预测/推断手指相对于我们想要生成的帧处于一致点的位置。这应该导致每个帧代表一致的时间量，并且应该意味着平滑滚动，而不管输入事件中的噪音如何。下图说明了理想的场景，其中蓝点是真实输入事件，绿色是重新采样的输入事件，如果您要使用真实输入事件而不是重新采样，则显示的滚动增量将会波动。
好的，我们已经进行了重采样，那么问题出在哪里呢？
一个悲伤和重新实施的故事
随着 90hz 设备的出现，Chrome（和 Android）内部的输入重采样功能于 2019 年被添加，上述问题变得更加明显（每帧在 2 与 1 个输入事件之间振荡，而不是我们通常在 60hz 设备上看到的每帧始终有 2 个输入事件） 。Android 实现了多种重采样算法（卡尔曼、线性等），并得出结论：线性重采样（在两点之间画一条线来计算速度，然后外推到给定的时间戳）足以满足其用例。这解决了大多数 Android 应用程序的问题，但没有解决 Chrome 的问题。
由于历史原因和网络规范对原始输入的要求，Chrome 使用无缓冲输入，因此随着设备开始出现采样率与输入不匹配的情况，Chrome 必须实现某种版本的重采样。下面我们看到，如果我们假设输入始终到达并且每个都是 30 像素的位移，那么理想情况下我们应该将其平滑到每帧 60 像素，如下所示：
然而，当我们调查最初的谜团时，我们发现现实与上图所示的理想情况有很大不同。我们发现屏幕的实际输入移动非常尖锐且不一致（超出我们的预期），并且我们的预测器正在改进一些东西，但没有达到预期的程度。左边是屏幕上真实的手指位移（每个点都是一个输入事件），右边是平滑后实际内容偏移预测器的结果（每个点是一帧）
帧在右侧一致地呈现，但帧与帧之间的位移峰值速率并不一致（-50 到 -40，然后是另一个 -52，尤其剧烈）。人类的手指不会如此离散地移动（以帧级精度）。相反，它们应该以梯度方式滑动和弯曲，逐渐加速或减速。所以我们知道我们这里有问题。我们深入研究了 Chrome 的实现，发现 Chrome 的实现（据说是 Android 的副本）存在一些根本性的差异。
1. Android 使用原生 C++ MotionEvent 时间戳（纳秒精度），但 Chrome 使用 Java MotionEvent.getEventTime和MotionEvent.getHistoricalEventTime（毫秒精度）。不幸的是，纳秒精度并不是公共 API 的一部分。然而，在计算事件时间戳之间的速度时，毫秒的舍入可能会给我们的预测器带来误差。
2. Android 的实现在选择两个输入事件时会非常小心，因此重采样会使用最相关的事件。然而，Chrome 使用简单的 FIFO 输入事件队列，这可能会导致在高刷新率设备上极少数情况下使用未来事件来预测过去速度的奇怪情况。
我们在 Chrome 中使用 Android 的重采样进行原型设计，但发现它对于 Chrome 的架构来说仍然不完美，导致一些卡顿。为了改进它，我们尝试了不同的算法，使用自动化一遍又一遍地重放相同的输入并评估屏幕位移曲线。经过调整后，它实现了1 欧元的过滤器实现，明显且极大地改善了滚动体验。使用此过滤器，屏幕可以紧密跟踪您的手指，并且网站可以平滑滚动，从而防止因输入事件不一致而导致卡顿。在我们的手动验证中，在高端和低端设备上都可以看到这种改进（这是 Redmi 9A 视频示例）。
向前走！
在 Android 14 中， java MotionEvents 的纳秒API将在 SDK 中公开，以便 Chrome（以及其他具有无缓冲输入的应用程序）能够调用它。我们还开发了跟踪滚动预测器帧质量的新指标，方法是创建一个测试应用程序，引入帧之间的像素级差异（并且没有其他形式的卡顿）并运行实验以查看人们会注意到什么。这些分析可以在此处阅读，并将用于未来获得更令人兴奋的性能胜利，并使之成为跟踪回归的可见区域。最后，在调整并启用1 欧元过滤器后，我们的指标显示缓慢滚动时可见卡顿减少了 2 倍！此改进即将生效 M116为默认值，但将一直推出到 M110，并使 Android 上的 Chrome 与 iOS 上的 Chrome 处于同等地位！
这个故事的寓意是：有时指标并不能涵盖所有情况，退一步并自上而下进行调查并了解情况可以为用户带来卓越的滚动体验。
—— 来自 S1Fun 试了下金丝雀版本流畅度在老手机上的确有明显提升，一加11上不明显。但是新版本滚动体验还是不如via。
—— 来自 S1Fun 但是 Via 不也用的是 Chromium，要比也是 Firefox android14才能用到吗
—— 来自 vivo V1981A, Android 12上的 S1Next-鹅版 v2.5.2-play JetBrains 发表于 2023-8-11 22:19
但是 Via 不也用的是 Chromium，要比也是 Firefox
Via调用的是WebView，内核没问题，不然其他调用WebView的软件也炸了，如果WebView debug工具的话可以看还是很多可以调的，行为和Chrome不一样也很正常。博文也说Chrome滚动不流畅也是历史遗留问题。
—— 来自 S1Fun 本帖最后由 noahhhh 于 2023-8-12 06:59 编辑
天气姐姐 发表于 2023-8-11 23:43
android14才能用到吗
—— 来自 vivo V1981A, Android 12上的 S1Next-鹅版 v2.5.2-play
等116更新，直接下beta也行，不知道iOS更新了116，Android还在115是不是这个原因。Android 14新API让开发更简单，可能会有点微小的提升
—— 来自 S1Fun noahhhh 发表于 2023-8-12 02:51
Via调用的是WebView，内核没问题，不然其他调用WebView的软件也炸了，如果WebView debug工具的话可以看还 ...
Webview 不就是 Chromium 已推送116.0.5845.92，Pixel 4上滑动确实流畅不少
—— 来自 S1Fun 借楼请教一个 Windows 下的 Chrome 近期 GPU 进程高占用问题（冲浪一会后就跑到 800m 往上，居高不下不再回收内存），可能（并不确定是否是直接原因）导致了网页内的异步请求响应重渲染页面的过程非常之慢（并不是网络原因，相同网络环境下横向比对至少有五六倍的差距，这个是我最无法忍受的）。
目前猜测的几个可能原因（尝试禁用其实也没有感到多大改善）：
- Zotero 扩展：会完整抓取网页 HTML 内容保存。
- Eagle 扩展：抓取网页图片保存，经常刷推用来存图，感觉就连推特网页都经常崩掉回退到上次导航。
- Squoosh 网页应用：非常常用用来压缩图片，核心代码是编译成 WASM 的，体感最有可能出问题的就是它。
Chrome 版本号 116，基本就是有更新就更，实在没有办法我就改用 Vivaldi 了。 Junakr 发表于 2023-8-22 00:32
借楼请教一个 Windows 下的 Chrome 近期 GPU 进程高占用问题（冲浪一会后就跑到 800m 往上，居高不下不再回 ...
shift+esc 看占用，开个无痕模式对照 Linux 上 chromium 的 vaapi 又双叒叕寄了（不过 aur 里给的 116 experimental 的预编译的包还是可以用的）
摘一个 arch 论坛老哥的话语
they wrote "we have fully transitioned to the new VD video decoder path."
They are fully transitioned to a heavy buggy decoder...
it's unbelievable, i've been using hardware acceleration with vaapi for more than a decade without any problems with gstreamer and mpv, but all the power of google is unable to write a decent decoder.
Junakr 发表于 2023-8-22 00:32
借楼请教一个 Windows 下的 Chrome 近期 GPU 进程高占用问题（冲浪一会后就跑到 800m 往上，居高不下不再回 ...
简单破个案吧，大概是某次移动机箱把内存条弄松了，重新插拔了一次后没注意到 XMP 失效了，就这么用了大半个月的 2133mhz，回到 3600mhz 的瞬间终于感觉一切都回来了。 PC版CHROME最近滚动的时候会出现花屏是不是这次更新干的好事？
页:
[1]