iOS群控，是指用一台电脑集中管理并批量操控多台 iPhone 的技术方案，免越狱、免签名、免硬件，靠外部输入注入驱动设备。
这篇要回答的是：iOS群控大促前要提前做什么，一周准备清单。
有个做跨境的老板，习惯在备忘录里写三行字：D-7、D-3、D-1。
大促前那一次，他写完这三行，往下翻了翻，发现自己漏了一行——设备；上面三行写的全是内容、价格、活动规则，没有一行跟设备有关。
后面发生的事不复杂。大促第一天上午，两台设备因为供电波动掉线，一条定时任务只发出去了一半。
他说如果这三台设备在前一周里被单独测过一次，那天上午就不用花两个小时处理一个本来可以避免的问题。
大促前的准备，内容那一侧大家都会做，设备这一侧最容易漏。按提前七天、三天、一天倒排，把设备这一侧该动的东西列一遍。
提前七天和提前三天，各该动什么
提前七天，先做压力测试，不做优化。 七天这个节点，唯一值得做的是把方案按大促的量跑一遍。
平时你一天发三条，大促一天要发十条。数量翻三倍之后暴露出来的问题，和你平时优化脚本能碰到的问题不是同一类。常见的是这三种：
- 供电不够。 十条任务说明设备唤醒更频繁，用电比平时密集。平时看不出来的供电余量，在这时候会显出来。
- USB 带宽不够。 如果任务里有截图、投屏这类动作，同时跑的台数一多，画面会卡、会超时。这一条在平时短时跑的时候很难发现。
- 任务排队。 如果多条任务的时间点挨得近，后面那一条可能因为设备还在忙而被跳过。这种情况中控里不会生成任务记录，你只会看到「这条没发」。
所以七天的动作是：按大促的排期，完整跑一遍。 跑完看三样：有没有掉线、有没有超时、有没有任务被跳过。
不要在这个节点做优化；为什么不做优化？变量一多，你就分不清跑得顺是因为优化有效，还是因为量还没上去。
提前三天，把设备和连接固定下来。 三天这个节点做的事叫「固化」；核心原则是：大促期间不要动任何物理连接。
具体三件：
第一，把设备的位置定死并贴标签。 哪台在哪个 HUB 的哪个口，写清楚贴在架子上。大促期间如果有人插拔过设备，靠记忆是找不回来的：而大促期间恰恰最容易有人手忙脚乱地插拔。
第二，把线材换掉可疑的； 平时充电时好时坏的、接口有点松的，这几天全换掉；一条线十几块钱，大促当天出问题的时间成本远不止这个数。
第三，把每一台的授权状态查一遍。 授权过期不会让设备掉线，它只是让任务跑不起来，表现得很安静；三天前查一遍，有问题还有时间处理。
提前一天，最怕的是再改一改
提前一天，只做核对，不改东西。
最后一天最容易犯的错是「再改一改」。
这一天原则上不再改脚本、不再调排期、不再插拔设备。只做核对：
- 脚本版本对不对。 确认跑的是你测过的那一版，而不是还在改的那一版。
- 排期有没有撞车。 把大促期间的定时任务按时间轴排开看一遍，确认没有两条任务落在同一个时间点。
- 账号和设备的对应关系对不对。 这一条大促最容易出错，因为临时加过设备、加过账号。
- 备用方案在不在。 哪个分组出问题的时候可以整体切到另一批，提前想好。
这一天如果发现必须改的东西，改完之后一定要再单独跑一次，而且只跑一台设备；改完不跑，等于把风险留到了大促当天。
三件看着有用、其实添乱的事
第一，为了保险把任务时间全提前。 有些人怕错过，把所有任务往前调半小时；结果所有任务挤在一起，反而更容易被跳过；错峰才是对的，见另一篇关于发布节奏的说明。
第二，临时加一批新设备。 大促前三天到货的新机器，没有经过你们平时的压力测试，也没在排期里验证过。新设备应该在平时加，不该在大促前加。
第三，把所有任务都设成重试三次。 重试本身没问题，但同一个任务重试三次说明设备被连续占用三段时间。如果大促期间任务本来就密，重试会把后面的任务挤掉；重试次数应该按任务的重要程度分别设，不是一刀切。
他给备忘录加的那一行
回到那份备忘录。
那位老板后来加了一行，叫 D-7 设备体检，下面只写了三件事：跑一遍全量、换掉可疑线材、查一遍授权。他说这三件事加起来一个小时，是他那次大促里花得最值的一小时。
大促当天的表现，基本由前一周决定。内容那一侧拼的是创意，设备那一侧拼的是有没有提前把变量固定下来。