版權(quán)所有，轉(zhuǎn)載注明。

桌面應(yīng)用軟件，在操作系統(tǒng)中，通過(guò)操作系統(tǒng)桌面窗體展現(xiàn)應(yīng)用內(nèi)容，并實(shí)現(xiàn)用戶交互操作。編程語(yǔ)言有很多種，但并不是每一種語(yǔ)言都具有支持UI開(kāi)發(fā)的能力，很多語(yǔ)言支持UI開(kāi)發(fā)能力，是有人專門為之實(shí)現(xiàn)的UI開(kāi)發(fā)支持平臺(tái)。簡(jiǎn)單地說(shuō)，需要有專門的語(yǔ)言UI庫(kù)支持，如C++中的Qt庫(kù)、MFC庫(kù)，Java的Swing、AWT相關(guān)依賴庫(kù)，否則語(yǔ)言是沒(méi)辦法進(jìn)行快速UI開(kāi)發(fā)的（可以通過(guò)編程語(yǔ)言調(diào)用系統(tǒng)函數(shù)，但很復(fù)雜）。

本文僅討論常用的編程開(kāi)發(fā)語(yǔ)言進(jìn)行桌面應(yīng)用軟件開(kāi)發(fā)的相關(guān)內(nèi)容，對(duì)于諸如Matlab的m語(yǔ)言、Labview以及其他的類似語(yǔ)言，并不適合廣泛的桌面應(yīng)用軟件開(kāi)發(fā)的情況，將不涉及。

1. 有哪些語(yǔ)言支持桌面應(yīng)用開(kāi)發(fā)

桌面應(yīng)用開(kāi)發(fā)的方式有很多種，一般分成三大類：
一是原生編譯運(yùn)行的開(kāi)發(fā)技術(shù)，這一類技術(shù)，通過(guò)編譯->可執(zhí)行文件方式，可執(zhí)行文件直接調(diào)用系統(tǒng)API，完成UI繪制等。這類開(kāi)發(fā)技術(shù)，有著較高的運(yùn)行效率，但一般來(lái)說(shuō)，開(kāi)發(fā)速度較慢，技術(shù)要求較高。
二是二次編譯或解釋運(yùn)行方式，這一類技術(shù)和將要說(shuō)的第三類技術(shù)類似，但又稍有一些不同，這一類語(yǔ)言是一開(kāi)始就有本地開(kāi)發(fā)和UI開(kāi)發(fā)的。一次編譯后，得到中間文件，通過(guò)平臺(tái)或虛機(jī)完成二次加載編譯或解釋運(yùn)行。運(yùn)行效率低于原生編譯，但平臺(tái)優(yōu)化后，其效率也是比較可觀的。就開(kāi)發(fā)速度方面，比原生編譯技術(shù)要快一些。
三是機(jī)箱模式，總是需要一個(gè)運(yùn)行外盒，才能夠運(yùn)行。這一類雖然類似于基于平臺(tái)或虛機(jī)，但是這一類一開(kāi)始的目標(biāo)不是桌面應(yīng)用，而是Web應(yīng)用開(kāi)發(fā)，包括了常見(jiàn)的RIA開(kāi)發(fā)技術(shù)和主流Web前端開(kāi)發(fā)技術(shù)。這一類技術(shù)桌面應(yīng)用開(kāi)發(fā)中，不外乎兩種方式，一種是單獨(dú)開(kāi)發(fā)了基于桌面的機(jī)箱，來(lái)提供運(yùn)行平臺(tái)。另一種就是對(duì)機(jī)箱打包嵌套，給機(jī)箱再加個(gè)外殼，讓機(jī)箱運(yùn)行在外殼上。運(yùn)行效率上，經(jīng)過(guò)不斷地革新和優(yōu)化，F(xiàn)lash引擎進(jìn)化、V8引擎的出世，總體上能夠滿足要求。開(kāi)發(fā)效率上，速度較快，畢竟平臺(tái)支持比較高級(jí)，很多東西直接拿來(lái)用。
目前比較流行的：

