关于android:8分钟带你了解-OpenSTF

1 什么是 STF

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

• 用户能够通过浏览器近程操作操作，调试手机利用，在设施上进行测试，实现真正意义的云端应用，调试，测试，治理真机。
• 可近程调试超过 160 多个设施，为搭建机器提供了很好的形式
• github 上 1 万多的 star https://github.com/DeviceFarm…

<br/>

相似产品：

• 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 型数据库，它有十分多的毛病，比方解决大量数据时的性能很差，材料十分匮乏，排查问题和数据库保护都十分艰难。

4.7 装置的坑

• node.js 只反对 8.x 版本的，所以能够用 nvm 来治理 node.js 的版本，装置多个 node.js
• 设施始终显示 disconnect 或者 preparing，之后 disconnect，这是他们的一个 bug，当数据线很差当时候会呈现。换一条数据线。
• 小米设施须要 sim 卡关上通过 usb 装置的权限才能够
• 如果在 docker 上装置，最好是 linux 零碎，mac 上能够装一个 linux 虚机来装置

参考：
因为参考的文章切实是太多了，没法一一列举进去，敬请体谅