gff

可以试试session.source(),我们现在部分用的就是这个，对比你想要的是否在获取到的页面信息里找到，有的toast可以获取到，有的就不可以了，不稳定 

好的，我试试去 这个export DEBUG=true，然后看看是什么错误，感谢大佬

@codeskyblue 大佬，你说的这个DEBUG=true是说我python里import wda 设置wda。DEBUG=true，还是这样，tidevcie xctest -B 。xctrunner --debug这样，下午又发现了一次崩溃，使用了启动命令后加--debug，打印的信息还是上面那个截图那样。

打开export DEBUG=ture，显示说dtxm socket closed 

发现大多次崩溃是，使用了exists，然后接的又使用了exists，每次好像都会遍历一下当前页面所有信息，会不会因为这样，过多的遍历页面信息，然后崩溃？ 每次都能有好几节这样的打印，每次打印的内容都很多。截屏截不全 

@electricbubble 对，主要现在我想确定一些，我这脚本写的哪些东西，导致了xctest中断，最终导致了tidevice崩溃 我那个是用wda的exists，判断一个元素是否在当前页面已经出现了，然后有一个方法里用了很多次 还有一个就是我们这个有登录和非登录的切换，有的时候切换的比较频繁，【qq登录】

好的，我去试试

大佬们，可怜可怜孩子吧。 可以不可以再帮我分析一下，为什么还是会报错。。。我发现好像每次都会有这个 server request not handled 

@electricbubble 好吧，我试了好多改我们代码，前一会有一次，是执行到facebook-wda里wait方法就wda退出了，wait等待一个登录弹窗出现，但是尝试了5次之后，又没事了。。。我还是再慢慢定位一下我们脚本哪搞的出问题了

我用tidevice 的wdaproxy方式执行wda【原因是失败可以自己重启】，和fackbook-wda的回调，暂时能勉强可以不会崩溃` def device_offline_callback(client, err): if isinstance(err, requests.ConnectionError): print("Handle device offline") ok = client.wait_ready(600) # 等待600s恢复 if not ok: return wda.Callback.RET_ABORT return wda.Callback.RET_RETRY c.register_callback(wda.Callback.ERROR, device_offline_callback, try_first=True)`