iOS 后台任务总结

首先Apple官方为我们准备了三类后台任务执行的场景:

1.Background Tasks：APP 在前台时启动某项任务，然后在未结束之前突然 切换到了后台，那么 APP 可以在切换回调里使用某些 API 来继续向系统请求一些时间来继续完成这个任务；完成之后通知系统，之后系统会将 APP 挂起；
2.Downloading/Uploading：在后台启动从网络下载/上传文件的任务 – 对于文件下载/上传，iOS 有专门的机制；
3.Specific Backgournd Tasks：应用需要在后台一直执行代码；

Background Tasks

Apple 文档建议，如果要启动一个后台任务（异步任务），可以使用 API beginBackgroundTaskWithExpirationHandler来指定，即使启动任务的时候，程序是处在前台的，也没有关系，当位于前台时，该方法请求得到的时间是DBL_MAX，也就是 double数据类型最大值，你可以认为是无限大，当任务执行过程中 APP 被切换到后台时，任务还没有完成，这个时间又会自动调整为一个时间片段（具体多少我没找到文档说明，都是说可以通过backgroundTimeRemaining属性得到）。需要注意的是， 这个方法是成对使用的，对于一个固定 task ，每次调用beginBackgroundTaskWithExpirationHandler，都会产生一个token 值(UIBackgroundTaskIdentifier实际是个整型)，必须在任务执行结束时，调用 endBackgroundTask 并传递这个token，来结束后台任务。另外，作为最佳实践，都应该传递一个 超时 handler，以防申请到的时间片段内，还是没能完成任务的话，做最后的清理和标注工作！如果不传的话，那么结果就是 iOS 直接 kill 掉你的APP，闪退.

下面是一段代码例子

// 在某处定义一个 token 变量
UIBackgroundTaskIdentifier _bgTaskToken;

// 进入后台 委派方法回调 
- (void)applicationDidEnterBackground:(UIApplication *)application
{
    _bgTaskToken = [application beginBackgroundTaskWithName:@"MyTask" expirationHandler:^{
        // 时间到了，任务还没完成，只能清理
        ...
        // 取消后台任务
        [application endBackgroundTask:_bgTaskToken];
        _bgTaskToken = UIBackgroundTaskInvalid;
    }];
 
    // 异步启动任务，这样不会阻塞 本委派方法回调
    dispatch_async(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0), ^{
        // 巴拉巴拉，做自己的任务
        ...
        
        // 任务在时间限制内结束啦，取消后台任务 
        [application endBackgroundTask:_bgTaskToken];
        _bgTaskToken = UIBackgroundTaskInvalid;
    });
}
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24

ios13新增了一个API模块:BackgroundTasks可以更轻松的管理后台任务,该框架区分了两大类背景任务：
应用程序刷新任务：短命的任务，使应用程序一整天都保持最新。
背景处理任务:用于执行可推迟的维护任务的长期任务 详细的API可参考BackGround Tasks

下面是一段代码例子

class AppDelegate: UIResponder, UIApplicationDelegate {

    var window: UIWindow?

    private let server: Server = MockServer()

    func application(_ application: UIApplication, didFinishLaunchingWithOptions launchOptions: [UIApplication.LaunchOptionsKey: Any]?) -> Bool {
        let feedVC = (window?.rootViewController as? UINavigationController)?.viewControllers.first as? FeedTableViewController
        feedVC?.server = server
        
        PersistentContainer.shared.loadInitialData()
        
        // MARK: Registering Launch Handlers for Tasks
        BGTaskScheduler.shared.register(forTaskWithIdentifier: "com.example.apple-samplecode.ColorFeed.refresh", using: nil) { task in
            // Downcast the parameter to an app refresh task as this identifier is used for a refresh request.
            self.handleAppRefresh(task: task as! BGAppRefreshTask)
        }
    
        BGTaskScheduler.shared.register(forTaskWithIdentifier: "com.example.apple-samplecode.ColorFeed.db_cleaning", using: nil) { task in
            // Downcast the parameter to a processing task as this identifier is used for a processing request.
            self.handleDatabaseCleaning(task: task as! BGProcessingTask)
        }

        return true
    }

    func applicationDidEnterBackground(_ application: UIApplication) {
        scheduleAppRefresh()
        scheduleDatabaseCleaningIfNeeded()
    }
    
    // MARK: - Scheduling Tasks
    
