mcomella
commented
3 years ago I looked into this and was able to add an OnGlobalLayoutListener. However, the number of layouts varies each time we start the app so it's somewhat impractical to add a check that the number of layouts does not increase. I can think of a few mediocre solutions (bolding the best ones):
- Force the count to work (viable for long term, involved solution but perhaps handling inflation will be good enough)
- Ensure all the async UI layouts at the same time via a barrier. This is a lot of work to identify all the async bits and it's easy to break by just not including new async code in the barrier. However, if we want our layout to happen once to reduce redundant work, this is one of the ways to do it.
- Get the count at an earlier milestone
- e.g. on first frame drawn. Unfortunately, I can't think of a milestone with useful values – on first frame is 1 total layout, homeFragment onCreate/Start/Resume on next frame drawn is 2 layouts but after that presumably the content loads async and causes the layout count to vary a lot)
- Use a different metric (seems the most promising but unclear what a good metric is)
- Instead of checking an absolute value, check a max value (e.g.
expectedLayoutCount < 10). Will make a flaky test that doesn't help identify the PR that caused the regression. - Is there a
measurehook better than alayouthook? - (high variance) Time spent in layout
- Find events that cause layout
- (very complex) We could look for all the code that dirties the layout tree (e.g.
addView) - Use inflation as a heuristic for number of layouts. Unlike number of layouts, should be consistent
- Instead of checking an absolute value, check a max value (e.g.
Notably, each time a layout occurs, we have no information as to why that layout occurred so, presumably, the only way to get that is with better tooling or our own introspection code that looks "pre-layout" (e.g. inspects the view hierarchy on layout). These could help us figure out why the layout count varies so much and what to do about it. (maybe probe would help?)
As for what we should do, I would recommend we just start with wrapping layout inflation calls and optionally leave the code in that counts the number of layouts if we think it's useful for our own reference (we could also add a profiler call there too though I found relating the markers to the stack view in the profiler was less easy than I'd hope).
MarcLeclair
stale[bot]
The number of layout and measure passes on startup can impact performance. We sometimes do multiple passes over our layouts during startup and we should definitely aim to reduce those.
Time: 3 days
┆Issue is synchronized with this Jira Task