在上篇文章Appium执行示例中把Appium的日志保存在了本地，接下来分析一下，Appium到底是如何工作的，打开保存在本地D盘的log日志文件开始分析
1.Appium服务启动默认端口为4723，这个端口是可以在启动Appium服务时自定义的，没有其他业务占用4723端口的话使用默认就好；然后可以看到日志保存的位置以及日志的等级。
2.在Eclipse运行代码，开始打印下面的日志；根据desiredCapabilities设置的所有参数值，并根据这个设置创建一个Appium Session，这个Session是唯一的，它用于接下来与客户端保持通信使用
3.根据aapt.exe工具得到apk的apckage、主Activity；如果在代码中通过desiredCapabilities设置了apk的apckage、主Activity，这一步就会被省略。
4.然后使用adb工具查看连接的设备；然后根据代码配置的udid，检查这台设备的准备情况，准备好后打印“echo 'ready'”
5.获取目标设备的API等级，25对应的是Android 7.1系统，不同的目标机器得到的API可能会不同
6.解析设置置语言，安装前重置等等操作；然后把app名字做了一层MD5加密，所以在后面不会再次出现apk的名字，而是这串MD5加密的名字。（有个报错是因为APK的原因，由于本人对于APP开发是临时抱佛脚，但这并不影响appium的执行，后续修复）
7.通过命令得到/data/local/tmp下面的apk的package，然后检查这个App是否安装，得到结果是没有安装则开始Installing App，开始安装App有一些处理，会先romove移除旧的apks并执行uninstalling卸载操作，都是为了安装app做准备的一些命令操作保证安装环境是干净的。然后开始安装。（这里顺便提一下/data/local/tmp这个目录一直出现，是由于没有ROOT的设备，这个目录是唯一不需要root权限可以访问的device目录）
8.完成appium服务的4724端口与设备4724端口完成转发，简单的说就是把Appium服务机器上的4724端口与设备端4724端口完成对接，接下来需要通过这个端口来通信。这个后面总结的时候再来看会更清晰。
9.推送AppiumBootstrap.jar到设备端，这个非常重要，后面文章会继续说这个Bootstrap到底是什么东东。然后推送Unicode IME、Setting、Unlock三个APK到设备端，可以发现在设备端安装了Appium Setting、Unlock两个APP。
10.杀掉全部关于uiautomator的运行，并且使用adb执行shell再次查看保证uiautomator没有运行；在设备端运行AppiumBootstrap，并启动一个Socket服务，监听4724端口。
11.通过adb在设备端运行app，并且准备好接下来的命令，设置超时时间为60秒。
12.开始发送请求，首先查找元素，得到响应找到Element元素1，然后请求点击操作，响应点击成功，完成操作。
13.遇到quit()方法或者60S后没有请求，开始收尾；先按下HOME回到首页，关闭logcat、关闭uiautomator、并且Appium服务删除session成功。
从上面的过程中其他的一些交互都很好理解，过程中推送了bootstrap.jar到底有什么用呢？Bootstrap.jar是Appium运行在安卓目标测试机器上的一个UiAutomator测试脚本，该脚本的唯一一个测试方法所做的事情是在目标机器开启一个socket服务器来把一个session中Appium从PC端过来的命令发送给UiAutomator来执行处理。
这个定义说明了bootstrap在appium和uiautomator中究竟处于一个什么样的角色：
首先，它是一个uiautomator的测试脚本，它的入口类Bootstrap继承于UiAutomatorTestCase，所以UiAututomator可以正常运行它，它也可以正常的使用uiautomator的方法，这个就是appium的命令可以转换成uiautomator的命令的关键
其次，它是一个socket服务器，它专门监听4724端口过来的appium的连接和命令数据，并把appium的命令转换成uiautomator的命令来让uiautomator进行处理最后，它处理的是appium从pc端过来的命令。
