读懂appium原理,看这篇就够了

Posted

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了读懂appium原理,看这篇就够了相关的知识,希望对你有一定的参考价值。

参考技术A 话不多说,直接上干货:

appium的整体架构是C/S模式,整体流程(返回顺序为逆向):

脚本请求 ——> 4723端口appium server ——> 解析参数给PC端4724端口 ——> 发送给设备4724端口 ——> 通过设备4724端口发给bootstrap.jar ——> Bootstrap.jar把命令发给uiautomator

1、脚本请求 ——> 4723端口appium server :

首先我们要开启appium服务,即Appium server,也就是在命令行用appium命令打开的东西,默认监听4723端口。4723端口专门和脚本打交道,基于WebDriver协议。webdriver是按照server – client的经典设计模式设计的,作用就是启动基于WebDriver Wire协议的appium服务,接下来脚本与appium server的通信实际上是一个HTTP request请求给appium server,在请求的body中,会以WebDriver Wire协议规定的 JSON 格式的字符串来告诉appium服务我们希望设备接下来做什么事情。读到这里,难免有同学会有疑问了,因为有一些文档上面说脚本发送请求是基于Json wire protocol协议的,首先这是完全正确的,接下来就解释一下:

appium中的Json wire protocol继承自selenium的webdriver wire protocol,并进行了扩展,使得Json wire protocol能够控制不同的移动设备的行为。如果大家觉得对于webdriver这个名词觉得比较陌生的话,接下来说一个词肯定熟悉 - Selenium。Selenium是一个浏览器自动化操作框架。Selenium主要由三种工具组成。第一个工具SeleniumIDE,是Firefox的扩展插件,支持用户录制和回访测试,录制/回访模式存在局限性,对许多用户来说并不适合,因此第二个工具——Selenium WebDriver提供了各种语言环境的API来支持更多控制权和编写符合标准软件开发实践的应用程序。最后一个工具——SeleniumGrid帮助工程师使用Selenium API控制分布在一系列机器上的浏览器实例,支持并发运行更多测试。在项目内部,它们分别被称为“IDE”、“WebDriver”和“Grid”。

那么webdriver wire protocol又是什么呢:

在我们创建一个WebDriver的过程中,Selenium首先会确认浏览器的native component是否存在可用而且版本匹配。接着就在目标浏览器里启动一整套Web Service,这套Web Service使用了Selenium自己设计定义的协议,名字叫做 The WebDriver Wire Protocol, 只不过对应到我们这里的浏览器指的是Appium。

WebDriver Wire协议是通用的,也就是说不管是FirefoxDriver还是ChromeDriver,启动之后都会在某一个端口启动基于这套协议的Web Service。对应到Appium,可以理解为是AppiumDriver。接下来,我们调用WebDriver的任何API,都需要借助一个 ComandExecutor 发送一个命令,实际上是一个HTTP request给端口上的Web Service。在我们的HTTP request的body中,会以WebDriver Wire协议规定的 JSON 格式的字符串来告诉Selenium我们希望浏览器(设备)接下来做什么事情。

说到这里可能会有疑问了,上面说到的是脚本请求对设备进行操作,但前提是,我们要对谁进行操作测试呢?这里就引入一个新名词:desiredCapabilities。了解了上述之后,再去看脚本怎么将desiredCapabilities传递给appium server就明白多了,脚本通过Json Wire Protocol协议以json格式发送测试设备信息给server端,测试设备信息被携带在Desired Capabilities中,这个东西实质上是一个key-value形式的对象,Desired Capabilities最重要的作用是告诉server本次测试的上下文。这次是要进行浏览器测试还是移动端测试?如果是移动端测试的话是android还是ios?如果android的话我们要测试哪个app?server的这些疑问Desired Capabilities都必须给予解答,否则server不买账,针对我们现在所说的安卓,它带来的影响就是无法完成app的启动。

