Performance comparison - building Android UI with code (Anko) vs XML Layout.

Performance comparison - building Android UI with code (Anko) vs XML Layout.

Andrew Drobyazko

Hi!

This is my first blog post.

Intro

Here I will be talking about difference in performance between using XML layouts and Anko to build UI for Android apps.

As you may know, Anko is a new DSL for Android, written in Kotlin. It helps a lot to develop Android apps using Kotlin lang. Anko provides various handy features, and my favorite is building ui with code. Yeah, you can tell me that we can also build user interface using Java, and create all Views in code, but it is ugly and hard to maintain.

The problem

By default, UI in Android is built using XML layout files. This is inconvenient because it is not typesafe, not null-safe, and it leads to overhead in cpu and ram usage. It can be insensibly for fast and powerful devices, but low-end devices may suffer from resources deficit. The more Views you have in your xml layout file, the more time it takes to:

  • inflate view from XML file
  • create view objects
  • find views by id with findViewById

Now imagine, that you need to perform that actions for multiple layouts, for example if you need to display list of items. In this case android will perform every step of those 3, for every list item in your UI. It will be even worse if every list item have more than 5-7 views. More views you have, more time it takes to display them.

By using Anko (or creating Views programmatically, even with Java) we can remove 2/3 of that work:

  • ~~inflate view from XML file~~
  • create view objects
  • ~~find views by id with findViewById~~

Also it is easy to create UI with Anko, if you’re familiar with android Layouts.

Benchmark

For benchmark i will use two Activities, with two similar lists of users. I think it is a typical case for Android apps. For every list item i will be using RelativeLayout with 4 views inside:

  • user avatar (using Fresco)
  • user name
  • user title
  • last seen date

After that i will measure onCreateViewHolder method execution time for every item.

device

Benchmark results

Well, i tested both cases on these devices:

  • android emulator on MacBook pro 15 2015
  • Meizu mx-5
  • THL w8 (low end)
  • Nexus 6 Marshmallow
  • Meizu mx-4
  • Samsung Galaxy S2 Plus
  • Samsung Galaxy S3
  • Samsung Galaxy J5

All values are in milliseconds, that needed for onCreateViewHolder method to execute inside the RecyclerView adapter.

Please note that frames on Android are drawing every 16 milliseconds, and if any frame will not be able to draw in that period, it will draw after 32/48/64... ms, and this is called dropped frames. So every time your frame takes >16ms to draw, it is dropped. Also note that your UI thread will have more work than just drawing frames, it need to handle all user input, and execute all of your code too. It means that less milliseconds to draw is better for us.

And here is what i got:

2016-04-18 17 13 40

Macbook XML results * Macbook Coded results

Meizu MX5 XML results * Meizu MX5 Coded results

Thl W8 XML results * Thl W8 Coded results

Nexus 5 XML results * Nexus 5 Coded results

Meizu MX4 XML results * Meizu MX4 Coded results

Galaxy S2 Plus XML results * Galaxy S2 Plus Coded results

Galaxy J5 XML results * Galaxy J5 Coded results

Galaxy S3 XML results * Galaxy S3 Coded results

Conclusion

As I thought, building User Interface on Android is faster with code, than with XML layout files. And this is true for all kind of devices/sdk’s.

We can see up to 300% performance boost here.

There is not a big (relatively) boost on high-end devices, but low-end devices can have huge boost using coded ui.

Should we use coded UI everywhere? - Only if you are using Kotlin, and you have some extra time for optimizations

Should we use it if we have large amount of Views into single list item? - I would say YES

Should we use it if our customer has low-end device, and says that app is freezing all the time? - Answer will be yes too.

Source code can be found HERE

P.S. You can try that benchmark by yourself, on your device. Just check the repo