1、标准写法
UIBackgroundTaskIdentifier backgroundUpdateTask;
long aa;
NSTimer *_timer;
- (void) didEnterBackground:(NSNotification *)notif{
aa = 0;
[self startTask];
}
- (void) startTask {
_timer = [NSTimer scheduledTimerWithTimeInterval:1 target:self selector:@selector(go:) userInfo:nil repeats:YES];
backgroundUpdateTask = [[UIApplication sharedApplication] beginBackgroundTaskWithExpirationHandler:^{
DDLogInfo(@"bgTask expiration=============");
[_timer invalidate];
[[UIApplication sharedApplication] endBackgroundTask:backgroundUpdateTask];
backgroundUpdateTask = UIBackgroundTaskInvalid;
}];
}
-(void)go:(NSTimer *)tim {
DDLogInfo(@"%@==%ld,%g ",[NSDate date],aa,[UIApplication sharedApplication].backgroundTimeRemaining);
aa++;
if (aa%10 == 0 || [UIApplication sharedApplication].backgroundTimeRemaining == 0) {
[LocalNotificationManager postLocalNotificationAlertBody:s];
}
}
文档上说有10分钟的执行时间，但从打印的backgroundTimeRemaining时间来看，只有180秒。
注意：测试此功能不能用Xcode直接debug运行，因为在调试器链接到app的进行的情况下，app是不会在后台被挂起的，也就是说即使backgroundTimeRemaining =0了，timer里的代码依然能够继续执行。
所以要测试运行态的情况，要么用文件日志(总是要导出比较麻烦)，要么用本地通知来查看。
2、是否能递归调用此方法来持续获得执行时间
在beginBackgroundTaskWithExpirationHandler里最后再递归调用[self startTask];
经尝试此方法无效，180秒超时后再次申请，会立刻回调超时的block，并且backgroundTimeRemaining时间一直都是0。
并且由于一直不停的在递归创建和终止后台任务，当Expiration真正到来的时候，一个还有一个创建的任务没有关闭。从而导致违背begin和end成对调用的原则，app被系统强制kill。所以此方法不但不能延长执行时间，还会导致app在180秒后台执行时间到达后，被系统kill的情况。
3、beginBackgroundTaskWithExpirationHandler多次被调用的情况
didEnterBackground每次调用都会触发beginBackgroundTaskWithExpirationHandler来创建新的后台任务，并用backgroundUpdateTask保存任务id，但如果第一次的任务还没有endBackgroundTask之前，应用回到前台，然后再次进入后台，就会重新创建一个新的后台任务，并且backgroundUpdateTask之前保存的id会被覆盖，这就违背了beginBackgroundTaskWithExpirationHandler与endBackgroundTask成对调用的原因。因为前一个后台任务超时的block回调的时候，其实是end了后一个taskId对应的后台任务，并且把taskId赋值为UIBackgroundTaskInvalid。而后一个后台任务超时的block回调的时候，taskId已经变成了null，对其进行end调用已经无效了，所以相当于没有成对调用begin和end，导致的结果就是：后一个后台任务超时的时候，app被系统强制kill。
所以每一次创建的后台任务都要有一个独立的变量来维护其taskId，如果只有一个后台任务，但是有重入的可能，那么应该在willEnterForeground回调中，把前一个后台任务进行endBackgroundTask操作，这样就不存在taskId被覆盖的问题了。或者是每次didEnterBackground的时候，检查taskId == UIBackgroundTaskInvalid，若不满足该条件，说明taskId已经引用了一个正在进行的后台任务，还没有完成，由于这个后台任务重进前台又切换回后台的情况下，backgroundTimeRemaining会被重置为180秒，所以在这种需求下，关闭前一个任务再重新建议一个相同的后台任务没有必要，所以应该直接
if(backgroundUpdateTask != UIBackgroundTaskInvalid){
return;
}
4、后台任务expiration后，app被系统kill的问题
按照文档里的说法，只要begin与end在真正expiration之前成对调用，就不会导致系统强制kill app，而是app从后台执行状态切换到suspend状态，但实际测试中，每次expiration之后，app都会被kill掉，根据是app从launch页面重新进入。但我在willTerminate通知里的回调中加了一个local notification，并没有触发这个本地通知。(从app switcher强制退出应用的时候会触发本地通知，说明本地通知有效)。只能认为是app从后台状态切换到suspend状态后，立刻被系统kill掉了，但不知道为什么会这样。
5、参考另一个文章中的实现，可以在任务结束后不被kill
参考http://www.cnblogs.com/lyanet/archive/2013/03/26/2983079.html
测试他这个写法是可以在endTask以后，app变成suspend而不是被直接kill，但我没找到跟前面写法有什么本质上的区别。
有三个不同点，依次排除一下。
① 在endTask里面把timer进行了invalidate处理。(测试无关，注释掉这部分代码依然可以)
② taskId使用的是属性而不是全局变量。(测试无关，替换成全局变量依然可以)
③ 使用了application delegate里面的回调，而不是notification center的通知。(把代码从AppDelegate移动到Controller里面用通知来回调)，竟然也好用。
把controller里的代码回退到初始状态再检查，还是会被系统kill掉，完全找不到两者之前有什么不同造成的。
最后，又恢复了。。感觉什么都没改，怎么好的完全不知道。
找到原因了！！！！
怀疑原因是某些其他地方开启的beginBackgroundTask没有被对应的end掉，找到在引入环信的时候，要求在ApplicationDelegate里做如下处理：
- (void)applicationDidEnterBackground:(UIApplication *)application {
[[EMClient sharedClient] applicationDidEnterBackground:application];
}
而在ApplicationDelegate里面begin和end正常是因为，用我写的applicationDidEnterBackground替换到了上面这段。
并且在正常和非正常关闭的现象做对比，当正常调用endTask的时候，Timer在收到Expiration的时候是会立刻被停止调用的。而异常的情况下Timer会继续调用直到被系统kill。所以怀疑是环信引入的代码没有做对应的begin和end操作。为了验证这个分析，通过swizzling UIApplication的beginBackgroundTask方法进行测试。
- (UIBackgroundTaskIdentifier )swizzling1 {
UIBackgroundTaskIdentifier taskId = [self swizzling1];
DDLogDebug(@"enter beginBackgroundTaskWithExpirationHandler:%ld",taskId);
return taskId;
}
- (void)swizzling2:(UIBackgroundTaskIdentifier) identifier {
DDLogDebug(@"enter endBackgroundTask:%ld",identifier);
[self swizzling2:identifier];
}
从日志结果看，begin了3次，id分别为1，4，6（6是我创建的）。end了4次，id分别是6，4，0，0。也就是说环信内部在end的时候不但搞错了对taskId的引用，很可能是用的同一个变量，创建id=4的时候覆盖了id=1的，关闭id=4的时候成功了，并且将id设置为UIBackgroundTaskInvalid == 0。而对应id=1的任务完成以后，关闭时执行了endTask:0，没有起到真正关闭的作用。于是再次等到真正expiration时再次关闭，依然是endTask:0，最终的结果就是还是没有关闭。到达时限以后begin和end没有成对调用，导致app被系统kill掉。
进一步研究，发现是环信的初始化中，在hyphenateApplication:didFinishLaunchingWithOptions:中已经监听了didEnterBackground和willEnterForeground的事件，并做了后台任务的处理，而application的对应代理里面再写一遍就会冲突，看来是文档不同步造成的问题。