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.
Related
I have a requirement where different views are to be shown on the same screen depending on the requirement. Which approach is better adding respective XML files or writing in java code by using TabActivity class object?
Short answer, defining your layout in code is better for performance than using XML.
Inflating an XML layout involves doing the same work as creating the layout in code, however you also need to parse the layout file (at least the first time it's used) which adds work compared to doing it in code.
HOWEVER, for the majority of use cases the performance hit is not noticeable, and the simplicity of defining an XML layout outweighs the performance benefits of doing it in code.
IMO, Writing layouts file is a better option.
Since, Writing layout will let the view load on compile time.
Whereas, While creating views pro-grammatically leads to slight increase in Runtime operations of the app.
Code written in java means dynamic generation of views are faster than xml rendering as the views increasing. Xml prefers as it is bit easy to implement the design using xml but it gets tough to handle when we use java to create dynamic views.
In your case if you have requirements to create dynamic view then you can create with Java.
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.
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.
I have a short question according to creating GUIs in android. What way is better xml or coding?
I always read that xml is way better but imagine you have a scrollview.
Inside the scrollview is a relativelayout. Inside that there shall be several rows with an ImageView next to a TextView next to a RadioButton. The number of rows can vary.
Is it really better to make lets say 50 Views in the xml or a loop in code where these views are created?
Each has its pros and cons. Just to name a few:
XML
pros -> fast GUI development, keep code clean
cons -> static
Dynamic (code)
pros -> able to react to runtime conditions
cons -> more code, which means poorer maintainability and potentially buggier
If you need to add components dynamically, only way is go with code (or) mixed approach (define layout in XML and add components in code). If your components are static XML may be best.
Dynamic content is, of course, added dynamically. So your example would require some java code. You should only add the dynamic part programmatically though, so you'd still use an xml document for the static parts (it's very unusual for a layout to be completely dynamic).
If you have a fixed number of views then yes, I'd write 50 of them in xml rather than with a loop. I guess you're wondering about code duplication and, as far as I know, you'll get some when using xml.
(One way to minimize code duplication within xmls' is with the usage of styles and themes)
I agree with the above. XML is a better approach to this even when you require dynamic updates you can still use XML bits and pieces to render the content. your code will be based on XML elements but XML files will be independent. hence if you break a funcitonality in the code you know that its your business logic thats broken not the UI part, which will make it easier to develop and find problems easily.
Why you do not use a ListView instead of a ScrollView.
It will be simplier to implement and performances must be better with it.
Create a XML file with a ListView and in your activity implements your own adapter to instanciate the rows.
You can find a lot of tutorials on internet talking about that, I'm sure you will find what you need !
Good luck.
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..