如今 Windows 軟體開發究竟該用什麼庫，C#、Qt，還是其他？

01-14

我是一名 iOS 開發者。雖然開發是在 macOS 下但是平時生活用的依然是 Windows 系統。
在 Windows 下，我在網上找不到某些特定用途的軟體或是對別人的作品不滿意，所以我想自己寫 Windows 下的軟體。
那麼我的問題就來了，我該選擇怎樣的開發語言和庫呢？

Windows 下據說 C# 簡單粗暴，但是又聽說這玩意體現微軟的封閉思想，網上很多人不推薦啊！說什麼並不能學習到系統知識。（雖然我挺想了解下 Windows 的）
然後 Qt 手頭有本 C++ GUI Qt4，以前買了但是沒怎麼看。據說它能寫酷炫界面，但是出來的文件比較大，最近翻了翻覺得還不錯，不過書的年份是 2008 了現在都 2014 了不知道深入學習的成本付出值不值得……
請問各位大神我該去學習 C# 還是 Qt 呢？

在GUI開發領域就沒有完美方案，每個技術方案都有缺點，而且根據場景不同各自缺點的嚴重程度也不同。

所以我的意見是，反正哪個方案都有無數坑，你有能力填哪個的坑就用哪個吧。

比如我，C/C++水平足夠好，對Qt MFC都很熟，所以我敢用，有坑我能填，反正有源碼，大不了自己去給它打補丁。

C# WPF不開源，遇到坑只能繞開了。

webkit JS，我不熟，遇到坑我是真沒辦法，所以謹慎選用。

大部分的坑是到了項目的中後期，用戶量大了才能發現的，那時你想換框架早就來不及了。

比如 Qt 的 trayicon實現有兼容問題，大約有千分之幾的概率在Windows下托盤圖標會出不來，用戶量到了上百萬的級別你才能發現，所以後來我自己實現了TrayIcon。

Qt的字體緩存當字體很多的時候非常占內存，一位同事給Qt實現了帶內存壓縮功能的字體緩存。

比較流行的框架，你遇到問題可以去搜索，去問人，比較小眾的你到 Stackoverflow都找不到相關話題，只能自己搞定。

這就像有人總問魔獸世界裡哪個職業哪個天賦厲害一樣，沒有明確答案，因人而異，只能說你會用哪個哪個就厲害。

如果你問學哪個？既然你從iOS的 OC過來的，就學 C#吧！反正未來是屬於託管語言的。

剛好C#、C++、QT、winform、wpf都懂點，我來跟你說說。

C++和C#是編程語言，QT、winform、wpf是三種技術（其實是三種寫界面的UI框架）。

它們常見的組合有三種：

C++搭配QT；（C++搭配mfc已經過時，不推薦）

C#搭配winform；（我目前工作用這個組合）

C#搭配wpf；

你對C++和C#都不熟，而且只是想做一些稱手的小工具的話，C#合適得多，開發速度快。

wpf相比winform來說設計理念更先進，當然如果只要粗略區分的話，可以認為wpf能做出更華麗的界面，而且對於不同尺寸的屏幕適配性更好。

做出華麗界面的容易程度（例如電腦上360安全衛士界面）：wpf ＞ QT＞winform

wpf的界面代碼使用xaml 代碼（類似於XML）寫的，相對於winform的直接拖控制項、改屬性要稍微複雜一些。

wpf還有輔助設計界面的軟體叫做blend ，這個就厲害了，不展開講了。

總之，如果只要求快速開發，軟體丑點沒關係，那麼選擇C# + winform，如果想做出華麗的界面，特別是你本人還懂平面設計的話，選擇C# + wpf （都只需要安裝一個visual studio 就行）。

認真回答問題的來了：

我總結你的學習目的主要有兩個方面：

1、製作Windows下特定用途的軟體

2、想學習了解Windows的系統知識

如果僅僅針對 Windows 平台，C# 比 Qt 有太多優勢，就像你在 Mac 下，Objective-C 肯定優先於Qt。從語言本身的角度來說，經過高度封裝的C++某些時候還是不如C#來的方便，我個人來說，雖然Qt用的比C#熟，但偶爾臨時做個什麼小工具啥的，還是喜歡用C#，因為開發快，沒別的。

