Fw: [討論] 為何WP7比Android還順? 從設計概念說起
這兩篇是歷史文章,曾經轉過來過,卻因為年代久遠而灰飛煙滅.
在上面版主的討論中有希望我再轉過來一次,原本覺得已經沒必要了,可是又看到有人以為
APP數量決定運作速度,實在看不下去,所以再轉一次.
M不M就見仁見智了,畢竟這篇文章也是老古董了,加上android也改善了.這陣子我也沒在關
注Android和wp8的底層機制,所以暫時也沒更新文章的打算.
就當作是個歷史故事來看吧!
PS:wp8有新的機制,所以100%保證不能用這篇文章的態度來看待WP8
=============================================================
作者: felaray (<^)<) 看板: MobileComm
標題: Fw: [討論] 為何WP7比Android還順? 從設計概念說起
時間: Sun Dec 9 14:58:30 2012
※ [本文轉錄自 WindowsPhone 看板 #1EdQ4F_y ]
作者: 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)
這樣請在開發的時候想辦法讓系統不要讓你的程式變成墓碑!
--
推
07/25 13:32,
07/25 13:32
→
07/25 13:36,
07/25 13:36
--
※ 發信站: 批踢踢實業坊(ptt.cc)
◆ From: 61.62.70.141
→
10/18 23:54, , 1F
10/18 23:54, 1F
→
10/18 23:57, , 2F
10/18 23:57, 2F
※ 編輯: felaray 來自: 61.62.70.141 (10/19 00:00)
推
10/19 00:02, , 3F
10/19 00:02, 3F
推
10/19 00:04, , 4F
10/19 00:04, 4F
推
10/19 00:04, , 5F
10/19 00:04, 5F
推
10/19 00:05, , 6F
10/19 00:05, 6F
推
10/19 00:12, , 7F
10/19 00:12, 7F
→
10/19 00:13, , 8F
10/19 00:13, 8F
推
10/19 00:15, , 9F
10/19 00:15, 9F
→
10/19 00:16, , 10F
10/19 00:16, 10F
推
10/19 00:19, , 11F
10/19 00:19, 11F
→
10/19 00:20, , 12F
10/19 00:20, 12F
→
10/19 00:20, , 13F
10/19 00:20, 13F
我剛剛的推文說服不了自己，稍微查了一下，iOS的程式即使在背景執行，也會吃到資源。
而我的文章應該要寫更清楚一點:WP7同時間只會執行1個程式，如無例外，通通變墓碑!
我是在某個iOS app介紹的網頁中看到:各位在升iOS4之後，多了背景執行的功能，卻也因
此常常忘了把背景的軟體關掉，而把記憶體吃光光，甚至還會出現個位數。當IOS記憶體過
低時，再開其他軟體就會Lag，甚至感覺道明顯的操作不順，這時候先要把背景程式一個一
個關掉，不過總覺得這個動作很麻煩，有時候要連按十幾次才能全部關閉，真的太不方便了。
所以大膽推測iOS 4的背景執行也會吃掉資源。不過iOS真的打心底就抗拒，不是很熟。
有錯請告知 謝謝!
iOS 4/5的文章在這邊找到一篇 http://chris959.blogspot.com/2011/06/ios-5.html
請看此章節:背景凍結的關閉
※ 編輯: felaray 來自: 61.62.70.141 (10/19 00:30)
推
10/19 00:36, , 14F
10/19 00:36, 14F
推
10/19 00:37, , 15F
10/19 00:37, 15F
→
10/19 00:38, , 16F
10/19 00:38, 16F
推
10/19 00:44, , 17F
10/19 00:44, 17F
→
10/19 00:44, , 18F
10/19 00:44, 18F
推
10/19 00:46, , 19F
10/19 00:46, 19F
→
10/19 00:46, , 20F
10/19 00:46, 20F
→
10/19 00:47, , 21F
10/19 00:47, 21F
→
10/19 00:47, , 22F
10/19 00:47, 22F
推
10/19 00:47, , 23F
10/19 00:47, 23F
→
10/19 00:48, , 24F
10/19 00:48, 24F
推
10/19 00:48, , 25F
10/19 00:48, 25F
→
10/19 00:48, , 26F
10/19 00:48, 26F
→
10/19 00:48, , 27F
10/19 00:48, 27F
推
10/19 00:48, , 28F
10/19 00:48, 28F
推
10/19 00:49, , 29F
10/19 00:49, 29F
→
10/19 00:49, , 30F
10/19 00:49, 30F
→
10/19 00:49, , 31F
10/19 00:49, 31F
推
10/19 00:52, , 32F
10/19 00:52, 32F
→
10/19 00:52, , 33F
10/19 00:52, 33F
推
10/19 01:00, , 34F
10/19 01:00, 34F
→
10/19 01:00, , 35F
10/19 01:00, 35F
→
10/19 01:08, , 36F
10/19 01:08, 36F
推
10/19 01:09, , 37F
10/19 01:09, 37F
→
10/19 01:10, , 38F
10/19 01:10, 38F
推
10/19 01:11, , 39F
10/19 01:11, 39F
→
10/19 01:11, , 40F
10/19 01:11, 40F
→
10/19 01:12, , 41F
10/19 01:12, 41F
→
10/19 01:18, , 42F
10/19 01:18, 42F
→
10/19 01:19, , 43F
10/19 01:19, 43F
→
10/19 01:19, , 44F
10/19 01:19, 44F
→
10/19 01:25, , 45F
10/19 01:25, 45F
→
10/19 01:26, , 46F
10/19 01:26, 46F
※ felaray:轉錄至看板 MobileComm 10/19 01:27
→
10/19 01:28, , 47F
10/19 01:28, 47F
→
10/19 01:28, , 48F
10/19 01:28, 48F
→
10/19 01:31, , 49F
10/19 01:31, 49F
→
10/19 01:31, , 50F
10/19 01:31, 50F
→
10/19 01:32, , 51F
10/19 01:32, 51F
→
10/19 01:32, , 52F
10/19 01:32, 52F
→
10/19 01:32, , 53F
10/19 01:32, 53F
→
10/19 01:33, , 54F
10/19 01:33, 54F
→
10/19 01:33, , 55F
10/19 01:33, 55F
→
10/19 01:33, , 56F
10/19 01:33, 56F
→
10/19 01:34, , 57F
10/19 01:34, 57F
→
10/19 01:35, , 58F
10/19 01:35, 58F
→
10/19 01:35, , 59F
10/19 01:35, 59F
→
10/19 01:36, , 60F
10/19 01:36, 60F
→
10/19 01:36, , 61F
10/19 01:36, 61F
→
10/19 01:36, , 62F
10/19 01:36, 62F
→
10/19 01:37, , 63F
10/19 01:37, 63F
→
10/19 01:38, , 64F
10/19 01:38, 64F
→
10/19 01:38, , 65F
10/19 01:38, 65F
→
10/19 01:58, , 66F
10/19 01:58, 66F
推
10/19 11:12, , 67F
10/19 11:12, 67F
→
10/19 11:27, , 68F
10/19 11:27, 68F
※ dais:轉錄至某隱形看板 10/19 13:14
→
10/20 03:14, , 69F
10/20 03:14, 69F
推
10/21 12:34, , 70F
10/21 12:34, 70F
※ 發信站: 批踢踢實業坊(ptt.cc)
※ 轉錄者: felaray (124.10.80.50), 時間: 12/09/2012 14:58:30
※ 編輯: felaray 來自: 124.10.80.50 (12/09 15:04)
討論串 (同標題文章)
完整討論串 (本文為第 1 之 2 篇)：
MobileComm 近期熱門文章
PTT數位生活區 即時熱門文章
