ios qx 耗电量好大，是真是假

看你有没有开脚本运行，运行脚本肯定会耗电。

Q：为什么此类应用在电量统计中占比很高？
A：当开启此类应用之后，由于所有的网络通信都被此类软件接管，所以所有的网络通讯耗电（如 WiFi 、4G ）都被计算在了此类应用上，使得此类软件在电量统计中占比很高。
但实际上，开启此类应用对电量消耗不会有显著影响。

原理应该是 vpn 类似吧，所有数据都要经过它

我自己的个人体验，一直开着，对续航的影响感知不明显。

个人感觉 surge 比 QX 省电……（以上仅代表个人观点和个人使用感受，如果你的观点不同，那么你是对的……）

2l 正解
不信的话可以关掉 qx 测试一天试一下 并不会提升多少

其实也不用一直开着

跑脚本更费电还费电池，去年刚买 12p 的时候跑脚本，电池健康蹭蹭往下掉，几个月就 90 以下了

你要不说我都没注意排名！ x 耗电量第四，不过没觉得开启或关闭后台有影响

@forson #7 我用备用机挂 QX 跑脚本，主力机就用 Surge，不跑脚本

感觉有影响 挂着 surge 偶尔会比较容易热

#Tips

代理软件 耗电 / 流量 问题

为什么使用了代理应用后在电量统计中显示耗电很多？
这是移动操作系统的一个特殊机制，Surge 、Quantumult 、Shadowrocket 等等所有的 SS 客户端开启后会接管全局的（几乎）所有通信，所以所有的网络方面电量消耗都会被算在 SS 客户端头上，实际使用中不会感到 SS 客户端对电量有明显影响，「设置 - 电池」中看到它的电池用量，绝大部分都是网络所消耗的电量，并不是 SS 客户端消耗的电量，SS 客户端就是背锅侠

网络流量也是如此的

via：聪聪🅥

@forson #8 夸张了吧，除非你像挖矿那样跑脚本，不然我只能认为你很夸张；而且这跟你的使用习惯也有关系（充电玩手机、过充过放、频繁使用充电宝等等），因为我之前也用 XR 挂着签到脚本，感觉也还好啊，用了两三年的手机电池健康还有 90%

简单的处理网络包理论上不会加大耗电的，但问题是，iOS 会专门给这些扩展开一个沙盒通信，多个线程之间沙盒通信才是耗电大户。

假

这类应用说是接管了所有网络，所以网络上的电量消耗都算在了软件上，所以感觉多。真的假的不知道，反正一直这样，之前我也无脑用别人的脚本，慢慢删减了很多，mimt 基本都关着，就还行吧。没办法

24 小时开着，也没见多用多少电

同樣是晚上到早上，小火箭掉電 15%~20%，換了 quanx 之後基本都維持在 3%~8%😂😂😂

@Tyuans 那都是借口。以 mimt 来说，需要把 源 app 的 https 解密，再重新用你的假证书封装，再转发请求到你的服务。与屏幕亮度比耗电确实没有显著增加，但是跟源 App 以及后台刷新比，那就是巨大的负担。这部分电量是实实在在软件造成的，和源 App 没关系

另外你的脚本后台执行、广告的过滤，熄屏后的流量都要经过那些软件的解包，打包，转发或者丢弃。

看看网络请求，能屏蔽一些广告图片，视频，我倒不觉得费电

费啥电，费智商而已，赶紧删了

个人感觉肯定会费电一点，你跑代理使用的协议还要加密解密啥的肯定会耗电

啥时候支持 vless 啊

会大幅增加耗电，因为不论使用本地代理 loopback 还是 tun 网卡接管，数据包组装好后会在内核态到用户态绕一圈到代理软件再经过用户态到内核态送到物理网卡，期间会增加多次上下文切换和数据拷贝，之前无聊做过测试，最坏的情况会让 CPU 的负载翻倍不止，特别是对于 QX 这种完全使用 tun 网卡接管的方案，比本地代理 loopback 开销还要大很多

@Cairetina 这还只是纯直连，走代理的话还要额外算上加密解密和规则审计还有协议本身的开销，本地代理和 tun 并不适合低功耗高性能的场景，选择开启就意味着放弃正常的续航，这没办法

