[轉錄] 為何WP7比Android還順? 從設計概說起

看板FCU_EE97A作者 (忘了回憶忘了忘記)時間12年前 (2011/10/19 16:51), 編輯推噓0(000)
留言0則, 0人參與, 最新討論串1/1
偷渡一下這篇文章... ---------------------------------------------------------------------------- 作者 felaray (<^)<) 看板 WindowsPhone 標題 [討論] 為何WP7比Android還順? 從設計概念說起 時間 Tue Oct 18 23:53:46 2011 ─────────────────────────────────────── 不論在座使用何種手機、搭載哪種作業系統,想必都對Windows Phone7時有所聞。 有些流言指出使用者跑去試用WP7,真的很順,跟iOS不惶多讓。但也有另一派的會反駁 "程式又不多"。 所以到底傳聞是真是假?到底WP7的速度是否和app的數量有關呢? 曾經版上有人是原先Android的用戶,跑去試用WP7手機,由於在Android有著"記憶體不足" 的前車之鑑,所以在WP7手機上面拼命開程式。打開了所有的程式,令人驚奇的是:居然還 是很順! 這真是太神奇了! 為什麼?下面就是為什麼。 如果你認為我只是在吹捧WP7而不屑一顧的話,你可以在這邊就關掉這篇文章,然後一廂情 願的跟人說android沒有app的話也很快。一年後你發現新的app已經迫使你換新的手機,而 WP7卻依舊可以用舊款手機安裝多款新的app。如果屆時你感到不解,歡迎你繼續來閱讀這 篇文章。 概念 在Android裡面,程式開了許多個,如果不關掉的話就會造成app一直吃著系統資源,最明 顯的例子是有人反映網路流量暴增,以為被盜用了。結果原來是各種需要保持連線的app沒 有完全關掉,用戶以為不管他就不吃流量了,進而造成系統資源持續被瓜分的情形。 用這個例子說明記憶體問題,隨著app的大小不同,所會占用的記憶體也不一。而Android 把常用的app預放在記憶體裡面,所以很多用戶會覺得:怎麼可用記憶體這麼少? 因此,很 多記憶體釋放的app就因而誕生。 說了這麼多Android,那WP7呢?只要用戶開了很多app,照理來說也是吃了很多資源阿! 其實不然。在WP7裡面,Mango 採用了所謂的"墓碑模式"(Tombstone),簡單來說,當使 用者從某個程式跳出來,或是切換到其他程式的時候,系統會把這個程式的狀態儲存起來 ,然後把硬體資源釋放出來,因此記憶體裡面就不會佔著一堆 App,影響系統的順暢度。 所以我如果原本在用導航軟體查看地圖,突然間需要上網查資料,當我叫出網頁的同時, 墓碑模式會幫我把導航軟體使用的狀況給存起來,然後釋放掉所使用的資源,以便下一個 app的使用。這樣可以確保機器資源的有效運用,不被浪費。 當然WP7的用戶自然也不用去找什麼記憶體清除app了。 App上架效能檢測(這邊我僅針對我有上架過的WP7做說明。我不知道Android有沒有) 當WP7開發人員千辛萬苦寫了一款通用遊戲機模擬器,可以玩XBOX360、PS3、PSP的遊戲, 雖說要載入30秒,這看似很強大的軟體,等這一點點時間也算值得!但是當你要上架以後 發現被打槍,執行軟體效能檢測才發現超過了微軟所定下的遊戲規則:"程式載入太久" 這才發現原來程式載入太慢也會被APP Hub打槍。 所以這逼的開發人員必須要精簡自己的程式、調校軟體已獲得更優的效能,而不是像 Android一樣一昧的提升自己的硬體規格,想用更高規格的硬體來hold住整個場面,到最後 彷彿沒有雙核心就無法執行太多軟體似的。應該是開發商要配合手機硬體才對,而不是手 機硬體規格一直追著App來跑。更何況更高規格的硬體效能可是一把兩面刃,雖說可以提升 用戶的流暢感,但是卻相對造成更高的功耗,這會讓手機的待機時間更為縮短。 對於有學過程式的人來說,即使是課堂學到的,老師們總是會千叮萬囑的交待效能的重要 ,寫程式除了功能漂亮以外,簡潔的程式碼也是大家致力追求的目標。 我想,如果您有努力看完這篇我花了兩個小時才打完的文章,或許這篇文章不一定能深度 完全解答效能的問題,但是起碼是一個分水嶺。千萬別再用App數量來評論流暢度了。這 兩者根本不同的概念。 備註:如果你是開發人員..如果你的程式需要背景多工(例如用戶一邊放音樂一邊看FB) 這樣請在開發的時候想辦法讓系統不要讓你的程式變成墓碑! -- 我剛剛的推文說服不了自己,稍微查了一下,iOS的程式即使在背景執行,也會吃到資源。 而我的文章應該要寫更清楚一點:WP7同時間只會執行1個程式,如無例外,通通變墓碑! 我是在某個iOS app介紹的網頁中看到:各位在升iOS4之後,多了背景執行的功能,卻也因 此常常忘了把背景的軟體關掉,而把記憶體吃光光,甚至還會出現個位數。當IOS記憶體過 低時,再開其他軟體就會Lag,甚至感覺道明顯的操作不順,這時候先要把背景程式一個一 個關掉,不過總覺得這個動作很麻煩,有時候要連按十幾次才能全部關閉,真的太不方便\ 了。 所以大膽推測iOS 4的背景執行也會吃掉資源。不過iOS真的打心底就抗拒,不是很熟。 有錯請告知 謝謝! iOS 4/5的文章在這邊找到一篇 http://chris959.blogspot.com/2011/06/ios-5.html ---------------------------------------------------------------------------- 墓碑機制 墓碑機制簡單定義 墓碑機制是微軟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 ,允許應用程序調用該接口保持實時更新。 ------------------------------------------------------------------------------ 底下得推文就不節錄了 還是來期待WP的手機好了 雖然IP5感覺很吸引人 但畢竟不知道啥時要出 -- ※ 發信站: 批踢踢實業坊(ptt.cc) ◆ From: 59.127.106.188 ※ 編輯: lavender717 來自: 59.127.106.188 (10/19 16:58)
文章代碼(AID): #1Ede-OZR (FCU_EE97A)