• 原生編譯：
  C++/MFC（Win）
  Objective-C（Mac）

• 托管平臺(tái)：
  C#/.NET Framework（Win）
  Java/Swing、AWT \*

• 富客戶端：
  Java/JavaFX \（Sun出的，富客戶端）
  ActionScript/Flex、Flash（Adobe Air、Adobe Flash） \（Adobe出的，富客戶端）
  SilverLight（微軟出的，富客戶端）（Win）
  Open Laszlo（挺渣的，我用過(guò)，效率低的不得了）

• Web式：
  HTML5/H5 + WebKit 、Node.Js（NW.JS）、Electron\*

• 其他：
  Python/PyQT、GTK+ \*
  Ruby TK\*
  Go \* （部分方言支持，入手要慎重）

• ** 有年頭的，但也有一些使用量的：**
  VB、Delphi

2. 選擇語(yǔ)言的評(píng)判標(biāo)準(zhǔn)

• 運(yùn)行效率
• 開(kāi)發(fā)效率
  貌似，運(yùn)行效率和開(kāi)發(fā)效率是一對(duì)矛盾的值，但隨著各類渲染技術(shù)、引擎、優(yōu)化的加深，這兩個(gè)值也開(kāi)始同步提高。實(shí)際上，下述的評(píng)判內(nèi)容，基本包含在了開(kāi)發(fā)效率中，只有各種依賴、支持良好，才能快速開(kāi)發(fā)，除此，還有語(yǔ)言的易用性。
• UI庫(kù)支持、渲染美化效果程度
• 網(wǎng)絡(luò)庫(kù)支持程度（是否支持網(wǎng)絡(luò)，網(wǎng)絡(luò)庫(kù)支持協(xié)議（TCP/IP？HTTP? SMTP？POP3？RTMP？））
• I/O支持
• 數(shù)據(jù)庫(kù)操作支持
• 算法庫(kù)支持程度
• 其他第三方庫(kù)支持程度，如JSON、XML支持，加密支持，壓縮文件支持等等
• 跨平臺(tái)能力（跨Windows、Linux、Macintosh OS X等操作系統(tǒng)）
• 新開(kāi)發(fā)技術(shù)學(xué)習(xí)成本
• 開(kāi)發(fā)平臺(tái)成本

3. 具體分析

以下將分析各種UI開(kāi)發(fā)技術(shù)的一些內(nèi)容。但主體趨勢(shì)無(wú)外乎以下方向：

• 運(yùn)行效率：原生 > 托管平臺(tái) > 富客戶端、Web

• 開(kāi)發(fā)效率：原生 < 托管平臺(tái) < 富客戶端、Web

就學(xué)習(xí)成本來(lái)說(shuō)，很難說(shuō)出誰(shuí)高誰(shuí)低，但是總體來(lái)說(shuō)，富客戶端和Web學(xué)習(xí)成本比較低，原生的學(xué)習(xí)成本比較高，因?yàn)樵乃嫦蜷_(kāi)發(fā)應(yīng)用場(chǎng)景比較固定，局限性大，所以考慮到技術(shù)人員的發(fā)展，成本算高的。

C++

基于C++語(yǔ)言進(jìn)行桌面應(yīng)用軟件開(kāi)發(fā)的框架和平臺(tái)較多，包括了Windows平臺(tái)流行的MFC、支持多平臺(tái)的Qt、GTK+等，都提供了GUI交互支持。

• 運(yùn)行效率

C++開(kāi)發(fā)的應(yīng)用軟件，需要針對(duì)運(yùn)行目標(biāo)平臺(tái)進(jìn)行單獨(dú)編譯、生成可執(zhí)行文件，運(yùn)行效率極高，具有較好的性能。

• 開(kāi)發(fā)效率

C++開(kāi)發(fā)要求開(kāi)發(fā)人員具有較好的C++基礎(chǔ)和應(yīng)用能力，否則將會(huì)極大的降低開(kāi)發(fā)效率。C++對(duì)內(nèi)存管理要求較高，需要耗費(fèi)較多精力處理。

