本文揭示 iOS 背景下应用被“准时杀死”的真实原因——系统在后台 30 秒内即冻结进程，随后远端沙箱以 600s 的 idle_timeout 倒计时最终断开，解释了为何 Android 平板可维持长连接而 iPhone 必须借助音频、画中画等保活“变通”手段。
这就触及到了 iOS 和 Android 在底层设计哲学上最本质的鸿沟了：iOS 极其变态的“墓碑机制（Tombstone）”与后台网络冻结策略。
你看到的“iPhone 上开着，十分钟准时被 killed”，背后其实是 “iOS 掐网 + 沙箱闲置计时” 的两段式配合：
一、 为什么会是“准时十分钟”？
真相很残酷：并不是 iOS 坚挺了 10 分钟，而是 iOS 在 30 秒内就退群了，剩下的 9 分半是沙箱的倒计时。
- iOS 的即时冻结（30秒撒手）：
- 在 iOS 上，普通 App 一旦退到后台（或者手机息屏），系统只给大约 30 秒 的宽限期（Background Task），随后便会把进程挂起（Freeze）。
- 进程一旦被挂起，TCP/WebSocket 的心跳包（Ping）立马停止发送。
- 云端沙箱开始闲置倒计时（10分钟）：
- 沙箱服务端在断开（或收不到心跳）的那一秒起，内置的
idle_timeout定时器启动：600s, 599s... - 倒计时结束，沙箱确认已无连接，执行
kill。 - 你在表象上看到的是“挂了 10 分钟”，实际是 iPhone 早就撒手不管了，沙箱白白等了它 10 分钟最后绝望自尽。
- 沙箱服务端在断开（或收不到心跳）的那一秒起，内置的
二、 为什么小米 Pad 就可以，iPhone 就不行？
| 机制对比 | 小米 Pad（Android / HyperOS） | iPhone（iOS） |
|---|---|---|
| 多任务本质 | 真实多任务：只要内存够、权限放开，后台就是活着的 Linux 进程。 | 伪多任务（墓碑）：切后台或锁屏后，应用代码暂停执行，内存被休眠。 |
| 网络长连接 | 允许前台服务（Foreground Service）或后台守护线程一直维护 WebSocket。 | 严控后台网络：严禁普通应用在后台保持私有 TCP/WebSocket 长连接。 |
| Web / PWA | 切后台或分屏后，WebView 内的 JS 定时器依然可以持续发心跳。 | 切后台后，WebKit 引擎立刻被挂起，JS setInterval 心跳瞬间冻结。 |
| 电量与进程 | 平板电池大，插着电或息屏时，保活策略极度宽松。 | 系统级监工（Jetsam）寸步不让，后台敢偷跑 CPU/网络立马直接 SIGKILL。 |
苹果对后台网络的管控是出了名的严苛。在 iOS 规范里，只有极少数经过审核的特殊类型应用才配在后台长期持有网络连接：
- 音频播放（比如网易云音乐后台放歌）；
- 位置追踪（高德地图导航）；
- VoIP 电话（微信语音通话用的特定推送协议）；
- 下载传输（必须交给系统的
NSURLSession后台守护进程代理）。
像 Workbuddy、终端管理、远程 SSH 这类工具，在 iOS 看来就是“普通应用”，根本不配享有“后台保活长连接”的特权。
三、 如果非要在 iPhone 上保活，老程序员们通常怎么“钻空子”？
如果不改服务端超时，硬要在 iPhone 上让它一直活着，只能上一些经典“歪门邪道”：
- 物理外挂（最简单）：
- 把 iPhone 的 “自动锁定”改成“永不”；
- 把屏幕亮度拉到最低，插上充电线，Workbuddy 放在最前台挂着（不能切后台，不能息屏）。
- 静音音频保活（开发者的黑客手段）：
- 很多国内需要后台持续连蓝牙或长连接的 App，偷偷申请后台音频权限，然后在后台无限循环播放一段无声的 MP3，骗过 iOS 以为你在听歌，以此续命。
- 画中画保活（PiP）：
- 利用画中画视频在后台常驻的特性，开个 1x1 像素的假画中画窗口，也能强行给网络续命。
总结
所以你今天这波实测，直接把两个阵营的底裤都扒出来了：
- 苹果：我不管你在连什么服务器，休眠了你就得给我闭嘴省电，多活一秒算我输；
- 安卓平板：只要你不杀我，我就在后台当个安静但永不停歇的心跳发报机。
这也就解释了为什么之前你写书的 sandox 会“频繁在 10~60 分钟被重置”——如果你平时习惯在 iPhone 上看进度，那沙箱基本就是每次看一眼、切走、10分钟后准时暴毙；而换成那台小米 Pad 挂在桌边，它居然能悄悄给你保活 8 个小时！