跨平台开发（跨平台开发方法）

本篇文章给大家谈谈跨平台开发，以及跨平台开发方法对应的知识点，希望对各位有所帮助，不要忘了收藏本站喔。 今天给各位分享跨平台开发的知识，其中也会对跨平台开发方法进行解释，如果能碰巧解决你现在面临的问题，别忘了关注本站，现在开始吧！

本文目录一览：

• 1、跨平台桌面开发，Electron还是WebView2 （中篇）
• 2、c#10和-6入门与跨平台开发怎么样
• 3、.Net如何跨平台？
• 4、为什么除了Flutter之外，我们还需要另一个跨平台开发框架？
• 5、C++跨平台SDK开发指北

跨平台桌面开发，Electron还是WebView2 （中篇）

这一周继续聊跨平台桌面开发这个事情。

在这篇文章中，跨平台开发我暂时会放下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呢？

下一篇，继续聊。

c#10和-6入门与跨平台开发怎么样

c10和net6入门与跨平台开发怎么样
C10和Net6是一种跨平台开发技术，它们可以帮助开发者快速开发出可以在多个平台上运行的应用程序。由于它们支持多种平台，开发者可以使用它们来快速开发出可以在不同平台上运行的应用程序。此外，它们还支持跨平台的UI开发，可以让开发者快速创建出支持多种平台的UI界面。总的来说，C10和Net6是一种非常有用的跨平台开发技术，能够帮助开发者快速开发出可以在多个平台上运行的应用程序。

.Net如何跨平台？

Windows平台和Linux平台；Java平台和.Net平台这两对冤家，在开发者眼里似乎永远都没有交集。然而，世界上没有绝对不可能的事情，听起来天方夜谭的事情往往很快就会变成现实。其实早在2005年，这个梦想就已经实现。\x0d\x0a使用微软Visual Studio .Net开发者，现在他们被提供一种新方法，可以开发在Linux下运行Web应用程序。这就是Grasshoppe。这是一套全名为Visual MainWin for J2EE Developer Edition 的工具，它可以免费得到，其设计目的就是在Visual Studio 开发工具和Linux、J2EE之间架起一座桥梁。它的设计者是Mainsoft公司，它被宣称为Linux下第一个基于Visual Studio的Linux IDE。\x0d\x0a1. Grasshoppe出现的动机\x0d\x0a随着计算机技术的广泛应用，单一的技术很难全面满足某些大型应用的全部需求。.Net技术可以实现夸语言开发，并且极大提高了开发效率，但是只能跑在Windows系列平上，无法满足大型分布式应用的需求；Java/J2EE可以跨平台，适合大型分布式应用，但是其开发效率以及开发难度一直让许多初学者望而却步。\x0d\x0a许多大型组织发现他们自己正在拥有和使用由.NET技术和J2EE技术混合组成的开发团队和发布服务器。为了平衡通过J2EE应用程序服务器发送的企业质量，公司的商业逻辑经常以企业JavaBean（EJB）的形式发布于J2EE应用程序服务器上。另一方面，为了满足日益变化的商业发展的要求，多数开发者比较喜欢在具有高度生产性能的Visual Studio.NET开发环境下实现描述逻辑。当你需要把.NET描述层连接到J2EE商业逻辑层时，挑战就产生了。如何在Visual Studio.NET中，用C#或Visual Basic.NET来实现ASP.NET描述层，然后再调用以EJB形式实现的商业逻辑层这一挑战性开发的呢？\x0d\x0a解决这个问题最好的办法就是在.Net平台和Java平台中间架设一座桥梁，让.Net平台可以访问Java，访问EJB，能够运行在不同的平台上。

为什么除了Flutter之外，我们还需要另一个跨平台开发框架？

不久前，谷歌正式推出 Jetpack Compose 1.0 版本。近日，JetBrains 在此基础上发布了 Compose Multiplatform Alpha 版本，旨在将 Compose 扩展到桌面和 Web 端。