Qt的優勢，一是跨平台，二是高效率。如果你是追求這兩個目的，就不用猶豫了。

你說Qt能寫出酷炫界面，其實 WPF 何嘗不是呢，想不到什麼是前者可以寫出，而後者無能為力的。

至於你想通過這兩個玩意了解Windows的系統知識，可能很長一段事件都不太可能。因為這兩者都太上層了，你很難見到下面的具體實現。就如寫個註冊表吧，Qt里QSettings、C#里Microsoft.Win32.Registry 都會讓你感覺無比自然簡單，誰會由此想到RegOpenKeyEx之流的痛苦難受呢。

所以，了解Windows系統最直接的辦法，就是直接學習Windows API。

或者你可考慮了解下MFC、WTL之類？

PS：C++ GUI Qt4那本書不算老，深入學習，你會收穫熟練的Qt技能，不會白費功夫的。現在市面上能找到的Qt5的書，都是扯淡。相信我。

作為一個研究多年windows界面開發的人來回答下，我認為到目前為止沒有真正完美的解決方案。是的，真的沒有。每種方案都有自己的特殊缺陷，以至於誰都只能在自己特定領域玩。一個個的點評：

MFC、WTL：不用我說了，設計理念太老。窗口間的組合出控制項這模式在windows上有很多bug（如windowless模式，窗口消息傳遞太多坑）。

qt：這個的主要問題是太大了。如果你要做互聯網客戶端，一定會對體積有要求，否則安裝率上不去。

Wpf：這貨就不說了，必須帶.net，而且首次啟動慢，部署困難。xp沒預裝.NET框架。要知道這世界上還有15%左右的xp。但不得不承認框架的設計理念是非常優秀的。

Duilib：以及之類的界面庫（soui、gaylib），這個是我研究最多的，然而深入的擼了幾年後，我徹底放棄了。最大的原因是沒有大公司支持，沒有人員投入，你是做不完善的。

就比如設計器、richedit，文本排版，都是天坑。

然而，如果想做一款小巧的互聯網客戶端我還是首選這類庫。原因是小巧，可控。不支持的效果以及缺陷，只有有一兩年工作經驗的程序員都可以hold的住。

Electron，以及nwjs：我比較看好的方向，但問題還是太大，現在不打包有100m+了！如果想做分發簡直是惡夢。（當然我現在在搞的miniblink就是想解決這問題。只是目前里可用還有段距離……）

綜上，如果你是個有2年C++開發經驗，又想做個可以小巧需分發的客戶端，最後還是要選duilib之類比較靠譜。畢竟代碼量小，可控，有什麼新需求好往裡加。

如果不管大小，或者用戶環境可控，那麼選wpf吧，功能強大。

如果不是那麼的在乎大小，但用戶環境不可控，建議選QT。WPF部署起來還是麻煩了點，QT可以避免，而且QT效果也不錯。

另外我想講講這些解決方案里除了electron這類的另外個大缺點：這些庫或框架都是自己定義的xml（或別的配置方式，比如我，就是json），學習需要成本，招人也需要成本。而且作為開發，你學習了這套庫，去別的地方可能完全沒地方用。你的項目上一波開發人員跑路了，重新找人，成本要哭。

所以這是我推薦electron這類框架的原因。H5的方案，到哪都能招的到人，更關鍵的是，開源前端框架現在不要太多，要任何效果任何控制項網上一抓一大把。曾經我是個H5黑，現在我棄暗投明了，H5帶來的開發效率提升真不是別的框架能比的。

待續…

實名反對一切說 Qt 是 GUI 庫的所有人！

人家官方定義是 C++ Framework！跟 Boost 是一個級別的。

也就是說一旦你使用了 Qt，你就可以享有它一切開發特性，包括且不限於資料庫、網路、XML、XML Pattern、3D、JavaScript、大量模板類，甚至 Qt 也有一套自己的聲明式語言，用於開發富客戶端，很是炫酷。而且 Signal / Slot 所有 C++ 實現中也是 Qt 實現得最好。初學者使用 Qt 完全與使用 .Net CLR 一樣，學習曲線很緩和。

