Develop Reference

Android: an easy way to alternate UI elements in one place

There is a dialogue, in one place of which I need to show either one element or another, depending on the situation. Example:
I would like to do this so that the elements below do not move. I want to keep the area occupied by alternating elements of a constant size.
What is the easiest way to do this?
I can, of course, manually change the visibility. Вut when switching, if there is a different height, then the underlying elements will jump. I can manually set their height equal, but this is inconvenient. It will be necessary to correct the heights of all alternating elements every time after I change one of them.
For example, Qt has Stack Layout that allows you to alternate elements and takes the size of the largest of them. Does Android have something like this?

You might be able to use the ViewSwitcher to hold the two layouts.
It holds 2 different child views and measures its height to the biggest child by default.
Here's the documentation for it: https://developer.android.com/reference/android/widget/ViewSwitcher

Just an idea if you can't find something like Stack Layout. I haven't tried it.
You can put all the elements in an horizontal LinearLayout with MATCH_PARENT width for the visible one and 0 for the invisible ones, but keeping all of them VISIBLE. It should always have the largest height and only the MATCH_PARENT width element should actually be visible.

How does fill_parent in Android actually work under the hood?

I see great value in fill_parent, and I'd like to make my own implementation of it so I can do more than just fill the remaining space (ex: fill 80% of the remaining space, etc.)
How does fill_parent actually work under the hood? As in how does it compute the space remaining, how does it work at runtime, etc.
I've done similar things to fill_parent in the past where I calculate the space an element should take up based on the current screen size, how much of the screen the element should take up, etc. but I want to know specifically how Android does it with fill_parent.

Try creating a custom View or ViewGroup and you will find out.
There's 3 stages on bringing a View to your screen:
measure
layout
draw
In measure the parent tells the child how much space is available. It may do that in respect to the childs layout parameters. So if the child says match_parent (fill_parent is deprecated) the parent will pass in either its own size, or the remaining space (most of the time...)
The child then takes the available size, calls setMeasuredDimenstion(allTheSpaceIGot) and that's measuring for you.
Next up during layout, the parent checks the childrens measured sizes. It then sets the childrens bounds (top, left, bottom, right) accordingly.
Finally in onDraw every child draws itself within its bounds.
To sum this up:
Child gives parent information about its wishes.
Parent offers child some available space.
Child says "I'll take it".
Parent gives child its final restraints
Child draws itself within the constraints
If you want to assign say 60% to a view you should have a look at creating a custom ViewGroup (since that is who actually decides on the childs dimensions)
I also wrote a blog post about custom views that goes into more detail, followed by how to create a custom layout.

The entire source code for Android is open source, freely available within a few clicks on Google, so you can read it and study it all you want.
But just a fair warning, it's definitely no small task you're trying to accomplish, as there are an enormous amount of cases you have to account for.
If you want a layout to take X percent of available height/width, take a look at PercentageRelativeLayout
Just FYI: 'fill_parent' is deprecated, use 'match_parent' instead. They literally do the exact same thing, it's simply a different word.

In Android, what Layout is faster 1. FrameLayouts inside LinearLayout or 2. One big RelativeLayout?

I am considering two different layout arrangements for a view (which will be a row in a RecyclerView). They are different, but they will both work, either as
One container vertical LinearLayout containing rows of FrameLayouts e.g. LinearLayout -> FrameLayouts -> Content
One big RelativeLayout that contains all other views (no FrameLayouts but all TextViews, Buttons and such) e.g. RelativeLayout -> Content
Now I was wondering: which one would be more preferable in terms of Layout performance?
It was my understanding that a RelativeLayout has to be measured twice and thus is pretty slow, while a FrameLayout is fast and a LinearLayout is ok in terms of layout performance. In one case I would only have one container that is slow (RelativeLayout -> Content) in the other I would have two containers that are quicker (LinearLayout -> FrameLayouts -> Content).

Short Answer (TLDR):
If you really know what you're doing, RelativeLayouts can be faster.
If you don't, they can be much slower.
Long Answer:
Nesting layouts manually such as a FrameLayout within a LinearLayout versus using relative positioning in a RelativeLayout can have pros and cons either way.
The cost is in calculating the dynamic sizes such as "wrap_content" which must expand based on their children's needs or constrain due to parent's requirements. This causes a factorial calculation problem which increases with depth.
Manual positioning by using nested views increases levels. The shallower the level, the better but still work. So literally the amount of work is the factorial of your level depth as described above.
For example:
A is nested under Root.
B is nested under A.
C is nested under B.
A affects Root's width.
B affects A which affects Root.
C affects B which affects A which affects Root.
Relative positioning by having one view position itself relative to another is the same as nested views in terms of dynamic sizing calculations since each relationship must be calculated with consideration of the other.
For example:
A is left of Root.
B is left of A.
C is left of B.
While A,B,C all live under Root, the dynamic measurement occurs like so:
A affects Root's width.
B affects A which affects Root.
C affects B which affects A which affects Root.
In other words, you have the same factorial calculation occurring.
So the only real difference is that RelativeLayouts give you finer control over relative positions at the cost of more complex XML.
On the flip side, with careful use of #dimens that are calculated ahead of time based on device attributes, the dynamic calculations can be avoided and when used properly, RelativeLayouts can be much more performant than any other layout when needing complex positioning.

