OpenSTF概述以及组成架构解读

最新推荐文章于 2024-06-05 09:42:42 发布

嵌入式逍遥

最新推荐文章于 2024-06-05 09:42:42 发布

阅读量3.2k

点赞数 2

文章标签： openstf 云手机 stf adb Android

原文链接：https://segmentfault.com/a/1190000023580853

版权

1 什么是STF

STF（Smartphone Test Farm）是一个开源的web架构应用

用户可以通过浏览器远程操作操作，调试手机应用，在设备上进行测试，实现真正意义的云端使用，调试，测试，管理真机。
可远程调试超过160多个设备，为搭建机器提供了很好的方式
github上1万多的star https://github.com/DeviceFarm...

类似产品：

AWS Device Farm
Google Cloud Test Lab
百度MTC的远程真机调试
Testin的云真机
腾讯WeTest的云真机
阿里MQC的远程真机租用

其中OpenSTF是开源项目，其他的平台大多也都是基于OpenSTF原理实现的

2 为什么需要 STF

2.1 解决测试机的高效利用

大家都需要设备，要互相借，还要维护借的表格
大家在不同地区
android设备太多，而且一直有新的

2.2 提高测试效率

STF提供设备机的CPU，内存，电量等性能的监测
对接monkey
查看log
自动化测试

2.3 测试机器的管理

固化测试机器的系统版本，系统设置，不被篡改
追踪查看测试机设置的人员

3 STF 功能介绍

3.1 OS 版本支持

目前只支持android系统， android 2.3.3 (SDK level 10) to android 10 (SDK level 29)

3.2 通过浏览器远程控制

实时屏幕操作和显示。刷新速度可以达到每秒30-40帧，可以旋转屏幕（minicap）
支持从PC键盘输入到android设备
支持复制黏贴
支持多点触控（minitouch）
拖拽安装，launch apk文件
通过minirev，可以直接从Android设备的端口转发本地服务，即便不在一个网段。
可以使用任意浏览器访问
展示和过滤设备日志。
当设备连接到电脑上，且打开adb模式或在一个局域网时，就可以通过adb connnect远程连接调试。
可以访问设备的文件系统。

3.3 在web上管理160+设备

查看设备状态，可以看到设备的连接状态：连接、离线、不可用（连接信号比较弱）、未授权、未连接
查看谁在使用设备
可以通过手机号码、IMEI、ICCID、Android系统版本号、运营商、手机型号或者其它属性来搜索设备。
检测设备电量
展示硬件详情
提供API

https://github.com/DeviceFarm...
http://youripaddress:7100/api/v1/devices/

4 STF 架构介绍

4.1 平台语言

查页面html使用Pug模版引擎
前端使用的是Angularjs
后端使用的是Nodejs
数据库使用的是对象型数据库Rethinkdb

4.2 主要模块

STF的核心功能可以理解为：“同步图像” + “点击”。前者使用minicap完成，后者依赖minitouch。具体结构看下图

4.3 架构介绍

设备端

STF在会在android设备上安装minicap和minitouch。使用minicap来捕获屏幕和使用minitouch来触发多点触控事件，并通过adb使用socket在服务端和设备端进行数据传输。
STF还会在android设备上安装STFService.apk，它在设备后台运行，提供了一组socket api可以用来监控和执行不同的action。同理，它也是通过adb和服务端通信，不过它使用的是protocal buffer数据格式。
minirev，直接从Android设备的端口转发本地服务，即便不在一个网段

服务端

STF的服务端由多个不同的独立的，基于nodejs的微服务组成，这些服务之间是通过ZeroMQ通信。服务端可以进一步分成Provider 层和Application层

Provider 层

Provider层（stf-provider）主要负责和设备之间进行通信。
通过adb来监控设备状态，当有新的设备连接，或者有设备断开则会立刻监控到
如果是新的connect设备，则provider会folck一个新的nodejs进程（stf-device），这个进程主要负责与该设备的所有通信。
总体说，stf由两个部分组成，分别是stf-provider和adb
另外，需要注意的是，provider层的服务需要跑在物理机上，所有的设备需要连着这台物理机。

Application 层

application层则是由STF -api、STF -app和STF -auth等微服务组成，这些微服务组成了一个完整的STF
从部署的角度来看，这些服务可以跑在任意地方，唯一的要求就是，这些服务能够通过网络和provider通信。这也就是意味着他们需要在同一个网段上

Client 层

使用Angular JS实现
通过websocket与服务进行通信

4.4 对比美团云真机架构

Agent - 相当于stf的provider
消息中心 - 相当于stf的triproxy

连接手机和Server的枢纽，消息中心主要处理屏幕的操作以及手机的状态变更等消息

数据存储模块 - 相当于stf的RethikDB

数据存储模块用来保存整个平台的数据，例如手机的状态、用户使用记录等。 - RethikDB

Server模块 - 服务端，websocket，nignx

Server用来集中管理和调度手机，与OpenSTF结构不同的是，我们的Server端包含Web服务器、Websocket服务器、动态代理以及消息处理服务等部分，Server将用户的访问动态代理到对应的Web服务器和Websocket服务器上，并通过消息处理模块向消息中心传递消息，实现用户与Agent端手机的交互。

4.5 STF 中的消息传递

