Does it (and in what way) effect performance to have a complex Layout hierarchy?
In what way does it affect an application to have deeply nested layouts (e.g. RealitiveLayout which contains many LinearLayouts which each contain....)
It has an effect, the simpler the better is the rule.
Every view — or worse, every layout manager — that you add to your
application comes at a cost: initialization, layout and drawing become
slower. The layout pass can be especially expensive when you nest
several LinearLayout that use the weight parameter, which requires the
child to be measured twice.
From: http://android-developers.blogspot.com/2009/02/android-layout-tricks-1.html
You can use hierarchyviewer to gauge the performance of your layout hierarchy. For more details see http://developer.android.com/guide/developing/debugging/debugging-ui.html
Yes it does and more than 3 levels are supposedly not recommended. That is one reason why the new GridLayout was created. Also the lint and hierarchyviewer tools in the SDK will help you optimizing your layouts.
However depending on your needs you might have to nest deeper. Just use the SDK tools and some devices with hands on testing to see if your performance bottlenecks are with the rendering. Most likely they are somewhere else in your code..
One of the main performance slogs with regards to views is not the rendering but inflating them from xml files..
Related
I totally understand the advantage of having ConstraintLayout when flatenning nested UI's. But with the introduction of ConstraintLayout I see people adopting it instead of RelativeLayout even for simple layouts with a flat structure.
Does ConstraintLayout always performs better than RelativeLayout?
Specifically in the case when a view can be achieved with single flat
structure with no nested UI?
If yes, shouldn't Relative Layout be deprecated?
Any help would be much appreciated :)
I think that should be a matter of choice and customs. Some UI designers prefer RelativeLayout where others prefer ConstraintLayout. The ConstraintLayout can be used in many cases more than the RelativeLayout. And yes it performs better than the RelativeLayout but I think for just a single flat structure I can opt for RelativeLayout too though due to support tooling provided by the ConstraintLayout it makes it a better option if you need that feature.
That's my point of view.
Yes, it performs better, ConstraintLayout has designed with performance optimization in mind. Also, it's very straightforward to use by just drag and drop things.
I really like Constraint layout to develop complex layout faster than any other one, but in my opinion, it's harder to make changes on it when you need, but is just my point of view
Q1 - Does ConstraintLayout always performs better than RelativeLayout
A1 - I saw a lot of questions and answers on StackOverflow about that subject and here is what I can say base on those threads and my personal experience with ConstraintLayout :
In most cases, if you are using ConstraintLayout properly it will work faster but , there is no guaranty that this is what you will get all the time.
From my personal experience with ConstraintLayout, it is working really fast and in all of my layouts (both simple and complicated in terms of UI) it works faster than RelativeLayout.
Q2 - shouldn't Relative Layout be deprecated
A2 - Why I believe that Relative Layout should not be deprecated.
I honestly don't see any valid reason for RelativeLayout to be deprecated, altho I am using ConstaintLayout I first started with RelativeLayout and now I see it as another tool to build my UI.
If it's not broken don't fix it:
Don't forget that there are a lot of developers around the globe, some prefer
RelativeLayout and some prefer ConstraintLayout, let's keep it this way is what I believe - don't take the option to choose from the developers, give them the option to choose what to use.
ConstraintLayout is not a better solution for building UI as a fact, its just my opinion.
I really think that its something that depends on the developer and his decisions, therefore - no layout is better than the other and no layout should be deprecated (as long as it works)
I was curious about knowing that why this happens in android studio when I'm trying to graphically edit layouts. Every views and attributes are reorganised. is there any rendering benefits or any benefits at all?
Because its not a drag and drop editor. Not really. You're putting children into a parent layout, which works on certain rules. When you drag children around, you change the rules but you're never putting it in a particular place.
I really, really, really suggest you don't use the graphical layout editor. Its confusing, not very accurate (especially if using custom views) and inefficient. Learn how to write layout xml, you'll be much faster and write easier to maintain layouts. Most pro devs don't use it at all.
Is there any performance difference between layouts done in code vs XML layouts in android?
Yes. XML layouts need to be loaded, parsed and inflated to generate the View. Behind the scenes the LayoutInflater does exactly what you would do when writing layouts through code, but with the overhead mentioned before.
Here is an interesting article on this topic, which covers View generation through code, also it is about a library written in Kotlin: https://nethergrim.github.io/performance/2016/04/16/anko.html
But even though there is a performance win, I would not recommend to write layout in code for the following reasons.
You couple your layout and your business logic. That's always bad.
You can't use the features of the AppCompatDelegate (loading Views for the latest Androind version. E.g. an AppCompatButton instead of a normal Button.
As far as i know, i can make one difference. Please correct/enhance my answer if possible.
For XML based, In compile time, the ID generated and stored in R file which we use to refer to that any particular layout(like TextView, Button etc.) inside our code. As the reference ID is getting generated at compile time, so at run time this overhead is not there and it is faster.
In code based, all things done at run time which makes the app slow. It is not that much visible if small number of layouts are there. But if you are creating a lot of Layouts pro-grammatically, then you may realise the slowness in your app.
Its hard to imagine that using XML would ever be faster.
Android SDK has a lot of performance tweaks to make loading and parsing XML fast. in recent times, if you use data binding to replace findViewById this dramatically improves performance as well as each call to findViewById parses the XML tree. Where as databasing will only parse the tree once.
Also, using include in XML allows for reuse of Views which improves performance especially in cases where you would have large object churn. There is all sorts of I eternal caching and pooling of objects as well so it's possible that inflated objects are cached/pooled and cloned for subsequent use reducing the overhead on using XML. I know this is definitely the case for Drawable assets hence the need to call mutate if you ever plan on modifying one.
There are scenarios where code would be slower, with every View you create and add to your layout, you will trigger a measure and layout pass, so if you try to build a complex, deep nested layout using code at runtime, this would take a lot longer to load.
There are other factors to consider, like:
styling is hard if not impossible to apply at runtime.
code with views created complete runtime mY be complex, hard to maintain and bug prone.
You can use ConstraintsLayout to flatten your views hence avoid writing custom ViewGroups if performance is an issue.
XML allows use of the editor to preview and debug your layouts.
If the ViewGroup you want to create is simple, or simply want to create a single View and insert it into a ViewGroup, doing it in code is probably hard to beat by any criteria.
If you want to do something a lot more complex, using XML and all its features like ViewStub, includes, DataBinding is probably the way to go. I have noticed that inflating Views can be visibly slow, if you do it a lot, hence the ViewHolder pattern, but if you're careful, it's hard to justify ever building Views and ViewGroups in code for any thing but simple layout additions.
I have created an android mobile application and i have thoroughly clean everything in the xml file of the application but there are 2 warnings that i can get rid of one is activity_main.xml has more than 80 views, bad for performance and the other is Nested weights are bad for performance i have an option to suppress those warnings but i'm not sure if its the right thing to do. i would like to know the draw back of these warning and if it is ok if i just suppress these warning or i need to eliminate these warning
Two thing can happen when you are using nested layout
StackOverFlow Exception and OutOfMemory exception. Please refer to this Stackoverflow: Caused by nested views?. You should optimize your layout you can refer to this Optimizing Layout Hierarchies.
has more than 80 views, bad for performance:
User interface performance is directly related to (among other things) the complexity of the View hierarchy being displayed. This warning message is simply letting you know that you have a lot of Views defined in this layout and that it could lead to UI performance problems. The solution is to look at your layout and considering how you can simplify the View hierarchy to achieve the desired results with fewer Views. Or, alternatively, you can take this warning with a grain of salt and just test to verify whether performance is acceptable for your layout on the device(s) that you plan to support.
Nested weights are bad for performance because:
Layout weights require a widget to be measured twice. When a LinearLayout with non-zero weights is nested inside another LinearLayout with non-zero weights, then the number of measurements increase exponentially.
It's always better to use RelativeLayouts and adjust your view according to the places of other views without using specific dpi values.
What is the use of <Space /> in andorid ui, how is it any different from an empty linearlayout.
Is there any special use of <Space> in android ?
From the docs:
Space is a lightweight View subclass that may be used to create gaps between components in general purpose layouts.
Yes it is different than a LinearLayout in that it cannot do all (any) of the things that a LinearLayout can do. It's purpose is solely to add a gap between some things. By taking out all of the LinearLayout functionality it makes the view "lighter" which will mean less resource intensive.
Space is used to define empty spaces (or gaps) inside a layout.
It was introduced in API level 14 alongside GridLayout.
To get a feel of what it's all about, check out this tutorial.
It’s often possible to take a complicated layout and break it down into a set of nested linear layouts and, provided this nesting doesn’t get too deep, this is still a good choice for many simple layouts.
For use in hierarchies that are too deep and there are performance problems, is a lightweight View subclass. The keyword being 'lightweight'.