STF 大厂真机云为何能做到公网真机远程使用,即可能采用视频流方案

leoche · 2021年04月24日 · 最后由 大浪 回复于 2021年11月26日 · 3458 次阅读
  • 吐槽
    公司由于业务需要做真机云快两年了,已小有成效。刚开始研究 stf 的时候那真是一个心累,项目进度逼的很紧、创新型项目人力也就一两个坑、STF 技术栈采用比较冷门的 angular 和后端 node。

  • 视频流
    言归正传,我把市面上的真机云都尝试了一遍观察其在远程调试时带宽占用,发现其带宽占用异常的小,再对比一下原生的 stf 一个天一个地。简单猜想其流畅的秘密,在于其带宽控制。


  • 原生 stf 想必研究真机云的都知道,stf 其图像成像方式是通过 minicap 不断截图,然后通过 socket 进行输出不断在浏览器绘制 png 图片。一张图片大概是 100k~200k 左右 (测试手机 1080x1920),minicap 文档描述一些较旧的机子渲染时能达到 10-20 FPS,一些较新的机子 30-40 FPS。我们取图片渲染平均值 150k, 也就意味着较旧一点的机子使用时所需贷款 1500k~3000k/s、一些较新的机子 4500k~6000k/s。这个带宽要求,也只能将 stf 限定在内网使用而且是同一办公室网段的那种。如果公司有分部,分部走专线的情况下一般都会有限速,带宽达不到 stf 要求的带宽情况下,就会出现图片传输延迟照成卡顿甚至图像一动不动。为了实现分部使用,甚至异地使用就需要降低带宽。


  • 先前是在图像压缩上下功夫,一直达不到效果。 一次在社区偶然间浏览看见一篇解析 UC 真机云文章,恍然大悟如果能直接从手机拿到图片编译成视频流通过算法压缩视频,或者直接从手机拿到视频呢。这里感谢下社区各位大佬的帮忙 基于 Scrcpy 的远程调试方案原来 stf 还可以这么玩 。 最后去研究了下 scrcpy 这个神奇的项目scrcpy,原来这个项目是用于 android 手机投屏使用,能直接从手机获取 H264 格式的视频流,最后使用 FFmpeg 在 PC 上解析 H264 视频流直接成像。我将其 scrcpy 中的获取 android 的 jar 包合入 STFServer.apk 中整合成一个 apk,然后将获取 H264 视频流直接映射至网页再解析最后绘制在 canvas 上。


  • 说下效果,简直是爽歪歪。优点有其三,在 APK 里直接限制流量输出、FPS 能突破 minicap 的极限、minicap 不兼容的 miui11 以上版本也能正常使用,解决公司异地分部使用真机云的难题。


画面静止时一帧大小也就 7~8k 左右,快速滑动一帧大小 10k~20k 左右。是不是爽歪歪。

  • 视频流与 Appium 结合

既已是视频流了那岂不是能存储起来,像播放视频一样回放。这一念头促使我深入研究了 appium 将视频流与自动化结合,助力我司 UI 自动化。下次有时间和大家分享视频流在我司自动化领域的实践。

共收到 24 条回复 时间 点赞

牛掰啊,这个解决问题的思路

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

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

咸鱼菜鸡 回复

minicap 只是控制图片的压缩比例、以及图片发送次数,图片发送次数少会直接影响流畅度。 研究下 H264,就能明白为何视频流方式为何优与图片流

请教大佬,你们公司的云真机,集成了 ios 吗,如果集成了是什么方案,是不是和之前那个虎牙大佬分享的一样,是用 webdriveragent 的思路

黑山老妖 回复

也是走视频流方式,图片编译成视频流然后传出来。带宽可控效果可以参考 UC 岩鼠

咸鱼菜鸡 回复

视频可以跨帧压缩 所以带宽占用小,我们是 4 个设备连接一个电脑,minicap 每帧图片都全量传的话有点吃不消.

leoche 回复

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

好文章啊👏

leoche #10 · 2021年04月25日 Author
咸鱼菜鸡 回复

截图方式输出图片大小随着屏幕分辨率不同,带宽占用极其不稳定波动异常大。 如果只考虑内网使用还好,跨网段甚至跨地域那不行了

leoche 回复

等有时间我研究一下

不错哦,jar 提取部分,希望希望能细说下。😀

请展开细说😀

leoche #14 · 2021年04月27日 Author

最近有点忙,有空展开细说

是客户端直接发送 h264 流, 然后由 web 端 进行解码 吗 , 我们目前是 直接在 客户端 转成图片在 发给 web

leoche #17 · 2021年04月27日 Author
哲豪 回复

对的,是直接客户端发送 h264 流

leoche 回复

请教下, 你们是 把流 给 后台先处理成图片 在给 web 渲染, 还是 直接让 web 解析 渲染啊

leoche #19 · 2021年04月27日 Author
哲豪 回复

流处理成图片,不是又回到 minicap 的思路了吗。是直接在 web 端渲染

leoche 回复

直接在 web 端的话, 是 自己 写的 插件? 还是 硬解啊

基本上都是走的 scrcpy 转换成视频流方案,前端采用视频流进行播放,这样肯定节约带宽。

"然后将获取 H264 视频流直接映射至网页再解析最后绘制在 canvas 上"大佬能详细讲讲这部分吗👃 ,前端解析 h264 流是怎么弄的,目前用的https://github.com/MarkRepo/wfs.js解析,虽然能拿到画面,但是浏览器兼容性不太行

24楼 已删除

老哥 有开源项目参考下吗

需要 登录 后方可回复, 如果你还没有账号请点击这里 注册