[轉載] 關於WP8開發人員程式開發語言選擇傾向的問題

這篇文章寫得不錯，轉過來

http://www.wpxap.com/thread-429060-1-1.html

基本概念：
1.Windows 8有Pro和RT兩種版本，Pro採用X86，RT採用ARM。
2.X86的可以運行Metro外還可以運行所有現有的傳統型程式（只要沒相容問題），ARM除了運行Metro程式，只能運行微軟提供的有限的傳統型程式並不允許第三放的傳統型程式，例如Windows 8內建的資源管理員，案頭版的IE10，案頭版的WP，案頭版的畫圖當然還有最重要的內建案頭版Office。
3.跨平台分為兩種，一種是寫一次，直接可跨平台運行，另一種是移植後才可以運行。
4.關於商店，Windows 8 Pro版和RT版都會訪問同一個Windows商店，而WP7和WP8會訪問手機版的商店，兩個商店是完全獨立的，手機商店裡面你不會看到任何windows的Metro程式。
5.Windows 8的Pro和RT版，能夠直接跨平台啟動並執行，只有Metro程式，而且必須是非C++的，也就是C#+XAML或HTML+JS。
6.WP8的程式，無論如何都需要移植，因為WP8的RTP無論多接近RT，它也還是一個縮水版，而且你也不會想要手機和平板是一套介面吧，很多基本軟體介面大改基本就是從新開發了。
7.移植的問題，主要是由語言和API的共通性決定的，silverlight是C#+XAML，語言共通，API，見過我另外一個文章的就知道WinRT的API和以前silverlight換湯不換藥，調用它的方式也相同對於C#，當然WinRT是Native code，siverlight是Managed 程式碼，效率有差，但這個差距不要以為很大，例如你要調用silverlight播放一個MP4視頻，silverlight也不是自己去播放視頻而是調用系統的功能，都是原生的還硬解呢。

結論：
Windows 8會共用一個商店，但你想要你的Metro程式只上架一個就能搞定兩者，就不能用C++，如果非要用C++，那麼就要為ARM專門移植一份（就算這個移植調整很小甚至只是重新編譯一下），然後上架兩個軟體分別針對X86和ARM額版本，並維護兩個版本。
WP7和WP8共用商店，如果要做到兩個平台相容，也就是只維護一個版本同時搞定WP7和WP8，該用什麼方式不言而喻，這個微軟當初WP7屏蔽一切CE的一切，死不開放native code，就是為了今天換血後平台的延續性做準備，所以WP8換心後WP7可以作為WP8的子集繼續存在，基礎軟體仍然共通。
如果搞其他，特別是C++，就代表，WP7一份，WP8一份，Windows 8 Pro一份，Windows 8 RT一份，維護4個版本，要知道WP8雙核起跳WP8還要半年才開始銷售，WP8開始銷售後WP7作為中低端還會銷售很長時間。
自己衡量，自己那些用戶端類軟體，有哪一點需要用到C++，何況是managed的C++，大家都是一樣的地位去調用WinRT，邏輯沒最佳化好，小心人家HTML+JS都比你流暢，要知道C++做商務邏輯的效率和可維護性時遠不如C#。
遊戲當然沒啥好說的，除了小遊戲，大型3D遊戲一定會迅速拋棄WP7。

關於效能：
其實做網頁的人最善於最佳化載入的邏輯了，這與HTML本身DOM的載入方式有關，而且開發人員最佳化到位，例片要滑到你能看到的地方才用ajax非同步載入，這是作為web開發人員所開發繞不開的東西，他們本來就會扣每一點資料的請求和載入，流量啊，習慣非同步做完一件事做另外一件。
載入邏輯最佳化最差的，首選只會搭積木的Net程式員，什麼MVVM，請求到50條資料，絕對是一次性綁上去顯示出來，然後卡你一下，Net程式員經常是1000條資料都不做消極式載入，一次性往列表插，例如很多歌詞軟體，你進入歌曲列表，100首的都還好C#的效能還能夠承受，如果你歌有1000首，呵呵，你就感覺到了，可悲的是我就是那種手機上1000多首歌的，喜歡存滿自己愛聽的專輯然後隨時都有選擇。
還有就是Net程式用多線程Easy，進一步造成卡，很典型的就是，搜狐視頻這類程式，進入後只要你敢立即滑動頁面，會觸發該頁的請求，然後使用者滑動到另外一頁，觸發了幾個頁面的請求，這些請求同時進行，本來這幾個並行的請求完成後應該先判斷使用者是否還停留在該頁是否還有必要立即往介面中填充資料，還是等使用者切換回該頁後再往介面填充資料，顯然這種基本的邏輯沒有做，所以，在你滑動時必須先卡死你一下。
C++不瞭解，不多說，但同時期穩定性較低的一定是C++的程式。
最後，大家會發現，最不容易卡的程式，是就語言來說效率最低的HTML+JS，不信大家可以拭目以待。

