隱藏在 iOS 4 多工處理背後的真相

今年四月，Apple 為了 iOS 4 特別召開了一個發表會 (當時還是稱作 iPhone OS 4)，發表這個號稱 "最先進" 的移動裝置作業系統。其實這也沒什麼好奇怪的，因為新版作業系統的確可以是非常大的變革，其重要性不亞於新硬體的發表 (雖然新硬體的發表比較會引人注目就是了)，以我個人來說，我酷愛軟體勝過硬體，這種發表會我反而比較喜歡。 :P

在 iOS 4 的所有新功能中，最受重視的一個就是多工處理，而這也是最具革命性的一個新功能。其實，說其 "革命性" 是有點誇張，別的手機作業系統早就有了，iOS 到了第四版才推出，拖延了這麼久，還有什麼競爭力呢 ? 又為什麼會拖這麼久呢 ? 原因在於 "多工處理" 功能本身的獨特性質。

1. 多工處理真的是必要的嗎 ?
這個問題一直是很多人沒有搞清楚的一點，想說在電腦上，同時執行 N 個程式是司空見慣的事，iOS 居然不行 ??!! 於是就跟著其他人一起叫囂。事實上，在手機等移動裝置上，它的重要性並不等同於一般電腦的作業系統，甚至可以說沒有也沒關係。我以下列幾點才分析一下 :

1. 螢幕大小及移動需求 : 試想，在手機 (或 iPad 等移動裝置) 這麼小的螢幕上，使用者一次會想做幾件事 ? 我保證九成以上的人一次只做一件事，而這一件事就是開啟一個 App，然後專心地使用，頂多是加聽音樂而已 (這一點我稍後會說明)。所以，就算有多工也沒什麼意義，因為使用者無暇使用別的 App，更別提他們極有可能正在移動中，走路時看路比較重要吧 ? 除非你不怕撞到東西。想當然耳，iOS 上的程式都是以全螢幕開啟，除了是螢幕已經夠小之外，另一個原因則是不會有人瞇著眼睛。在那裡點選工具列切換視窗。
2. 電力及效能問題 : 在 iOS 4 發表會中，Steve Jobs 清楚地講了多工處理的最大缺點，即為電力及效能。移動裝置的生命就是電池，當有 App 在背景運行的時候，會不斷地佔用 CPU 資源以及記憶體空間，以致於會讓其他 App 的效能降低，而且持續消耗電池的電力。或許會有人說 "阿那是使用者自找的阿 !! 誰叫他們自己要開這麼多 App !!! 何必為了這個就不開放其他使用者使用多工處理呢 ?" 重點是，大多數的使用者會知道這種事情嗎 ? 若直接開放多工，他們只會感到 App 跑得很慢、一天到晚當掉，玩個兩三下就沒電了，最後得出一個 "iPhone sucks" 的結論，這是 Apple 絕對不允許的。
3. 多工的選擇性 : 這一點就是 iOS 4 對多工處理下的功夫，詳細內容留到下一段再說，主要的概念就是 "真的每個 App 都有多工的必要及價值嗎 ?" 比如說我在 PC 上玩個遊戲，玩到一半想休息，就先暫停，然後上網收個信，但是在收信的時候，遊戲依然在跑。這是多工沒錯吧 ? 但這其實是系統資源的浪費，因為 CPU 及作業系統必須不斷分配時間給一個根本沒人操作的程式，它只是無謂地浪費電而已。同理，其實很多 App 根本不需要有多工處理的能力，這跟該 App 的特性有關。其實在 iOS 4 之前，並非完全沒有多工處理的能力，只不過是 iOS 只開放給自家的 App 使用而已，比如說 Safari 在關閉後，會記錄關閉前所瀏覽的頁面 (不是只記錄網址)，而 iPod 的音樂播放功能也可以在背景執行。

2. iOS 4 跟其他手機作業系統的多工處理有何不同 ?
在 iOS 4 發表會中，Apple 花了很大一番工夫去解釋多工處理的細節。原因在於 "真正的多工" 有著續航力及效能的問題。故 Apple 限制住 iOS 4 的多工處理，只准許下圖七種功能可以在背景執行 :