那么,将测试设备信息告知之后,是不是就可以开始进行测试了呢?答案是:NO。这里又要引入一个名词:session。session就是一个会话,在webdriver/appium,你的所有工作永远都是在session start后才可以进行的。client 创建1个session,在该session中通过http向appium server发送请求,appium server解析请求,完成相应操作并返回response。

Session在计算机中,尤其是在网络应用中,称为“会话控制”。Session 对象存储特定用户会话所需的属性及配置信息,对应到这里其实就是desiredCapabilities中的配置信息参数。脚本通过POST /session这个URL,然后传入Desired Capabilities就可以开启session了,由于这是第一次请求创建session,所有并没有一个已创建的session id,所以appium server会调用android driver(appium升级到2.0.0后,原有的AppiumDriver函数变成抽象函数了,需更改为AndroidDriver)为client生成一个session并且生成一个与此session相关联的session id,这个 session id将被在本次响应中返回给客户端保存,当下次脚本发出操作请求时就会自带session id为唯一标识,代表所打开的设备,Appium server会按照此session id把这个session检索出来使用,脚本向appium server发送的请求即是存在于创建的session中的。

Session 的作用就是它在appium服务上保持设备的状态信息,供在任何时间进行访问,在多次的操作行为中,存储在 Session对象中的配置信息将不会丢失,而是在整个用户会话中一直存在下去,整个测试进程中设备与程序的联系不会断开,也不需要每次都发送带配置信息的请求,程序都知道对哪个设备进行测试操作。当测试结束后,需关闭webdriver,driver.quit()会关闭所有关联窗口和session,并且也会把进程也关闭。

2、解析参数给PC端4724端口 ——> 发送给设备4724端口 ——> 通过设备4724端口发给bootstrap.jar ——> Bootstrap.jar把命令发给uiautomator:

创建session成功之前,就已将bootstrap.jar放入手机中,并开启设备上的基于appium bootstrap的socket服务,绑定本机和boostrap通信的端口号4724用于和Android设备通讯,默认监听4724端口,等待client的连接。

Appium server将脚本的请求解析后给到4724端口,通过设备的4724端口转发解析后的请求, 此时,对于socket服务来说,appium server就充当了client的角色,appium server通过4724端口主动去请求设备上的socket服务,即向socket服务发送请求,即bootstrap.jar,Bootstrap.jar再把Appium的命令转换成uiautomator的命令来让uiautomator进行处理。有请求就有返回,socket接收到请求后会做出响应,原路返回给脚本,然后脚本再进行下一次的请求。

网络上的两个程序通过一个双向的通信连接实现数据的交换,这个连接的一端称为一个socket。appium和手机的通信过程,主要是数据交换的一个过程,socket的作用是就是为了实现双向通信,它需要一对端口号,对应到这里就是4724,手机端的bootstrap就是socket-server端,appium server就是socket-client端。

关于socket的通信原理,先从服务器端说起。服务器端先初始化Socket,然后与端口绑定(bind),对端口进行监听(listen),调用accept阻塞,等待客户端连接。在这时如果有个客户端初始化一个Socket,然后连接服务器(connect),如果连接成功,这时客户端与服务器端的连接就建立了。客户端发送数据请求,服务器端接收请求并处理请求,然后把回应数据发送给客户端,客户端读取数据,最后关闭连接,一次交互结束。

Handler原理剖析,看这篇就够了

Handler原理剖析,看这篇就够了

本篇文章将会对Handler进行深层次的剖析,结合关系剖析图、代码走向剖析图以及10个常见问题,希望看完文章的同学都能有所收获,加深对Handler的了解!

一、Handler运行原理剖析

1.关系剖析图


如果把整个Handler交互看做一个工厂,Thread就是动力MessageQueue是履带Looper是转轴Loooper的loop方法就是开关,当调用loop方法时整个工厂开始循环工作,处理来自send和post提交到MessageQueue的消息,每处理完一个后由Handler的dispatch分发出去

2.代码走向剖析图


