Has anyone seen or compiled benchmarks comparing declarative (XML) versus programmatically created UI's in Android?
There are things that Google has done to speed up the declarative approach, but you still do have the layout inflation step done at runtime.
Have you ever switched (or considered) changing your UI from declarative to programmatic for any reason?
Declarative UI requires thinking about app development from a new perspective. Declarative UI requires thinking about app development from a new perspective, accepting that it's okay to rebuild parts of your UI from scratch instead of modifying them. Modern CPUs are fast enough to do so, and can even handle animations.
There are several declarative UI frameworks like Flutter, React native, SwiftUI and Jetpack compose. Jetpack compose is a UI toolkit that makes use of declarative UI paradigm to create Android application's UI.
Flutter is declarative. This means that Flutter builds its user interface to reflect the current state of your app: When the state of your app changes (for example, the user flips a switch in the settings screen), you change the state, and that triggers a redraw of the user interface.
Declarative programming is a paradigm describing WHAT the program does, without explicitly specifying its control flow. Imperative programming is a paradigm describing HOW the program should do something by explicitly specifying each instruction (or statement) step by step, which mutate the program's state.
Very little of the layout inflation is done at runtime. As hinted in the LayoutInflator API docs:
For performance reasons, view inflation relies heavily on pre-processing of XML files that is done at build time. Therefore, it is not currently possible to use LayoutInflater with an XmlPullParser over a plain XML file at runtime
If you take a look at the source, many of the views are pulled from a hash map based on their XML tag.
In answer to your question of whether I have benchmarked the inflater, I have to say no. Personally I find the idea of benchmarking the layout inflater in Android for your app to be the equivalent of benchmarking the DOM parser in Firefox for your website. I don't think the exercise is pointless, but you should have a much better reason than "my activity layout is too complicated for the inflater"...
If you require a dynamically generated layout, you would be best off creating it programmatically. If your view is simply taking a long time to inflate, you should simplify your view XML.
I've developed this class to pre-inflate a pool of views and reuse it everytime I need. I've gained seconds in performance while updating UI, which is quite impressive.
My Logcat says:
updating UI inflating on demand >> 2136mS
updating UI reusing from pool >> 937mS
Here is my class, just don't mind my clumsy Java coding style, I'm a C++ embedded programmer.
import java.util.ArrayList;
import java.util.List;
import android.view.LayoutInflater;
import android.view.View;
public class ViewPool {
private List<View> mViews;
private LayoutInflater mInf;
private int mIdx;
private int mResource;
/**
* Constructor, gives Inflater and resource ID to inflate
* @param mInf Layout inflater
* @param rID Resource ID of view to inflate
* @para number number of views that must inflate on first initialization
*/
public ViewPool(LayoutInflater mInf, int rID, int number) {
super();
int idx;
mViews = new ArrayList<View>();
this.mInf = mInf;
mResource = rID;
mIdx=0; // index of first used item
for(idx=0; idx<number;++idx)
{
mViews.add((View)mInf.inflate(mResource, null));
}
}
/**
* Start from first item of pool
*/
public void Reset()
{
mIdx=0;
}
/**
* Get a view from pool, if no more views on pool, inflate more
* @return
*/
public View GetView()
{
View retval;
retval = mViews.get(mIdx);
++mIdx;
if(mIdx == mViews.size()) // no more views in pool??
mViews.add((View)mInf.inflate(mResource, null)); // inflate more
return(retval);
}
}
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With