本文主要是看了WWDC 2013 – Session 204 – What’s New with Multitasking 做出的翻譯和總結。文字/視訊連結如下
該session主要講的是iOS7比iOS6在多工管理上新增了這些API.
- 後臺應用重新整理
- 遠端推送
- 後臺傳輸服務
iOS6的時候, 儘管你鎖屏了, 一些程式的後臺任務也會繼續執行直到完成.
iOS7的時候做了改進, 鎖屏之後手機很快就會進入睡眠狀態, 任務就會被掛起 但是, 當手機被喚醒了, 例如在看郵件的時候, 你的應用程式就能利用這些時間片去繼續執行後臺任務.
iOS7之後, 建議使用NSURLSession.
應用程式進入後臺後仍然有幾分鐘的時間可以處理任務, 但是這幾分鐘不保證是連續的. 也就是說有可能會被強行中斷, 例如記憶體不足的時候系統會殺死後臺應用程式.
新概念 :
App Switcher, app在進入後臺之前系統會先拍個快照, 這樣你在切換應用程式的介面就會看到退出時的app的介面. 這種行為為 : State Restoration
需要注意的是 : 在App Switch划走app在iOS6的時候只會停止app runnning(仍處於Background狀態), 而在iOS7則還會停止app running in the background. 所以現在一些使用到GPS或者實時位置更新的app在被划走之後這些功能就會停止執行, 你不會在後臺收到任何通知.
首先, iOS7新增的多工處理的API分為三大種
Background Fetch: 後臺獲取, 供進入後臺的app的能週期性地更新他的內容.Remote Notification: 遠端通知, 當你傳送一個很重要的通知時, 他能夠從後臺喚醒你的app. 例如即時通訊的訊息等Background Transfer Service: 後臺傳輸服務, 他允許在使用者離開你的app後(回到桌面)通過自啟動在後臺佇列中執行上傳和下載任務.
後臺應用重新整理
後臺應用重新整理能保證每當你的app進入onFocus狀態的時候使用者看到的都是最新的內容, 而不是他們之前退出時(舊)的內容.
使用用法 :
- 在info.plist中把
Background Fetch這個key新增到UI background modes中. - 設定後臺獲取的
minimum fetch interval, 最小時間間隔
12345678910- (BOOL)application:(UIApplication *)application didFinishLaunchingWithOptions:(NSDictionary *)launchOptions{/** 預設是UIApplicationBackgroundFetchIntervalNever.*/[application setMinimumBackgroundFetchInterval:3600];return YES;} - 當時間到了的時候, 你的應用程式將(launch/resume)呼叫以下方法. 你唯一需要做的就是實現這個方法, 傳送網路請求, 接收響應資料並重新整理UI.
123456- (void)application:(UIApplication *)application performFetchWithCompletionHandler:(void (^)(UIBackgroundFetchResult))completionHandler{// go to fetch your new content here// go to update UI here// 做完所有處理後一定要呼叫completionHandler block 告訴系統}
最小時間間隔
需要注意的是, 當你的應用是剛下載好的, 使用者還沒登陸時, 這個值應為never. 當使用者登陸之後, 這個值可以告訴系統, 讓系統在適當的時間間隔下啟動你的應用併發起網路請求並更新UI(例如更新使用者狀態資訊等). 當然, 如果使用者退出登陸了, 你應該設定這個值為never.
例如你設定了5秒鐘, 則代表app在退出到後臺執行的5秒鐘以內是不會呼叫該API的, 只有在5秒鐘之後才有可能去獲取資料. 也就是說, 應用在進入後臺後的interval這個時間段內是不會被喚醒的.
問題來了, 這有什麼用? 我肯定希望我的app任何時候都能自動更新然後每次使用者進入我app的時候顯示的都是最新的內容啊! 這麼想就太自私了, 因為使用者手機有電量, 流量等等各種限制. 例如, 抓取某幾個地區的天氣資料, 這是個很耗流量, 電量且耗伺服器資源的操作, 此時你不會想每隔1分鐘他就發起一個網路請求吧? 你會傾向於1個小時或者更長的時間去請求, 這能節省資源, 提高使用者體驗.
需要注意的是, 不應該把delegate方法中的completionHandler當做property儲存起來再呼叫, 而是應該通過方法傳遞待完成後直接呼叫. 因為當後臺重新整理同時出現兩次的時候, 第二次的block就會把第一次的block給覆蓋掉(假如是用property儲存的話), 那意味著第一次的block永遠無法被呼叫. 切記!
當iOS系統中同一時間有多個後臺獲取任務的時候, 系統就能在一個時間段內處理這些任務, 而不是零零散散地處理, 那會加大電池損耗. 但是一個時間段內的任務太多了也是會增大電量的損耗的.
更為牛逼的是, iOS系統做了如此的優化. 他用一個observer觀察使用者真實的使用習慣, 例如我每天早上7點鐘開啟簡書看文章, 每天中午12點開啟簡書, 每天晚上10點開啟簡書. 那麼系統就會記錄起這個模式. 之後就會盡可能在我開啟app之前就做好這個後臺應用重新整理的工作.
如果我們不需要後臺應用重新整理的服務, 可以自行在設定 -> 通用 -> 後臺應用重新整理裡關掉這個功能. 畢竟有時候我們真的電量不足了, 或是流量不夠用了…
遠端通知
當我發一個訊息給我朋友的時候, 實際上是我先發給蘋果的伺服器, 然後蘋果伺服器再下發給我朋友的裝置, 然後他才接收到訊息/彈窗.
另外, 還能發一個Silent Notification(不帶訊息的通知), 他會在後臺交付然後launch/resume你的app, 並執行一些你自定義的任務.
Silent Notification配置在這裡
使用方法 :
- 在info.plist中把
remote-notification這個key新增到UI background modes中. - 當你傳送一個遠端通知之後, app就會被launch/resume
12345- (void)application:(UIApplication *)application didReceiveRemoteNotification:(NSDictionary *)userInfo fetchCompletionHandler:(void (^)(UIBackgroundFetchResult))completionHandler{// do something here// remember call completionHandler block when finished work}
然而, 通知發得太頻繁的話, 你的裝置和蘋果的伺服器會限制你的傳送頻率. 蘋果的伺服器會先把你的一些通知先儲存起來, 過一會再推送給使用者.
後臺重新整理和遠端推送的區別
| 後臺重新整理 | 遠端推送 | |
|---|---|---|
| 內容重要性 | 有意思但是不太重要 | 需要立馬讓使用者知道的 |
| 頻率 | 非常頻繁 | 偶爾 |
| 例子 | 新聞, 社交, 圖片分享 | 即時資訊, 同步內容, 稍後閱讀 |
後臺傳輸服務
iOS7後支援後臺上傳/下載. iOS會把你的上傳/下載任務放在後臺傳輸服務佇列中, 當然與此同時你的app將會被喚醒, 以便處理任務執行過程中的任何突發事件, 並保證使用者能第一時間知道這些情況.
使用的是NSURLSession而不是NSURLConnection. 他可以用NSURLSessionConfiguration來自定義該session的策略, 例如是否需要快取, 超時等等. 顯然, 他也會launch/resume你的app.
|
1 2 3 4 5 |
- (void)application:(UIApplication *)application handleEventsForBackgroundURLSession:(NSString *)identifier completionHandler:(void (^)())completionHandler { // do something here // remember call completionHandler block when finished work } |
由於後臺傳輸服務是多應用並行的, 所以你要用盡可能少的時間去做UI更新操作(少於一分鐘), 同時也要保證CPU使用率不要太高. 用instrument中的Time Profile檢視執行時間, 優化讓CPU執行時間儘可能少.
一般來說人們會使用這個後臺任務API來關閉資料庫連線操作或者關閉控制程式碼或者其他系統資源.
資料保護
NSFileProtection
- completeProtection表示沒鎖屏的時候資料可正常訪問, 鎖屏以後資料全部不能訪問.
- None表示有沒有鎖屏都能正常訪問.
在database, SQLite database方面我們一定要用completeProtection以保證安全.
打賞支援我寫出更多好文章，謝謝！
打賞作者
打賞支援我寫出更多好文章，謝謝！
任選一種支付方式