Compose Multiplatform 由 Compose for Desktop 和 Compose for Web 组成，通过 Kotlin Multiplatform 支持许多不同的平台。其中，Compose Desktop 采用 Google 的 Skia 图形库，来实现在 Windows、macOS 和 Linux 上的 UI 绘制，借此在所有支持的操作系统中提供统一的体验，类似于 Flutter 的做法。

根据 Kotlin 团队的说法，相比起 Electron 框架，Compose Multiplatform 在内存消耗、安装大小和 UI 渲染性能等方面将有更明显的优势。随着 Alpha 版本的发布，Compose Multiplatform 还收获了新的 Android Studio 插件，包括对在 IDE 中显示组件预览的支持以及许多附加功能。

我们希望通过本文帮助大家进一步了解 Compose 的跨平台能力，以及 JetBrains 将 Compose 从 Android 扩展到这些其他平台背后的主要驱动力是什么。

基于 Jetpack Compose 1.0

由谷歌打造的 Jetpack Compose 是一款用于在 Android 应用程序之内构建用户界面的官方框架，上周刚刚发布 1.0 版本。与此同时，Android Studio 代号“极狐”的首个稳定版 2020.3.1 也正式亮相。

尽管才刚迎来 1.0，但谷歌表示“目前 Play Store 中已经有超过 2000 款应用程序在使用 Compose——更重要的是，就连 Play Store 这款应用本身也在使用 Compose。”谷歌方面还表示，“我们一直在与一些顶级应用的开发人员进行合作，他们的反馈和支持帮助我们使 1.0 版本更加强大。”

Jetpack Compose for Android 迎来 1.0 版本

Compose 基于 Kotlin 开发，而 Kotlin 与 Android Studio（即官方指定的 Android IDE）均来自开发工具厂商 JetBrains。虽然 Jetpack Compose 专为 Android 打造（与谷歌的 Flutter 框架不同）， 但 JetBrains 公司坚信 Compose 完全能够获得跨平台能力 。

Compose for Desktop: 这只是开始

Compose Multiplatform 可以说是该框架面向 MacOS、Linux、Windows 以及 Web 开设的一个端口，目前刚刚发布 1.0 Alpha 版本。虽然尚处于早期开发阶段，但 JetBrains 表示，其已经“为开发人员带来能够基本安全使用的稳定 API”。

TheRegister 就此事询问了 JetBrains 公司 Compose 项目负责人 Nikolay Igotti，希望了解为什么该公司在拥有了已经广泛应用于 IntelliJ IDEA IDE 及多种丰富变体的桌面应用程序跨平台 Java 框架之外，还要费力开发 Compose for Desktop。Igotti 的回答是，“旧有 Java 框架基本上就是修改版的 Swing。Swing 属于默认 JDK UI 框架，Swing 和 AWT（Abstract Windows Toolkit，抽象窗口工具包）。Compose 则完全是另一码事，当然我们也在设计中考虑到了互操作性需求……Swing 这套框架太陈旧了，最早出现在上世纪九十年代末。多年来人们对于 UI 的设计思路已经天翻地覆，Swing 显然满足不了要求了。”

JetBrains IDE 中的 Compose for Desktop 项目

Compose 与 Swing 有一个比较大的共同点：与其他使用本机控件的跨平台框架，比如例如 Java 的 SWT（Standard Widget Toolkit）以及微软的 Xamarin 有所不同，它们选择自主绘制控件。Compose 使用的 Skia 开源图形库，也在谷歌 Chrome、Flutter 及其他众多框架当中得到广泛应用。那这是否意味着 Compose 应用程序将没有自己的原生外观？对此，Igotti 的回应是，“这取决于开发人员的选择，取决于他们如何为应用程序设置主题。在这方面，Compose 的情况与 Flutter 等其他框架没什么区别。”

