自动化xctrace录制卡在‘Stopping recording...’的问题排查

我在通过xctrace配合UI测试自动化捕获iOS应用卡顿，流程为每个UI测试用例启停一次xctrace，但每约20次运行就会出现一次xctrace无法退出、卡在Stopping recording...的情况。以下是对该问题的原因分析和解决办法：

可能原因 #

• 进程同步异常：xctrace停止时需要与被attach的应用进程、iOS设备完成数据同步，如果UI测试结束时应用处于资源未释放、进程僵死或崩溃状态，会导致xctrace无法正常完成trace文件的写入流程。
• 输出重定向顺序错误：原启动命令中>> trace.log & 2>&1的顺序有误，错误输出未正确重定向到日志文件，可能导致xctrace子进程的输出缓冲阻塞，进而卡住退出流程。
• 信号处理不彻底：仅发送INT信号可能无法触发xctrace的退出逻辑，尤其是当xctrace正处于磁盘写入或设备通信的阻塞状态时。
• 存储/权限问题：设备存储空间不足、trace文件输出路径权限不足，会导致xctrace在保存录制文件时卡住。

解决办法 #

1. 修正xctrace启动命令的输出重定向 #

原命令中错误输出重定向的顺序不正确，调整后确保stdout和stderr都写入日志文件：

xcrun xctrace record \
    --device <device> \
    --attach <pid|name> \
    --template <path|name> \
    --time-limit 5m \
    --no-prompt \
    --output recording.trace \
    >> trace.log 2>&1 &

xctracePID=$!

2. 增强停止逻辑，增加超时与强制终止机制 #

替换原停止命令，添加超时等待和多级信号终止逻辑，避免无限等待：

# 发送INT信号尝试优雅停止
kill -INT $xctracePID 2>/dev/null

# 等待10秒，检查进程是否存活
timeout=10
while kill -0 $xctracePID 2>/dev/null && [ $timeout -gt 0 ]; do
    sleep 1
    timeout=$((timeout-1))
done

# 若仍存活，发送TERM信号
if kill -0 $xctracePID 2>/dev/null; then
    echo "xctrace未响应INT信号，发送TERM信号" >> trace.log
    kill -TERM $xctracePID 2>/dev/null
    sleep 3
fi

# 最后仍存活则强制KILL
if kill -0 $xctracePID 2>/dev/null; then
    echo "xctrace未响应TERM信号，强制终止" >> trace.log
    kill -KILL $xctracePID 2>/dev/null
fi

# 清理僵尸进程
wait $xctracePID 2>/dev/null

3. 其他优化措施 #

• 增加缓冲时间：UI测试结束后，不要立即停止xctrace，等待1-2秒让应用进程状态稳定后再执行停止操作。
• 检查设备状态：每次测试前检查iOS设备的存储空间，确保有足够空间保存trace文件；同时确认被attach的应用进程处于正常运行状态。
• 更新Xcode：升级到最新版本的Xcode，Apple会定期修复xctrace的已知稳定性问题。
• 避免重复attach：确保每次测试前，上一次的xctrace进程已完全终止，避免多个xctrace进程同时attach到同一应用导致资源竞争。

内容的提问来源于stack exchange，提问作者Tieme