• UI效果

UI效果與具體的GUI交互支持方式有關(guān)。
MFC采用貼圖方式美化外觀，且交互界面運(yùn)行效率高，在Windows平臺(tái)中，UI渲染有多種先進(jìn)的圖形庫(kù)和渲染引擎支持，能夠獲得極佳的UI性能和效果。

• 網(wǎng)絡(luò)支持

C++語(yǔ)言對(duì)網(wǎng)絡(luò)的支持較好，具有多種成熟的開(kāi)源網(wǎng)絡(luò)庫(kù)可使用，如重量級(jí)的ACE，Boost的ASIO、陳碩的Muduo，僅支持Linux的libev、主要支持Linux的libevent。

• I/O支持

C++語(yǔ)言作為編譯型原生運(yùn)行程序開(kāi)發(fā)語(yǔ)言，本身就具有對(duì)I/O的天然良好支持，通過(guò)I/O流能夠快速完成本地文件操作等等一系列I/O操作。

• 數(shù)據(jù)庫(kù)支持

C++語(yǔ)言對(duì)于數(shù)據(jù)庫(kù)支持，主要依賴于數(shù)據(jù)庫(kù)驅(qū)動(dòng)程序提供的接口支持程度，目前對(duì)絕大對(duì)數(shù)主流數(shù)據(jù)庫(kù)都有著良好的支持。

• 其他第三方庫(kù)支持

C++作為目前使用量較大的開(kāi)發(fā)語(yǔ)言，其各個(gè)方面均有較好的支持

• 跨平臺(tái)能力

C++開(kāi)發(fā)的程序跨平臺(tái)能力較差，需要針對(duì)目標(biāo)平臺(tái)進(jìn)行單獨(dú)編譯。當(dāng)所使用的框架、類庫(kù)不支持目標(biāo)平臺(tái)時(shí)，將導(dǎo)致失敗的跨平臺(tái)開(kāi)發(fā)。
MFC目前不支持跨平臺(tái)，僅支持Windows平臺(tái)。
Qt和GTK+對(duì)較多平臺(tái)均支持，包括Windows、Linux、Mac OS X。

• 成本考慮

C++語(yǔ)言開(kāi)發(fā)，一直是成本居然不下，前期開(kāi)發(fā)架構(gòu)搭建、業(yè)務(wù)邏輯堆砌成本高，后期測(cè)試、維護(hù)，每一項(xiàng)環(huán)節(jié)都占據(jù)了較高的成本使用。C++的開(kāi)發(fā)、維護(hù)，都要求參與者有著較高的開(kāi)發(fā)素養(yǎng)，因此人工成本也是一個(gè)大項(xiàng)。
基于成本考慮，C++項(xiàng)目適合于運(yùn)行效率要求高

C#語(yǔ)言

C#語(yǔ)言是Windows中的當(dāng)紅語(yǔ)言，在Web、系統(tǒng)服務(wù)、桌面應(yīng)用、富客戶端等多有涉及。C#基于.NET Framewrok開(kāi)發(fā)的桌面應(yīng)用軟件，也是Win系中的主流方式。
此外，隨著微軟的努力，感謝Visual Studio Core和.NET Code，實(shí)現(xiàn)了跨平臺(tái)開(kāi)發(fā)和運(yùn)行。

• 運(yùn)行效率

C#桌面應(yīng)用基于托管式運(yùn)行，效率相比于C++較低。

• 開(kāi)發(fā)效率

C#開(kāi)發(fā)效率較高較快，入門快、上手快，但后期優(yōu)化困難，需要較為深入的研究。

• UI效果

C#的UI效果通過(guò)皮膚控制。由于C#消耗資源較多，在低配機(jī)器上，UI流暢度較低。

• 網(wǎng)絡(luò)支持

C#網(wǎng)絡(luò)支持良好。

• I/O支持

