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

[autoxbc]

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

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

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

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

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

[yyfearth]

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

[azh7138m]

ls+10086

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

[autoxbc]

@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]

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

[autoxbc]

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

[shuai265]

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

[ileenhow]

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

[leeg810312]

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

[miniwade514]

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

[autoxbc]

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

[autoxbc]

@leeg810312 #8
@miniwade514 #9

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

[leeg810312]

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

[linking]

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

[learnshare]

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

[wohenyingyu01]

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

[autoxbc]

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

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

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

[autoxbc]

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

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

[crysislinux]

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

[skye]

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

[wangxn]

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