Understand the hidden costs of Android transparency

I'm watching a video https://youtu.be/wIy8g8yNhNk

My first question

As I learned from the video, when we draw an opaque view, we just put the data (roughly speaking) on the screen. This is the so-called rendering. Is that correct?

My second question

Now, let's draw a textview with an opaque background and translucent text. As described in the video, why do we do it in two steps: we draw the textview as opaque, and then apply a new alpha value to make the text translucent? Is this just the way Android is designed? Why can't we draw a translucent pixel in one step?

My third question

Here Ian ne Lewis introduced us to a view composed of two parts: opaque (at the top) and translucent (below the opaque part). He said that the two parts do not overlap. But the opaque part is at the top of the translucent part. So why did he say that these views do not overlap? As far as I know, by "overlapping", he means having translucent objects on opaque objects

resolvent:

Answer your first question:

Rendering is the process that the Android framework performs when drawing an opaque view on the screen

Second question

To render the textview, Android will first draw an opaque background and then draw translucent text. As you can see in the video: when rendering the alpha layer, Android must redraw the background layer to see what color the alpha should be mixed

This is how Android is designed. Even if the background and text are opaque, Android will draw the background first and then the text (but this time it doesn't need to check the background for fusion)

Question 3

I don't think you can correctly understand the meaning of overlap. This is an example: