标签 跨平台 下的文章

Andreia Gaita 在 OSCON 开源大会上发表了一个题为跨平台开发者的自白的演讲。她长期从事于开源工作,并且为 Mono 工程(LCTT 译注:一个致力于开创 .NET 在 Linux 上使用的开源工程)做着贡献,主要以 C#/C++ 开发。Andreia 任职于 GitHub,她的工作是专注构建 Visual Studio 的 GitHub 扩展管理器。

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

在你开发跨平台代码中,你使用过的最简单的和最难的代码语言是什么?

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

你使用的跨平台开发工具或者抽象层有哪些?

我的大部分跨平台工作都是为其它需要开发跨平台应用的人开发工具、库和 绑定 binding ,一般是用 MONO/C# 和 C/C++。在抽象的层面我用的不多,更多是在 glib 库和 友元 friends 方面。大多数时候,我用 Mono 去完成各种跨平台应用的,包括 UI,或者偶然在游戏开发中用到 Unity3D 的部分。我经常使用 Electron(LCTT 译注: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 版本,一系列的运行着各种发行版的虚拟机。如果我不能确定我要使用的操作系统的包的状态,我有时就会静态连接库,有时会子模块化依赖以确保它们一直可用。大多时候,我会避免这些很棘手的问题,除非我非常需要使用他们。

你使用持续集成(CI)、代码审查以及相关的工具吗?

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

你依赖于自动构建测试,或者倾向于在每个平台上构建并且进行本地测试吗?

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

如果你要做跨平台开发,你喜欢用跨编辑器的构建系统,比如在 Windows 上使用 Visual Studio,在 Linux 上使用 Qt Creator,在 Mac 上使用 XCode 吗?还是你更趋向于使用 Eclipse 这样的可以在所有平台上使用的单一平台?

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

在跨平台开发的时候,你更喜欢使用什么样的编辑器、开发环境和 IDE 呢?

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

你之前和现在最喜欢的跨平台项目是什么?

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

你怎样看跨平台开发的未来趋势呢?

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


via: https://opensource.com/business/16/5/oscon-interview-andreia-gaita

作者:Marcus D. Hanwell 译者:vim-kakali 校对:wxy

本文由 LCTT 原创翻译,Linux中国 荣誉推出

随着安全性问题变得越来越重要,密码当然是越安全越理想(比如多步认证),这一点再强调也不为过。

因此,于是我最近就试用了几个安全密码管理器,试图找到一款比较安全,易于使用并且跨平台的应用软件。

首先,我尝试了LastPass。LastPass大概最为人们所熟知,因为它是基于WEB管理密码的,是所有软件中平台无关性最强的。但是我发现它的界面简陋,而且提供太多的工具和选项,比较繁琐。

接下来,我又试了试KeePass 2。尽管是一款功能相当完善的应用软件,非常类似于下面我将要描述的,但是官方没有提供Linux的安装包,而且社区移植的版本,虽然可用,但仍然算不上最好的。所以我又尝试了其他应用。

在所有的试用过的软件中,我最喜欢的是 KeePassX 。 它原来是KeePass的在Linux上的移植版,但是后来演变成了独立的应用。凭借更漂亮、更原生的外观,KeePassX 打败了KeePass 2。

在ubuntu中使用KeePassX

方便的是,KeePassX已经提供在ubuntu上安装的软件包。

从命令行安装KeePassX或者 从软件管理中心安装

安装后打开它,你会看到一个空白窗口。点击工具条上的第一个按钮来创建一个新数据库。你可以使用密钥文件或者密码保护这个刚刚创建的数据库。一般你会使用密码,因为只需要记住它并输入就行了 - 你应该输入较长的密码,这样你就可以防止其他人使用你的数据库。

接下来,你得把它存到某个位置。我保存在我的Dropbox里面,这样就可以从多个地方获取。Dropbox使用双因子认证,所以如果有人想进到我的Dropbox里面,他就得拿到我的手机,这样的方式是还是相当安全的。

或者你也可以使用其他的服务,比如Google Drive和Skydrive,它们都可以使用认证器应用;也可以使用Box,它用短信进行双因子认证。

当然,如果你 真的 很在意自己的密码,你很可能不想把密码存到其他的组织,因为理论上密码是可以被他们获取到的。

Ubuntu中KeePassX的主界面

使用该应用还是相当直观明了的。你可以添加分组,然后在分组里添加密码。KeePassX带有一个很方便的密码生成器,当你需要输入一个密码的时候可以使用该生成器,而不用自己构思一个。我倾向于使用所有基本的字符以及挑选的特殊的字符来生成我的密码,20个字符的长度,当然这得看你访问的网站接不接受了。

需要注意一点,有些网站并不告诉你他们接受多长字符的密码,倾向于只在输入框限制输入长度。如果你粘贴进去的密码看起来没那么长,很可能就不是你要输入的口令,而被截断了。这种情况我碰到过几次。

KeePassX 密码生成器

根据日常的使用经验,我积累了一些小的技巧,使得操作KeePassX更简单一些:

关于复制粘贴的担心

像这样复制粘贴密码,你可能会比较担心。可以肯定的是这比手动输入高效多了。默认情况下,KeePassX会在一分钟后清空粘贴板,你也可以设置更短的时间,所以不必担心有人会在你电脑上把密码粘贴下来查看。你也可以开启一个AutoType的特性,不过这对于我来说没用。Chris Zuber 在评论里面说明了如何使用 AutoType 。

数据库的困境

如果你把数据库存放到云端,就不要为云端服务设置完全随机的密码。如果你不能进入到云,但是又把云密码存储到云里边,这是完全没有用的。这看起来似乎很明显,但是刚开始我却没有意识到这一点。

确保所有的密码都是安全的

为了查看常用的账号,工作或者学习的时候要频繁地掏手机,这也是一件挺痛苦的事儿,所以设置密码的时候不妨想象一下这种情形,哈。

未来

如果你以前也深入了解过KeePass 2和KeePassX,或许会注意到二者使用不同的数据库格式。

KeePass 2使用一种新的版本格式,比如允许自定义字段。尽管KeePassX目前还不支持新的.kdbx格式,不过正在开发中的新的版本会支持的。

可以预览一下新版本的KeePassX,界面大为改善。你也可以从GitHub上6下载后自己安装。

KeePassX 2.0 主界面

密码项的一些细节

密码项的附加属性

历史登陆信息,比如从先前的版本替换掉"Backup"文件夹之类的

KeePassX 2.0 中的配置

其他建议

正如本文开头所说,我在寻找能够跨平台的东西。这正是.kdb格式的优点 - 很多应用都支持这种格式。KeePassX 在 Mac OS X上运行起来要比KeePass 2容易得多,在windows上也可以。

Android系统上,我使用KeePassDroid6,在我的手机和平板上运行都很稳定。

via: http://www.omgubuntu.co.uk/2013/10/manage-passwords-securely-keepassx

译者:l3b2w1 校对:wxy

本文由 LCTT 原创翻译,Linux中国 荣誉推出