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:
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.
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.
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
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
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.
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.notify() methods, you can imagine that
nativePollOnce is a rough equivalent for
Object.notify(), except they’re implemented completely differently:
futex Linux call. It’s worth noticing that neither
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.
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 😉
Answered By – Lawiusz
Answer Checked By – Mary Flores (BugsFixing Volunteer)