那 Compose for Desktop 应用程序是否依赖于 JVM（Java Virtual Machine）运行？Igotti 表示，“我们也知道，JVM 应用程序的发布情况可能比较棘手。因此我们提供自己的 Gradle 插件，其使用 jpackage 与 Jlink 以 JVM 应用程序为基础制作原生应用程序。Mac 的.dmg、Windows 的 MSI、Linux 的 deb 包等均可实现，大家用不着担心 JVM。”

也就是说，开发成果将会是一款被精心包裹起来的 JVM 应用程序。JetBrains 还有一款用于解决这个问题的 Kotlin/Native 编译器，“预计将在未来发布，或者专门用于桌面开发。”

对应用程序的另一种思考方式

那 Web 应用程序方面呢？Igotti 回应称，“我们使用 Kotlin/JS 编译器。”Compose 的 Web 版本不如桌面版先进，说明文档中也警告称“API 尚未最终确定，预计会发生重大变化。”此外，虽然 Web 版本确实使用 Compose 模型，但 API 却完全不同，而且会使用 HTML 与 CSS。所以，Web 版与 Compose for Desktop 之间能够共享的代码应该比较少。

据 Igotti 介绍，“Compose 代表着一种不同的应用程序思考方式。状态即 UI 的真实来源，而 UI 本身是无状态的，其表达永远由状态计算得出。在这方面，Compose for Web 采用一组相同的原语，完全相同的状态管理思路。但是对于具体的小部件集合与排列方式，Web 版与桌面版之间确实无法互通。”

说到这里，为什么要把 Compose for Android 扩展到多种其他平台之上？“Compose 的目标受众主要分为三类。首先是使用 Kotlin 与 Compose 的 Android 开发人员，他们希望把自己的开发成果交付至其他平台；其二是纯 Kotlin 开发人员，他们希望以‘一次编写、随处运行’的方式开发新的应用程序；第三则是那些不太熟悉 Kotlin 或者 Compose，但又希望开发出精美 UI 的用户，我们希望能为他们提供实现目标的工具。”

Igotti 并没有给出具体的发布日期，但表示自己希望 Beta 版能在今年秋天发布，“我们也希望能在今年之内推出 1.0 版本。”项目本身是完全开源的，“二十一世纪了，框架在大多数人们心目中就不应该收费。我们只是想开发一款长期缺失的软件”，补足 JetBrains 当前商业模式中的工具链。

那么，JetBrains 会在自己的其他工具中使用 Compose 吗？事实上，他们的 JetBrains Toolbox（用于管理已安装的 IDE）已经在使用 Compose，但 Igotti 表示短时间内 Compose 还无法取代 IntelliJ IDEA 等现有框架。“编辑器是其中最复杂也最重要的组件，经历了 20 年的发展演进，我们几乎不可能在中途进行重写了。无论是 JetBrains 还是我个人，都不打算强迫每个人都转而使用 Compose。我们的目标是为原有框架选项满足不了的用户提供新的解决方案。”

写在最后

那么，为什么除了 Flutter 之外，我们还需要另一个跨平台框架？虽然谷歌的 Flutter 最开始主要面向移动设备，但现在也开始向桌面及 iOS 进军，甚至比 Compose 还抢先了一步。不过，根据 StackOverflow 的最新调查， Flutter 使用的语言为 Dart；尽管 Dart 语言的人气正在增长（正是受到 Flutter 的推动），但仍然无法与 Kotlin 相提并论。

Compose 代表着一种独特的 UI 构建方法，也许最期待 Compose 跨平台功能的受众，正是那些曾在 Android 上使用过它、又特别喜欢这种 UI 构建体验的开发者。

想要进一步了解 Compose，国内 Android 开发者可访问以下链接查看中文手册： https://compose--/

延伸阅读：

https://www.theregister.com/2021/08/06/compose_for_desktop_kotlin_framework/

C++跨平台SDK开发指北

上半年一直忙于主机平台支付功能的接入，原来基于android开发的sdk并不适用主机平台。为了满足业务需求，先是重新开发了一套unity的sdk，用于unity引擎游戏业务集成。然而该unity sdk并不能满足ue4引擎游戏业务的需求，考虑到后续sdk的兼容和通用，选择重新开发一套c++ sdk，实现跨主机平台接入。

