Bilby 為什麼能做到 7.45M 還好用——解開一個極簡客戶端的技術取捨

Bilby 是什麼——一個只服務訂閱黨的純粹派

如果你把 B 站官方客戶端比作一個百貨商場，那 Bilby 就是街角那間只賣你固定訂閱清單的雜貨鋪。它是一款開源的第三方 B 站 Android 客戶端，安裝包只有 7.45M——對比官方客戶端動輒幾十上百兆的體積，這個數字本身就足以引發好奇心。

Bilby 的產品邏輯從一開始就很明確：只解決追更這一件事。直播、商城、創作中心、番劇、會員購、消息推送……整個砍掉。留下來的只有四件事：看訂閱動態、看影片、發彈幕、聽音訊。對垂直類粉絲來說，這意味著打開 App 就是滿滿的想看內容，永遠不會被推薦演算法塞來的「可能感興趣」打擾。

安裝

安裝從 Bilby下載 拿到的 APK 基本上就是一次標準的側載流程，但有幾個點值得單獨注意。因為它是第三方客戶端，不經過應用商店分發，所以你需要先在手機上允許「未知來源」安裝——這個選項通常在系統設定的隱私或安全分區裡。

下載完 APK 點安裝就好，整個過程不到一分鐘。安裝完成後打開 App，第一件事是掃碼登錄 B 站賬號——這裡不要驚訝，Bilby 不維護自己的賬號體系，所有數據（關注列表、稍後再看、彈幕發送權限）都走 B 站官方 API，所以登錄是繞不開的一步。好消息是，因為開源可審計，它不會存你的密碼，只拿掃碼後的 token。

登錄完成後進訂閱頁就能看到所有關註 UP 主的最新動態了。沒有引導向導，沒有首頁推薦，打開就是乾淨的時間線——這也是它和官方客戶端體驗差異最大的地方。

7.45M 裡到底裝了什麼——從代碼結構看極簡主義

現在進入真正有意思的部分：為什麼一個 B 站客戶端可以做到這麼小？我翻了它的開源代碼結構，答案比想像中更直觀——不是壓縮技術有多先進，而是它真的沒寫那些東西。

問題：功能模組的邊界在哪裡

先給你一個直觀的對比。官方客戶端的 APK 裡，光「直播」一個模組就可能包含：直播流播放器、禮物動畫系統、彈幕系統（和影片彈幕是兩套代碼）、粉團面板、直播推薦演算法……這個模組本身可能就好幾兆。而 Bilby 的代碼裡，連直播相關的類都沒有——不是寫了個空殼，是整個 import 路徑都不存在。

它採用的是一種叫做「硬邊界模組化」的架構思路：每個功能域的代碼完全自包含，不存在跨域調用。砍掉一個模組，就是把那個文件夾整個刪掉，編譯器自動不會把它打進最終 APK。這種架構在常規應用裡少見，因為多數應用的功能模組之間是互相牽扯的——但 Bilby 反其道而行之，從設計之初就保證了模組之間零耦合。

拆解：數據流的極簡設計

打開一個訂閱動態卡片到進入播放頁，這個過程在 Bilby 裡的數據流是這樣的：

1. 啟動時調 B 站官方 API 拉關注列表（一次請求，拿到所有關註 UP 主的 mid）
2. 並行拉取每個 UP 主的最新 10 條動態（用 B 站公開的動態接口，不需要特殊權限）
3. 本地做時間排序，渲染成卡片列表
4. 點擊卡片 → 傳 video_id 給播放器組件 → 播放器組件再調官方播放地址接口拿真實流地址

整個過程沒有任何本地緩存層（除了系統級的 HTTP 緩存），沒有任何數據庫，沒有任何異步預加載策略。用戶操作什麼就請求什麼，純粹到了一種極致。

這種設計的代價是什麼？啟動速度取決於網絡，弱網環境下體驗會差。但收益是——你不需要一個 Room 數據庫佔空間，不需要一套複雜的緩存淘汰邏輯，不需要處理「本地數據和服務端數據不一致」這種經典問題。代碼量直接砍掉一個數量級。

取捨：哪些東西它選擇不做

我整理了一下 Bilby 明確不做、且短期內也沒有計劃做的功能清單：

• 不做推薦演算法：發現新內容只能靠搜索和關注，沒有「猜你喜歡」
• 不做畫中畫：後台聽音訊可以，但浮窗播放不支持
• 不做下載緩存：純流媒體，影片不會存本地
• 不做番劇分區：沒有專門的追番板塊，追番 只能通過關注 UP 主
• 不做消息推送：沒有任何推送機制，你打開才知道有沒有更新

這份清單裡每一條，在官方客戶端裡都可能是一個好幾人團隊的工作量。而 Bilby 選擇了放棄——用項目維護者自己的話說：「我們不想做一個 B 站複製品，我們想做一個 B 站的閱讀器」。

判斷：這套架構適合誰

說一個自己造的類比：如果把 B 站比作一座城市，官方客戶端就是城市的地鐵系統——線路全、覆蓋廣、哪都能到，但高峰期擠、線路複雜、偶爾還要繞路。Bilby 就是你自己買的一輛自行車——只能去你常去的那幾條街，但永遠不會堵，上車就走，停車方便。

這套架構最適合的人群是：已經有明確關註列表、只追固定幾個 UP 主、討厭演算法推薦的重度使用者。如果你是那種每天打開 B 站就不知道看什麼、靠推薦打發時間的人——Bilby 會讓你覺得「什麼都沒有」。但如果你早就被推薦演算法推煩了、只想安靜看完訂閱列表——它會讓你覺得「終於有人懂我要什麼了」。

7.45M 不是一個炫技的數字，它是一個產品定位的直接結果：你砍掉的每一個功能，都會讓你的目標用戶更清晰，也讓你的代碼更乾淨。Bilby 的架構哲學說穿了就是一句話——知道自己不做什麼，比知道自己要做什麼更重要。

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