这是个产假作业。故事是这样的。
创新互联专注于滕州企业网站建设,成都响应式网站建设,商城系统网站开发。滕州网站建设公司,为滕州等地区提供建站服务。全流程定制开发，专业设计，全程项目跟踪，创新互联专业和态度为您提供的服务
生了娃，生活一地鸡毛。擦，碎钞机的需求怎么那么多。
当时，有一堆返利优惠券app比较火
...这里扯多了这篇文章被锁了....
我就想，来扒一扒，他们是怎么赚钱的。
结论：淘宝联盟。
淘宝联盟是阿里巴巴旗下的亲儿子，不那么有名是因为是个私生子吧，官网上还有个没听过的名号叫“阿里妈妈”，呵呵。淘宝联盟是给淘宝上推广商品的人用的，他们有一个专门的名称，叫做淘宝客，即“推广者（Publisher）”，他们帮电商平台推荐商品给别的买家，买家购买后，电商平台可以增加销量，而他们则可以获得推广佣金。
后来，知道京东也有自己的联盟平台，叫做“京东联盟”，拼多多也有，叫做“多多进宝”。
回到这些app的赚钱逻辑上来。对于用户而言，它们的两个噱头是：
“用我们的app买，你可以自用省钱”
“用我们的app，分享给别人下单，你可以赚钱！”
所以，这些app推广起来很容易啊，因为谁用谁赚钱呀！
那么为何不自己搭一个呢？
与其这些佣金落到别人口袋，不如自己直接做最顶层上线，发展出N个下线，岂不是躺着赚钱，哈哈哈哈哈
搞清楚赚钱逻辑之后，我发现淘宝联盟的api是很开放的。
商品链接： ;pid=mm_343780171_368000361_101527600308itemId=595640102734src=qtka_wxxtdx=1
其中，activityId是优惠券id，pid是推广者在阿里妈妈官网注册的id，只有这个id是我注册的，那么佣金就到我口袋去了，哈哈哈。
刚好练一下flutter，一次开发，两端使用，我一个人就可以了。app暂时取名为“小猪购”，拿粉红猪贴牌。
演示视频：
这一周继续聊跨平台桌面开发这个事情。
在这篇文章中，我暂时会放下Electron与WebView2的一个对比，而聊一聊跨平台这个对于程序员群体来说不陌生的词。
一个趋势是：跨平台开发几乎是在各个技术方向都会持续发展的
跨平台这个词，对于程序员来说，应该是不陌生的。因为这个概念不只在某一端存在，后端，前端，移动端，桌面端几乎所有方向都对跨平台有需求。
在后端，Java是跨平台的，当你用Java来编写后端服务时，并不需要考虑操作系统，因为它几乎支持主流的操作系统。现在，编写一个后端服务，选用Java仍是主流。虽然可能它的跨平台特性已经不是程序员最在意的点了。
而在移动端，类似React Native，Flutter也是非常有名的跨平台移动开发，它们与移动原生开发方式之间一直是竞争与共存。
而前端因为依托于浏览器，天然就是跨平台的。事实上，很多应用或服务早期纷纷选择从原生应用迁移至前端WEB方式的一个非常重要的原因就在于它是跨平台的。
桌面操作系统很长一段时间一直是Windows一家独大，所以桌面开发一直是Windows独占，直至现在为止，很多专业级的软件仍然是Windows独占的。
而Linux桌面操作系统与MacOS桌面操作系统，早些年几乎可以忽略不计，压根不需要考虑这两种系统。但随着近些年它们的慢慢流行，特别是苹果的MacOS的以其杰出的工艺，流畅的体验，叠加苹果手机的流行，其市场份额增长非常之快，在特定的诸如编程，设计等行业人群中使用范围较广，这使得开发支持MacOS系统这个点变得越来越重要。
所以，在桌面开发领域，跨平台的需求也越来越高。
这也是Electron及早期的NW.js能迅速发展起来并得到非常广应用的原因所在。
无论是哪一端，跨平台技术之所以频繁出现与不断发展，其根本原因就在于编程的一个重要痛点在于：
为了让同一个服务能在所有设备上运行，程序员不得不编写与维护非常多不同版本的程序
每一个程序或软件后面的服务，都有一个非常迫切的需求，就是期望它的用户无论何时，无论何地，无论使用任何设备，都能方便友好的使用这个服务。
也是因为这个原因，Web发展起来了，因为Web的优势就在这，只要你的设备上有浏览器，就能访问。
但Web毕竟性能有限，且浏览器这种形式并不利于用户忠诚度的培养，它存在天然的弱点。一些简单的操作服务使用Web并无问题，但稍微有点要求的，Web可能就并不是非常适合。
所以，一种趋势不可避免地流行起来：
对不同设备或系统进行抽象，基于某一种特定的编程语言，编写出能与原生程序相媲美的，又能跨平台的技术便层出不穷了
对吧，Java是使用JVM来抽象不同的操作系统，React Native则是使用虚拟DOM以及转换成原生控件的方式来实现跨平台，而Electron则是通过性能较好的Chrome内核+NodeJS原生调用能力的搭配来实现跨平台桌面开发。
总而言之，这种跨平台的技术不会消亡，只会有新的技术层出不穷，而它们与原生开发一定是相互竞争，配合与共存的。相互之间无法取代。
那再回到跨平台技术上来说，一个良好的跨平台开发的技术或框架，重点是什么。
或者换种方式说，哪些特性使得它更易于流行起来？
我个人认为有以下的几个点：
跨平台开发技术能不能流行起来的一个非常重要的点就在于，使用了什么样的编程语言。
以移动端跨平台开发技术来说明，一个React Native，一个Flutter，这两个是比较知名主流的跨平台移动开发技术。React Native使用的是前端React技术，而Flutter则是Google的D语言。
显而易见的是，虽然Flutter是使用skia引擎在底层重绘一套UI，其性能相比React Native这种模式更佳，但React Native更易于被接受。
在流行度上，React Native始终比Flutter更流行，一个最重要的原因也在于：
使用已熟知的前端编程语言，比起重新学习一个D语言更易于被接受，维护成本更可控。
这个问题在跨平台桌面开发中也是类似，跨平台桌面开发技术也不是Electron最开始出现，比如著名的QT很早就有了，但比起Electron这种使用前端编程技术来说，显然在编程语言的门槛上和程序员群体上都存在困难，这也是Electron能后来居上的原因所在。
因为，大多数程序员群体，相比较另外学习一门什么语言去做什么，使用自己熟悉的语言来做什么是更容易，意愿也更高。
而从公司或团队的考量上看，选择偏门的小众语言存在成本上的顾虑，比如人员招聘是否容易？
跨平台技术在尝试解决不同平台不一致，它或多或少会损耗性能。这也决定了几乎没有任何一个跨平台技术能取代原生开发。
这是一个取舍的问题，对于一个程序来说，究竟性能有多重要。对于比较看重性能的程序来说，原生开发可能是最优选择。
但跨平台的性能损耗也有高低之分，并不在同一水平线上。
其实，无论是Electron，或是WebView2，都是基于浏览器内核+前端技术的跨平台桌面解决方案，这也是为什么要把它们放在一起聊的原因。
Electron是先行者（当然，严格说来，NW.js出现的更早，但今天它的流行度已远远落后于Electron了），而WebView2则是后来者。
那做为后来者的WebView2究竟做了哪些改进？它又有多大的能力来挑战Electron呢？
下一篇，继续聊。
随着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的好帮手，对于用户和苹果来说是双赢，而对于竞争对手而言，这或许又是一个值得借鉴和学习的点。
目前，最优的选择有四个：
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
随着我们对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框架为标准在各端分别编译为不同的代码，各端分别有一个运行时框架或兼容组件库保证代码正确运行。
