Windows Phone 7 墓碑機制

l_serein發表於2012-10-17
原文網址 : https://blog.csdn.net/l_serein/article/details/8080975
Windows

一個優秀的移動平臺需要意識到移動能力所帶來的諸如硬體限制一類的負面影響。相比於
桌面應用， 移動裝置有著更小的記憶體，更低的處理能力，受限的螢幕顯示以及受限的電池
容量。考慮到以上這些限制可以得到如下結論：在一臺非專注（多用途）的裝置上會有許多
應用程式執行，他們最終都會被關閉，這樣才能給其他應用程式騰出執行所需要的資源。

Windows Phone 用一種叫做“墓碑”的機制來處理這個問題。 儘管表面上看“墓碑”是一個非常
直白的命題， 但實際上在開發者中它是頗具爭議的。 有些人覺得它（墓碑）沒有存在的必要。
還有一些人說它太難了。剩下的一些人僅僅只是討厭“墓碑”這樣一個名字。然而，儘管有著這麼多的詬病
移動裝置的限制還是使得它（墓碑）成為了一種必須品，一款好的移動應用不得不跟“墓碑”打交道。

Windows Phone應用的生命週期

大多數 Windows Phone開發者第一次接觸到這個平臺的時候都會這麼定義一款應用程式的生命週期：
1.Start
2.Run
3.Exit
4.Go back to 1 and start again

Windows Phone 7重新定義了這樣一個生命週期，使得它更加的面向會話而更少的去程式導向。

在Windows Phone 7中 你應該這麼來考慮應用程式的生命週期

1.Start
2.Run
3.Interrupted execution or exit
4.If interrupted, come back-or, even if interrupted, start anew
5.If exited, start anew

這種面向會話的模型的好處在於：使用者在各個應用程式之間切換的時候不需要考慮作業系統是如何來管理
系統資源的。譬如說，使用者暫停遊戲去檢視一條簡訊的時候不會擔心繫統會直接終止遊戲程式。使用者期望
的是看完簡訊能夠繼續剛在正在進行的遊戲。如果這種機制工作的很完美的話，底層的機制就無所謂了。

當然這種機制也有它的負面影響，譬如說開發者要考慮更多的東西來保證會話（ session）的持續性，因為
這些會話（ session)依然執行在一個傳統的以處理為核心的作業系統上。 為了在這樣一個以處理為核心的
環境中容納多個會話，我們需要為會話定義一些邏輯狀態： Launched, Activated, Running, Deactivated,
Tombstoned以及Closed(or Ended);

圖1 展示的是 Windows Phone 7應用程式的生命週期。生命週期中的一些 event事件會在圖2 中給出，這些是
在 the Microsoft.Phone.Shell.PhoneApplicationService 這樣一個類中給出的。
 


                                             圖1Windows Phone 7的生命週期

                                              圖2 Application Lifecycle Events


墓碑狀態稍微複雜一點， 它跟PhoneApplicationService event並沒有直接的關係。當一個應用應用程式被deactivated，
作業系統並不會馬上終止這個應用程式的程式。理論上來說，作業系統只有在需要更多系統資源的情況下才會這麼做。
這時應用程式甚至都完全沒有察覺，它就這麼被赤裸裸的幹掉了。

當控制轉向另外一個應用程式的時候， Windows Phone 7會立馬殺死程式，但是千萬不要百分百指望這樣一個細節。
去年2月份的時候， 微軟已經在 Mobile World Congress上發表宣告稱：一些改進措施例如 Fast App Switching （快速
應用切換）就快面世了， 不要根據一些細枝末節的描述就斷定“墓碑”是否發生了。作為替代措施，我們應該做好準備，
在deactivation的時候做一些工作。

Deactivated vs. Tombstoned


一部手機同一時刻會有許多程式在執行（shell, phone and so on), 但是在統一時刻， 手機的前臺只應該有一個應用程式
（沒有應用程式執行的時候可以為0）。

當一個前端應用程式把控制權轉交給另外一個應用程式或者是作業系統元件本身的時候，它就被deactivated了。當一個
程式被deactivated的時候， 作業系統就會殺死程式，釋放相應系統資源。這個就叫做“墓碑”。

正如你所瞭解的那樣， “墓碑”並不總是在每一次應用程式被deactivated的時候就發生，但是如果發生了，“墓碑”一定是
緊隨一次deactivated事件發生的。事實上Deactivated是PhoneApplicationService在"墓碑"之前的最後一個動作，所以這
裡才是每次應用程式被重新啟用的時候你需要操作的部分。

圖3 展示了能夠導致deactivation的不同事件， 以及對墓碑是否發生了的一些猜測

                                                            圖3 Deactivation Tasks

有一些列的chooser不會立即觸發“墓碑”， 他們只會在使用者採取了一些特定操作的時候才會觸發”墓碑“。這些chooser
包括PhotoChooserTask(除非使用者指定了數量)， CameraCaptureTask, MediaPlayerLauncher, EmailAddressChooserTask
以及PhoneNumberChooserTask。
所有其他的choosers和launchers都會在呼叫show方法之後立即觸發“墓碑”。

想要看看Windows Phone 7應用程式生命週期的例項程式碼，可以登入LWP.TombStoning上下載相關程式碼。

Saving and Restoring State

基於會話的導航根本目的是為了讓使用者能夠在不同的應用程式之間實現無縫切換，你必須在Deactivated事件中儲存所有的
相關狀態，並且在Activated事件中恢復這些狀態。大多應用程式都有如下的三種狀態需要管理：

  • Persistent application state 
  • Session-specific application state 
  • UI- or page-specific state

* 持久應用程式狀態，必須要持久化，包括應用程式的設定引數，使用者資料等等
* 會話相關的應用程式狀態， 包括臨時狀態例如快取以及ViewModels，它們都需要在activation中進行儲存，但是在第一次執行
     應用程式的時候重新賦值
* 使用者介面或頁面相關狀態，當應用程式被activated的時候需要儲存在PhoneApplicationPage中。當墓碑觸發的時候Windows Phone 7
     有一個應用程式狀態的棧。在activation的時候，它會恢復在“墓碑”的時候的最後一個活動頁面。如果使用者按下Back按鈕，前一個頁面
     會被例項化。

相關文章