3 ms·

The scrolling difference is due to differences in how Android and iOS prioritize things. On iOS, putting your finger on the screen stops all processing on the p

by cheald 14y ago

The scrolling difference is due to differences in how Android and iOS prioritize things. On iOS, putting your finger on the screen stops all processing on the page - no rendering, no animation, no Javascript, no downloading, nothing runs until you lift your finger off the screen. This lets the system devote 100% of its processing power to moving that rendered graphic around. Android, by comparison, continues to perform its tasks while you scroll. This means that the scrolling can be jerkier if things are loading, but you continue to get a full interactive page while you're scrolling. Speaking as a developer, iOS(/mobile Safari) gives me fits. It's the mobile generation's IE6.

danielrm26 14y ago
Well, given that a tiny fraction of users are developers, doesn't it seem like a poor decision on Google's part to have a poor user experience in order to help in some other area? Seems like UX should in fact be the highest priority.
- cheald 14y ago
  The way that iOS does things prevents developers from doing things to help UX! For example, as an effect of this prioritization, iOS doesn't report scroll position while you're scrolling a page or scrollable div in a page, until the scroll has completed, and the scroll momentum has come to a full stop. This makes all sorts of app-like interactions impossible in an iOS webapp. I don't really think that the user experience is poor, per se. I think it's a matter of acclimation; I've been using Android since the Nexus One, and while it was certainly frustrating in the past, Android 4.1 really stepped things up, and it's a really nice experience now. I appreciate how iOS scrolling feels, but in general, Android's way of doing things seems to be a lot nicer to me. I actively use Android and iOS devices on a daily basis (my phone is an LG Nexus 4, the same one you disliked), and Android feels much, much better to me than iOS does, with the sole exception of scrolling smoothness. It's worth noting that there is one difference that might have been annoying you; iOS starts scrolling as soon as you start moving your finger. Android has a deadzone of a few pixels, so it might feel less responsive if you're used to the lack of deadzone on iOS. Once you're used to it, it's not an issue.
elsurudo 14y ago
I don't think this is strictly true. The runloop has different modes, and you can attach background operations to them accordingly. It's true that scrolling does block some modes (and by extension some background tasks and timers), though.
- cheald 14y ago
  Perhaps in apps, but not in the browser.
trendnet 14y ago
"...no downloading, nothing runs until you lift your finger off the screen." It's not true. The browser continues fetching data, and the kernel continues with context switching.
- cheald 14y ago
  I'll have to try it again then. Last I'd looked at it (this was early iOS 5), though, it caused really nasty issues with a preloading gallery I was working on. We ended up having to preload several slides in advance, as iOS would just flatly refuse to do anything in the page until the user had removed their finger from the page. The context switching I'll give you. I really meant that the browser appears to stop doing all its stuff while you're touching the screen, not that the system comes to a full halt. Obviously the render loop is still running. The fact that you also don't get scroll position updates until the drag momentum wears out is also a giant pain in the ass.
  - calciphus 14y ago
    Maybe that's why iOS has so much more "mobile data" - all these weird hacks like prefetching a bunch of data the user may never see in order to make scrolling behavior more acceptable.
