一次 App 更新失败，CEO 不得不辞职谢罪：技术重构导致用户纷纷将数千元高科技产品丢进垃圾堆

Sonos 应用程序更新失败，CEO 都下课了！

你没看错，就是那个做音响的Sonos。去年 5 月，他们推出了一款新 App，想通过这个新 App 来提升用户体验，结果却适得其反。

这款 App 几乎成了“Bug”集合，用户连最基本的功能都无法正常使用，比如访问或搜索音乐库、设置睡眠计时器，甚至连下载都成了问题。这不仅引发了用户的强烈不满，还拖累了其他产品的开发和发布进度。Sonos 公司还表示，修复这些问题预计将花费 2000 万至 3000 万美元。

因为这场“翻车事件”，Sonos 去年的股价一路下滑，公司还被迫裁员。首席执行官 Patrick Spence 在去年 10 月公开承认了这次失误，并表示他和其他 7 名公司高管将放弃奖金以示负责。而如今，CEO 顶不住压力，直接辞职，这一决定成了过去八个月里最戏剧性的进展。

让懂技术的人来掌舵

现在，拥有工程师背景的 Conrad 接过了这份重担，努力提振士气并希望能挽回消费者的信任。

Conrad 曾在 Pandora 担任 CTO 长达 10 年，也在 Snapchat 担任过 2 年的产品副总裁。他的履历还包括上世纪 90 年代参与开发苹果的 Finder 软件。最近，他担任了流媒体服务 Quibi（虽因失败而停运）的首席产品官。Sonos 公司表示，他很适合这个临时 CEO 的位置，因为他对公司当前的困境了如指掌，而且这段时间一直都在忙着修那个出问题的 App。

Spence 虽然被“请”走了，但“金饭碗”却没丢。他还能在 Sonos 混到今年 6 月底，每个月拿 7500 美元，为公司提供“战略咨询服务”。更爽的是，最后还能拿 187.5 万美元的“补偿”！这些数据都是 Sonos 自己公布的。

送走销售型 CEO，转而让有技术和产品背景的人来负责这款高科技产品，这个决策本身也让很多网友拍手称快，认为这才是公司应该做的选择。

“这位 CEO 和他领导的产品管理团队彻底毁掉了 Sonos 曾经积累的所有良好声誉，尤其是他们几乎完全不需要外部网络访问就能运行的独特优势。这种现象是对社会的控诉：这些人可以从一家公司跳到另一家公司，赚取数百万美元，而那些试图正确做事的人却不断遭到践踏。”

“我敢打赌，工程团队很可能曾强烈警告高管们可能会发生的后果，但却被无视了。尤其是有消息说：‘员工声称，Sonos 越来越看重吸引新客户和取悦投资者，而不是确保旧硬件能够与新应用程序正常兼容。’这听起来像是一个有意为之的选择。话虽如此，我怀疑 Sonos 的市场基本上已经消失了。”

“工程师在理解客户的需求和想法方面处于更有利的位置。销售人员的职责是销售他们的产品，根本上并不需要理解客户的需求或想法。给一个优秀的销售人员一份模糊的销售大纲，他们就能把产品卖出去。他们并不需要技术上的准确性才能取得成功。是的，这对客户不好，生活也因此变得更艰难，并且给 IT 人员、工程师以及其他需要应对每天业务中技术现实的人带来荒谬、适得其反且让人愤怒的情况......如果一个对所售产品有充分理解的工程师掌舵，他处于最有利的位置来控制销售和营销团队，并根据客户的实际需求来引导开发。这可能最终导致总体利润较低，但会有更好的产品和更好的长期声誉。”

Sonos 是怎么变“砖”的？

事实上，Sonos 正面临着其历史上最具挑战性的时期。

新推出的 App 问题频发，导致许多用户无法正常使用音响设备，甚至选择将这些昂贵的音箱丢弃。对此，有网友分享了他的一段亲身经历，颇具讽刺意味。

网友 schappim 在一次与家人散步时，在垃圾桶里看到了一台几乎全新的 Sonos 音箱。出于好奇，他将其捡回家，一查发现竟然是一台价值 500 美元的 Sonos Play:5 音箱。回到家后，插上电源，音箱顺利启动。接着，他尝试使用 iPhone 上的 Sonos 新应用程序进行配对，却始终无法连接。不甘心的他转而用一台备用的 Android 设备再试一次，结果奇迹发生了——音箱瞬间完成配对！更让人惊喜的是，一旦用 Android 设备完成设置，他竟然可以通过 iPhone 上的 Sonos 应用正常控制这台音箱。

