iOS群控，是通过一台电脑对多台 iPhone 做集中管理与批量操作的技术方案，不越狱、不装插件、不需要开发板。
这篇要回答的是：iOS群控发内容，为什么不能都挤在同一小时。
有个做服装的人，用 iOS群控 管着二十七个号，给我看过他的排期表。一张纸，左边写着账号，右边写着时间，从上到下全是「20:00」。
二十七台设备，同一个时间点。
他一开始觉得这样挺好，省事；数据齐、人不用等、发完一起收工。真正开始跑才知道不对劲。
挤在一起，先坏的是哪一步
上传不是即时完成的。
每条内容都要先传到平台，平台那边排队处理。处理完才显示出来。二十七台同时开始传，等于二十七个上传任务挤在一条管道里；有的三五秒就好了，有的要卡一分多钟。
问题不在慢，在于失败会扎堆。某个时间段网络一抖，同时开始的那一批里会有一半传失败。你去补的时候，又得从那二十七个号里挑出失败的那些，一个个再来。
更麻烦的是人。你不可能同时盯着二十七个屏幕，所以实际上你完全不知道哪一个失败了，直到第二天有人跟你说「昨天那条没看到」。
时间规则、分批和素材怎么落
不用你掐着表守。
iOS中控 的工具栏里有新建定时任务，把任务名、脚本、执行时间、设备选好就能存。存完它会按你设的周期自己往下跑，人不用在场。这就是自动发帖 样子。
周期有几种填法：按天、按间隔分钟、按间隔秒；执行次数填 0 表示不限次，一直按周期跑；想临时停下就在工具栏暂停，不需要删掉重建。
iOS自动化脚本 跑起来之后，这套时间规则就是整套流程里最不该临时改动的部分。今天改一次明天改一次，人的记忆跟不上，出错就查不出来。
最常见的错误是按设备编号分批：前十个一组、中间十个一组。看着整齐，是把风险平均摊开了；那按什么分？按业务。同一组内容发到同一批账号，那就让这批账号在一组里；不同内容线之间才需要错开。
间隔给多少？看你最慢的一次跑完要多久。如果你见过某次上传花了两分钟，那就别让两批之间只隔一分钟。留够余量的意思是：上一批全部有结果了，再动下一批。
排期要能执行，素材得能对上。
两级目录最省事：第一层是日期，第二层是账号。比如 0928 下面放 A07 美妆、B02 五金，每个文件夹里是该账号当天要发的东西。
这样做的好处是当天要发什么，打开日期文件夹一眼就看到了。补发的时候也一样，缺哪条找哪条。
反过来，如果素材按内容主题分类，你每次排期都要从五个文件夹里各捞一点出来，越到后面越容易漏。
收工核一遍，只有三种情况值得改
每天收工前花五分钟过一遍当天的任务记录。
看三个东西：任务有没有按时启动、启动后有没有报错、报错的是哪几台。有记录就不用回忆，直接对着看；发现三台失败，当天补掉，第二天不用惦记。
多账号运营里最容易被省掉的就是这一步。发出去有动静，核对没有反馈，所以一直往后拖；拖到某天客户来问，你才发现上个月有两天是空的。
规则定下来之后，只有三种情况值得改。
一种是失败率持续偏高，比如连着几天都有一两成失败；这说明间隔给少了，或者素材有问题。
一种是内容排期本身变了，比如从一天一轮变成一天两轮。
还有一种是设备规模变了。三十台变六十台，原来的间隔一定不够用了。
矩阵号运营 做到后面会发现，规则越稳越省事；除了这三种，剩下的都是手痒。排期表看着不顺眼想调一下，这种调整通常只带来混乱。
他后来把二十七个号分了四批
回到开头那个做服装的人。他后来把二十七个号分成四批，每批间隔十二分钟，从晚上七点半排到八点四十。
他说改完第一周他就发现，原来半夜还在等着收工的日子没有了，第二天早上看一遍记录就知道昨天全发完了。
定时任务 只是个工具，分几批、隔多久，还得看你自己的节奏。这个数字别人的方案里抄不来。