指导
Gaita 在 OSCON 开源大会上发表了题为“跨平台开发人员的自白”的演讲。 她长期从事开源工作，为Mono项目（LCTT译注：一个致力于开创.NET在Linux上使用的开源项目）做出了贡献，主要使用C#/C++开发。 在 ，她担任专注于构建的扩展经理。
我迫不及待地在她演讲前向她询问跨平台开发的情况，问她在过去16年里作为跨平台开发者学到了什么。
在您开发跨平台代码时，您使用过的最简单和最难的编码语言是什么？
A：我很少讨论某种语言的优缺点，更多的是讨论这些语言的库和工具。 该语言的编译器、解释器和构建系统决定了使用它们进行跨平台开发的难易程度（或者是否可以进行跨平台开发），而可用的 UI 库和对本地系统的访问则决定了兼容性与操作系统。 集成的紧密程度。 在我看来，我认为 C# 最适合跨平台开发工作。 该语言本身包含允许快速本机调用和精确内存映射的功能，如果您希望代码能够与系统和本机库交互，则需要这些功能。 当我需要非常具体的系统功能时，我会切换到 C 或 C++。
您使用哪些跨平台开发工具或抽象层？
答：我的大部分跨平台工作是为其他需要开发跨平台应用程序的人开发工具、库和绑定，通常是 MONO/C# 和 C/C++。 我在抽象层面上用得不多，更多的是在 glib 库和朋友上。 大多数时候，我使用Mono来完成各种跨平台应用，包括UI，或者偶尔用在游戏开发中。 我经常使用它（译注：Atom编辑器的兄弟项目，可以用来开发桌面应用程序）。
您使用过哪些构建系统？ 它们之间的差异是由于语言或平台差异造成的吗？
我尝试选择适合我使用的语言的构建系统。 这样，我的头痛就会减少（希望如此）。 它需要支持平台和架构之间的选择、构建输出位置智能（多个并行构建）、易于配置等。大多数时候，我的项目使用 C/C++ 和 C# 的组合，我想构建不同的配置环境（调试、发布、OSX、Linux、iOS 等） 构建的输出选择具有不同参数的不同编译器。 构建系统可以为我完成这一切，而不会（太）打扰我。 我一直在时不时地尝试不同的构建系统，看看有什么新功能，但最终我又回到使用 shell 和批处理脚本或 Perl 脚本的组合来完成工作（因为如果我希望用户构建我的软件，我仍然最好选择一种可以在任何地方使用的命令行脚本语言）。
如何平衡提供原生外观和统一 UI 的需求？
跨平台用户界面的实现很困难。 过去几年我使用过一些跨平台 GUI，但我认为这些事情没有最佳解决方案。 基本上有两种选择。 你可以选择一个跨平台的工具来制作一个并不完全适合你所有支持的平台的UI，但是代码库比较小，维护成本也比较低。 或者您可以选择开发特定于平台的 UI，它看起来更原生、集成性更好，但需要更大的代码库和更高的维护成本。 这个决定完全取决于应用程序的类型、它有多少功能、您拥有多少资源以及您将在多少个平台上运行它？
归根结底，我觉得用户对于这种“一UI通关”的接受度还是比较高的，比如框架。 我有一个 +C + C# 框架副项目，希望有一天能用 C# 构建一个应用程序，这样我就可以两全其美。
构建/打包系统依赖关系对您来说重要吗？
我依赖保守的用法，并且多次受到损坏的 ABI（LCTT 注释：应用程序二进制接口）、冲突的符号和丢失包的困扰。 我决定要针对哪个操作系统版本，并选择最低的公共部分以最大程度地减少问题。 通常这意味着有五个不同的Xcode和OSX框架库，同一台机器上安装了五个不同的版本，多个clang（LCTT译注：C语言，C++，-C，C++语言轻量级编译器）和gcc版本，一系列运行各种发行版的虚拟机。 如果我不确定要使用的操作系统的包的状态，我有时会静态链接库，有时会对依赖项进行子调制以确保它们始终可用。 大多数时候，我会避免这些棘手的问题，除非我绝对需要使用它们。
您是否使用持续集成 (CI)、代码审查和相关工具？
基本上每天都会用。 这是保持生产力的唯一方法。 我在项目中做的第一件事就是配置跨平台构建脚本，以使一切尽可能自动化。 当您为多个平台进行开发时，持续集成至关重要。 没有人可以在一台机器上构建各种平台的不同组合，一旦你的构建过程不包括所有平台，你就不会注意到你搞砸的事情。 在共享的多平台代码库中，不同的人拥有不同的平台和功能，因此保证质量的唯一方法是跨团队代码审查结合持续集成和其他分析工具。 这与其他软件项目不同，如果不使用相关工具，其他软件项目就会失败。
您是否依赖自动化构建测试，或者您倾向于在每个平台上进行构建并在本地进行测试？
对于不包含 UI 的工具和库，我通常使用自动化构建测试。 如果有 UI，我将同时使用两者 - 现有 GUI 工具几乎没有可靠的、可编写脚本的 UI 自动化，因此我要么为我想要在我支持的自动化工具平台上支持的平台创建 UI，要么进行测试手动。 如果一个项目使用自定义 UI 库（比如类似的库），那么开发可编程自动化工具并自动化大部分工作就相当容易。 尽管如此，没有什么比人类的双击更能测试失败了。
您更喜欢哪种跨编辑器构建系统？
我喜欢使用跨编辑器构建系统。 我更喜欢将项目文件保存在不同的 IDE 上（这使得添加 IDE 更容易），并告诉 IDE 通过使用构建脚本在它们支持的平台上进行构建。 编辑器是开发人员最重要的工具，需要时间和精力来学习它们，而且它们是不可替代的。 我有自己喜欢的编辑器和工具，每个人也可以使用自己喜欢的工具。
跨平台开发时，您更喜欢使用什么样的编辑器、开发环境和IDE？
跨平台开发人员仅限于在大多数平台上工作的少数常见选择之一。 我喜欢使用它，但除了平台之外我不能依赖它（你可能不希望它成为你的主要交叉编译平台），所以我不会使用它作为我的主要 IDE。 即使可以，跨平台开发人员的核心技能也是了解和使用尽可能多的平台。 这意味着熟悉它们——使用该平台上的编辑器和库，了解操作系统以及它在哪里工作、它是如何工作的、它的局限性等等。做这些事情需要清醒的头脑（我的捷径是加强记忆） ，而且我必须依赖跨平台编辑器。 所以我使用 Emacs 和 .
过去和现在您最喜欢的跨平台项目是什么？
我一直很喜欢 Mono 并且发现它很方便，大多数其他项目都以某种方式围绕它展开。 它是我多年前开发的一个绑定，可以将C#开发的应用程序嵌入到Web浏览器页面中，看起来很有特色。 我开发了一个应用程序，它是在linux上开发的，它可以在嵌入浏览器页面的GTK视图上运行。 在该项目（之前称为 Cxxi）中，我开始为 C++ 库生成 C# 绑定，以便我可以在 C# 中调用、实例化 C++ 类并对其进行子类化。 这样，在运行时，它会检测正在使用的平台以及用于创建本机运行时的编译器，并为其生成正确的 C# 绑定。 多么有趣啊。
您如何看待未来跨平台发展的趋势？
我们构建原生应用程序的方式已经改变，我感觉各种桌面操作系统之间的明显差异正在慢慢模糊； 因此构建跨平台应用程序会更加容易，并且系统的集成不需要完全本地化。 从坏的方面来说，这可能意味着应用程序可用性较差，并且利用操作系统特性的能力较差。 库、工具和运行时的跨平台开发是我们知道如何做得更好的事情，但跨平台应用程序开发仍然需要我们的努力。
原文来自：：443/-7743-1.html
