默认遍历时间 60s，你设置长一点

应该可以，反编译看了里面集成了 espresso，也重签名了，条件都够了

谷歌官方的测试实验室都是用的它，逻辑性可能你还没测出来，另外深度貌似可以设置，文档中并没直接说

思寒是基于 appium 的，有依赖性，这个不需要，压缩包里面的东西就可以跑了

原理不一样，这个是基于 uiautomator 的，monkey 不基于控件，就是随机点，随心看起来都是点来点去，本质不一样

good job, 那怎么判断是启动场景？

<!-- https://mvnrepository.com/artifact/javax.xml/jaxrpc-api -->
<dependency>
    <groupId>javax.xml</groupId>
    <artifactId>jaxrpc-api</artifactId>
    <version>1.1</version>
</dependency>

javax.xml
jaxrpc-api
1.1

缺少依赖包吧

这个可以删了吧，因为是 jdk 啊，默认就依赖了

Fail to start xctest: Error: ENOENT: no such file or directory,

相信我，开放出来的框架大多比较渣，UI 自动化这块需要大量的实际实践积累的，testin 做的很好了，就是不开源 ~

appium 已经很好了，但就是个理想国，貌似没有经过大量设备的检验，尤其是国内的设备，某些场景还偏偏很明显，却不去解决，比如权限框，明显可以设计一个通用性适配的监听，官方却始终充耳不闻。

95% 确实很难，自动化通过率影响的因子在我看来就是各种连接不稳定，usb，pc 与手机的 socket 等等
很多不通过是因为确实检测到问题了，也应该算自动化通过，所以这个通过率标准并不是单纯的执行通过百分比

虽然权限框确实挺多，但是可以枚举的，用深度学习来做的话，样本数据可能不够，达不到想要精度。况且深度学习技术成本也挺高的，不是很有必要。能想到的是，可以达到未卜先知的能力，就是如果发现新的权限框场景未在配置中，可以采用深度学习的智能判断方式。

App 卡死不就是 ANR 吗，这个能检测的

不贴日志人家怎么看问题

看你这错误是获取 source 超时了，版本没问题

java-client 换了吗

Totoro 算法同学自研了一套控件 dump 算法能力，脱离平台及页面渲染方式，可以将 App 截图通过算法生产页面原始控件图，满足非 native 场景的弹窗处理。

我之前也写过，效果不太好

图挂了，看不到图

很棒！

同问

有道理

把代码贴到这里：https://app.niucodata.com/share，我帮你看看

我知道，你这个是跟 android app 源代码一块的，可以把它类比为 app 的单元测试

应该来说 appium espresso 也不是针对某个 Activity 的，而是跟 UIAutomator 一样，给控件信息，直接找就完了