Clash 安卓耗電異常分析:背景保活、TUN 模式與廠商省電策略的取捨
行動端掛代理耗電偏高多與背景喚醒和 TUN 模式有關。本文分析常見耗電來源,給出背景執行策略、規則精簡與各廠商省電白名單的具體設定建議。
耗電異常先分類:是真耗電,還是感知偏差
安卓上掛代理後感覺手機「更燙更耗電」,不一定全是代理軟體的問題。先做一次基本區分,避免走錯排查方向。打開系統設定裡的電池用量統計,看 Clash 類應用的耗電占比是否明顯高於其他常駐應用(如聊天軟體、郵件用戶端)。如果占比在個位數百分點,大概率是正常代理轉發的開銷;如果長期排在耗電榜前三、且螢幕關閉後占比依然很高,才需要認定為異常。
另外要區分「耗電」和「發熱」。發熱多是短時間內高負載導致,比如剛匯入訂閱、批量測速節點延遲的那幾分鐘;耗電則是長時間尺度的累積消耗,主要看背景駐留期間的表現。這篇文章聚焦的是背景持續運行狀態下的耗電問題,而不是短暫的高負載發熱。
三個主要耗電來源:喚醒、TUN、規則匹配
背景喚醒頻率
Clash 系用戶端要維持代理服務和已建立的連線,系統層面會把它標記為需要保持存活的行程。如果用戶端本身或系統排程頻繁喚醒 CPU 做心跳檢測、連線保活、訂閱到期檢查,即便沒有實際流量在跑,也會累積不小的耗電。這一項在夜間「掛機不用手機」的場景裡最明顯——手機放一晚上,電量掉得比不裝代理時明顯更多,基本可以定位到喚醒頻率上。
TUN 模式的系統層接管
TUN 模式在系統網路層建立一個虛擬網卡,把裝置上所有應用的流量都先牽引到 Clash 核心處理,再按規則分流轉發。這種全域接管方式覆蓋面廣、相容性好,幾乎不會有應用繞過代理,但代價是每一個資料封包都多了一層封裝、解封裝和規則匹配的開銷。在安卓上,TUN 模式還涉及和系統 VPN 服務框架的互動,這層互動本身也有固定的資源消耗。手機端 CPU 效能和散熱空間遠不如桌面端,這部分開銷放大後就體現為耗電和發熱。
規則集大小與匹配複雜度
規則分流需要把每條連線的目標網域名稱或 IP 與規則清單逐條比對,規則集越大、層級越複雜,單次匹配耗時越長。有些訂閱自帶的規則集包含幾千條規則外加多個遠端規則集(rule-providers),用戶端在背景需要按設定週期拉取更新這些規則集,拉取和解析過程本身也會占用 CPU 和網路。如果同時掛載了多個體積較大的規則集,背景維護成本會明顯上升。
先看是否開了 TUN 模式,再看規則集數量和更新頻率,最後才排查系統省電策略是否誤殺了保活機制。三者疊加時,建議按這個順序逐項關閉變數,單獨測試哪一項對耗電影響最大。
背景執行策略的取捨
安卓的背景管理機制本身在「保證應用存活」和「限制背景耗電」之間做平衡,代理類應用恰好卡在兩者的矛盾點上:代理需要長期在背景維持連線才能持續生效,但系統的省電策略又傾向於限制背景行程。這裡沒有一個絕對正確的設定,只有場景取捨。
- 日常輕度使用:如果只是瀏覽網頁、看資訊,不需要代理常年在背景保持連線,可以在不用的時候手動斷開代理服務,減少背景喚醒次數,這是最直接的省電方式。
- 需要保持連線的場景(如掛著接收訊息推播、長期掛機的場景):需要把用戶端加入系統的背景白名單,允許其繞過省電限制,但同時要接受這會帶來相應的電量消耗,這是一個明確的權衡而不是漏洞。
- 只在特定應用上用代理:如果用戶端支援分應用規則或按套件名稱分流,只讓確實需要代理的應用走 TUN 通道,其餘應用直連,能顯著降低整體的規則匹配和轉發壓力。
建議根據自己的實際使用頻率對號入座,而不是不管場景統一開最激進或最保守的設定。
規則精簡:減少背景常駐負擔
很多訂閱自帶的規則集是「大而全」式設計,覆蓋大量小眾場景。對絕大多數使用者,精簡規則集能直接降低背景匹配和更新的開銷,以下是幾個可執行的方向:
- 檢查用戶端裡載入的 rule-providers 數量,合併或刪除長期用不到的分類規則集(比如極少存取的特定地區服務規則)。
- 把規則集的更新間隔(interval)適當拉長,沒有必要每天都拉取更新,多數規則集的實際變動頻率並不高,間隔設定為 3~7 天通常足夠。
- 減少同時掛載的策略群組數量,策略群組內的自動測速(url-test)本身會週期性發起探測請求,策略群組越多,背景定時任務越多。
- 確認沒有重複的規則集從多個訂閱來源交叉引入,重複規則會拖慢匹配速度但不增加實際效果。
rule-providers:
reject:
type: http
interval: 259200 # 三天更新一次,而非預設更頻繁的間隔
behavior: domain規則集調整後建議觀察一到兩天的電池用量對比,再決定是否繼續精簍,避免一次性刪得太多導致該走代理的流量漏掉。
各廠商省電策略下的白名單設定
台灣本地主流安卓廠商的系統在原生安卓基礎上疊加了各自的省電和行程管理策略,這些策略經常會在使用者沒有察覺的情況下殺掉代理服務行程,導致代理「莫名其妙斷掉」或者為了保持連線而反覆重啟、反而更耗電。下表是常見設定入口,具體選單文案可能因系統版本略有差異:
| 廠商系統 | 關鍵設定項 | 建議動作 |
|---|---|---|
| MIUI / HyperOS | 省電策略 · 自啟動管理 · 鎖定背景 | 設為「無限制」,開啟自啟動,工作清單長按鎖定 |
| EMUI / HarmonyOS | 電池 · 應用啟動管理 | 關閉「自動管理」,手動允許自啟動、關聯啟動、背景執行 |
| ColorOS / OxygenOS | 電池 · 應用耗電管控 | 設為「允許背景活動」,關閉深度睡眠限制 |
| Funtouch OS / OriginOS | 電池 · 背景高耗電 | 加入允許清單,關閉「智慧省電」對該應用的限制 |
| One UI (三星) | 電池 · 背景使用限制 | 從「休眠中的應用」清單移出,設為「不受監控」 |
把用戶端加入白名單之後,背景閃退和連線中斷的機率會明顯下降,但要清楚這是用一部分電量換取穩定性,和上一節的省電策略是相互制約的關係。合理做法是:如果確實需要長期掛機,加白名單;如果只是偶爾使用,保留系統預設的省電限制,用時手動打開即可。
部分廠商系統的「超級省電模式」或「極限省電」會強制斷開所有非白名單應用的網路存取,這類模式下即便代理用戶端在白名單裡,也可能因為系統整體網路策略被限制而無法正常連網,遇到這種情況要先確認裝置目前不在超級省電模式中。
什麼情況下該考慮不用 TUN 模式
TUN 模式不是唯一選項。如果裝置發熱和耗電已經明顯影響日常使用,可以評估切換到系統代理模式(在需要代理的應用或瀏覽器裡單獨設定代理位址),犧牲一部分覆蓋面來換取更低的系統層開銷。系統代理模式下,只有主動設定了代理的應用走轉發,其餘應用完全不受影響,匹配和轉發的總量會小很多。
這個取捨適合以下場景:只在瀏覽器或少數幾個應用裡需要代理、裝置本身效能偏低發熱敏感、或者只是臨時性使用而不追求全域覆蓋。反過來,如果需要覆蓋裝置上所有應用(比如某些應用有硬編碼的網域檢測,繞過全域代理會導致功能異常),TUN 模式仍然是更穩妥的選擇,這時候耗電就是必須接受的成本,應該把精力放在前面提到的規則精簡和白名單設定上,而不是糾結要不要用 TUN。
一次完整的排查流程建議
- 打開系統電池用量統計,確認耗電占比是否真的異常(參考本文第一節的判斷標準)。
- 檢查是否開啟了 TUN 模式,嘗試臨時切換為系統代理模式做一天對比,觀察耗電差異。
- 清點目前載入的規則集數量和更新間隔,精簡掉長期不用的分類,拉長更新週期。
- 檢查策略群組內自動測速的探測頻率,減少不必要的定時探測任務。
- 確認廠商省電策略的設定是否合理:需要長期掛機則加白名單,偶爾使用則維持系統預設限制。
- 觀察調整後一到兩天的電池曲線,確認耗電是否回落到合理區間,再決定是否需要進一步調整。
按這個順序逐項排查,基本能把耗電異常定位到具體環節,而不是籠統地歸咎於「代理軟體耗電」。多數情況下,耗電問題的根源是規則集過大或背景喚醒過頻,調整這兩項往往比糾結要不要用 TUN 模式更有效。