flutterqt的简单介绍

桌面端开发都用什么语言，简单分析下这些语言的优劣势对比？

目前，最优的选择有四个：

创新互联建站是一家专注于成都网站设计、做网站与策划设计,尚志网站建设哪家好?创新互联建站做网站,专注于网站建设10余年,网设计领域的专业建站公司;建站业务涵盖:尚志等地区。尚志做网站价格咨询:13518219792

1.如果只在win下使用，.net form是不二选择，可谓是又快又好，企业应用或定制开发都是相当好的，初学者也可以入手。

2.electron，跨平台。需要会前端，必须熟悉js、css和html。属于前端人员大杀器，如果是初学者，需要一下子学三样东西，再加上electron的进程间通信，可能会被搞懵。

3. qt5，可以使用qml（js语法）进行UI编程，但是需要懂c艹，但是写软件相当快，还可以写安卓、ios、Linux、嵌入式中的应用。

4.flutter，刚刚正式支持win平台的软件开发。谷歌出的这个东西，适合没有基础的初学者，因为是一个全新的体系，全新的语言，写ios、安卓非常高效，之后还会兼容h5。如果是初学者可以跟着走，值得尝试。但是新东西总有一些坑。

正式项目跨平台建议electron或qt，只用win平台强烈建议微软自己的net。个人技术尝试建议flutter。

桌面端开发跨平台的，如果你是轻量级的项目，那么我推荐你用electron, 目前使用Electron来开发的桌面应用非常多，我们最熟悉的比如Atom,VScode等等。

而且在github上也能找到许多应用使用了electron。

electron是Node，Chromium,html,css,js的结合框架，这就需要你有一定的前端基础。其实只需要了解一下electron的API就行了，其他的就像你在做web是一样的。

这种方式最大的缺点就是性能，还有透明窗口也有问题。所以在做需要性能方面占有很大成分的项目时，并不推荐使用这个方式。

那么其他的，就是最近几年使用比较多的windows directui框架，但它不是跨平台的。

那么就引出了qt，作为c++跨平台的界面框架，这个上手的话，我觉得对一般人是有难度的，因为首先需要扎实的c++功底，其次你要熟悉控件的制作原理，因为有时候你需要定制自己的UI控件。它现在在嵌入式，军工领域非常受欢迎。但是整个库非常臃肿庞大，而且开发界面的效率也非常低。如果来做互联网项目，迭代更新的速度根本就跟不上。

目前都只有大公司会采用，像maya这种生产力型的应用很多是qt做的。

还有一种是直接使用Cef加js，比如网易云音乐，就是这么搞的，但是很多和系统平台的交互接口你需要重写，等于是需要自己造轮子。工作量大，目前没有适合的框架给你套用，也需要扎实的c++功底。

其实pc端的应用基本也就windows会火一些，再加一个macos，那么选择qt应该会很好一点，毕竟你自己造一个跨平台的框架，太费时。总之，做跨平台就意味着，不可能做到既有效率又完美的实现各种功能，许多都要自己摸索。

win桌面端直接上visual studio啊！然后你熟悉什么语言？vb.net，c#，c++都有相应的win桌面工具。直接用就好了，非常好用

编程语言这种东西无所谓，只要能用啥都可以。 主要看你老板需要和你会用什么语言。

比如 我用AS编安卓程序，当然用JAVA。不过我后台最开始用ASP和ASP.NET来做，现在换PHP了。桌面端用QT或者VB做。 涉及单片机部分控制也用C。

现在做跨平台的了 开始以QT为主了。

只要能达到目的啥都可以。

学会1-2种 换其他的也不是很难。

对初学者来建议学C起步吧。

精通一门，重新学个语言入门也就1个月的事。

PC桌面程序，如果简单一点的，用pyqt5+python的开发难度和周期都比较现实一点

会C++ 用Qt5 非常不错 写代码效率很高

会js 用atom使用的那个框架

会Python用PyQt 写代码很快

会java用JavaFX

看语言咯

还可以用delphi，其firemonkey框架发布8年时间，支持跨平台：win，安卓，ios，macos，linux，后续支持webassembly，界面是控件拖拽布局所见即所得，开发效率较高。编译生成的是机器码，编译速度快，调试方便，其生成机器码运行效率较高，支持x86，arm的32位64位处理器。支持跨平台3D界面，蓝牙通讯，定位，重力，摄像等，支持多种SQL,NoSQL数据库。单个开发工具实现前后端开发，跨平台开发。适合个人和小公司用一套工具实现大部分开发需求。

主要有以下几种技术

### Duilib

#### 简述

Duilib是在Windows平台上使用最广泛的类库，使用C++和XML混合编程，国内很多计算机企业都喜欢使用这个类库，可能是由于他的技术许可比较宽泛的原因。

适合于界面比较简单的软件，视觉特效丰富，局限于Windows的平台。例子：360电脑管家。

#### 优势

#### 劣势

### Gtk、Qt或WxWidget：

#### 简述

三种基本可以做到跨平台的技术，使用C/C++开发，使用者广泛。其中WxWidget使用了API嫁接方式，Qt和Gtk（包括各种绑定技术）使用自绘技术。

