有人知道开发 Spotify 桌面应用程序时使用了哪种语言或技术吗？ 稳定、美观、轻巧。
【问题讨论】：
标签： desktop-application spotify
从这里：http://www.quora.com/What-is-the-technology-behind-the-Spotify-desktop-app
日期：2014-09-09
Andreas Blixt，在 Spotify 工作了 5 年的员工：
我们所有客户端的核心都是 C++，但自 Rasmus 的 帖子被压缩了，功能被分成模块。作为 Spotify 在越来越多的平台以及 获得更丰富的功能集，我们需要确保“核心”不 成为“一切的一点点”。这意味着爆发 某些功能，例如播放控制，变成自己独立的 模块。这些模块仍然是 C++，但足够独立 他们的逻辑理论上可以在其他地方实现 语言。我们将这些模块的接口层称为“Cosmos”，并且 它的工作方式与 HTTP 不太相似。 Cosmos 允许任何部分 客户端使用任意路径与模块通信，并且 有效载荷，允许更灵活的架构。一些明显的 好处是版本化接口（例如：GET sp://player/v1/main 返回播放器状态）和 JSON 用于传递数据。这是 对我们桌面客户端的另一项更改很重要。
如今，我们的很多桌面用户界面实际上都在使用 Chromium Embedded 框架（CEF），这基本上意味着我们的观点是由 JavaScript、HTML 和 CSS。让我们所有的功能团队能够 在他们的特征上工作而不用担心破坏别人的观点， 每个视图都在自己的“浏览器”中进行沙盒处理（我猜你可以认为 的视图作为 Chrome 中的选项卡，但我们同时显示多个 时间）。但是，这带来了一个限制：共享数据 视图之间变得更加困难。这就是 Cosmos 的用武之地 真正简化了核心 (C++) 和 JavaScript 之间的通信 土地：JS 客户端可以发出任意请求，如果有 绑定，该请求得到处理和响应。一个例子是 “消息”端点，它允许任何视图将 JSON 数据推送到任何 其他正在监听的视图（有点像 HTML5 中的 window.postMessage， 除了这个还可以与 C++ 模块接口）。这也是如何 客户端中的所有播放按钮都知道曲目是否正在播放或 不是，或者它是否可以离线使用（另一个 Cosmos 模块），或者 是否已将歌曲保存到音乐中。
我们的技术堆栈的另一个重要变化是我们已经移动 一些逻辑进一步“返回”，进入视图聚合服务。所以我们在哪里 之前会在客户端执行几乎所有逻辑，仅使用 后端作为数据存储，我们现在在逻辑层做更多的工作 在数据存储和客户端之间，非常暴露端点 类似于 Cosmos（实际上，您可以使用完全相同的方式调用后端 你称之为 Cosmos 模块，所以在层之间移动并不麻烦）。 这样做的原因有两个：第一，它让我们扩展到更多 平台更快，因为要实现的客户端逻辑更少 第二，它确实有助于我们保持客户行为更加一致 并且是最新的，因为客户更“愚蠢”。为了减轻任何 可能由此产生的减速 我们已确保有 缓存所有数据的规则，这样客户端仍然会保留数据 在本地，它只是不负责尽可能多的业务逻辑 曾经。
【讨论】：
这是他们使用的第三方组件列表（当然是在 C++ 之上）：
【讨论】：
根据 Spotify 设计师的说法：
http://twitter.com/#!/tobiasahlin/status/96483609799692288
“其中一些是 C++，还有一些是 HTML 风格的标记语言，称为 Spider” “它专为在 Spotify 中使用而构建”
【讨论】：
Spotify 现在使用Chromium Embedded Framework (CEF) 在桌面应用程序中显示由 HTML/CSS/JavaScript 组成的 Web 界面。
【讨论】：
来自他们的website：
Spotify 主要使用 Python 和 C++ 构建
【讨论】：
鉴于它在 Windows 上运行，显然不是 .NET（进程资源管理器告诉我），没有遵循 AIR 安装过程，我会说 C++ 使用跨平台库。
一切都被编译成一个可执行文件，这表明他们可以访问所有依赖项的源代码。
W.r.t to Techno...我认为他们使用的是 Hardhouse Electronica
【讨论】：
这个答案更新了，来自他们的工程博客：https://engineering.atspotify.com/2021/04/07/building-the-future-of-our-desktop-apps/
Spotify 桌面客户端是一个 Windows 和 Mac 原生应用程序，它使用 CEF（Chromium Embedded Framework）来显示基于 Web 的用户界面。今天仍然如此，但对于以前版本的 Desktop，客户端中的每个“页面”都构建为独立的“应用程序”，以在其自己的 iframe 中运行。
然而，他们最近不得不更新他们的架构，因为他们想以一种单一团队可以开发和为两个客户提供功能。
最终架构看起来像一层平台 API，将底层 Spotify 生态系统暴露给客户端，具有基于 React 的用户界面和通过 React Hooks 暴露的平台 API。因此，新 UI 可以在 Web 上运行，它可以在我们的桌面容器中运行，并且永远不知道或关心数据是来自我们的 C++ 堆栈还是我们的 Web 基础架构。
【讨论】：
在这里查看第一个答案： https://www.quora.com/What-is-the-technology-stack-behind-the-Spotify-web-client
Spotify 前技术主管 Andreas Blixt 详细回答了这个问题。
我们有一个 PHP 层来处理登录（以及其他一些 服务器端逻辑）以及为不同域上的应用程序提供服务（对于 安全原因）。剩下的都是 JavaScript。
为了让 JavaScript 与后端通信，它通过 我们所说的“接入点”（AP），一种高度优化的 C++ 服务 它可以一次处理大量活动连接。这项服务是 负责将请求路由到正确的后端服务。这 服务能够在端口 80 和 443 上运行以克服 防火墙限制。通信是通过 WebSocket（或 Flash 适用于某些浏览器）。
为了与特定的后端服务通信，我们路由请求 使用我们自己的名为“Hermes”的交通工具通过 AP。这是 基本上是一个 URL 方案，让 AP 知道将 要求。有效载荷被编码为 Protobuf。爱马仕有一个很好的缓存 将结果存储到 IndexedDB 的系统（我们称之为“Mercury”） 支持它的浏览器（我们在桌面有相同的系统 客户端，而是在 C++ 中实现），以避免请求相同的 数据两次。这对于重新请求的资源非常有用 很多，例如艺术家、专辑和曲目。
对于 UI，我们编写了一个非常高级的应用程序框架 （称为“缝合”）允许开发每个视图 由不同的团队独立进行，而不必担心 打破任何东西。视图在沙盒中运行，但可以 仍然依赖共享库来处理常见的事情，例如加载 跟踪元数据等。截至撰写本文时，我们有大约 35 个独特的视图（或 应用程序）在网络播放器中。
视图通过我们所谓的“桥梁”获取数据并执行操作 （基本上，一个API）使用postMessage，所以我们不需要 重新初始化每个应用程序的所有通用代码。真正酷的东西 关于这一点，我之前提到的很多〜35个视图可以 实际上也在桌面客户端内部运行而无需修改。的 当然，他们将使用 Chromium 挂钩而不是 postMessage 嵌入式框架和我们的 C++ 核心。
我们尝试尽可能多地使用 HTML 5 技术，但在某些情况下 情况取决于 Flash。我认为我们有一个非常酷的技术堆栈 我们的网络播放器。
【讨论】：
前端是用 FLEX 编写的，请在您的 mac 或 windows 机器上查看源代码。你会看到很多 flex 文件格式的 xml 文件。
当然，与服务器和平台集成的连接可能是用 C++ 原生编写的。但是 UI 部分只是 FLEX...
【讨论】：