Improve UI Performance in RecyclerView Layout Part-2

Here is the list of the blogs in this series:

• Part 1 — Common Situations
• Part 2 — Impact of constraintlayout and databinding on performance
• Part 3 — Inflating layout asynchronously

How ConstraintLayout and dataBinding will improve RecyclerView’s performance?

Since announcing ConstraintLayout at Google I/O last year, we've continued to improve the layout's stability and layout editor support. We've also added new features specific to ConstraintLayout that help you build various type of layouts, such as introducing chains and setting size as a ratio. In addition to these features, there is a notable performance benefit by using ConstraintLayout.

We will take an example :

Let’s say we want to build a layout with traditional layouts like this :

<RelativeLayout>
  <ImageView />
  <ImageView />
  <RelativeLayout>
    <TextView />
    <LinearLayout>
      <TextView />
      <RelativeLayout>
        <EditText />
      </RelativeLayout>
    </LinearLayout>
    <LinearLayout>
      <TextView />
      <RelativeLayout>
        <EditText />
      </RelativeLayout>
    </LinearLayout>
    <TextView />
  </RelativeLayout>
  <LinearLayout >
    <Button />
    <Button />
  </LinearLayout>
</RelativeLayout>

this hierarchy is created with some nested views. Although we can improve this type of view hierarchy

As discussed before, nested hierarchies can adversely affect performance, so we will build this layout with flat hierarchy:

This is because ConstraintLayout allows you to build complex layouts without having to nest View and ViewGroup elements. solution for nested layout

<android.support.constraint.ConstraintLayout>
  <ImageView />
  <ImageView />
  <TextView />
  <EditText />
  <TextView />
  <TextView />
  <EditText />
  <Button />
  <Button />
  <TextView />
</android.support.constraint.ConstraintLayout>

Let’s take a look at the difference between ConstraintLayout and traditional layout using Android Studio’s Systrace tool. We called the measure and layout phases for each ViewGroup (ConstraintLayout and Traditional) programmatically and triggered Systrace while the measure and layout calls are executing.

Measurement results:

We did measure compare between Nested layout with traditional layouts and ConstraintLayout. Our performance comparison shows that ConstraintLayout performs about 40% better in the measure/layout phase than RelativeLayout

Measure / Layout (unit: ms, average of 100 frames)

And we compared other cases :

RecyclerView with 100 Items

We measured 100 items built with constraintLayout and also 100 items built with traditional layouts and the difference is :

RecylerView with Items

Complex UI :

We compared ConstraintLayout with traditional layouts on complex views :

Traditional vs Constraint

As these results show, ConstraintLayout is likely to be more performant than traditional layouts. Moreover, ConstraintLayout has other features that help you build complex and performant layouts.

In the N release of Android, the ConstraintLayout class provides similar functionality to RelativeLayout, but at a significantly lower cost.

Additionally, if your app targets Android 7.0 (API level 24), it is likely that you can use a special layout editor to create a ConstraintLayout object instead of RelativeLayout. Doing so allows you to avoid many of the issues this section describes. The ConstraintLayout class offers similar layout control, but with much-improved performance. This class uses its own constraint-solving system to resolve relationships between views in a very different way from standard layouts.

In almost all cases when you would have previously need a deeply-nested layout, ConstraintLayout should be your go-to layout for optimal performance and ease of use.

DataBinding and ViewBinding vs findViewById:

problems of findViewById :

findViewById is the source of many user-facing bugs in Android. It’s easy to pass an id that’s not in the current layout — producing null and a crash. And, since it doesn’t have any type-safety built in it’s easy to ship code that calls findViewById<TextView>(R.id.image). View binding replaces findViewById with a concise, safe alternative.

Not only is this slow, it’s not safe because it’s not checked at compile time. If the ID you pass to findViewById() is wrong, the app will crash at run time.

DataBinding :

The Data Binding — Support library that facilitate you to bind layout’s UI components to data models directly in the layout itself rather than programmatically.

How does it help ?

avoid all the boilerplate of findViewById

code minimalization :

minimize code for activity(xml help activity and split binding)

Android guidelines recommend using databinding to avoid writing extra code in onBindViewHolder

custom property declaration in xml:

can create custom attribute and be applied to every View (since the first parameter is a View you can restrict to certain classes by changing this type) In general, moving code out of the activity is great for maintainability and testability.

performance and ambiguity:

No need to always spend CPU time searching for a specific ID in xml

if 2 same ids in different xml findByViewId will get those 2 however Databinding will get only in specific xml

A public final field will be generated for each View with an ID in the layout.

Method findViewById() returns an object of View type, this object holds the properties values then we need to cast it to the specific element, for example, TextView which is a class to draw the text view this class and all elements’ classes are subclasses of View class so what we do is downcasting, that when this method returns the object of View type we downcast it to the element class

The binding does a single pass on the View hierarchy, extracting the Views with IDs. This mechanism can be faster than calling findViewById for several Views.

How it finds the properties? it finds the properties of the element using the id if the tag in the XML file first it searches in the XML file for the tag that holds the element’s name and then it looks at the id if it is the id which it wants then it takes it otherwise it searches for another tag (with the same element name).

Type-safe :

because properties are always correctly typed based on the views in the layout. So if you put a TextView in the layout, view binding will expose a TextView property.

Null-safe :

for layouts defined in multiple configurations. View binding will detect if a view is only present in some configurations and create a @Nullable property.

Avoid nullPointerException

preventing memory leaks

Memory leaks occur when an application allocates memory for an object, but then fails to release the memory when the object is no longer being used.

Conclusion

Using data binding can lead to faster development times, faster execution times and more readable and maintained code.

Databinding is really faster compared to findViewById and setText . Not only performance, It is also much faster and maintainable for mid, full-scale projects.

I hope you enjoyed this blog and learned something! on the next one, we will be talking about inflating layout asynchronously