iOS群控，是通过一台电脑对多台 iPhone 做集中管理与批量操作的技术方案，不越狱、不装插件、不需要开发板。
这篇要回答的是：iOS群控换了一批机型，脚本为什么会点歪。
有个做饰品矩阵的人，去年换了一批二手机。
旧的是 iPhone 8，新的是一批 iPhone 11。换上之后的第一条任务跑得特别顺——中控里每一台都显示成功，用了大概十二分钟。
他去泡了杯咖啡。回来打开其中一个账号看内容，没有；再开第二个，也没有。
十台设备，任务状态全是成功，实际一条内容都没发出去。
问题出在坐标。iPhone 8 和 iPhone 11 的分辨率不一样，同一套点击坐标在旧机器上落在「发布」按钮上，在新机器上落到了按钮左边二十个像素，那块地方什么都没有，点了也不会报错。
这是换机型之后最常见、也最难发现的一类问题：不报错，只是什么都没做。
坐标为什么会失效，失效之后为什么不报错
脚本点击的基本单位是坐标点。
坐标点是相对于屏幕分辨率定义的。旧机器 750×1334，新机器 828×1792，同一个 (400, 1200) 在两个屏幕上落到完全不同位置：旧机器上可能在页面中部，新机器上可能已经靠近底部。
而点击这个动作没有「目标」这个概念。脚本不会知道你点的是不是按钮，它只负责在 (400, 1200) 按下、抬起。点在按钮上，是触发；点在空白处，什么都不会发生。
所以这类问题的表现是：
- 中控里任务状态显示成功（每一步都执行了）
- 不报错（没有失败可报）
- 结果是空的（什么都没发生）
三个特征叠在一起，就是它比报错危险的地方； 报错你会立刻知道，这个不会；点歪了会报错吗？不会。
怎么确认、怎么修，下次买设备怎么避免
怎么在两分钟内确认是不是这个问题。 不用拆机、不用改脚本，先做这一步。
拿一台新机型，手工走一遍流程的最后一个动作。 也就是打开应用，手动点到发布那一步，看看实际按钮的位置和你脚本里写的坐标差多少。
具体做法：在中控里打开这台设备的投屏，把鼠标移到发布按钮上，看工具栏显示的光标坐标，跟你脚本里写的那个数字比。
差几十个像素以内（不同机型的正常误差），说明是坐标问题；差几百个像素，说明页面结构可能都不一样了，那是另一类问题。
这一步的价值是：避免你在还没确认原因的情况下就开始改脚本。 换机型之后的第一类怀疑对象永远是坐标，第二类才是系统版本、应用版本、网络。
修的时候按什么顺序改。 确认是坐标问题之后，修的顺序很重要，因为改错了会影响到已经跑好的那批机器。
第一步：按机型分组。 先在设备列表里把新旧机型分成两组，各自独立；这一步不做，后面所有的调整都是盲改。
第二步：只在新机型上重标坐标； 逐台确认关键动作的坐标。通常就三五个点：打开应用、进入发布页、填写区、发布按钮。把新机型的坐标记录成一组新的参数。
第三步：让脚本按分组取参数。 不是复制一份脚本，而是让同一份脚本根据设备所属分组读取不同的坐标组；这样以后再加机型，只需要加一组参数，不用维护第二份脚本。
一个容易被忽略的连带问题：等待时间。 坐标改对之后，还有一件事要一起看，等待时间。
新机型的性能通常比旧机型好，加载更快；这说明旧机型上设的两秒等待，在新机型上可能一秒就够了。听起来是好事，但反过来会有问题：如果你把等待时间按新机型调短，旧机型就会来不及。
所以等待时间应该按最慢的那台定，而不是按平均或者按新机型定。常见做法是留一个较宽松的等待加上「等元素出现」的判断，而不是写死秒数。
下次买设备的时候怎么避免。 这件事的根子在采购，不在脚本。
尽量整批同型号； 同型号说明同一套坐标，维护成本低一个量级。混用机型在十台以内还能忍，过了三十台就变成持续消耗，每次加机器都要重标一遍坐标。
如果业务上确实需要混用（比如二手市场某个价位只有一种机型），那就把机型当成一个长期维度管起来：设备别名里带上机型标识、脚本参数按机型分组、加新机型的时候走一遍完整的验证流程，而不是直接插上就跑。
他后来加的一条规矩
回到那十台机器。
他那天花了两个小时重标坐标，把新旧机型分成两组，脚本改成按组取参数；之后又跑了两次确认，才把任务推全量。
他后来加了条规矩：任何新机型进机房，先单独跑一条只发一条内容的测试任务，人工确认内容真的出现了，才能进正式排期。
这条规矩看起来慢，但它拦住的是「十台设备报成功、实际什么都没做」这种情况：而后者花掉的时间远不止测试那几分钟。