V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
autoxbc
V2EX  ›  程序员

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

  •  
  •   autoxbc · 2017-08-02 18:06:49 +08:00 · 6484 次点击
    这是一个创建于 2654 天前的主题,其中的信息可能已经有所发展或是发生改变。
    简单的说是这样:
    iOS 的 webview 内核设定了其在进行 momentum scrolling(弹性滚动)时,会停止所有的事件响应及 DOM 操作引起的页面渲染。

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

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

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

    回到题目,某天得到一部中等配置的 android 机,下了个 uc,一滚动把我吓傻了,卡成幻灯片了。
    25 条回复    2017-08-03 15:27:24 +08:00
    yyfearth
        1
    yyfearth  
       2017-08-02 18:27:46 +08:00   ❤️ 3
    开发者不会喜欢这个机制的 因为这个不是可控的
    因为这么做就没办法实现 视差滚动 (Parallax Scrolling) 了
    而且也有很多需要 scroll event 调整页面的效果也没办法实现了
    也没法模拟实现 position sticky 或 fixed
    相比之下 Google 推的 passive event listener 的机制就好很多
    azh7138m
        2
    azh7138m  
       2017-08-02 18:42:10 +08:00   ❤️ 1
    autoxbc
        3
    autoxbc  
    OP
       2017-08-02 19:31:02 +08:00
    @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
        4
    coolzjy  
       2017-08-02 19:39:18 +08:00
    @autoxbc
    需要关注的不是 scrollevent,而是 touchevent,这才是影响性能的元凶。
    autoxbc
        5
    autoxbc  
    OP
       2017-08-02 19:43:31 +08:00
    @coolzjy #4 不懂您的意思,touch 卡就卡一点,scroll 卡会卡一串,谁是大头
    shuai265
        6
    shuai265  
       2017-08-02 20:30:44 +08:00
    像 1L 说的,特殊情况下可能会出现不可控的情况吧。类似的 tableviewCell 的复用机制,有时候也会出现无法控制的情形。
    ileenhow
        7
    ileenhow  
       2017-08-02 20:55:24 +08:00
    想了解一下,怎样模拟 iOS 的这种机制
    leeg810312
        8
    leeg810312  
       2017-08-02 21:09:48 +08:00 via Android
    在我看这正是 Apple 软件开发实力不强的典型例子,Apple 强于软硬件整合、用户体验,为了一点点用户体验,直接用一刀切的阻塞方法解决事件响应和页面渲染性能问题,以至于如 1 楼说的很多操作不能开发,怎么能说是良苦用心?如标题说阻塞机制没有大规模借鉴,恰好证明了这个问题所在。要说即使现在的 2000 元 Android 机,浏览器性能也一点不差,只要你别用国产的那些“广告”浏览器。
    miniwade514
        9
    miniwade514  
       2017-08-02 21:11:28 +08:00
    这个机制是对性能问题的妥协,是一种取舍,并不是什么进步,所以我不认为这种机制会被推广。
    autoxbc
        10
    autoxbc  
    OP
       2017-08-02 21:34:02 +08:00
    @ileenhow #7 我又查了一下,就是常说的去抖 debounce。记录事件的时间戳,和上一次的比较,低于阈值(还在滚动中)延迟回调,高于阈值(滚动完毕)执行回调。
    autoxbc
        11
    autoxbc  
    OP
       2017-08-02 21:52:59 +08:00
    @leeg810312 #8
    @miniwade514 #9

    Apple 上一次为了一点点用户体验,做了一个取舍,一刀切了 Flash。是不是进步不知道,android 很快学去了。
    leeg810312
        12
    leeg810312  
       2017-08-02 22:01:27 +08:00 via Android   ❤️ 1
    @autoxbc Flash 不是 Apple 开发的,apple 能做什么,ios 的浏览器内核是它自己做的都做不好,能相提并论?这逻辑真搞笑。
    linking
        13
    linking  
       2017-08-02 22:12:22 +08:00
    开发中需要实时监听滚动的交互也不少啊,比如导航菜单的高亮,元素浮现的动画;如果说这是个好的机制,为什么在更先进的 WKWebView 中又去掉了这个机制呢?
    learnshare
        14
    learnshare  
       2017-08-02 22:45:51 +08:00
    Fixed 的元素会随着滚动飘走,目前只见过这一个不太合理的地方
    对性能的优化不能以牺牲功能为代价
    wohenyingyu01
        15
    wohenyingyu01  
       2017-08-02 22:51:16 +08:00
    @shuai265 tableviewcell 和这个有关系么 = =
    autoxbc
        16
    autoxbc  
    OP
       2017-08-02 22:58:45 +08:00
    @linking #13 我觉得把讨论的议题换成,在浏览器中,给 UI 线程高优先级,并允许其钳制 JS 线程的资源使用,那么投赞成票的应该会多一点。UIWebView 的处理方法显现了一点雏形。

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

    可能我更多的从用户的角度写代码,当我看到那些优化的很差的页面,也没有办法从系统层面给他去抖时,心情是很沮丧的,我希望浏览器给我选择的余地。
    autoxbc
        17
    autoxbc  
    OP
       2017-08-02 23:06:22 +08:00
    @learnshare #14 可不可以用 css 实现。

    前端界好像有个倾向,用 js 代替一切。内容用 js 生成,排版用 js 控制,这个有点跑偏。
    crysislinux
        18
    crysislinux  
       2017-08-02 23:14:33 +08:00
    @autoxbc 然而这并不是同一个问题,样式有些用了 js,那是因为单纯 css 没办法实现或者有些问题需要取舍,估计没几个人真喜欢 js 写 css,写起来也挺不方便的。。
    skye
        19
    skye  
       2017-08-03 03:26:08 +08:00   ❤️ 1
    这么个问题居然还能吵起来。。。lz 明明很友善的讨论问题。
    wangxn
        20
    wangxn  
       2017-08-03 07:44:00 +08:00 via Android
    凡是捧一样东西、踩一样东西都会引起论战,尤其是在自己不熟悉的情况下。
    murmur
        21
    murmur  
       2017-08-03 08:13:41 +08:00
    scroll ?我只知道 ios 如果不在 div 上加个 translate 000 一滚动的时候就呼啦一大片空白 这绝对是巨大的 bug
    ios 实际上兼容问题比 android 还恶心,国产的 android4.4 都调教的服服帖帖,几个前缀 postcss 也搞定
    反观 ios
    murmur
        22
    murmur  
       2017-08-03 08:32:56 +08:00
    @leeg810312 apple 为了利益竞争砍掉了 flash,商业目的没必要扯太多技术,你看现在 apple 在 h5 上优化的很好么
    以前 adobe 没做好至少别人做了,现在 safari 那坨东西比 chrome 恶心太多
    maplerecall
        23
    maplerecall  
       2017-08-03 10:11:49 +08:00 via Android
    @murmur 对对,很明显感觉 safari 最近的发展越来越奇怪了,各种诡异的兼容性问题越来越多…而且现在 iOS 上的 webview 在后台较多的情况下有也会出现严重的渲染性能问题,比如 transition 直接失效…

    另外 scrollevent 这个的确导致了一些设计的想法不得不放弃或者被迫使用模拟滚动这种低效的方法解决…
    learnshare
        24
    learnshare  
       2017-08-03 14:54:44 +08:00
    @autoxbc fixed 是 CSS 实现的,没有详细测试过,不知道是不是个例
    autoxbc
        25
    autoxbc  
    OP
       2017-08-03 15:27:24 +08:00
    @learnshare #24 刚测了一下,iOS 版 UC 使用 UIWebView,是 scroll 阻塞 dom 的实现,position:fixed 不会飘走。
    关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   5327 人在线   最高记录 6679   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 26ms · UTC 07:09 · PVG 15:09 · LAX 23:09 · JFK 02:09
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.