```html

在Android上跑ab（ApacheBench）？力测别急着摇头。我手头这台Pixel 6a，力测没root，力测没装Termux，力测就靠一个Magisk模块挂载了静态编译的力测ab二进制——跑通了。而且测的力测是本机Nginx，端口8080，力测QPS稳定在2300左右。力测这数字比某些云服务器还好看，力测因为手机CPU调度激进，力测小核直接拉满。力测

但事情没这么简单。力测Google从Android 10开始收紧exec权限，力测/data/local/tmp下的力测可执行文件默认不能直接跑。你得先chmod 755，力测再./ab。我第一次试的时候报错“Permission denied”，折腾半小时才发现是SELinux的context问题。用magiskpolicy --live "allow untrusted_app shell_data_file file execute"才搞定。这玩意儿没人写在文档里，全靠翻XDA论坛的老帖。

ab本身是Apache HTTP Server自带的压测工具，单文件静态编译后不到200KB。我用的版本是2.4.57，从Debian的arm64包提取出来的。命令很直接：./ab -n 10000 -c 100 http://127.0.0.1:8080/test.html。-c 100表示100个并发，-n 10000是总请求数。手机跑这个，发热明显，后盖能到42度。但结果有意思：前3000个请求的延迟在12ms左右，之后突然跳到45ms——明显是thermal throttling。Android的温控比Linux桌面激进得多，大核一热就锁频率。

你可能会问，为什么不用手机测远程服务器？我试过。Wi-Fi 6环境下，ab连局域网内的PC，QPS只有800多。瓶颈在无线网卡的中断处理，不是CPU。所以真要压测，最好让ab跑在localhost，测的是手机本身的协议栈和CPU极限。这跟用PC压测完全两码事。

还有个坑：Android的TCP缓冲区默认很小。/proc/sys/net/ipv4/tcp_rmem显示接收窗口才128KB。我手动改成1MB后，QPS从1800涨到2300。改这个需要root，命令是echo "4096 87380 1048576" > /proc/sys/net/ipv4/tcp_rmem。重启失效，得写进init.d脚本。普通用户别折腾，容易把网络搞崩。

ab的输出里有个“Failed requests”指标。在Android上跑，这个数字经常不为零。不是服务器挂了，是手机Wi-Fi省电机制导致的连接重置。我关了“Wi-Fi扫描调节”和“自适应电池”之后，失败率从2%降到0.1%。这跟ab本身无关，纯粹是Android的电源管理在捣乱。

最后说个实际案例。我用这台Pixel 6a测一个Go写的HTTP服务，开了HTTP/1.1 keep-alive。ab的-k参数必须加，否则每次请求都重建TCP连接，QPS直接掉到600。加了-k之后，稳定在2200。但注意：ab的keep-alive实现有bug，在Android的bionic libc上偶尔会卡死。我遇到过三次，只能kill -9。所以别跑太长时间，-n 50000以内比较安全。

如果你真想在生产环境用Android做压测节点，建议用Termux装ab，别用Magisk。Termux的proot环境更干净，虽然性能损失约15%，但稳定。我现在的做法是：Termux里跑ab，Magisk里跑tcpdump抓包，两边对比看丢包。这组合比PC上的wrk+iftop还顺手——毕竟手机随身带，蹲厕所都能测一波。

```