Skip to content Skip to sidebar Skip to footer

Renderthread Vs Ui Thread

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 ever

Solution 1:

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:

  1. View#draw -> UI Thread
  2. 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, ...).

Solution 2:

Render thread as it name explains just do the rendering onDraw(), UI Thread do onMeasure(), onLayout(), etc... the concept of that separation is to do the hard work of measuring and calculating the other things without blocking the rendering that leads to smooth fps

watch this

Post a Comment for "Renderthread Vs Ui Thread"