Will this bring any performance improvement to rendering, measuring and layout phases or will just skip the xml parsing or the performance improvements are likely to come when the UI composing will be truly multi-threaded.

There is no XML parsing in existing Android Layouts on runtime, because XML is parsed on compile time

Yes, we're reworking measure and layout for performance in compose

When i said parsing i meant the inflation process, i misspoke. If i understand correctly the new components used for drawing will basically just wrap a kind of render node used to just generate the render list, which should give big performance improvements for custom "widgets". And how would drawables integrate into this picture.

Drawing has the same basic shape as it does for views today, views already behave the way you describe. Each view has a render node that it records drawing commands into when its draw method is called, the canvas provided there isn't directly drawing pixels in the usual code path

I understand but renderNode was introduced in api level 29 so before there was no way that i know of to break a complex view into smaller parts so you could rerecord just part of the display list of a view. So this looks very promising. Thanks for the clarification.

When i said parsing i meant the inflation process, i misspoke

I believe that biggest problem of current view inflation is not inflation process and even reflections, but biggest part is just constructor invocation, because it’s pretty heavy on every view, and Compose I hope will solve this problem

Bingo. View constructors do tons of work and several calls to

Context.obtainStyledAttributes

, one for each layer of inheritance. That's gotten more expensive as themes have also become more complex and layered.

@miha-x64 Why 🚫 ? Could you show me layout xml on runtime?

It's not a straight XML, but it still must be parsed.