configure首先会去调用Appium类的getDeviceType这个方法，而这个方法最终又会去调用getDeviceTypeFromPlatform这个方法：
Appium.prototype.getDeviceTypeFromPlatform = function (caps) {
var device = null;
switch (caps) {
case 'ios':
device = DT_IOS;
break;
case 'android':
device = DT_ANDROID;
break;
case 'firefoxos':
device = DT_FIREFOX_OS;
break;
}
return device;
};
可以看到我们支持的platform就三个，所以我们在测试脚本设置capabilities选项的时候别填错了：
ios
android
firefox
最终返回的device定义如下，其实就是一些对应的字串：
var DT_IOS = "ios"
, DT_SAFARI = "safari"
, DT_ANDROID = "android"
, DT_CHROME = "chrome"
, DT_SELENDROID = "selendroid"
, DT_FIREFOX_OS = "firefoxos";
但是别小看这些字串，我们下面会看到就是通过他们来实例化对应的设备类的。
在获得deviceType后，configure方法下一个重要的步骤就是去根据这个deviceType字串去调用getNewDevice这个方法获得或者叫做创建一个对应的设备对象了：
Appium.prototype.getNewDevice = function (deviceType) { var DeviceClass = (function () { switch (deviceType) { case DT_IOS: return IOS; case DT_SAFARI: return Safari; case DT_ANDROID: return Android; case DT_CHROME: return Chrome; case DT_SELENDROID: return Selendroid; case DT_FIREFOX_OS: return FirefoxOs; default: throw new Error("Tried to start a device that doesn't exist: " + deviceType); } })(); return new DeviceClass(); }; |
DeviceClass这个变量是通过匿名函数返回的一个别的地方export出来的一个对象，比如以DT_ANDROID这个deviceType为例子，它返回的是Android，而Android的定义是：
, Android = require('./devices/android/android.js')
而android.js导出来的其实就是Android这个类：
var Android = function () {
this.init();
};
...
module.exports = Android;
最终getNewDevice这个方法通过new DeviceClass()对设备类进行实例化，事实上就是相当于new Android()，在我们这个例子中。那么在实例化Android这个设备类的时候其构造函数调用init方法又做了什么事情呢？
Android.prototype.init = function () {
...
this.args.devicePort = 4724;
...
this.initQueue();
...
this.adb = null;
...
this.uiautomator = null;
...
}
Android类的init方法会初始化一大堆成员变量，在这里我们列出几个我们这篇文章需要关注的：
args.devicePort:指定我们pc端forward到bootstrap的端口号4724
adb:Android Debug Bridge实例，初始化为null，往后很进行设置
uiautomator:初始化为空，往后会设置成uiautomator类的实例，转本处理往bootstrap发送接收命令的事情
当中还调用了一个initQueue方法来把Appium的Work Queue给初始化了,这个Work Queue其实就是nodejs的async这个库的queue这个流程控制对象。首先，我们要搞清楚我们为什么需要用到这个queue呢？我们知道nodejs是异步执行框架的，如果不做特别的处理的话，我们一下子来了几个命令如“1.点击按钮打开新页面；2.读取新页面读取目标控件内容和预期结果比较”，那么nodejs就会两个命令同时执行，但不保证谁先占用了cpu完成操作，那么问题就来了，如果在准备执行1之前，cpu调度切换到2，那么我们的脚本就会失败，因为我们1还没有执行完，新页面还没有打开！
而async这个库的不同对象就是专门针对这些问题提供的解决办法，比如waterfals，auto，serials和queue等，其他的我暂时没有碰到，所以不清楚，至于queue是怎么运作的，我们摘录下网上的一个解析：
queue: 是一个串行的消息队列，通过限制了worker数量，不再一次性全部执行。当worker数量不够用时，新加入的任务将会排队等候，直到有新的worker可用。
这里worker决定了我们一次过能并行处理queue里面的task的数量，我们看下Appium的Work Queue的worker是多少：
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); }; |
从倒数第2行我们可以看到worker是1，也就是一次过appium只会处理一个task，其他push进去的task只能等待第一个task处理完。那么这样就清楚了，我们刚才提到的两个命令，只要保证1先于2入队列，那么在异步执行的nodejs框架中就能保证1会先于2而执行。
