App States and Multitasking
Managing App State Changes
App states
![](https://i-blog.csdnimg.cn/blog_migrate/77f4abd22e87e679dc4bd070d53d8cbf.png)
Most state transitions are accompanied by a corresponding call to the methods of your appdelegate object(e.g.application:willFinishLaunchingWithOptions:
).
The App Launch Cycle
As part of the launch cycle, the system creates a process and main thread for your app and calls your app’smain
function on that main thread.
If your app is launched into the background, the main difference is that instead of your app being made active, it enters the background state to handle the event and then is suspended shortly afterward:
To determine whether your app is launching into the foreground or background, check theapplicationState
property of the shared UIApplication
object.
About the main Function
#import <UIKit/UIKit.h>
int main(int argc, char *argv[])
{
@autoreleasepool {
return UIApplicationMain(argc, argv, nil, NSStringFromClass([MyAppDelegate class]));
}
}
UIApplicationMain parameters:
-
The third parameter identifies the name of the principal app class. This is the class responsible for running the app. It is recommend that you specify
nil
for this parameter, which causes UIKit to use theUIApplication
class. -
The fourth parameter identifies the class of your custom app delegate.
What to Do at Launch Time
-
Check the contents of the launch options dictionary for information about why the app was launched, and respond appropriately.
-
Initialize the app’s critical data structures.
-
Prepare your app’s window and views for display.
- If your app does not automatically load a main storyboard or nib file at launch time, you can use the
application:willFinishLaunchingWithOptions:
method to prepare your app’s window for display.
- If your app does not automatically load a main storyboard or nib file at launch time, you can use the
pps are expected to launch and initialize themselves and start handling events in less than 5 seconds. If an app does not finish its launch cycle in a timely manner, the system kills it for being unresponsive.
Responding to Interruptions
Moving to the Background
![](https://i-blog.csdnimg.cn/blog_migrate/8754a17332a5da6a0bbc84aded40c067.png)
What to Do When Moving to the Background
-
Prepare to have their picture taken. When the
applicationDidEnterBackground:
method returns, the system takes a picture of your app’s user interface and uses the resulting image for transition animations. If any views in your interface contain sensitive information, you should hide or modify those views before theapplicationDidEnterBackground:
method returns. -
Save user data and app state information. All unsaved changes should be written to disk when entering the background.
-
Free up as much memory as possible.
Your app delegate’s applicationDidEnterBackground:
method has approximately 5 seconds to finish any tasks and return. If the method does not return before time runs out, your app is killed and purged from memory.
Memory Usage for Background Apps
Apps that consume large amounts of memory while in the background are the first apps to be terminated.Returning to the Foreground
![](https://i-blog.csdnimg.cn/blog_migrate/7462cb33a5591960bec8a99545b3c901.png)
Processing Queued Notifications at Wakeup Time
A suspended app does not execute any code and therefore cannot process notifications related to orientation changes, time changes, preferences changes, and many others that would affect the app’s appearance or state. To prevent your app from becoming overloaded with notifications when it resumes, the system coalesces events and delivers a single notification (of each relevant type) that reflects the net change since your app was suspended.Notifications delivered to waking apps => Table 3-2
App Termination
If your app is running (either in the foreground or background) at termination time, the system calls your app delegate’sapplicationWillTerminate:
method so that you can perform any required cleanup.
The applicationWillTerminate:
method is not called if your app is currently suspended.
The Main Run Loop
The main run loop of your app is responsible for processing all user-related events. The UIApplication
object sets up the main run loop at launch time and uses it to process events and handle updates to view-based interfaces. As the name suggests, the main run loop executes on the app’s main thread. This behavior ensures that user-related events are processed serially in the order in which they were received.
As the user interacts with a device, events related to those interactions are generated by the system and delivered to the app via a special port set up by UIKit. Events are queued internally by the app and dispatched one-by-one to the main run loop for execution. The UIApplication
object is the first object to receive the event and make the decision about what needs to be done. A touch event is usually dispatched to the main window object, which in turn dispatches it to the view in which the touch occurred:
Common types of events for iOS apps --- Table 3-3 (Event Handling Guide for iOS)
Background Execution and Multitasking
If you find you need to perform background tasks, here are some guidelines for when that is appropriate:
-
You need to implement at least one of several specific user services.
-
You need to perform a single finite-length task.
-
You need to use notifications to alert the user to some relevant piece of information when your app is not running.
Background modes for apps --- Table 3-4