VPN 真的更耗电吗？先该测什么

开启 VPN 之后出现的耗电，通常只是换了名字的工作负载变化。一条空闲挂着的隧道、一次夜间备份，以及每隔几分钟就重连一次的客户端，消耗的电量差别很大。状态栏里的图标没法告诉你看到的是哪一种。

把隧道和它承载的东西分开

照片备份或视频通话会推送数据，VPN 随后必须对这些数据加密、认证并转发。其中一部分电力成本属于产生流量的应用，只有一部分属于隧道本身。把电池报告与网络、屏幕统计放在一起读，才能把两者分开。在改动任何一个设置之前，先从这里开始。

平台报告的归因方式也各不相同。一个被标记为 VPN 的组件可能包含本来就该花掉的射频时间，而它很少能单独分离出加密带来的额外开销。把这个百分比当作起点，而不是测量结果。

adb shell dumpsys batterystats --charged com.example.vpn | head -60
adb shell dumpsys netstats detail | head -40

第一条命令打印上一个充电周期里各组件分到的电量。第二条显示哪些接口搬了多少数据，而正是这个上下文把一个百分比变成对工作负载的描述。在就隧道下结论之前，先把两者对比一下。

如果传输时设备发热，就在相同条件下比较不同客户端或协议设置。为了追一个耗电数字而削弱加密，是用已知的代价换未知的代价。

重连让射频一直醒着

屏幕看起来空闲，并不代表网络空闲。消息、同步和更新检查仍在发包，而每一次小交换都可能把射频唤醒得比数据包本身持续的时间长得多。数据包时长与射频开启时间之间的这个差值，正是待机耗电藏身之处。这也解释了为什么一条空闲隧道仍然可能比一台空闲设备更费电。

keepalive 存在是有原因的：它让 NAT 映射保持打开，或者发现已经消失的对端。它的间隔取决于协议和所用的网络。关掉它或许能减少活动，但会让隧道在一段空闲之后无法使用。

grep -i keepalive /etc/wireguard/wg0.conf
wg show wg0 latest-handshakes

第一条命令显示是否配置了持久 keepalive，以及间隔是多少。第二条显示最后一次握手发生在什么时候，这能把安静的隧道和不断自我重建的隧道区分开。

当耗电发生在网络切换之后时，连接历史最重要。修好反复恢复的问题，通常比更换出口位置更值，因为不停重连的客户端把电力花在恢复上，而不是传输上。

当平台挂起隧道时

操作系统会限制后台执行，一条在熄屏后消失的隧道可能是这条策略的牺牲品，而不是服务器故障。从用户角度看两者一模一样，所以平台日志才重要。

把所有应用都排除在电源管理之外，会改变工作负载，让之后任何比较都失去意义。只把 VPN 客户端和真正需要它的那一个应用排除在外，然后对着同一条基线重新测量。

睡眠之后该怎么办，要单独决定。常开运行、无 VPN 时阻断、以及普通的电池优化，回答的是不同的问题；一个靠悄悄放弃必需覆盖来省电的设置，并没有满足最初的要求。

拿可比的东西作比较，然后再决定

两次测量用同一个任务、同一个网络和同样的时长，并记录传输量、重连次数、温度和信号强度。电池百分比的短期变化噪声很大，所以只有在可比使用下反复出现的模式，才是值得据以行动的证据。一次测量只是轶事。

在日程允许时，把可选的大流量传输挪到充电器旁和不计流量的网络上。然后再看一整天，因为一条空闲数小时的隧道，远比一条忙碌二十分钟的隧道便宜。

写下你改了什么，以及第二次测量显示了什么。没有这份记录，下一次比较就会从另一条基线开始，同一场争论又要从零重来。