唯一的缺點就是太大了……

如今已經2017年，我還經常看到有人，拿著Qt4的特性批判一番Qt，然後拿著C#的新特性，讚美C#。我沒用過C#，沒用過WPF，我也不評價這些，因為我沒有親自使用過、對比過，這樣得出的評價肯定是片面的，不客觀的。

但是我用過Qt，至少我能從Qt的角度來看這個問題。

首先我假設，開發只考慮Windows平台，那麼我的結論是：

如果你已經有了C++的基礎，並且願意學習QML語言，那麼可以考慮下Qt。要是沒有C++基礎，並且也不願意學習，那麼我不建議使用Qt，因為綜合來說，學習成本太高。

我認為Qt現在的方向在於QtQuick這個框架，這個不但是我認為，從官方現在的宣傳，開發力度來看，傳統的QtWidgets已經基本不改動了，現在精力全在QtQuick這裡。QtQuick其實就是QML開發界面，C++開發底層。那麼這個角度來說，Qt4就已經淘汰了。當然Qt4裡面確實也有QML，但是和5比起來差別是在太多。目前如果要用Qt，我推薦5.7這個版本。

當開發者可以熟練使用QML做界面，C++做底層這樣的方式後，就可以發揮出Qt的優勢：

首先是開發界面速度快，這是得益於QML本身結構類似於CSS（不是XML），並且有js用於做處理邏輯，開發效率自然不言而喻。不像是以前widgets時代，看起來是拖控制項，但是想把界面做的靈活，還是逃不開用C++寫界面的問題。

其次底層C++，保證了在界面快速開發的同時，在功能上也不失去靈活（配合C++11）和性能，並且伴有大量Qt的優質庫，對於大部分需求，根本不需要找第三方庫，直接搞定。比如說JSON解析、XML解析、資料庫、日誌系統、測試系統等等，Qt不但已經準備好，而且和Qt本身高度融合。

另外QML開發出來的程序，天生就是OpenGL加速，Windows上DPI什麼的自然不是問題，想怎麼適配就怎麼適配。來個複雜的特效，上個粒子系統，也沒有問題。

至於程序打包後，算上庫，zip壓縮後20MB以內肯定妥妥的。我覺得對於現代的一個程序，這不是問題。除非寫的是什麼超級小工具，一定要力求100KB搞定整個程序，那當我沒說過。

對了，為什麼說綜合學習成本高，因為我看現在要用好Qt，不但要會C++，而且要會C++11，還要多學一個QML。雖然QML本身沒多少東西，但是說到底也是一堆知識點，不是說1個星期就可以掌握的那種，也需要一段時間的學習和積累。

個人是玩Qt的、、、當然傾向Qt、、

但是說句客觀的話，如果你只是為了Win平台的話，而且沒有很高的性能的要求，還是C#.net好、、、

如果肯呢個平台多樣，就去玩Qt吧、、

基本贊同掃地僧看法，duilib沒有資金僱傭優秀的人才去完善她也一直深以為憾。未來我也看好瀏覽器平台應用到桌面開發，因為目前桌面平台開放性和標準化程度落後太多。近期的方案，electon不太清楚，但nwjs bug和多，用戶量大和需要長久維護的要慎重，兩者的內存佔用也很難控制。我個人覺得react native或weex應該去開發pc版本。不知微信小程序之類的平台會不會有pc版，pc版容器什麼時候會native化，但感覺以後可能會有

主選 c# + winform，備選 py +pyqt。

沒有較極端的要求，我認為 Windows Desktop UI 正確的方向是 WPF。Per-monitor DPI Aware、硬體加速（Direct3D DirectWrite）、XAML、靈活的布局、MVVM 以及強大的 C#（就說一點：用 await 寫 I/O 程序）。說性能差什麼的，都是哪年的黃曆了，Visual Studio UI 也不算簡單了，面對大文件瞬間完成語法高亮，內存佔用也不高，只是吃磁碟 I/O（當然我相信這跟 WPF 沒關係）。

比某些代碼質量糟糕、用 GDI 渲染文字、不支持高 DPI 的垃圾框架不知道高到哪裡去了。

