VPN 会让电池掉电吗？无线电本来就在做的事

关于耗电的抱怨通常是“VPN 把我的电吃光了”，这是结论，不是观察。测量显示的是传输、无线电唤醒和重连的混合让设备一直忙。加密贡献了一部分账单，而在现代手机上它很少是最大的那一项。把三者分开，抱怨就变成可以真正测试的东西。

隧道给数据包的旅程加了什么

隧道承载的每个数据包都要经过认证、加密、再包一层包头，并在对端拆开。这些工作消耗处理器周期，更重要的是，它让网络接口比单有载荷时忙得更久。一次走隧道十分钟的备份仍然是十分钟的备份，只是每个数据包的开销略高。字节数和时长来自应用，而不来自隧道。

所以电池报告里的百分比是判断额外开销的糟糕指南。报告按组件归因工作量，而归因规则因平台而异。

把报告与网络计数器和屏幕点亮时间放在一起看。当传输窗口与耗电窗口吻合时，工作量解释了结果，协议只是次要因素。当计数器停住而耗电仍在继续时，是有东西让无线电保持唤醒，下一节就是该看的地方。

保活、重连与无线电的唤醒状态

看起来空闲的屏幕并不能证明网络空闲。同步、消息和更新检查都会发送少量流量，而每一次都可能把无线电从低功耗状态中拉出来，持续时间远长于交换本身。小而频繁的流量按字节算很贵，因为固定成本占主导。

隧道会以保活的形式加上自己的小流量，用来保持 NAT 映射打开，或者察觉已经消失的对端。它们的用途取决于协议和网络，关掉它们可能减少活动，却会让隧道在空闲期后无法使用。如果你要测试别的值，先记下原值，并确认之后隧道仍能恢复。绝不要从另一个协议搬来间隔，因为适合一种设计的常数在另一种设计里是任意的。

第二项成本是连接抖动。每隔几分钟就重连一次的客户端把时间花在握手上而不是载荷上，无线电始终没机会安定下来。

当平台为省电而停掉隧道

移动操作系统限制后台执行，隧道也不例外。屏幕一关就消失的连接通常是平台集成问题，而不是服务器拒绝会话。客户端自己的电池指引是入手之处，因为它描述了受支持的跨睡眠保持连接方式。

把所有东西都排除在电源管理之外并不是解决办法。它会造出另一种工作负载，并毁掉你想做的比较。

然后决定设备睡眠时该发生什么，因为常开运行、无隧道时阻断和电池优化回答的是三个不同的问题。一个靠悄悄放弃所需覆盖来省电的设置并没有保住原目标，它掩盖了失败。在调整任何东西之前，先把预期策略写下来。没有它，你最终只能在耗电的隧道和干脆不存在的隧道之间做选择，还把两种结果都称作成功。

建立比较，而不是建立信念

同类相比：同样的任务、同样的网络、同样的时长、相近的信号。记录传输的数据量、重连次数、设备温度和信号条件，因为其中任何一项都可能单独改变结果。一小时掉几个百分点的电，落在多数手机的噪声范围内；而多次运行中可重复的规律则不是。Android VPN 指南描述了行为良好的客户端所遵循的生命周期与常开行为，这在某个客户端做不到时是有用的参照。

把可选的大流量传输挪到电量和网络都便宜的时候。

然后按比较显示的结论行动。如果是工作量造成的，就安排工作量。如果是抖动造成的，就修复引起抖动的网络切换。如果是平台造成的，就遵循该客户端受支持的电池策略。削弱加密设置是唯一能在不触碰原因的情况下改善数字的改动，所以它应该是任何人最后才动的东西。