额，殊途同归啊....

好想法！

好奇的点击来，竟然还被 @ 了，H5 覆盖率方案是有的，但是目前没有资源做，排期咯

#12 楼 @pacerron

#10 楼 @Lihuazhang 嗯啊

其实是想维护的，工作太忙了真的没时间，有兴趣的我可以加你来维护，再有就是 xc8.0 不支持 uiautomation 了，内部也在排期做一个基于 UITesting 的 monkey 出来

其实是可以的，我只能说这么多了

你的这个方案无法真正落地到手工测试业务，脱机启动的问题、代码侵入的问题、覆盖率收集丢失情况的考虑 解决以上三点才有可能真正落地，建议深入了解下 jacoco 的原理，怎样改造才能解决以上三个问题。

Appium 太多的中间件导致稳定性是个问题，如果做 android 的话 可以考虑 espresso, 个人非常看好这个框架！优势：1.google 亲生 2.自动线程同步 3.虽然是基于 instrumentation 的但目前可以调用 UIAutomator 支持夸进程 4.webview 也加入了支持基于 atoms 缺点呢就是支持的 android api 版本不算多，目前是支持 8、10、15、16,、17 、18、19、21 具体看测试需求了

#5 楼 @fenfenzhong 你可以用我说的方法尝试一下，“FPS 不一定和界面卡顿成正比” 这个我是论证过的，你可以再验证一下

FPS 的的高低和界面卡顿并不是成正比，android 上的 FPS 计算是依赖于用户交互，并不是说 FPS 低界面就一定不流畅，所以我个人认为用 FPS 去判定界面的流程性是不太严禁的，建议直接计算每一个 VSYNC 的丢帧率，即 1s 当中去计算 (丢帧数/60)，掉帧率越低说明界面越流畅。

#39 楼 @softblank blackCoder 致敬！

1.有些机型 longPress 不支持
2.没有验证点的验证录制
3.失败没有截图 (tearDown 里应该默认放一条截图的代码)
4.缺少详细的 log 日志 System 日志 截图等等, 不足以发现 app 的问题

#15 楼 @1056866402 解析 traceview 都是 Google 的，可以自己网上搜 traceview 源代码，我们只是加了过滤，存储解析结果到数据库，去除 GUI，添加命令行参数等功能，至于解析 traceview 的代码用的就是原生的，没有改动。

#8 楼 @monkey 我是这样分析的老机器也是可以用的，老 api 更适用于 traceview 的设计初衷，计算某个逻辑流程或函数的耗时，一般这种收集时间就比较短，所以影响也不打，traceview 也不会影响整个 app 的生命周期。但我用它时，其实 traceview 会常驻整个 app 生命周期，这样肯定会影响比较大，估计 Google 是出于长时间收集 trace 对 app 性能影响较大的背景下推出了新的 api，新的 apistartMethodTracingSampling也只不过是加入了采样间隔自定义，我设置 10ms 采样间隔基本感知不到卡，老机器的话如果纯 native app 应该影响属于可以接受范围，但是如果是 web 较多的应该会卡 B..., 换个角度想，同样的机器，同样的环境下得出的结果就有参考价值，即使只是 5.0....后边再想想怎么去解决老机器问题吧。

#4 楼 @monkey 记得要用5.0，Google 官方说4.4加入了startMethodTracingSampling后来我查 api 文档startMethodTracingSampling是 API21 才加入，即 5.0，被 Google 坑了。

#2 楼 @monkey 我用老的 apistartMethodTracing会将我们的 App 变成卡的一 B，可以卡出 ANR....黑屏....，尤其 web 页，native 还好，使用startMethodTracingSampling后正如官方所说性能影响很小，尝试后几乎影响很小，但也坚持仅作为参考值

#1 楼 @monkey 测试环节，预上线环境，上线时肯定要摘下对于代码块，api21 以后使用startMethodTracingSampling会好很多，但也仅作为参考值，这东西重点就在于数据的积累和周期性的环比。

单一接口的参数化，以及返回结果的正则校验也应该支持

#1 楼 @lihuazhang 帮你优化一下，启动的步骤用adb shell monkey -p com.my.pkg -c android.intent.category.LAUNCHER 1 省去 launchActivty 强相关

#175 楼 @wangbin039 good!