问题
I'm using the new background fetch mode in iOS 7, In my users' crash logs I'm seeing a lot of:
MyApp[11893] has active assertions beyond permitted time:
{(
<BKProcessAssertion: 0x176afef0> identifier: Background Content Fetching (3281) process: MyApp[11893] permittedBackgroundDuration: 30.000000 reason: backgroundContentFetching owner pid:33 preventSuspend preventThrottleDownUI preventIdleSleep preventSuspendOnSleep
)}
I assume I'm getting this because my update is taking longer than the permitted 30 seconds and is therefore being killed by the system. There's nothing I can do do ensure the fetch takes <30sec, as it's obviously dependant on many external factors.
Now, this seems like pretty reasonable behaviour - desired, even - but does it need to be crashing and polluting the logs? Should I be monitoring the [UIApplication sharedApplication].backgroundTimeRemaining and call my completionHandler early if I start to run low on time, or am I doing things correctly?
回答1:
A crash log sounds reasonable since the app is being killed by the OS.
If you want to avoid the crash and fail gracefully, yes, monitoring the backgroundTimeRemaining sounds like a good solution.
Since you are not going to complete the operation in time in any case is better to terminate it yourself, instead of getting killed by the OS.
回答2:
Per the Apple docs,
your app has up to 30 seconds of wall-clock time to perform the download operation and call the specified completion handler block
If you are downloading data using http or ftp you could look at using NSURLSession and associated classes to kick off the fetch and call the completion handler immediately, and then iOS will re-awaken your app when the download has finished.
来源：https://stackoverflow.com/questions/19622779/ios-kills-my-background-fetch-process-creates-unnecessary-crash-logs