It depends on the context, there's no easy way to answer this question. There are existing threads with similar discussions already, and it is thought that performance gain is negligible.
RecyclerView allows you to reuse existing ViewHolders. A limited amount of ViewHolders ("RecyclerView pool") is created once, with different view type count in mind.
Assuming you do not spoil ViewHolder pattern, by, e.g. inflating views each time in bind method, you are unlikely to feel the difference between RelativeLayout and LinearLayout root layouts.
However, if you use some sort of objects with dynamic size properties (e.g. ImageView with height set to wrap_content and you load different bitmaps into it), it is likely that your layout will be invalidated and calculated again on each call to onBindViewHolder().
So my assumption is, reasonable usage of RelativeLayout won't bring you into any performance trouble.

Is Android layout really exponentially hard?

Some commonly used android layouts such as
RelativeLayout and LinearLayout (when weights are nonzero)
have onMeasure() implementations that measure their children
twice, resulting in exponential running time when nested.
This is easily verifiable by emitting Log entries
from a leaf View's onMeasure()... it gets called 2depth
times.
Can someone give a clear and specific description as to why this is?
Most importantly, is this exponential behavior due to an important part
of the overall contract, or is it just an implementation detail
that might be optimized away? If it is believed to be unavoidable,
please give an example that requires it.
Such an example would greatly help me and others
who are grumbling that the "keep your layouts shallow"
mandate is burdensome and who are wondering
whether this is being driven simply by
not-yet-optimal algorithms in the core libraries,
or whether there really is a fundamental difficulty
blocking a fix.
Perhaps a minimal example would consist
of a Button inside a LinearLayout inside another LinearLayout
(with match_parent and weight=1 everywhere, to trigger
the full exponential behavior),
with some additional parameters or circumstances
making it clear that all four of the calls
to Button.onMeasure() are indeed meaningful and necessary.
My first guess would be that only two linear-time
traversals are really needed-- the first traversal to gather everyone's
preferred sizes, the second traversal to distribute slack
and/or shrinkage.
Other layout engines in the world, such as those for Tex and Swing and HTML,
seem to be able to routinely handle very deep hierarchies
having lots of alignment constraints and stretches,
without any exponential blowup, and I imagine that's how they work.
Please note, I don't want answers explaining how
the exponential blow-up occurs-- I understand that,
and there have been several posts already where that has been
asked and answered:
Why are nested weights bad for performance? Alternatives?
Android layout measuring time doubles with each step up the hierarchy
Layout Weight warning Nested weight bad performance
Efficiency of Android Layout hierarchy
http://android-developers.blogspot.com/2009/02/android-layout-tricks-1.html
My question is whether the recursive double-measuring is
fundamentally necessary/justified,
and if so, I'd like a clear explanation/example showing why.
Edit 2013/8/22: I think maybe my question is still not getting across.
I'll try to clarify and explain my motivation, more boldly this time.
Layout is not an exponentially hard problem,
as evidenced by efficient layout engines in the world, such as those for Tex and Swing and HTML.
So, what happened with LinearLayout,
and how should the android developer community proceed in response?
I am asking not in the spirit of laying blame,
but rather to understand and decide how to best move forward.
I can think of 4 possibilities:
Fix the performance bug in the core library, without changing any contracts
Change contracts as needed, and fix the performance bug in the
core library
Write an alternative to LinearLayout, that has its essential
features (namely distributing extra space among children in specified proportions) but without the performance bug, and use it for new apps
Continue to micromanage our layouts to work around the
performance bug for the rest of our android development careers.
(4) isn't a serious option for me personally.
Furthermore it seems clear to me that
changing the behavior of LinearLayout at this point is impractical,
so I don't believe (2) is a serious option either.
That leaves (1) and (3).
I'm capable and willing to do either of those personally, but which one?
Obviously (1) is far preferable if it's possible-- so, is it possible?
That seems to be the crucial blocking question that needs to be answered
in order to determine how to move forward.
I have spent some time in the core code
and the doc and it's not becoming clear,
so that is why I'm asking the question here.

