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.

• 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.

• 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.

• 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.

• 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.

• 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