Windows 8为什么会是开发人员的2012

在一周前微软刚刚发布Windows 8的首个公开展示版本时，来自各界的反响普遍较为积极。Winodws 8提供的新用户界面看起来简洁、有吸引力、功能全面，而且这也是微软推出的第一款被广泛认为具备友好外观的桌面操作系统。然而，负面的声音也同时出现。该展示版本在Windows开发者群体中饱受诟病，原因非常明确：开发人员们被告知，他们一切固有的经验、知识体系以及过去所编写过的全部程序在 Winodws 8中都毫无用武之地。

难倒Windows 8将要成为开发人员的2012么?

问题的关键在于Windows 8为了使Windows系列操作系统能够推广到平板设备上而过分追求外观与感受方面的要求，这使其不得不为那些充满强烈“浸入式”体验以及新鲜风格的全屏应用提供支持。随之而来的情况是，Windows 8将针对这类应用程序的开发而囊括各种新的API，症结就在这里。其实拥有全新的API本身并不算大问题(但Windows系统平台上从来就没有支持过这类平板风格的应用程序，所以当下既有的各类资源显然无法发挥作用)，不过最令人抓狂的是微软所公布的这类API的使用方式。主管Windows系统体验的微软副总裁Julie Larson-Green简要对一款新的“浸入式”天气预报程序进行了介绍，整个说明中最为重要的内容是该应用程序用到了“我们全新的开发平台，也就是，呃，基于HTML5及JavaScript。”

此言一出，开发业界立时哀鸿遍野、天怒人怨。

开发人员们过去已经在Windows开发平台上投入了大量的时间、精力与资金。多年来，大家学会了Win32、COM、MFC、ATL、 Visual Basic 6、.NET、WinForms、Silverlight、WPF等等工具的使用技巧。所有这些技术都能在特定时间、特定项目中发挥作用，为 Windows桌面系统的应用程序创建提供帮助。而除了Visual Basic 6，其它各种工具时至今日仍然或多或少得到当前Windows系统的支持，而且这些工具也无法单独应对所有需求;也就是说，除了Visual Basic 6及WinForms，其它工具在当下的Windows开发工作中仍然扮演着各自不同的角色。

在听闻Windows 8将为其新型“浸入式”应用程序引入HTML5及JavaScript后，Windows开发者们毫不掩饰内心的失落与恐慌。这种“一刀切”式的方针意味着完全放弃近二十年来苦苦积累起来的Windows开发知识及经验——还要加上为学习微软那些最新最强大的技术所付出的海量时间——此外，也许同样重要的是，我们不得不放弃内容全面、功能丰富的固有框架及强大、普及率极高的Visual Studio开发环境，转而将阵地迁移到一套更为原始、系统简陋且充斥着大量劣质开发工具的平台。

合理的反应

微软抛弃一切既有经验的念头看起来相当疯狂，但人们同样可能觉得开发人员们的反应有些过激——不过毫无疑问的是，微软未来的发展方向已经初现端倪：大力支持HTML5，尽管它在许多方面弱于其它技术。Larson-Green就Windows 8所做的评论令人震惊，没错，但这其实只是证实了开发人员们此前的一些猜想。开发者当然不愿意为微软的决定买单，然而如今各种迹象表明Larson- Green所表达的观点正一步步变为现实;如果想要用到最新的开发平台，我们终究需要面对HTML5与JavaScript。

微软可以说从来没有为其开发战略规划出什么上佳的前进方向并一直坚持贯彻。发展过程总是充满混乱的内斗，新的技术潮流带来大量跳跃式革新，而这些引领型的新软件又鲜有成功的范例。直到大约一年半之前，情况终于有所改观，一切似乎开始尘埃落定，.NET、Windows Presentation Foundation(简称WPF)与WPF的Flash类分支Silverlight三者紧密协作。WPF与.NET相互配合，提供了一个用于编写 GUI应用的更为灵活、高效且结构明晰的方式，而Silverlight则作为WPF的精简版本为Windows及Mac OS X系统上的浏览器提供功能多样的各类插件。

这些技术都谈不上完美——WPF的执行效率从未达到用户们的预期，而Silverlight的跨平台支持能力也一直没有百分之百发挥出来——但软件开发在这个阶段至少在产品层面上表现出了令人欣慰的一致性。WPF与.NET应付大型应用程序，Silverlight则专攻移动版本。

希望落空

然而好景不长，IE9出现了。这一次微软选择了HTML5，伴随着该决定，各种麻烦也接踵而至。在IE9出现之前，Silverlight一直是微软较为偏爱的跨平台应用程序开发方案。广泛支持平台的缺乏使得Silverlight根本无法对竞争对手Flash造成严重威胁，但至少它占有一席之地，并且在支持它的平台上表现良好。而从IE9得势之时开始，Silverlight就立马沦为板凳选手，而HTML5则成了指路的明灯、航行的舵手。在这种情况下，即使Silverlight仍有出场的机会，也只能在那些HTML5实在应付不了的方面发挥作用，例如处理流媒体视频。除此之外，开发人员们不得不接受这样一个事实——改用HTML5吧。

