[转载] 关于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是托管代码，效率有差，但这个差距不要以为很大，例如你要调用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。
作为开发者，自己看着办吧。