求助 - tidevice运行过程中崩溃，提示dtxm socket closed 不知道是什么原因

[gffguo]

环境mac【打算用windows的，所以先用mac试一试】 + python3.8 + tidevic 0.3.3 + pytest + allure + facebook-wda 1.3.3

问题描述： 我们写的自动化case，启动tidevice之后，case正常运行，但是大概率情况下，运行10 - 30分钟，tidevce崩溃，之前用xcode启动wda的时候，很少很少会这样

求助，我想知道是我们的代码影响到了tidevie服务了嘛？或者哪些情况下可能影响到tidevice服务？还是因为企业证书，我们使用的这个里面教程，强行写死，使xcode编译用用企业证书【https://github.com/appium/appium/issues/13086#issuecomment-559488669】 感谢各位大佬解答，再次感谢

tidevice退出截图

[codeskyblue]

你这个不像企业证书啊。 设置环境变量 export DEBUG=true 可以看到具体的错误日志

[gffguo]

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

[gffguo]

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

[gffguo]

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

[codeskyblue]

你看看有没有可能是执行了什么特定的代码，然后tievice就崩了

[gffguo]

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

[electricbubble]

@gffguo 你在用 WDA 获取 微信 的 source ?

我有过很多次这么做, 大部分情况都导致 xctest 被强制中断

重启 微信 后, 会有较大概率成功, 但是依旧很慢且有被中断的可能

我觉得不一定是 tidevice 的问题

[gffguo]

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

[electricbubble]

exists 会遍历当前页面元素

但凡是涉及到 微信 的较多页面元素, 都有可能导致被强制中断

我目前的做法是, 提高 目标元素 的 描述精准度

尽可能的使用更多 谓词 描述 目标元素

比如同时指定 元素坐标范围 控件类型

[gffguo]

好的，我去试试

[gffguo]

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

[electricbubble]

日志看上去是正常的 被 触发了 停止。。。

tidevice 的 转发 和 xctest 看上去都是正常的。。。

[gffguo]

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

[gffguo]

我用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)`