SpaceX 龙飞船中的新触控交互操作系统，意味着什么？ 第1页

意味着 JavaScript 上天了！

据本台刚刚收到的消息，SpaceX 龙飞船的触控 UI 基于 Chromium + JavaScript 技术栈开发，开放的 Web 技术就此成为了人类首个应用到载人航天领域的 GUI 技术栈。相信这对数百万前端开发者们来说是个更为历史性的时刻。

这个基于 Web 技术打造的触控 UI 界面是这样的：

这个消息可能为业界带来什么重大影响呢？下面是本台洋葱新闻时间：

• 仅在一夜之间，Electron 风评即由「笨重臃肿的 Chrome 马甲套壳」变成了「稳定安全的航天级 GUI 基础架构」。
• 在飞船 UI 系统宕机时，宇航员手册中记载了最后的应急方案，那就是删掉 node_modules 然后 npm install。
• 「面试造火箭」一语成谶，「宇宙飞船 UI 架构设计」现已加入 BAT 前端面试题库。
• 前端培训班题材纷纷由「高仿美团饿了么首页」转向「高仿宇宙飞船控制台」，全套教学视频 + 源码仅需 998。
• 各大前端框架争相游说各国载人航天团队，史称前端太空竞赛。
• 社区开始争论 React Hooks 和 Vue Composition API 哪个更适合登月。
• SpaceMVC 项目取代 TodoMVC，成为了下一个前端框架的 battle 标准。
• 工程师一旦发现飞船超重，第一个排查问题的位置就是 node_modules。
• 某国湿婆神号飞船任务失败，原因竟是该国程序员屏幕上的咖喱混淆了 == 和 ===，导致类型比较出错。

言归正传，这条新闻的出处仅仅是一条非官方的 Tweet。在 Fake News 横行的今天，怎样确定龙飞船 2 号用的就是 JavaScript 呢？SpaceX 并没有开源他们的技术栈，但仍然有不少可供交叉验证的有趣信息源，今天摸到了条大鱼啊（笑）。

首先，推文中附上了四年前 Stack Exchange 上 对猎鹰 9 号计算机技术栈的讨论，其中的主要信息源则是 Reddit 上 SpaceX 软件团队的 AMA 介绍 。另外，Hacker News 上近期也有活跃的 后续讨论帖。这里对其中（与 GUI 部分相关的）主要信息整理如下：

• 龙飞船 2 号和猎鹰 9 号的飞控软件系统基于 Linux，其底层均由 C/C++ 实现。Chromium + JavaScript 属于这一系统中的太空舱界面（flight interface）部分。
• UI 界面有 100% 的测试覆盖率，包括对图形绘制结果的验证。
• UI 屏幕彼此之间是完全独立的，相当于冗余备份。
• UI 系统可以重启，在直播中对接国际空间站时就有这样的例子。
• 除了飞控系统中的 UI 外，SpaceX 还有其他需要 GUI 的地方。负责地面软件的团队使用 LabView 开发地面指挥中心的 GUI，企业 IT 团队则使用常见的 Web 技术栈开发项目管理、库存管理等内部后台系统。

上面这些信息除了 AMA 之外都可能有偏差，主要讨论者也未必是这套触屏 UI 的实际开发者。不过稍加搜索就能发现更有趣的料，那就是这套 UI 界面设计师自己的 Portfolio 页面：

看到这个页面的时候，我第一印象是这真不是「Lorem Ipsum」式的 Demo 吗……这也太梦幻了吧。但在找到设计师 AJ Fitzpartrick 的 LinkedIn 之后，基本可以确定这还真不是 PPT，有被羡慕到。

所以为宇宙飞船设计触屏 UI，到底是在干嘛呢？具体细节仍然处于保密状态，但这位设计师公开的工作描述包括了这些：

• 将航天员在飞行阶段的职责转化为软件需求，与太空运营团队合作，创建出用于驾驶舱触屏显示器的线框和 UI 流程。
• 向 SpaceX 团队和 NASA 客户（包括龙飞船的宇航员机组在内）介绍设计和 UI 流程。
• 基于太空旅行的独特条件，制定风格指南和设计规范，例如适应宇航员手套的触摸目标，以及保证震动时的易读性。
• 与软件工程师紧密合作，了解硬件和技术限制，确定用户体验上的空白和设计任务的优先级。
• 将设计产物和用于生产的素材交付给软件工程师。

虽然好像也不是特别复杂，但是这牛逼真是可以吹一辈子啊……