大家都清楚，WP7時WP8的一個子集，未來會有越來越多的軟體不支援WP7，特別是新的3D遊戲，但也不至於什麼開發人員全部轉向C++之類的，C++不過是一種選擇。

還是找些實際的來說明問題吧：

 

第一類：HTML+JS：
這類程式可以通用於Windows Pro和RT，微軟內建的程式使用較多例如：照片Photo，Xbox Live，Music,Video,BingNews,BingSports,BingTravel,BingWeather,skydrive。
大家可以看到，JS寫的功能複雜的軟體，會存在不少.winmd的檔案。
簡單解釋下winmd的程式集，就是一種可以由C#和C++編寫，然後被JS，C#，C++,三者調用的東西。
JS畢竟是動態語言，寫起來蛋疼太容易寫錯，調試也不如方便，所以其他還是用C#，就像做web開發，例如MVC架構，Views也就是介面是HTML+JS，Controller和Service都是C#。
沒發現有些應用的結構，還真和做Web開發用MVC架構類似麼，哈哈，做web開發的Net程式員是不是很親切。
這些如果用C#編寫，那麼就不會破壞跨平台能力，如果用C++，那麼自己為不同平台準備吧。

圖中是Video。

 

第二類：C#+XAML，大多數第三方開發人員選用，由於語言互連，API近似，移植到WP7的Silverlight也較為方便，做到WP7和WP8的直接共用。
系統內建的BingMaps，第三方Sina 微博，PPTV，QQ音樂，馬鈴薯，人人HD。
圖中是PPTV，看到第二張圖中的處理器支援沒，通殺X86和ARM，我覺得微軟這裡不人性化，普通使用者還關心X86還是ARM？直接說平台更好，例如Win8 Pro，Win8RT。

這個會是目前，對於微軟的平台，最主流和通用性最好的方案。

 

第三類：C++，試了幾個國產軟體，目前就發現一個背時的QQ，既然QQ選擇C++，那就給Windows 8 Pro，Windows 8 RT做兩套分別維護吧。
看CPU支援，目前只能用於X86，蛋疼了吧。
而且可以看到，就算用C++，仍然是用XAML，仍然是調用WinRT裡面的組件，介面仍然是調用WinRT裡面的介面控制項，這個mangaged的C++，我看不到它的優勢在哪裡。
如果真有部分核心需要用C++的運算能力（大部分擷取資料呈現類沒有這種需求，可以說90%普通應用沒有此需求），也或許有C++現成封裝好的類庫好用，但這部分完全可以用C++，現成的C++類庫改造成winmd類庫，然後供JS或者C#調用。
項目都用C++語言，用C++去調用WinRT，語言習慣也有所改變，畢竟WinRT是吸收Net的精華，例如metadata，所有習慣都是繼承於Net，與WinRT打交道用C++的語言卻是Net的套路，我看不到任何好處。
介面這一塊的XAML也是源於WPF，一直都是Net的東西，C++加XAML，何必呢，難道指望都調用WinRT的東西效能更高？到時候最順滑的程式介面這部分是JS寫出來的才悲劇。
C++，就老老實實用在運算密集型的部分吧，例如遊戲引擎一類，介面這一塊就別來搶生意了。

C++是最沒有跨微軟平台能力的，說白了，就是C#滿足不了的東西，只有C++才有的東西，迫切需要移植的東西，才需要用C++。
大家覺得哪一類屬於這種，QQ之類，weibo，馬鈴薯，優酷，之類屬於這一類嗎？
目前通行於WP7，WP8，並且能夠從Win8方便移植的最佳方案，明顯是C#+XAML，對應到WP7和WP8，就是他們都可以支援的silverlight。
作為開發人員，自己看著辦吧。