不仅仅在操作系统层面,在整个IT行业,通用性和性能,一直都是天平的两端。硬件层面,通用的CPU,性能远不如各种专用的ASIC芯片;CPU内部,通用的整数指令性能远不如各种专用运算指令如浮点、SIMD、加解密等指令。软件层面,通常也是一个流程写到底,比多次调用各种通用的封装好的基础函数性能要好。
今天很多各种虚拟机语言如Java、.Net,脚本语言如PHP、Python,以及以HTML/CSS、XML、JavaScript结合的Web应用这类大量实时文本解析的技术普及,前提是今天的硬件性能比日常应用的性能需求高的多。我举个例子,大家今天依然很常用的一些系统操作、文档处理等应用,早了不说,其实和Win95+Office95,可以说90%常用功能一致的。Win95+Office95的硬件需求才多高?不说刚上市发布时的最低配置要求,哪怕后来相对普及时的主流硬件配置,不过奔腾MMX 166,32M内存。如果按照大家更熟悉也和今天体系更接近的Windows 2000+Office 2000,发布时很常见的奔腾3 733/800+128M内存也是跑得很流畅了。而今天的主流硬件性能,不说和老旧的奔腾MMX 166比,哪怕和奔腾3 800比,单核性能也少说提升十多二十倍,多核性能就更不用说了。
所以现在我们看到的操作系统没有“完全”屏蔽底层,为软件环境提供统一运行环境,具体来说是几个原因:
1、历史遗留。今天大家常见的操作系统都不算太年轻,毕竟开源的Linux成熟之后,想搞个操作系统自己定制改拨下,总比从头开发一个,解决各种硬件驱动问题要方便得多。而Linux是1991年开始开发,当时的主流硬件最新也就是486 33/50 MHz,并没有足够的性能余量去追求通用性。Java出现是1995年,开始流行是2000年之后,这个时候主流CPU主频已经突破1 GHz了,但这个时期,性能依然是阻碍Java普及的一大原因。
2、硬件性能还不够。对于文档处理这样的日常应用来说,今天的硬件性能是过剩了,可以去追求通用性,这也是今天很多系统、应用以Web APP形式出现的前提。但还有大量的多媒体创作、高性能计算以及多种需要处理大量数据运算、用户请求的企业应用仍然是性能渴求的。这些应用目前为止还无法以牺牲性能为代价去追求通用性,反而是为了性能还需要牺牲通用性,例如用类似汇编的intrinsics来编程。
3、x86在2005-2015年期间的强势。随着Intel在1998年推出至强,x86开始进入服务器市场。便宜的价格,加上集群技术的成熟,很多以前代表着高性能、高可用性的CPU,例如Alpha,SPARC,POWER等都被抢掉了相当部分市场,同时先进制程的芯片研发、生产成本越发高昂,这些CPU都在逐渐走向消亡——到了今天,仅仅剩下IBM的POWER凭着兼容性和高可用性、以及商业机构客户提供的高昂利润还在坚持。事实上,Windows NT一直到Windows 2000的BETA版,都是同时支持x86、Alpha、MIPS和PowerPC的,虽然还做不到题主所说的应用与硬件无关,但一份代码在多个平台上分别编译后运行是可能的。随着这些x86以外的指令集架构的CPU消亡,操作系统和其他软件开发商自然也没有动力去做跨硬件平台的工作——直到这几年ARM凭借低功耗在移动平台一枝独秀,加上智能手机、平板电脑这些移动设备的流行,快速迭代终于摸到了x86的尾巴,服务器市场、移动计算市场都出现了极少量的ARM设备,才又有了这种跨平台的需求出现。
因为慢。安卓的Java就是屏蔽了底层架构,为应用软件提供了统一的运行环境。但是,在安卓上跑游戏,用Java不够快,所以游戏厂商纷纷选择直接接触底层架构,用NDK/C/C++直接开发ARM原生库,然后挂接到Java中使用。有的游戏甚至整个引擎都是C/C++写的,Java只做为启动部分,加载完ARM原生库,绘图工作转移出去之后就不再有动作了,所有3D/绘图操作全部由ARM原生库完成,这样才能在手机上达到想要的性能。
当然,如果你愿意接受一半的续航、一半的帧数、两倍的发热,在安卓上直接用Java跑大型游戏也不是不可以。如果某个大型游戏是纯Java写的,没用任何原生库,那它就能百分之百与x86电脑上的安卓模拟器兼容。但是代价是什么呢?在手机上运行的时候,估计就只有旗舰机能勉强流畅游玩了,更低配的手机可能会直接卡成PPT。
不过,小游戏,特别是非3D游戏,完全没这种问题,Java显然能满足它们的性能需求。但如果他们最终没选择用Java开发,那么唯一的担心可能是:Java太容易破解了。而C/C++要破解起来就难很多,外挂的技术门槛就要更高。
备注:Kotlin也是Java虚拟机语言,在安卓内,和Java运行在同样的虚拟机里,所以上面所有对Java的表述也同样适用于Kotlin。
而Kotlin在iOS上是直接编译为目标平台机器码(比如ARM指令集),此时它就不符合题设条件了,换一种CPU就不能运行,所以不用考虑这种情况。
这其实是个伪命题。
操作系统给应用软件提供的API,本来就是统一运行环境。操作系统一直都在努力给软件提供一个统一的运行环境。他们确实是这样想的。
如果为x86Windows写的代码全都能在armWindows上面运行,微软开心不开心啊?当然开心,睡觉都要笑醒。——所以操作系统产商当然有动力提供统一运行环境。
但是呢?实际上应用软件的开发者有千千万万,需求有形形色色,人的行为总会有多样性。所以实际上他们做出的事情就不可预期。
举个例子:Android 系统。一开始就设计为使用java虚拟机,这,总该是非常统一的运行环境了吧?
然而实际上呢?由于有相当多的现有代码使用C或者C++开发,要复用这些代码必须使用NDK。另外就是,java虚拟机并没有提供足够完备的功能,比如串口通讯就必须依赖C写的库。jvm无法完成。
各种原因敦促了 android 必须开放NDK编译,然而NDK意味着,不同的CPU架构必定会生成不同的代码(除非是实时编译)。
为了解决这个问题,最常见的办法是:将所有可支持架构的编译结果都打包到程序中,程序运行的时候判断当前CPU架构决定加载哪一份代码。
比如,苹果当年切换到intel处理器的时候,就是这么做,要求开发者打包应用的时候将新旧两个体系的应用都打包进去。
Google有没有这么要求?有:Google 要求 NDK 开发者对 arm,arm64,mips,x86 等架构全都进行打包,而安卓的安装器在安装app到目标设备的时候,会根据目标设备的实际架构,只选择目标架构安装上去。
我们看到,Google的想法是好的,实际上呢?实际上,开发者们根本就不愿意打包所有架构,往往都偷懒只打包 armeabi 架构。
然而现实是:7年来生产的所有新款手机都是 arm64 架构的。而Android Studio从3.4开始就默认只打包手机对应架构的ndk包(对于手机来说,这意味着AS默认只打包arm64架构,除非你在gradle设定中强制设定ndkfilter)。
可是相当多的开发者依然,宁可在gradle中强制设定ndkfilter,也不愿意提供arm64版本的包。——当然,他们同样也没有提供 x86,没有提供 mips 的包。
那么问题来了,操作系统能不能只接受源代码,然后,到不同平台架构上实时编译,这样确实就什么架构都能跑了?
答案是:操作系统确实能够这么做,但软件开发商不愿意啊。
如果你的代码支持让操作系统实时的到目标机去编译,那么你这个代码就相当于完全没有加密的,很容易被破译,从公司管理的角度,这样暴露自己的IP(智力财产)是不合规的。
我的看法:理论上可以这么做,只要规定软件发布必须把主流CPU架构都打包就好。但实际上只有苹果能做到这一点。苹果可以规定你不按照我的要求打包就不让你发布。安卓跟Windows就不行。
这大概就是自由的代价吧。允许软件开发有更多自由,就必然没法阻止开发者使用或者只提供某个特定架构才能用的库。操作系统如果无法从软件发布的源头上管控软件发布,那么就没有办法支持所有的情况。
在操作系统看来,它是把cpu直接共享给了应用程序,而不是把cpu抽象成什么东西来间接供应用程序使用
应用程序使用cpu并不需要它来代劳,它只是在各个程序之间做一个调度而已
如何使用cpu是你自己的事,我不管也不关心你是咋用的,更没有所谓的“屏蔽底层架构”的概念。你要想实现这种特性,那就你自己来搞,我不想掺和这种事
很少有人不基于框架直接写GUI界面啦,我这个回答就从GUI框架反过来推什么语言做GUI合适。(只聊桌面端GUI编程框架)
几乎是C++领域最流行的跨平台桌面端软件开发框架了,这个框架是两个挪威人在1995年创建的,发展至今可以说历史相当悠久,稳定性也很有保障。很多大公司都在用它做界面比如金山的WPS。
它内置了自绘引擎,也就是说界面上的一个按钮,一个文本框,都是Qt的引擎自己画的,这保证了基于Qt开发的软件界面在不同操作系统上看起来是一模一样的。
它提供了大量的与界面无关但与软件开发息息相关的API,比如、网络、文件系统、剪切板等,而且让这些API在不同的操作系统下都有效,这极大的节省了开发人员的时间。
但它也有一些缺点,比如在处理一些特殊需求上很不方便,比如:目前Qt有没有比较好解决高分屏下缩放显示的方案?,Qt没有真正完美的无边框解决方案吗?等,在一些组件的渲染上也会出一些隐藏的较深的问题(QListItem),一旦遇到,就很难解决。
Qt近年来不太专一,qml,qtquick等,搞了很多,而且这些新玩意儿一直不温不火,有些模块做了又废弃了,比如:qt script,搞来搞去,搞的模块繁多且复杂,用起来不是很舒服。
Qt有界面描述语言(XML描述界面),可以通过设计器拖拽空间设计界面,编译期界面描述语言被转义成C++代码,性能上没啥损失。
Qt商业授权不太友好,开发商业应用一定要谨慎,之前听说有公司为此付出了高额的版权费。个人开发者可以免费使用。Qt的免费版本不允许静态链接,会有版权上的限制,但开发者还是可以通过一些特殊的编译方法静态连接Qt的库的。
除了使用C++开发Qt应用外,开发者还可以使用其他语言开发Qt应用,最流行的就是使用Python基于PyQt做Qt应用了,其他语言的绑定不是很成熟,但PyQt仍然有版权的问题。
GTK是1997年创建的,也非常成熟稳定,是C语言开发的,但有很多语言的绑定,比如官方支持的JavaScript、Rust等,当然用C++语言操作GTK也很方便,它也有自绘引擎(Cairo),也提供了大量系统相关的API,商业授权也非常友好,基于GTK开发商业软件不用担心收到律师函的问题,虽然它是一个跨平台桌面软件,但它似乎只在Linux操作系统领域流行,有非常多的Linux桌面软件都是基于GTK开发的。
这也直接导致GTK的维护者很重视Linux领域的发展,而忽视Windows和Mac领域。这个框架提供的很多API,只在Linux下有,Windows和Mac下没有。这样的API数量众多。甚至在Windows下编译一下GTK的源码都要比Linux下难很多。而且GTK的渲染引擎在Windows下性能表现也不如在Linux下好。
GTK在Windows上也没办法静态连接,它到不是因为版权的问题,而是它依赖MSYS2的一些库,这个库用于在Windows上模拟Linux环境,这也是为什么GTK在Windows上表现不佳的原因之一。
另外,由于GTK是C语言开发的,所以开发风格也很C语言化,这对于部分开发者来说可能觉得繁琐。
wxWidgets是1992年英国的一个大学教授开创的跨平台GUI软件,也非常成熟稳定,商业授权非常友好。它没有自绘引擎,而是对不同平台下的界面API做了整合和封装,这样开发者在Windows下开发的软件看起来就是Windows窗口风格、Linux开发的软件看起来就是Linux窗口风格,这对于某些软件来说,正是他们想要的,但要想搞一些花哨的特效就没那么容易了。它同样也提供了大量的系统相关的API供开发者使用。
它是C++开发的,所以对C++开发者非常友好,除此之外它还支持静态连接,也就是说开发个应用不用分发给用户一大堆dll,当然Qt也支持静态连接,但是你得自己编译Qt的源码(不是很方便),而且Qt的授权规则也不允许普通开发者这么做。
它会有些小问题,比如我之前提的:wxEVT_NOTIFICATION_MESSAGE_DISMISSED event emit twice,但总体来说还是非常稳的。除了开发的界面比较死板外,没啥大的问题。目前使用这个框架开发软件的人越来越少了。
fltk是1998年创建的跨平台开源GUI框架,历史悠久,商业授权友好,而且C++之父也用它,它非常轻量级,支持静态连接,一个简单的应用编译后只有500K左右,非常赞,
它有自己的自绘引擎,没记错的话用的是OpenGL,但它的重绘机制是按区域重绘的,如果组件A所在的区域上存在组件B,那么A组件重绘时,会把B组件的给重回掉,开发者必须自己写代码处理这种情况。想象一下,如果你想实现一个A组件fade out的同时B组件fade in的效果,就会非常麻烦。
FLTK提供的一些组件样式都比较刻板,绘图API也比较少,你想实现一个漂亮一点的圆角按钮(它内置圆角按钮的圆角大小是不能改的),必须自己画,而且还得借助一些非常奇葩的手段才行(如果你想知道,可以联系我)
它是C++开发的,但API不够现代,用起来总体还算舒服的,它有Rust绑定:fltk-rs。它的用户比前面三个都少。它提供了一些与界面无关的操作系统API,但非常少,几乎可以忽略。
Duilib
是2010年国内一个开发者开发的GUI开发框架,因为底层基于DirectUI开发,所以只支持Windows平台,不支持跨平台,开源协议友好,商用没有任何问题(需要附加Lincence文件),国内有很多大厂基于这个技术做桌面端应用,比如网易、腾讯、百度,这个框架是基于C++开发的,对C++开发者友好。但框架本身还有一些问题,比如对高分屏支持不佳、特殊控件绘制上也有一些小问题,除了界面相关的API外,几乎没有提供系统级的API,作者纯粹是用爱发电来开发这个框架,所以更新不是很及时。
相对来说网易基于Duilib开发的分支更完善一些:NIM_Duilib_Framework,添加了高分屏支持、多国语言、整合了多线程处理的支持,但环境搭建相对比较麻烦。如果开发者要用这个框架,一定要用develop分支下的代码,master分支下的代码问题很多,这个框架看上去也是作者一个人努力的成果。
Sciter是2006年创建的跨平台闭源GUI框架,足够稳定,商业授权不友好,但个人开发者可以随便用(只能用动态链接库),一旦公司规模超过3人,就得买版权了(有权静态连接)。
它内部封了一个浏览器核心,让开发者使用HTML,CSS,JS来创建界面,但对这个浏览器核心做了大量的精简,不像Electron和NW.js动辄上百兆的体积,它只要6M就够了。当然这也意味着有些浏览器特性它是不支持的,比如CSS3的flex布局,它就不支持(但它提供了自己的flex布局实现方式)。以前它使用自研的一个脚本语言(和JavaScript很像),自从集成了Fabrice Bellard大神的QuickJs之后,就全面支持JavaScript了。它还对一些特殊的场景做了内置的支持,比如渲染大列表。
它使用C++开发,对C++开发者很友好,有Rust、go、Python等语言的绑定,但都是社区提供的,质量堪忧。有很多知名厂商都用这个库做界面,比如360、teamviewer、赛门铁克等。
RmlUi和Sciter很像,可以看成Sciter的替代框架,但RmlUi这个项目有三界作者,一个一个的弃坑不知道新任作者会不会弃坑,目前还不是很成熟,比如我正在尝试帮作者解决的CJK输入法的问题,目前还不推荐大家使用这个框架。
CEF是2008年创立的,基于Chromium的跨平台GUI框架,稳定且商业授权友好,国内很多大厂都用的CEF:比如微信桌面端、网易云音乐桌面端、QQ桌面端、微信桌面端、MATLAB、FoxMail、OBS Studio,装机量破亿。
由于它几乎封了一个完整的Chromium,所以体积非常大,但支持所有的HTMLCSSJS特性,它几乎不提供任何与操作系统相关的API,创建个托盘图标、读写个文件啥的,都要开发者自己完成,它是C/C++开发完成的,对C++用户非常友好,它有gopythonjava等语言的绑定,但都是社区提供的,质量值得担忧。
它对Chromium封装的很好,避免了开发者直接与Blink、V8、Chromium等复杂的代码打交道,很多功能都有默认实现方式,遵从约定由于配置原则,有经验的C++开发者可以很轻松的驾驭CEF框架。
由于Chromium是版本弟,所以CEF版本发布也非常频繁,很多被标记为稳定的版本,还是会出一些莫名其妙的问题,选一个好的版本非常重要。
与Electron一样,它也是分主进程和渲染进程的,所以开发者要非常娴熟的运用跨进程通信的技术,虽然CEF提供了跨进程相关的API,但复杂度还是有点高的,使用的时候要认真细心。
这是微软的跨平台GUI框架,不仅仅支持桌面端,还支持移动端,但官方并不支持Linux的桌面端(黑人问号,感觉与微软近些年向开放、开源的大方针相悖),这个框架新的狠,至今还没发布稳定版。目前还没什么人用。而且不知道将来会不会被微软放弃。
它是.NET平台下的GUI框架,有自绘引擎,对C#开发者很友好,界面依然是用XAML描述的,可能很多人一听到XAML就直接弃坑了。XAML表现力确实弱一些,我觉得WPF没火起来跟XAML有直接关系。
使用这个框架开发桌面应用得封一个.NET框架给用户,当然有了.NET框架应用程序访问一般的系统级API也就不成问题了。
这是JetBrains搞的跨平台GUI框架,也非常新,前段时间刚刚推出1.0.0版本,但这个版本还不是很稳,至少比Flutter Desktop的第一个稳定版要差很多。同样也几乎没什么人用。
它的自绘引擎用的是Google的skia,这个自绘引擎稳的很,Chrome和Flutter都是用的它,所以排版、绘制、渲染之类的工作不太会出问题。比Java生态圈里的Swing和JavaFx要好很多。
JetBrains的东西当然对Kotlin开发者友好啦,Java生态下的很多东西你都能用,访问系统级API也没啥大问题,同样也得考虑封一个JRE给用户。
这是谷歌的跨平台开发框架,开源、免费、文档齐全、投入力度大且持久,同样也新的很,Windows版本刚刚发稳定版,Mac版本还没稳定。
如果你完全没搞过移动端的flutter,想用这个框架开发桌面应用,那么意味着你要学的东西还挺多的。好在dart和flutter入门都不是很难,学习曲线比较平缓。
由于flutter在移动端积累了很多年,所以界面上的一些东西在desktop端都比较稳(skia自绘引擎),与操作系统相关的东西还不成熟,生态也不太好,比如你想订制一下窗口的标题栏,想访问一下注册表这类工作可能得自己想办法。不过它有类似FFI的支持,跟C/C++语言打交道很方便。
开发者直接使用Dart语言描述界面,这会导致众多大括号嵌套在一起的问题,可能很多开发者不习惯。
这是微软Edge浏览器团队推出的跨平台GUI引擎,是闭源的,目前只支持Windows,对C#和C++开发者友好,如果使用C#开发,就得考虑把.NET运行时分发给用户,如果使用C++开发,就得自己处理系统级API的操作,webview2本身是不对系统级API做封装的。
这个框架推出也没多久,很多API也还不稳定,更值得担忧的是这个团队,他们前不久刚刚放弃了自己的浏览器核心转而使用Chromium浏览器核心,不知道他们会不会放弃webview2这个框架。
它的优势是可以复用系统当中已存在的webview2二进制资源,也就是说它虽然封了一个Chromium浏览器核心,但如果你可以确定客户电脑已经存在了基于webview2开发的应用,你的安装包体积可以足够小。
它也是多进程架构,甚至比Electron还要多一个进程(为了复用二进制资源),资源占用比较多。
这个库使用操作系统的浏览器引擎来达到减小安装包体积的问题,Mac上使用Cocoa/WebKit,Linux上使用gtk-webkit2,Windows 10上使用Edge(也就是上一个小节里提到的webview2),它应该是不支持Win7的。开发者要考虑前端代码浏览器兼容的问题。
开源且免费(MIT)有go、Rust、Python等语言的绑定,不过官方支持的是go语言,C和C++,操作浏览器的API非常少,不支持自定义scheme,更别提系统级API了。
采用的技术方案与webview类似,所以安装包也足够小,非常新,还没发布稳定版,开源免费。webview框架碰到的问题TAURI都有,
使用Rust开发,将来会支持Deno,作者说将来会直接使用webview的技术来支持多平台,
NW.js最早把Chromium和Node绑定到一起,用前端知识做界面,用Node技术访问操作系统,最早叫node-webkit,在2012年创建。NW.js基于MIT开源,可以无忧使用。没记错的话,微信小程序开发工具是用NW.js开发的。作者是英特尔的员工,英特尔的一些工具也是用NW.js开发的。
除了Chromium和Node的能力外,NW.js自己也封装了一些系统级API,类似托盘图标、剪切板、系统菜单这种,但数量明显比Electron要少。
NW.js可以在多个窗口间共享同一个Node.js上下文,而且还可以通过配置让Node的上下文和Dom上下文混合,这给开发者带来了很多便利。心智负担减少很多。不像Electron要时刻想着进程间通信,哪些模块当前进程不能用这类问题。
NW.js虽然起步早,但奈何没有杀手级应用,周边的生态和工具链没发展起来。用的人越来越少,维护的投入也不如Electron大,再加上Chromium更新非常频繁,导致NW.js的有些API也不是很稳,恶性循环加剧。
Electron的作者曾经在NW.js团队工作过(NW.js项目贡献第二多的人就是Electron的作者),后来辗转到了github公司,于2013年在创建了Electron,也是个开源免费的产品。由于VSCode、slak等国际型产品都选择了Electron,所以从者甚众,生态和周边工具链也完善的多。虽然开发方式上有点蹩脚的地方(多进程架构及模块归属进程),但瑕不掩瑜。
Electron每创建一个窗口都会多一个进程,这使Electron创建窗口的效率不高(秒级),NW.js有复用进程的机制,即使新窗口加载完全不同域的页面也不会创建新的进程(毫秒级)。这也是为什么很多基于Electron开发的应用都使用Dom模拟弹窗的原因。
无论是浏览器相关的API,还是系统级API,Electron提供的都比NW.js多。
--------2022-02-25更新--------
这些框架除了对开发者使用的编程语言有要求外,还有一个重要的差异就是有没有独立的界面描述语言(也就是UI DSL),这非常重要,涉及到一个框架表达业务的重要能力。
类似XAML、qt的ui文件、HTML+CSS都是界面描述语言,下面这种也可以算界面描述语言,但我感觉它不够纯粹(flutter、qml和Compose Multiplatform都是类似这样的):
panel { row { checkBox(...) row { textField(...) // indented relatively to the checkbox above } } }
但无论如何,显而易见的是,没有任何一个界面描述语言能比的上HTML+CSS组合。想想看:HTML里各种花里胡哨的语义化标签和Dom操作技巧,CSS里的布局方式、伪元素、动画描述...,对比之下你就会觉得XAML、qml直流都是弟弟。
除此之外,一个优秀的GUI框架还有两个重要的需求,这里我简单聊聊:
强大的事件处理机制必不可少。
想想这些:鼠标事件、键盘事件、触屏事件...界面加载完成、媒体播放结束、元素大小改变...网络状态变更、数据段传输完成...另外,还得处理事件冒泡、事件捕获、事件分发吧...
qt的开发者曾经说过qt的SIGNAL和SLOT机制是有性能问题的(但影响很小)
强大的异步处理机制必不可少
你不能在用户处理业务逻辑的时候,让界面渲染工作阻塞,这就需要一个强大的异步处理机制,让开发者自己去开线程去完成业务处理,无疑是又麻烦又会增加开发者的心智负担。
我记得很早之前在C# WinForm应用中,点击一个按钮,如果不用Invoke执行逻辑处理的话,界面就会卡死。
这么看来,在你的GUI应用里包一个浏览器核心还是挺有必要的,这样你就可以用HTML+CSS强大的能力来描述你的界面,用JavaScript强大的事件处理机制和异步处理机制来完成用户交互。
可能有人会想,这会带来很多问题呀,比如应用体积会增大的100M以上、会占用更多的CPU和内存资源,还会更耗电等等。
确实,目前来看这些都是问题,但仔细想想,这些问题应该不会持续太久,网络会变的更快,用户的磁盘和内存会变得更大,CPU处理能力也会更好,耗电的问题当然会持续存在,甚至会愈发耗电,但电的供应会持续增长呀。
web相关的技术之所以胜出,并不是这些技术的设计者有多厉害,而是这20多年间,有大量的人涌入了这个领域,前赴后继的推动着它前进。其他任何一个领域都没有这么热火朝天的景象。推荐大家看看我的另一个回答:
------------2022-02-27更新----------
用Web相关的技术做GUI应用的优势是,让开发者可以把大部分精力投注在业务本身上,而不是处理与GUI相关的技术细节。
实际上所有的框架,都应该是这个目的,比如ORM框架,目的应该是让开发者把大部分精力投注在业务与数据之间的关系上,而不是管理关系型数据的技术细节。
当然这肯定是有损耗的,在性能、稳定性、资源消耗上,都会有所削减。而且,因为有框架的存在,开发者很难深入到框架内部做一些特殊的事情。比如,我们该如何修改HTML的排版渲染机制呢?
所以,有些框架注重性能,有些框架注重开发效率,开发者做选择题的时候也应该衡量这两个问题,你的应用对哪些方面要求多一些呢?
你如果要开发一个视频监控系统,没多少业务功能,但要24小时不间断的记录视频数据,随时调取某一段时间的视频数据,这种应用可能Qt是最好的选择。
你如果要开发一个类似飞书的团队协作应用,业务逻辑复杂的一塌糊涂,而且要在短时间内满足更多用户的需求,占领更多的市场,那么Electron可能是更好的选择(目前飞书已经不再用Electron了,他们自己编译了Chromium核心,自己封了一个类似CEF的框架)
目前微软、谷歌、JetBrains等公司都非常重视桌面端开发框架,也在推各自的框架产品,说明桌面应用领域并没有没落,反而应该更加受到重视。
虽然移动端应用大行其道,但我认为,只有生活、社交、轻娱乐等方向上的应用在移动端有较好的发展。文档协作、大型游戏、开发工具、专业管控软件等应用还是在PC端发展的更好一些,毕竟PC端有更多样的输入输出设备、更广阔的显示和交互的空间,更强的存储和计算能力。
希望桌面软件开发领域的从业者都能获得幸福。
满屏荒唐言,一把辛酸泪,一把辛酸泪,一把辛酸泪...
因为本身男人就有从来不给不能实现具现的人或物花钱的本能,加上中国男性更加的世俗化,以及中国社会对中国男性硬件方面的要求,导致追星给女偶像花钱这样的事情很难发生在当下的中国男性身上。
但并不是说男性对女性的需求就少了,因为在色情业方面,中国的卖淫业一直有着强大的供需关系,各种洗脚房暗娼,从高端到低端,从几千到几十,从一线城市到留守农村,从企业董事到农民工,买春现象非常普遍存在。没有庞大的消费者,商品早就消失了,根本用不着扫。
即便是前段时间爆出来,某官员给冯某主播刷了上亿的公款,最后还不是为了见面发生性关系么。
而对于女团这种东西,用部分新闻下评论就是“不给肏零分”,中国男性可能会欣赏某个女明星,听听她的歌看看她的剧,但是要花钱的话没戏,这一点男性比女性鸡贼的很,才不会浪费时间花费金钱去搞什么粉丝应援。
在这点上,我认为女性就做的不如男性,十分的傻,把精力和金钱都浪费到了无用的地方,有那个精力多锻炼身体、学习知识、关心政治,才有机会在政治、经济、文化领域夺取占比。