支持 Mac 和 Windows 桌面的建议答案

【问题标题】：Advice for supporting both Mac and Windows Desktops支持 Mac 和 Windows 桌面的建议
【发布时间】：2011-06-21 22:00:47
【问题描述】：

构建支持 Windows 和 OS X 的 GUI 桌面应用程序的最佳做法是什么？假设它是预算软件，所以有一些数学和一些大数据结构。用户数据保存在 XML 文件中；没有单独的数据库或网络。

在一个极端情况下，您可以只用 C# 构建 Windows 版本，用 Objective C 构建 Mac 版本。有没有更好的方法，让您可以更轻松地保持两个版本同步并减少重复代码？你会用 C++ 编写数学和数据结构以及“业务逻辑”，并为简单的系统调用（如 IO）编写预处理指令，然后为 Windows 和 OS X 编写一个单独的 GUI 层吗？假设您想要本机代码，C/C++ 是跨平台后端的唯一选择吗？有什么方法可以一次编写 GUI 部分吗？（我希望不会。）

请注意，我不是在问如何使用交叉编译器。我对您如何以最少的麻烦来构建您的整个项目很感兴趣。

【问题讨论】：

或许可以看看Qt之类的跨平台框架？

标签： windows macos cross-platform desktop-application

【解决方案1】：

您基本上是正确的。您将使用 C/C++ 编写数据模型，使用 C#/.NET 和 Objective-C/Cocoa 编写 UI。

我不熟悉 C# 如何与非 C# 代码对话，但 Objective-C（基于 C 构建）很容易与 C 和 C++（后者与 Objective-C++）对话。如果您更愿意将 Python 和/或 Ruby 与 Objective-C 代码和 Cocoa 框架一起使用，您也可以将它们用于跨平台细分。

我赞赏您超越 Java 或其他跨平台 UI 的简单解决方案。如果你走原生路线，你将拥有一个更好看、更易于使用的产品。

【讨论】：

从 C# 应用程序调用 C/C++ dll 并不太讨厌。如果我将 dll 设为“托管”会更干净，但我怀疑这会严重污染 C++ 代码，因此很难为 Mac 编译它。（我不肯定；我没有使用托管 C++ 的经验。）

【解决方案2】：

鉴于我对平台原生用户界面和控件/小部件的强烈感受，我很可能在这个问题上与大多数人有不同的看法，但我更倾向于您的第二种方法。即使我还不够自虐，无法单独完成构建整个应用程序的麻烦。

所以我肯定会编写完全独立于 GUI 层的库或数据层代码。用 C++ 来做是一个明显的选择，特别是如果你已经习惯了这种语言，但稍后会详细介绍。关键是这段代码应该仅限于您的“业务逻辑”，因此完全独立于平台。如果您遵循可靠的面向对象原则，那么应该会发现大量的编程工作都是在这个级别上完成的。

除此之外，您还可以为 Windows 和 OS X 的核心 OS 和 UI 功能编写一个精简的“包装”库。包装库将是负责与平台和您的数据直接交互的唯一实体层代码应该从这个包装库调用函数，而不是直接从平台的 API 调用。

当然，阅读这篇文章的你们中的一些人可能会尖叫“但这就是 QT 已经为你做的事情！”是的，我知道。但它不使用本机小部件，并且在这么多 地方不符合标准平台约定。这意味着它很烂。我见过其他的 Windows 包装器库确实做到了这一点，但我还没有在 OS X 上看到一个看起来不错的包装器库。是的，我很挑剔，但你的典型 Mac 用户也是如此。他们只是不会像 Windows 用户那样忍受屏幕上的垃圾类型，甚至 Mac Office 团队也知道这一点。（我们都为您努力做到这一点而集体鼓掌。）

就您选择的语言而言，您说您正在两个平台上寻找本机代码。那是一块很难钉在墙上的果冻。例如，您认为 JIT 编译的代码是原生的吗？如果不是，则排除 C#。排除任何类型的解释代码会排除许多其他潜在语言。除了 C++ 和 Objective-C 之外，您没有太多选择other。但 C++/Win32 编程并不比 Cocoa 编程难多少，只是不同而已。

【讨论】：

我同意您对 GUI 平台的审美判断，以及您对 Mac 用户的评价。对我来说，Windows 上的 C# 和 Mac 上的 Obj-C 已经足够“原生”了（我的目标是一个相当旧的 .Net 版本。）我只是不希望共享代码带来大型框架安装。跨度>
@Paul：那么值得注意的是，C# 与 C++ 代码的互操作并没有那么困难。但我认为编写一个调用本机 API 的包装器库（即使在 Windows 上也可以使用 C++ 而不是 C#，因为 .NET Framework 提供了自己的 GUI 库）仍然是比在两个平台上完全独立地重新发明 GUI 更简单的解决方案.当然，如果您决定在两个平台上设计单独的 GUI，您将拥有更大的灵活性。例如，您可能希望您的应用看起来像 Mac 上的 iTunes 和 Windows 上的 Microsoft Word。
@Cajun：当然，这是一种可能的解释。但假设 C#/.NET 是 Windows 上的“主要支持的语言/框架”也是错误的。我想很多人都这么认为，这证明了 Microsoft 的营销能力，但 Windows确实提供了程序员多年来一直使用的本机 API 来编写 C/C++ 应用程序。它被称为 Win32，而 WinForms 只是对它的一个沉重的包装。 WPF 添加了一些额外的东西，但最终也依赖于 Win32 API。 .NET 仍然不符合“本机”的任何一个定义。
@Paul：不，不。我不会使用 Qt，但这并不能阻止你做一些类似于它自己做的事情。它不是严格的包装器，因为它重新实现了标准控件。如果您编写自己的包装器，您只需调用平台并让它处理控件/窗口/等的绘制。如果您熟悉 WinForms，这基本上就是它对 Win32 API 所做的事情。 MFC 使用 C++ 中的 Win32 API 执行此操作。当然，您不需要公开所有可能的功能，只需公开您的应用使用的功能即可。但重点是Button 控件的外观和行为方式相同
（续）就您的应用程序代码而言，因为它所处理的只是您的包装库，它提供了一个通用接口。包装器库将独立负责使用操作系统完成所有繁重的工作。将抽象的 Button 类转换为平台 API 所需的任何内容，以便在屏幕上绘制该按钮并与之交互。那有意义吗？我不确定您到底有多少编程经验，以及使用什么语言/平台。当然，这不会是一个微不足道的项目。

【解决方案3】：

你看过Mono吗？它允许您在 .Net 中进行开发，但可以跨平台部署。

【讨论】：

谢谢你的建议，但我不想用大框架来妨碍安装。否则我会使用 Java。
@Paul：请注意，在 Windows 机器上安装 C#/.NET仍然需要一个框架。是的，可以预期很多计算机已经安装了这个，但肯定不是全部。您对已安装基础的依赖程度取决于您所针对的 .NET Framework 版本。您不能假设每个人都会安装最新版本；它甚至还没有包含在 Windows 版本中。如果您的目标是完全避免使用框架（就像我在回答中提到的那样，坚持严格使用本机代码），那么您也必须在 PC 端避开 C#。
@Cody，请参阅我对您的回答的评论：我计划需要一个相当旧的 .Net，所以它应该在那里。