虽然很早之前也接触过c++开发，但工作以来主要还是做android平台开发，c++很多东西早就忘的一干二净了。相对于早前自己开发的unity sdk，c#语言更类似java，同样采用虚拟机实现，平台工具都比较齐全。而c++自身的语言特性和平台实现差异，决定了重新开发一套c++ sdk的难度。

c++ sdk的目标是能支持跨平台调用，实现多平台支付接入。如：既能支持switch、ps4、xbox等不同平台支付功能的接入，又能支持unity跨平台调用该sdk。因此，对外暴露的sdk接口入参回调等最好是统一格式，最小化的个性定制。

c++对外接口如下所示：

为了实现unity跨平台调用该c++ sdk，需要再封装一层协议接口层，实现unity到c++的转换。并通过dllexport，将接口暴露到unity层。

以初始化接口Initialize为例：

unity层调用c++ dll库中接口的方式如下：

这部分内容主要分析c++ sdk的逻辑设计思路。c++ sdk对外提供初始化、支付、补发、查物品信息和查营销信息等功能，对内需要维护复用一套框架，实现不同平台不同支付渠道的接入。

由于对外提供的接口存在相似性（入参request、回调callback），抽象出订单中心。

每次各外部接口调用开始到结束，复用同一套订单逻辑。以支付接口调用为例：

sdk是以渠道为粒度，提供了一套框架，负责实现各渠道的流程调度。而每个渠道通常存在差异，对外提供的功能不一，从而将渠道的每项功能抽象为具体的渠道实例，如：支付渠道、补发渠道、查物品信息渠道和查营销活动渠道。而sdk再通过基类，抽象出各功能渠道的流程框架，具体实现交由不同子类渠道完成。

仍以支付为例：

由于c++不支持反射，不能像java实现实例的动态创建。c++ sdk通过渠道工厂类，负责渠道实例的创建回收。

网络层设计的目标是既能满足sdk自身业务需要，又能跨平台调用。于是将网络抽象成3层：

这里讲下跨平台层实现逻辑。

由于sdk目标是能在多平台上运行，而不同平台如windows、linux和unix中网络库不同；要实现多平台统一，可以采用的方式有：

c++ sdk的目标是跨平台，但如何实现跨平台？

综合sdk实现过程中，需要跨平台实现的主要是sdk的基础功能，如：网络收发、AES加/解密、gzip压缩。正如在上面提到的一样，开始的方案是通过引入第三方平台无关的库来实现各基础功能，再通过编译成不同平台的库来实现跨平台。而在x64上，自己也通过这种方式实现了整套流程，在x64上采用的库为：

而在移植到ps4平台时，花了大量时间做libcurl的编译，而openssl编译适配更是毫无头绪。于是放弃了这种实现，改而通过将基础功能下沉到具体平台实现，sdk抽象出基类实现跨平台框架。最终在ps4的移植后，采用的方式：

c++ sdk断断续续开发了一个多月，重新捡起c++到完成ps4的移植测试，还是有点成就感的。之前虽然也重新写了一套unity sdk，但相对c++ sdk来说，难度还是低了很多。虽然也是重复造轮子，但在整个项目的过程中，碰到的问题远比预期的多，解决问题的快乐才是继续的源动力。 关于跨平台开发和跨平台开发方法的介绍到此就结束了，不知道你从中找到你需要的信息了吗 ？如果你还想了解更多这方面的信息，记得收藏关注本站。 跨平台开发的介绍就聊到这里吧，感谢你花时间阅读本站内容，更多关于跨平台开发方法、跨平台开发的信息别忘了在本站进行查找喔。

版权声明：本文内容由网络用户投稿，版权归原作者所有，本站不拥有其著作权，亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容，请联系我们jiasou666@gmail.com 处理，核实后本网站将在24小时内删除侵权内容。