短平快的話：

1. Electron：js開發界面，可用cpp擴展

2. PyQt5: Py開發界面，可用cpp擴展

3. QWebView：js開發界面，py cpp做後端（非界面部分）

比開發速度，上面三個方案完爆c#

Qt5以後，Qt全面使用gpu加速繪製。

微軟自己都很少用 WPF，做個 vscode還要去用 electron。

界面腳本化是大勢所趨，弄個界面就該快，改兩行代碼按個快捷就該跑起來，避免改個文件一編譯就等半天，或者出個bug找兩天：

編碼-測試-編碼這個核心工作流越短越好。上面三個方案都跨平台，況且人的時間本來就有限，上面幾門技術學了你不虧，其他好多地方都用得上，關鍵是開發效率都比c#高。

再比較下性能：https://www.youtube.com/watch?v=8O-0k4MLKs8

Qt 5.6 MinGW 和 .NET 4.5 WPF 跑同一個測試，Qt 的速度是 WPF的兩倍！

主要是兩個技術序列：

1. 基於web技術的桌面產品，比如vscode，atom，Slack，網易雲音樂，釘釘之類的成熟應用挺多，文檔也豐富，問問題有人答，搜問題搜得到。

短短兩年間，這麼多來自微軟，Facebook, Slack，Docker等公司的桌面產品使用 Electron開發出來，更多的可以到：Electron Apps 自己看。

2. 基於PyQt的桌面產品：DropBox client, R Studio, Calibre, Eric Python IDE, Spyder, PDF Catalog Creator for Magento，出活快，寫小工具用它根飛一樣，做專業系統可以和C++Qt無縫整合。

R Studio

Spyder

上面兩張 R Studio / Spyder 的截圖，PyQt做的，不算簡單吧，這界面，想看酷炫的可以去看 PyQt的 demo，不要覺得 PyQt有多大， DropBox客戶端打包出來 24MB，比很多手機app都小。

Electron 內核整合了 NodeJS，所有 NodeJS能用的模塊 js都能用，比如：

node-ffi/node-ffi 模塊，可以讓你直接調用 C++寫的動態庫，不需要用C++寫個node擴展：

var ffi = require("ffi");


var libm = ffi.Library("libm", {

"ceil": [ "double", [ "double" ] ]

});

libm.ceil(1.5); // 2

// You can also access just functions in the current process by passing a null var current = ffi.Library(null, { "atoi": [ "int", [ "string" ] ] }); current.atoi("1234"); // 1234

Python/PyQt也有類似的介面。

WPF線上產品不考慮，不要看著你們辦公室沒人用xp就以為天下沒xp了，你去二三線城市的網吧里看看，大範圍的xp。現在這個時間點國內還有 45%的電腦跑xp，這問題三年內不會緩解，你要做線上系統你基本不可能拋棄這群用戶，做內部工具又沒有上面三個快捷，更何況跨平台問題。

雖然我承認 C#是一門好語言，但堆邏輯還是沒有 js，python之類的快，且不管 C#還是 WPF，應用面太窄，學會了將來能用的地方也不多，不值得投入。而上面我給你推薦的三套方案，所涉及到的技術應用範疇都廣的多，比如你學會了js/Electron，可以無縫把你桌面應用遷移到 web上，比如同時開發web版本，可以稍微該一下做成移動app，學了python/qt，也有好多別的事情可以做。

所以，學一個東西要考慮它本身的價值

ps：用過win32，owl，vcl，mfc，c#，tk，wx，手擼DirectUI，qt

不會坑你

既然你問出這個問題了，那麼肯定希望找個簡單方便的

那就沒有比.net更方便的了

很多人推薦wpf，我倒覺得沒必要，winform一樣很快速方便，在XP和win7冷啟動速度比wpf快很多，後面的windows下wpf需要的東西感覺已經被預熱了，沒那麼慢。對。net版本要求低，反正等了解了過後再使用wpf一點不晚。

net體系入門非常簡單，深入有價值，學習曲線平緩，潛力大，任何時候裝個最新的VS就能開搞，運行庫的問題我倒是覺得你設置好app.config後，讓人家自己去裝一個最好，現在連顯卡驅動都幫你安裝.net4.0了，應該不是啥大問題。

