iOS自动化脚本怎么定时批量发送？排期、下发与失败补跑

iOS群控，是通过一台电脑对多台 iPhone 做集中管理与批量操作的技术方案，不越狱、不装插件、不需要开发板。

这篇要回答的是：iOS 自动化脚本怎么定时批量发送，排期、下发与失败补跑。

有个人把脚本调通之后跟我说了一句话，我记到现在。

他说：能跑通，和能天天跑通，是两件事。

当时他的脚本已经在一台手机上跑得很顺了。放到二十台上，第一周就出了三种他不会处理的问题：有两台机器到点没启动、有一台跑了一半停住、还有一台跑完了但结果不对。

这三种问题，一台机上你永远不会遇到。

为什么「能跑通」不够

单台调试时，你在旁边看着。屏幕卡住了你等一会儿，点歪了你重来一次，机器发烫你把它挪开。

批量执行时，这些都没有了。脚本在二十台机器上按同一个时间表跑，出问题的机器不会被你顺手扶一把。它会一直错下去，然后影响后面的步骤。

所以批量执行真正要解决的不是「怎么让它跑」，而是三件事：什么时候跑、按什么顺序跑、跑挂了怎么办。

最容易踩的坑是让所有设备卡在同一个时间点。

把定时任务的执行时间设成整点，二十台设备在同一分钟开始同一个动作。从外面看就是二十台机器同时在做同一件事；同一分钟二十台齐动，像人干的事吗？不像。这既不像人，也让你排查起来很痛苦：出问题的时候你不知道是哪一台先挂的。

比较稳的排法是错峰。

把设备分三批，每批隔十几分钟启动。批次内部再让每台错开几秒到几十秒，不要让它们完全对齐；同一件事，今天这批先做，明天换一批先做。

时段上也有讲究。如果你的业务是要给客户看的状态，那就要避开对方那边的深夜。如果纯粹是内部处理，那尽量放在你人在的时间段。出了问题能马上处理，比半夜跑完第二天才发现好。

顺序这件事，单台跑的时候想不到。

有一台设备如果本身有问题，你让它先跑，它会把整个批次的节奏拖住：脚本卡在那台上等，其他十九台空转。所以下发之前先做一次在线检查，把不在线、连不上的挑出去，只对能用的设备下发。

还有一点是任务之间的先后。如果脚本要依赖前一步的结果（比如先登录再操作），那这类任务不能并行，得等前一步全部回报完再进下一步。不依赖的就可以一起发。

脚本调用的每个动作都是有返回值的：成功的时候返回的是空，不成功的时候会返回一段说明。这个返回值得看；很多人不看，调用完直接往下走；结果前面一步没生效，后面全歪。

我的做法是三步。

第一步，自己包一个判断函数，统一判断这次动作成没成。不要在每个调用点写一遍。

第二步，没成就重试一次。手机不是电脑，同样一步在旧机器上慢半拍，重试一次能救回大部分偶发问题。

第三步，连着两次不行就把这台从这一轮里摘出去，记一笔，别让它拖着其他设备一起等。二十台里坏两台，剩下十八台该跑完。

还有一种情况是会话本身出问题，表现是画面还在但点了没反应。这种时候先重置会话，通常比拔线重插快，也不用去动那二十根线。

这是最容易被忽略的一条。

失败重试是解决偶发问题的，不是解决系统问题的。如果同一步在十台机器上连着失败，那不可能是十台机器同时坏了。大概率是脚本本身有问题，或者那一步依赖的页面变了。

这种情况继续重试只是浪费时间，而且会在页面上留下大量异常操作。正确的做法是停下来，在一台机器上手动走一遍那一步，看看到底卡在哪。多台同时失败，还能当偶发处理吗？不能。

判断标准可以简单一点：同一台连续失败，重试；多台同时失败，停。

把上面几条凑起来，大概是这样一个流程：

执行前先查一遍在线状态，把不在线的摘出去；在线设备分三批，每批间隔十几分钟启动；批内每台再错开几秒；每台的动作失败重试一次，连续两次失败就把这台标记出来跳过；整批结束后看失败清单，只对失败的那几台补跑；如果失败集中在同一步，先停下来查脚本，别急着补跑。

这套排法不复杂，但能把「能跑通」变成「能天天跑通」。那个人后来的说法是，他现在早上起来只看两样东西：昨天跑了多少台，有几台需要补。脚本功能和分组控制里有更细的说明。