这是一个创建于 2670 天前的主题，其中的信息可能已经有所发展或是发生改变。
简单的说是这样：
iOS 的 webview 内核设定了其在进行 momentum scrolling(弹性滚动)时，会停止所有的事件响应及 DOM 操作引起的页面渲染。
这个机制决定了无论你在 onscroll 里放多少个复杂回调，也丝毫不会影响 iOS 的浏览体验。
有些人还把这个特性当成 bug，找各种方法绕过，实在是不理解 iOS 的良苦用心。
https://segmentfault.com/q/1010000004453730
我自己写的脚本，全部的事件回调，都模拟这种机制，完全不考虑节流的情况下，一样有很好的性能。
回到题目，某天得到一部中等配置的 android 机，下了个 uc，一滚动把我吓傻了，卡成幻灯片了。
iOS 的 webview 内核设定了其在进行 momentum scrolling(弹性滚动)时，会停止所有的事件响应及 DOM 操作引起的页面渲染。
这个机制决定了无论你在 onscroll 里放多少个复杂回调，也丝毫不会影响 iOS 的浏览体验。
有些人还把这个特性当成 bug，找各种方法绕过，实在是不理解 iOS 的良苦用心。
https://segmentfault.com/q/1010000004453730
我自己写的脚本，全部的事件回调，都模拟这种机制，完全不考虑节流的情况下，一样有很好的性能。
回到题目，某天得到一部中等配置的 android 机，下了个 uc，一滚动把我吓傻了，卡成幻灯片了。
 |
1
yyfearth 2017-08-02 18:27:46 +08:00  3
开发者不会喜欢这个机制的 因为这个不是可控的
因为这么做就没办法实现 视差滚动 (Parallax Scrolling) 了 而且也有很多需要 scroll event 调整页面的效果也没办法实现了 也没法模拟实现 position sticky 或 fixed 相比之下 Google 推的 passive event listener 的机制就好很多 |
 |
2
azh7138m 2017-08-02 18:42:10 +08:00 1
ls+10086
[使用_passive_改善的滚屏性能]( https://developer.mozilla.org/zh-CN/docs/Web/API/EventTarget/addEventListener#使用_passive_改善的滚屏性能) |
 |
3
autoxbc OP @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 卡顿的机制。 |
 |
6
shuai265 2017-08-02 20:30:44 +08:00
像 1L 说的，特殊情况下可能会出现不可控的情况吧。类似的 tableviewCell 的复用机制，有时候也会出现无法控制的情形。
|
 |
7
ileenhow 2017-08-02 20:55:24 +08:00
想了解一下，怎样模拟 iOS 的这种机制
|
 |
8
leeg810312 2017-08-02 21:09:48 +08:00 via Android
在我看这正是 Apple 软件开发实力不强的典型例子，Apple 强于软硬件整合、用户体验，为了一点点用户体验，直接用一刀切的阻塞方法解决事件响应和页面渲染性能问题，以至于如 1 楼说的很多操作不能开发，怎么能说是良苦用心？如标题说阻塞机制没有大规模借鉴，恰好证明了这个问题所在。要说即使现在的 2000 元 Android 机，浏览器性能也一点不差，只要你别用国产的那些“广告”浏览器。
|
 |
9
miniwade514 2017-08-02 21:11:28 +08:00
这个机制是对性能问题的妥协，是一种取舍，并不是什么进步，所以我不认为这种机制会被推广。
|
|
10
autoxbc OP @ileenhow #7 我又查了一下，就是常说的去抖 debounce。记录事件的时间戳，和上一次的比较，低于阈值(还在滚动中)延迟回调，高于阈值(滚动完毕)执行回调。
|
|
11
autoxbc OP |
|
12
leeg810312 2017-08-02 22:01:27 +08:00 via Android 1
@autoxbc Flash 不是 Apple 开发的，apple 能做什么，ios 的浏览器内核是它自己做的都做不好，能相提并论？这逻辑真搞笑。
|
 |
13
linking 2017-08-02 22:12:22 +08:00
开发中需要实时监听滚动的交互也不少啊，比如导航菜单的高亮，元素浮现的动画；如果说这是个好的机制，为什么在更先进的 WKWebView 中又去掉了这个机制呢？
|
 |
14
learnshare 2017-08-02 22:45:51 +08:00
Fixed 的元素会随着滚动飘走，目前只见过这一个不太合理的地方
对性能的优化不能以牺牲功能为代价 |
 |
15
wohenyingyu01 2017-08-02 22:51:16 +08:00
@shuai265 tableviewcell 和这个有关系么 = =
|
|
16
autoxbc OP @linking #13 我觉得把讨论的议题换成，在浏览器中，给 UI 线程高优先级，并允许其钳制 JS 线程的资源使用，那么投赞成票的应该会多一点。UIWebView 的处理方法显现了一点雏形。
感谢您提供 WKWebView 取消类似机制的信息。不知道取消后，有没有相关的机制优化体验，还是全凭 Web 开发者的自觉。 可能我更多的从用户的角度写代码，当我看到那些优化的很差的页面，也没有办法从系统层面给他去抖时，心情是很沮丧的，我希望浏览器给我选择的余地。 |
|
17
autoxbc OP |
 |
18
crysislinux 2017-08-02 23:14:33 +08:00
@autoxbc 然而这并不是同一个问题，样式有些用了 js，那是因为单纯 css 没办法实现或者有些问题需要取舍，估计没几个人真喜欢 js 写 css，写起来也挺不方便的。。
|
 |
19
skye 2017-08-03 03:26:08 +08:00 1
这么个问题居然还能吵起来。。。lz 明明很友善的讨论问题。
|
 |
20
wangxn 2017-08-03 07:44:00 +08:00 via Android
凡是捧一样东西、踩一样东西都会引起论战，尤其是在自己不熟悉的情况下。
|
 |
21
murmur 2017-08-03 08:13:41 +08:00
scroll ？我只知道 ios 如果不在 div 上加个 translate 000 一滚动的时候就呼啦一大片空白 这绝对是巨大的 bug
ios 实际上兼容问题比 android 还恶心，国产的 android4.4 都调教的服服帖帖，几个前缀 postcss 也搞定 反观 ios |
|
22
murmur 2017-08-03 08:32:56 +08:00
@leeg810312 apple 为了利益竞争砍掉了 flash，商业目的没必要扯太多技术，你看现在 apple 在 h5 上优化的很好么
以前 adobe 没做好至少别人做了，现在 safari 那坨东西比 chrome 恶心太多 |
 |
23
maplerecall 2017-08-03 10:11:49 +08:00 via Android
@murmur 对对，很明显感觉 safari 最近的发展越来越奇怪了，各种诡异的兼容性问题越来越多…而且现在 iOS 上的 webview 在后台较多的情况下有也会出现严重的渲染性能问题，比如 transition 直接失效…
另外 scrollevent 这个的确导致了一些设计的想法不得不放弃或者被迫使用模拟滚动这种低效的方法解决… |
|
24
learnshare 2017-08-03 14:54:44 +08:00
@autoxbc fixed 是 CSS 实现的，没有详细测试过，不知道是不是个例
|
|
25
autoxbc OP @learnshare #24 刚测了一下，iOS 版 UC 使用 UIWebView，是 scroll 阻塞 dom 的实现，position:fixed 不会飘走。
|
Select Language