In terms of measuring children twice, it's my understanding that this is what happens with LinearLayouts particularly when weights are involved. The best explanation I've found for this comes from RomainGuy in one of his presentations.
He has a slide about this and briefly speaks to it at 17:45. Feel free to rewind to get a bit of context though. You can find the video I'm referencing here: Devoxx'10 - Dive Into Android
Basically what he says is that on the first pass they calculate the total width or height depending on orientation of the LinearLayout, add the weights of the children, and find out how much space is left over, then on the second pass with that information they are able to properly divvy out all the remaining space to all the children. Simple enough.
I'd also like to point out though that yes, while it's very true that shallow layout hierarchies have less of a performance hit, if you are adding just 1 or 2 extra layers, you probably aren't going to see a big performance impact for the user. Once it's laid out, it's done. Even in ListView's if you properly use the given "convertView", and set up ViewHolder's, you're going to get good performance.
I'd encourage you to use DDMS and do a layout dump of some of Google's apps. They are very complex, and often times surprisingly deep, but they still get good performance. Don't be stupid with your layouts, but if it saves you time, adding an extra layout isn't the end of the world.

From here: http://developer.android.com/guide/topics/ui/how-android-draws.html
A parent View may call measure() more than once on its children. For example, the parent may measure each child once with unspecified dimensions to find out how big they want to be, then call measure() on them again with actual numbers if the sum of all the children's unconstrained sizes is too big or too small (that is, if the children don't agree among themselves as to how much space they each get, the parent will intervene and set the rules on the second pass).
It seems they view the measurement pass as a dialog between parent and children. In other words they opted for maximum flexibility instead of optimization. It still seems like they could optimize the base layouts though.

I came here tonight to ask this. It's disappointing that nobody else even seems to understand your question. After thinking about it for a couple more hours, I think I might know the answer.
Consider this example:
The red box represents a LinearLayout with vertical orientation. The green box represents another LinearLayout with horizontal orientation. I would expect the layout to proceed like this:
1) The red LinearLayout would measure the heights of green LinearLayout and the large blue widget on the bottom, then compare their weights, divide any leftover vertical space accordingly, and measure the children again. (The important thing to know here is that "measuring" a view actually sets its size.)
2) The green LinearLayout would then measure the widths of its three children, compare their weights, divide the horizontal space, and "measure" again.
The catch is that in order for the red layout to measure the height of the green layout, the green layout needs to know the height of its children.
Now, you would think that LinearLayout would be smart enough to optimize away many of its calculations. For example, there is no logical reason for the green layout to measure the width of its children when determining its own height. And if its children all have a height of fill_parent, then it shouldn't need to perform any calculations at all.
But the API doesn't allow LinearLayout to be that smart. The fundamental problem is that there is no way to measure only one dimension of a view. You can get them separately after they've been measured, but the actual measurement is done by View#onMeasure(int, int). The arguments to that method are encoded with View.MeasureSpec, and there's no way to encode "ignore this dimension." So the green LinearLayout stupidly calculates both dimensions of all its children when the red layout measures it, then repeats the entire process again when it does its own layout. The widths will not have changed the second time around, but they must still be recalculated because, again, there's no way to tell the layout or its children to measure only one dimension.
So to answer your question... no, it doesn't necessarily need to be this way, at least for many common use cases. This is a deficiency of the Android API.
If Google were to add new methods to View to measure dimensions separately, the default implementation would have to rely on onMeasure(int, int), which could be even worse for performance. But if there are any unused bits in the View.MeasureSpec encoding, then it might be possible to add an "ignore" flag that would allow future versions of LinearLayout to be better optimized.

The problem in my opinion is the measure cache. As far as I could see the cache only works if there was a layout of the view in the middle, so when you perform two consecutives measures of a child (even with the same exact measure specs) in the same "onMeasure" all the children and their sub-children are measured again. If the measure cache worked fine, the second measure should be much faster as it would take the cached values and it wouldn't cause all the children hierarchy to be measured again.

How is the number of views limited?

