跨平台开发者的经验之谈

标签：

我在她发表演讲前就迫不及待的想要问她一些关于跨平台开发的事，问问她作为一名跨平台开发者在这 16 年之中学习到了什么。

A:我很少讨论某种语言的好坏，更多是讨论是那些语言有哪些库和工具。语言的编译器、解释器以及构建系统决定了用它们做跨平台开发的难易程度（或者它们是否可能做跨平台开发），可用的 UI 库和对本地系统的访问能力决定了与该操作系统集成的紧密程度。按照我的观点，我认为 C# 最适合完成跨平台开发工作。这种语言自身包括了允许快速的本地调用和精确的内存映射的功能，如果你希望你的代码能够与系统和本地函数库进行交互就需要这些功能。而当我需要非常特殊的系统功能时，我就会切换到 C 或者 C++。

A:我的大部分跨平台工作都是为其它需要开发跨平台应用的人开发工具、库和绑定，一般是用 MONO/C# 和 C/C++。在抽象的层面我用的不多，更多是在 glib 库和友元方面。大多数时候，我用 Mono 去完成各种跨平台应用的，包括 UI，或者偶然在游戏开发中用到 Unity3D 的部分。我经常使用 Electron（ 译注：Atom 编辑器的兄弟项目，可以用 Electron 开发桌面应用)。

我试着选择适合我使用的语言的构建系统。那样，就会很少遇到让我头疼的问题（希望如此）。它需要支持平台和体系结构间的选择、构建输出结果位置可以智能些（多个并行构建），以及易配置性等。大多数时候，我的项目会结合使用 C/C++ 和 C#，我要从同一源代码同时构建不同的配置环境（调试、发布、Windows、OSX、Linux、Android、iOS 等等），这通常需要为每个构建的输出结果选择带有不同参数的不同编译器。构建系统可以帮我做到这一切而不用让我（太）费心。我时常尝试着用不同的构建系统，看看有些什么新的变化，但是最终，我还是回到了使用 makefile 的情况，并结合使用 shell 和批处理脚本或 Perl 脚本来完成工作（因为如果我希望用户来构建我的软件，我还是最好选择一种到处都可以用的命令行脚本语言）。

跨平台的用户界面的实现很困难。在过去几年中我已经使用了一些跨平台 GUI，并且我认为这些事情上并没有最优解。基本上有两种选择。你可以选择一个跨平台工具去做一个并不是完全适合你所有支持的平台的 UI，但是代码库比较小，维护成本比较低。或者你可以选择去开发针对平台的 UI，那样看起来更原生，集成的也更好，但是需要更大的代码库和更高的维护成本。这种决定完全取决于 APP 的类型、它有多少功能、你有多少资源，以及你要把它运行在多少平台上？

最后，我认为用户比较接受这种“一个 UI 打通关”了，就比如 Electron 框架。我有个 Chromium + C + C# 的框架侧项目，有一天我希望可以用 C# 构建 Electron 型的 app，这样的话我就可以做到两全其美了。

我依赖的使用方面很保守，我被崩溃的 ABI（LCTT 译注：应用程序二进制接口）、冲突的符号、以及丢失的包等问题困扰了太多次。我决定我要针对的操作系统版本，并选择最低的公有部分来使问题最小化。通常这就意味着有五种不同的 Xcode 和 OSX 框架库，要在同样的机器上相应安装五种不同的 Visual Studio 版本，多种 clang（LCTT 译注：C语言、C++、Object-C、C++ 语言的轻量级编译器）和 gcc 版本，一系列的运行着各种发行版的虚拟机。如果我不能确定我要使用的操作系统的包的状态，我有时就会静态连接库，有时会子模块化依赖以确保它们一直可用。大多时候，我会避免这些很棘手的问题，除非我非常需要使用他们。

基本每天都用。这是保持高效的唯一方式。我在一个项目中做的第一件事情是配置跨平台构建脚本，保证每件事尽可能自动化完成。当你面向多平台开发的时候，持续集成是至关重要的。没有人能在一个机器上构建各种平台的不同组合，并且一旦你的构建过程没有包含所有的平台，你就不会注意到你搞砸的事情。在一个共享式的多平台代码库中，不同的人拥有不同的平台和功能，所以保证质量的唯一的方法是跨团队代码审查结合持续集成和其他分析工具。这不同于其他的软件项目，如果不使用相关的工具就会面临失败。

对于不包括 UI 的工具和库，我通常使用自动构建测试。如果有 UI，两种方法我都会用到——针对已有的 GUI 工具的可靠的、可脚本化的 UI 自动化少到几乎没有，所以我要么我去针对我要跨我所支持的平台创建 UI 自动化工具，要么手动进行测试。如果一个项目使用了定制的 UI 库（比如说一个类似 Unity3D 的 OpenGL UI），开发可编程的自动化工具并自动化大多数工作就相当容易。不过，没有什么东西会像人一样双击就测试出问题。

我喜欢使用跨编辑器的构建系统。我更喜欢在不同的IDE上保存项目文件（这样可以使增加 IDE 变得更容易），通过使用构建脚本让 IDE 在它们支持的平台上去构建。对于一个开发者来说编辑器是最重要的工具，学习它们是需要花费时间和精力的，而它们是不可相互替代的。我有我自己喜欢的编辑器和工具，每个人也可以使用他们最喜爱的工具。

跨平台开发者被限制在只能选择可以在多数平台上工作的所共有的不多选择之一。我爱用 Visual Studio，但是我不能依赖它完成除 Windows 平台之外的工作（你可能不想让 Windows 成为你的主要的交叉编译平台），所以我不会使用它作为我的主要 IDE。即使可以，跨平台开发者的核心技能也是尽可能的了解和使用大量的平台。这就意味着必须很熟悉它们——使用该平台上的编辑器和库，了解这种操作系统及其适用场景、运行方式以及它的局限性等。做这些事情就需要头脑清醒（我的捷径是加强记忆），我必须依赖跨平台的编辑器。所以我使用 Emacs 和 Sublime。

我一直很喜欢 Mono，并且得心应手，其它的项目大部分都是以某种方式围绕着它进行的。Gluezilla 是我在多年前开发的一个 Mozilla 绑定，可以把 C# 开发的应用嵌入到 Web 浏览器页面中，并且看起来很有特色。我开发过一个 Winform 应用，它是在 linux 上开发的，它可以在 Windows 上运行在一个 Mozilla 浏览器页面里嵌入的 GTK 视图中。CppSharp 项目（以前叫做 Cxxi，更早时叫做 CppInterop）是一个我开始为 C++ 库生成 C# 绑定的项目，这样就可以在 C# 中调用、创建实例、子类化 C++ 类。这样，它在运行的时候就能够检测到所使用的平台，以及用来创建本地运行库的是什么编译器，并为它生成正确的 C# 绑定。这多么有趣啊。

我们构建本地应用程序的方式已经改变了，我感觉在各种桌面操作系统的明显差异在慢慢变得模糊；所以构建跨平台的应用程序将会更加容易，而且对系统的集成也不需要完全本地化。不好的是，这可能意味着应用程序易用性更糟，并且在发挥操作系统特性方面所能做的更少。库、工具以及运行环境的跨平台开发是一种我们知道怎样做的更好，但是跨平台应用程序的开发仍然需要我们的努力。

跨平台开发者的经验之谈

标签：

原文地址：http://www.cnblogs.com/linux130/p/5887404.html