gecko 14y ago
This has been repeatedly invalidated over and over and over again, and I'm really tired of being brought up as the excuse. First, you can simply prove that's not right empirically: start loading a large page, slap down your finger, scroll around for awhile, notice that the rendering has halted (which seems to confirm what you're saying), and then release your finger, to witness the page snap to 100% completeness. Why? Because things were indeed continuing in the background; the only thing that "blocked" is that the OpenGL canvas you're dragging around doesn't get swapped while you're scrolling. Here's what's actually happening: iOS makes it absurdly easy to do computations on background threads. Android doesn't. iOS makes it very easy to offload a lot of processing to the GPU. Android doesn't. The difficulty means that many apps end up doing computation and actual rendering on the UI thread, which, surprise, makes for a jerky experience, whereas most iOS apps do the computation on a different thread than they do their rendering. Throw in that Dalvik's GC is beyond horrible and you've got everything you need for a nice and jittery UI experience. Note that Android absolutely allows you to do background processing, GPU-heavy rendering; it's just harder. You can even avod the GC by carefully reusing objects in fast-render loops. In fact, our Android Trello dev either just released or is about to release an update to the Android app that makes it scroll smooth as silk by doing all of the above. But it requires a lot more effort to get to the same place, which is why "all" iOS apps perform better than Android ones.
- cheald 14y ago
  I must be doing something different, because performing your exact test doesn't have the results you describe. I just opened a CNET article on my latest-gen iPod Touch running iOS 6. When the page was half-loaded (header loaded in, no content yet), I placed my finger on the page and dragged it a couple pixels. I left it there for 30 seconds - nothing on the page changed during this time - then removed my finger. I then very clearly watched the story header image progressively download, and it took several more seconds for the page to become fully rendered.
danielrm26 14y ago
There's an easy way to test this: visit a very large site while tcpdump or Burp is capturing all your HTTP traffic. And upon first touch of the site, put your finger on the screen. Does the stream of requests from your phone stop? No, it doesn't. The requests visibly continue to be made in the background as the page continues to load, so your comment isn't accurate.
- cheald 14y ago
  Okay, here you go. Installed tcpdump on my router, grabbed all traffic to my ipod during the test. The test consisted of opening one webpage (cnet, again), and putting my finger down on the screen twice while the page was loading. I opened the dump in Wireshark and filtered it to HTTP traffic. http://cl.ly/image/1R0v1P3y0J1u http://cl.ly/image/1R0v1P3y0J1u You can clearly see that traffic stops at 8 seconds, when I put my finger on the device. It then resumes 23 seconds later, when I remove my finger. It then stops again 2 seconds later, when I put my finger back on the device. This was one pageload, no shennanigans, just putting my finger down on the device and scrolling it slightly while the page was loading. It took ~40 seconds to load that page because I had my finger on the screen. It looks an awful lot like the device is not downloading anything while my finger is on the screen. It certainly didn't just snap to "fully rendered" when I removed my finger at 31 seconds.
  - chrisringrose 14y ago
    I think this is an iPod limitation implemented by Apple. I have the iPhone 5, loaded a large non-mobile site, and did the same thing. Upon lifting my finger, the rest of the page loads instantly.
    - cheald 14y ago
      The same behavior that I observed happens on my first-gen iPad, FWIW. I don't have an iPhone to test with.

by cheald 14y ago

danielrm26 14y ago

Well, given that a tiny fraction of users are developers, doesn't it seem like a poor decision on Google's part to have a poor user experience in order to help in some other area? Seems like UX should in fact be the highest priority.

cheald 14y ago
The way that iOS does things prevents developers from doing things to help UX! For example, as an effect of this prioritization, iOS doesn't report scroll position while you're scrolling a page or scrollable div in a page, until the scroll has completed, and the scroll momentum has come to a full stop. This makes all sorts of app-like interactions impossible in an iOS webapp. I don't really think that the user experience is poor, per se. I think it's a matter of acclimation; I've been using Android since the Nexus One, and while it was certainly frustrating in the past, Android 4.1 really stepped things up, and it's a really nice experience now. I appreciate how iOS scrolling feels, but in general, Android's way of doing things seems to be a lot nicer to me. I actively use Android and iOS devices on a daily basis (my phone is an LG Nexus 4, the same one you disliked), and Android feels much, much better to me than iOS does, with the sole exception of scrolling smoothness. It's worth noting that there is one difference that might have been annoying you; iOS starts scrolling as soon as you start moving your finger. Android has a deadzone of a few pixels, so it might feel less responsive if you're used to the lack of deadzone on iOS. Once you're used to it, it's not an issue.

elsurudo 14y ago

I don't think this is strictly true. The runloop has different modes, and you can attach background operations to them accordingly. It's true that scrolling does block some modes (and by extension some background tasks and timers), though.

cheald 14y ago
Perhaps in apps, but not in the browser.

trendnet 14y ago

"...no downloading, nothing runs until you lift your finger off the screen." It's not true. The browser continues fetching data, and the kernel continues with context switching.

cheald 14y ago
I'll have to try it again then. Last I'd looked at it (this was early iOS 5), though, it caused really nasty issues with a preloading gallery I was working on. We ended up having to preload several slides in advance, as iOS would just flatly refuse to do anything in the page until the user had removed their finger from the page. The context switching I'll give you. I really meant that the browser appears to stop doing all its stuff while you're touching the screen, not that the system comes to a full halt. Obviously the render loop is still running. The fact that you also don't get scroll position updates until the drag momentum wears out is also a giant pain in the ass.
- calciphus 14y ago
  Maybe that's why iOS has so much more "mobile data" - all these weird hacks like prefetching a bunch of data the user may never see in order to make scrolling behavior more acceptable.

gecko 14y ago

This has been repeatedly invalidated over and over and over again, and I'm really tired of being brought up as the excuse. First, you can simply prove that's not right empirically: start loading a large page, slap down your finger, scroll around for awhile, notice that the rendering has halted (which seems to confirm what you're saying), and then release your finger, to witness the page snap to 100% completeness. Why? Because things were indeed continuing in the background; the only thing that "blocked" is that the OpenGL canvas you're dragging around doesn't get swapped while you're scrolling. Here's what's actually happening: iOS makes it absurdly easy to do computations on background threads. Android doesn't. iOS makes it very easy to offload a lot of processing to the GPU. Android doesn't. The difficulty means that many apps end up doing computation and actual rendering on the UI thread, which, surprise, makes for a jerky experience, whereas most iOS apps do the computation on a different thread than they do their rendering. Throw in that Dalvik's GC is beyond horrible and you've got everything you need for a nice and jittery UI experience. Note that Android absolutely allows you to do background processing, GPU-heavy rendering; it's just harder. You can even avod the GC by carefully reusing objects in fast-render loops. In fact, our Android Trello dev either just released or is about to release an update to the Android app that makes it scroll smooth as silk by doing all of the above. But it requires a lot more effort to get to the same place, which is why "all" iOS apps perform better than Android ones.

cheald 14y ago
I must be doing something different, because performing your exact test doesn't have the results you describe. I just opened a CNET article on my latest-gen iPod Touch running iOS 6. When the page was half-loaded (header loaded in, no content yet), I placed my finger on the page and dragged it a couple pixels. I left it there for 30 seconds - nothing on the page changed during this time - then removed my finger. I then very clearly watched the story header image progressively download, and it took several more seconds for the page to become fully rendered.

danielrm26 14y ago

There's an easy way to test this: visit a very large site while tcpdump or Burp is capturing all your HTTP traffic. And upon first touch of the site, put your finger on the screen. Does the stream of requests from your phone stop? No, it doesn't. The requests visibly continue to be made in the background as the page continues to load, so your comment isn't accurate.

cheald 14y ago
Okay, here you go. Installed tcpdump on my router, grabbed all traffic to my ipod during the test. The test consisted of opening one webpage (cnet, again), and putting my finger down on the screen twice while the page was loading. I opened the dump in Wireshark and filtered it to HTTP traffic. http://cl.ly/image/1R0v1P3y0J1u http://cl.ly/image/1R0v1P3y0J1u You can clearly see that traffic stops at 8 seconds, when I put my finger on the device. It then resumes 23 seconds later, when I remove my finger. It then stops again 2 seconds later, when I put my finger back on the device. This was one pageload, no shennanigans, just putting my finger down on the device and scrolling it slightly while the page was loading. It took ~40 seconds to load that page because I had my finger on the screen. It looks an awful lot like the device is not downloading anything while my finger is on the screen. It certainly didn't just snap to "fully rendered" when I removed my finger at 31 seconds.
- chrisringrose 14y ago
  I think this is an iPod limitation implemented by Apple. I have the iPhone 5, loaded a large non-mobile site, and did the same thing. Upon lifting my finger, the rest of the page loads instantly.
  - cheald 14y ago
    The same behavior that I observed happens on my first-gen iPad, FWIW. I don't have an iPhone to test with.