In order to implement a clean architecture with separate and reusable UI components, I need to have hierarchies of nested FrameLayouts (up to 3-4 nested FrameLayouts), all of which have both layout_width and layout_height set to match_parent (the general idea behind that architecture is described in this answer).
I came to wonder if there is any noticeable performance overhead associated with this practice of nesting FrameLayouts. In order to make the question less abstract, let's discuss it in context of two concrete hierarchies: "static" hierarchy (nothing moves on the screen), and "scrollable" hierarchy (user can scroll the screen).
"Static" hierarchy:
once the screen containing this hierarchy is shown, nothing changes anymore.
"Scrollable" hierarchy:
after this hierarchy is shown on the screen, the user can scroll the inner ListView, thus requiring redraw of the innermost RelativeLayouts.
I'm not worried at all about "static" hierarchy - the overhead of nested FrameLayouts in this case is paid once and will not impact layout's performance in any noticeable way.
- Q1: Is this assumption correct, or there are some performance-degrading scenarios which I can bump into?
What about "scrollable" layout? I wonder whether the fact that the inner ListView is wrapped in several FrameLayouts affects its scrolling performance...
- Q2: Are outer
FrameLayoutsaffect nestedListViewscrolling performance? - Q3: If answer to Q2 is "yes", what is the exact overhead in "scrollable" case?

