A few months ago I discovered that the Google Analytics Java library for Android can interfere with the performance of your application because it accesses a database on the main thread.
Not wanting to abandon analytics, I’ve been using this class ever since. It’s a useful wrapper around the GoogleAnalyticsTracker class which I thought I’d share because it’s simply very useful. It:
Using it is very simple, here’s an example:
And here’s the class which you’re welcome to use in any of your own projects.
I’ve been unable to code for the past week, so as I started to ease myself back in today, I took time to investigate a phenomenon I first noticed months back.
Reto Meier has been a strong advocate for the use of analytics, his code and all the available sample code indicate that you call the analytics tracker on the UI thread. But if you use the Google Analytics SDK for Android like this, calling the tracker on the UI thread, it can make your app very unresponsive. I noticed this after adding the library to my Metaglow application, buttons that had felt very snappy immediately felt sluggish, even though I’d taken care to keep the UI thread ‘hygenic’.
Today I sat down and wrote a little stub of code that collects some basic call-time statistics for the GoogleAnalyticsTracker class from version 1.1 of the SDK. I made a few runs on my Nexus One by proceeding to use Metaglow over an extended session. In each run I collected timings for approximately 100 calls to the trackPageView and trackEvent methods.
Of the three runs, these were the most typical numbers (one set slightly was slightly faster, one set was significantly slower):
So, you can expect users to occasionally encounter UI glitches of 1/5th* of a second or more just from queuing an analytics event; and (admittedly I don’t have figures for this) it’s my experience that the pauses are more significant than this; infrequent, but long when they occur; this gives a bad user experience.
It’s documented that the analytics data is queued into batches and dispatched separately from the call that records them, so this behaviour (infrequent but lengthy pauses) can’t be due to network I/O. But it is what we are told to expect when we are performing writes to Flash storage. So I used traceview to peek inside the execution of the analytics code and confirm that this was the cause.
Those green blocks, which are just about visible, are writes inside Sqlite3 and this explains the uneven performance.
Since I want to keep analytics I will probably write my own event queue around the Google analytics tracker, to decouple it from the UI thread. If you use Google analytics and want to give users a smooth experience, you may need to do this work too.
(*) this figure is based on 2 standard deviations above the mean