以上代码走向图无论send还是post,最终都是通过Handler的enqueueMessage方法将消息放到MessageQueue中,线程调用loop方法后循环从MessageQueue的next方法中获取消息并进行处理,每处理完一个后由Handler的dispatchMessage分发再通过handleMessage方法回调出去

二、Handler常见问题解答

1.一个线程可以有多少Handler?

无数个,因为在任何地方都可以直接new

2.一个线程可以有几个Looper?你如何保证只有那么多个?

一个,因为源码中已经做了这种判断,在线程被创建时源码中会通过ThreadLocal进行线程与Looper的绑定,通过一个Object[]使前者为key后者为value依次向后,当我们在调用Looper的prepare方法去创建其时,源码中会去调用ThreadLocal的get去判断,如存在抛出异常,不存在则调用set进行创建绑定;如果是主线程,则源码已经在ActivityThread的main方法中为我们创建好了,所以我们可以直接在主线程中new和使用,子线程中却需要调用prepare和loop进行使用

3.Handler为什么会发生内存泄漏?为什么其他的内部类没有这个问题?

因为Java虚拟机中内部类默认持有外部类的引用,当Activity如果在无感知的情况下被销毁时,Handler如果还在执行某些耗时操作时,所以就会产生内存泄漏;这跟Handler的原理有关,因为源码中消息池每一个Message都持有一个target(Handler)对象,而这个target(Handler)对象都持有外部类的引用如Activity,所以其他内部类没有这个问题
拓展:可以通过static+weak reference或Handler的remove对应方法解决

4.为何主线程可以直接new Handler?如果子线程想要new Handler需要做些什么?

因为主线程在ActivityThread的main方法中已经创建了Looper,所以主线程使用Handler时可以直接new;子线程使用Handler时需要调用Looper的prepare和loop方法才能进行使用,否则会抛出异常

5.如果子线程中需要维护一个Looper,当消息队列中没有消息时会发生什么问题?怎么解决?这样解决有什么作用?

当子线程run方法体的业务逻辑执行完时会走到loop处,导致子线程死锁;可以通过调用Looper提供的quitSafely方法,最终调用MessageQueue的quit方法,传一个true即可,如false则抛出异常,感兴趣的小伙伴可以去看看源码,提示主线程不允许退出;作用是移除所有没有处理的消息然后唤醒native锁并且释放资源

6.如果存在多个Handler往MessageQueue中添加数据,因为发送消息时各个Handler可能处于不同的线程,那源码内部是如何实现线程安全的?

因为在源码中可以发现MessageQueue的enqueueMessage方法在将消息推入时将入了同步代码块,在next去消息时也加入了同步代码块,所以保证了Handler消息的通讯是线程安全的

7.我们使用Message时应该怎么样去创建它更合理?

使用obtain去创建Message最合理

8.使用Handler的postDelay等延时方法后消息队列会有什么变化?

会根据delay时间去进行一个时间排序,通过遍历单链表把delay消息插入到合适的位置,然后通过nativePollOnce进行休眠,如有新消息进入则调用nativeWake唤醒,然后再计算时间差进行休眠,直到msg.when >= now为止

9.Looper死循环为什么不会导致应用卡死?

loop循环的取出消息并分发,无消息时会阻塞在next()方法中nativePollOnce()代码行,并释放CPU资源进入休眠,Android的绝大部分操作都是通过Handler机制来完成的,如果没有消息,则不需要程序去响应,就不会发生卡死。应用卡死指的是ANR一般是消息处理过程中耗时太长导致没有及时响应用户的操作

10.源码中是如何对Message做优化的?使用的是什么Java设计模式?

源码中对Message进行了池化策略的优化,避免过多的创建Message对象;享元模式

以上是关于读懂appium原理,看这篇就够了的主要内容,如果未能解决你的问题,请参考以下文章

Handler原理剖析,看这篇就够了

Handler原理剖析,看这篇就够了

Handler原理剖析,看这篇就够了

Handler原理剖析,看这篇就够了

App测试工具大全,收藏这篇就够了!

RPC框架实现原理,看这篇就够了!