C#本地化支持良好，面向?qū)ο蟛僮鞯姆庋b，使得各種I/O操作都很便捷。

• 數(shù)據(jù)庫(kù)支持

C#對(duì)SQL Server數(shù)據(jù)庫(kù)支持良好。對(duì)其他數(shù)據(jù)庫(kù)，需要特殊的支持。

• 其他第三方庫(kù)支持

C#本身做了較為完整的工具類封裝，不僅在基本的JSON之類的支持良好，在加密、編碼等方面也有著良好支持。

• 跨平臺(tái)能力

不太好，但是微軟正在致力于跨平臺(tái)。但微軟不應(yīng)該如此好心，他們從來(lái)不會(huì)讓客戶和用戶離開(kāi)win系平臺(tái)的，這也許只是他們放出的一個(gè)糖衣。

• 成本考慮

Windows平臺(tái)采用C#開(kāi)發(fā)簡(jiǎn)單的桌面應(yīng)用成本較低。大中型、復(fù)雜應(yīng)用需要慎重考慮。

Java

Java是目前服務(wù)器端的主流語(yǔ)言之一。Java語(yǔ)言用于桌面應(yīng)用開(kāi)發(fā)的產(chǎn)品較多，但更多的體現(xiàn)在Sun公司、Oracle公司自主研發(fā)產(chǎn)品，如Eclipse。一些對(duì)性能有較高要求的應(yīng)用，并不適合用Java開(kāi)發(fā)，而更適合用C/C++。但Java最為突出的有點(diǎn)是Write once， Run anywhere，跨平臺(tái)性無(wú)與倫比。

• 運(yùn)行效率

基于JVM的運(yùn)行方式，使得Java遜于C++。

• 開(kāi)發(fā)效率

有著Java基礎(chǔ)的開(kāi)發(fā)人員，能夠快速開(kāi)發(fā)。

• UI效果

依賴皮膚效果。控件豐富度，需要第三方支持，原生控件種類較少，頗簡(jiǎn)陋。

• 網(wǎng)絡(luò)支持

支持良好，同時(shí)擁有眾多第三方庫(kù)支持。

• I/O支持

支持良好。

• 數(shù)據(jù)庫(kù)支持

支持良好。

• 其他第三方庫(kù)支持

Java的第三方庫(kù)支持眾多。

• 跨平臺(tái)能力

Java有著良好的跨平臺(tái)能力。

• 成本考慮

Java開(kāi)發(fā)成本較低，但其UI性能較弱，需要考慮后期項(xiàng)目膨脹后的應(yīng)對(duì)辦法。

Objective-C

與C++同宗，但又有著很多不同的一門語(yǔ)言，隨著蘋果系列產(chǎn)品的暢銷，OC開(kāi)發(fā)也逐漸主流化。Objective-C由蘋果公司推出，主要面向Mac系列系統(tǒng)使用，跨平臺(tái)能力較差。

• 運(yùn)行效率

運(yùn)行效率較高，屬于原生編譯運(yùn)行。

• 開(kāi)發(fā)效率

熟悉OC語(yǔ)言，能夠快速開(kāi)發(fā)。

• UI效果

UI效果借助貼圖，控件樣式較多。

• 網(wǎng)絡(luò)支持

支持網(wǎng)絡(luò)，隨著OC火爆，很多第三方庫(kù)紛紛支持。

• I/O支持

支持本地化操作。

• 數(shù)據(jù)庫(kù)支持

支持Mac上的數(shù)據(jù)庫(kù)，如SQLite、MySQL等。

• 其他第三方庫(kù)支持

OC越來(lái)越流行，越來(lái)越多的第三方庫(kù)出現(xiàn)，支持越來(lái)越好。

• 跨平臺(tái)能力

不具有跨平臺(tái)能力。

• 成本考慮

僅支持Mac OS X。

富客戶端

富客戶端一度是瀏覽器的霸主，但隨著H5的興起，更多更絢爛的效果由H5實(shí)現(xiàn)，甚至H5頁(yè)肩負(fù)起了RIA的任務(wù)，老牌富客戶端開(kāi)發(fā)技術(shù)主鍵平淡，但不可否認(rèn)的是，以Flash為主的富客戶端依然對(duì)Web RIA擁有著不可撼動(dòng)的主流地位。本文主要討論桌面應(yīng)用，富客戶端中，很大一部分是可以實(shí)現(xiàn)桌面應(yīng)用開(kāi)發(fā)，當(dāng)前最流行的Flex/Flesh，是典型的代表。富客戶端技術(shù)開(kāi)發(fā)語(yǔ)言根據(jù)平臺(tái)不同而不同，包括了Flash/Flex的ActionScript/OpenLaszlo、JavaFX的Java、SliverLight的C#等等。富客戶端技術(shù)并不是一個(gè)單純技術(shù)，而是以其他開(kāi)發(fā)語(yǔ)言和技術(shù)支撐起來(lái)的復(fù)合型開(kāi)發(fā)技術(shù)。

• 運(yùn)行效率

富客戶端運(yùn)行基于其特定的環(huán)境和運(yùn)行平臺(tái)，如Flash播放平臺(tái)、JVM、.NET Framework插件等，從而導(dǎo)致了相比于原生編譯程序，其效率較為低下，從而不適合進(jìn)行復(fù)雜功能和高強(qiáng)度運(yùn)算處理應(yīng)用的開(kāi)發(fā)。
隨著技術(shù)不斷的革新，富客戶端在運(yùn)行效率上也有著較大的提升，但綜合來(lái)看效率普遍偏低，因此注重高效率的程序開(kāi)發(fā)可以繞過(guò)這一塊另?yè)裢贰?/p>

• 開(kāi)發(fā)效率

富客戶端開(kāi)發(fā)技術(shù)，往往是基于其他技術(shù)而形成的綜合技術(shù)。
Flash/Flex的ActionScript是一類面型對(duì)象的腳本開(kāi)發(fā)語(yǔ)言，該語(yǔ)言語(yǔ)法與一般面向?qū)ο箝_(kāi)發(fā)語(yǔ)言類似，在語(yǔ)法格式上，其變量聲明格式與傳統(tǒng)的編程語(yǔ)言略有不同（類型后置寫法），但一旦熟悉之后，基本無(wú)礙。除此，F(xiàn)lash/Flex的UI界面開(kāi)發(fā)，通過(guò)特殊的皮膚機(jī)制實(shí)現(xiàn)，需要投入一定的精力研究。
JavaFX目前支持Java語(yǔ)言開(kāi)發(fā)，對(duì)于一般Java開(kāi)發(fā)者來(lái)說(shuō)，需要熟悉JavaFX帶來(lái)的新內(nèi)容，能夠較快上手。
SliverLight基于C#語(yǔ)言，C#入門極易，但優(yōu)化困難，所以入門級(jí)開(kāi)發(fā)較快，后期優(yōu)化比較扎手。

• UI效果

富客戶端的UI效果，一般靠皮膚支撐。JavaFX在3D圖形支持上稍弱，有待加強(qiáng)。

• 網(wǎng)絡(luò)支持

富客戶端天然具有網(wǎng)絡(luò)支持能力，通常具有較強(qiáng)的多媒體支持能力。Flash/Flex支持更多的多媒體網(wǎng)絡(luò)協(xié)議，如RTMP流媒體傳輸協(xié)議等，很多在線直播平臺(tái)均采用該網(wǎng)絡(luò)技術(shù)。

• I/O支持

富客戶端桌面應(yīng)用開(kāi)發(fā)中，借助本地化操作支持，能夠較好實(shí)現(xiàn)I/O操作。

• 數(shù)據(jù)庫(kù)支持

富客戶端開(kāi)發(fā)中，不同類型對(duì)數(shù)據(jù)庫(kù)連接和操作的支持不一致。ActionScript對(duì)這一類支持較差，并且缺乏第三方庫(kù)支持。JavaFX天然使用Java語(yǔ)言，在各類數(shù)據(jù)庫(kù)支持方面較好。SilverLight采用C#語(yǔ)言，對(duì)SQL Server數(shù)據(jù)庫(kù)支持良好。