    func scheduleAppRefresh() {
        let request = BGAppRefreshTaskRequest(identifier: "com.example.apple-samplecode.ColorFeed.refresh")
        request.earliestBeginDate = Date(timeIntervalSinceNow: 15 * 60) // Fetch no earlier than 15 minutes from now
        
        do {
            try BGTaskScheduler.shared.submit(request)
        } catch {
            print("Could not schedule app refresh: \(error)")
        }
    }
    
    func scheduleDatabaseCleaningIfNeeded() {
        let lastCleanDate = PersistentContainer.shared.lastCleaned ?? .distantPast

        let now = Date()
        let oneWeek = TimeInterval(7 * 24 * 60 * 60)

        // Clean the database at most once per week.
        guard now > (lastCleanDate + oneWeek) else { return }
        
        let request = BGProcessingTaskRequest(identifier: "com.example.apple-samplecode.ColorFeed.db_cleaning")
        request.requiresNetworkConnectivity = false
        request.requiresExternalPower = true
        
        do {
            try BGTaskScheduler.shared.submit(request)
        } catch {
            print("Could not schedule database cleaning: \(error)")
        }
    }
    
    // MARK: - Handling Launch for Tasks

    // Fetch the latest feed entries from server.
    func handleAppRefresh(task: BGAppRefreshTask) {
        scheduleAppRefresh()
        
        let queue = OperationQueue()
        queue.maxConcurrentOperationCount = 1
        
        let context = PersistentContainer.shared.newBackgroundContext()
        let operations = Operations.getOperationsToFetchLatestEntries(using: context, server: server)
        let lastOperation = operations.last!
        
        task.expirationHandler = {
            // After all operations are cancelled, the completion block below is called to set the task to complete.
            queue.cancelAllOperations()
        }

        lastOperation.completionBlock = {
            task.setTaskCompleted(success: !lastOperation.isCancelled)
        }

        queue.addOperations(operations, waitUntilFinished: false)
    }
    
    // Delete feed entries older than one day.
    func handleDatabaseCleaning(task: BGProcessingTask) {
        let queue = OperationQueue()
        queue.maxConcurrentOperationCount = 1

        let context = PersistentContainer.shared.newBackgroundContext()
        let predicate = NSPredicate(format: "timestamp < %@", NSDate(timeIntervalSinceNow: -24 * 60 * 60))
        let cleanDatabaseOperation = DeleteFeedEntriesOperation(context: context, predicate: predicate)
        
        task.expirationHandler = {
            // After all operations are cancelled, the completion block below is called to set the task to complete.
            queue.cancelAllOperations()
        }

        cleanDatabaseOperation.completionBlock = {
            let success = !cleanDatabaseOperation.isCancelled
            if success {
                // Update the last clean date to the current time.
                PersistentContainer.shared.lastCleaned = Date()
            }
            
            task.setTaskCompleted(success: success)
        }
        
        queue.addOperation(cleanDatabaseOperation)
    }
}
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116

Background Downloading或者Uploading(后台下载或者上传)

这类后台任务，必须使用 iOS 指定的机制才可以，那就是 NSURLSession。使用 NSURLSession 建立的下载任务，会被系统直接在另外一个独立的系统进程里进行管理，不会因 APP 进入后台或挂起等而受到影响，iOS 会统一管理所有的下载任务。并且，即使你的 APP 已经挂掉啦，下载任务还是会继续，等到下载完成啦，系统会唤起你的 APP 进程，并通知你，但如果是用户主动杀掉的你的进程，那么系统会自动取消下载任务。
具体使用方法：

• 1. 使用 NSURLSessionConfiguration 类的 backgroundSessionConfigurationWithIdentifier 方法创建一个 NSURLSessionConfiguration 对象，参数为一个字符串，作为一个token ，完成时会用到，不能为空或 nil；
• 2. 设置上一步创建出的对象的 sessionSendsLaunchEvents 属性为 YES；(属性解释:当后台会话中的任务完成时，允许在后台恢复 或启动应用程序 或需要验证时。这只适用于使用+backgroundSessionConfigurationWithIdentifier创建的配置:默认值是YES。)
• 3. 如果开启下载任务时，是位于前台的，将 discretionary 属性也设置为 YES；(这个属性允是许根据系统的判断来调度后台任务，以获得最佳性能)
• 4. 设置你需要的其他属性值；
• 5. 使用配置好的 NSURLSessionConfiguration 对象，作为参数，创建 NSURLSession 实例对象；
     6，使用 NSURLSession 开始下载task，之后就是调用下载或上传Task代理方法,代理方法可以看 《URL Session Programming Guide》

