为何 iOS 的 scroll 阻塞 dom 机制没被大规模借鉴？

• 请不要在回答技术问题时复制粘贴 AI 生成的内容

This topic created in 3235 days ago, the information mentioned may be changed or developed.

简单的说是这样：
iOS 的 webview 内核设定了其在进行 momentum scrolling(弹性滚动)时，会停止所有的事件响应及 DOM 操作引起的页面渲染。

这个机制决定了无论你在 onscroll 里放多少个复杂回调，也丝毫不会影响 iOS 的浏览体验。

有些人还把这个特性当成 bug，找各种方法绕过，实在是不理解 iOS 的良苦用心。
https://segmentfault.com/q/1010000004453730

我自己写的脚本，全部的事件回调，都模拟这种机制，完全不考虑节流的情况下，一样有很好的性能。

回到题目，某天得到一部中等配置的 android 机，下了个 uc，一滚动把我吓傻了，卡成幻灯片了。

iOS

DOM

回调

滚动

25 replies • 2017-08-03 15:27:24 +08:00

yyfearth

Aug 2, 2017

开发者不会喜欢这个机制的因为这个不是可控的
因为这么做就没办法实现视差滚动 (Parallax Scrolling) 了
而且也有很多需要 scroll event 调整页面的效果也没办法实现了
也没法模拟实现 position sticky 或 fixed
相比之下 Google 推的 passive event listener 的机制就好很多

azh7138m

Aug 2, 2017

ls+10086

[使用_passive_改善的滚屏性能]( https://developer.mozilla.org/zh-CN/docs/Web/API/EventTarget/addEventListener#使用_passive_改善的滚屏性能)

autoxbc

Aug 2, 2017

@yyfearth #1 感谢您提供 passive 的参考。我大概看了一下，说的不是同一个事情。

passive 的背景是：对于一个 cancelable: true 的 UI Event，因为可能存在 preventDefault，所以浏览器会等待回调执行完毕，确定是否存在 preventDefault，再决定是否触发 UI Rendering。

passive 允许开发者提前声明是否 preventDefault，来压缩 touchstart 到 UI Rendering 的等待时间。

但是 scroll 是 cancelable: false 的 UI Event，不能从 passive 得到任何好处。

iOS 的阻塞机制，是 UI Rendering 之后的流程，指的是一个页面一旦开始 scrolling，UI 和 Event Stream 被冻结，scrollend 后解冻，这是彻底解决 UI 卡顿的机制。

coolzjy

Aug 2, 2017

@autoxbc
需要关注的不是 scrollevent，而是 touchevent，这才是影响性能的元凶。

autoxbc

Aug 2, 2017

@coolzjy #4 不懂您的意思，touch 卡就卡一点，scroll 卡会卡一串，谁是大头

shuai265

Aug 2, 2017

像 1L 说的，特殊情况下可能会出现不可控的情况吧。类似的 tableviewCell 的复用机制，有时候也会出现无法控制的情形。

ileenhow

Aug 2, 2017

想了解一下，怎样模拟 iOS 的这种机制

leeg810312

Aug 2, 2017 via Android

在我看这正是 Apple 软件开发实力不强的典型例子，Apple 强于软硬件整合、用户体验，为了一点点用户体验，直接用一刀切的阻塞方法解决事件响应和页面渲染性能问题，以至于如 1 楼说的很多操作不能开发，怎么能说是良苦用心？如标题说阻塞机制没有大规模借鉴，恰好证明了这个问题所在。要说即使现在的 2000 元 Android 机，浏览器性能也一点不差，只要你别用国产的那些“广告”浏览器。

miniwade514

Aug 2, 2017

这个机制是对性能问题的妥协，是一种取舍，并不是什么进步，所以我不认为这种机制会被推广。

autoxbc

Aug 2, 2017

@ileenhow #7 我又查了一下，就是常说的去抖 debounce。记录事件的时间戳，和上一次的比较，低于阈值(还在滚动中)延迟回调，高于阈值(滚动完毕)执行回调。

autoxbc

Aug 2, 2017

@leeg810312 #8
@miniwade514 #9

Apple 上一次为了一点点用户体验，做了一个取舍，一刀切了 Flash。是不是进步不知道，android 很快学去了。

leeg810312

Aug 2, 2017 via Android

@autoxbc Flash 不是 Apple 开发的，apple 能做什么，ios 的浏览器内核是它自己做的都做不好，能相提并论？这逻辑真搞笑。

linking

Aug 2, 2017

开发中需要实时监听滚动的交互也不少啊，比如导航菜单的高亮，元素浮现的动画；如果说这是个好的机制，为什么在更先进的 WKWebView 中又去掉了这个机制呢？

learnshare

Aug 2, 2017

Fixed 的元素会随着滚动飘走，目前只见过这一个不太合理的地方
对性能的优化不能以牺牲功能为代价

wohenyingyu01

Aug 2, 2017

@shuai265 tableviewcell 和这个有关系么 = =

autoxbc

Aug 2, 2017

@linking #13 我觉得把讨论的议题换成，在浏览器中，给 UI 线程高优先级，并允许其钳制 JS 线程的资源使用，那么投赞成票的应该会多一点。UIWebView 的处理方法显现了一点雏形。

感谢您提供 WKWebView 取消类似机制的信息。不知道取消后，有没有相关的机制优化体验，还是全凭 Web 开发者的自觉。

可能我更多的从用户的角度写代码，当我看到那些优化的很差的页面，也没有办法从系统层面给他去抖时，心情是很沮丧的，我希望浏览器给我选择的余地。

autoxbc

Aug 2, 2017

@learnshare #14 可不可以用 css 实现。

前端界好像有个倾向，用 js 代替一切。内容用 js 生成，排版用 js 控制，这个有点跑偏。

crysislinux

Aug 2, 2017

@autoxbc 然而这并不是同一个问题，样式有些用了 js，那是因为单纯 css 没办法实现或者有些问题需要取舍，估计没几个人真喜欢 js 写 css，写起来也挺不方便的。。

skye

Aug 3, 2017

这么个问题居然还能吵起来。。。lz 明明很友善的讨论问题。

wangxn

Aug 3, 2017 via Android

凡是捧一样东西、踩一样东西都会引起论战，尤其是在自己不熟悉的情况下。

murmur

Aug 3, 2017

scroll ？我只知道 ios 如果不在 div 上加个 translate 000 一滚动的时候就呼啦一大片空白这绝对是巨大的 bug
ios 实际上兼容问题比 android 还恶心，国产的 android4.4 都调教的服服帖帖，几个前缀 postcss 也搞定
反观 ios

murmur

Aug 3, 2017

@leeg810312 apple 为了利益竞争砍掉了 flash，商业目的没必要扯太多技术，你看现在 apple 在 h5 上优化的很好么
以前 adobe 没做好至少别人做了，现在 safari 那坨东西比 chrome 恶心太多

maplerecall

Aug 3, 2017 via Android

@murmur 对对，很明显感觉 safari 最近的发展越来越奇怪了，各种诡异的兼容性问题越来越多…而且现在 iOS 上的 webview 在后台较多的情况下有也会出现严重的渲染性能问题，比如 transition 直接失效…

另外 scrollevent 这个的确导致了一些设计的想法不得不放弃或者被迫使用模拟滚动这种低效的方法解决…

learnshare

Aug 3, 2017

@autoxbc fixed 是 CSS 实现的，没有详细测试过，不知道是不是个例

autoxbc

Aug 3, 2017

@learnshare #24 刚测了一下，iOS 版 UC 使用 UIWebView，是 scroll 阻塞 dom 的实现，position:fixed 不会飘走。