。去年 5 月，他们推出了一款新 App，想通过这个新 App 来提升用户体验，结果却适得其反。这款 App 几乎成了“Bug”集合，用户连最基本的功能都无法正常使用，比如访问或搜索音乐库、设置睡眠计时器，甚至连下载都成了问题。这不仅引发了用户的强烈不满，还拖累了其他产品的开发和发布进度。Sonos 公司还表示，修复这些问题预计将花费 2000 万至 3000 万美元。

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

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

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

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

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

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

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

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

　　在新款应用这边，Sonos 决定在两大移动平台上使用相同的前端，因此统一采用了 JavaScript 框架，这就保证了 UX 代码只需要编写一次。（自从 S1 拆分以来，Windows/Mac 版应用程序的功能一直处于冻结状态，因此其 UX 也没有发生变化。）不太确定 UX 框架对于应用程序的性能有多大的影响，但后端不再继续使用 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 专门在 上发布了关于如何处理这个问题的建议，但新应用似乎并未遵循这些建议，导致音量控制变得“神经质”。特别是从 UPnP 切换至 WebSocket 的事件处理方式后，情况进一步恶化。

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

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

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

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

　　在 AI 大模型技术如汹涌浪潮席卷软件开发领域的当下，变革与机遇交织，挑战与突破共生。2025 年 4 月 10 - 12 日，QCon 全球软件开发大会将在北京召开，以 “智能融合，引领未来” 为年度主题，汇聚各领域的技术先行者以及创新实践者，为行业发展拨云见日。现在报名可以享受 8 折优惠，单张门票立省 1360 元，详情可联系票务经理 咨询。