测试客户端硬件加速与指令集对移动端耗电及发热的影响
#硬件加速#电池发热#移动端代理
阅读需 4 分钟||
许多用户抱怨，在手机或移动设备上开启全天候代理会遭遇明显的续航缩短。而另一批用户则表示几乎毫无感觉。抛开后台唤醒机制不谈，加解密算法能否调用硬件指令集加速，是决定发热与耗电的核心。
1. 纯软件解密的功耗黑洞
无论是 VLESS、Trojan 还是 Shadowsocks，代理数据的进出都伴随着复杂的流加密（如 ChaCha20）或块加密（如 AES）。 如果客户端应用没有做好优化，或者系统架构不支持硬件指令，手机 CPU 将被迫使用通用的算术逻辑单元进行极其繁重的循环计算（纯软件计算）。对于持续千兆的高清视频流而言，这种密集的计算会让处理器长时间无法进入深度睡眠模式，表现为手机发热、电池电量快速蒸发。
2. 硬件加速扩展 (Hardware Cryptography) 的救场
正如在软路由中使用 AES-NI 提升吞吐量一样，现代的移动端芯片（如苹果 A 系列、高通骁龙）均内置了专用的密码学加速协处理器（Cryptography Extensions）。 优秀的代理内核在初始化时会检测硬件特性：
- 当使用如
AES-128-GCM的算法时，数据被直接旁路送入协处理器。此时 CPU 可以保持极低频率的待机状态，整个加解密过程几乎不产生额外发热，能耗比极高。
3. 算法选择建议
若您希望在手机上获得最佳的续航体验：
- 优先选择 AES 架构：在当前绝大多数现代手机和电脑上，得益于成熟的硬件电路，AES-GCM 加密算法的能效表现是最优的。
- 移动端适配较弱时的退路：如果您的旧款手机硬件老旧，缺乏 AES 专属指令集，尝试在服务端配置中选用
ChaCha20-Poly1305。该算法在设计之初便是为了在纯软件计算环境下提供更轻量、更高效的运算表现。