夸赞下的确流畅度和操作响应效果不错
好奇 web 端实时解 h264 流用的是什么
另外云真机租用这个，送的时长过期后没有购买渠道@_@

thx

领

光哥 cheatsheet

是商业产品，有免费功能

https://www.appetizer.io
目前 1.4.3 Maxim 的配置运行都完工了

不感谢老婆？要命

从小做起，改改 README 也是贡献：https://github.com/openatx/uiautomator2/pull/34/commits/23d9219068ce7939177458d13bb82a8ae4af7d43

基本就是之前讨论的，重点就是启动前关掉 uiautomator-server，上次卡在怕 server 关了 shell 就没了，结果幸运是 atxagent 提供的。这脚本是我跑过 PoC 可用的，正好有时间写了下

当然，1. 守护，保活 2. 反向代理多个 daemon 服务，不可能每个 service 一个 port/unixsocket；atx-agent 也暴露全功能 tty shell，脚本照旧；adb over TCP 方案开启也挺麻烦的

所以有私有化部署的商业服务在此

docker 好的 atxserver 应该能显示设备 但是不一定能操作它 你试试

这个只有 linux 可以用，而且端口就绑死了

repo 里面已经有 dockerfile 了。。。
另外 docker 并没有试验成功，因为 docker 启动后会造成手机连接 atx-server 时候是 docker 网卡的 ip，所以 docker 这块并未推出完整的介绍

总感觉专栏的 node title 还是要和 topic 的分类有区分，比如前面加一个 "栏" 的 badge；另外有几个微调的 dom 地方，直接 PR 还是？

这比较蛋疼 compile (":xxx") 实际 build 时候流程和 gradle 层面复杂度太高，真 组件化应该是真的 git repo 分离，每个子项目有自己的中间产物（jar/aar），自己的 unittest，在自己的 unittest 里面有接入 jacoco，有基本的 library 级别的覆盖率数据，然后在 apk 层面，总的包含所有 aar/jar，然后保证 jacoco agent 不重复冲突，exclude 掉一些类，有一个整 app 级别的测试用力的覆盖率数据

以场景（业务）为第一指导，设定几个通用指标，比如恒温说的启动场景，这个是一个重要的场景；此外就是一些最主要的流程，商城 app 就是购买，工具 app 就是主要几个功能；场景有了，去找重要的指标，也就那么几个；最后再来考虑万一环境不单纯性能会有什么影响（这个一般也不太会做到这么深），启动上你可以用 Appetizer；指标上，启动时间已经测了，cpu 利用率和耗电挂钩，分每个细分阶段里面的 UI 卡顿，HTTP 请求，还有主线程上面忙等等给开发比较具体的优化点

能有专人管理的完整的 rancher/k8s 那当然好啦

VM 早就过时，体积大，启动慢，内存耗费大，数据抠不出来

操作步骤 yml 还好 无非做好默认搜索方式然后多次猜测来简化用户表达 不过验证逻辑 yml 就蛋疼了
想到还有用 excel 写步骤的 其实和 yml 差不多
这种 case 描述最好大家能协作模块化 这对无论什么 ui 自动化工具都是类似的 是前端 比如 u2 和 appcrawler 统一一个格式
验证要考虑考虑 嵌入 yml 就意味着咬死一个语言了 可能无法跨工具通用

appcrawler 总算要有新版本了
@seveniruby u2 包了一个 jsonrpc 的东西 那个本来也是 java 写的 应该可以直接调

docker 方案已经在路上

英文讨论在这里：https://issuetracker.google.com/issues/37004446

主要问题是 aar 好像不太能插桩，因为 jacoco 是在 javac 的时候，用 asm.jar 插桩的，一种方法是 exclude 掉 aar 的代码，这样统计主干，然后 aar 自己测自己

是的，从无到有是必要的，因为 没覆盖的分支 == 该分支上的任何错误肯定都测不到，注意错误不限于Exception，要确保大回归有比较高的覆盖率；但是只看覆盖是不够的，覆盖只是基本款

可以