十年技術債，一刀清：小米澎湃OS 4 到底要做什么！

小米的系統這些年有一個很矛盾的口碑——更新頻率高，功能堆得多，但Bug修不完，偶發卡頓像慢性病一樣總也斷不了根。每次新版發布，評論區永遠有兩派：一派說"又流暢了"，另一派說"又翻車了"。

問題不在某一次更新做得好不好，而在于地基本身已經老了。

從 MIUI 1 到澎湃OS 3，小米的系統代碼層層堆疊了十三年。早期用 Java 寫的模塊、后來用 Kotlin 重構的模塊、不同時期不同團隊留下的兼容層、調用鏈、SDK 依賴——這些東西混在一起，就像一棟老樓里從地下室到天臺塞滿了歷任住客留下的雜物。表面刷再多遍漆，樓板承重的問題始終在那里。日常使用中那些偶發的掉幀、后臺被殺、內存泄漏，歸根結底都不是表面問題，而是底層架構老化帶來的連鎖反應。

今年八月，小米準備做一件很激進的事：把這十三年的舊賬一次性清掉。

澎湃OS 4 將成為小米歷史上第一個"零遺留"系統版本。所謂零遺留，是指徹底移除從 MIUI 時代延續至今的全部舊 SDK、冗余代碼和歷史兼容層。這不是改幾個接口、刪幾個廢棄函數的小手術，而是從架構層面把承重墻砸掉重砌。

具體怎么做？核心系統應用全部用 Flutter 和 Rust 重寫。

這兩種技術的選擇很有講究。Rust 是一門以"內存安全"著稱的編程語言，傳統的 C/C++ 架構下，內存管理一旦出錯就容易引發崩潰和不可預測的卡頓，Rust 從語言層面就杜絕了這類問題。Flutter 則是谷歌推出的跨平臺 UI 框架，它不經過系統原生控件的轉譯，而是直接調用底層圖形引擎進行渲染，界面的一致性和流暢度都會比傳統方案更高。

小米已經在 HyperOS 3.1 上開始試點了。天氣、相冊等系統核心應用已經換成基于新 HyperOS SDK 的版本，部分應用版本號里出現了"R"標識，說明 Rust 重寫已經進入實際部署階段。用開發者的工具去查看這些新版應用的內部結構，會發現一個很明顯的變化——連傳統安卓應用標配的 dex 目錄都消失了，取而代之的是純原生動態庫。這意味著它們已經不再是傳統意義上的安卓應用，而是跳過了 Java/Kotlin 虛擬機層的原生程序。

代價也很直白：這些新版系統應用無法在舊版系統上運行。以后想從新機里提取一個 APK 裝到老手機上——架構都不兼容了，裝不上。小米在用兼容性換穩定性和效率，這一刀切得很果斷，也很決絕。

安卓 17 本身也在配合這次變革。谷歌計劃在今年的安卓 17 中部署名為 DeliQueue 的新系統架構，用并行操作機制取代舊版 MessageQueue 的單線程鎖定排隊模式。過去安卓系統處理后臺任務時，所有線程必須嚴格按順序排隊訪問內存，前面一個重負載任務卡住，后面所有輕量指令只能原地等待。DeliQueue 允許系統根據實時資源情況動態調度不同任務并行處理，測試數據顯示普通應用的丟幀現象減少了約 4%，系統桌面和啟動器的滑動漏幀率更是降了 7.7%。安卓 17 拓寬了底層數據通道，澎湃OS 4 則在這條更寬的通道上跑一套全新的引擎——兩層優化疊加，理論上的流暢度提升是可以預期的。

但底層重構只是澎湃OS 4 的一半故事。另一半是 AI。

這次小米做 AI 的方式跟之前完全不同。不是在桌面上放一個語音助手入口，也不是在相機里加幾個修圖濾鏡，而是把自研 AI 模型直接嵌入系統的調度層。資源分配、內存管理、任務優先級、后臺?；畈呗浴@些過去靠固定規則處理的事情，現在交給 AI 來做動態決策。它不需要用戶喚醒，也不會跳出一個對話框問你"需要幫忙嗎"，而是作為一個隱形的系統管家，持續在后臺優化每一個運行環節。

雷軍在去年的技術大獎頒獎典禮上透露過一個目標：2026 年要在一款終端設備上首次實現自研芯片玄戒、自研操作系統和自研 AI 大模型 MiMo 三者的深度融合與協同運行。澎湃OS 4 就是這個"三件套閉環"的操作系統環節。如果底層不干凈、架構不統一，后續的 AI 能力接入、多終端協同、車機系統聯動全都會被拖住。從這個角度看，清除 MIUI 遺留代碼不僅僅是為了讓手機更流暢，更是為了給整個小米生態的技術底座掃清障礙。