• 其他第三方庫(kù)支持

由于Adobe開(kāi)發(fā)的Flash/Flex ActionScript開(kāi)發(fā)平臺(tái)，尚處于閉源狀態(tài)，因此第三方拓展較少，但其本身已經(jīng)具有較多的支持，如JSON支持等。
JavaFX能夠使用Java開(kāi)發(fā)中的各類第三方庫(kù)，支持絕對(duì)良好。

• 跨平臺(tái)能力

富客戶端都具有較好的跨平臺(tái)能力。

• 成本考慮

富客戶端開(kāi)發(fā)成本，需要根據(jù)不同類型RIA區(qū)別對(duì)待。
綜合考慮，JavaFX開(kāi)發(fā)成本較低。Flash/Flex開(kāi)發(fā)成本稍高。

Web

Web語(yǔ)言實(shí)現(xiàn)桌面應(yīng)用開(kāi)發(fā)，實(shí)際上和RIA類似，主要的套路是利用瀏覽器引擎完成UI渲染，目前比較主流的是IE瀏覽器引擎和WebKit引擎。隨著H5前端技術(shù)、NODE.JS等的大肆興起，桌面應(yīng)用逐漸冷淡。但基于瀏覽器引擎開(kāi)發(fā)桌面應(yīng)用的技術(shù)，卻因此而得到發(fā)展，如基于node.js的NW.js、基于io.js的Electron等等，以及國(guó)內(nèi)很多公司自主研發(fā)的開(kāi)發(fā)平臺(tái)。

• 運(yùn)行效率

隨著V8引擎的發(fā)布，Node.js借助其實(shí)現(xiàn)了服務(wù)器端JS編程的可能，作為桌面應(yīng)用，其性能也有大幅度提升，可以與其他桌面應(yīng)用開(kāi)發(fā)技術(shù)相提并論。

• 開(kāi)發(fā)效率

使用前端技術(shù)開(kāi)發(fā)，對(duì)于有前端開(kāi)發(fā)經(jīng)驗(yàn)的人來(lái)說(shuō)，在克服了開(kāi)發(fā)環(huán)境和運(yùn)行環(huán)境搭建后，稍微摸索下開(kāi)發(fā)技巧，之后的路將會(huì)比較坦蕩。

• UI效果

參考H5的效果，不難想象，UI效果將會(huì)達(dá)到比較炫酷的級(jí)別。

• 網(wǎng)絡(luò)支持

NW.js使用了WebKit支持UI渲染，同時(shí)使用node.js完成本地化操作，網(wǎng)絡(luò)支持通過(guò)node.js，支持良好。

• I/O支持

本地操作極為良好，通過(guò)JS提供的多種API，能夠輕松完成各種本地操作，因此對(duì)I/O支持良好。

• 數(shù)據(jù)庫(kù)支持

目前，有很多的JS數(shù)據(jù)庫(kù)操作庫(kù)，這方面支持較為良好。

• 其他第三方庫(kù)支持

隨著WebKit桌面應(yīng)用開(kāi)發(fā)的高速發(fā)展，同時(shí)以node.js等為主的JS后端編程實(shí)現(xiàn)，其他支持都已經(jīng)逐步跟進(jìn)，達(dá)到較好的支持。

• 跨平臺(tái)能力

不言而喻，擁有良好的跨平臺(tái)能力。

• 成本考慮

開(kāi)發(fā)成本主要在環(huán)境搭建和開(kāi)發(fā)入門方面，一旦入門后，有著豐富前端開(kāi)發(fā)經(jīng)驗(yàn)的人員，能夠快速進(jìn)行開(kāi)發(fā)。同時(shí)，隨著相應(yīng)技術(shù)的發(fā)展，文檔、資料、開(kāi)源代碼等逐漸豐富，開(kāi)發(fā)成本逐步降低。
維護(hù)成本方面，并非涉及到全新的開(kāi)發(fā)語(yǔ)言，成本因此能夠控制在較低的程度。