在STF中，只要用户点击按钮，这台手机会被标记为占用状态，其他用户立刻就能看到这个最新的状态。同时其他用户也没法使用这个手机。这种即时的消息传递不能靠普通的接口的方式进行，STF中主要是通过ZeroMQ和Protobuf来实现这种即时的消息传递。

4.5.1 ZeroMQ 用到的三个模式

push/pull是单向模式，消息只能由push端发出，由pull端进行拉取。一般来说pull端对消息进行处理，如果一个pull端不能及时处理，可以同时有多个pull端，这种情况下，一条消息只能被一个pull端拉取，拉过之后其他pull端就不能再次拉取。如果没有pull端拉取，消息过多的时候可能会溢出。
publish-subscribe这属于发布订阅模式。与push-pull所不同的，pub会向所有已经连接的sub发消息，如果没有sub连接，消息会被丢弃。
dealer/router是路由模式，适用于有多个发送端和多个接收端的情况，这样可以实现负载均衡。在stf中，同时有多个用户和多台手机在线，dealer-router很适用于这种情况下的消息传递。

4.5.2 Protocol Buffer

zeromq只是负责消息流的处理，而具体如何组织消息，则是通过其他的方式，stf使用了Protocol Buffer，它是Google的数据交换的格式，与protobuf类似的东西其实是json和xml，protobuff的优势在于更小的体积，这样在大量数据传输的时候节省了带宽资源。与json和xml所不同的是，protobuff自带了一个编译器，protoc，只需要用它进行编译，可以编译成JAVA、python、C++代码，简单来说，它可以生成对应语言的数据类型，比如说生成java的一个类等等。

4.5.3 Websocket

启动一个websocket，负责前端页面和服务端通信

4.5.4 Processer

连接了设备和前端页面的所有通信

4.5.5 Dev

设备单元：文档没有说明，不过看源码，这部分封装了对设备操作的逻辑，譬如实际的apk安装，touch操作，实时显示图像，调用adbkit安装app等逻辑。

4.5.6 Provider

给每个设备启动一个work process，负责和设备的通信

4.5.7 Reaper

reaper进程维护着一个TTLSet，主要负责对超过存活时间的设备进行收割

4.5.8 Triproxy

triproxy其实是一个三端的消息转发器，它包含三个端口，pull、pub和dealer，分别对应zmq的三种工作模式。triproxy模块最大的用途是模块的解耦。
的pull端用来拉取websocket模块或者provider模块的消息，之所以用pull的模式是因为消息从websocket或者provider到triproxy的消息传递是单向的，而push-pull模式可以保证消息传递的可靠性，就是说，如果pull端断开，push端的消息仍然会被保留而不会丢失，直到pull把消息拉走，例如，provider发现一台手机的在线状态发生了改变，就是通过push的方式推给triproxy。
而pub端则用来广播消息，广播的特点就是一个发送端可以对应多个接收端，这些接收端可以同时接收到消息，例如设备状态的改变需要广播给所有的websocket模块，进而广播给所有的在线用户。当然广播的另外一个特点是如果广播时客户端不在线，那么这条消息就永远收不到了，因此，广播的消息也可以说是不太重要的消息，比如说如果provider的一台手机没有收到用户占用的消息，最多是用户占用失败，而不会造成太大的影响，而provider占用成功的消息如果用广播的方式就麻烦了，用户没收到占用成功的消息，会继续做占用的操作而不会成功，除非手机超时自动取消占用。
triproxy和processor的通信是双向，因此用了dealer模式。dealer模式虽然可以一对多，但是一条消息只能唯一的传给一个接收方，就是说如果做了processor扩展，存在多个processor的情况下，同样的消息只会被一个processor处理，这点儿需要注意。

4.5.9 我们通过一个例子看下消息传递的过程。

看看stf是如何发现有新的设备连上usb的

设备连上usb
Provider 发现设备状态发生变化（监控add，change，remove）

client.trackDevices().then(function(tracker) {

  log.info('Tracking devices')

 ...}

Provider 通过zmq向processor发送一个protoBuf消息DeviceIntroductionMessage
Processor 进程收到DeviceIntroductionMessage
Processor 调用dbapi.saveDeviceInitialState()方法将消息中携带的设备信息保存到rethinkDB
Processor 向provider发送DeviceRegisteredMessage
Processor 将DeviceIntroductionMessage广播出去（websocket、reaper）
Websocket进程收到DeviceIntroductionMessage
通过websocket(协议)向前端发送一个’device.add'消息，前端页面会根据该消息更新设备连接状态。
Provider收到DeviceRegisteredMessage会通过flippedTracker发送一个以deviceId为消息名称的消息，参数为’register’（至此设备注册就算完成了，接下来就是启动device进程）
Provider 启动device进程，接下来就是设备和device进程之间的监听
device进程启动成功之后会向父进程发送一个message，内容是'ready'，表示device进程启动成功了，至此整个设备连接就已经完成了。

4.6 存在的问题

不同android设备的兼容性问题
本地 STF 内网穿透公网访问
provider启动多了，有点耗资源
如果对方忘记release 设备，设备会一直被占用，除非认为的把设备拔掉重新连接
如果是动态ip的话，会失败，所以需要申请static ip
不同地区如果网络弄不好的话，会延迟很厉害
OpenSTF使用RethikDB作为数据库，RethikDB是一个NoSQL型数据库，它有非常多的缺点，比如处理大量数据时的性能很差，资料非常匮乏，排查问题和数据库维护都非常困难。