IOS app life cycle

Source: Internet
Author: User

Reported the attitude of consulting, began to write iOS blog, I hope that we learn together, and common progress ....

Their own drawing has been added to the HJC watermark. Not their own drawing, there is no HJC watermark.

iOS Knowledge Points:

1. Have a deep understanding of the features of iOS (such as Object life cycle, memory management, protocols, features, GCD, blocks, coreanimation, Cocoa Touch Framework, runtime mechanism, etc.)

2, iOS performance optimization and memory optimization, code debugging and tuning and related tools (such as: Instruments), integration tools.

3, multi-threading, network communication (such as HTTP, socket, UDP), Data persistence (4 commonly used)

4, design mode, such as KVO, single case, adapter, strategy, agent, factory,

5, interface UI (such as storyboard, Nib), various UI controls, can customize UI control, UI architecture

6, architecture design, familiar with third-party libraries, open source components (such as: Sdwebimage, Afnetwork, ASI, THREE20), and can develop third-party components

7 Quality: Code Review, Unit test, automated test

8. Familiar with Swift

9, skilled use of xcode development tools, including engineering configuration (such as certificate configuration, call third-party library, etc.), skilled use of git, svn and other tools

10. Proficient in commonly used data structures and algorithms

11, Animation: cocos2d, Unity3d

One, App lifecycle---5 states of the app

The iOS app is available in 5 different states, namely:

1, not running is not running: app is not started or forced to terminate.

2. Inactive inactive: The current app is running in the foreground, but does not receive events (other code may be executing at the moment). Typically, a midway transition stays in this state briefly whenever the app is switching from one state to another. The only time it takes longer to stay in this state is when the user locks the screen, or the user is prompted to respond to certain events (such as phone calls, unread text messages, etc.).

3. Active activation: The current app is running in the foreground and receiving events. This is the normal state at which the app is running in the foreground.

4, Backgroud backstage: The program in the background and can execute code, most of the program into this state will stay in this state for a while. The time will then go into the suspended state (Suspended). After special request can be in Backgroud state for a long time.

5. Suspended hangs: The program cannot execute code in the background. The system automatically turns the program into this state and does not give notice. When suspended, the program is still in memory, when the system memory is low, the system will remove the suspended program, to provide more memory for the foreground program.

One thing to note is that for applications that go directly into the background state from the not running state, the user interface file will still be loaded if the application has an interface when the boot enters the background state, but it will not appear on the application window.
In order to determine in the program whether your program is entering the foreground or background, you can application:didfinishlaunchingwithoptions: The ApplicationState property of the UIApplication class object is detected in the method, and if the application enters foreground, the property value is Uiapplicationstateinactive, and if you enter background, is the Uiapplicationstatebackground.

To detect the sample code:

Uiapplicationstate state = [UIApplication sharedapplication].applicationstate;
Return (state==uiapplicationstateactive | | state==uiapplicationstateinactive);

Second, the app lifecycle---execution process

Application:didfinishlaunchingwithoptions: This is the function that is called when the program starts.

Applicationdidbecomeactive: The function that the app executes when it prepares to enter the foreground runtime.

Applicationwillresignactive: The function that the app is currently executing from the foreground run state.

Applicationdidenterbackground: When the application is in the background state and no code is executed, the future will be suspended into the suspended state.

Applicationwillenterforeground: The current app is moving from the background into the foreground running state, but it is not currently in the active state when the function is executed.

Applicationwillterminate: The function that the current application is about to be terminated, called before terminating. This method is not called if the app is currently in suspended.

Press the HOME key:

Applicationwillresignactive

Applicationdidenterbackground

1. When the URL request arrives, if your app is not running, it will be started and moved to the foreground to open the URL.

Application:didfinishlaunchingwithoptions:

Application:openURL:sourceApplication:

Applicationdidbecomeactive

2. When the URL request arrives, if your app is running background or is suspended, it will be moved to the foreground to open the URL.

Share back from third parties:

Applicationwillenterforeground

Application:openURL:sourceApplication:

Applicationdidbecomeactive

Applications that support custom URL patterns can specify different splash screen images between apps before they start and go to work with URLs. For details, see Apple's Official document Iphoneappprogrammingguide.pdf on page 85th, "providing Launch Images for Custom URL schemes".

3, notification, in particular, displays the banner mode of notification, and does not like the above interrupt the current active state of the application to switch to the inactive state. The banner of such notifications is placed above the top edge of your application window, so your app is still in active state and continues to receive touch events as before. However, if the user pulls down banner to render the notification hub content, the current app will switch to the inactive state as the warning-based interrupt above.

During a call, adjust the UI of your app:

When the user is on the phone and returns to your app to continue the call, the height of the status bar should increase to reflect the fact that the user is calling. Similarly, when a user ends a call, the height of the status bar should be scaled back to normal height. The best way to handle the height change of the status bar is to use view controllers to manage your app views. When the status bar frame size changes, view controllers automatically adjusts all the internal views that they manage.

