棒~最近我也在看 UI 流畅度这一块。
我觉得 FPS 只是在评定 UI 流畅过程中的一个参考值。
这跟用户操作快慢、场景转换快慢、请求响应快慢都有关。
所以 FPS 确实跟是否流程是不成正比的。
可以把界面绘制速度也考虑进来，综合去考察卡顿。

PS：之前看 android 的源码，其实开发者模式里的 GPU 呈现模式，就是不断地执行 gfx 的 command，然后把得到的数据相加然后展示，然后继续执行，继续展示。所以 LZ 用 gfx 的方式确实更加统一一点。

说到底，Appium 并不是最好的，但应该是综合素质最好的开源自动化框架了。
你的 App 是纯 Native 还是 Hybrid？
你的 App 是否需要复杂的手势交互？
你的 Apk 能不能接受重签名？
你对脚本语言有没有偏好依赖？
你的 case 是否需要并行执行？

想好这些问题再选择也不迟。
Native Only 的话，UIAutomator 已经足够优秀了

cool~UI 流畅度全套方案了~~

#8 楼 @monkey yeah，nice to have。细节体验

进度条的意义不大吧感觉~

想了一下，应该还可以这样。

通过线程的方式启动adb install xx，push 部分可以根据楼主的方式回调出来。
但后续真正安装的 Progress bar 不需要做到真实，mock 一个出来就好。
循环获取管道里的信息，当 get 到 success 时，进度条直接 100%->finish，当出现 failed 时，进度条锁定，把错误抛出。

真是欢乐~~

Jenkins Remote Api 非常完善

一楼二楼都是广告~~~

来填一发~100QB 黑幕吧~

MD 语法搞起来.......这代码根本不能看啊☁️

可以把场景拿出来看看。

纳尼

🐂逼。
有什么公司在用fastlane么

做自己，不迷失

向 Q 博学习~

#51 楼 @xubin98246 卧槽，20 台。稳定吗？或者说，当其中有 6~7 台在被同时调试的时候，运作正常吗。

#12 楼 @zhangqi4mvp 如果确定了，那就把 resign 这个步骤毙掉，这要动 appium 源码。
或者把安装应用，启动应用的过程自己做，这个稍微利用一下 appium server argu 或者 desire_caps 的特性就行了。

可以先确定一下是不是 resign 这个步骤影响启动。

抹去出处，
抄袭可耻。

MD 格式......