结构严谨，软件可以做的很大很复杂。例子：WPS和Maya。

#### 优势

#### 劣势

### Electron：

#### 简介

使用Web技术开发桌面软件，基于Chromium（Chrome）引擎，使用JS编程语言，绝大多数使用者都是原来的网页开发者。

绝大多数都是爱好者使用，处于“勉强可用”的地步。

适合大面积静态展示型软件使用。例子：网易云音乐。

#### 优势

#### 劣势

### QtQuick（QML）

#### 简述

Qt公司开发的一款基于OpenGL的图形类库，有显卡加速，类似于Duilib。采用了C++与QML混合编程。QML类似于JavaScript语言。

QtQuick下一个版本在Qt 6上更加强大，业界期待已久。

#### 优势

#### 劣势

### Atk、Swing或JavaFX

使用Java语言开发软件，有JDK加持业界积累的众多Java类库支持。有不输于VS的IDEA加持，本应该更棒，只是现在已经式微了。

绝大多数使用者都是企业开发（不追求界面美观）、爱好者（开发顺手）。

### WinForm、WPF或Xamarin：

使用C#开发，WinForm和WPF局限于Windows平台。有VisualStudio加持使用很爽。

### Flutter:

使用Dart语言，新类库，bug可能会很多。

### SwiftUI或Cocoa：

苹果平台原生界面技术，macOS平台内建支持，不是macOS专用软件不推荐。

### Win32：

经典Windows 平台API，绝大多数只有一些老软件还在使用，不是维护老软件不推荐。

winform,不二选择

webview2，作为一个浏览器控件嵌入在桌面应用中，支持.net core和.net framework

iPadOS 16推迟发布：与其着急发，不如细打磨

随着9月份的临近，一年一度的 科技 春晚又要与我们见面了，届时除了iPhone、iPad这类硬件会准时发布之外，iOS 16及iPadOS 16也会和我们见面。但根据外媒的最新消息称，iPadOS 16的发布日期可能要延期到10月上旬。

图源推特

从WWDC 2019开始，iPad OS无论是大版本还是小版本都是与iOS同步推出，此次推迟不禁让人好奇，到底是设计师基于beta版本又做出了什么大幅度更新还是BUG数量太多，调试难度较大。但不管怎么样，如今大家对于iPad OS必然是较为不满的，尤其是对于iPad Pro 2021以及iPad Air 5的用户，明明都已经用上了M1处理器，但却用不上更具生产力的macOS，确实让人有些失望。

回过头来想想，从iPadOS独立出来已经过去了三年多，虽然其确实与iOS之间有了一定的差异，但为何大家对它还是如此不满意？它到底又该如何改变才能符合我们的需求呢？

根据业界人士的分析，iPadOS 16延迟的最大原因是苹果正在对iPad多任务的处理能力进行大刀阔斧地改革，一旦成功，就能让用户同时在一个屏幕上运行多个任务，而且可以根据用户的需求调整窗口大小等。但由于之前的代码过于混乱，导致不少iPad在运行该功能时出现了闪退、界面混乱或是直接不能使用的状态。

图源苹果官网

另外还有媒体爆料，iPadOS 16中还会加入一个全新的功能，当iPad与外接键盘或触控板连接后就会自动把应用程序进行缩小窗口化，更方便用户进行缩放、移动、关闭、以及多任务处理，简单来说就看起来更符合我们操作电脑的习惯。

再加上iPadOS 16 beta版上已经上线的“台前调度”功能，其允许用户在iPad和高达6K分辨率的外部显示器上同时运行8个应用程序，而且这套交互方式与触控、键鼠都兼容。 尤其是使用鼠标时，App的边界都是可拖动的，这与PC的使用习惯一致，也方便用户无缝衔接到iPad上处理工作，可以说这个功能彻底改变了iPad的交互方式，用户可以根据自己的需求去调节屏幕上的每一个APP大小，生产力确实拉满。

雷 科技 版权图

这些全新加入的新功能无疑是对工程师和iPad性能的一次巨大考验，或许也因此目前台前调度功能仅限用于iPad Pro 2021和iPad Air 5。而此次iPadOS延期或许就是为了让更多的非M1版iPad用上该功能，只不过目前的进展不是那么顺利罢了。

另外我们还可以猜测之后的iPadOS会和macOS同时发布，毕竟从现在的爆料和使用状况来看，iPad和Mac之间的联系越来越紧密，越来越像是Mac用户的第二块屏幕。 其实简单想想也可以理解，给iPad用上macOS显然是不现实的，还不如通过一些新功能增强两者之间的联系，这样既不会让影响到双方的定位，也能变相提升iPad的生产力。

图源苹果官网

差点忘了，此次爆料中还表示今年将会发布一台全新的入门级iPad以及一台搭载M2处理器的iPad Pro，前者将舍弃掉Lighting接口，使得整个iPad产品线都变成USB-C口，更利于用户传输文件等，后者则没什么好说的，一发布那必然是平板界的天花板，这两款产品估计也会延迟到10月左右发布。