微软这么做也有自己的道理。如果我们真的想让广大用户将注意力集中到某个平台上来，HTML5是不可或缺的。对于面向网页的应用程序来说，对DRM 视频之类并不存在特殊的需求，因此HTML5的优势从长远来看还是相当明显的。但第三方开发人员们对微软的这种定位方式极为不满，这也是可以理解的。对于一位长期通过流水线式作业编写内部应用程序的开发人员来说，对某款浏览器插件产生依赖并不算是什么问题，而且Silverlight过去是，现在也仍然是一款具备相当多亮点的辅助工具。

HTML5如今还是专注于提高其较为擅长的文本处理能力;而相应的架构及语义表达也倾向于对结构化文本文档的创建进行完善，而非针对应用程序中的用户接口。在按钮、图标、列表框、树状视图及其它接口控制等等Silverlight程序能够发挥良好作用的方面，基于HTML5的应用程序则依然只能靠基本的文本框来应付，而没有更高层次的处理概念可供选择。JavaScript函数库正在试图弥补这种差距，但这些函数库不具备Silverlight所能提供的功能及控制力。最后，如果某位开发人员打算为用户接口的创建设计一套架构，该架构成品看起来将非常接近Silverlight的产物，而非其真正生母HTML5。

HTML5的另一个薄弱环节在于工具。HTML5所对应的设计与开发工具并不像Silverlight的工具那样成熟和强大，这使得基于HTML5 的开发工作变得更为复杂，特别是在当前应用程序自身的复杂程度也在不断增加的前提之下。到目前为止，尽管HTML5仍在继续被当作部署于浏览器中的应用程序的首选开发平台，但微软实际上几乎没有为这款平台的诸多问题付出任何实质性努力。

无论如何，Redmond总部的确已经为HTML5做了点事情，相对于之前对Silverlight及WPF所采取的完全袖手旁观的态度，现在的情况还算是略有改善。IE9的创建基于名为Direct 2D的API。这是一款2D图形函数库，采用了Direct3D 10作为加速手段。其实Direct2D API甚至比HTML5还要低端;至少HTML5的页面基本上是由文本框所构建，而这些框体自身都具备一些“智能”属性，且拥有布局规划、边框、背景及其它更多内容。与此相对应的是，Direct2D能够在为开发人员留出布局空间的前提下，处理稍微复杂些的项目，例如各类曲线或是曲线组。此外，不同于 WPF在利用Direct3D方面所表现出的低下效率，IE9及Direct2D在利用效率方面都得到了大幅度的优化。

对于IE9，微软在向其开发社区公布的通告中提到两点：HTML5是首选技术，无论其是否真正合适或好用;如果大家对性能有较高要求，可以直接在 C++中使用低端的Direct2D(这当然也很令人反感)或是中端的HTML5。如果大家想使用高端且专用的高性能API(例如某个基于 Direct2D的WPF版本)，这事儿没戏，还是尽早放弃此类念头吧。

因此针对Windows 8所公开的说明应该是微软在对过去几年所采取的策略进行综合汇总的结果。尽管HTML5因为缺陷众多而成为一款口碑很差的开发平台，但Windows 8的开发人员们只要决定制作新的“浸入式”应用程序，他们就没有更好的选择。这项策略无疑是疯狂且极具毁灭性的，但至少它保证了开发要求的一致性。IE9 的登场与Silverlight的退隐只是贯彻这套方针的第一步;“浸入式”应用程序必须使用HTML5则是接下来必须接受的条件。

莫名的沉默

鉴于由合理原因造成的恐慌情绪正在开发者社区中逐渐蔓延，人们可能会期望微软站出来做点什么以安定人心。毕竟，如果微软有办法保留工作人员们当前具备的、基于Windows系统的开发知识及经验，那么整件事情似乎还有斡旋的余地。

然而与之相反，微软却坚持认为历史趋势已然证明D9不能再作为开发工作的专注重点，而且其企业整体也将于今年九月举行的开发大会上深入讨论下一步开发平台。还有其它消息吗?答案是否定的，甚至连句“别担心，我们肯定会想办法让大家继续通过.NET及本机代码来编写‘浸入式’应用程序，大家还是能够用上自己最为熟知的开发技能”这样的安慰性话语都没有。

重新选择阵营

这种战略无疑非常危险。Windows仍然会在很长一段时间内充当企业级桌面系统中的带头大哥，因此以商业应用为主的开发人员们别无选择，只能听任微软的摆布。也就是说，虽然前路崎岖，市场的实际风险却并不大。但对于那些将着眼点放在平板设备及智能手机市场的开发商来说，事态就完全不同了。微软 Redmond总部不得不承认，在以下两方面他们正面临窘境：Windows Phone还不满一岁，启动步伐也极为缓慢;而在Windows 8成熟之前，整个企业也没有可以依赖的平板设备平台。要在商务及移动市场上两路开花，微软需要崭新的“浸入式”应用程序。而且只具备这一个条件也还不够好 ——只有应用产品还不能算成功，用户也得买账才行——但如果连这个条件都不具备那就完全没戏唱了。如果Windows 8平板设备没有足够多的对应程序，那么它将永远在iPad的威势下被压得抬不起头来。

