3. 建立Appium Server和Bootstrap的连接

Appium.prototype.invoke = function (cb) {   this.sessionId = UUID.create().hex;   logger.debug('Creating new appium session ' + this.sessionId);    if (this.device.args.autoLaunch === false) {     ...      } else {     // the normal case, where we launch the device for folks      var onStart = function (err, sessionIdOverride) {       if (sessionIdOverride) {         this.sessionId = sessionIdOverride;         logger.debug("Overriding session id with " +                     JSON.stringify(sessionIdOverride));       }       if (err) return this.cleanupSession(err, cb);       logger.debug("Device launched! Ready for commands");       this.setCommandTimeout(this.desiredCapabilities.newCommandTimeout);       cb(null, this.device);     }.bind(this);      this.device.start(onStart, _.once(this.cleanupSession.bind(this)));   } };

onStart是启动连接上设备后的回调，重要的是最后面的一行，从上一节我们知道appium现在保存的设备类其实已经是Android类了，它调用device的start其实就是调用了Android实例的start，我们跳到/devices/android/android.js看下这个start做了什么：

Android.prototype.start = function (cb, onDie) {   this.launchCb = cb;   this.uiautomatorExitCb = onDie;   logger.info("Starting android appium");    if (this.adb === null) {     this.adb = new ADB(this.args);   }    if (this.uiautomator === null) {     this.uiautomator = new UiAutomator(this.adb, this.args);     this.uiautomator.setExitHandler(this.onUiautomatorExit.bind(this));   }    logger.debug("Using fast reset? " + this.args.fastReset);   async.series([     this.prepareDevice.bind(this),     this.packageAndLaunchActivityFromManifest.bind(this),     this.checkApiLevel.bind(this),     this.pushStrings.bind(this),     this.processFromManifest.bind(this),     this.uninstallApp.bind(this),     this.installAppForTest.bind(this),     this.forwardPort.bind(this),     this.pushAppium.bind(this),     this.initUnicode.bind(this),     this.pushSettingsApp.bind(this),     this.pushUnlock.bind(this),     this.uiautomator.start.bind(this.uiautomator),     this.wakeUp.bind(this),     this.unlock.bind(this),     this.getDataDir.bind(this),     this.setupCompressedLayoutHierarchy.bind(this),     this.startAppUnderTest.bind(this),     this.initAutoWebview.bind(this)   ], function (err) {     if (err) {       this.shutdown(function () {         this.launchCb(err);       }.bind(this));     } else {       this.didLaunch = true;       this.launchCb(null, this.proxySessionId);     }   }.bind(this)); };

这个方法很长，但做的事情也很重要：

• 建立adb，代码跟踪进去可以见到建立adb不是在appium server本身的源码里面实现的，调用的是另外一个叫"appium-adb"的库，我手头没有源码，所以就不去看它了，但是不用看我都猜到是怎么回事，无非就是像本人以前分析《MonkeyRunner源码分析之启动》时分析chimpchat一样，把adb给封装一下，然后提供一些额外的方便使用的方法出来而已
• 创建uiautomator这个底层与bootstrap和目标机器交互的类的实例，既然需要和目标机器交互，那么刚才的adb时必须作为参数传进去的了。大家还记得上面提到的在初始化Android这个设备类的时候uiautomator这个变量时设置成null的吧，其实它是在这个时候进行实例化的。这里有一点需要注意的是systemPort这个参数，appium server最终与bootstrap建立的socket连接的端口就是它，现在传进来的就是

var UiAutomator = function (adb, opts) {   this.adb = adb;   this.proc = null;   this.cmdCb = null;   this.socketClient = null;   this.restartBootstrap = false;   this.onSocketReady = noop;   this.alreadyExited = false;   this.onExit = noop;   this.shuttingDown = false;   this.webSocket = opts.webSocket;   this.systemPort = opts.systemPort;   this.resendLastCommand = function () {}; };

• 往下我们会看到nodejs流程控制类库async的另外一个对象series，这个有别于上面用到的queue，因为queue时按照worker的数量来看同时执行多少个task的，而series时完全按顺序执行的，所以叫做series
• 这个series 要做的事情就多了，主要就是真正运行时的环境准备，比如检查目标及其api的level是否大于17，安装测试包，bootstrap端口转发，开始测试目标app等，如果每个都进行分析的话大可以另外开一个系列了。这个不是不可能，今后看我时间吧，这里我就分析跟我们这个小节密切相关的uiautomator.start这个方法，其实其他的大家大可以之后自行分析。

往下分析之前大家要注意bind的参数

    this.uiautomator.start.bind(this.uiautomator), 

大家可以看到bind的参数是当前这个Android实例的uiautomator这个对象，所以最终start这个方法里面用到的所有的this指得都是Android这个实例的uiautomator对象。

UiAutomator.prototype.start = function (readyCb) {   logger.info("Starting App");   this.adb.killProcessesByName('uiautomator', function (err) {     if (err) return readyCb(err);     logger.debug("Running bootstrap");     var args = ["shell", "uiautomator", "runtest", "AppiumBootstrap.jar", "-c",         "io.appium.android.bootstrap.Bootstrap"];      this.alreadyExited = false;     this.onSocketReady = readyCb;      this.proc = this.adb.spawn(args);     this.proc.on("error", function (err) {       logger.error("Unable to spawn adb: " + err.message);       if (!this.alreadyExited) {         this.alreadyExited = true;         readyCb(new Error("Unable to start Android Debug Bridge: " +           err.message));       }     }.bind(this));     this.proc.stdout.on('data', this.outputStreamHandler.bind(this));     this.proc.stderr.on('data', this.errorStreamHandler.bind(this));     this.proc.on('exit', this.exitHandler.bind(this));   }.bind(this)); };

UiAutomator的实例在启动的时候会先通过传进来的adb实例spawn一个新进程来把bootstrap给启动起来，启动的详细流程这里就不谈了，大家可以看本人之前的文章《 Appium Android Bootstrap源码分析之启动运行》

UiAutomator.prototype.outputStreamHandler = function (output) {   this.checkForSocketReady(output);   this.handleBootstrapOutput(output); };

很简短，仅仅两行，第二行就是刚才说的去处理bootstrap本应打印到命令行的其他标准输出。而第一行比较特殊，注意它的输入参数也是ouput这个标准输出数据，我们进去看看它要干嘛：

UiAutomator.prototype.checkForSocketReady = function (output) {   if (/Appium Socket Server Ready/.test(output)) {     this.socketClient = net.connect(this.systemPort, function () {       this.debug("Connected!");       this.onSocketReady(null);     }.bind(this));     this.socketClient.setEncoding('utf8');     ...   } }; 

它做的第一件事情就是去检查启动bootstrap 的时候标准输出有没有"Appium Socket Server Ready"这个字符串，有就代表bootstrap已经启动起来了，没有的话这个函数就直接finish了。

uiautomator runtest AppiumBootstrap.jar -c io.appium.android.bootstrap.Bootstrap

输入如下，果不其然：

    this.socketClient = net.connect(this.systemPort, function () { 

UiAutomator实例，也就是Android类实例的uiautomator对象，所拥有的socketClient就是appium server专门用来与bootstrap通信的实例。这里的this.systemPort就是4724，至于为什么，我就不回答了，大家去再跟踪细点就知道了

4. 往Bootstrap发送命令

既然任务队列已经初始化，与boostrap通信的socket也建立妥当了，那么现在就是时候看一个实例来看下appium server是如何在接受到appium client的rest命令后，往bootstrap那边去灌命令的了。
开始之前我们先看下debug log，看下appium client端发送过来的命令及相关的输出：

info: --> POST /wd/hub/session/ae82c5ae-76f8-4f67-9312-39e4a52f5643/element/2/click {"id":"2"}

那么我们参照路由routing表查找到对应的处理controller：

rest.post('/wd/hub/session/:sessionId?/element/:elementId?/click', controller.doClick);

对应的处理方法是controller.doClick。注意这里前面一部分是http request的body，后面一部分是params。

• sessionId：ae82c5ae-76f8-4f67-9312-39e4a52f5643
• elementId: 2

从这些参数我们可以知道appium client端需要appium server帮忙处理的事情是：请在当前这个session中点击当前界面的bootstrap那边的控件哈稀表键值为2的控件（至于控件哈稀表这个概念如果不清楚的劳烦你先去看下本人的这篇文章《 Appium Android Bootstrap源码分析之控件AndroidElement》）

exports.doClick = function (req, res) {   var elementId = req.params.elementId || req.body.element;   req.device.click(elementId, getResponseHandler(req, res)); };

第一行是把client传送过来的控件在bootstrap中的控件哈稀表key解析出来，至于为什么需要传两个一样的值然后进行或，我还没有看appium client端的代码，所以这里解析不了，也许今后有时间分析client代码的话会给大家说明白。但在这里你只需要知道这个elementId是怎么回事做什么用的就够了，这个不影响我们去理解appium server的运行原理。

req.device = appium.device;

而appium.device对象又是在第2节在start Appium实例时通过其configuration等一系列调用中初始化的，最终在我们安卓环境中就是初始化成Android这个设备类的实例,而Android这个类又extend了android-controller.js里面的所有方法：

... , androidController = require('./android-controller.js') ... _.extend(Android.prototype, androidController);

所以最终的click落实到了android-controller.js里面也就是androidController对象的click方法：

androidController.click = function (elementId, cb) {   this.proxy(["element:click", {elementId: elementId}], cb); };

只有一行，调用的是proxy这个方法，跳进去：

exports.proxy = function (command, cb) {   logger.debug('Pushing command to appium work queue: ' + JSON.stringify(command));   this.push([command, cb]); };

所做的事情就是直接把刚才那传命令作为一个task来push到上面提到的async.queue这个Apium Work Queue里面。

Android.prototype.initQueue = function () {   this.queue = async.queue(function (task, cb) {     var action = task.action,         params = task.params;      this.cbForCurrentCmd = cb;      if (this.adb && !this.shuttingDown) {       this.uiautomator.sendAction(action, params, function (response) {         this.cbForCurrentCmd = null;         if (typeof cb === 'function') {           this.respond(response, cb);         }       }.bind(this));     } else {       this.cbForCurrentCmd = null;       var msg = "Tried to send command to non-existent Android device, " +                  "maybe it shut down?";       if (this.shuttingDown) {         msg = "We're in the middle of shutting down the Android device, " +               "so your request won't be executed. Sorry!";       }       this.respond({         status: status.codes.UnknownError.code       , value: msg       }, cb);     }   }.bind(this), 1); };

取得传进来的task相关键值，在我们这个例子中就是：

• action:"element:click"
• params:"{elementId:2"}

UiAutomator.prototype.sendAction = function (action, params, cb) {   if (typeof params === "function") {     cb = params;     params = {};   }   var extra = {action: action, params: params};   this.sendCommand('action', extra, cb); };

将参数组合成以下并传给sendCommand：

• 参数1:‘action’
• 参数2:'{action:action,parames:{elementId:2}'

UiAutomator.prototype.sendCommand = function (type, extra, cb) {     ...  else if (this.socketClient) {     ...     var cmd = {cmd: type};     cmd = _.extend(cmd, extra);     var cmdJson = JSON.stringify(cmd) + "\n";     this.cmdCb = cb;     var logCmd = cmdJson.trim();     if (logCmd.length > 1000) {       logCmd = logCmd.substr(0, 1000) + "...";     }     this.debug("Sending command to android: " + logCmd);     this.socketClient.write(cmdJson);   }      ... } 

根据传进来的参数，最终组合成以下参数通过第3节初始化好的与bootstrap进行socket通信的socketClient来往bootstrap灌入命令：

• {"cmd":"action","action":element:click","params":{"elementId":"2"}}

5. 小结

通过本文我们了解了appium server作为bootstrap的客户端，同时又作为appium client的服务器端，是如何处理从client来的命令然后组建成相应的json命令字串发送到bootstrap来进行处理的：

• 初始化REST路由表来接收appium client过来的REST命令调用并分发给相应的controller方法来进行处理
• appium client发送命令之前会先触发一个创建session的请求，在路由表表现为“rest.post('/wd/hub/session', controller.createSession);”。对应的controller处理方法会开始初始化与bootstrap的连接
• 创建的session的过程会调用Appium类的start方法然后机型一系列的动作：
  • 初始化设备类Android
  • 用Async库的queue对象初始化Appium的Work Queue
  • 创建adb实例并启动adb
  • 安装测试apk
  • 通过adb启动bootstrap
  • 建立Appium Server和bootstrap的socket连接
  • ...,等等等等
• 创建好连接后Appium Server就会接收client过来的命令，比如click，然后对应的controller处理方法就会建立命令对应的task并把它push到async queue里面
• 一旦有新task进入到async queue，对应的回调函数就会触发，开始往已经建立的与bootstrap的socket连接发送json字串命令