qt 也是個成熟的庫，但畢竟是個很特別的c++體系，入門應該是比較大的障礙。

vb6 以前也是神器，雖然是被拋棄的，還得用很老的ide，隨便寫點程序可以，深入學習沒啥價值了。

delphi 在當年也是很方便的東西，好多這樣子的程序，現在一樣沒啥價值了。

MFC 當年就很麻煩的東西，而且沒啥價值了。

C#的上手速度和開發速度都比Qt快得多，如果程序不太複雜，用Qt的還在學習階段，用C#的已經開發完了。

C++本來就比C#複雜得多，也不太適合做GUI（C++ Builder除外），所以選C#無疑。

如果喜歡C++的粗野和強大，那就首選Qt，首選，看書的話，就選我的《Qt Quick核心編程》和《Qt on Android核心編程》吧。

作為根紅苗正的革命。。。啊，不對！嗯。。。開源小將，豈可與黑五類（微軟/英特爾/甲骨文/思科/易安信）出身的黑崽子為伍！

咱們自然是要用Java。。。等等。。。Java雖然不是出身黑五類，但是現在被黑五類家庭收養了啊。這樣算起來也是黑崽子啊。。。而且，聽說他幹活慢吞吞的總是磨洋工，這是充滿了對我革命工作的不滿和消極抵抗啊。嗯，堅決不能用Java！！！

根紅苗正。。。根紅苗正。。。似乎只有老大哥C++可以干這活，其他的什麼GO啊Python什麼的專業不對口。不過，老大哥幹活雖然效率特高，但工錢也是高到天上去了，這不符合革命工作要多快好省的原則啊。頭疼。。。。。。

啊，對了，聽說現在微軟棄暗投明，加入了我開源大家庭並且把C#給開源了。這樣C#就應該不算黑崽子了，這貨據說一向幹得多要的少，吃的是草，擠出來的是奶。NND，照這樣說，這不是我革命同志是什麼！就是他了！

裝個VS沒事兒瞎搗鼓唄。高能提示：安裝時請去掉SQL Server Express組件。

c#是語言，qt是gui庫，你的兩個選擇就不是一類東西，沒有可比性。qt應該和wpf比較。

如果只開發windows下的軟體，c#是首選沒什麼好說的。

另外學習c#，還可以使用xamarin進行ios和android開發。

最後我不知道c#體現了微軟的什麼封閉思想？c#的語言規範早就公開到ECMA, c#的編譯器也即將開源，nb的人可以自己實現個c#，我覺得已經夠open了

現在的程序員啊，我問他們為什麼不努力成為一流的程序員，他們說坑就那麼多划不來。那我問他們為什麼不隨便學個用用，他們就說不能成為一流的程序員了。

我呸！

什麼封閉開放，都比這些人強多了。這些人的理性水平之低，根本選什麼東西來學都改變不了命運的。

順便推薦一下www.gaclib.net ，跨windows/linux/mac/ios/android/wp的C#封閉是吧，我把它抄到C++順便開源了，只支持windows，這樣就開放了，啊哈哈哈。

企業級應用，快速拖動各種強大的第三方控制項，特別是資料庫的表格之類的，並且客戶是以Windows系統為主，那麼開發用C#的WinForm。

如果非常在乎程序的性能，用VC++內嵌彙編。

如果想盡量節約時間，盡量多使用現成組件，用Java。

如果是想做多平台GUI，用QT。

如果你是高手，你會用C++寫Core，C#寫GUI，Java寫資料庫中間件，然後用thrift、pb之類的開源RPC框架結合起來。

如果你是屌炸天的美術專家 + 多媒體專家，建議用Flex或Air，它能帶給你無窮的想像力，並且專門面向美工之類的。

果斷wpf吧，你既然想在windows上gui開發，去看看微軟最新的技術不是很自然的么，再說wpf都10幾年前的技術了。

就像你在蘋果的生態里自然想優先選擇蘋果自己推薦的技術，想上windows看看微軟的唄。

我以前也喜歡別人一說什麼就跟人爭什麼跨平台云云，現在戒了。