如果在下载完成之前，你的APP已经挂起或者死掉啦，那么当系统完成下载之后，系统会唤醒你的 APP，并回调 你的 app 委托方法 application:handleEventsForBackgroundURLSession:completionHandler:，在这其中，参数会传进来一个 token，这个就是你第一步里 传入的 字符串，使用这个 字符串，再重新创建一个 NSURLSessionConfiguration，并进行与开始任务之前一样的配置，那么就可以使用这些对象来获取已经完成的任务的详细情况了。当后台下载或者上传任务完成之后会通过URLSessionDidFinishEventsForBackgroundURLSession这个代理方法来通知我们.

Background Long-Running Tasks

在 iOS 里只有特定的一些应用类型才会被允许可以在后台一直运行，APP 必须显式的声明一些特定权限，才可以在后台进行长时间运行而不被挂起。
一些应用类型有 6 种：

• 需要在后台播放音频 – 如 Music Player；
• 需要在后台录音；
• 在后台时也需要不断通知用户位置变动的，比如导航；
• 支持 VoIP 电话的 – 如 skype 网络电话；
• 需要在后台有规律的下载和处理网络内容的；
• 在后台有规律的从其他外设(第三方配件)获取并更新数据的；

要实现这些类型服务的 APP，需要进行专门的声明，这样系统才会采取相应的操作。

先来看看怎么声明。

声明后台服务类型

通过 XCode 的 project setting 里就可以配置类型，选择之后会自动 在你 工程的 Info.plist 文件里 增加 UIBackgroundModes 键值对；一个 APP 可以同时声明多种支持的后台长期任务类型，在 XCode 里勾选上即可；
下表给出了所有 在 XCode 可选的 类型 及 具体含义；

Playing and Recording Background Audio

一些典型的应用例子：

• 音乐播放软件
• 录音APP
• 支持 AirPlay 音视频播放的APP
• 网络通话软件
  当你在 Info.plist 里声明了 UIBackgroundModes 为 audio 的时候，在后台进行 audio 的相关操作时，系统 audio API 会自动阻止系统将你的 APP 进程挂起，所以不需要 APP 自己再进行其他额外的处理，只需要处理自己的软件逻辑即可。

注意：手机上是有可能会有多个 APP 同时拥有后台 audio 操作权限的，这时候系统会根据 每个 APP 开始操作音频时的 audio session 配置来决定如何进行操作，而且你应该非常小心的处理一些中断事件，如来电，其他系统提示音等，这些都有相关的 API 和机制，可以参考 《Audio Session Programming Guide》

Tracking the User’s Location

有三种方式来实现 位置的访问：

• The significant-change location service（这也是官方推荐的方式）
• Foreground-only location services
• Background location services
  前两种都不需要在 Info.plist 里声明 UIBackgroundModes ，只有最后一种需要。
  The significant-change location service ，字面理解，就是只有位置有变化时才会发出通知，有人说这个时机是依据基站，切换了基站时，就会发出一次通知，所以频率会受基站的密度影响，所以市区更新频率会比郊区高。但好处 是这个服务不管你的 APP 是在前台还是后台，不管是否已经被挂起，或已经死掉了，他都会唤醒你的进程进行相应处理，所以应该是最省电的。

后两种都是标准的定位服务，只不过一个只能工作在前台，而一个可以在后台工作；
注意：官方对于使用后台定位服务的 APP 审核是非常严格的，所以使用时一定要小心，并提供足够的说明和解释。
至于如何实现一个定位 APP ，请看 《Location and Maps Programming Guide 》

Implementing a VoIP App

网络通话软件，skype 就是其中一个。VoIP应用能够使用户通过互联网拨打和接听电话，而不是通过蜂窝移动网。VoIP应用严重依赖网络，打VoIP电话导致高的能耗就不足为奇了。当VoIP应用处于不活跃的状态时，不管怎样应用都应该彻底地空闲已到达省电的目的。
大致步骤：

• 在 Info.plist 里进行UIBackgroundModes配置；
• 创建一个VoIP证书。
• 配置VoIP推送通知。
• 处理推送。
  注意：更多关于VoIP推送通知的信息，具体实现请参考 PushKit Framework Reference

Downloading Newsstand Content in the Background

杂志应用，居然还有专门的处理。但我看介绍，跟前面讲解的 后台下载文件没啥区别啊！！另外好像也是用 通知推送 触发啊。About Newsstand Kit Framework

Communicating with an External Accessory