这个问题我只在 iPad 上有感知，如果我不在路由端翻墙，那么 iPad 挂着小火箭或者圈 X，待机 3-4 天就空了。而如果不开的话，甚至待机半个月还有电。

iPhone 上没那么明显，本来就使用频率高，能耗高，反正至少每天一冲。

实测 13pro 待机情况下，qx 是 loon 耗电量的 3-4 倍…不知道什么情况

@Cairetina 你这个分析的很有道理，CPU 负载确实会增加很多

参考了 surge 的说明文档，qx 应该用的是方法 2 ，需要对协议栈重组，会有额外的性能开销。

https://manual.nssurge.com/book/understanding-surge/cn/

在 macOS 和 iOS 下，要想使程序发出的网络连接被另一个程序所接管，而不是直接将数据发送到物理网卡，有以下三种方式：

配置代理：如果系统配置了代理服务器，那么程序在执行网络请求的时候，就不会直接连接目标服务器，而是产生一个发向代理服务器的连接。利用这个特性，可以在本地启动一个代理服务，并配置系统代理为 127.0.0.1 （即本机）的一个端口，这样就可以接管网络请求。
但是，这种方式要求程序自身支持代理机制，系统的代理设置只是告知程序应该使用代理，需要程序自己完成代理的后续逻辑。好在，对于绝大部分带用户界面的程序，由于开发时使用了系统的高层网络框架（ Cocoa/Cocoa Touch ），开发者不需要进行任何额外的工作就可以支持代理。

而对于命令行程序，由于使用的是 POSIX 接口进行网络请求，该接口并没有对代理服务器提供内嵌支持，所以需要开发者自己完成对代理服务器的支持，这导致各种命令行程序对代理的支持情况和具体行为并不统一。同时由于大部分命令行程序并没有为 macOS 进行特殊处理，所以不会理会系统配置里的代理服务器设置。大部分命令行程序需要通过环境变量 https_proxy 和 http_proxy 去配置代理，还有一部分需要通过修改配置文件进行配置。

还有少量程序由于完全缺乏代理服务器的支持，无法通过这种方式去接管网络连接。

虚拟网卡（ Virtual Network Interface ，简写为 VIF ）：主流操作系统几乎都存在 TUN 和 TAP 两种虚拟网卡接口，原本是为了提供对 VPN 的支持。通过在系统中建立虚拟网卡并配置全局路由表，可以接管所有的网络请求。
这种方式对应程序来说是无感知的，所以并不需要程序主动提供支持，几乎所有程序都可以被这种方式接管网络请求。除非程序主动指定了物理网卡，绕过了默认的虚拟网卡。

Socket Filter：这是 macOS 的一项内核特性，可以通过注入一个 Kernel Extension （ kext ）对所有 socket 调用进行 hook ，以此接管请求。
除系统自身的一些程序外，这种方式可以强制接管系统中所有程序的所有网络请求。如 Proxifier 和 Little Snitch 就使用了这种方式接管网络。

这三种方式各有优劣：

方法 1 性能最优，对系统侵入性最小，无奈有部分程序不支持。

方法 2 性能略低，因为截取到的流量是 IP 层的数据包，需要有一个 TCP 协议栈进行重组装，造成了额外的性能开销。

方式 3 最暴力，对系统侵入性高，Kernel Extension 有可能造成整个系统的不稳定，Apple 已确认在未来的 macOS 中将取消对 Socket Filter 的支持。

@qiaoqiao1235 方法一的性能最优其实是作为系统代理配置远程代理时是最优的，但 Surge 是本地代理，额外增加的一次内核态到用户态，用户态到内核态数据拷贝以及上下文切换还是绕不开，性能和引入的 CPU 负载同样是不理想的，相比方法 3 仅仅是使用 loopback 接口 MTU 相比 TUN 更大带来的一些性能优势而已，并不是大头，所以其实半斤八两

@Cairetina 方法 3 -> 方法 2

@Cairetina #29 感谢，学习了😁

@Cairetina network framework 呢，看 Surge 说明是用户态网络栈？

@Love4Taylor 只减少了 Surge 从 tun 接管流量后再发送到物理网卡中间的一次上下文切换和数据拷贝，但相比直接连接依然多一次 tun/loopback 到用户空间，而且经过测试负载没有明显下降