Could There Be Any Performance Difference Between Writing The Same Code (for The Layout) In Xml Or Java File?

I know that there are differences in what you can and can not do in XML and a java file, but so far I understood that a java file can do everything a XML file can do, at least that

Solution 1:

creating the ui hierarchy by hand in your activity class will be faster but MUCH more complicated than using xml layout files (about the LayoutInflater performance see its createView(String name, String prefix, AttributeSet attrs) method used when inflating the layouts and you will find out its not a speed daemon), i cannot give you any numbers in % though

Solution 2:

Maybe there is no efficient or appropriate way to weigh the performance difference between the xml layout and the java code. But for the development convenience's sake, I would decide to use xml rather than java codes. After all, you have Palette to render your xml layout file instantly. And there is Smart Recommends of attributes of widgets when you writes xml. And you can drag and drop widgets too. But can you do this when writing java file to layout your widgets? And how many lines will you write when a structure is way too complicated?

Solution 3:

I wouldn't bother much about the performance difference between XML and programmatically designed UI.

Basically the XML approach is always to be favored over the programmatical approach. XML designed UIs are easier to read and to understand, and since an UI is something visual, I would go as far as saying that readability is the key in the developement of an extensible AND maintainable UI.

Worst case scenario in readability for the programmatical approach would be when every element of your UI was designed in different files. Imagine an element that is designed in one file then added to the form in another file, with the form being also designed in another file. You would not know what's the deal and for a simple change like adding a button or a label or even just changing some text, you would have to go through a lot of code.

This means you would lose a lot of time in further developement of that UI and at some point it would not be maintainable at all(well you might be able to maintain it but imagine a big project with many developement teams involved, where more than just one person needs to understand the concept and the structure in order be able to keep the developement going)

Of course you can't always design your UI in XML. For example: If you have custom modular control elements which are more complex than just a display for a text and you want to display a dynamical amount of them, which depends on a result from a database query, then I guarantee you that you will have to add them programmatically to your form. ELSE you would have to add a fixed maximum amount of them to your form in the XML and then supply them with data and toggle their visibility in the code. Trust me you wouldn't want to do that ;) And now to answer your question: I say the XML approach is slower. With your XML having to hold the maximum amount of objects possible for display you will always have overhead of objects being loaded and maintained in the life cycle, which are not even used. Objects being generated dynamically, will cost less performance, since their amount varies and thus is not fixed.

EDIT: If you care much about the peformance of your UI, I recommend you to perform some studies on the lifecycle of the form and also control elements. The UI is created in phases and in this act certain events are fired. It can have a great impact on the performance if you decide to update the displayed information at a certain phase. I might have never developed anything for android, but having worked with actionscript and asp.net I learned that UI performance and the life cycle of display elements go hand in hand.

EDIT 2: Another great impact on performance has the location of the controls you use within their inheritance structure tree. Take a look at this theoretical inheritance structure:

Object -> UI-Element -> Display-Element -> Image-Element

Lets say you have only one Image to display. In this case you can basically go with the Image-Element without even thinking. But if you have a lot images to display which also change in size, and maybe even location, then it might be a good idea to keep away from using the Image-Element and write a custom element which inherits lets say the UI-Element and fits your needs. The custom control element would be faster since it is closer to the root of the inheritance structure tree. Reason for this is generally speaking: each time you move further away from the root you gain functionality and more functionality comes at the cost of performance.

Solution 4:

Truth is this: everything done in the UI thread slows the UI. So, if you declare a layout programmatically it will slow the principal thread, and you can't add a view if you don't create it on the main thread (someone correct me if I'm wrong). Try to avoid this if it is possible.

This also refers to this question Best practices: Layouts on Android (Programmatic vs XML)

Doing all your views in Java code would take, compared to xml designing, too long to finish while xml is more understandable and has a visual editor in your IDE if you are using Android Studio or ADT. I highly recommend you use xml to design your app's activities/fragments.

EDIT 1

This question solves the view creation in UI thread Can I create UI outside main thread (UI Thread)?

EDIT 2

To clarify, Android does create views "programmatically" when it inflates. The real big operational difference is that when you inflate a full layout Android re uses some components while doing it programmatically doesn't ensure this.

This is the related stackoverflow question

EDIT 3

As pointed out by @pskink, I've just looked at the code of LayoutInflater#createView(String name, String prefix, AttributeSet attrs) and it calls Java's classLoader. This loader creates a class if it's not in memory so it is just as inefficient to use createView programmatically than doing it by xml. So is just as slow for the UI to use an xml layout than inflating views programmatically so it does not affect to performance.

There is one "but" to this answer, Adapters have a different way to work because they re use views, but if used correctly custom adapters will be as effective as default ones.