【转载】原来stf还可以这样玩

*本文获得原作者授权转载

第一感觉

第一眼看下去, 非常清爽, 使用起来非常流畅, 进入真机几乎是秒开, 操作响应也非常及时, 而且右边的菜单区域还有不少他们扩展的功能, 他们家的iPhone使用起来还比较流畅, 总体使用起来, 感觉非常棒.

从技术的角度看看, 首先可以看出他们应该是基于openstf的

从消息的命名和前端的几个websocket连接, 看起来也是基于openstf去做的, 但可以看出他们在openstf的基础上做了很多扩展和优化.
例如这个stf后端与前端通信的主要的websocket:
wss://yanshu.effirst.com/socket.io/?EIO=3&transport=websocket
里面有十分多他们自己扩展的信息, 例如 webdebug.enable logcat.irmaStartSer 等.. 似乎都是对应云真机里面他们扩展的web调试 和 日志的功能的.

而且touch的消息也是与openstf一模一样, 可以断定, 他们也是基于openstf或者使用了openstf里面的minitouch.

另一个传输手机屏幕的websocket, 更惊喜了..

他们的屏幕数据传输量非常小...

对比我们自己的, 简直是差距太大了啊...

从devtools下面的16进制数据可以看出, 数据中都是0 0 0 1开头, 应该是使用了H264或者H265, 对比我们公司内部云测平台使用openstf的原生的方案, 数据量实在相差很大.

当前我们内部的云测平台, 手机屏幕的传输, 现在遇到的瓶颈主要有2个, 帧率和带宽. 我司的渣渣WIFI, 绝大部分情况下最大的下载速度, 也就只有2.5MB/s左右, 即使我们调低了minicap输出的图片质量, 在我们可以接受的画质下, 最终输出的图片质量一张也50KB左右, 如果到达30帧时, 就已经吃掉了我们的电脑一大半的带宽了, 再连个adb调试, 也比较吃力, 另外我们有一些国产机型, minicap的帧率最高只有不到16帧, 日常用起来体验还是能感觉到卡.

看到岩鼠的方案, 应该是和https://github.com/Genymobile/scrcpy的方案一样, 直接通过反射调用安卓的SurfaceControl私有API, 把屏幕传给MediaCodec, 由系统去做录屏, 最终编码成H264, 通过websocket发送给前端的video做展示. 使用这样的方式, 在画面快速变化时, 基本都可以达到60帧, 并且流量能通过编码器的码率控制, 由于视频的压缩方式优势, 视频流能极大的减少了带宽, 并且提供高达60帧, 也不用考虑带宽过大的问题. 这块对于我们优化minicap的方案, 提供了一个新的思路.

我也要把这个方案搬到我司的内部云测平台上~~~

非常方便的Web调试

另外很吸引的我功能就是调试的tab里面的内容, 细玩了一下, 居然能直接在在右边区域, 调试手机里面的网页... 这波操作非常6, 对于前端开发者来说, 非常方便.

更神奇的是, 居然iOS也能直接在网页通过devtools调试...而且体验还不差, safari该有的功能他也有.
平时我们调试iOS的网页, 都需要把手机插到自己mac, 使用mac的safari才能调. 至于他怎么做, 我不熟悉iOS, 还真不知道了...

这个web调试功能, 我绝对服气, 市面上还没看到有竞品可以做到.

先说这么多了, 下次再深挖一些岩鼠里面的一些更深入的技术细节, 我也要去规划一下我司内部的云测平台的优化计划.

免费试用岩鼠云设备平台

看了小编转载的文章，想不想赶快试用下岩鼠云真机呢？每天都有免费试用体验额度哦。复制下面链接到浏览器了解详情！
>>>点击访问岩鼠云设备平台<<<