HTML5和桌面软件开发的碰撞

当我们谈论桌面软件开发技术的时候你会想到什么如果不对技术本身进行更为深入的探讨在我的世界里有这么多技术概念可以被罗列出来请原谅我本质上是一个Windows程序员的事实。操作系统 API。操作系统发展到今日几乎桌面应用的所有功能都是基于系统API构建的。调用API和语言及技术无关哪怕是使用汇编。例如代码来源于网络本地重新编译;我的第一个win32汇编程序;一个经典的hello world !程序;.386.model flat,stdcalloption casemap:none;;头文件的定义;include windows.incinclude user32.incinclude kernel32.incincludelib user32.libincludelib kernel32.lib;;数据段;.dataszCaption db 我的第一个win32程序,0szText db hello world !,0;;代码段;.codestart:invoke MessageBox,NULL,offset szText,offset szCaption,MB_OKinvoke ExitProcess,NULL;end start代码清单0-1 汇编MessageBox在代码清单0-1中通过汇编调用MessageBox Api来呈现一个简单窗口程序。代码清单0-1的运行结果如下图0-1 代码清单0-1运行结果同样的我们使用c/c来调用这样一个win32 API代码可能是如下这样的#include windows.hint main(){MessageBox(NULL, (LPCWSTR)LHello world!,(LPCWSTR)L我的第一个win32应用程序, MB_OK);return 0;}代码清单0-2 c/c版MessageBox代码清单0-2运行结果如下图图0-2 代码清单0-2运行结果在系统API之上经过抽象与封装在各个操作系统上形成了各自的所谓的库和框架。比如windows的MFC和Delphi等Linux的Gnome、GTK、KDE等Max OS X平台的Cocoa开发库。对于系统API的强依赖性直接导致的问题是桌面应用的可移植性开发人员不得不针对不同平台的操作系统即使同一平台也不一定能良好兼容编写不同的代码。另外即使你已经编写了不同的代码来适配不同的操作系统和平台仍然没有办法保证桌面应用的UI和交互是一致的这一点上有的开发者认为一致反而是障碍因为不同平台下的用户的桌面应用的使用习惯是不一样的。但是UI呢我觉得保证UI一致是极其有必要的。笔者接触到的最早的跨平台桌面UI库是Qt。Qt是一个跨平台的C图形用户界面库由挪威TrollTech公司出品目前包括Qt基于Framebuffer的Qt Embedded快速开发工具Qt Designer国际化工具Qt Linguist等部分Qt支持所有Unix系统当然也包括Linux还支持WinNT/Win2kWin95/98平台。图0-3 Qt上文中提到的Linux的KDE就是Qt的杰作。Qt做出了两方面的努力都很成功一个是软件UIQt在UI方面展现了独特的效果这种效果脱离了所依赖的操作系统的桌面风格提现了桌面软件在交互体验方面的需求另一个方面是跨平台性它同时支持windows和Linux在跨平台的同时保证了自身UI和交互效果的独立性。值的一提的是对于桌面软件的UI和用户体验Linux和Os X从一开始就做得很好相反windows一直在快速开发上做文章这一点一直到.NET 的Winform都没有什么大的改变。我们不能说在windows上做不出炫酷的或者交互良好的桌面软件毕竟强大的系统API能让我们无所不能但是这是开发者的追求不是这个技术体系的给我们的引导结果是大多数windows桌面软件都是灰色的几乎没什么好的交互效果这可能有点偏激。现在我们简单总结下桌面软件开发有两方面的问题成为制约1) 跨平台性2) 低成本的UI和交互自定义对于跨平台性上面我们提到应用程序的底层是系统API系统API具有天然的系统隔离性对于开发人员处理这种兼容问题难度往往要大于实现应用程序本身。即使是Qt这样的UI库也根本解决不了问题UI库可以移植单应用程序本身不能移植。随着python和Java这样的具有独立运行时的框架出现之后跨平台的问题似乎看到了曙光。在操作系统API和应用之间加了一个隔离层解放了开发者。微软的.NET也模仿了Java但是只是实现了在windows 各个不同的系统之间的可移植性微软现在也加入了开源大军.NET也可以支持在LinuxOS X上运行了。虽然运行时本身还具有系统的强依赖性但是大多数开发者而言我们可以忽略这些关注框架提供的基础类库而不是系统API。跨平台性似乎暂时得到了好的解决方案虽然并不完美但是从生产力的角度确实得到了空前的提高我们暂且认为问题得到了解决那么UI和交互呢顺着刚才的路线去想在可跨平台的语言基础上构建强大的UI库是不是就解决了这个问题呢确实有人在这样做但是却没有真正的成功者。问题出在哪里了呢在语言和框架发展的过程中尤其是互联网的发展专家们抽象和发展了应用程序的基础功能比如文件访问、网络请求、压缩解压缩、加密解密等等这些内容都被集成到了可跨平台的基础类库中UI和交互一直做为附属品在这些语言和框架中没有得到足够的重视。但是是人们不重视UI和交互吗答案是否定的随着互联网的发展UI和交互越发的得到重视而且空前发展UI和交互有了单独的语言来处理和定义——HTML和CSS。可是遗憾的是这两门语言并没有运用到桌面应用里来在编程领域出现了前端和后端的划分出现了C/S和B/S的划分出现了专门的前端程序员和后端程序员却没有桌面程序员。这是历史的发展我们无可厚非而且要快乐的接受。HTML和CSS是全新的语言和c/c、Java/C#、Python都有本质的区别首先它面向UI和交互可以近乎精准的还原设计其次它们是声明性语言不是命令性语言。声明性语言为设计而生你只需告诉它我要个黑色背景就可以了这是语言层级的支持而不像命令式语言想的是如何实现一个黑色背景。除了HTML和CSS之外和它们绑定到一起的还有Javascript一门很长一段时间只能运行在浏览器中同DOM进行交互的语言。现在我们再回头看桌面软件开发在UI和交互方面没有办法和网页端应用相比这是从诞生开始就注定的宿命。在网页端应用飞速发展这些年里尤其是HTML5出现之后人们仿佛觉得桌面应用已经日落西山了早晚有一天会消亡。虽然桌面应用的开发者数量在减少构建在纯桌面环境的的应用也越来越少但是桌面环境并没有要消失的迹象即使是浏览器本身也仍然是一个桌面应用它也只能完成桌面应用的一小部分功能只要你要使用桌面就会有桌面应用的需求。桌面应用开发技术也没有止步并和浏览器技术一步步融合。融入互联网融入web是人类生活的需求同时也是桌面软件开发技术的需求在软件内部嵌入和控制网页成为最初的诉求。于是浏览器的功能被精简成为组件被引入桌面软件中微软凭借自家浏览器技术的强项在.NET 中引入了WebBrowser控件这一举措方便了开发者同时因为WebBrowser控件强依赖系统安装的浏览器微软的浏览器又和系统依赖过强导致控件在不同的客户系统上的展现行为也会有差别。当然离跨平台又远了一步。图0-4 WebBrower控件示例同时我们也应该看到控件的方式虽然精简了浏览器功能但是也扩展了Web应用的能力控件是可以和调用者进行通信的也就意味着控件是可以通过“后端代码”访问本地资源的。但是在这一方面并没有长足的发展。同时Google开源了Chromium项目基于C的CEF项目将Chromium进行改造使之成为一个控件相对于微软的WebBrowser控件这一举措意义很大。Chromium是开源的可以更好的和调用代码进行交互甚至可以扩展javascript接口使之可以调用操作系统资源。随着web应用的发展浏览器由于本身的定位和安全特性的限制很多需要和客户端交互的功能无法完成于是出现了浏览器扩展的概念但是扩展也不是无限制的。这方面微软对浏览器的扩展最为粗暴它直接支持Activex控件几乎可以无限制访问本地资源但是同时也打破了浏览器安全特性这也是一直到现在很多银行的网银只支持IE浏览器的原因。其他浏览器也在这一方面做出了妥协浏览器的Js或者本地扩展功能都被支持起来不过仅仅是妥协而已因为浏览器的使命不是开发桌面应用。在这期间微软做了很大的尝试首先是基于.NET框架的WPF微软推出了XAML语言全新的声明性语言想让开发者像写HTML一样编写软件的界面和交互这不正是广大开发者的心声吗可以说WPF是很成功的产品使用WPF我们已经可以能够开发出炫酷的桌面软件了。但是从跨平台性角度讲受.NET本身的制约另外并没有斩掉开发者和设计师之间的鸿沟。它仍然是传统桌面软件的延伸面向的是仍然是后端开发人员前端开发、交互设计师、UI设计师并没有被引入进来。图0-5 WPF微软在这个方向上并没有止步随着windows8操作系统的推出Windows Runtime浮出水面。微软运行使用HTML5和Javascript开发WinRT的应用看起来非常美好的一件事情但是在微软手里却多出了很多遗憾。虽然我们可以使用HTML5和Javascript开发应用甚至在移动端但是这些应用只能运行于Windows Runtime环境连Windows8的传统桌面环境都不可以更不要谈什么跨平台了。原因是微软直接扩展