Linux和Android：哪个是你下一个设计的正确选择？

如果你的下一个应用会部署在一个32位或64位处理器和TCP/IP网络的设备上，那么现在正是好机会，因为你已经考虑选择Linux或者Android作为你的操作系统。将原有实时操作系统和内核相比较，无论是Android还是Linux都是成熟的企业/桌面级操作系统。它们都能运行现成的中间件和打包应用程序，即便是在专门的和移动应用环境中。然而，这两个开源的操作系统从软件堆栈的底层到顶层的开发、集成和托管方式都不一样，而这些都影响着如何以及在何处找到最好的部署方案。

本文将会整理出在选择小绿机器人或矮胖企鹅时要考虑的决定因素。特别地，本文关注的是为何在不同的使用场景下需要不同的开发方法，为何是使用这个操作系统而不是另一个，为何有些应用程序只需使用一个操作系统，而有时候却同时需要这两个操作系统。

接下来的内容部分代表了一个经典的“思想运动”，但实际上这个讨论源于一系列围绕以能源管理，IVI（汽车信息娱乐系统），网络和智能显示设备为前提的项目目标的对话和产品设计的辩论。

开放盒子还是封闭盒子？

绝大多数的原有系统都是非常封闭的实体。即使选中的实时操作系统支持标准的API（典型的如POSIX线程和/或BSDlite 网络的子集），为那些平台精心定制或托管在那些平台上的应用程序也还都是高度定制的。它们也仍然是唯一的在整个生命周期中运行在那些系统的软件。相比之下，那些部署在智能手机、平板电脑和其他越来越多的现代智能设备上的软件已经更像桌面**务器系统软件了。由于有了越来越多的现代设备，原始设备制造商、运营商和终端用户已经可以在设备的整个使用过程中安装新应用程序包了。固件和系统软件也已能在不依靠特殊的工作台软件或工厂式RMA（翻修）程序的情况下完成升级。

在创造一个智能手机操作系统时，Google将Android定位为一个开放的、现场可升级的应用程序平台，这个移动操作系统的核心思想是随时能够运行应用程序包。因此，为了创建，销售和部署打包应用程序，围绕着Android平台生态环境的优化首先是通过Google Play应用商店进行的。

Linux系统也存在着和Android应用程序平台同样的情况，但从实践的角度来看，它更适合一次性部署在封闭盒应用中。确实如此，Linux上的编程存在着更多被认可的编程方法，比如C，C++，Java，Ruby，Python，Lua等等，但却不存在一个为构建、发布和安装应用程序的单一模型，也不存在一个跟Android一样的支持（如果不确定）互操作性的硬件抽象模型。相反，存在着多种特定的方法（如包管理，apt-get等方法）和工作在不同内核体系架构树（Kernel Tree）中的普通/最佳实践。

由于这些务实的原因，Linux有点更适合于封闭或半封闭的应用程序。如果不需要广泛的互操作性，也不用考虑是否会破坏API和打包应用程序，原始设备制造商（OEM）就可以从约束中解脱；这还能让他们从为设备的硬件和软件需求专门做定制和适配Linux的工作中解脱。若当一个生态系统围绕单一设备演变（就好像发生在Raspberry Pi和Python上），Linux的例子总能打破封闭盒子策略，就好像使用了Dalvik虚拟机和亲睐于Java的Android一样。

有一点需要注意，不要把开放盒子和封闭盒子的问题与开源和不开源的问题混淆。Linux内核和GNU/Linux操作系统远比Android更开源。维护和升级Linux的社区是真正的精英管理的社区，它对各种来源的资源都开放。相比之下，Android是Google和它的顶级合作伙伴OHA可以发号施令和掌控平台发展路线图的私人俱乐部，它只接受了外界组织的最小输入。

你是想预算还是省点钱？

和开放/闭合盒子有关的问题是资源丰富与否的问题。有一个极端资源不足的例子是说只有一个网络接口的大块头的设备，而一个极端资源丰富的设计则需要一个显示器、键盘、定点设备或触摸屏，一个健壮的内存和存储器部件等。世界上最真实的设计则是介于这两者之间。

鉴于其智能手机的遗产，Android适用于拥有丰富接口的消费电子类应用程序。在盒子之外，Android协议栈支持手持和平板类型的配置，而且它正越来越多地被部署在DTV，机顶盒，IVI系统和其他用户界面密集型系统上。因此，没有多少令人信服的理由去说服人们在无外设的系统上使用Android系统。

相反，Linux能够支持的硬件配置和外围设备范围非常广泛而且丰富，它还可以根据需要被裁减为一个只拥有内存、存储器等的极度精简的系统。若没有几百MB甚至GB的DRAM或更多的Flash空间（对于操作系统和应用程序），是无法将Android部署在这样的系统之上的，但你可能只需要几十MB的存储空间就能部署一个简约型Linux系统（天啊，我从未想到过我会认为Linux是那么的小！）。在为精简硬件配置挑选系统时，另一个不投票给Android的原因是Android是CPU/GPU密集型的系统。