Python

一種膠水語(yǔ)言，目前也支持了UI開(kāi)發(fā)。

• 運(yùn)行效率

一般。

• 開(kāi)發(fā)效率

快。

• UI效果

局限性較大，控件庫(kù)豐富度較弱。

• 網(wǎng)絡(luò)支持

支持。

• I/O支持

支持。

• 數(shù)據(jù)庫(kù)支持

支持。

• 其他支持

支持良好

• 跨平臺(tái)能力

良好。

• 成本考慮

成本較低，但不適合大型應(yīng)用開(kāi)發(fā)。

Ruby

Ruby on Rails是當(dāng)前炒作的比較火爆的一個(gè)概念，在Web開(kāi)發(fā)中也有著一席之地。Ruby用于桌面應(yīng)用開(kāi)發(fā)，基于TK平臺(tái)實(shí)現(xiàn)。Ruby，作為一個(gè)簡(jiǎn)單面向?qū)ο蟮哪_本語(yǔ)言，其優(yōu)點(diǎn)是使用簡(jiǎn)單，開(kāi)發(fā)快速。

• 運(yùn)行效率

一般，腳本語(yǔ)言的效率都不會(huì)太高。

• 開(kāi)發(fā)效率

快，Ruby比較簡(jiǎn)潔，開(kāi)發(fā)速度較快。

• UI效果

作為腳本語(yǔ)言，由TK決定，控件庫(kù)豐富度較弱。

• 網(wǎng)絡(luò)支持

支持。

• I/O支持

基本支持。

• 數(shù)據(jù)庫(kù)支持

良好支持。

• 其他支持

良好支持

• 跨平臺(tái)能力

采用虛擬機(jī)運(yùn)行，跨平臺(tái)能力良好。

• 成本考慮

成本較低，但不適合大型應(yīng)用開(kāi)發(fā)。

Go

Go語(yǔ)言的一些方言，目前支持UI開(kāi)發(fā)。但即便是神一樣的方言設(shè)計(jì)者，也有力不從心的時(shí)候，也無(wú)法與大型公司為靠山的開(kāi)發(fā)平臺(tái)豐富和穩(wěn)定。但Go語(yǔ)言的開(kāi)發(fā)速度，絕不是蓋的。

• 運(yùn)行效率

視情況而定，由方言的特性決定。

• 開(kāi)發(fā)效率

快。

• UI效果

絕大多數(shù)個(gè)人貢獻(xiàn)，所以，控件庫(kù)豐富度較弱。

• 網(wǎng)絡(luò)支持

視情況而定，由方言的特性決定，一般是支持的。

• I/O支持

視情況而定，由方言的特性決定，一般是支持的。

• 數(shù)據(jù)庫(kù)支持

視情況而定，由方言的特性決定。

• 其他支持

視情況而定，由方言的特性決定。

• 跨平臺(tái)能力

視情況而定，由方言的特性決定。

• 成本考慮

成本較低，關(guān)鍵是快速開(kāi)發(fā)效率高。

小結(jié)

