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

是否有人知道用于开发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用于传递数据有一些明显的好处。这对于我们的桌面客户端的另一项更改很重要。

如今，我们的许多桌面UI实际上都使用Chromium嵌入式框架（CEF），这基本上意味着我们的视图由JavaScript，HTML和CSS提供支持。为了使我们所有的功能团队都能够使用其功能而不必担心会破坏其他人的视图，每个视图都在自己的“浏览器”中进行沙箱处理（我想您可以将视图视为Chrome中的标签页，但我们会展示更多多于一次）。但是，这带来了一个限制：在视图之间共享数据变得更加困难。这就是Cosmos出现的地方，它确实简化了核心（C ++）与JavaScript领域之间的通信：JS客户端可以发出任意请求，并且如果存在绑定，则该请求将得到处理和响应。一个例子是“消息” 端点，该端点允许任何视图将JSON数据推送到正在侦听的任何其他视图（类似于HTML5中的window.postMessage，但该视图也可以与C ++模块接口）。这也是客户端中所有播放按钮如何知道曲目是否正在播放，是否可以脱机使用（另一个Cosmos模块）或是否已将歌曲保存到音乐中的方式。

技术堆栈的另一个重要变化是，我们已将某些逻辑进一步“退回”到视图聚合服务中。因此，我们以前几乎只在将后端用作数据存储区的情况下在客户端中执行几乎所有逻辑，现在我们在数据存储区和客户端之间的逻辑层中进行了更多工作，从而暴露了与Cosmos非常相似的端点（实际上，您可以使用与调用Cosmos模块完全相同的方式来调用后端，因此在各层之间移动并不麻烦。这样做的原因有两点：一是由于无需实施更多的客户端逻辑，它使我们能够更快地扩展到更多平台；二，由于客户端是兼容的，它确实帮助我们保持了客户行为的一致性和最新性。更“愚蠢”。

这是它们使用的第三方组件的列表（当然是C ++）：

• 促进
• 外籍人士
• 快速删除
• giflib
• 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嵌入式框架（CEF）在桌面应用程序中显示由HTML / CSS / JavaScript组成的Web界面。

从他们的网站：

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

鉴于它运行在Windows上，显然不是.NET（Process Explorer告诉我），它没有遵循AIR安装过程，我想说的是使用跨平台库的C ++。

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

向Techno致敬...我认为他们使用了Hardhouse Electronica

在此处检查第一个答案：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嵌入式框架和我们的C ++内核代替postMessage。

我们尝试尽可能多地使用HTML 5技术，但在某些情况下取决于Flash。我认为总体而言，我们为网络播放器提供了一个非常酷的技术堆栈。

前端用FLEX编写，在Mac或Windows计算机上签出源代码。您将看到很多以flex文件格式的xml文件。

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