我行我素12334从接到这个项目需求到现在，整理出一套能在 iOS 真机上跑通的账号批量上号系统，前后大概花了两周时间。最核心的难点其实不在"发起登录"这一步，而在登录前的设备调度、游戏识别，以及登录后的状态判定——也就是项目标题里反复强调的智能验号和自动识别游戏。下面我把这套源码的设计思路、关键模块和踩过的坑完整拆开讲，所有代码部分都是实际跑过的版本，涉及敏感信息的地方我用替换文本做了脱敏。
如果你也在做游戏测试环境搭建、玩家回访任务，或者需要定期用大批真实账号验证 App 在 iOS 不同系统版本上的登录表现，这篇文章应该能帮你省下不少弯路。它解决的底层痛点是：一堆 iPhone / iPad 连在那里，如何不靠人工一只只点屏幕，而是通过几个后台队列自动把账号分发到设备、自动识别当前启动的游戏，再自动判断账号是否真的登录成功，最终把结果写回任务列表。
1. 这套批量上号系统本来是解决什么的
先说应用场景。很多人一看到"批量上号""智能验号"这几个词就自动往灰色地带联想，实际上在正规研发团队里，批量账号登录是特别常见的测试需求。比如游戏发行前的兼容性回归，几十个测试账号要覆盖 iOS 15 到 iOS 17 的设备，每个账号都有不同的新手引导状态或不同等级存档；再比如买量落地页要验证不同渠道包的登录跳转是否正常，这些都是需要同时操作多台真机的场景。
1.1 用几十个账号做兼容回归时的痛点
在没有这套源码之前，团队的做法很原始：一个人抱着两台手机，手输密码，观察是否弹窗，再手动记录这个账号的登录结果。遇到设备多了就得拉几个人凑一张桌子，否则测试进度会卡在"账号登录"这一环。
这里的痛点有四层：
- 设备状态不可知。哪台手机电量和网络正常、哪台已经卡在某个界面，全靠人肉巡检。
- 账号密文容易泄露。为了图快，大家会把账号密码做成共享 Excel，用完之后也不记得清理。
- 登录成功与否没有统一标准。有人看到进入主界面就写"成功"，有人要看到游戏内服务器选择页面才认定成功，口径不一致，后面分析数据就乱了。
- 重复劳动极多。正常账号登录一次就够了，但 QA 场景下经常需要登出、清缓存、再登录，反复循环。
1.2 系统的边界与适用场景
在介绍源码能力之前必须把边界说清楚：这套系统做的是"基于 iOS 系统授权机制的 UI 自动化登录流程编排"，它不会去 hook 系统接口，不会调用任何私有 API，也不会伪造设备信息。它做的事情，相当于一个坐在设备前面的人，把"打开游戏、输入账号、输入密码、点击登录、等待进入、截屏确认"这一套动作自动化执行而已。因此它天然适合以下场景：
- 自己的测试账号、自己公司开发或已获得测试授权的游戏。
- 需要把登录耗时压缩到可接受的范围内，从而把测试人力集中在真正的功能验证上。
- 需要跨多台设备并发执行任务，且要求结果可视化。
反过来，如果你想用这套源码去绕过多因子验证、去碰不属于自己的账号体系，那它一定会失效，因为 Apple 和各个游戏服务端对异常登录行为都有风控。技术上不仅跑不通，合规上也过不去。所以后面我讲的智能验号，验的一直都是"账号能否正常进入游戏"，也就是登录态的确认。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 源码主框架：四个模块怎么各司其职
整个项目在架构上分成了四层：设备调度层、iOS 执行层、登录策略与账号会话管理层、后台任务层。每一个层次只依赖于自己的上游抽象接口，不会互相揉在一起，这样后续扩展新游戏或者扩充设备池的时候，不用把整条链路推倒重写。
2.1 设备调度层
设备调度层负责回答一个最简单的问题：现在哪些手机在线、哪些设备空闲、哪些设备值得分配一个登录任务。
实际实现里，每台设备接入 Mac 或 Windows 宿主机后，通过 USB 链路建立一条稳定的通信通道。调度层会周期性获取设备的基础信息，包括系统版本、设备型号、剩余电量、剩余存储空间，还有当前是否处于锁屏状态。我维护了一个设备字典，状态是空余、忙碌、异常、离线四种。每次把任务提交进来时，调度器只会把任务派发给"空余 + 电量大于30% + 系统版本匹配"的设备，其他设备直接跳过，不会像早期版本那样把大量任务一股脑塞给同一台设备导致后面全部超时。
2.2 iOS 执行层
执行层是整套系统里最复杂的一块地方，它需要真正和 iOS 界面打交道。项目里内置了一个以 XCTest 为底座的执行器，这套执行器会在被控设备上以调试方式启动一个临时 Runner，Runner 的能力可以理解为：
- 读取当前前台应用的前台 Bundle ID。
- 遍历当前界面里的 UI 树节点，读取按钮、输入框、静态文本。
- 对某个坐标点或者 UI 节点执行点击和长按。
- 在指定输入框里输入文本，前提是文本框处于可编辑状态。
- 获取设备当期截屏图。
Runner 与本机之间通过 USB 或者局域网通信，宿主机能持续向 Runner 下发操作指令。之所以没有使用模拟器方案，是因为绝大多数网游在模拟器里跑不起来，而且真机覆盖到的系统行为和网络情况才更接近真实用户环境。
2.3 登录策略与账号会话管理
登录策略是整个流程的逻辑大脑。每个游戏都需要一套自己的登录动作模板，模板里说明这个游戏登录界面的核心特征、账号输入框的大概坐标或可识别的 accessibility id、密码输入框位置、登录按钮确认方式以及登录成功后的特征界面。
会话管理则负责维护账号的登录态。在登录流程结束之后，系统会为当前账号生成本次登录的结果记录，包括是否需要短信验证、是否进入异常弹窗、是从哪个入口启动的游戏。这些记录会按设备 UDID 和游戏 ID 索引，后续如果出现账号被登录态挤出或者会话过期，可以直接触发重登。
2.4 后台任务层
后台任务层