有人知道开发 Spotify 桌面应用程序使用了哪种语言或技术吗?它稳定、美观、轻巧。
9 回答
从这里:http
://www.quora.com/What-is-the-technology-behind-the-Spotify-desktop-app 日期:2014-09-09
在 Spotify 工作了 5 年的员工 Andreas Blixt:
我们所有客户的核心都是 C++,但是自从 Rasmus 的帖子被压缩后,这个核心已经被压缩了,功能被分成了模块。随着 Spotify 在越来越多的平台上可用以及获得更丰富的功能集,我们需要确保“核心”不会成为“一切的一点点”。这意味着将某些功能(例如播放控制)分解到它们自己的单独模块中。这些模块仍然是 C++,但足够独立,理论上它们的逻辑可以用其他语言实现。我们将这些模块的接口层称为“Cosmos”,它的工作方式与 HTTP 并没有太大的不同。Cosmos 允许客户端的任何部分使用任意路径和有效负载与模块进行通信,从而实现更灵活的架构。一些明显的好处是版本化接口(例如:GET sp://player/v1/main 返回播放器状态)和用于传递数据的 JSON。这对于我们桌面客户端的另一个变化很重要。
如今,我们的很多桌面 UI 实际上都在使用 Chromium Embedded Framework (CEF),这基本上意味着我们的视图由 JavaScript、HTML 和 CSS 提供支持。为了让我们所有的功能团队能够处理他们的功能而不必担心破坏其他人的视图,每个视图都在他们自己的“浏览器”中进行沙盒处理(我想您可以将视图视为 Chrome 中的选项卡,除了我们展示更多一次不止一个)。但是,这带来了一个限制:在视图之间共享数据变得更加困难。这就是 Cosmos 的用武之地,它真正简化了核心 (C++) 和 JavaScript 领域之间的通信:JS 客户端可以发出任意请求,如果存在绑定,则该请求得到处理和响应。一个例子是“消息” 端点,它允许任何视图将 JSON 数据推送到正在监听的任何其他视图(有点像 HTML5 中的 window.postMessage,除了这个也可以与 C++ 模块交互)。这也是客户端中的所有播放按钮如何知道一首曲目是否正在播放,或者它是否可以离线使用(另一个 Cosmos 模块),或者你是否已经将一首歌曲保存到你的音乐中。
我们技术堆栈的另一个重要变化是我们将一些逻辑进一步“向后”移动到视图聚合服务中。因此,我们以前会在客户端中执行几乎所有逻辑,仅使用后端作为数据存储,现在我们在数据存储和客户端之间的逻辑层中做更多的工作,暴露与 Cosmos 非常相似的端点(实际上,您可以像调用 Cosmos 模块一样调用后端,因此在层之间移动并不麻烦)。这样做的原因有两个:第一,它让我们更快地扩展到更多平台,因为要实现的客户端逻辑更少;第二,它确实帮助我们保持客户端行为更加一致和最新,因为客户端是更“愚蠢”。
以下是他们使用的第三方组件列表(当然是在 C++ 之上):
- 促进
- 外籍人士
- 快速委托
- gif库
- libjpeg
- 利博格
- libvorbis
- 梅森捻线机
- zlib
- NSIS(仅限 Windows)
- Windows 模板库(仅限 Windows)
- 咆哮(仅限 Max OS X)
- MATrackingArea(仅限 Mac OS X)
根据 Spotify 设计师的说法:
http://twitter.com/#!/tobiasahlin/status/96483609799692288
“其中一些是用 C++ 编写的,还有一些是用一种叫做 Spider 的 HTML 风格的标记语言编写的”
Spotify 现在使用Chromium Embedded Framework (CEF) 在桌面应用程序中显示由 HTML/CSS/JavaScript 组成的 Web 界面。
从他们的网站:
Spotify 主要使用 Python 和 C++ 构建
鉴于它在 Windows 上运行,显然不是 .NET(进程资源管理器告诉我),没有遵循 AIR 安装过程,我会说 C++ 使用跨平台库。
一切都被编译成一个可执行文件,这表明他们可以访问所有依赖项的源。
Wrt 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 中运行。
然而,他们最近不得不更新他们的架构,因为他们想以一种单一团队可以为这两个客户端开发和交付功能的方式集成使用 React 和桌面客户端构建的Web 播放器。
最终的架构看起来像一层平台 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。Hermes 有一个很好的缓存系统(我们称之为“Mercury”),它将结果存储到支持它的浏览器的 IndexedDB 中(我们在桌面客户端有相同的系统,但用 C++ 实现),以避免两次请求相同的数据。这对于经常被重新请求的资源非常有用,例如艺术家、专辑和曲目。
对于 UI,我们编写了一个非常高级的应用程序框架(称为“Stitch”),允许不同团队独立开发每个视图,而不必担心会破坏任何东西。这些视图在沙盒中运行,但仍然可以依赖共享库来处理常见的事情,例如加载轨道元数据等。在撰写本文时,我们在网络播放器中有大约 35 个独特的视图(或应用程序)。
视图通过使用 postMessage 的“桥”(基本上是 API)获取数据并执行操作,因此我们不需要重新初始化每个应用程序的所有公共代码。真正很酷的一点是,我之前提到的大约 35 个视图实际上也可以在桌面客户端中运行而无需修改。当然,他们将使用挂钩到 Chromium Embedded Framework 和我们的 C++ 核心,而不是 postMessage。
我们尝试尽可能多地使用 HTML 5 技术,但在某些情况下依赖于 Flash。我认为我们的网络播放器总体上有一个非常酷的技术堆栈。
前端是用 FLEX 编写的,在你的 mac 或 windows 机器上查看源代码。你会看到很多 flex 文件格式的 xml 文件。
当然,与服务器和平台集成的连接可能是用 C++ 原生编写的。但 UI 部分只是 FLEX ......