所以，如果你的设计是想通过部署一个低端CPU，不使用GPU，并且最小化内存和存储器来达到降低成本的目的，那么Linux是一个更合适的选择。如果你有很多钱拿来“烧” -- 这些年，硅的价格只要几美元了，但显示器和输入硬件则很可能是需要几万美元的，那么这时候Android会更适合你。

本地显示还是自带设备（BYO）？

在上个月的RTC杂志上，我写了一篇为无外设系统挑选可用设备作为显示服务器的文章。在文中我强调了本地无外设系统设计是如何利用在附近或远程的基于浏览器显示设备的，包括智能手机、数字电视等。在Android和Linux中选择其一的前提下，需要一个本地的还是远程的显示器是另一个决定因素。若你的设备需要一个近距离的身体上接触的显示，那么拥有一个集成用户接口（UI）的Android是一个不错的选择。但如果用户主要是想在远处通过浏览器或专用的智能手机和平板电脑应用程序来与设备交互，那么你可以通过支持使用Linux来托管Apache服务或几个小Web服务器**务器端的编程范例（PHP，Python，C等）达到省掉Android系统的开销的目的。

当然，你可以根据需要同时配置Android和Linux来支持本地显示、网络接口或移动应用程序。两个操作系统都支持丰富的用户接口，而且都很容易被部署为Web服务器。但现成的Android应用程序只能运行和显示在一个Android原生显示设备上，而使用GTK+或Qt创建的Linux原生应用则要求一个本地显示器或一个可用的远程X服务器。

选择Java或C/C++,还是LAMP？

一个半技术性的论点是Android或Linux是熟悉的编程语言和框架。如果你的团队已经在一些其他环境中创建了Java应用程序，那么你很可能会希望可以利用这个专业知识去创造其他设备上的应用程序（甚至是无外设的设备）。但如果你的开发人员更熟悉C/C++，Lua，GTK+和QT类似的UI框架及无数的其他编程范式，那么强烈建议你选择Linux和/或LAMP（Linux，Apache httpd，MySQL和PHP/Perl/Python）。

这个论点并非是很明确的，还要和在座的其他人一起讨论。你也可以使用Android/Linux本地编程接口来创建你的应用程序，但你可能会打破Android应用程序的互操作性和封装，并且不再拥有一个开放盒子。还请记住，在选择某种语言和框架的同时往往还要考虑是本地显示还是远程显示。另外，也许更解放性的思想是当今开发人员通晓多种语言，这样无论在Android还是在Linux上使用Java，C++或Web编程语言都会感到同样舒适。

考虑许可证

一套非技术然而复杂的以许可体制为中心的选择标准围绕着Linux和Android以及写给这两个操作系统的应用程序和扩展展开。许多原生设备制造商之所以采用Android是因为这个移动操作系统的自由许可条款：实际上Apache 2.0对于Android中间件及其应用程序的组件只是在底层Linux级别的通用公共许可证（GNU GPL）部分对原生设备制造商有披露资料的要求。Android中的顶级Apache许可证总是注明“OEM friendly”，是因为设备制造商修改了Android堆栈的大部分，并使用了在Apache和任何其他OSS许可证（表1）下都不需要披露修改和分发他们自己的代码的硬件抽象层（HAL）来添加了外围设备接口。实际情况稍微有些复杂，这在Black Duck的文章“Android-Opportunity，Complexity and Abundance”中有论述。

表格1 各种Android和Linux堆栈层的许可

这不是一个反对Linux的例子—它只是很可能完美地在一台运行着Linux的设备上隔离和保护专有代码。然而，修改和添加到Linux堆栈上的每一种类型都需要考虑它自己的实际情况（见表1）。特别地，一些原生设备制造商不喜欢直接在任何GNU许可证（GPLv2/v3，LGPL等）下工作，这就导致他们选择了Android，而非Linux。当然，他们仍然需要部署Linux内核，但运行其上的Android库和中间件仅仅将它作为一个“缓冲器”。通常做到这样就可以感到很舒适了。

在这里，我们的目的只是为各种类型的智能设备提供选择Android或Linux的一般指导方法。对于垂直应用程序（手机、医学设备、运输工具等）而言，这种分类本身并不想列出所有的方法，而是想提供开发范例依赖的选择标准，或者提供考虑设备市场和部署生命周期的途径。

表2总结了本文表述的论点。它强调了选择不是绝对的：由于Android包含了一个Linux内核实例，Android系统理论上可以托管和运行和Linux一样的软件。Linux同样因为能托管和运行Java，以及一系列的用户接口（UI）框架，它也能被部署在有本地显示器的设备中，即使在和Android有密切关系的手机、平板电脑和其他设备上。

表2 总结了Android和Linux特点的论点

所以，去使用Android或Linux或同时使用这两个操作系统吧。但需要先考虑以下问题：

在你的设备的整个寿命中，系统软件和应用程序是如何部署的？你想将你的预算中的大部分花在哪些地方上？设备主要有哪些用户交互模式？你的开发人员有哪些编程嗜好？你选择的平台和许可证对你公司的知识产权（IP）组合有怎么样的影响？