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.
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.
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.
Can anybody briefly explain the advantages and disadvantages of dynamically modifying layouts as opposed to having static layouts? I faced this question in a quiz. Please explain your answer in detail. The following are True/False questions.
Dynamically-created layouts will appear on the screen and will respond noticeably faster than static layouts will.
Dynamically-created user interfaces can adapt to an application's runtime state, such as the amount of data that needs to be
displayed at any one time.
Dynamic layouts can take advantage of contextual information that's not tracked by Android's configuration system (such as current location, usage time, or ambient light measurements).
Static layouts can't take advantage of contextual information, such as the device's orientation.
The first statement is False because the idea of allowing static and dynamic layouts isn't to improve efficiency but to better seperete the view from the model/controller and to allow changes to the layout without recompiling the code. See here for more information: Android xml vs java layouts performance.
The second and third statements are True because this is information that can only be determined at runtime so to take advantage of that you would need to create some dynamic layout settings e.g. updating a position on a map, or updating the current weather for the area you are in.
The bottom statement is False because you can have layouts in XML files that are named specifically for the devices orientation e.g. layout-land.xml. Android will correctly pick this layout when the configuration is changed to landscape.
Remember that Android allows you to use both static and dynamic layouts but from what i've read most people opt for the static layout options where possible as this separation makes changes to the layout much easier. Dynamic vs XML layout in Android?
Good luck with the course, I believe i'm doing the same one.
Cheers,
Alexei Blue.
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'.