Fw: [討論] 為何WP7比Android還順? 從設計概念說起

看板MobileComm (行動通訊)作者felaray時間12年前 (2012/12/09 14:58)推噓4(4推 0噓 11→)

留言15則, 5人參與討論串2/2 (看更多)

轉錄理由同上篇文章作者: felaray (<^)<) 看板: MobileComm 標題: Fw: [討論] 為何WP7比Android還順? 從設計概念說起時間: Sun Dec 9 14:58:41 2012 ※ [本文轉錄自 WindowsPhone 看板 #1EdRIrtj ] 作者: felaray (<^)<) 看板: WindowsPhone 標題: Re: [討論] 為何WP7比Android還順? 從設計概念說起時間: Wed Oct 19 01:17:38 2011 看大家討論的很熱烈很想修文來回應不過怕修到大家的討論XD 我這篇提供一篇翻譯過後的文章，來源是大陸的百度網。(以下資料應該是7.0的) 墓碑機制墓碑機制簡單定義墓碑機制是微軟Windows Phone 7手機操作系統中的一個程序運行規則。說簡單點，就是手機上一個任務被迫中斷時（如有電話打入），系統記錄下當前應用程序的狀態後，（像把事件記錄在墓碑上一樣），然後中止程序。當需要恢復時，根據“墓碑”上的內容，將程序恢復到中斷之前的狀態。這樣的一種機制就是“墓碑機制” 墓碑機制具體表現微軟在今年發布了全新的Windows Phone 7手機操作系統，但令人不解的是，WP7卻不支持多任務運行。據了解，WP7並不是嚴格的單任務，比如WP7中微軟自家的IE和ZUNE就能同時運行。首先來說一些WP7系統程序運行的基本規則，微軟不允許任何第三方應用程序在WP7的後台運行，特定時間內只有一個應用程序的在前台運行，如果你的應用程序沒有在前台顯示，就表示這些程序並沒有運行，這樣就不耗費運行內存和處理器資源。這樣做主要是為了延長電池續航時間，並保證響應一致的用戶體驗。但是所有的WP7手機都將配備返回按鈕硬件，這個按鈕除了有返回導航功能之外，還將支持應用程序之間的切換，比如當你在某個應用程序時點擊了裡面的網頁鏈接，然後調用內置瀏覽器進行查看，在查看完畢之後就可以按返回鍵重新返回剛才的程序。現在問題就出來了，當前的應用程序切換回之前的應用時，究竟是恢復了一個應用還是重新打開了這個應用呢？因為剛才已經說過了，WP7不允許後台運行程序，而兩者的區別就是，重新打開時不會保持剛才的使用狀態，恢復是可以延續使用狀態的，這就要說到微軟的墓碑（Tombstone ）機制了。墓碑是微軟為WP7切換應用程序狀態的一種處理機制，以使用過程為例，當用戶正在使用一個應用程序，比如游戲或者新聞閱讀，這時有電話打進來，來電提示和通話頁面將會在前台顯示，正在運行的遊戲就會消失，但是WP7不允許背景執行應用，這時候墓碑機制就會觸發，遊戲的運行狀態包括畫面、進度等等數據會凍結保存，相當於暫停，但是遊戲確實沒有運行，這也是墓碑名字的含義：應用程序已經死了，但是墓碑上記錄有臨終前的所有狀態。當通話結束後，遊戲操作系統會將應用程序進程重新啟動，並將狀態數據傳遞為應用進行恢復，這也相當於應用從墓地裡面爬出來，並按照墓碑上記錄的狀態進行還原。在程序代碼示例中，微軟給出了單個應用程序的運行狀態代碼，共有四個App.xaml.cs文件，這些直接關係到執行模式的代碼分別是Application_ Launching、Application_ Activated、Application_ Deactivated、Application_ Closing，分別是啟動、復活（激活程序恢復狀態）、停用（記錄墓碑數據）、關閉（徹底關閉）。開發者們需要注意的是，在開發過程中需要使用微軟給出的工具和相關代碼才能讓自己的應用支持墓碑機制，否則當用戶正在使用的時候突然一個電話過來之後就得再次手動打開程序重頭再來，這會讓用戶非常不爽。(原po:這真的讓人很不爽尤其是很多小遊戲很容易跳出要重玩) 在早期的WP7系統中，微軟並沒有在程序不運行的時候將進程徹底殺死，而是將其暫停，但是這種情況導致了後台運行堆棧的混亂， API和事件觸發經常會出現問題，所以微軟才決定使用墓碑機制。不過完全實行墓碑機制將會影響到電話的某些功能，比如短信、即時通信、天氣等需要時刻保持運行和更新的應用，微軟同樣給出了推送通知服務（Push Notification Services ）的API ，允許應用程序調用該接口保持實時更新。 --

推

KevinLomax

07/25 13:32,

07/25 13:32

→

w96284cn

07/25 13:36,

07/25 13:36

-- ※ 發信站: 批踢踢實業坊(ptt.cc) ◆ From: 61.62.70.141

推

james732

10/19 01:41, , 1^F