From the Android Threads doc:
you must not manipulate your UI from a worker thread—you must do all manipulation to your user interface from the UI thread
So I believe that everything on the screen is rendered by the UI thread. But in Android Lollipop they have introduced a RenderThread:
A new system-managed processing thread called RenderThread keeps animations smooth even when there are delays in the main UI thread
How does it work? Does the RenderThread use the UI thread to render animations (Views with new properties) on the screen? If so, why doesn't it block the UI thread?
解决方案
The RenderThread depends on the UI Thread but it does run in parallel along with the last mentioned one.
Its main job is to run expensive computation on the GPU in order to empty the heavy load of the UI Thread.
How does it work?
Basically, the UI Thread acts as a job dispatcher. It prepares a pipeline of commands to be executed on the RenderThread.
The GPU doesn't know what an animation is; it can only understand basic commands, e.g:
translation(x,y,z)
rotate(x,y)
or basic drawing utilities:
drawCircle(centerX, centerY, radius, paint)
drawRoundRect(left, top, right, bottom, cornerRadiusX, cornerRadiusY, paint)
Combined together they form the complex animation you see on the screen.
Does the RenderThread use the UI thread to render animations (Views with new properties) on the screen?
No, it runs asynchronously
If so, why doesn't it block the UI thread?
The docs explain that the rendering is performed in two phases:
View#draw -> UI Thread
DrawFrame -> RenderThread, which performs work based on the View#draw phase.
On a lower level, when using hardware acceleration, the deferred rendering is executed by a DisplayListCanvas.
In this Canvas implementation you can find the aforementioned drawing commands, such as drawCircle.
As such, the DisplayListCanvas is also the drawing target of the RenderNodeAnimator, which runs the basic animation commands (translate, scale, alpha, ...).