Windows Phone 7自发售以来的市场占有率图示

微软最为重视的要素之一仍然是其开发工具以及庞大的开发人员社区。Windows Phone明确反映了这个社区的价值所在：至少在可用的应用程序数量方面，它的表现将竞争对手手远远甩在身后。超过两万款应用程序可供使用，这一数字足以傲视webOS在线商店，更不用说黑莓的BlackBerry App World。事实上Windows Phone拥有这样骄人的发展态势，正是因为采用了Silverlight作为其开发平台。这类开发工作上手轻松、容易熟悉，甚至开发人员会在用户群体相对较小的情况下仍旧为其研制软件产品，因为工作过程充满趣味。

那些有过为手机开发软件经历的开发者们，当然很希望能够在为Windows 8制作产品时让相关经验派上用场。苹果与谷歌的平板设备操作系统都可以直接把对应的智能手机上的软件拿来使用，因此Windows 8需要具备同样的特性几乎可以说是板上钉钉。即使是那些还没有鼓捣过手机应用的技术人员，也一定会对利用自己既有的Windows开发技能为平板设备制作应用程序产生兴趣。

然而，如今开发人员们被告知，要将注意力转移到平板设备上，他们必须要抛弃以往全部的知识储备，这无异于当头一棒。这些微软本应极力拉拢的开发者们现在有充分的理由质疑这款平台的发展前景。而且他们真的为此愤怒且担忧。这种强迫大家必须使用HTML5及JavaScript的行为简直可以说是在鼓励我们重新选择支持阵营。

应用程序的重生

这其中最具讽刺意味的是，微软长久以来一直把网页应用程序作为威胁其企业生存的死敌。如果网页本身转化为平台，那么人们将不再需要Windows系统中的各类程序，甚至会进而抛弃Windows系统本身。这种观念的直接后果就是微软对Netscape公司所实施的毁灭性打击以及在浏览器之争中不顾一切夺取胜利的做法;微软认为，只要成功实现上述战略，即使网页本身真的变成平台，至少也要通过使用微软产品的方式将其保持在自己的控制之下。

微软赢得浏览器之战至今已经过去了十年，相对于当时对网页应用程序取代本地客户端的担忧，当下的现状几乎是完全相反：客户端应用程序领域获得了爆炸式的发展。丰富的应用程序——其中许多的前端都是云托管之下的网页应用程序——正在蓬勃成长，而这一切都要归功于智能手机及平板设备市场的兴起。苹果 App Store与Android Market来势之迅猛有效扼制了网页应用程序的嚣张气焰，并同时提高了人们投入客户端应用程序开发工作的决心和热情。因为比起单纯的网页应用，开发人员们通过客户端可以为用户奉上功能更多、使用体验更好的产品。

虽然这种趋势可能无法一直持续下去——例如金融时报认为，为了刻意规避苹果App Store策略而设计的网页应用程序表明这类应用模式仍然具备很广阔的前景——但不可否认，当前实体类应用程序的发展态势及重要作用超出了任何人在五年前所做出的预测。

智能手机与平板设备再次将应用程序推向时代的巅峰，而微软，作为世界上应用程序方面最为重量级的巨鳄级企业，理应最大程度地利用这种趋势。微软拥有最好的开发工具以及资金充裕、只待在其新的平板设备上大展拳脚的众多第三方开发商——万事俱备，只欠东风。

疯狂，但并不愚蠢

微软依然在保持沉默，他们似乎很乐于看到目前的局面，即无论这项决定会造成多大的损失及麻烦，将HTML5与JavaScript作为 Windows 8“浸入式”应用程序开发惟一工具的方针将决不动摇。而微软这种沉默保持得越久，就越是能说服人们放弃那些不切实际的幻想，踏踏实实地认清事实：微软并不是刻意不发言，而是没有什么可说的。HTML5和JavaScript可能真的是“浸入式”应用程序开发的仅有途径。因为如果微软还留有后手，那么目前这长时间的沉默就变得莫名其妙了。但必须承认，微软当下的态度非常伤人，开发商们在逐渐开始动摇并丧失信心，麻木地等待将于今年九月正式发布的、会令人彻底抓狂的最终结论。

但微软绝不愚蠢，在这个问题方面的通告及公共关系处理貌似疯狂，开发商们的激烈反应也在预料之中。但这家庞大的企业不可能忘记过去的教训，因此强迫开发商们抛弃一切经验并因此彻底丧失开发支持优势的情况应该不会发生。Windows 8将提供一个新的API，而且大家不必通过编写页面的方式来使用它。

微软可能不会针对新API作出任何相关的官方声明，但已经有蛛丝马迹逐渐曝光，近来还出现了作为证据的截图。目前具体细节尚不明了，但我相信随着时间的推移，整个谜题将越来越趋于清晰。届时，我们将彻底了解到Windows 8会如何摆脱HTML噩梦的纠缠。