從安卓手機換到 iPhone 就想要改掉清理後台的習慣，查閲了一些資料，知道 iOS 後台機制不需要用戶介入，在使用中也實行了這一點，奈何心裏總有幽靈作祟，總是會感覺到不清理後台續航會降低，手機會發熱，進而管不住清後台的手。
Let me be as clear as I can be: the iOS multitasking bar does not contain “a list of all running apps”. It contains “a list of recently used apps”. The user never has to manage background tasks on iOS.
Fraser Speirs
在網上搜尋到的大部分中文內容會引用 Fraser Speirs 在他的一篇部落格裏很明確的指出的內容：iOS 的 Multitasking bar 實際上是 A list of recently used apps，所以，你不需要清理後台。但當我順藤摸瓜找到這篇部落格的原文時，卻發現這篇部落格發表時間在 2012 年。10 年過去了，這篇文章的內容自然是經不住滄海桑田，早已過時，情況早已發生了微妙的變化，蘋果早就加入了各式各樣的後台機制。這就衍生出了兩個問題，蘋果的後台機制是否真的會影響 iPhone 的續航和發熱？殺後台是否有助於提升使用體驗？
有趣的是，作者在某個時候關閉並存檔了他的部落格，在他的存檔裏卻並未出現這篇文章，這意味著作者可能刻意刪除了它。既然這種流傳已久的説法是基於一篇早已過時的文章，結果自然是不可信的，根據這篇文章得出結論，是一個不負責任的營銷號行為，我能做的唯有查詢更新的資料以及親身實踐。
查詢資料
Some apps perform work for a short time while in the foreground and must continue uninterrupted if they go to the background. Other apps defer that work to perform in the background at a later time or even at night while the device charges. And some apps need background processing time at varied and unpredictable times, such as when an external event or message arrives.
Apple Developer Docs
蘋果不會也不能一刀切死後台，相反，針對不同應用對後台執行的需求，蘋果舉了五種場景的例子。
Continue Foreground Work in the Background
Defer Intensive Work
Update Your App’s Content
Wake Your App with a Background Push
Request Background Time and Notify the User
為了用戶體驗，蘋果對應用的後台限制非常嚴格。針對這五種場景，蘋果設計了多樣且易於使用的 API 來滿足不同的需求，在預設情況下，當一個 App 進入後台時，系統會給 App 最多5秒的時間來進行回寫資料等操作，隨後系統便會將這個 App 掛起（Suspend），5秒的時間對於大多數 App 來説已經足夠。當 App 需要在後台完成更多操作時，可以蔘照蘋果給出的 5種場景設計 App 的後台策略。例如：一個新聞類 App 可以在收到新聞時被系統喚醒到後台接收這則新聞，呼叫application(_:didReceiveRemoteNotification:fetchCompletionHandler:)，App 便可以取得至多 30 秒的時間完成接收新聞的操作。同時，App 完成操作後必須要呼叫endBackgroundTask(_:) 以告知系統自己完成了操作。否則在超過30秒後，系統便會殺死（Kill） App 的程序。得益於 AppStore 嚴格的稽核，上架的 App 基本都經過了規範的編寫。
又例如：某網盤需要備份用戶今天新拍攝的照片，這是一個密集且工作量大的工作（不知道怎麼翻譯，原文是 Intensive Works），那麼呼叫BGProcessingTask以計劃一個備份工作，系統會自動根據用戶充電的時段、睡覺的時段等資訊訓練出來的模型自動選擇最佳的時段來執行計劃好的 Intensive Works。
Schedule these types of background tasks using
BGProcessingTask, and the system decides the best time to launch your background task.
如你所見，得益於蘋果給開發者提供的一套強大易用的 API 以及 AppStore 對於應用在上架前嚴格的稽核，iOS 的後台機制在保持對應用嚴格限制的情況下卻沒有增加開發難度，在開發文件裏，出現的最頻繁的一句話是。
The system decides the best time to launch your task.
蘋果將自己用心開發的優質 API 提供給開發者，這些 API 看似簡單，實則需要有大量的技術沉澱，看似簡單的“選擇最佳時間”，背後卻充斥着大量的機器學習演算法，既然開發者直接呼叫現成優質的 API 就能將用戶體驗提升幾個層級，那麼何樂而不為呢？在同一個開發者付出相同的工作量的情況下，開發 iPhone App 能夠實現同功能 Andriod App 高出幾個層次的質量，這也難怪早期 iPhone 在搶佔市場份額時，App Store 能夠在稽核如此嚴格，抽成如此高的情況下湧現大量優質應用。AppStore 裏應用呼叫後台的規範程度也就不必多言了。完全可以像谷歌一樣用1倍的努力把體驗做到90分，卻還是要花10倍的努力把體驗做到極致，這很蘋果。
殺後台是否有助於提升使用體驗？
我們已經知曉蘋果的後台機制是十分智慧的，可後台機制再智慧也依舊有失靈的時候。這就是第二個問題，殺後台是否有助於提升使用體驗？
可以説，除了能讓心裏更好受，以及可能在這幾個咖哩味十足的iOS版本提升滑動桌面的順滑度以外，殺後台無助於提升使用體驗，甚至會降低使用體驗。
滑動關閉後台應用程式可能會降低iPhone的續航時間，除非是無響應的情況，否則不應該強制關閉應用。
Craig Federighi
當應用程式被從“後台”劃掉，其會被移出RAM，這樣，應用程式將不會再執行。按照蘋果的邏輯，前面所提到的一系列智慧的後台機制都不會運作。不僅如此，重新從快閃記憶體載入APP會增加電量的消耗且徒增發熱，比從直接從RAM“解凍”APP更加費時。這麼一看，Craig説的是不是很有道理？是的，在Craig所處的環境裏，這句話絕對可以稱得上是“金玉良言”。
可惜在中國，情況有些許不同。第一種情況是流氓應用，以中國第一產品經理的微信為例，在之前很長一段時間裏（可能現在也是）微信會透過某種手段儘可能延長自己的後台存活時間，甚至於後台活動超過前台使用的時間。這自然會使耗電量增加。從後台列表，準確的説，是最近使用的應用列表強行殺掉微信，的確可以避免這種情況的發生。但微信在國內的地位不必我多説，從後台劃掉微信會大幅增加微信的啓動時長，每次開啓微信看到“連線中……收取中”轉圈轉個老半天可比耗電更煩人。再者，沒有人會希望為了省電而錯過女朋友或者上司只打一次的微信電話。這種時候，停用微信的後台重新整理可能是一個更好的選擇。
類似的情況發生在國內被牆的服務上，在沒有代理的情況下，除非開發者專門對此作過最佳化，國內被封鎖的服務、應用會出現一個較為尷尬的問題：按照計劃，這些應用需要更新內容，但因遭到GFW的封鎖，一直收不到伺服器的回應，於是一直執行，直到觸發系統的時間限制。前面已經提到過，這種情況下，APP會被系統“殺死”。對於第二種情況，解決方法有二：一是做好分流，24小時掛代理。二是和微信一樣，停用這些應用的後台重新整理。但無論如何，不要從後台直接殺死這些應用，因為直接殺死這些應用造成的體驗遠比耗電更糟。
寫個總結
在寫這篇文章時，我發現，越是寫下去，越是背離了寫這篇文章的初衷，即“提升使用體驗”。技術為人文服務，智能手機歸根結底只是我們手邊的一個工具，與其費盡心機省電，不如按照自己覺得舒服的方式使用手機。耗電也好，卡頓也好，都由技術的進步解決。我們可以因興趣使然研究這些技術問題，但絕不能讓這些技術問題成為我們生活的全部，放下手機，放下這些技術問題，我們還有很多更有意義的事可以做，很多人可以聚，很多地方可以去玩。
蔘考
題圖來自：https://www.macworld.com/article/667789/iphone-xs-review.html
評論已停用，直到您接受功能性 Cookie。