Cerulean 是一款輕量工具合集——它為什麼這麼小？

Cerulean 是一款輕量工具合集——它為什麼這麼小？

Cerulean下載（中文別名「一個木函」）是 Android 平台上一款擁有上百個實用小工具的應用——從 B 站影片解析、垃圾分類查詢、隨機決策到 OCR 文字辨識、圖片壓縮、PDF 轉換，日常中那些「偶爾需要但懶得裝專用 App」的零碎場景，它一個全兜住。

但真正讓我好奇的不是功能列表有多長，而是它的安裝包只有 37.99MB。對比之下，任何一個「單功能 App」——比如專門的 B 站解析器、專門的垃圾分類查詢、專門的 PDF 轉換器——動輒就是 20~50MB。把上百個這種工具塞進同一個應用，體積反而沒有翻倍，甚至比不少單功能 App 還小。這怎麼做到的？

安裝

Cerulean官網 是純 Android APK，安裝過程跟大多數第三方應用一樣：下載 APK 檔案後允許「未知來源安裝」即可。版本更新走應用商店（Google Play 或國內第三方商店），新版本會覆蓋安裝，收藏的工具和自訂設定都會保留。

首次啟動時不需要註冊登入，也不會強制要求任何敏感權限——它的策略是「用到哪個工具才申請哪個權限」，比如 OCR 用到相機權限、圖片壓縮用到儲存權限，沒用到的一律不碰。這點在 Android 隱私規範越來越嚴的環境下，體驗上比那種一上來就要十幾項權限的應用舒服很多。

如果從舊版本升級安裝，建議不要先卸載舊版再裝新版——直接覆蓋安裝能保留收藏清單和自訂工具設定，卸載重裝會清空這些資料。

問題导向：工具合集的核心矛盾

在拆解 Cerulean 的架構之前，先想清楚一個問題：工具合集要解的核心矛盾是什麼？

單功能 App 的問題很直觀——手機裡裝 10 個就開始顯雜、裝 30 個就翻半天找不到、每個都要佔儲存空間和記憶體。但把上百個功能塞進一個 App，會遇到另一組問題：

1. 安裝包體積爆炸：每個工具如果獨立帶資源檔（圖示、UI 佈局、字串資源），累積下來很容易破百 MB
2. 啟動速度變慢：每多一個功能，啟動時的類載入、資源初始化就多一份開銷
3. 記憶體佔用膨脹：即便大部分工具你從來不開，它們的程式碼和資源仍常駐在記憶體裡

Cerulean 把這三個問題解決得相當乾淨。我把它的設計拆開來說。

拆解一：模組化解耦，按需載入

Cerulean 的上百個工具不是寫在同一個程式碼庫裡的。它採用的是一種類似「外掛系統」的架構設計——每個工具是一個獨立的模組，核心應用只負責工具的註冊、發現和路由。

具體來說：

• 核心殼（Core Shell）：只做三件事——啟動應用、顯示工具清單、根據點擊跳轉到對應工具。這部分程式碼體積很小，啟動速度基本不受工具數量影響。
• 工具模組（Tool Modules）：每個工具作為獨立的模組存在，它只在被用戶實際打開時才載入記憶體——你從來不碰的那 80 個工具，它們的程式碼和資源在安裝包裡是靜態壓縮狀態，永遠不會佔用執行時記憶體。
• 共用資源池：圖示、字串、通用 UI 元件這些在多個工具中重複出現的資源，抽成獨立資源池，所有工具共享一份——這是安裝包體積保持緊湊的關鍵之一。

打個生活化的類比：Cerulean 就像一個自助餐廳——你進去看到的是菜單（工具清單），你點哪道菜，廚房才開始做（載入模組）。沒點的菜不會預先炒好堆在自助餐台邊佔地方。對比之下，那些單功能 App 就像每道菜都開一個獨立餐廳，你要吃 10 道菜就得跑 10 家店，每家店的廚房還要常駐等你光臨。

拆解二：功能聚合 vs 功能隔離的取捨

Cerulean 並不是什麼效率工具都往裡面塞。觀察它的工具清單會發現一個規律：所有工具都是「純前端工具」——它們只操作設備本地資源（相機、儲存、感應器、瀏覽器 WebView），或只做輕量 API 請求，沒有任何一個需要長時間後台執行、本地資料庫、或複雜的線上同步。

這個選擇非常刻意：

取捨	聚合的好處	聚合的代價
啟動速度	核心殼極小，冷啟動快	工具首次載入有 100~200ms 延遲
記憶體	閒置時只佔核心殼的記憶體	同時開多個工具時記憶體會疊加
安裝包	共享資源池減少重複	需要額外的模組路由邏輯
更新頻率	一次更新覆蓋全部工具	某個小工具的 bug 也得等整包更新

Cerulean 在這張表上的選擇很明確：它優先犧牲「首次載入速度」來換取「閒置時輕量」。對日常使用場景來說，這個取捨是對的——你不會 1 秒內連開 10 個工具，但你的手機裡會常駐這個應用。冷啟動快 + 閒置輕量，就是它比單功能 App 更討喜的原因。

拆解三：資料與狀態處理的隱性設計

還有一個很容易被忽略的設計：Cerulean 的工具之間幾乎沒有資料依賴。

• 垃圾分類查詢工具的資料庫（全國城市分類規則）是一次性打包進 APK 的靜態資料，不需要網路請求
• B 站影片解析工具走的是外部 API，解析結果用完即棄，不寫本地資料庫
• 做個決定（隨機工具）的選項清單存在 SharedPreferences 裡，跟其他工具完全隔離

這種「無狀態」設計帶來兩個好處：一是模組可以完全獨立開發和維護，二是某個工具出 bug 不會連帶影響其他工具。代價是——它沒有雲同步——收藏的工具列表、自訂的隨機選項，換手機就得手動搬一次。對大多數用戶來說這不是大問題，但對重度依賴雲端備份的人可能是個減分项。

判斷：這套原理意味著什麼

總結一下 Cerulean 的設計哲學：用戶不會因為「需要一個功能」而裝一個 App，但會因為「一個 App 能覆蓋 80% 的零碎需求」而保留它。

它適合的場景：

• 日常零碎工具和自動化小需求偶爾用一下，但不想裝一堆單功能 App
• 注重手機儲存空間和記憶體佔用
• 喜歡「一個應用解決大部分小麻煩」的簡潔感

它可能不適合的場景：

• 需要重度使用某個功能（比如每天用 OCR 掃描幾十頁文檔），此時專業 App 的體驗和精度會更好
• 需要雲同步和多設備協同
• 對離線功能有強烈需求（部分工具依賴外部 API，對方介面變動可能導致功能失效）

最後說一個我自己的觀察：工具合集這種產品形態的核心生命力，不在於它功能有多齊全，而在於它能不能保持輕量。每多一個功能，如果就得讓應用重 5MB、啟動慢 100ms、記憶體多佔 30MB，那終究會淪為另一個肥大的系統應用。Cerulean 的模組化解耦 + 按需載入 + 共享資源池這三板斧，目前把這個平衡拿捏得不錯——37MB 裝上百個工具，閒置時記憶體佔用只有幾十 MB，冷啟動不卡頓。這是它真正厲害的地方。

本文為個人基於網路公開資料整理編寫，非官方內容，僅供學習交流參考；軟體版權歸原作者所有，請支持正版；使用過程中遇到問題請查閱官方管道，本文不承擔任何責任。