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 正面臨著其歷史上最具挑戰性的時期。
新推出的 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
宣告：本文為 InfoQ 翻譯，未經許可禁止轉載。
今日好文推薦
本報告由 華為 & InfoQ 研究中心聯合釋出。《中國技術市場發展趨勢 2025 之開發者篇》全面分析了開發者生態的現狀及未來發展趨勢。透過多維度的資料調研與市場分析，聚焦開發者城市分佈、技能演變、行業流動、收入水平、學習生態及人工智慧應用等核心議題，為技術領域的從業者、企業和教育機構提供權威參考。