If your app is not using view controllers for some reason, you should manually respond to the change in the status bar frame size, Specifically, through the registration of Uiapplicationdidchangestatusbarframenotification notification to achieve. The notification handler handler should get the height of the status bar and use that data to moderately adjust the height of the view included in the current app.

4, the application of cutting back to the table background should do what:

Applications can do some preparatory work before the Applicationdidenterbackground: Background state, and when tangential to the background state, all applications need to do the following:

(1) Application interface snapshot. When the Applicationdidenterbackground: method returns, the system saves a snapshot of the application interface and uses the snapshot image as the conversion animation. If you have a view that involves sensitive information in your application interface, you should hide or modify the views before Applicationdidenterbackground: method returns.

(2) Save user data and app status information. All unsaved changes should be written to disk before being cut to the background state. This step is necessary because your app is likely to be killed quickly in the background for a variety of other reasons. You can perform these operations on background thread background threads, as needed.

(3) Release as many memory resources as possible.

Applicationdidenterbackground: Method allows up to 5 seconds to complete any task and then return. In practice, this method should be returned as quickly as possible. If this method does not return after the time expires, the app is killed and the memory consumed is cleared. If your application does require more time to perform a task, you can call Beginbackgroundtaskwithexpirationhandler: The method requests the background execution time, and then starts a thread that can perform the task for a long time. Whether or not you start a thread that performs a background task, the Applicationdidenterbackground: Method must exit after 5 seconds.

Note: Uiapplicationdidenterbackgroundnotification notifications are also sent so that the app is interested in this notification to know the current applied tangent to the background state. Objects in your app can register for this notification using the default notification hubs.

5. Foreground applications have higher priority than background applications when using system resources and hardware. In particular, when applying tangential background, the following points should be followed:

(1) Do not invoke anything in the app code for OpenGL ES.

(2) All Bonjour related services are canceled before the app hangs suspended. If your app does not turn off these and Bonjour related services, the system will automatically turn off these services when the app is suspended.

(3) in the network-based sockets application, the connection failure needs to be handled. When the app exits resume execution from the background, if you encounter sockets using errors, simply rebuild the socket connection.

(4) Save the application state before cutting to the background state. In the case of low memory alarms, the background app may be cleared out of memory to free up space. Applications in the suspended state are prioritized to clear memory and will not be notified before they are purged.

(5) When you cut back into the background, release any memory that is no longer needed. such as a large memory cache object (image), then cut into the front, releasing all references to these cached objects.

(6) Stop using the system shared resource before it is suspended. Applications that use system-shared resources, such as Address Book or Calendar Data, must stop using these shared resources before they are suspended. Your app has not stopped using these shared resources after it has been suspended, it should be killed.

(7) Avoid updating application windows and views. Although creating and manipulating windows and view objects in the background does not cause the app to be killed, you can defer the work until the app returns to the foreground.

(8) Respond to external attachment connections and loss of connection notifications. For applications that communicate with external attachments, a disconnection notification is sent when the application is tangential to the background state. The app must register this notification and use it to switch off the current attachment access session. When the app returns foreground, a matching notification is sent, giving the app an opportunity to re-establish the session.

(9) When you cut back into the background, clear the resources associated with the behavior warning. In order to save the application context between apps switching, the system does not automatically dismiss action sheets (uiactionsheet) and alert Views (Uialertview) when the app is tangent to the background. For apps running before the iOS4.0 version, action sheets and alerts are still dismiss out when exiting, so that the application's cancellation handler has the opportunity to run.

(10) Remove all sensitive view information when cutting back into the background. Views or windows with sensitive information must be hidden or removed because the system will snapshot the application interface and generate app toggle animations.

(11) The app performs the least amount of work when running in the background. The system is usually very limited in execution time for applications running in the background and for applications running in the foreground. If the app plays audio in the background or monitors location changes, the app should focus only on this task, and all unnecessary tasks should be deferred. Applications that perform too long in the background will be throttled back by the system or killed directly.

6, the memory use of the background application:

When the phone memory is about to run out, the system terminates applications that suspend suspended to reclaim memory. However, applications that consume a large amount of memory while running in the background background will be terminated first.

Here are some examples of objects that need to be recycled:

(1) Cached image objects

(2) relatively large multimedia files or data files that can be reloaded from disk.

(3) Any application that is no longer needed, and which can easily be recreated later.

To help your application reduce its memory footprint, the system automatically frees up many objects behind the scenes to support your application. For example:

(1) Release the backing store of all the core animation layers to prevent these layers from continuing to appear on the screen without changing the properties of the current layer. And does not release the Layer object itself.

(2) Remove all references to cached images. (If the app does not have strong references to these images, then they are then removed from memory)

(3) Release some other data caches that are managed by the system.

7, return to the front desk foreground

1) processing the notification queue when the application tangent forward station is awakened

If changes in direction, time changes, preference changes, and other behaviors or states that affect the appearance of the app, etc., the system sends these related notifications into the queue and sends these notifications to the app as soon as the app resumes foreground or background re-executes the code. To prevent the application from being overwhelmed by too many notifications because of excessive notification, the system merges events and only passes a single notification that responds to a network change since the app was suspended.

The specific notification consolidation rules are shown in the following table:

The notification queue is typically delivered before any touch events and user input to the main running loop of the application main run loops. Most applications should be able to handle these events quickly enough. However, if you find your app looks noticeably sluggish when recovering from the background, you can use instruments to determine whether the notification processing code is running and causing a delay.

An app will also receive update notifications for all views that have been marked as dirty since it was updated when it returns to the foreground. Apps running in background background can also call the Setneedsdisplay or Setneedsdisplayinrect: method to request a view update. However, because the interface is not visible at this point, the system merges the requests and updates the view only after the app resumes the foreground.

(2) calmly handle local changes

When the app is in a pending suspended state, if the user changes the current language setting, you can use the NSCURRENTLOCALDIDCHANENOTIFICATION notification to force any local sensitive information (such as date, time, Numbers, and so on) are updated. Of course, the best way to avoid local information-related event handling is to write code that updates the view in such a way that it is easier to update the view. Like what:

A. Use the Autoupdatingcurrentlocal class method to retrieve the Nslocal object. This method returns a local object that responds to local changes and automatically updates itself. So, you don't need to recreate it again. Then, when local information changes, your app still needs to refresh the view that contains the local information.

B. Re-create the cached date or number format object whenever local information changes.

(3) Response to Application settings change

If the app contains settings that are managed by the Settings app, the app should follow nsuserdefaultsdidchangenotification notifications.

8. Application termination

If the app will be terminated when it is running in the foreground or in the background, the system will call the app agent's Applicationwillterminate: method to save the user data or apply state information, the maximum run time is 5 seconds, the expired app is killed and the memory is removed.

Note: There will be no notification when an app in the suspended state is terminated. However, if the app is currently running in the background background, the system invokes the Applicationwillterminate: Method of the application proxy when the app is to be terminated. The app is not allowed to request additional background execution time in this method.

9. Main running loop main run loop

The UIApplication object installs the main run loop when the app starts and uses this loop to handle events and handle view-based interface updates. The main run loop is run in the app's main thread of the application. This ensures that all user events are executed serially in the order in which they are received.

When the user interacts with the app, the events associated with these interactions are automatically generated by the system and passed to the application via a special port set by Uikit. An event exists as a queue within the application and one is distributed to the application's main run loop to execute. The UIApplication object is the first object to receive an event, and determines how the event needs to be handled. Touch events are typically distributed to the application's main window object, and are eventually distributed to the view on which the touch event occurred. Other event passes may be slightly different from touch event passing through a variety of application objects.

There are many types of events that can be passed in an iOS app. The most common events are listed in the following table:

Most of these event types are passed through the application's main run loop, but some are not. For example: The accelerometer event is passed directly to the application of the specified accelerometer proxy pair image. For more information about how the system handles most types of events, including touch, remote control, motion, accelerometer, and gyroscopic events, see Event Handling Guide for IOS.

Some events, such as touch, remote control classes, are typically handled by the response object being applied. The response object exists anywhere in the app. (UIApplication objects, view objects, view controller objects, and so on are examples of response objects). Most events target a specific response object, but can also be passed to other response objects (with a response chain), for example: A view that does not handle any event can pass an event to its parent view or to a view controller.

The handling of events that occur on a view of the controls class (such as a button) and the processing of touch events that occur on other types of views are somewhat different.  Because there are only a very limited number of interaction behaviors that occur on the object of the control class, these interactions are repackaged into an active message and passed to the appropriate target object. This target-action design pattern makes it very easy to apply a control-type View object to trigger a custom code execution.

Reference article: http://blog.csdn.net/duanyipeng/article/details/7101829

IOS app life cycle

Related Article

Contact Us

The content source of this page is from Internet, which doesn't represent Alibaba Cloud's opinion; products and services mentioned on that page don't have any relationship with Alibaba Cloud. If the content of the page makes you feel confusing, please write us an email, we will handle the problem within 5 days after receiving your email.

If you find any instances of plagiarism from the community, please send an email to: info-contact@alibabacloud.com and provide relevant evidence. A staff member will contact you within 5 working days.

A Free Trial That Lets You Build Big!

Start building with 50+ products and up to 12 months usage for Elastic Compute Service

  • Sales Support

    1 on 1 presale consultation

  • After-Sales Support

    24/7 Technical Support 6 Free Tickets per Quarter Faster Response

  • Alibaba Cloud offers highly flexible support services tailored to meet your exact needs.