Appium Android Bootstrap source code analysis
This article will assume the role of introduction in the series and will not analyze any code. It will only give you a Basic impression, it is convenient for you to analyze it with yourself on the basis of your impression.
1. Bootstrap definition and role in Appium. Let's take a look at a high-level architecture diagram I prepared when I first came into contact with appium about a month ago.
The following section shows the location of bootstrap in blue. We can see that it is running on the target Android testing machine. It listens to port 4724 to obtain the command and passes it to UiAutomator for processing.
So how should we define bootstrap? I don't know if the official website has made a definition, but in my own language, I will define it like this:
Bootstrap is a UiAutomator test script run by Appium on the android target testing machine, the only test method of this script is to enable a socket server on the target machine to send the Appium command in a session from the PC to UiAutomator for processing.
This definition illustrates the role that bootstrap plays in appium and uiautomator: first, it is a test script of uiautomator, and its entry class Bootstrap inherits from UiAutomatorTestCase, therefore, UiAututomator can run normally. It can also use the uiautomator method normally. This is the key to converting the appium command to the uiautomator command. It is a socket server, it listens to the connection and command data of appium from Port 4724, and converts the appium command to the uiautomator command to let uiautomator handle the final process, it processes commands from the pc side of appium, rather than a file. This is confusing when I first came into contact with appium. I thought that appium was the whole script file sent to the target machine and then analyzed and processed by bootstrap. This is not the case.
2. List of key Bootstrap classes
The bootstrap definition is illustrated in a few words above, then, let's continue to list the key classes of the bootstrap jar package, their key methods, and their own instructions, let's give you an example of what each draft idea class is like. In this way, we can better understand the article below.
Class |
Key Method |
Key Member |
Parent |
Description |
Comment |
Bootstrap |
TestRunServer |
|
|
Run a SocketServer as a UiAutomatorTestCase method to listen on port 4724. |
The whole bootstrap runs in the form of TestCase of UiAutomator. Therefore, the Bootstrap class must inherit from UiAutomatorTestCase. |
SocketServer |
HandleClientData |
|
|
Read the string command information from the socket, convert it to the AndroidCommand command, and then call the runCommand command to execute the command to return |
|
AndroidComma NdType |
|
Enum AndroidCommandType { ACTION, SHUTDOWN } |
|
There are only two types of Android commands. The shutdown method is different from the normal action method. |
|
AndroidComma Nd |
Action/getElement |
JSONObject json; AndroidCommandType primitive type; |
|
Obtain the real command from the json command information sent by the user. |
|
CommandHand Ler |
Execute |
|
|
Virtual class. Other real CommandHandler, such as the parent class of click |
|
AndroidComma NdExecutor |
Execute |
HashMap < String, CommandHan Dler> map |
|
Map is a ing between all command strings and real CommandHandler. The member function execute is to find the corresponding handler of map through the string command and then execute |
|
AndroidComma NdResult |
AndroidCommandResult |
JSONObject json |
|
Class that organizes return values in json format |
|
AndroidElement |
Click |
UiObject el; String id; |
|
Represents a control |
The id is the key of the elements hash table maintained by AndroidElementsHash, not the Control id. |
AndroidElement Hash |
AddElement |
Hashtable < String, AndroidEle Ment> Elements; |
|
Maintain the hash table of all controls that this session has encountered so far |
Note that the key is the member variable "id" of the AndroidElement above. Every time there is a new control coming from the appium pc, this value will add one |
Click |
Execute |
|
CommandHandler |
Class for processing the click command. The actual execution is the upload AndroidCommand corresponding to the Click method of the UiObject. |
Other commands such as find, drag, and setText are the same. |
Strategy |
FromString |
PublicenumStrategy { CLASS_NAME (Class Name "), CSS_SELECT OR (css Selector ") , ID ("id ), NAME ("name ), LINK_TEXT ( Link Text ), PARTIAL_LI NK_TEXT ("p Artial Link Text ), XPATH ("xpa Th ), ACCESSIBIL ITY_ID ("ac Cessibilit Y id "), ANDROID_UI AUTOMATOR ( -Android Uiautomato R ); |
|
Query control commands |
Find CommandHandler searches controls in different ways based on different policies given by the user. For example, the method of using xpath is different from that of using uiautomator. |
|
|
|
|
|
|
The classes here will be further elaborated in our next analysis article, so here you just need to make a rough idea of what these classes are like.
3. the Bootstrap running process introduction was intended to draw a class diagram to describe the bootstrap architecture. However, from the above class table, we can see that the key classes in bootstrap basically do not actually use Object-oriented Inheritance, because they basically have no parent class. In fact, we can also understand that every class is not complicated and does not do many things. Even if we need to do more things, we can simply combine other classes. So here I also gave up providing class diagrams for you, and I will provide my own hand-painted (in that case, I did not install the corresponding charging flowchart software on my macbook pro) A sequence diagram using the process of processing the click command from the pc side of appium as an example. First, you have a preliminary idea. It doesn't matter if you cannot understand it, I will write another article later specifically to describe this process to concatenate all the key classes.