从一名普通开发者角度看:为什么Surface RT/Pro会失败?

最近很多IT资讯论坛都有发表对微软的Windows 8的Surface RT/Pro系列产品失败分析的文章。而本文则是从一名普通开发者的角度看微软Surface产品线溃败的原因。

笔者自身曾经只是一名普通的Windows 8开发者,所涉及的内容如有错误请指正。

看到很多论坛都把Surface系列产品失败的原因归咎于其错误的产品定位,其实回顾下Windows 8发布前的一些文章报道其实大部分都是正面的态度。从Windows 8 Developer Preview到Release Preview有很多新颖的特性,其中就包括Metro风格界面,那时候都包括我在内的很多开发者都很看好Windows 8。而我们恰恰就是那”大部分”人,对产品看不到更远。在开发时,作为开发者很早就可以拿到微软的产品原型,第一次把Windows 8 Pro平板拿在手里,就觉得很不可思议,觉得这会是个颠覆性的产品,因为在小小的平板上有着和PC一样的桌面环境,想象PC上有那么多给力的游戏,要是能随时随地在平板上玩起来岂不……但是当我在平板上打开一个桌面游戏时,我感觉到了什么,没有键盘、鼠标……那时并没有想到这竟成为Windows 8最失败的产品定位:PC平板。用户使用平板时根本不应该考虑去找个键盘鼠标来搭配。所以呢,结果就导致了微软Surface广告上极力推崇的那个键盘。但作为开发者,我认为Windows 8如果作为一个新的桌面操作系统的确还是很优秀的,比Windows 7好了很多。至于很多人抱怨的开始菜单,我无所谓。价格方面,微软本身就是移动平台的新入门玩家,脚跟都没站稳,就想着赚钱,大部分国内厂商的方法是选择用低廉的价格来让用户熟悉你的产品,因为用户不会为一个他们并不清楚有任何实际优点的东西支付高昂的价格,诺基亚也是如此,从Lumia 920上市的4500售价到目前近乎斩腰的价格就很明显了。

 

除了产品定位,在我看来有一个很重要的因素是微软的技术文化, API式学习和”凡事皆有我的规则(Microsoft`s rules)“。从操作系统到Office,微软有很多自家的东西,用自己的核心技术搭建起来了自己的软件王国。假如一种技术诞生于开源社区,而在微软的词典中找不到的话,微软会立刻学习,并且结合自身的技术积淀创造出一个全新的标准(这点和国内的企鹅是完全不同的),提供更简单的API和接口,让开发者更容易学会和使用。但也正是这样自我的软件王国或许会毁了微软,因为世界上大部分Coder不喜欢这样API式学习(例如开源社区)。在Windows 8中微软除了支持自己的儿子C#外还推出了新的干儿子语言的C++/CX,后者是继C++/CLI后的又一个C++扩展,或者可以理解为C++变种,没错,这种变种语言由标准C++扩展而来,只能靠微软支持并在Windows 8新系统中使用,学了它以后你不会再感觉到自己憔悴了,相反会觉得自己更年轻,更像baby了(因为更简单了),而且你心里很清楚,自己的下一份工作八成还会和微软打交道。在新的C++/CX语法学习中,按照MSDN敲出了代码,恩,很好,运行起来了,界面很漂亮,很大的成就感,突然间程序挂掉,这时候你有三种选择:一、到MSDN论坛或者其它开发者社区讨论,他们给出的回答通常类似于:你照着下面的代码敲试试?看看MSDN你就知道了! 通常第一种选择的结果会直接导致第二种选择:看更多的MSDN文档来寻找解决方法。我选择了第三种:放弃这样的学习。对开发者而言这种API式学习的背后是巨大的学习成本,毕竟不是所有开发者都是微软MVP,没有那么多人会理解这些API背后的核心技术,Windows 8的开发者在入门时做得最多的一件事应该就是在用有限的精力浏览无限的MSDN文档,当微软更换了节奏(被替代的C++/CLI便是如此)你只有从头来过。而从软件公司的角度来说,这样的API Coder没有多大价值,他们需要的仅仅是有个人按照MSDN文档上的接口来把代码组装起来,你不干,总会找得到人来做。作为一个有价值的Programmer,想掌握排序查找加密算法、资源调度、API设计?抱歉,MSDN文档里没有。

 

API和接口学习的背后是微软的游戏规则,微软的确在把复杂的技术简单化,也曾经创造出了很多经典的技术概念(比如MFC的RTTI利用和消息循环、COM)。但是越来越多的规则开始暴露了一个目的:巩固自己的王国。渐渐地开始把技术细节隐藏,降低对开发者的智商要求,从而吸引到更多的开发者(当我看到技术群里越来越多的大学生甚至是中学生在学习这个,心里都觉得可惜了,自身兴趣爱好也罢,居然有高校把开发Win 8 App作为论文达标标准)。笔者自身在学习过程中就得无时无刻并且无数次地遵循着微软的游戏规则。Windows 8 的Metro API中限制使用Win32 Native API(出于安全考虑,可以理解,听说微软正在慢慢开放一部分Native API),之前的Windows开发经验全部报废,公司积累的代码大部分都要重写。算了,使用第三方库吧,结果应用商店提交时检测到你的代码中包含”异类”的API,不给予通过。行,按照示例代码实现了部分功能,然而想实现进一步功能时参考了其它示例代码(别说你初学的时候不是这样的),结果拼接在一起运行,好了,挂了,程序的堆栈显示中断在N个莫名其妙的dll中,除了少数几种异常Bug可以捕捉(大多数开发者那时候并不知道这些方法,因为不在MSDN中)外你只能干瞪眼,心里默默地念一句”艹”,然后在其它的示例代码中寻找可替代的方案,无论最终的方案运行效率如何,此时此刻你心里想要的只是可以运行起来的代码,根本不会考虑别的问题。然而你还没有考虑用户实际操作下的可能行为(微软提出后台挂起概念其实也并不新鲜,但是饱受诟病,当时我随意从应用商店下载了几个App,随意地复杂操作几下,每个必闪退。再看看Windows应用商店里Win 8 版QQ的评论就知道了,连腾讯这样的大公司写了几个版本的Win 8 QQ都无法改变它的异常闪退,更何况为这些问题挣扎的你)。好了,此时此刻笔者已经改完了所有的Bug,在你本机上运行一切正常,在平板样机上也OK了,提交到应用商店,结果被拒绝了,理由是应用加载时间取决与当前的网络环境,汗,Windows Store商店应用自身启动时间甚至比我的应用还慢,而且经常无法加载也是公认的。最后,彻底放弃了。水平有限,无法领悟MSDN的强大。

 

错误的产品定位、高昂的API学习成本、各种API限制于一身、整个开发过程几乎是全新开发,没有多少重用的概念(这点还是可以理解,毕竟是一个新的平台)、无厘头的异常和闪退(如果说Win8之父史蒂夫 辛诺夫斯基因为是偏平化UI设计而被炒鱿鱼的话,那么造成App异常闪退的架构师就应该倒扣工资了)这些因素无论它们各占多少轻重,总之加起来就是Surface系列产品失败的全部,至少作为一个普通的开发者,我是这么认为的。