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

[autoxbc]

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

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

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

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

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

[murmur]

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

[murmur]

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

[maplerecall]

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

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

[learnshare]

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

[autoxbc]

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