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
FrameLayouts
affect nestedListView
scrolling performance? - Q3: If answer to Q2 is "yes", what is the exact overhead in "scrollable" case?