收藏
回答

onPageScroll


onPageScroll的滚动在Android机中表现很差

最后一次编辑于  2018-02-02
回答关注问题邀请回答
收藏

13 个回答

  • 星期二
    星期二
    2018-07-25

    现在解决了吗?安卓会卡一下再跑出来

    2018-07-25
    赞同
    回复
  • Zwx。
    Zwx。
    2018-03-09

    哈哈哈移动端因为浏览器原因甚至于设备原因导致的各种兼容性和坑,正是让我们痛也并不怎么快乐的地方

    2018-03-09
    赞同
    回复
  • 永恒君
    永恒君
    2018-03-09

    非常 nice,共同进步。


    看完你给的案例后我也在思考一个问题,

    以前手机在滑动时会禁掉动画和 gif 播放,

    大部分手机还会减少或屏蔽 scroll 的触发。


    那有没有什么办法呢,以前也是有的,

    比如 touchend 后的 2s 里,自己加个 20ms 的 setinterval 触发。

    但后来实验下来好像系统并不是 touchend 后才开始做限制。


    所以才有了 AlloyTouch 和 better-scroll 等自写滚动的插件的出头之日吧。这很有意思。

    2018-03-09
    赞同
    回复
  • Zwx。
    Zwx。
    2018-03-09

    @永恒君

    目前没有看到设备不支持sticky,但为了防止存在,我选择了在onload()的时候通过

    if (CSS.supports("position", "sticky") || CSS.supports("position", "-webkit-sticky")) {    // 支持 sticky}

    去判断是否支持sticky,支持就是用sticky,不支持就是用fixed。

    感谢解惑!

    2018-03-09
    赞同
    回复
  • Zwx。
    Zwx。
    2018-03-09

    @永恒君

    你小程序搜索“电影出票儿”,点击进入电影详情就可以看到筛选器的问题。

    感谢!

    position:sticky 实测可用,虽然在安卓上快速滑动的时候还是会出现延迟,不过较于fixed已经有了很大的优化,就是不知道sticky在小程序中是否也存在兼容性问题,正在测试中。

    2018-03-09
    赞同
    回复
  • 永恒君
    永恒君
    2018-03-09

    这个方面是不得不承认的,IOS 要更佳,无论是 scroll 的触发次数还是渲染性能上。


    我手机上的猫眼电影没看到这个吸顶的效果,

    如果是元素本来在某位置,滑动超过该位置则吸顶的话,

    css 的 position: sticky 要更佳,已测可用。(不知是不是你的需求)

    2018-03-09
    赞同
    回复
  • Zwx。
    Zwx。
    2018-03-09

    @永恒君

    感觉是安卓手机渲染视图的性能相比较于ios更差?

    2018-03-09
    赞同
    回复
  • Zwx。
    Zwx。
    2018-03-09

    @永恒君

    谢答。代码中确实已经加入了位置判断以及值的判断,当中其实也只setData了一次,但是安卓上就是会停顿一下然后再到该到的位置。

    代码如下:


    控制台如下:


    安卓真机上会出现这个情况


    tab栏会延迟大概几百毫秒的时间,到对应的位置,看了猫眼电影的电影出票儿里的电影详情页面,上面的筛选器也是在安卓下会出现这种问题,也是延迟很短的时间,然后闪到该到的位置。


    2018-03-09
    赞同
    回复 1
    • 刘亚亚
      刘亚亚
      2018-09-06

      有解决吗,朋友

      2018-09-06
      回复
  • 永恒君
    永恒君
    2018-03-09

    如果其中需要加动画的话,

    更推荐使用 createAnimation 来做,

    它的性能几乎和 dom 操作相近。

    2018-03-09
    赞同
    回复
  • 永恒君
    永恒君
    2018-03-09

    我的意思是,每次滑动会触发十多次 onPageScroll,

    如果每次都 setData,这个性能会非常得糟糕。


    所以更推荐达成位置判断后,再进行一次值是否需要变化的判断,

    这样在十多次触发中只会有一次 setData。


    不妨你 for 个 1000 次 setData 看看效果,会非常卡顿。

    这种沟通成本可能源于小程序 webview 与 js 的分离,存在跨端通信的成本问题。

    2018-03-09
    赞同
    回复

正在加载...