Re: iOS app launching speed
Re: iOS app launching speed
- Subject: Re: iOS app launching speed
- From: Conrad Shultz <email@hidden>
- Date: Tue, 15 May 2012 15:32:47 -0700
On 5/15/12 1:57 PM, Alex Zavatone wrote:
> But that's the point, I'm never going to display an empty TVC.
>
> Lame is how an HTML page loads with pieces coming in in varying order,
> with parts of the page appearing and then resizing and then graphics
> appearing and then being replaced.
> I don't want to see it build piece by piece. And I certainly don't want
> the user to see that mess. I want the data to load in an organized
> manner and then if the screen /MUST/ display in a piece by piece
> fashion, do not resize components or adjust scroll positions after the
> data appears, and display the data in an orderly fashion as if it were
> meant to come in in that order.
I feel like we should back up here and walk through the loading process
because I get the impression that we are all talking about different events.
When you launch an application, the sequence of events is, to a first
approximation, the following:
1) Springboard, or launchd, or the window server, or whatever Apple
component is responsible for managing application launches looks inside
your bundle and picks out a Default.png depending on the device and
orientation. This gets drawn immediately to the screen.
2) After going through the usual application launch details that you
have no control over (and whose duration will depend on hardware, system
resources and activity, etc.), the OS sends your application delegate
-applicationDidFinishLaunchingWithOptions:. This is effectively the
first place you can start doing anything interesting.
3) The Default.png continues to be displayed until
-applicationDidFinishLaunchingWithOptions: returns and, on the next turn
of the run loop, the UI can start being updated. This means that it is
very important to get and and get out of
-applicationDidFinishLaunchingWithOptions: FAST. No synchronous network
connections, no lengthy disk I/O, no blocking CPU operations. If you
drag your feet in here, not only will Default.png remain on screen too
long, but the watchdog might even kill your app.
4) On the next turn of the run loop, the UI (which was set up in
-applicationDidFinishLaunchingWithOptions:) is displayed, instantly
replacing Default.png.
5) The run loop is now running normally, and you can do whatever you
wish within your code.
The takeaways:
* Don't block in -applicationDidFinishLaunchingWithOptions:. (Well,
don't ever block, but especially not here.)
* Don't display a splash screen in Default.png because it will, if
things are working well, flash away very quickly.
What I am suggesting you do is have a Default.png that will ease the
transition to the initial UI, which might just be an empty table view.
As data comes in, you update the table view.
If you don't want to update the table view in real time (I agree with
you that if the connection is really slow it can be awkward to watch
rows load one at a time), you can collect updates as they come in and
load them in batches.
> For loading a TVC with a 4KB data load, I opt to make the user wait
> 1/20th of a second so that the TVC can display all at once with all its
> data. And when a user selects a top level item from that TVC, I'll
> spawn off the next requests to get the data expected while the user is
> occupied by looking at the interface. There is a split second where the
> user thinks about what's in front of their eyes and I want to use that
> to the user's advantage by prefetching data.
Except that, as discussed, you have no way to ensure that it will only
be 1/20th of a second. Plus, things that start out as 4 KB have a way
of growing; it's easier to implement best practices up front than to
have to rearchitect your entire launch process when your manager or
client comes to you and says, "OK, now we need to deal with 500 KB."
And if you do get fast performance, you run smack into the other problem
I described with splash screens (the flash/strobe effect), which you
haven't addressed.
--
Conrad Shultz
Synthetiq Solutions
www.synthetiqsolutions.com
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden