机会地获取少量内容

需要定期检查新内容的应用程序可以要求系统将其唤醒，以便它们可以启动该内容的提取操作。要支持此模式，请在Xcode项目的“功能”选项卡的“后台模式”部分中启用“后台提取”选项。（您也可以通过在应用程序的Info.plist文件中包含带有fetch值的UIBackgroundModes键来启用此支持。）启用此模式不能保证系统随时随地执行后台提取。系统必须平衡应用程序的需要，以便根据其他应用程序和系统本身的需要来获取内容。评估该信息后，如果有很好的机会，系统会给应用程序一些时间。

当一个很好的机会出现时，系统会将应用程序唤醒或启动，并调用应用程序委托应用程序：performFetchWithCompletionHandler：method。使用该方法检查新内容，并在内容可用时启动下载操作。完成下载新内容后，您必须执行提供的完成处理程序块，传递指示内容是否可用的结果。执行此块会告诉系统它可以将您的应用程序移回暂停状态并评估其电源使用情况。快速下载少量内容并准确反映内容可供下载的应用程序，将来可能会在未来获得执行时间，而不是需要很长时间才能下载其内容或声明内容可用的应用程序，然后执行不下载任何东西。

下载任何内容时，建议您使用NSURLSession类来启动和管理您的下载。有关如何使用此类管理上载和下载任务的信息，请参阅URL会话编程指南。URL Session Programming Guide.

使用推送通知启动下载

如果您的服务器在您的应用可用新内容时向用户设备发送推送通知，则可以让系统在后台运行应用程序，以便立即开始下载新内容。这种背景模式的目的是减少用户看到推送通知之后，您的应用程序能够显示相关内容之间经过的时间。应用程序通常在用户看到通知大致相同的时间唤醒，但仍然会给您更多的时间。

要支持此后台模式，请在Xcode项目的“功能”选项卡的“后台模式”部分中启用“远程通知”选项。 （您也可以通过在应用程序的Info.plist文件中包含带有远程通知值的UIBackgroundModes键来启用此支持。）

对于触发下载操作的推送通知，通知的有效载荷必须包含其值设置为1的内容可用键。当该键存在时，系统将在后台唤醒应用程序（或将其启动到后台），调用应用程序代理的应用程序：didReceiveRemoteNotification：fetchCompletionHandler：method。您执行该方法应下载相关内容并将其集成到您的应用程序中。

下载任何内容时，建议您使用NSURLSession类来启动和管理您的下载。有关如何使用此类管理上载和下载任务的信息，请参阅URL会话编程指南。

在后台下载书报摊内容

下载新杂志或报纸发行物的报亭应用程序可以注册在后台执行这些下载。您可以在Xcode项目的“功能”选项卡的“后台”模式部分中启用对报摊下载的支持。（您也可以通过将UIBackgroundModes键与应用程序的Info.plist文件中的报刊亭内容值相结合来启用此支持。）当此键存在时，系统启动您的应用程序（如果尚未运行），则可以开始下载新的发行物。

当您使用书报摊套件启动下载时，系统会处理您的应用程序的下载过程。即使您的应用程序被暂停或终止，系统仍会继续下载该文件。下载操作完成后，系统将文件传输到您的应用程序沙盒，并通知您的应用程序。如果应用程序没有运行，则此通知会将其清除并给予机会处理新下载的文件。如果在下载过程中出现错误，您的应用程序也会被唤醒来处理。

有关如何使用报刊套件框架下载内容的信息，请参阅报亭套件框架参考。Newsstand Kit Framework Reference.

与外部插件的通讯

使用外部插件的应用程序可以要求在应用程序被暂停时提供更新。这种支持对于定期传送数据的某些类型的附件（如心率监视器）很重要。您可以从Xcode项目的“功能”选项卡的“后台”模式部分启用对外部附件通信的支持。（您也可以通过将UIBackgroundModes键与外部附件值一起包含在应用程序的Info.plist文件中来启用此支持。）启用此模式时，外部附件框架不会关闭与配件的活动会话。（在iOS 4及更早版本中，这些会话在应用程序被暂停时自动关闭。）当新数据从附件到达时，框架会唤醒您的应用程序，以便它可以处理该数据。该系统还唤醒应用程序来处理附件连接和断开通知。

任何支持附件更新后台处理的应用程序都必须遵循以下基本准则：

应用程序必须提供一个界面，允许用户启动和停止附件更新事件的发送。那么该接口应该适当地打开或关闭附件会话。

醒来后，该应用程序大概需要10秒才能处理数据。理想情况下，它应尽可能快地处理数据，并允许自己再次挂起。但是，如果需要更多的时间，应用程序可以使用beginBackgroundTaskWithExpirationHandler：方法来请求更多的时间;它应该只在绝对必要的时候这样做。

与蓝牙配件进行通信

如果外围设备在应用程式被挂起时提供更新，那么与蓝牙外设配合使用的应用程式可能会被唤醒。这种支持对于定期传送数据的蓝牙-LL配件（如蓝牙心率传输带）非常重要。您可以在Xcode项目的“功能”选项卡的“后台”模式部分中支持使用蓝牙配件。（您也可以通过在应用程序的Info.plist文件中包含具有蓝牙中心值的UIBackgroundModes键来启用此支持。）启用此模式时，核心蓝牙框架将保持打开相应外设的任何活动会话。此外，从外设到达的新数据使系统唤醒应用程序，以便它可以处理数据。该系统还唤醒应用程序来处理附件连接和断开通知。

在iOS 6中，应用程序也可以使用蓝牙配件在外设模式下运行。要充当蓝牙配件，您必须从Xcode项目的“功能”选项卡的“后台”模式部分启用对该模式的支持。（您也可以通过在应用程序的Info.plist文件中包含UIBackgroundModes键和蓝牙外设值来启用此支持。）启用此模式可让核心蓝牙框架在后台简单地唤醒应用程序，以便它可以处理附件- 相关要求。为这些事件而唤醒的应用程序应该处理它们并尽可能快地返回，以便再次暂停应用。

支持蓝牙数据后台处理的任何应用程序都必须基于会话，并遵循以下基本准则：

应用程序必须提供一个允许用户启动和停止蓝牙事件传送的界面。那么该接口应该适当地打开或关闭会话。

醒来后，该应用程序大概需要10秒才能处理数据。理想情况下，它应尽可能快地处理数据，并允许自己再次挂起。但是，如果需要更多的时间，应用程序可以使用beginBackgroundTaskWithExpirationHandler：方法来请求更多的时间;它应该只在绝对必要的时候这样做。

在后台中得到用户的注意

通知是一种在应用程序被暂停时，在后台运行，或者不运行时使用户注意的行为。应用程序可以使用本地通知来显示警报，播放声音，徽标应用程序的图标或三者的组合。例如，闹钟应用程序可能会使用本地通知播放闹钟声音并显示提示来关闭闹钟。当通知发送给用户时，用户必须决定信息是否保证使应用程序返回到前台。（如果应用程序已经在前台运行，本地通知会静默地传送到应用程序，而不是用户）。

要计划本地通知的传递，请创建UILocalNotification类的实例，配置通知参数，并使用UIApplication类的方法进行调度。本地通知对象包含有关要发送的通知类型（声音，警报或徽章）以及发送的时间（如适用）的信息。UIApplication类的方法提供了立即或在预定时间发送通知的选项。

列表3-2显示了使用用户设置的日期和时间安排单个警报的示例。此示例一次只配置一个报警，并在安排新的报警之前取消上一个报警。（您自己的应用程序在任何给定的时间可以不超过128个本地通知活动，其中任何一个可以配置为以指定的间隔重复。）闹钟本身包括一个警报框和一个声音文件，如果应用程序播放在闹钟发生时不运行或处于后台状态。如果应用程序处于活动状态，因此在前台运行，应用程序代理的应用程序：didReceiveLocalNotification：方法被调用。

列表3-2计划警报通知

- (void)scheduleAlarmForDate:(NSDate*)theDate

{

UIApplication* app = [UIApplicationsharedApplication];

NSArray*   oldNotifications = [app scheduledLocalNotifications];

// Clear out the old notificationbefore scheduling a new one.

if ([oldNotifications count] > 0)

[appcancelAllLocalNotifications];

// Create a new notification.

UILocalNotification* alarm =[[UILocalNotification alloc] init];

if (alarm)

{

alarm.fireDate =theDate;

alarm.timeZone =[NSTimeZone defaultTimeZone];

alarm.repeatInterval =0;

alarm.soundName =@"alarmsound.caf";

alarm.alertBody =@"Time to wake up!";

[appscheduleLocalNotification:alarm];

}

}

与本地通知一起使用的声音文件与用于推送通知的声音文件要求相同。自定义声音文件必须位于应用程序的主包中，并支持以下格式之一：LinearPCM，MA4，μ-Law或a-Law。您还可以指定UILocalNotificationDefaultSoundName常量来播放设备的默认警报声音。当发送通知并播放声音时，系统还会在支持该设备的设备上触发振动。

您可以使用UIApplication类的方法取消计划通知或获取通知列表。有关这些方法的更多信息，请参阅UIApplication类参考UIApplication Class Reference。有关配置本地通知的其他信息，请参阅本地和远程通知编程指南。Local and Remote Notification Programming Guide

了解您的应用程序何时进入后台

支持后台执行的应用程序可能会被系统重新启动以处理传入的事件。如果某个应用程序由于用户强制退出以外的任何原因而终止，则当发生以下其中一个事件时，系统启动该应用程序：

对于位置应用程序：

系统会收到一个位置更新，以满足应用的配置标准进行传送。

设备进入或退出注册区域。 （区域可以是地理区域或iBeacon区域。）

对于音频应用，音频框架需要该应用来处理一些数据。 （音频应用程序包括播放音频或使用麦克风的应用程序。）

对于蓝牙应用程序：

在中央角色扮演的应用程序从连接的外围设备接收数据。

在外设角色扮演的应用程序从连接的中央接收命令。

对于后台下载应用程序：

推送通知到达应用程序，通知的有效内容包含值为1的内容可用密钥。

该系统有机会时会唤醒应用程序，开始下载新内容。

对于使用NSURLSession类在后台下载内容的应用程序，与该会话对象关联的所有任务都已成功完成或收到错误。

报亭应用程序启动的下载完成。

在大多数情况下，系统在用户强制退出后不会重新启动应用程序。一个例外是位置应用程序，在iOS8和更高版本被用户强制退出后重新启动。然而，在其他情况下，用户必须明确启动应用程序或重新启动设备，然后系统可以将应用程序自动启动到后台。当设备上启用密码保护功能时，系统在用户首次解锁设备之前不会在后台启动应用程序。

作为负责任的后台应用程序

前台应用程序在使用系统资源和硬件时始终优先于后台应用程序。在后台运行的应用程序需要为这种差异做好准备，并在后台运行时调整其行为。具体来说，移动到后台的应用程序应遵循以下准则：

不要再您的代码进行任何OpenGL ES调用。在后台运行时，不得创建EAGLContext对象或发出任何OpenGLES绘图命令。使用这些调用使您的应用程序立即被杀死。应用程序还必须确保任何先前提交的命令在移动到后台之前已经完成。有关在移动到后台时如何处理OpenGL ES的信息，请参阅在OpenGLES编程指南中实现多任务感知OpenGL ES应用程序。Implementing a Multitasking-aware OpenGL ES ApplicationinOpenGL ES Programming Guide.

取消任何Bonjour相关的服务，然后才被停用。当您的应用程序移动到后台，并且在它被暂停之前，它应该从Bonjour注销并关闭与任何网络服务相关联的监听套接字。暂停的应用程序无法响应传入的服务请求。关闭这些服务会阻止他们在实际上不可用。如果您不自己关闭Bonjour服务，系统会在您的应用程式被暂停时自动关闭这些服务。

准备好处理基于网络的套接字中的连接失败。由于任何原因，您的应用程序暂停时，系统可能会破坏套接字连接。只要您的基于套接字的代码已准备好用于其他类型的网络故障，例如丢失的信号或网络转换，则不应导致任何异常问题。当您的应用程序恢复时，如果在使用套接字时遇到故障，只需重新建立连接。

在移动到背景之前保存应用程序状态。在低内存条件下，后台应用程序可能会从内存中清除以释放空间。已暂停的应用程序首先被清除，并且在清除应用程序之前不会通知应用程序。因此，应用程序应该利用iOS6及更高版本的状态保存机制将其接口状态保存到磁盘。有关如何支持此功能的信息，请参阅保存应用程序在启动时的视觉外观。Preserving Your App’s Visual Appearance Across Launches.

移动到背景时删除对不需要的对象的强引用。如果您的应用程序维护对象（特别是图像）的大内存缓存，请移动到后台时删除对这些高速缓存的所有强引用。有关更多信息，请参阅减少内存占用。Reduce Your Memory Footprint

停止使用共享系统资源。与共享系统资源（如地址簿或日历数据库）进行交互的应用程序应在停用之前停止使用这些资源。这样的资源的优先级总是来到前台应用程序。当您的应用程式被挂起时，如果发现使用共享资源，该应用程式将被杀死。

避免更新您的窗口和视图。因为您的应用程序的Windows和视图在您的应用程序在后台时不可见，您应该避免更新它们。在您需要更新应用程序快照之前需要更新窗口的内容的情况下才是例外。

响应外部附件的连接和断开通知。对于与外部附件通信的应用程序，当应用程序移动到后台时，系统会自动发送断开通知。该应用程序必须注册此通知，并使用它来关闭当前的附件会话。当应用程序返回到前台时，会发送一个匹配的连接通知，给予应用程序重新连接的机会。有关处理附件连接和断开通知的更多信息，请参阅外部附件编程主题。External Accessory Programming Topics

清理移动到后台的活动警告的资源。为了在应用程序之间切换时保留上下文，当您的应用程序移动到后台时，系统不会自动关闭操作工作表（UIActionSheet）或警报视图（UIAlertView）。在移动到背景之前，由您提供适当的清理行为。例如，您可能想以编程方式取消操作表或警报视图，或保存足够的上下文信息以在以后恢复视图（在应用程序终止的情况下）。

移动到后台之前，请从视图中删除敏感信息。当应用程序转换到背景时，系统会收到应用程序主窗口的快照，然后在将应用程序转移到前台时，该窗口会简要显示。在从应用程序DIDEnterBackground：方法返回之前，您应该隐藏或隐藏可能作为快照一部分捕获的密码和其他敏感的个人信息。

在后台运行时做最小的工作。给予后台应用程序的执行时间比给予前台应用程序的时间量更加受限制。在后台执行太多时间的应用程序可能被系统限制或终止。

如果您正在实施背景音频应用程序或允许在后台运行的任何其他类型的应用程序，则应用程序会以常规方式响应传入的邮件。换句话说，系统可能会在您的应用程序发生低内存警告时通知您的应用程序。并且在系统需要终止应用以释放更多内存的情况下，应用程序会调用其委托的applicationWillTerminate：方法在退出之前执行任何最终任务。

选择退出后台执行

如果您不希望您的应用程序在后台运行，您可以通过将UIApplicationExitsOnSuspend键（值为YES）添加到应用程序的Info.plist文件中来显式退出背景。当应用程序选择退出时，它会在不运行，非活动状态和活动状态之间循环，并且不会进入后台或挂起状态。当用户按下“主页”按钮退出应用程序时，应用程序委托的applicationWillTerminate：方法被调用，并且该应用程序在终止之前清理并退出大约5秒钟并移回到不运行状态。

强烈不鼓励退出后台执行，但在某些情况下可能是首选。具体来说，如果背景执行的代码对您的应用程序增加了很大的复杂性，那么终止应用程序可能会更简单。此外，如果您的应用程序消耗大量内存，并且无法轻松释放任何内存，系统可能会迅速杀死您的应用程序，为其他应用程序腾出空间。因此，选择终止而不是切换到后台，可能产生相同的结果，并节省开发时间和精力。

有关您可以在应用程序的Info.plist文件中包含的键的更多信息，请参阅信息属性列表键参考。Information Property List Key Reference.