1. 背景音樂及定位 : 簡單的說就是幾個自家 App 的延伸，背景音樂讓其他 App 也能在背景播放音樂，發表會時舉例的是 Pandora (類似 KKBox 之類的串流音樂服務)，而我最近發現 Aweditorium 也可以在背景播放音樂 [1] !! 實在很讓人興奮；背景定位功能則是將網路地圖的定位能力，推廣至第三方 App，讓 iDevice 變成 GPS 導航機 (不過我沒有含 3G 的 iDevice，所以用不到就是 :P)
2. Voice over IP (VoIP) : 就是紅遍半片天的網路電話，發表會上舉例的當然是最紅的 Skype，而 Apple 開放這部分的 API 之後，其他的 App 也可以使用這個功能，比如說最近很熱門的 Viber，也是用了這方面的技術。
3. 推播 : 這個功能在之前的 iOS 版本就有了，藉由外部伺服器發出通知給 Apple 的伺服器，之後再由 Apple 伺服器發出通知給 iDevice。此類功能大多用在即時通訊或信箱類的 App，由於開啟推播時 App 本身並沒有在執行，故可以節省 App 在背景連線執行所損耗的部分電力 [2]。可是以往的推播需要網路連線，實在是繞了一大圈，又容易受連線品質的影響，故 iOS 4 加入 "區域" 推播的功能，讓 App 自己可以在某些情況下自己送出通知，比如說如鬧鐘一般，到了某時間就自動送出通知，這樣不僅更省電，而且更有效率。
4. 程序的完成 : 簡單的說，就是將檔案上傳等程序丟到背景執行，完成後就停止。這裡有個很有趣的一點，就是 "task" 包含的範圍有哪些 ? 由於我沒有看過 iOS 4 SDK，故不清楚，但是大量影片或照片的上傳應該是最常見的此類應用了，一般在桌面端 OS 裡會 "放著給電腦跑" 的吃重工作 (如轉檔、燒錄光碟 .... 等) 都不太會出現在 iDevice 上，畢竟移動裝置的訴求就是快，而且續航力好。這部分最可能遇到的另一種情形大概是網頁的讀取吧，我是否可以放著 Safari 或 App store 等需要網路連線的 App 在背景慢慢跑完再回去看呢 ? 答案是不行 !!! (我實際測試過) 看來真的只接受某些特定的服務而已，而且該開發者還必須為了該功能去改用 iOS 4 的新 API 才行。
5. 程序的背景凍結 : 若照字面翻譯應該是 "快速的 App 切換"，不過就是意指用 Home 按鈕退出 App 後，不會直接關閉，而是凍結在背景，此時該 App 的一切狀態都被儲存著，就像影片被按下暫停鍵那樣。之後，使用者可以任意執行其他的 App，若想回去執行被凍結的 App，只要到 iOS 4 的多工處理工具列裡點選，就可以快速地切換回之前執行到一半的 App，而且是從凍結前的狀態開始。說到這裡，應該有人發現 iOS 4 的多工處理分為兩種，其一是上述幾點的特定服務，它們可以實際地在背景執行；另一種並非在背景執行，只是將當時的狀態凍結在背景，不使用任何的 CPU 資源，而事實上大部分的 App 都屬於這種。

大致上可以如上述整理成五點。可能會有人覺得，這樣哪裡夠 ? 你看人家 Android 跟 WM，想在背景裡怎麼跑就怎麼跑，iOS 也太小氣了吧 ? 重點在於，有多少種程序是真正需要在背景執行的 ? 由於移動裝置的螢幕小，一次大概只能控制一個 App，其他的 App 根本不必在背景執行，因為使用者根本沒在使用它們。如果是真正需要在背景跑的程序，其實差不多就是 iOS 釋出的那幾種服務 : 背景音樂、背景定位、VoIP .... 等，其它的程序就冷凍在背景裡吧，使用者只要能快速返回退出時的狀態，不要每次都重來就夠了。

相較之下，其他主推多工的手機 OS，啥東西都可以在背景跑，其實大多是浪費電，前幾代的 Android 版本為了主打多工，甚至讓 App 難以關閉，全部丟到背景執行，使用者還要去下載 "Task Killer" 這個 App 去關閉其他執行中的 App，在我看來實在有點本末倒置的感覺 [3]。