一台好的设备不仅仅是包含了优秀的硬件性能，系统层面也尤其重要。更重要的是，苹果最近几年将iPad定位为了生产力工具。 但是现实却是骨感的，即使官方将iPad定位在了生产力工具上面，但是实际上，在消费者层面上来看，iPad则完全沦为了看电影和盖泡面的工具。

自第一代iPad诞生至今，在很多人印象中iPad一直是个不能接打电话的大屏版iPhone，实际上好像也并没有错，毕竟iPad此前一直运行的也是iOS系统，后续就算苹果推出iPad Pro并将其定位为生产力工具，也依然无法让外界打消大屏iPhone的固有印象。

图源苹果官网

直到2019年，苹果宣布iPad OS彻底独立，之后也会与iOS慢慢拉开差距，但作为iPad多年的用户，我依旧感觉不到两者的差异有多大，甚至iPad OS相比iOS还缺少了不少基础功能。当然这也是使用方法的不同，我既不拿它来画画也不拿来工作，纯粹只是把它当成是一台视频播放器和大号 游戏 机来使用。

雷 科技 版权图

可能有读者会说，iPad可以连接键盘来码字，也可以展示PPT、视频等，但这些功能笔记本电脑做得会更好；又或者有读者会说，iPad的性能这么强，也是很多视频剪辑人员的必备工具啊，目前iPad上面最强悍的视频编辑软件无非就是Luma Fusion，这是一款完全仿照Final Cut Pro设计的APP。但它也就仅限于十分相似罢了，当你真的用它去剪辑一个视频的时候，你会发现使用触屏去操作上有多么不舒服，再加上iPad那混乱的文件管理，想导入一些素材简直是噩梦。

iPad真的是生产力工具吗？严格意义上来说确实是，但经不起推敲，它和传统电脑相比，有着较强的局限性，只能完成一些相对简单的工作。 例如你把工作想象成一条20公里的马路，PC会是一辆 汽车 ，iPad顶多就是辆摩托车，虽然都能到达目的地，但你在上面花的时间和精力是要远大于 汽车 的。

图源苹果官网

早在WP时代，微软就在强调平台的统一性，看起来多平台统一似乎是一种未来的趋势。从最主流的框架跨平台（Flutter、Qt等），到Fuchsia和鸿蒙的系统跨平台似乎都在强调多平台的统一性，而苹果作为业界把生态系统玩得最溜的企业，自然不会在这个地方被人甩开一大截。 所以，就目前的情况来看，苹果的操作系统体系是目前最有希望彻底完成跨平台系统统一的系统。

不管是从此次iPadOS 16延期、beta版中的各种新功能还是苹果将iPad全员更换成USB-C口，我们都能看出苹果正在不断地去完善他们的生态系统，让iPad不再是用户手中的大号iPhone，让它能够更好地去完成一些PC设备的任务。正如前文中说的那样，iPad不可能成为第二个“Mac”，但它完全有可能成为Mac的好帮手，对于用户和苹果来说是双赢，而对于竞争对手而言，这或许又是一个值得借鉴和学习的点。

北大青鸟设计培训：web前端多端编程开发框架结构？

随着我们对web前端编程开发技术的掌握，越来越多的框架语言和架构方式被我们所熟知。

下面四川北大青鸟就一起来了解一下，web前端开发的一些常见框架结构。

1.全包型这类框架大的特点就是从底层的渲染引擎、布局引擎，到中层的DSL，再到上层的框架全部由自己开发，代表框架是Qt和Flutter。

这类框架优点非常明显：性能(的上限)高;各平台渲染结果一致。

缺点也非常明显：需要完全重新学习DSL(QML/Dart)，以及难以适配中国特色的端：小程序。

这类框架是原始也是纯正的的多端开发框架，由于底层到上层每个环节都掌握在自己手里，也能大可能地去保证开发和跨端体验一致。

但它们的框架研发成本巨大，渲染引擎、布局引擎、DSL、上层框架每个部分都需要大量人力开发维护。

2.Web技术型这类框架把Web技术(JavaScript，CSS)带到移动开发中，自研布局引擎处理CSS，使用JavaScript写业务逻辑，使用流行的前端框架作为DSL，各端分别使用各自的原生组件渲染。

代表框架是ReactNative和Weex，这样做的优点有：开发迅速;复用前端生态;易于学习上手，不管前端后端移动端，多多少少都会一点JS、CSS。

缺点有：1.交互复杂时难以写出高性能的代码，这类框架的设计就必然导致JS和Native之间需要通信，类似于手势操作这样频繁地触发通信就很可能使得UI无法在16ms内及时绘制。

ReactNative有一些声明式的组件可以避免这个问题，但声明式的写法很难满足复杂交互的需求。

2.由于没有渲染引擎，使用各端的原生组件渲染，相同代码渲染的一致性没有一种高。

3.JavaScript编译型这类框架就是我们这篇文章的主角们：Taro、WePY、uni-app、mpvue、chameleon，它们的原理也都大同小异：先以JavaScript作为基础选定一个DSL框架，以这个DSL框架为标准在各端分别编译为不同的代码，各端分别有一个运行时框架或兼容组件库保证代码正确运行。