对此，schappim 感慨道：“我只能猜测，这台音箱的原主人可能是个 iPhone 用户，因为搞不定 iOS 应用的 Bug，竟然直接把这么好的音箱丢进了垃圾桶！简直难以置信。”

夸张的是甚至还有 YouTuber 专门制作视频以讲解如何改造从垃圾堆里捡到的 Sonos 音响，让它不依赖云服务也能正常工作。有网友对此评论说：“Sonos 几乎是故意通过软件更新让许多设备变成砖块。很多 Sonos 用户是有消费能力的发烧友，但并不具备技术知识，因此直接选择放弃这些设备。”

要知道，Sonos 的音响，尤其是高端型号，价格还是挺让人“下不了手”的。

那么，Sonos 的应用究竟是如何重写的，又是哪些改动导致这些设备变成了“砖”呢？

实际上，自 Sonos 公司建立以来，其扬声器一直是 UPnP（通用即插即用）设备领域的黄金标准。Sonos 的旧应用依靠行业标准协议和开放接口设计，功能强大且兼容性好。Sonos 扬声器通过 UPnP（通用即插即用）技术和 SSDP 发现机制，与网络上的设备无缝连接。同时开放了大量 API，供应用与设备通信，比如查找设备、播放音乐等。

Sonos 的 SMAPI 接口更是大幅扩展了其音乐服务的支持能力，使设备兼容超过 100 种音乐服务。而云服务只是作为补充，Sonos 云 API 主要面向音乐服务集成商（如 Spotify Direct）和开发者，提供简单的音乐控制和集成功能，而不是直接支持完整的用户应用。

从旧到新：转型云端失败

Sonos 在新应用中放弃了旧有代码，完全采用了新的技术架构，对前端（用户体验部分）和后端（设备与音乐服务通信部分）进行了大规模重构。

当应用程序启动时，其必须先找到扬声器设备，才能再执行其他更多操作。但出于某种莫名其妙的原因，Sonos 决定放弃 SSDP 并完全依赖 mDNS 进行设备发现。因此大量用户报告称系统本来运行正常，但突然发现在应用中找不到任何设备对象。这表明 mDNS 在多数家庭网络上都不足以支撑起一套可靠的设备发现系统，或者说他们的代码当中存在某些巨大缺陷。

在前端方面，旧版 S1 应用程序使用了设备上的原生用户体验框架，并被移植到各个平台。因此除了 Windows 选择使用 WPF 之外，其他平台都使用当时最为“通行”用户体验框架。这样的设计虽然在所有平台上都带来了可靠的体验，但成本显然也随之提高：用户体验中的每项新功能都必须在四个不同的 UX 代码库中分别实现（后端是 C/C++，且在所有代码库之间共享）。

在新款应用这边，Sonos 决定在两大移动平台上使用相同的前端，因此统一采用了 JavaScript 框架，这就保证了 UX 代码只需要编写一次。（自从 S1 拆分以来，Windows/Mac 版应用程序的功能一直处于冻结状态，因此其 UX 也没有发生变化。）不太确定 UX 框架对于应用程序的性能有多大的影响，但后端不再继续使用 UPnP 明显才是对应用程序性能产生显著影响的最主要根源。

后端的重大变化是不再依赖 UPnP，取而代之的是加密网络流量和转向云端架构来支持完整的用户应用。

过去的事件处理是基于 UPnP（本质上就是在应用程序当中运行一个简单的 http 服务器，当事件发出时会从扬声器处获取调用），但现在却是基于 websocket。微软首席工程师 Andy Pennell 拥有十多年开发 Sonos 应用的经验，对 Sonos 系统有深入的技术理解。通过他的逆向分析，他发现了一些 Sonos 需要重新审视的重要问题。

加密导致的性能开销：由于现在所有流量都已经过加密，因此每次网络调用都需要消耗更多的 CPU 周期：客户端先对流量进行加密和发送（TLS 操作也更加繁琐），扬声器随后需要对数据流进行解密才能执行后续操作。加密开销对于老款 Sonos 设备无疑比较沉重，因为这些设备的内置 RAM 非常小（最低只有 64 MB，而最新款 Sonos 设备则高达 8 GB），双方的 CPU 性能也存在类似的巨大差异。此外，云 API 比 UPnP API 更加“话痨”，所以网络开销自然也会成倍增加。

