而且并发不是这么做的吧。，， 正常的流程应该是起多个子进程 然后每个子进程里面执行命令去获取 driver 跑脚本什么的

你的 Self.driver = devices_start_sync（）但是 devices_start_sync 这个并没有返回值啊，只是起了两个子进程而已

web 自动化相对移动自动化部署来说还是方便了很多，你可以直接搞个 jenkins+gitlab 这种

我觉得你这个最简单的办法就是可以让用户吧本地作为执行机，然后 debug 的时候 可以吧本地当做执行机去执行

如果这样的话 怎么保留之前的应用和数据呢

d(resource_id="XXX")[1] 是第二个这个 id 属性的控件 不是什么子节点。。

啥意思。。。

d(resource_id="XXX")[1].click()

等有时间我研究一下

你不是安装和取消公用一个 id 吗，第一个是安装，第二个就是取消呀，加上 ins 就好了。。

还好吧 我这边分辨率减半 图片次数不减的情况下 一张图片大小在 40k 左右 基本上还是很流畅的

你可以取第二个 resource_id 呀

我觉得可以加一个按照时间筛选的功能，以前的帖子很多因为时效性已经没用了

我有点怀疑你是不是真的用了 minicap 了。。

minicap 你也可以限制图片大小和每秒发的图片数呀。

占坑 以后有时间尝试~

曾经被鸽过两个口头 offer~

先收藏 等以后有时间尝试一下

我觉得真没必要，如果你要判断这些 那你 ui 自动化要判断的东西也太多了，比如说页面上所有的控件显示是否正常这种，我个人还是觉得 ui 自动化只做功能验证就行。至于显示这种应该交给更好实现的方式去做，比如手动或者接口

这种为啥要前端去统计数据呀。。。没搞懂。。ui 自动化不是验证功能吗。。统计数据啥的交给接口呀

我觉得重启 app 并不是一个好的选择，会丢失很多性能数据，尽量还是要保留 app 的运行状态比较好

好深奥的题目呀

感觉你这个没必要用接口去查数据吧，纯粹走页面判断就好了，这种关联性特别强的，我觉得完全可以放在一条用例里面，添加，编辑，删除，失败了也可以根据这个顺序重跑， 没必要做的特别复杂吧

我觉得在每次错误判断之后应该要返回到你脚本一开始执行的起点，如果是桌面就一直多按几次返回键，如果是应用首页就在回到桌面之后再进应用，不管怎么样都要确保重跑或者下一条用例跑的时候不会因为上次的异常出现问题。

appcrawler 不是已经停止维护了吗