ios7 多任務

關於多任務，更新一：
@~~>~~：簡單地說 iOS 這一次的“真多任務”意思是“所有 app 都可以在一定情況下被喚起在後台進行一些任務”，
而不是“所有 app 切換到後台就停在那裡不走了”，不被喚起的 app 就算顯示在後台上也不會消耗電量，會被喚起的
 app 你就算殺了它在一定條件下它還是會被喚起執行背景工作。

發布會上用的例子是 Facebook——如果每天早上九點 check 一下 Facebook 更新的話，iOS 會學習使用習慣，以後就算
 Facebook 不在後台上也會每天九點之前喚醒一下更新最新資料，以便使用者開啟的時候不需要再等待更新，形成一種“Fac
ebook 一直在後台”的感受。

關於多任務，更新二：
@saraphines：iOS 7 中，應用程式的後台執行模型，新增了如下兩種類型：

1.fetch：如果應用程式需要從網路中有規律的下載新資料，那麼現在可以通過向系統註冊一下，使新資料的下載操作可以
週期性被喚醒或者啟動以在後台進行下載。註冊方法為：在程式的 Info.plist 中，將 UIBackgroundModes 索引值設定為
fetch，然後在 app delegate 中，使用方法 setMinimumBackgroundFetchInterval: 來設定下載新資料操作之間的最小
時間間隔。另外，必須在 app delegate 中實現 application:performFetchWithCompletionHandler: 方法以執行任意的
下載。

2.remote-notifaction：在 iOS 7 之前，程式中使用的推播通知是用來給使用者推送新的訊息，而有新的訊息到達時，如果
需要獲得訊息相關更多內容時，還需要使用者啟動相應的程式，以在程式中擷取新的訊息內容，而現在在 iOS 7 中，通過推
送通知，可以啟動一個後台下載操作任務。要使用這種模型，只需要將程式 Info.plist 檔案中的 UIBackgroundModes 鍵
值設定為 remote-notification，然後在 app delegate 中實現 application:didReceiveRemoteNotification:fetchComp
letionHandler: 方法。

無論是 fetch 或 remote-notification 後台執行模型，在適當的時機，都有可能被啟動或者從休眠（suspended）狀態轉
移到後台狀態。就拿 fetch 後台模型來說，系統會根據當前可用的資訊來來決定啟動或者喚醒程式的最佳時機。例如，當
網路條件不錯，或者裝置已經被喚醒的時候，會啟動或喚醒程式以執行程式的 fetch 後台操作。再來看看 remote-notifi
cation 後台執行模型：當有一條新的推播通知到達裝置時（在通知使用者之前），程式可以先去下載新的訊息內容，當內容
都準備好之後，就可以通知使用者了。可見，對於 remote-notification 後台執行模型，可以讓使用者把注意力都集中在內容
上，這也符合本文開頭提到的 iOS 7 設計重心。

關於多任務，更新三：
@mayokaze：iOS 7 中的 app 分為四種後台模式，需要注意的是無論哪一種都需要 app 本身實現相應的後台介面。

level 1：無後台僅有推送 － 參考 iOS 3.x。

level 2：墓碑式後台 － 現場還原，即所謂的偽多任務，絕大多數 iOS 4 以後的 app 是這種後台模式。

level 3：由系統智能調度的後台 － iOS 7 新增的 background fetch。

keynote 上著重講過的根據使用者行為自動調整達到效率最優的後台模式，用於處理不是很有時效性的資訊擷取，例如 sns，
新聞類應用的後台更新等，系統會根據使用者啟動應用的頻率和時間以及當前的網路和電量情況來智能分配每個應用的擷取頻
率和時間，資料重新整理是統一的，即系統可以在一個進程內擷取多個應用所需的資料而不是一個應用一個進程（類似統一的推
送機制，都是為了省電），開發人員不能確定資料會在何時被更新所以這個 api 只能用於處理非敏感資訊。

level 4：真後台

但此真後台非 Android 和傳統案頭 OS 的真後台，為了讓使用者免於進程管理仍然有多種限制，大致分為圖中幾種模式

其中 2345 跟 iOS 4 時代基本沒變化，audio 和 VoIP 是真正意義上的多任務，Newstand 是定時更新，location 則是由系
統統一管理。

在前面提過，我認為 iOS 7 不能算真後台因為使用者和開發人員都不能預測何時被系統調度。

Task Completion 是 iOS4 就有的一個通用後台介面，可供任意類型的 app 使用，其限制是只能後台運行 10 分鐘。iOS 7

對其作出的改變是原本的 10 分鐘是連續的 10 分鐘，既是說即使在這 10 分鐘內使用者關閉了螢幕或是時間到自動關屏了系
統也不會進入休眠狀態而是等待 10 分鐘後台運行完畢；新的系統則會正常休眠，將剩餘的後台時間留到使用者下一次喚醒裝置。

這樣背景已耗用時間仍是 10 分鐘但不再是連續的。這樣做的好處是省電，打個比方現在很多詞典帶後台複製選詞功能，實際
上就是用了 task completion，這樣一旦使用者開啟一次詞典並退出就意味著裝置至少 10 分鐘沒法進入休眠狀態，對電量是很
大的消耗，iOS7 以後該休眠照樣休眠，並且下次你喚醒裝置後台取詞還在。

Remote Notification 是本次較大的一個改進。以往 IM 類應用接受推送後點進去需要再收一次資訊的情況將不複存在，推送
將能夠直接啟動背景工作，具體的時限我還沒仔細看。

值得注意的是 Remote Notification 支援 silent notification，這樣 dropbox 這類同步應用可以在後台以最節能的模式實
時靜默同步了，類似布卡漫畫這種也可以推送正在追的漫畫的新章節並在後台靜默下載，待到下載好再給使用者發送一個本地推
送，使用者點開即看無需再連網。

關於 background fetch 和 remote notification 的適用情境官方給出了參考。

background transfer service – iOS 有史以來最接近傳統多任務的後台介面，可供任意類型的 app 調用，無時間限制。應
用情境包括後台上傳和下載資料，這使得遊戲後台更新資料包，後台上傳視頻等等都成為可能，但是正如其名字，它只能用於
處理上傳下載這種傳輸類的任務，類似後台剪下板監控這種它就無能為力了。

組合－實際應用情境中靈活組合多種後台模式可以實現傳統多任務的絕大多數應用模式而無需使用者插手進程管理，例如一個地
圖類應用可以開啟 location 服務，當檢測到使用者進入一個新的城市後開啟一個background transfer service 下載該城市的
資料包。又比如， remote notification 可以和 background transfer service 組合實現訂閱的電視劇甚至電影后台靜默更
新。