1. 以C++語(yǔ)言為基礎(chǔ)的桌面應(yīng)用開(kāi)發(fā)技術(shù)，具有較高效率，但跨平臺(tái)實(shí)現(xiàn)比較困難，需要具體平臺(tái)庫(kù)支撐，但Qt和GTK+基本上達(dá)到了跨平臺(tái)的能力。
2. OC專門針對(duì)Macintosh OS X，雖然具有較高的效率和較強(qiáng)的UI效果，但是跨平臺(tái)能力限制了其廣泛發(fā)展的可能性（除非蘋果稱霸天下……）。
3. C#是目前Windows系統(tǒng)上桌面應(yīng)用開(kāi)發(fā)使用最多的開(kāi)發(fā)技術(shù)之一（好像把之一去掉，不過(guò)還有MFC鎮(zhèn)壓著，不可造次），C#雖然在效率上低于C++，但是在開(kāi)發(fā)效率上甩C/C++幾條街啊。
4. Java在UI、用戶交互開(kāi)發(fā)方面，一直是不溫不火的狀態(tài)，Swing、AWT已經(jīng)是過(guò)去式了，但做一些小工具還是可以考慮的，畢竟Java語(yǔ)言會(huì)的人多。
5. 富客戶端開(kāi)發(fā)技術(shù)，在桌面應(yīng)用開(kāi)發(fā)市場(chǎng)中也占有一席之地，尤其是網(wǎng)絡(luò)多媒體應(yīng)用，我鵝的某寵就是這種模式。Flash/Flex是富客戶端的大哥大，SliverLight也曾紅火一時(shí)。JavaFX最近新軍崛起，是否能夠占據(jù)導(dǎo)一份市場(chǎng)，也要拭目以待。
6. WebKit為基礎(chǔ)的Web式桌面應(yīng)用開(kāi)發(fā)，以Web引擎作為UI渲染工具，是一個(gè)高明的設(shè)計(jì)和思路。隨著H5、Node.js的興起，Web式桌面應(yīng)用也在逐漸火爆，某道翻譯軟件目前應(yīng)該是在借鑒NW.JS的基礎(chǔ)上使用自主研發(fā)的heX完成UI開(kāi)發(fā)。
7. 至于其他的語(yǔ)種，如Python、Ruby，腳本開(kāi)發(fā)語(yǔ)言，效率不高，UI有限，但能夠?qū)崿F(xiàn)快速開(kāi)發(fā)，小型軟件方面也有一定優(yōu)勢(shì)。Go語(yǔ)言作為程序節(jié)的高冷語(yǔ)言，部分方言有對(duì)UI的支持，開(kāi)發(fā)速度絕對(duì)快，但是要求對(duì)函數(shù)式編程有一定掌握，稍有些門檻。

那么該如何選擇

１、 首先判斷項(xiàng)目類型，對(duì)運(yùn)行效率需求如何、對(duì)一些特殊的技術(shù)指標(biāo)要求。如果有著較高的運(yùn)行效率要求，那么選擇范圍也就較低了，多在原生編譯和高度優(yōu)化的平臺(tái)上選擇。如果對(duì)UI靈活性、自主性要求較高，也要重點(diǎn)考慮原生編譯，因?yàn)樵幾g更接近底層，自由度更大。
2、 開(kāi)發(fā)速度要求：如果有快速開(kāi)發(fā)要求，盡量避免原生開(kāi)發(fā)，一個(gè)是跨平臺(tái)比較麻煩，另一個(gè)是原生開(kāi)發(fā)，即便是提供了較多的UI支持庫(kù)，也不可能像基于平臺(tái)的技術(shù)有著良好的封裝。
3、 考慮技術(shù)人員的底蘊(yùn)：如果具有特殊的技術(shù)人員，精通某一方面，那么必須要把這個(gè)考慮進(jìn)去，這不但是技術(shù)方面的保證，也是開(kāi)發(fā)成本的保證。
4、 后期考慮：從長(zhǎng)遠(yuǎn)考慮項(xiàng)目的要求，有沒(méi)有什么特殊的考慮，如以后往Web上靠，那么就考慮NW.JS或者Electron等。往流媒體富客戶端，那么要考慮Flex技術(shù)。等等。

結(jié)尾

支持桌面應(yīng)用軟件開(kāi)發(fā)的技術(shù)，只要具有相應(yīng)的UI支持基礎(chǔ)就能夠?qū)崿F(xiàn)，因此相關(guān)技術(shù)并不止上述幾類，但上述幾大類是目前桌面應(yīng)用開(kāi)發(fā)的主流開(kāi)發(fā)技術(shù)，占據(jù)了絕大部分的市場(chǎng)。其他較小眾的桌面開(kāi)發(fā)技術(shù)由于其小眾化、文檔匱乏，較難流行。