3. iOS 4 的多工有何缺點 ?
這也沒啥好講的，主要就是限制太多嘛 !!! 雖然 Apple 很努力地尋找 "多工" 與 "續航力 & 效能" 間的平衡，但這是沒有正確答案的，可以不斷地試圖改進。比如說，就我在上一段提到的 "程序的完成"，若能在背景完成網頁等網路服務的讀取，似乎蠻不賴的，反正都是完成了就凍結 + 斷線，沒理由只留給檔案上傳這樣簡單的服務 (當然也許還有別的服務可以使用，但我這裡沒有相關的情報)。

而關於 iOS 多工的諸多限制，其實還有一項很重要的應用尚未被允許，就是 App 的聯合使用，比如說使用者不能在 Mail App 裡內嵌其它的文書編輯 App；此外，最有名的例子就是 iAcces 中文輸入法，不能跟其他 App 聯合使用就毫無意義，只能用 JB 破解去執行。Apple 對此非常嚴格，只允許 iAcces Clipboard 這個剪貼簿上架，可是用過就知道，只能用剪貼的方式輸入中文實在做不了什麼事。Apple 有可能是基於 App 的穩定性而不允許第三方 App 的連動 (畢竟 iOS 是 App 取向的 OS，跟一般檔案取向的 OS 不同)，但是期待能像多工處理一樣，以加上限制的方式漸漸開放。

另外，有蠻多人抱怨多工處理工具列沒有組織性。換句話說，就是它沒有把真正在背景執行的 App 跟單純凍結在背景的 App 分開。而 iOS 4 預設不會在 App 用 Home 鍵退出後關閉它，全部都會丟到背景，所以使用 iDevice 沒幾分鐘就可能有一大堆 App 在多工工具列裡，此時要去找正在背景執行的 App 的確是一件麻煩事。

不過最令我在意的是，App 被凍結在背景後是儲存於記憶體中，其實這也會耗電 (雖然遠不及 CPU 持續運作所耗的電量)，而 iOS 4 會將所有被退出的 App 都丟到背景，時間一久將造成記憶體的空間被佔滿，降低其它 App 的執行效能及穩定度。雖然 iOS 4 會控制記憶體的使用，一但不夠就會關閉某些被凍結的 App，但是它會關哪些呢 ? 有沒有先後順序 ? 何時關呢 ? 非得要撐到讓執行的 App 會當掉才關 ? 這些都還有很大的不穩定性及改進空間，希望下一版能加入讓 App 可以退出即關閉的 API，或是將所有未加入多工的 App 直接賦與這種特性 [4]。

======================

多工處理這種看似理所當然的功能，在行動裝置領域裡居然變成一門很深的學問，可見一些司空見慣的事並不是永遠都是如此，還是要考量當時的狀況再做判斷。而對於 iOS 多工處理的批評也讓我更加堅定自己嘗試的重要性，不動大腦就人云亦云很容易做出讓人啼笑皆非的蠢事。


附註
1. 像 Aweditorium 這一類的社交 / 新聞 / 資訊軟體在 iPad 上非常流行，最有名的就是 Flipboard，另外，Pulse News 也是頗受好評的一個 App，這種彙整資訊的平台跟 iPad 簡直絕配，讓 iPad 成為最好的行動資訊載具。這裡有一篇文章將 Aweditorium 比喻為 "音樂版的 Flipboard"，受歡迎的程度可見一般。
2. 當然推播還是有在背景執行 "被動" 性的連線，雖然較為省電，但是若無需求，還是關掉比較好，畢竟積少成多也是很恐怖的。
3. 有趣的是，由於 Android 的分裂性，很多手機根本不能更新到新版 Android，所以這種舊版的餘毒能影響的人更多，時間也更長，這跟 iPhone 就差很多了。
4. 這裡的 "未加入多工" 並非是不使用特定的多工服務，而是根本沒有編譯成 iOS 4 版本的 App，比如說我之前在 "iPad 實機體驗" 一文裡分享的 "英漢字典 EC Dict 繁體版" 就是一個活生生的例子。它根本沒有更新過，當然也沒有改版成 iOS 4 的版本，而這樣會有什麼現象呢 ? 就是即使將它凍結到背景，切換回來之後還是跟重新啟動沒兩樣，這種程式在退出後乾脆直接關掉算了。