在桌面开发上,我已经尝试过许多框架和组合,比如Qt/PyQt,Electron,Flutter,Winform. 如今跨平台风气正盛,包括MAUI,Flutter以及Kotlin MultiPlatform(KMP)等等都风头正盛. 但我的理解是作为个人开发,很多时候并不需要写跨平台的桌面应用,不如写原生的.
目前我的理解是:
- 需要仔细思考产品跨平台的必要性,跨平台并不是free launch.
- C++的桌面程序框架也有很多,但许多人因为语言问题放弃了,着实可惜.由于c++的高性能和gl图形库诞生许多简单的GUI,比如awesome-dear-imgui和raylib
- Qt框架不只是GUI,拿他跟其他UI库比较不公平.它提供了包括网络库在内的功能,而这本身就是C++相比其他现代语言在标准库和生态的差距. 此外Qt还有结合JS的QML,QWebEngine一堆技术.
- 使用Web技术开发桌面应用的开发体验仍然有待提升,目前React Native发展正盛,也是得益于前端的蓬勃生态.
- c++、Rust编写程序有相对更高的性能,可以写成库供其他语言的UI应用调用.
- 微软目前还是在基于XAML的桌面应用开发上发力,MAUI和WinUI3是微软主推的,在win11以及将来都是windows桌面开发重点,Avalonia也很不错
- Lazarus可以用于C++桌面应用的快速开发,此外还有C++ builder社区版试用C++ Builder社区版
- Flutter,KMP(包括jetpack compose)以及SwiftUI的写法类似(移动端应用写法),不同与xaml也不是同于new对象. 它们都是从移动端技术向跨平台应用发展折射到桌面开发的,一些技术栈和思想和做Qt、Winform的人可能不太相同(Web技术也是).
这里我从WPF入手学一点基础,由此可以向WinUI3,Uno,MAUI以及Avalonia桌面应用开发发展(后三者是跨平台框架).
资源
对于桌面应用框架,我有几点个人的偏好和思考.
- 虽然说对于有经验的程序员并不会因为编程语言问题而不去学习某个框架,毕竟桌面应用是一个domain的知识,这独立于保存语言.但实际这依然会对应用的生态影响,比如Dart语言使用人数相对较少,势必会对第三方库的生态造成影响,使得许多用户不敢深度使用,大企业就更别说了. 相比来说,React Native和Electron就完全可以借用web技术和生态,用户增长趋势稳定
- UI的写法虽然各个框架不同,但完全都能理解并且不会对编写程序有过多影响。目前UI的写法有类似QtWidgets和Winforms直接new对象,相对更原始,但控制性还挺高. 还有Flutter,Jetpack Compose,Kotlin Multiplatform and Compose Multiplatform这种是通过代码但是是嵌套声明式的写法,还有微软超爱的XAML写法和Qt Qml声明式写法,此外有web开发的大手,通过嵌入浏览器内核的html,css写法. 这些写法各有优劣,理性看待便是.
- 在渲染性能上,除了electron之外,其他框架大多数时候都没有什么太大的性能问题.而且electron只是使用web技术做桌面应用的一个例子罢了,此外还有Tauri 2.0 | Tauri,chromiumembedded/cef: Chromium Embedded Framework (CEF). ,sciter – Multiplatform HTML/CSS/JavaScript UI Engine for Desktop and Mobile Application,pywebview等等此外在跨平台图形绘制上,有像Flutter通过统一的绘制引擎保证一致性的,有在不同操作系统上使用不同绘制库实现的.
- 跨平台框架是个伪问题,或者说这个问题不是从解决实际问题出发的。许多时候都要认真思考一下跨平台应用的开发成本
- 鉴于许多桌面应用其实基本主流用户都在windows上,而windows原生应用,比如微软的技术就有非常多桌面框架(Winforms,WPF,UWP,WinUI),但许多开发者都担心微软又会立马抛弃,目前MAUI,Blazor,WinUI3这些技术是微软主推的,此外社区也有Uno和Avalonia 跨平台技术. 这也导致微软没有构建起良好的社区氛围,大公司的官僚气息、决策的朝令夕改使得开发者并不好受。希望目前微软能在技术上稳定下来Learning center | .NET,构建好技术文档和社区资源吸引开发者.
