-1

Got a performance issue when lots of nested RelativeLayouts are used.

For example if we have some RelativeLayout as a UI root, and every container(button, label, textview, imageview) is a RelativeLayout + Android based component (ex. aButton = RelativeLayout + ImageView + TextView), then in a complex view of 4 buttons, 3 images and 6 labels we get ~15 nested RelativeLayouts.

RelativeLayout has a very complex onMeasure method, that calculates size of every child to determine the size of layout. Calculating size of a complex view of 15-20 nested RelativeLayouts costs ~5 seconds, that's too much. onMeasure is most expensive of all calls, even drawing finished much faster then measurement. <=UPD=>
To prevent appearing suggestions to use native android views to build something complex:
Ability to add everything to everything is required. That's why every container has to be not just View, but ViewGroup. And RelativeLayout features like gravity and alignment can also help alot, that's why lot's of RelativeLayouts are used. <=/UPD=>

Had anyone got these performance problems?
Should replacing RelativeLayout with some other Layout solve issue?
Or removing all these nested layouts is the only way to deal with the problem?
Does anyone know how much layouts can be nested without some performance problems appearing?

AAverin
  • 3,014
  • 3
  • 27
  • 32

3 Answers3

2

It definitely depends on your testing device. But you should check the hierarchyviewer (within the tools directory) for unneccessary nests of views in order to remove them.

Also your aButton sounds like a stock ImageButton. So you could replace at least that with a standard solution.

If you posted some code it might be easier to tell whether there are more items that could be replaced by stock solutions.

Ben Weiss
  • 17,182
  • 6
  • 67
  • 87
  • Misstiped my aButton version. aButton = RelativeLayout + ImageButton + TextView (for label support). I've checked HierarchyViewer, everything seems to look fine. Of course, I can get rid of some layouts, but it doesnt increase average perofmance. Instead of 6 seconds before view appears I get ~4. Still too much – AAverin Dec 09 '10 at 07:41
  • Ok, so you could use a simple button with the `android:background="@color/transparent"` tag for making the button itself transparent and then use `android:drawableTop="@drawable/some_drawable"` for drawing an image in the button itself. – Ben Weiss Dec 09 '10 at 07:45
  • Yea, that's a solution to simplify button. I can also create my own class someButton extended ImageButton, and draw label in onDraw() method without using TextView. In that case RelativeLayout is also no longer needed. But, first I'd like to be sure that using N amount of nested RelativeLayouts is wrong for some reason. After that I'll start simplifying components and rewriting UI architecture of my app. – AAverin Dec 09 '10 at 07:52
  • Generally it would be better to use a smaller amount of layouts, but you should not have to resign from your screen design. Further you should try to use those layouts that are provided by the system itself i.e. Button instead of ImageButton and TextView within a RelativeLayout in order to speed up the layout process. The more layout elements there are the longer it takes to load them. – Ben Weiss Dec 09 '10 at 08:04
  • @Jitsu: Already read [this](http://developer.android.com/resources/articles/layout-tricks-efficiency.html)? It could help you. – Octavian Helm Dec 09 '10 at 11:23
0

After a few tests came to conclusion that having more that 12 nested layouts does a great impact on performance.
On average 10-11 nested layouts should work fine.
For example 12 nested layouts with 12 children on each display in 6 seconds on device, and in 9 on emulator.

AAverin
  • 3,014
  • 3
  • 27
  • 32
0

It was my understanding that the whole point of relativelayout is that you don't have to nest them to the nth degree. Why not just use a few RelativeLayout s rather than 1 per component?

Gustav
  • 1