而 Flutter 和 Rust 的引入，可能還隱藏著一個更長遠的布局。

技術圈有一種推測：小米用 Flutter 重寫核心應用，是在為未來脫離安卓做準備。Flutter 天然跨平臺，如果有一天小米推出完全自研的操作系統——不再基于安卓內核——那么 Flutter 上的應用層幾乎可以無縫遷移過去，只需要適配底層的嵌入層和圖形接口就行。華為當年從安卓過渡到鴻蒙，走的就是類似的路徑，先用跨平臺框架做 UI 層的抽象和兼容，再逐步替換底層。

另一種推測更務實：小米現在的產品線已經覆蓋手機、平板、汽車、穿戴設備甚至 AR 眼鏡，用 Flutter 做統一渲染框架，可以讓核心系統應用在不同終端上保持一致的體驗，不需要每個平臺單獨開發一套 UI。玄戒芯片后續也要布局手機、平板、車機和穿戴全生態，統一的應用框架會讓芯片和系統的協同成本大幅降低。

不管哪種推測更接近現實，都指向同一個結論——澎湃OS 4 的底層重寫不是為了解決今天的問題，而是為了讓小米在未來五到十年的系統演進中不被歷史包袱拖住。

UI 層面也有值得關注的變化。徠卡色彩體系從相機擴展到了整個系統界面，圖標配色、控件風格、甚至通知欄和控制中心的色調都會統一到徠卡的視覺語言下。新增的徠卡調色盤功能允許用戶像調顏料一樣自由調整對比度、飽和度和影調傾向，還可以保存自定義預設。鎖屏界面也在重新設計，方向是更沉浸、更個性化。UI 的多窗口優化和自適應機制則讓不同尺寸的屏幕——從小屏 Redmi 到折疊屏 Mix Fold——都能獲得合理的布局和交互。這些變化不算驚天動地，但它們跟底層重構一起，讓整個系統從里到外第一次有了"統一感"。

適配方面，首批機型包括小米 14/15/18 系列、Redmi K70/K80 系列以及 Mix Fold 4 等旗艦和折疊屏，八月內測推送。第二批大約在今年第四季度覆蓋更多中端機型。小米 12S、13 等老旗艦據傳仍在名單里，但功能可能有刪減。同時有 16 款老機型確認無緣升級，主要是 2020 年前后發布的產品，硬件性能和產品生命周期決定了它們止步于此。

另外還有一個命名上的有趣傳聞：小米可能不再沿用數字序號，而是直接對齊年份，把新系統叫"澎湃OS 26"。如果屬實，這不僅僅是一次命名風格的變化，而是在心理上宣告跟 MIUI 時代徹底切割——不再是"MIUI 的第幾個后續版本"，而是一個全新操作系統的紀年元年。

有意思的是，爆料人提到了一個不太直覺的判斷：旗艦機在澎湃OS 4 上的感知提升可能不算巨大，反而是入門級和中端設備會成為最大的受益者。原因很簡單——被清除的那些冗余代碼和技術債務，在性能富裕的旗艦機上被硬件算力掩蓋了，你感覺不到它們在拖后腿；但在內存緊張、處理器不夠強的中低端設備上，同樣的冗余會直接導致可感知的卡頓和發熱。底層清理對這些設備的體驗改善，可能比堆硬件更有效。

風險當然是存在的。涉及語言級別的底層推倒重來，在初期版本中幾乎必然伴隨兼容性陣痛。內測階段報錯閃退不可避免，第三方應用如果跟不上新框架的節奏，用戶體驗也會打折扣。小米過去系統更新的穩定性一直有爭議，這一代如果八月內測之后 Bug 滿天飛，再好的架構愿景也很難讓用戶買賬。

但從另一個角度看，如果一套系統長期停留在修修補補的狀態，遲早會被自身的復雜度反噬。十三年的代碼堆積不可能靠每次更新修幾個 Bug 來解決，總有一天必須連根拔起。小米選擇在 2026 年動這刀——自研芯片已經量產、AI 大模型已經就緒、安卓 17 本身也在做底層革新——時機上確實已經是最合適的窗口。

澎湃OS 4 不是一次讓人興奮的功能升級，而是一次讓人緊張的手術。手術成功了，小米的系統會第一次真正擺脫 MIUI 的影子，成為一個獨立的、干凈的、能承載未來十年生態擴展的技術底座。手術失敗了，兼容性的陣痛會讓用戶對小米系統的信心再受一次打擊。

但不管結果如何，這一刀遲早要切下去。與其再縫補十年，不如現在就把舊賬清了。