用什么语言或技术开发 Spotify 桌面应用程序？

有人知道 Spotify 桌面应用程序是使用哪种语言或技术开发的吗？ 稳定，漂亮，重量轻。

86024 次浏览
小开

考虑到它是在窗户上运行的，显然不是。NET (进程浏览器告诉我) ，没有遵循 AIR 安装进程，我会说 C + + 使用跨平台库。

所有内容都被编译成一个可执行文件，这表明它们可以访问所有依赖项的源。

从 W.rt 到 Techno... 我想他们用的是 Hardhouse 电子公司

小开

下面是他们使用的第三方组件列表(当然是在 C + + 之上) :

  • 加油
  • 外国人
  • 快速授权
  • Giflib
  • Libjpeg
  • Libogg
  • Libvorbis
  • 梅森旋转算法
  • Zlib
  • NSIS (只适用于视窗系统)
  • Windows Template Library (只适用于视窗)
  • 咆哮(仅限最大 OS X)
  • MATrackingArea (仅限 Mac OS X)
小开

前端是用 FLEX 编写的，检查你的 Mac 或 Windows 机器上的源代码。您将看到许多 xml 文件，它们采用 flex 文件格式。

当然，到服务器和平台集成的连接可能是用 c + + 本地编写的。但用户界面部分只是 FLEX..。

小开

来自他们的 网站:

Spotify 主要是用 Python 和 C + + 构建的

小开

Spotify 的一位设计师表示:

Http://twitter.com/#!/tobiasahlin/status/96483609799692288

有些是用 C + + 编写的，有些是用类似 HTML 的标记语言 Spider 编写的 “它只能在 Spotify 中使用”

小开

Spotify 现在使用 Chromium 嵌入式框架(CEF)在桌面应用程序中显示由 HTML/CSS/JavaScript 组成的 Web 界面。

小开

从这里: http://www.quora.com/What-is-the-technology-behind-the-Spotify-desktop-app
日期: 2014-09-09

安德烈亚斯•布利克斯特(Andreas Blixt) ，5年 Spotify 员工:

