10 KiB
一位跨平台开发者的自白
Andreia Gaita1将会在OSCON开源大会上发表一个题为跨平台开发者的自白的演讲。她长期从事于开源工作，并且为Mono3【译者注:一个致力于开创.NET在Linux上使用的开源工程】工程做着贡献。Andreia任职于GitHub，她的工作是专注于为Visual Studio构建github上的可扩展管理器。
我在她发表演讲前就迫不及待的想要问她一些关于跨平台开发的事，作为一名跨平台开发者，她已经有了16年的学习经验了。
在你跨平台工作的过程中，你使用过的最简单的和最难的代码语言是什么?
很少讨论某种语言的好坏，大多数是关于对于这种语言的库和工具的易用性。编译器、解释器以及构建器语言决定了用它们做跨平台开发的难易程度(不论它是否可能)，能够实现UI和本地系统访问的函数库的可用性都决定了开发时兼容操作系统的程度。如果这样想，我认为C#最适合完成跨平台开发工作。这种语言有它自己的特色，它允许本地快速唤醒和精确的内存地址；如果你希望你的代码能够与系统和本地函数库进行交互，那么你就会需要C#。当我需要特殊的系统集成的时候，我就会切换到C或者C++。
你使用的跨平台开发工具或者抽象有哪些？
我的大部分跨平台工作都是为其他人开发工具和库，然后把它们组合起来开发跨平台的应用程序，其中大多用到MONO/C#。说真的，我不太懂抽象。大多数时候，我依赖Mono去完成一个跨平台的app开发以及它的UI，或者一个偶然的游戏开发中的Unity3D部分。我经常使用Electron【译者注：Atom编辑器的兄弟项目，可以用Electron开发桌面应用】。
你接触过哪些构建系统？它们之间的区别是由于语言还是平台的不同？
我试着选择适合我使用语言的构建系统。那样 ，就会很少遇到让我头疼的问题。它需要支持平台和体系结构间的选择、构建智能工件位置（多个并行构建）以及易配置性等。大多数时候，我的项目会结合C/C++和C#，同时我也想要为一些开源分支构建相应的配置环境（Debug, Release, Windows, OSX, Linux, Android, iOS, etc, etc.)），通常也需要为每个构建的智能工件选择带有不同标志的编译器。所以我不得不做很多工作，而这种以我的方式进行的工作并没有很多收获。我时常尝试着用不同的构建系统，仅仅是想了解到最新的情况，但是最终我还是回到使用makefile的情况，采用shell和批处理脚本之一与Perl脚本相结合的方式，以达到使用他们的目的（因为如果我想用户去做很多我做的事情，我还是最好选择一种命令行脚本语言，这样它在哪里都可以用）。
你怎样平衡在这种统一用户接口视觉体验需求上的强烈渴望呢？
用户接口的跨平台实现很困难。在过去几年中我已经使用了一些跨平台GUI，并且我认为一些问题没有最优解。那些问题都基于两种操作，你也可以选择一个跨平台工具去做一个UI，去用你所喜欢的所有的平台，这样感觉不是太对，用小的代码库和比较低的维护费用。或者你可以选择去开发一个特有平台的UI，那样看起来就会是很本地化并且能很好的使其与一个大型的代码库结合，也会有很高的维护费用。这种决定完全取决于APP的类型。它的特色在哪里呢?你有什么资源？你可以把它运行在多少平台上？
最后，我认为用户对于这种框架性的“一个UI统治所有”的UI的容忍度更大了，就比如Electron。我曾经有个Chromium+C+C#的框架侧项目，并且希望我在一天内用C#构建Electron型的app，这样的话我就可以做到两全其美了。
你对构建或者打包有依赖性吗 ?
我很少谈及依赖性问题。很多次我都被ABI【译者注:应用程序二进制接口】的崩溃、存在冲突的征兆以及包的丢失问题所困扰。我决定我要使用的操作系统的版本，都是选择最低的依赖去使问题最小化。通常这就意味着有五种不同的Xcode的副本和OSX框架库 ，在同样的机器上有五种不同的Visual Studio版本需要相应的被安装，多种clang【译者注：C语言、C++、Object-C、C++语言的轻量级编译器】和gcc版本，一系列的可以运行的其他的VM版本。如果我不能确定我要使用的操作系统的包的规定，我时常会连接静态库与子模块之间的依赖确保它们一直可用。大多时候，我会避免这些很棘手的问题，除非我非常需要使用他们。
你使用能够持续集成的、代码重读的相关工具吗？
基本每天都用。这是保持高效的唯一方式。我在一个项目中做的第一件事情是配置跨平台构建脚本，保证每件事尽可能自动化完成。当你想要使用多平台的时候，CI【译者注：持续集成】是至关重要的。在一个机器上，没有人能结合所有的不同的平台。并且一旦你的构建过程没有包含所有的平台，你就不会注意到你搞砸的事情。在一个共享的多平台代码库中 ，不同的人拥有不同的平台和特征，所以仅有的方法是保证跨团队浏览代码时结合CI和其他分析工具的公平性。这不同于其他的软件项目，如果不使用相关的工具就只有失败了。
你依赖于自动构建测试或者趋向于在每个平台上构建并且进行局部测试吗?
对于不包括UI的工具和库，我通常能够侥幸完成自动构建测试。如果那是一个UI，两种方法我都会用到——做一个可靠的，可自动编写脚本的UI，因为基本没有GUI工具，所以我不得不在去创建UI自动化工具，这种工具可以工作在所有的我用到的平台上，或者我也可以手动完成。如果一个项目使用一个定制的UI工具（一个像Unity3D那样做的OpenGL UI ），开发自动化的可编写脚本工具和更多的自动化工具就相当容易。不过，没有什么东西会像人类一样通过双击而搞砸事情。
如果你要做跨平台开发，你想要在不同的平台上使用不同的编辑器，比如在Windows上使用Visual Studio，在Linux上使用Qt Creator，在Mac上使用XCode吗？还是你更趋向于使用Eclipse这样的可以在所有平台上使用的编辑器？
我喜欢使用不同的编辑器构建系统。我更喜欢在不同的带有构建脚本的IDE上保存项目文件（可以使增加IDE变得更容易），这些脚本可以为他们支持的平台去驱动IDE开始工作。对于一个开发者来说编辑器是最重要的工具，开发者花费时间和精力去学习使用各种编辑器，但是它们都不能相互替代。我使用我最喜欢的编辑器和工具，每个人也应该能使用他们最喜爱的工具。
在跨平台开发的时候，你更喜欢使用什么开发环境和IDE呢？
跨平台开发者好像被诅咒一样，他们不得不选择小众化的编辑器去完成大多数跨平台的工作。我爱用Visual Studio，但是我不能依赖它完成除windows平台外的工作（你可能不想让windows成为你的初级交叉编译平台，所以我不会使用它作为我的初级集成开发环境。即使我这么做了，跨平台开发者的潜意识也知道有可能会用到很多平台。这就意味着必须很熟悉他们——使用一种平台上的编辑器就必须知道这种操作系统的设置，运行方式以及它的局限性等。做这些事情就需要头脑清醒（我的捷径是加强记忆），我不得不依赖于跨平台编辑器。所以我使用Emacs 和Sublime。
你最喜欢的过去跨平台项目是什么？
我一直很喜欢Mono,并且得心应手，在一些开发中大多数的项目都是用一些方法围绕着它进行的。Gluezilla曾经是我在多年前开发的一个Mozilla【译者注：Mozilla基金会，为支持和领导开源Mozilla项目而设立的非营利组织】结合器，可以C#开发的app嵌入到web浏览器试图中，并且看起来很明显。在这一点上，我开发过一个窗体app，它是在linux上开发的，它运行在带有一个嵌入GTK试图的windows系统上，并且这个系统将会运行一个Mozilla浏览器试图。CppSharp项目(以前叫做Cxxi，更早时叫做CppInterop)是一个我开始结合绑定有C#的C++库的项目，这样就可以唤醒和创建实例来把C#结合到C++中。这样做的话，它在运行的时候就能够发现所使用的平台以及用来创建本地运行库的编译器；而且还为它生成正确的C#绑定。这多么有趣啊。
你怎样看跨平台开发的未来趋势呢?
我们构建本地应用程序的方式已经改变了，我觉得在各种桌面操作系统之间存在差异，而且这种差异将会变得更加微妙；所以构建跨平台的应用程序将会更加容易，而且这种应用程序即使没有在本平台也可以完全兼容。不好的是，这可能意味着应用程序很难获得，并且当在操作系统上使用的时候功能得不到最好的发挥。我们知道怎样把库和工具以及运行环境的跨平台开发做的更好，但是跨平台应用程序的开发仍然需要我们的努力。
via: https://opensource.com/business/16/5/oscon-interview-andreia-gaita
作者：Marcus D. Hanwell 译者：vim-kakali 校对：校对者ID