I know that threads have a message queue and handlers are able to push runnables or messages to them, but when I profile my android application using Android Studio tools, there is a strange process:
android.os.MessageQueue.nativePollOnce
It uses the CPU more than all the other processes. What is it and how can I reduce the time that the CPU spends on it? You can find the profiler result below.
android.os.MessageQueue. Low-level class holding the list of messages to be dispatched by a Looper . Messages are not added directly to a MessageQueue, but rather through Handler objects associated with the Looper. You can retrieve the MessageQueue for the current thread with Looper.
↳ android.os.Looper. Class used to run a message loop for a thread. Threads by default do not have a message loop associated with them; to create one, call prepare() in the thread that is to run the loop, and then loop() to have it process messages until the loop is stopped.
Android handles all the UI operations and input events from one single thread which is known as called the Main or UI thread. Android collects all events in this thread in a queue and processes this queue with an instance of the Looper class.
Short answer:
The nativePollOnce
method is used to "wait" till the next Message
becomes available. If the time spent during this call is long, your main (UI) thread has no real work to do and waits for next events to process. There's no need to worry about that.
Explanation:
Because the "main" thread is responsible for drawing UI and handling various events, it's Runnable
has a loop which processes all these events. The loop is managed by a Looper
and its job is quite straightforward: it processes all Messages in the MessageQueue
.
A Message
is added to the queue for example in response to input events, as frame rendering callback or even your own Handler.post
calls. Sometimes the main thread has no work to do (that is, no messages in the queue), which may happen e.g. just after finishing rendering single frame (the thread has just drawn one frame and is ready for the next one, just waits for a proper time). Two Java methods in the MessageQueue
class are interesting to us: Message next()
and boolean enqueueMessage(Message, long)
. Message next()
, as its name suggest, takes and returns the next Message from the queue. If the queue is empty (and there's nothing to return), the method calls native void nativePollOnce(long, int)
which blocks until a new message is added. At this point you might ask how does nativePollOnce
know when to wake up. That's a very good question. When a Message
is added to the queue, the framework calls the enqueueMessage
method, which not only inserts the message into the queue, but also calls native static void nativeWake(long)
, if there's need to wake up the queue. The core magic of nativePollOnce
and nativeWake
happens in the native (actually, C++) code. Native MessageQueue utilizes a Linux system call named epoll
, which allows to monitor a file descriptor for IO events. nativePollOnce
calls epoll_wait
on a certain file descriptor, whereas nativeWake
writes to the descriptor, which is one of the IO operations, epoll_wait
waits for. The kernel then takes out the epoll-waiting thread from the waiting state and the thread proceeds with handling the new message. If you're familiar with Java's Object.wait()
and Object.notify()
methods, you can imagine that nativePollOnce
is a rough equivalent for Object.wait()
and nativeWake
for Object.notify()
, except they're implemented completely differently: nativePollOnce
uses epoll
and Object.wait()
uses futex
Linux call. It's worth noticing that neither nativePollOnce
nor Object.wait()
waste CPU cycles, as when a thread enters either method, it becomes disabled for thread scheduling purposes (quoting the javadoc for the Object
class). However, some profilers may mistakenly recognize epoll-waiting (or even Object-waiting) threads as running and consuming CPU time, which is incorrect. If those methods actually wasted CPU cycles, all idle apps would use 100% of the CPU, heating and slowing down the device.
Conclusion:
You shouldn't worry about nativePollOnce
. It just indicates that processing of all Messages has been finished and the thread waits for the next one. Well, that simply means you don't give too much work to your main thread ;)
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With