4 Dec 2015

Droidcon Paris 2015

Two weeks ago we were at the Droidcon Paris. We won’t do a report of each conference but a summary of each topics dealt during those two days!

We’ll see the following topics:

  • Performance of an Android app
  • Android build system
  • Test your Android app
  • Languages and tools

2015-11-09 08.45.57

Performance of an Android app

Based on the following conferences:

  • Performance matter – Ran Nachmany, Google
  • Let’s sprinkle some #PerfMatters on our ViewGroups  François Blavoet, Deezer
  • Advanced Scrolling Techniques on Android – Cyril Mottier, Captain Train

Hardware limitation

A mobile has limited network, battery, CPU and memory. You must save them to make your app a great app.

Battery

To save the battery you should defer the work if you don’t need the result immediately. You can use wake locks, and batch them, to plan your work. A best practice is to use a timeout when acquiring a WakeLock in order to be sure that it will be released even if there is an error.

Network

To save the network you should prefetch the data that the user might use and batch the other type of data.

You can use analytics to know how much data you need to prefetch. The side effect is that you will improve both the battery life and the UX of the app.

If you want to batch data you can queue requests and launch them when the mobile is less used by using the JobScheduler or GcmNetworkManager (pre Lollipop).

Another best practice is to use FlatBuffers instead of Json. Json is great because it’s human readable but it’s not machine optimized. You can see how Facebook used them to improve the performance of its app on their technical blog:  Improving Facebook’s performance on Android with FlatBuffers.

Memory

GC events eats framerate. If you want your app to be smooth at 60 fps you should prevent GC. The most greedy actions are:

  • handling images: avoid them by using Picasso or Glide
  • using HashMap: use ArrayMap when using less than 1000 objects or maps of maps
  • using autoboxing: use primitive instead of objets

Views

If you want to debug your frozen application you can use Systrace. It will give you advice on what could go wrong. If you want to debug your views you can use Hierarchy Viewer.

One way to improve the rendering of your views is to merge you views and layout them manually.

Android build system

Based on the following conferences:

  • Keynote – Evolution inside the build system – Eric Lafortune, GuardSquare
  • Squeezing the last drop of performance out of your Gradle builds – Madis Pink, ZeroTurnaround
  • Level up your Android Build – Florian Mierzejewski, Novoda

A new build system

Google is working on new build system composed of two tools: Jack and Jill. It is already the default build tool on AOSP. You can use it by adding useJack = true in your gradle file.

Jack compile source code (.java) into dalvik bytecode (.dex) in a single conversion step. It doesn’t need to use temporary files (Java bytecode and optimised Java bytecode).

Jill converts the library (.class) into intermediary bytecode and caches them.

Jack and Jill won’t improve the build time but will optimize the size of the app (-39% with Google I/O 2015 app) and will support Java 8 and closure! Furthermore, it doesn’t improve runtime performance, you still need to use Proguard.

Optimize you build

If your build time is long, you can measure it with the options “–dry-run” and “–profile”.

Some general tips to improve it:

  • Update Gradle: after the version 2.4 the build are cached. Find your version on Gradle website.
  • Keep Java up-to-date
  • Use a SSD because Gradle does tons of I/O
  • Add –deamon to reuse you Gradle instance
  • Add –configure-on-demand if building multiple projects
  • Use multidex with minSdk 21 on your debug build

If your build is still too slow, you’ll have to understand what takes times. For instance:

  • Do you change dynamically some value with buildConfigField (for instance to save the build date)?
  • Can you extract some code into a module and add it as a dependency?

Test your Android app

Based on the following conferences:

  • Comment tester (vraiment) une application Android – Thomas Guerin, Deezer
  • Testez unitairement votre code, même votre UI ! – Stan Kocken, Freelance
  • Linty Fresh – Matthew Compton , Big Nerd Ranch

The previous conferences details very well how to test your app, I recommand you to check the presentations. They are very detailed and I don’t have the pretention to summarize them.

You can also create custom Lint Check to check best practices while you develop your app. You can for instance add a lint to check if there are enums in your app. A code sample is provided on GitHub.

Languages and tools

Kotlin

Kotlin the main subject of the 2nd morning. It’s a new language which is integrated in the IDE, concise and light weight. Kotlin is a functionnal programming language. Its main benefits are that it support Lambda, has null safety and provide extensions. You can easily use it in you app because it can be mixed with Java.

We watched a live coding session on how to create an geolocalisation app with the Google Play Services with less than 200 lines of code! It was pretty impressive!

Android Data Binding

The Android Data Binding library allow to bind data to the view from the XML. It allows you to easily create new attributes, for instance imageUrl on an ImageView. It helps to remove all the boilerplate to initialize the view and do the binding.

This library is still in beta and there are some detractors such as Jake Wharthon. If you still want to use it, the documentation is pretty good.

Conclusion

It was two very interesting days and if you couldn’t make it, I recommand you to watch the videos on YouTube.

Share