这里还有一个有趣之处，那就是这位 UI/UX 设计师此前并非来自「航空航天体制内」，而是做 App 与 Web 的设计出身的。他的代表作品包括索尼的全球设计规范和图片编辑器，还有 iOS 的社交应用等。这也体现了 SpaceX 在组建精英团队时的多元文化（例如做上面介绍的飞控软件的团队，其背景就来自于游戏、消费者软件、Web 开发、金融、电信、航空、学术界等）。所以做交互的同学们还是要有点志气，万一哪天我国的宇宙飞船也要招人做设计稿了呢？

至于 SpaceX 正式对外的分享资料，则主要来自 2016 年的 GDC 分享 。他们在其中介绍了新一代软件工具技术对他们的价值：

这页 PPT 直译过来是这样的：

• 算力上的进步开启了全新的可能性
• 存储、计算和渲染能力上的突破，使实现 3D 渲染和交互式地图等特性成为了可能。
• 移动设备在重量和能耗上的改进非常显著。
• 触摸屏已经很便宜，普及到随处可见。
• 浏览器是界面开发的新平台
• 各种库和框架提供了稳定的功能，并能快速实现原型。
• 现代化的开发和调试工具提高了迭代速度。
• 技术的跨业界通用性扩大了潜在的人选范围，减少了磨合时间。

PPT 上还有专门的一页讲了触摸屏技术：

要点直译过来也很简单：

• 将操作控制移到显示屏上后，极大地减少了空间占用和混乱。
• 通过多个相同的显示屏，很容易实现冗余备份。
• 触摸屏的泛用性使得开发变得容易，还能流水线式地执行训练和测试。
• 基于软件的界面布局，提高了迭代速度。

这就是新一代 UI 技术栈对航天领域的影响了。

不过对于到此为止的这些内容，仍然可能会有些「这不就只是用 JS 画了点花里胡哨的东西而已吗」的质疑。但其实在即将发射的 詹姆斯·韦伯太空望远镜（JWST）里，NASA 已经在用 JavaScript 操控太空望远镜的观测计划了：

在 JWST 机载架构中，活动计划均由地面上传。每个计划都包含了多个 Visit，它们通过上层的机载 JavaScript 来处理。而每个 Visit 则会包含由下层机载脚本处理的观测活动（如探测器配置、回转请求等）。这些机载脚本会构建出命令和遥测请求，从而操作观测子系统（如科学仪器、航天器总线中的姿态控制子系统等）。

这个架构设计写在了介绍 JWST 的论文（JWST: Maximizing Efficiency and Minimizing Ground Systems）里，如图所示：

对于这个破天荒地引入 JS 引擎的操作，其实还有另一篇论文，讲了事件驱动的 JWST 操作设计（Event-driven James Webb Space Telescope Operations）。NASA 使用的是一个由 Nombas 公司开发的普通商用级 JS 引擎，它被嵌入在了 VxWorks 实时操作系统中。论文中探讨了在 JWST 中引入事件驱动架构的优势，值得感兴趣的同学拓展一下视野。

Nombas 公司在《JavaScript 20 年》中登场过。它虽然名不见经传，但其实也是首次 TC39 会议的参与者，当时的产品是名称跟 C++ 相反的 Cmm（C minus minus）语言。后来他们在此基础上研发出了嵌入式 ECMAScript 引擎 ScriptEase，亦即被 NASA 选用的产品。这家公司后来被 Openwave 收购。

到此为止，我们已经看到 JavaScript 这门「罄竹难书」的语言，居然已经开始在无比高大上的航天领域崭露头角了。在《JavaScript 20 年》史书的结尾处，JS 之父 Brendan Eich 是这样为 JS 正名的：

• 最早他们说 JavaScript 没法做「富互联网应用」。
• 然后他们说 JavaScript 没法快起来。
• 然后他们说 JavaScript 没法修复语言问题。
• 然后他们说 JavaScript 没法做多核与 GPU 运算。

今天我们可以再补一条：然后他们说 JavaScript 没法做航天级项目。

Wrong every time!

于是我们再次应证了这条规律：Always bet on JS.

当然了，用不用 JS 说到底看的还是实际场景，龙飞船成功的关键也并不是 JS，而是大量前沿科学与工程领域实打实的硬核积累。但作为 GUI 开发者，这里还是许个小小的祝愿，希望有生之年大家做的 UI，能有机会帮助人类飞向更大的世界吧。