音量管理体验问题：目前最能体现糟糕现状、也是最令用户诟病的就是设备音量管理体验，例如：在一组 8 台扬声器中，用户可以弹出设备音量面板，其中会显示所有 8 台设备的音量以及群组整体音量（群组音量为各台设备音量的加权平均值）。用户都喜欢把各个音量滑块设置在不同的位置，但在 Sonos 群组中，这会产生大量音量变化事件。具体来讲，更改群组音量会影响每台设备的具体音量，而每台设备则会发回一个事件来声明其新音量。

当用户快速拖动音量滑块时，事件会成倍增加，并且由于事件顺序无法保证，极易导致控制延迟和混乱（所以，千千万万不要更改音量 UX 代码）。尽管 Sonos 专门在https://docs.sonos.com/docs/volume上发布了关于如何处理这个问题的建议，但新应用似乎并未遵循这些建议，导致音量控制变得“神经质”。特别是从 UPnP 切换至 WebSocket 的事件处理方式后，情况进一步恶化。

音乐服务的变更及性能影响：性能下降的另一个原因，则跟如今的音乐服务运行方式有关：在旧款应用程序中，应用会直接向各种音乐服务（例如苹果音乐、Spotify 等）发出 SMAPI 调用以枚举条目并获取乐曲。新款应用改为调用 Sonos 云以完成这些操作，而后其云服务再发出 SMAPI 调用以获取乐曲数据，最后再将这些数据给应用端。哪怕只是乐曲音频，这也会产生比以往更多的网络流量，而且速度也要慢得多。

此外，这种架构还导致新应用不再支持自定义 SD 类型的音乐服务，因为这些服务无法通过云端访问，因此新款应用会直接将其忽略。而即使在云端缓存了大量数据，这样的新流程仍然会产生额外的路由开销，而且有些数据也无法被缓存在云端（例如任何个性化内容，包括苹果音乐上的播放列表）。去年，他们开始将移动应用中的搜索功能改为在云端完成，根据猜测这就是新款应用的试水之举。这不仅导致本地库搜索功能被破坏，而且问题至今仍未得到解决（在新架构下也不可能得到解决）。

说到本地库，好消息是本地 mp3 音乐文件的收藏插图仍然能从本地网络获取，完全不涉及云端，而这也是新款应用中少数未经变更的网络代码之一。请注意：虽然也有部分用户“丢失”了其本地库，但这应该只是配置问题，实际底层代码对于多数用户仍然有效。移动应用已经无法在 Sonos 系统中添加 NAS 驱动器，但桌面版应用程序仍可正常操作。

新款应用还缺失了不少旧应用所具备的关键功能，但过去的一段时间里已经有一些功能通过更新成功回归。比如说队列管理，这可是 Sonos 必须重视的一项关键功能（也直接决定着用户体验，毕竟这可是随时调整拥有上万首乐曲的歌单的唯一高效方式）。

与新应用一同发布的，还有一款 Web 版应用（可通过 play.sonos.com 访问），它允许用户在外出时通过浏览器窗口远程控制 Sonos 系统。这款 Web 版应用使用了改进后的 Sonos 云 API，更加讽刺的是，Web 版在识别扬声器方面的表现竟然比需要本地安装的移动版应用还要稳定。这是因为在 SSDP 支持下，扬声器能够在本地网络中互相识别位置，并将这些信息开放给 Sonos 云服务。

值得注意的是，Sonos 并未在用户账户上提供多因素验证功能，也没有提供撤销 Web 应用程序身份验证的机制。这意味着，用户无法有效管理第三方对账户权限的使用，这显然是一个不小的安全隐患。

Sonos 似乎并未真正认识到问题的严重性。官方甚至将新应用的发布形容为“勇敢的决定”。好吧，对于很多用户来说，这个“勇敢”更像是“胆大包天”。

而且，由于设备发现问题的影响，不仅是老用户们对于应用程序的使用体验感到沮丧，就连很多新用户在收到闪闪发亮的 Sonos 设备后也连不上应用端。这些怒气冲冲的用户通常不会再废话，直接把设备塞回包装盒并选择退货，当然，也有直接丢进垃圾桶的情况。

参考链接：

https://www.reuters.com/business/retail-consumer/sonos-ceo-patrick-spence-steps-down-after-app-update-debacle-2025-01-13/

https://news.ycombinator.com/item?id=42687932

https://www.linkedin.com/pulse/what-happened-sonos-app-technical-analysis-andy-pennell-wigwc/?trackingId=kSfNh0CXT2OTCTbZ%2FYpQrA%3D%3D