Titanium Community Questions & Answer Archive

We felt that 6+ years of knowledge should not die so this is the Titanium Community Questions & Answer Archive

Tips for reducing load time

I'm looking for strategies to reduce start up time. Right now, my app takes almost 15 seconds to load … the splash screen is displayed that long, makes you think the app has crashed or isn't going to load.

I'm testing on a 3GS w/ iOS 4.0.1. The app is currently compiled with SDK 1.4.2, though similarly long load times were the norm with and earlier. I don't have such long load times on Android: ~3 seconds on my Droid 1.

My main window is four buttons and a background image. A hidden scroll view is also created. It has two nested views, containing 6 fields and two buttons.

Sorry, I don't care to post my code. So, I'm hoping you can just provide some high-level strategies, things to watch out for, etc.

— asked November 22nd 2010 by Tim Poulsen
  • iphone
  • performance
  • If you're going to vote my question down, please have the decency to leave a comment telling me why?

    — commented November 22nd 2010 by Tim Poulsen
  • I'll vote you back to neutral, seems a valid question!

    — commented November 22nd 2010 by Andrew Burgess
  • Thank you Andrew! I didn't think I was asking anything that absurd. My comment that the code is faster on my droid was not meant as some sort of slam against iOS. I know asking this question is just a long shot, made worse by not wanting to share my code.

    — commented November 22nd 2010 by Tim Poulsen

6 Answers

  • Tim,

    My SWAG is the difference in start up time is not so much iOS vs Android as it is just the speed of the devices being used. If you tried on an iPhone 4 the load time is likely to be greatly reduced from the 3GS.

    That said, it doesn't answer your question.

    I'm too new to Titanium to give much help here, but here are a couple ideas:

    • Only "lazy load" stuff as needed. That is, try to avoid doing something until it is needed. For example, don't preload various windows; wait until you must show them.

    • Use the URL property of windows to put the processing for that window in a separate *.js context. This makes that window run on its own thread. One trade-off here is the new window does not have direct access to the variables in the parent window. See "Passing Data" at the bottom of the Window object docs for ideas on how to handle that.

    • This next tip is tricky and deceiving in my book, but it is actually what Apple recommends in their SDK documentation. Instead of a typical splash screen, they say take a screen shot of your opening page and use it as the splash page. This gives the appearance of almost immediate launch, but of course at that point it does not respond to taps or anything because there are no objects on the screen.

    — answered November 22nd 2010 by Doug Handy
  • Doug, thanks for your tips. Is there a way to lazy load a view? Maybe I should go with a window. I was having troubles on android doing so and adopted a view. But I guess I could go with platform specific code, as I've done that overall for other reasons.

    Users tap a button to open a somewhat complex view (scrollview, containing a pair of nested views, one with eight or so data entry fields, the other a slide-up picker based on Dan Tamas' technique). That could be part of the slow down I guess.

    I have only a 3GS for testing. I asked a friend with an iPhone 4 to test the app, but I haven't heard from him in a couple of days. Hopefully his results will be better.

    — answered November 22nd 2010 by Tim Poulsen
    1 Comment
    • I tried moving the view definition code to an include file (not the url:somefile.js kind of thing you can do with a window). No effect as I expected. You don't get a separate thread with an include, but it was simple to do so I thought at least worth a shot.

      Next, I put the main view definition statements w/in the main stream of the app. Then I used an "open" event listener on the window to define all the fields & labels on the view. This was an attempt at masking or overlapping the loading of the view. It didn't really work. The app loaded maybe three seconds faster. But, if you interacted with it at all before the view was fully defined, it would hang. And, there was no indication that the view was being built. I suppose I could add some further "please wait" sort of output. But, for only a couple of seconds of gain it's not worth it.

      — commented November 22nd 2010 by Tim Poulsen
  • Building with the 1.4.3 nightly build improved speed maybe 25%. The app loads twice as quickly with 1.5 nightly build. However, at this stage neither of those APIs works completely for my app. Button event handlers seem to get lost and my views are rendered in strangely semi-transparent ways. So for now, I'll stick with 1.4.2 and deal with slow load times on older devices.

    — answered November 24th 2010 by Tim Poulsen
  • 15 seconds for startup seems pretty excessive - what it the startup time for the default generated application on your device?

    Doug had some good thoughts, but you might want to do some low-tech profiling to see if there are specific areas of your code that are taking a long time. Maybe print a timestamp at the top of your app.js, and at various points during the creation of your UI - could be helpful in determining where the bottleneck is.

    — answered November 24th 2010 by Kevin Whinnery
  • Kevin, the bottleneck is most certainly the rendering of this scrollview:

    which includes this nested slide-up view containing a picker

    My comments below describe my various attempts to load/render this view in different ways. None of those attempts have worked completely.

    — answered November 24th 2010 by Tim Poulsen
  • For what its worth (in case someone like me finds this thread in a search).

    I had the same problem with multiple scrollviews really slowing down load time. Each additional scrollview slowed things down massively (i had 3).
    Elsewhere in the q&a using a tabgroup is mentioned but i couldn't do this as my app is not easily structured like that.

    I can also confirm that file size of the images is pretty irrelevant as long as they are not excessive (mine ranged from 4KB to 89KB).

    I fixed it by making sure the sub views and the scollviews they are part of were not being loaded until that 'page' of my app was visible. This meant that the other content on the page and in the app loaded very quick and there is a 1 or 2 second delay before the scrollviews come up which looks way better than long splash screen for the whole app.

    thumbs up to the rule ALWAYS LAZY LOAD

    — answered January 8th 2011 by Jez Manser
The ownership of individual contributions to this community generated content is retained by the authors of their contributions.
All trademarks remain the property of the respective owner.