5

I am developing a web-app utilizing Application Cache, and everything is working great on desktop browsers and on Android (even very old & slow android handsets). However downloading the appcache is taking much much much longer on iOS 6 in both Safari and Chrome.

My application cache total size is a mere 2.1Mb, and I have a pretty solid 70Mbps (download) internet connection. I would expect caching to be pretty rapid.

Here are my times so far:

  • Desktop Chrome: <1s (similar times for Safari & Firefox)
  • Android 2.3.3 Stock Browser: ~4s (similar times for Chrome & Dolphin)
  • Android 4.2.2 (Emulated): ~7s (running inside a PhoneGap app)
  • iPhone 4S 6.0 Safari: 8 minutes!!! (around the same in iOS Chrome too!!)
  • iPad 2 6.0 Safari: as above!!!

All of these devices are using the same wifi and internet connection, and my iPhone/iPad are otherwise functioning fine (no native apps exhibiting internet speed issues, and regular websites load just fine). There just seems to be something absolutely decimating AppCache download speed under iOS.

The window.applicationCache.status throughout this time is appCache.DOWNLOADING, and I have a progress event running counting the files as they are downloaded, so I'm certain that it is not stuck elsewhere. This just appears to be the time it takes to download. What gives?

Addendum : The iPhone also runs ridiculously hot, and the battery ticks down very quickly during this operation. It seems that something is causing the CPU to run flat-out during this download.

(Note: I can't publish a link to the web-app here as we're still in private beta, but if you would need to see it before you think you'd be able to help diagnose it, email me at the address in my profile and I'll send a link to the app).

Karl White
  • 497
  • 1
  • 5
  • 13
  • 2
    To start, throw a TCP sniffer on it (like [Wireshark](http://www.wireshark.org/)) to get an idea of what the conversation between the device/server looks like during that 8 minute period. – Tim M. Apr 10 '13 at 21:56

2 Answers2

2

Okay, I figured it out with the help of the iOS Emulator, and Xcode Instruments to profile it. (I'm not sure if I should add my solution into the main question, or as an answer, but I thought I'd do it this way as my question is already a little cluttered).

As it turns out, it was actually some erroneous javascript causing the issue, but apparently only on iOS.

The web-app is intended to only be a single page high (no vertical scrolling, except within specific DIVs), so in addition to the usual standard JS code for hiding the address bar...

        window.addEventListener("load",function() {
            // Set a timeout...
            setTimeout(function(){
                // Hide the address bar!
                window.scrollTo(0, 1);
            }, 0);
        });

...I had also added in the following:

        $(document).scroll(
            function(e){
                window.scrollTo(0, 1);
            });

From looking at the profile results, I was able to see that a lot of time was being spent in scrollTo, so it immediately pointed to this as the cause. Why the scroll event was being triggered so much, I have no idea (this was occurring with no touching of the screen whatsoever).

My initial fix is to throttle that code, but I am now evaluating whether or not I even need it at all. Here is the code I have that fixes it for now (using jquery-debounce, which I was already using for something else):

        $(document).scroll(
            $.throttle(function(e){
                window.scrollTo(0, 1);
            })
        , 10);

The download time of the application cache is now in line with the Android times. Phew!

Karl White
  • 497
  • 1
  • 5
  • 13
0

The code is getting itself into an infinite loop, as the initial scrollTo function call triggers the scroll event handler, which then repeatedly re-triggers itself! My best guess is that the iOS JavaScript engine handles this infinite loop differently to the other browsers' JavaScript engines.

Mark Salvin
  • 21
  • 2