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.
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)
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.
Suppose I have a ViewGroup that can contain several optional children views, say a VideoView, an ImageView and a few optional buttons.
Are significant resources wasted if I include all possible children views in the layout file but set all of them to visibility gone by default, but change visibility as appropriate at runtime?
Is it better just to add the views at runtime as needed? Is there another approach that would be more sensible? Fragments?
I prefer to create them all and hide them. I've noticed that a most of the built-in Android layouts I've looked at do the same. Personally, I think it cuts down on NullPointerExceptions and the checks needed to avoid them.
The resources saved by not creating a handful of views in the layout file should normally not make a large difference for the runtime resource consumption of your application, except for cases where they contain huge images or other very heavy ressources.
On the other hand, having those views in the layout file (and hiding them)
makes them much more readable than creating them in Java code
leads to them being checked by Android Lint.
That's why I always suggest to have them in the layout.
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..
I don't think I have really ever nested more than about three levels worth of Layouts (RelativeLayout, LinearLayout, FrameLayout) in Android. I am not thinking about list items which also use a custom layout for ListView but just normal layouts for an activity.
To the point though, I was chatting with another developer about nesting layouts for a certain layout we were discussing and he seemed to think that even a few nested layouts really slowed down performance. I figured there is some truth but it cant be that much.
Does anyone have a more expert approach to this? Any input? Opinion?
Thanks.
UPDATE for those who found on Google:
The first answer below is a great resource. It looks like a lot and people seem to skip over answers like that but please check it out. Very valuable.
I guess there is no silver bullet for this but I will give you some tips:
1) Try using the tools provided with the android sdk.
I tend to analyze my layouts with hierarchyviewer and layoutopt trying to reduce the amount of View used and the height of the tree.
2) Read Romain Guy's posts about <include>, <merge> and <ViewStub>
These tags are not used often but they provide great speed "hacks".
http://www.curious-creature.org/2009/03/01/android-layout-tricks-3-optimize-part-1/
http://www.curious-creature.org/2009/03/16/android-layout-tricks-4-optimize-part-2/
3) Use dmtracedump and measure how long does it take to inflate a view.
You can check how long it takes to inflate a view. Get an inflater and measure how long it takes to inflate each of your options.
I havent done any proper testing to support this, still, I believe that android was design to use nesting Layouts in order to provide adequate UI's to the user, its practically the only way to support multiple screens so I wouldn't really worry about which is the most efficient, just that it looks the way it should.
Any other kind of bad programming practice would probably have a bigger effect in efficiency than layout nesting.
The difference will be much more important when you use such a layout for every item in a ListView for instance. Hopefully this simple example showed you that getting to know your layouts is the best way to learn how to optimize your UI.
Can't give you a full answer, but Romain Guy has specifically stated that nested RelativeLayouts have an exponential time for measurement.
See video here at 38:08 mark
actually all of them are based on the same class..
but it would be better to use according to me as follows:
<RelativeLayout>
<LinearLayout>
<at> here we just create nested more as we wont></at>
</LinearLayout>
</RelativeLayout>