obtainium 更新追蹤深度解析：一個把分散源頭匯成單一清單的 Android 工具
obtainium 是什麼
obtainium 是一款專門給 Android 開源應用做更新追蹤的工具——它不屬於任何官方商店，而是自己去各個發布源頭把版本訊息抓下來，集中在一個清單裡告訴你哪些應用有更新、幫你下載甚至安裝。
這聽起來像是「下載器」，但定位上它做的事情比下載多得多。市面上有 F-Droid、有 APKMirror、有 GitHub Release、有國內應用商店，每個源頭的版本號格式不一、發布頻率不一、有些還要簽名校驗——obtainium 的核心就是把這些分散的源頭轉成同一套內部數據結構，然後用統一的規則來判斷「哪個是更新」。如果你手機裡裝了五個以上不進 Google Play 的開源應用，obtainium 基本就是必需品。
安裝
obtainium 沒有上架任何官方商店，所以安裝方式就是 obtainium下載 APK 手動安裝——安裝包約 22MB，對應 Android 8.0 以上系統。首次安裝時 Android 會彈出「未知來源」警告，允許當前瀏覽器安裝即可，不用開全局權限。
裝完之後的第一件事，反而是把 obtainium 自己加進追蹤清單。原因很直接：它發版頻率高，beta 預發布也常推，靠手動重裝很容易漏掉修復。做法很簡單，切到「新增應用」標籤頁，貼上它的 GitHub Release 倉庫地址，源會自動識別為 GitHub，確認架構篩選選項後點新增。這個動作同時也是在驗證你的後台更新和安裝流程有沒有設對——之後 obtainium 的更新會跟其他應用一樣走同一條管線。
一個問題：為什麼它能比對出版本？
我第一次用 obtainium 時最困惑的不是界面，而是它怎麼解決版本比對的問題。
聽起來很簡單：抓兩個版本號字符串，比一下大小。但現實是，不同開源項目的版本號風格差異巨大——有的用語義化版本 v1.2.3，有的用 git commit hash，有的用發布時間戳，有的甚至沒有明確版本號只有「latest」標籤。GitHub Release 的 tag 可能是 v1.1.20-beta.1，F-Droid 的元數據裡寫的是 1.1.20，APKMirror 的文件名裡藏著另一串數字——obtainium 必須從這些雜亂的輸入中抽出可比對的版本。
它的解法是把版本字符串拆成 token 數組，然後逐段對齊比對。具體來說，先用正則把字符串按 .、-、_、字母數字邊界切開，每個 token 如果能解析成整數就按數值比，不能解析就按字符串比。1.1.20 和 1.1.19 的差異在第三個 token，1.1.20-beta.1 和 1.1.20 的差異在第四段（beta.1 < 空）——這樣就能處理大多數情況。但如果兩個版本號格式完全不同，比如一個是 2026-09-15 時間戳、另一個是 v1.2.3，比對結果就會退化成字符串字典序，此時 obtainium 會彈出警告讓用戶確認，而不是默默判斷錯。
拆解：從源頭到安裝包的完整管線
obtainium 的架構可以分成四層，每一層都有明確的責任邊界。
第一層：源識別與配置解析。 用戶貼一個 URL 進去，obtainium 先判斷這是什麼源——GitHub Release、GitLab、F-Droid、HTML 頁面、國內商店、下載直鏈，每種源有自己的解析器。GitHub 源會調 Release API 抓 asset 列表，然後按架構（arm64-v8a、armeabi-v7a）和版本過濾；HTML 兜底源最靈活，需要用戶自己填 XPath 告訴它哪裡是版本號、哪裡是下載鏈。這一層的輸出是一個標準化的 App 對象，裡面有當前版本、遠程最新版本、可用資產列表。
第二層：版本比對。 就是剛才說的 token 化比對器。這一層只關心版本號，不關心下載。輸出是一個枚舉：UP_TO_DATE、NEW_AVAILABLE、UNKNOWN。UNKNOWN 代表版本號解析失敗或格式不兼容，obtainium 此時不會自動更新，而是在界面上標記為「請確認」。
第三層：後台調度。 這是 obtainium 最有意思的取捨點——它提供兩種後台檢查機制，讓用戶自己選。預設用 WorkManager，這是 Android 官方的後台任務調度器，省電、系統友好，但會被廠商的電池優化推遲，尤其是激進省電的國產 ROM，檢查間隔會被順延好幾小時。另一種是前台服務，以常駐通知的形式持續運行，更可靠、不被電池策略掐掉，代價是通知欄常駐和少量耗電。obtainium 在文檔裡坦白承認這兩者沒有完美解，給的建議是：原生類 ROM 用預設、更新提醒總遲到的換前台服務、對通知欄敏感的接受偶發延遲。這種把取捨直接交給用戶而不是硬選一個預設的姿態，在工具類軟體裡很少見。
第四層：下載與安裝。 下載支援並行，多個應用同時拉下來總耗時更短。安裝分三檔：普通情況走系統安裝器（需要用戶點確認一次）；配 Shizuku 可以靜默安裝但需要一點 adb 設置；Root 安裝器最乾淨但需要 root 權限。obtainium 在這裡沒有強制要求任何一檔，而是讓安裝能力跟著用戶設備條件走——更詳細的安裝說明可以參考 obtainium官網。
取捨：這套設計的代價
obtainium 的架構很乾淨，但不是沒有代價。
最明顯的是 GitHub API 限額。未認證請求每小時 60 次，obtainium 追蹤十幾個應用很快就會用光。解法是讓用戶自己建一個 read-only 的個人訪問令牌填進去，限額升到每小時 5000 次。這是典型的開源專案姿態——把麻煩轉給用戶，但也給了用戶完整控制權。
第二個代價是簽名衝突。obtainium 只能下載和安裝 APK，無法繞過 Android 的簽名校驗——如果你從 A 源裝了某個應用、後來又從 B 源裝了同一包名但不同簽名的版本，obtainium 只會提示更新失敗讓你先卸載再裝。這不是 bug，是 Android 系統層的硬性約束，但很多用戶第一次遇到時會以為是 obtainium 壞了。
第三個代價是 HTML 兜底源的脆弱性。當某個應用沒有 GitHub/GitLab/F-Droid 發布時，obtainium 允許用戶填一個網頁 URL 和 XPath 來抓版本號和下載鏈——但網頁一改版，XPath 就廢了。obtainium 對此的處理是把 XPath 配置存在每個應用的條目裡，用戶可以匯出導入，但維護成本還是在。
判斷：這套原理意味著什麼
obtainium 適合的場景很清晰：你關注的應用不在 Google Play 上，或者在 Play 上的版本發布比官方發布慢（很多開源專案就是這樣），而且你願意花十分鐘把追蹤清單設好。如果你只用 Play 商店裡的應用，obtainium 對你來說就是多餘的。
它不適合的場景也同樣清晰：你需要的是「一鍵下載所有應用最新版」而不是「我選哪些要追蹤」；你不會設 GitHub 訪問令牌、不會寫 XPath；你的設備沒有 root 也不想折騰 Shizuku，那每次更新還是要手動點一次確認——obtainium 幫你省的只有「去各個網站找下載頁」這個動作，最後那一下確認還是在的。
但不管怎麼說，obtainium 做對了一件事：它沒有試圖成為另一個應用商店，而是專注做「把分散源頭匯成單一清單」這一件事。版本比對、源識別、後台調度、安裝能力——每一層都有明確的責任邊界和對應的取捨，用戶可以按需取用而不是被迫接受某個預設。這大概就是開源工具最可貴的地方：它尊重你的設備，也尊重你的時間。
本文為個人基於網路公開資料整理編寫，非官方內容，僅供學習交流參考；軟體版權歸原作者所有，請支持正版；使用過程中遇到問題請查閱官方管道，本文不承擔任何責任。
