iOS 后台挂起+解决方案(长时间后台运行)

一个应用程序的生命周期分为好多种状态:应用程序失去焦点、应用程序完全获取焦点、应用程序进入前台、应用程序进入后台、应用程序关闭、应用程序被挂起等等。我们简单说一下,应用的前台状态、后台状态以及挂起状态。

前台状态:但应用程序处于屏幕的第一层,呈现显示的时候,就属于前台状态。

后台状态:当前app如果不是作为屏幕中的第一层,呈现显示给用户,那么此时app就是后台状态。
举例:
锁屏(包括:当前应用下锁屏、其他应用下锁屏、桌面锁屏)
用户在使用其他应用app2,当前 app1 虽然没有上滑kill掉,但是屏幕中的第一层显示的是app2, 那么app1就是后台了。

ps:下拉系统菜单 、上拉系统菜单,app并没有进入后台状态,只不过app失去了焦点罢了。

挂起状态:当前app后台状态,但是不一定挂起,挂起就是关于app的一切代码都不再运行了。
从测试实践来看,如果app进入后台状态,一般情况下是很快就会被挂起的,也就是进入后台状态后,里面代码运行马上就停止了。


如果需要在app进入到后台的时候,仍要继续运行,需要怎么办呢?

两种情况:
1、app进入后台之后,需要一两分钟继续一些特殊的操作,特殊操作完成之后才会被挂起。比如:app进入后台之后,上传用户使用的操作信息。
2、app进入后台之后,需要一直保持运行。比如:后台播放音乐。


一、创建后台运行任务(app会被延时挂起3分钟左右)

创建后台运行任务之后,app并不会被直接挂起,app会继续运行到该任务的结束时间,通过测试,该任务运行时间大约不到3分钟,也就175秒左右。(不过,这些时间对于一些简单的操作,也是足够了)

例:app进入后台之后,需要上传用户操作数据,上传完成之后,再让app挂起。

1、定义一个UIBackgroundTaskIdentifier属性,用于记录后台任务的id

@property (assign, nonatomic) UIBackgroundTaskIdentifier backgroundTaskIdentifier;

2、在-application:didFinishLaunchingWithOptions:方法中声明backgroundTaskIdentifier无效。

// 首先初始化backgroundTaskIdentifier
// 应用程序启动完成的时候就会调用AppDelegate的方法
- (BOOL)application:(UIApplication *)application didFinishLaunchingWithOptions:(NSDictionary *)launchOptions {
    // Override point for customization after application launch.
    NSLog(@"%s",__func__);
    
    // 初始化backgroundTaskIdentifier
    self.backgroundTaskIdentifier = UIBackgroundTaskInvalid;

    return YES;
}

3、在-applicationDidEnterBackground:方法中创建后台任务

// 当应用程序进入后台的时候调用
- (void)applicationDidEnterBackground:(UIApplication *)application {
    NSLog(@"%s",__func__);
    
    // 进入后台。若没有后台任务,创建后台任务。(如果有后台任务,不再创建后台任务)
    if (self.backgroundTaskIdentifier == UIBackgroundTaskInvalid) {

        // 但应用进入后台时,要求将用户的操作数据上传到服务器
        // 因为是上传用户数据,不要求特别精确。
        // 在本地记录上次上传的时候,如果两次上传时间不超过10分钟,则不需要上传。超过10分钟,才会上传。
        NSInteger lastDate = [[[NSUserDefaults standardUserDefaults] valueForKey:@"loadingDate"] integerValue];

        NSInteger nowDate = (NSInteger)[[NSDate date] timeIntervalSince1970];

        if (nowDate - lastDate > 600) {
            // 超过了10分钟,上传

            // 标记一个长时间运行的后台任务将开始
            // 通过调试,发现,iOS给了我们额外的3分钟(180s)来执行这个任务。
            // beginBackgroundTaskWithExpirationHandler一定要和endBackgroundTask方法对应才行。
            self.backgroundTaskIdentifier = [application beginBackgroundTaskWithExpirationHandler:^{
                // 后台任务到时间之后,会自动执行该回调。
                // 在该回调中要执行结束后台任务方法。
                // 如果操作提前完成,也可以手动结束后台任务。如果,手动结束后台任务,则不走改回调方法。
                [self endBackgroundTask];
            }];

            // 上传用户操作数据
            [self uploadUserActionDataWithFinished:^(NSInteger status) {
                if (status == 1) {
                    // 上传用户操作数据成功
                    // 删除存储的用户操作数据
                    
                    // 记录最新的用户操作数据上传时间
                    [[NSUserDefaults standardUserDefaults] setValue:[NSNumber numberWithInteger:nowDate] forKey:@"loadingDate"];
                    [[NSUserDefaults standardUserDefaults] synchronize];
                    
                    // 最后结束后台任务
                } else {
                    // 上传用户操作数据失败,不做任何操作,直接结束后台任务就行
                }
                
                // 结束后台任务
                [self endBackgroundTask];
            }];
        } else {

        }
    }
}

// 结束后台任务
- (void)endBackgroundTask {
    if (self.backgroundTaskIdentifier != UIBackgroundTaskInvalid) {
        // 每个对 beginBackgroundTaskWithExpirationHandler:方法的调用,必须要相应的调用 endBackgroundTask:方法。这样,来告诉应用程序你已经执行完成了。
        // 也就是说,我们向 iOS 要更多时间来完成一个任务,那么我们必须告诉 iOS 你什么时候能完成那个任务。
        // 也就是要告诉应用程序:“好借好还”嘛。
        // 标记指定的后台任务完成
        [[UIApplication sharedApplication] endBackgroundTask:self.backgroundTaskIdentifier];
        // 销毁后台任务标识符
        self.backgroundTaskIdentifier = UIBackgroundTaskInvalid;
    }
}

// 上传用户操作数据
- (void)uploadUserActionDataWithFinished:(void (^)(NSInteger status))finish {
    // 上传用户操作
    // 这里写了一个定时,30秒以后上传完成,结束后台任务
    dispatch_after(dispatch_time(DISPATCH_TIME_NOW, (int64_t)(30 * NSEC_PER_SEC)), dispatch_get_main_queue(), ^{
        if (finish) {
            finish(1);
        }
    });
}

PS:每个对 beginBackgroundTaskWithExpirationHandler:方法的调用,必须要相应的调用 endBackgroundTask:方法。这样,来告诉应用程序你已经执行完成了。

最后编辑于
©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 204,530评论 6 478
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 86,403评论 2 381
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 151,120评论 0 337
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 54,770评论 1 277
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 63,758评论 5 367
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 48,649评论 1 281
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 38,021评论 3 398
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 36,675评论 0 258
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 40,931评论 1 299
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 35,659评论 2 321
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 37,751评论 1 330
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 33,410评论 4 321
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 39,004评论 3 307
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 29,969评论 0 19
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 31,203评论 1 260
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 45,042评论 2 350
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 42,493评论 2 343