AndroidViewClient's device.touch() is much slower than MonkeyRunner's. Can it be fixed?

Question

I've ditched MonkeyRunner for AndroidViewClient to benefit from its added reliability and simplicity of implementation (thank God for pure Python).

I need to perform several device.touch() events as fast as possible, however AndroidViewClient seems to achieve those significantly slower than MonkeyRunner.

Here's the code I used to time them both:

for iteration in range(1,6):
    ts_start = datetime.datetime.now()
    device.touch(1,1,'DOWN_AND_UP')
    chrono = datetime.datetime.now() - ts_start
    print str(iteration)+': '+str(chrono)

Here's MonkeyRunner's output:

1: 0:00:00.003000
2: 0:00:00.002001
3: 0:00:00.002001
4: 0:00:00.002001
5: 0:00:00.002000

Here's AVC's output:

1: 0:00:00.460000
2: 0:00:00.515000
3: 0:00:00.499000
4: 0:00:00.508000
5: 0:00:00.456000

That's about 200 times slower on average.

It seems like it's possible to store events in a binary file, then pushing and running it directly on the phone. However, I'd like to stick with a pure AVC approach.

Is that possible?

Edit:

Since it's not possible for now to achieve better performance the way I'd like to, I had to implement the event-files way like I mentioned.

I used two resources in order to do so:

• https://qatesttech.wordpress.com/2012/06/21/turning-the-output-from-getevent-into-something-something-that-can-be-used/
• http://ktnr74.blogspot.fr/2013/06/emulating-touchscreen-interaction-with.html

Here is how one of those files looks like (truncated):

#!/bin/sh
sendevent /dev/input/event1 3 57 0
sendevent /dev/input/event1 3 55 0
sendevent /dev/input/event1 3 53 640
sendevent /dev/input/event1 3 54 900
sendevent /dev/input/event1 3 58 1
sendevent /dev/input/event1 0 2 0
sendevent /dev/input/event1 0 0 0
sendevent /dev/input/event1 0 2 0
sendevent /dev/input/event1 0 0 0
sendevent /dev/input/event1 3 57 0
sendevent /dev/input/event1 3 55 0
sendevent /dev/input/event1 3 53 640
sendevent /dev/input/event1 3 54 730
sendevent /dev/input/event1 3 58 1
sendevent /dev/input/event1 0 2 0
sendevent /dev/input/event1 0 0 0
sendevent /dev/input/event1 0 2 0
sendevent /dev/input/event1 0 0 0
sendevent /dev/input/event1 3 57 0
sendevent /dev/input/event1 3 55 0
sendevent /dev/input/event1 3 53 500
sendevent /dev/input/event1 3 54 900
sendevent /dev/input/event1 3 58 1
sendevent /dev/input/event1 0 2 0
sendevent /dev/input/event1 0 0 0
sendevent /dev/input/event1 0 2 0
sendevent /dev/input/event1 0 0 0

Performance-wise, it's about twice as slow as a MonkeyRunner implementation.

Answer 1

You're absolutely correct, if you look at the codes of AVC and MonkeyRunner, I think the flow chart is like below, both are using sockets but the difference of speed is because Monkeyrunner uses direct client socket to connect to Monkey server on the device to send command like tap, press once the monkey server is started on the device. AVC socket communicates to adb server to send the input tap/press, I don't know which "sauce" is in adb input, I guess it is Java which produce this slow response time. I think the owner of AVC can implement the Monkey server in a blink of eyes, but there is a problem, Uiautomator and Monkey can not coexist together, so I guess he should make a tradeoff between speed and stability for the majority of users:

AVC: client socket ---> ADB server ---> ADB daemon on device
MonkeyRunner: client socket ---> Monkey server on device