Open mattprecious opened 4 years ago
I just looked into the details of the events and batching looks insanely hard.
Maybe someone else will figure it out!
I kinda solved this scrolling performance issue. As the Vikas G’s answer in stackoverflow
The reason why your replay takes a long time is because the sendevent binary opens the interface file, writes data to it and closes it for every call to sendevent. So in theory, if you have a bunch of sendevent commands, the binary is opening the interface file, writing data and closing it for every command. The way I've solved this issue is by re-writing the sendevent.c file under /system/core/toolbox to open the file only once during replay, writing all the data and closing it at the end of the replay. It works perfectly for me!
So, I got the sendevent.c source code and made some modifications: now it has a while that keep receiving commands and sending events until it receives a exit command. Therefore, it is no longer necessary to open and close the interface file after every single event. The result is a much more fluid performance, especially when scrolling:
On the other hand, this changes ended up creating a new issue: recording the commands and replaying them after is practically impossible, since there is no delay between events. So, if you, for example, record opening some app and performing a scroll, when replaying it, the scroll will be done in the splash screen. Guess that maybe I can record the time between getevent commands and send it to the .C file, giving the intended delay. Any other thoughts?
And oh - my fork url: https://github.com/guilhermealbm/adb-event-mirror
I wonder if this is something we can contribute upstream to AOSP? It would be great if sendevent
allowed keeping the file descriptor open and sending events to it in real-time. Not too dissimilar from how a shell works. Let me see if I can float the idea to someone...
Maybe batching up MOVE events would help with the throttling