外设设备有很多，比如一些心率监控器，会在必要的时候向手机推送数据。声明了UIBackgroundModes 为 external-accessory 后，系统就不会主动关闭 APP 与 外设之间的连接，而是替 APP 监视这个连接，当有数据过来时，会唤醒 APP 进行处理，每次唤醒 APP 只有 10 S 种时间进行数据处理，所以应当越快越好，万不得已，如果10S不够，需要使用 beginBackgroundTaskWithExpirationHandler: 方法再申请一段时间进行处理；
【Note】：Apple 要求此类应用 需要提供一个 开启 和 关闭 连接的界面供用户使用；

Communicating with a Bluetooth Accessory

类似上一节的 配件，如果心率监控器跟 手机之间使用的连接方式是蓝牙，那么就一模一样啦，连 唤醒的时间限制都一样，都是 10 S！

Fetching Small Amounts of Content Opportunistically

有人依靠这种手段来实现后台永存，但现在不好使啦，除非你是真的每次都在下载东西，而且每次时间都很短。用户的流量啊。因为声明了这个 mode 之后，并不保证 系统一定会给你分配时间来执行后台任务，因为它自己有一套逻辑，如果你经常性唤醒，但却每次都耗时很久，又没有做从网络下载东西的操作，那么以后你被分配给唤醒的几率就会越来越小。另外还有审核！

正常情况下，声明了这个类型之后，系统在你的 APP 进入后台后，会间隔性的给机会将你的 APP 唤醒，并回调你的 委托方法application:performFetchWithCompletionHandler:，你需要在这个回调里检查是否有新内容可用，如果有，就开启后台下载，推荐使用 NSURLSession 来建立，下载完成后，你必须调用这个方法出入 的 completionHandler 并传入一个 整型值 来表示 你的处理是否正常，UI是否已经更新，让系统来决定更新 snapshot等；

Using Push Notifications to Initiate a Download

这个方式，是你的应用中包含通知功能时，你在服务端推送的通知内容里加入 键值对 content-available = 1 ，那么 手机收到这个通知后，会自动启动 APP 到后台，或 唤醒（依旧保持后台执行），并回调 委托方法 application:didReceiveRemoteNotification:fetchCompletionHandler: ，在这个方法里进行内容下载。
【Note】：需要服务端推送配合

哪些情况系统会唤醒挂起进程

当一些特定事件发生时，系统会唤醒已经被挂起的进程，转换到后台运行状态，这些事件针对不同类型的APP 有所不同：

1. location apps

• 系统产生了符合 APP 配置的定位要求的位置更新；
• 设备进入或离开了一个网络注册的区域，你可以理解为基站；

2. audio apps

• audio framework 需要 app 处理数据的时候–任何 播放、录制；

3. Bluetooth apps

• 当手机扮演中心设备时，收到了其他蓝牙设备发来的数据；
• 当手机扮演外围设备时，收到了蓝牙服务端发来的数据；

4. background download apps

• 本应用的一个包含 content-available = 1 的推送通知到达了手机；
• background fetch 类型，系统给予了 APP 唤醒的机会；
• 使用 NSURLSession 进行后台下载的APP，在下载过程完成或出现问题时，系统会主动唤醒对应 APP；
• 杂志应用，下载完成时唤醒 APP；

提示：绝大多数情况下，系统不会重启被用户手动强制关闭的 APP，但在 iOS 8 之后， location apps 是个例外。其他的所有被用户手动强制关闭的APP 都不会被系统主动唤起，直到 用户再次 主动启动这个 APP，或者手机重启并在用户输入了解锁密码之后才会恢复机制。

做一个尽责的后台APP

Apple 教育我们，如果你要实现一个后台 APP，应该做一个有责任的APP，不要乱搞。

• 不要在后台调用任何 OpenGL ES 接口，在进入后台之前也要保证这些调用都已结束，否则你的 APP 将直接被 kill；
• 取消所有 Bonjour 相关的操作，还不清楚这个是啥东西，不过 Apple 说即使你不取消，它在把你挂起之前也会都给你取消；
• 如果有网络操作，做好容错处理；
• 保存 APP 状态，进入后台前持久化一些数据，以便恢复；
• 尽可能多的释放内存，尤其是强引用；
• 停止使用共享的系统资源，比如 电话本，日历等，进入后台前，release他们；
• 不要在后台进行 UI 的更新操作；
• 做好对外设配件的 连接 和断开 事件的响应；这个是 外设编程的机制啦，需要 参考 External Accessory Programming Topics ；
• 关闭弹出窗口和弹出菜单等；
• 移除窗口上的一些敏感信息；
• 在后台的执行尽可能小的任务；