I want to figure out the main effectivity issues of the Android layouts and views. I'm doing a research now but maybe somebody has answers already.
I have a RelativeLayout that is populated with views dynamically. Basically, the application loads a forum thread in XML and then renders the discussion tree so each message is displayed in its own group of views. I've decided not to use WebView because I want to implement some client-side functions that should be easier to do on custom views than on HTML page.
However this approach has a major flaw: it's heavy.
The first problem (which I've solved) was nesting of views. This is not an issue now, my layout is almost flat so the maximum depth is 10-12 (counting from the very top PhoneWindow$DecorView, the actual depth depends on data).
Now I've reached the next limit that is somehow connected to (or caused by) resource consumption of the views. After loading the data, the application hangs for a while to build the layout (creates the views and populates them with the data), and the hang time seems to grow linear with the data size; and if the data is large enough, the view will never appear (eventually the system suggests closing the application because it isn't responding).
Now the questions:
Does memory consumption depend significantly on the view class? In other words, is there any major difference between a Button and a TextView, or an ImageView? I can attach a click handler to any view so they don't differ much in usage.
Do background images affect the performance? If the same image is set in N views, will it make the layout N times heavier? (I understand that this question may look silly but anyway.)
Are nine-patch images significantly heavier than regular ones? What is better: to create N views where each has some background images, or to make one view that is N times wider and has a repeating background?
Given some layouts, what should be optimized first: overall number of views, nesting levels, or something else?
The most interesting. Is that possible to measure or at least estimate the resources consumed by the activity and its views? If I make some change, how could I see that I'm going the right way?
UPDATE
Thanks to User117, some questions that I asked above are now answered. I've used the Hierarchy Viewer and optimized my layout: compared to what I had before, the overall number of views is now reduced almost twice, and the nesting is also reduced.
However the application still hangs on a large forum thread.
UPDATE 2
I've connected the debugger to my device and found that the application gets out of memory.
But what is very unexpected for me is that the error occurs after I populate the layout. The sequence is as follows:
All my views are added. I can see a slight slow down as they are being added.
Almost nothing happens for a couple of seconds. During that time, a few info messages are spawned in the log, they are identical: [global] Loaded time zone names for en_US in XXXXms, the only difference is number of milliseconds.
The out of memory error message is spawned: [dalvikvm-heap] Out of memory on a N-byte allocation (the actual size varies). The long error reporting starts.
What does this mean? Looks like the rendering have its own demands that may be considerable.
UPDATE 3
At last I've found the core issue. Here is a screenshot from my application, see an explanation below the image.
Each message consists of a round button that shows or hides the replies and a red content frame to the right of the button. This is very simple and requires only 6 views including the layouts.
The problem is the indentation with these connection lines that show which message is related to which.
In my current implementation, the indentation is built of small ImageView's, each containing a square image that shows either empty space, or a vertical line, or a T-like connector, or a L-like corner. All these views are aligned to each other within the large RelativeLayout that holds the whole discussion tree.
This works fine for small and medium trees (up to few hundreds of messages), but when I try to load a large tree (2K+ messages), I get the result explained in UPDATE 2 above.
Obviously, I have two problems here. I spawn large number of views that all consume memory, and these views are ImageView's that require more memory for rendering because they render a bitmap and therefore create graphics caches (according to explanation given by User117 in the comments).
I tried disabling loading the images into the indentation views but got no effect. It seems like adding that huge number of views is quite enough to eat all available memory.
My other idea was to create an indentation image for each message that would contain all pipes and corners, so each message would have the only indentation view instead of 10 or 20. But this is even more consuming: I've got out of memory in the middle of populating the layout. (I cached the images in a map so two bitmaps with identical sequence of images weren't created, that didn't help.)
So I'm coming to conclusion that I'm in a dead end. Is it ever possible to draw all these lines at once?

Different View's are different kinds of Object. Some only draw() light weight stuff, some can hold large Bitmap Objects, and handler Objects and so on. So, yes different View's will consume different amount of RAM.
If same Bitmap object is shared among views, There's only one Object in RAM, each View will have a reference variable pointing to that object. But, not so when View draws: Drawing same Bitmap n times at n places on screen will consume n times CPU and generate n different bitmap_cache for each View.
Each side of a 9-patch image is actually bigger by 2 pixels from the original image. They are not much different as a file. When they are drawn, both can be scaled and will take almost equal space. The only difference is that 9-Patch are scaled differently.
Setting the background of the larger, parent view is better when the child views are transparent, and background will show through.
You can save a small image and set a tiled background so that it can fill a large area.
Nesting is to be optimized first, because all of the views might not be visible at a given time, let's say only a few views are visible in scrolling layout. Then you can cut down on total number of views used. Take cues from ListView: Given that user will be only seeing a sub set of total data at a time, it re-cycles the views. and saves a lot of resources.
SDK provides Hierarchy Viewer tool for this purpose. It shows a full tree structure of a running Layout, also places red flags for the sluggish parts of the layout.
A good layout is that which:
Easy to be measured (avoid complex weighted widths, heights and alignments). For
example instead of doing layout_gravity="left" for each each child, parent can have gravity="left".
Has less depth, each overlapping view adds another layer to be composited while screen is drawn. Each nested View Structure, asks for a chained layout call.
Is smart and re-cycles Views rather than create all of them.
Reuses its parts: tags like <merge> and <include>.
Update:
Answers to this question, show many approaches for a tree view in android.