我们所有客户的核心都是 C + + 但这个核心是从拉斯马斯开始的 后得到浓缩，与功能分裂成模块 Spotify 可以在越来越多的平台上使用 为了获得更丰富的特性集，我们需要确保“核心”不会 成为“一点点的一切”。这意味着突破 某些功能，如回放控制，成为自己的独立 这些模块仍然是 C + + ，但是已经足够自包含了 他们的逻辑理论上可以在其他地方实现 我们将这些模块的接口层称为“ Cosmos”，并且 它的工作方式与 HTTP 没有太大的不同 客户端通信模块使用任意路径和 有效载荷，允许更灵活的架构 好处是版本化的接口(例如: GET sp://player/v1/main 返回播放器状态)和 JSON 来传递数据 对我们的桌面客户端的另一个变化很重要。

现在我们的很多桌面用户界面实际上都是使用 Chromium 嵌入式的 框架(CEF) ，这基本上意味着我们的视图由 JavaScript，HTML 和 CSS 不用担心打破别人的观点, 每个视图都在自己的“浏览器”中被沙箱保存(我想你可以这样想 除了我们在一个 这带来了一个限制: 共享数据 两种观点之间的差异变得更加复杂。这就是宇宙介入的原因 真正简化了 core (C + +)和 JavaScript 之间的通信 Land: JS 客户机可以发出任意的请求，如果有一个 该请求得到处理和响应 “ message”端点，它允许任何视图将 JSON 数据推送到任何 其他正在监听的视图(有点像 HTML5中的 window.postMessage, 除此之外，它还可以与 C + + 模块接口) 所有的播放按钮在客户端知道是否一个轨道正在播放或 或者它是否可以离线使用(另一个 Cosmos 模块) ，或者 你是否为你的音乐保留了一首歌。

我们的技术栈的另一个重要变化是我们移动了 一些逻辑进一步“回来”，到视图聚合服务 将在客户端中执行几乎所有逻辑，只使用 后端作为一个数据存储，我们现在在逻辑层中做更多的工作 在数据存储区和客户端之间，将端点公开得非常 类似于 Cosmos (事实上，您可以用完全相同的方式调用后端 你调用一个宇宙模块，所以在不同层之间移动不是一个麻烦)。 原因有两个: 第一，它让我们扩展到更多 平台更快，因为有更少的客户端逻辑实现 第二，它确实帮助我们保持客户行为的一致性 和最新的，因为客户更“愚蠢”。减轻任何 我们已经确保了可能由此导致的经济放缓 缓存所有数据的规则，以便客户端仍然保留数据 在本地，它只是不像它那样负责那么多的业务逻辑 曾经是。

小开

点击这里查看第一个答案: 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)。

为了与特定的后端服务通信，我们路由请求 通过美联社使用我们自己的运输工具“赫尔墨斯”。这是 基本上是一个 URL 方案，让 AP 知道在哪里发送 有效载荷被编码为 Protobuf。 Hermes 有一个很好的缓存 系统(我们称之为“ Mercury”)将结果存储到 IndexedDB 支持它的浏览器(我们在桌面上有相同的系统 客户端，而是在 C + + 中实现) ，以避免请求相同的 这对于获得重新请求的资源非常有用 很多，如艺术家，专辑和曲目。

对于 UI，我们已经编写了一个相当高级的应用程序框架 (称为“ Stitch”)允许开发每个视图 由不同的团队独立完成，而不必担心 打破任何东西。视图运行在沙箱，但可以 仍然依赖于共享库进行加载等常见操作 追踪元数据，等等，截至本文写作时，我们有约35个独特的视图(或 应用程序)。

视图通过所谓的“桥梁”获取数据并执行操作 (基本上是一个 API)使用 postMessage，所以我们不需要 重新初始化每个应用程序的所有公共代码 关于这一点，我之前提到的大约35个观点中的很多都可以 实际上也可以在桌面客户端内运行，而不需要修改 当然，他们将使用一个钩子进入 Chromium，而不是 postMessage 嵌入式框架，以及我们的 C + + 核心。

我们尽可能多地使用 HTML5技术，但是在某些方面 我觉得我们有一个非常酷的技术栈 我们的网络播放器。

小开

这个答案更新得更快，来自他们的工程博客: https://engineering.atspotify.com/2021/04/07/building-the-future-of-our-desktop-apps/

Spotify 桌面客户端是一个 Windows 和 Mac 本地应用程序，它使用 CEF (Chromium 嵌入式框架)来显示基于 Web 的用户界面。现在仍然是这样，但是对于以前的桌面版本，客户端中的每个“页面”都是作为一个独立的“应用程序”构建的，可以在它自己的 iframe 中运行。

然而，他们最近不得不更新他们的架构，因为他们想要集成与 React 和 桌面客户端构建的 网络播放器，这样一个团队可以为两个客户开发和发布特性。

最终的体系结构看起来像是一个平台 API 层，它向客户端公开了底层的 Spotify 生态系统，具有基于 React 的用户界面和通过 React Hooks 公开的平台 API。因此，新的 UI 可以在网络上运行，它可以在我们的桌面容器中运行，而且永远不会知道或关心数据是来自我们的 C + + 堆栈还是我们的网络基础设施。

架构图

小开

  • 问题追踪器:

    • 哨兵

  • 保安:

    • ReCAPTCHA

  • 杂项:

    • Spotify 网站
    • PWA
    • 亚马逊 S3

  • 标签管理器:

    • 谷歌标签管理器

  • JavaScript 库:

    • Core-js 3.24.0
    • 反应

  • PaaS:

    • 亚马逊网络服务
    • 反向代理

  • 特使:

    • 乖乖听话

  • 其他:

    • OneTrust
    • A/B 测试
    • 谷歌优化

提交答案