(23)-设备分类
最后更新于：2022-04-01 06:55:12
[上一篇文章](http://testerhome.com/topics/1858)已经讲了cts如何自动检测到设备，效果就是无需我们再去调用`ADB`的`getIDevice()`得到设备,利用的是ADB中提供的观察者模式做到了这一点，那么得到设备后我们如何对这些设备进行管理的呢？
# 设备分类
cts中将设备分为3种状态：处于验证中的设备，可用设备，执行任务的设备。这三种状态的设备分别用3个集合保存：
~~~
//处于验证中的设备集合
private Map<String, IDeviceStateMonitor> mCheckDeviceMap;
//可用设备的集合
private ConditionPriorityBlockingQueue<IDevice> mAvailableDeviceQueue;
//执行任务的设备集合
private Map<String, IManagedTestDevice> mAllocatedDeviceMap;
~~~
## 1.处于验证中的设备集合
`mCheckDeviceMap`是一个`Map`，`key`值表示设备的`SN`号，`value`值表示当前设备的状态监听器对象`IDeviceStateMonitor`(以后会讲到)。当一个新设备被检测的时候会首先放到该Map中，然后会调用`IDeviceStateMonitor`.`waitForDeviceShell(final long waitTime)`来对设备进行一个扫描，扫描通过以后，就会将设备添加到可用设备集合`mAvailableDeviceQueue`中。但是不管扫描成不成功，经过检测步骤后，都会从`mCheckDeviceMap`设备集合中删除该设备。所以可以说该容器这是临时存放设备用的，为的是对设备进行验证是否可用，就像机场里过安检一样。
## 2.可用的设备集合
`mAvailableDeviceQueue`是一个[优先队列](http://baike.baidu.com/view/1267829.htm)，且是线程安全的，这是`cts`自定义的一个队列数据结构。你可以传入条件选择设备，比如按设备号选择，按平台号选择都可以。返回的是一个`IDevice`对象，这是原生的`ADB`中定义的接口类。该集合是一个中间集合，它从`mCheckDeviceMap`中得到集合，然后等到用户使用设备后，就将集合中的某个元素"送给"了执行任务的设备集合`mAllocatedDeviceMap`。
## 3.执行任务的设备集合
`mAllocatedDeviceMap`集合是一个Map，`key`值表示设备的`SN`号，`value`值表示的是cts自己定义的设备对象的接口`IManagedTestDevice`。当用户选择一个可用设备后，是从可用设备集合`mAvailableDeviceQueue`中得到了一个`IDevice`,然后`cts`使用外观模式，将其封装到了继承自`IManagedTestDevice`接口的对象`TestDevice`(这个类很重要，以后会单独讲)中，里面有很多关于设备的方法可以被调用，那么用户实际能操作就是这个`TestDevice`类。等待任务完成后，该设备将“送还”到可用设备集合中，这只是一个借用的过程，用完了就还给了它，这样的话这个设备还可以继续执行其他任务。
## 4.总结
通过上面的介绍，我们用一幅图来描述一下3个集合之间的关系。
# 检测设备后分类
终于到了揭晓庐山真面目的时候，以上的种种解释，包括第一篇文章的铺垫，都是为了下面的内容铺垫的，讲代码的东西就是这么的麻烦。先上代码：
~~~
private class ManagedDeviceListener implements IDeviceChangeListener {
/**
* {@inheritDoc}
*/
@Override
public void deviceChanged(IDevice device, int changeMask) {
IManagedTestDevice testDevice = mAllocatedDeviceMap.get(device.getSerialNumber());
if ((changeMask & IDevice.CHANGE_STATE) != 0) {
if (testDevice != null) {
TestDeviceState newState = TestDeviceState.getStateByDdms(device.getState());
testDevice.setDeviceState(newState);
} else if (mCheckDeviceMap.containsKey(device.getSerialNumber())) {
IDeviceStateMonitor monitor = mCheckDeviceMap.get(device.getSerialNumber());
monitor.setState(TestDeviceState.getStateByDdms(device.getState()));
} else if (!mAvailableDeviceQueue.contains(device) && device.getState() ==IDevice.DeviceState.ONLINE) {
checkAndAddAvailableDevice(device);
}
}
}
/**
* {@inheritDoc}
*/
@Override
public void deviceConnected(IDevice device) {
CLog.d("Detected device connect %s, id %d", device.getSerialNumber(), device.hashCode());
IManagedTestDevice testDevice = mAllocatedDeviceMap.get(device.getSerialNumber());
if (testDevice == null) {
if (isValidDeviceSerial(device.getSerialNumber()) && device.getState() == IDevice.DeviceState.ONLINE) {
checkAndAddAvailableDevice(device);
} else if (mCheckDeviceMap.containsKey(device.getSerialNumber())) {
IDeviceStateMonitor monitor = mCheckDeviceMap.get(device.getSerialNumber());
monitor.setState(TestDeviceState.getStateByDdms(device.getState()));
}
} else {
// this device is known already. However DDMS will allocate a
// new IDevice, so need
// to update the TestDevice record with the new device
CLog.d("Updating IDevice for device %s", device.getSerialNumber());
testDevice.setIDevice(device);
TestDeviceState newState = TestDeviceState.getStateByDdms(device.getState());
testDevice.setDeviceState(newState);
}
}
private boolean isValidDeviceSerial(String serial) {
return serial.length() > 1 && !serial.contains("?");
}
/**
* {@inheritDoc}
*/
@Override
public void deviceDisconnected(IDevice disconnectedDevice) {
if (mAvailableDeviceQueue.remove(disconnectedDevice)) {
CLog.i("Removed disconnected device %s from available queue",disconnectedDevice.getSerialNumber());
}
IManagedTestDevice testDevice = mAllocatedDeviceMap.get(disconnectedDevice.getSerialNumber());
if (testDevice != null) {
testDevice.setDeviceState(TestDeviceState.NOT_AVAILABLE);
} else if (mCheckDeviceMap.containsKey(disconnectedDevice.getSerialNumber())) {
IDeviceStateMonitor monitor = mCheckDeviceMap.get(disconnectedDevice.getSerialNumber());
monitor.setState(TestDeviceState.NOT_AVAILABLE);
}
updateDeviceMonitor();
}
}
~~~
上面的代码我在第一篇文章中有涉及，只是那个时候我把三个监听方法里的具体实现给隐藏了，现在终于把它展现出来了。
## deviceChanged方法
该方法会在设备连接的时候调用，但是我们做了个判断，就是设备状态的改变，那就说明该设备连接前`ADB`已经知道了该设备的存在，只是它与之前的状态发生了变化，所以在设备第一次连接的时候，该方法里的代码块是不会被调用的。那么再具体说说操作步骤：
`1`.首先判断设备的改变是否是状态的改变，因为设备的变化很有多种，我们需要关心的设备于PC连接状态的改变，所以需要做判断。
`2`.然后从`mAllocatedDeviceMap`集合中尝试获得发生改变的设备，这一步是为了检查是否会影响到执行任务的设备。因为在任务执行过程中，不是每时每刻都能去检测状态，所以cts采用的是被动判断，如果状态发生改变，需要通知正在执行任务的设备监听器，由监听器去做相应的处理。
`3`.如果确定状态发生改变的设备是正在执行任务的设备，就需要将其状态设置为新状态。
`4`.如果不是正在执行任务的设备，那么再去验证是否属于另外2个集合中的设备。
`5`.如果是检测集合`mCheckDeviceMap`中的元素，那么也要重新设置设备状态，不过这个时候是从检测设备集合中得到设备再改变它的状态。
`6`.如果改变的设备既不是执行任务的设备，也不是检测中的设备，这个时候我们要判断是否是新设备，这个时候可能有人会有疑问？为什么不判断是否存在于可分配设备中呢？这得从`deviceChanged`的调用机制来说，`deviceChanged`只在设备连接进来的时候会调用，设备掉线的时候该方法不会被调用，那么自然这个里面无需判断是否是可分配设备中。只需要判断传进来的`IDevice`的状态是否在线且不在可分配设备列表中，这个时候就要按新设备来处理啦。另外判断是否在该集合中是需要在`deviceDisconnected`中判断的。
## deviceConnected方法
这个方法会在有设备连接的时候调用，不管是新设备还是旧设备。它的处理步骤如下：
`1`.首先判断该设备是否正在执行任务，如果正在执行任务，`ok`！我们需要更新该设备的状态。如果不是进入第二步:
`2`.如果在线且通过判断其`SN`号是可用的，如果条件不通过，跳到第三步，如果通过的话，这个时候需要进行操作判断是否可以放到可用设备集合中。
`3`.是否存在于检测设备集合中，如果存在就将其设备更新下。
## deviceDisconnected方法
这个方法会在设备离线的时候调用，
`1`.首先试着从可用集合中删除该设备，然后进入第二步。
`2`.剩下的处理方式和上面的`deviceConnected`一样。
# 总结
设备管理的复杂性较之我所讲的，我所能说的也只是皮毛，希望对此有兴趣研究研究源码。提示一下，在研究源码之前先了解一下23种设计模式中常用模式，对你的理解会很有帮助。