A Saga of Improvement in Android App Performance — Part 1
Why performance is Important?
The performance gives a soothing and faster experience to the user because of which he/she prefers your application over other apps in the same category. It helps to give you a competitive edge over others while bad performance can give an unsatisfactory experience to user which can turn into a customer and business loss. In short, good performance in the app translates to happier customers and the success of your application.
Introduction
We all want our apps to perform better, but we are always confused about how to define the performance or right metrics of performance? is it good or bad? how can we improve or maintain this?
In this blog series, I will cover how we improve and maintain application performance in Tokopedia.
We consider that performance in apps broadly has two aspects first is speed and the second is smoothness. Let’s learn more about this.
Improvement Stages
We follow 4 steps improvement cycle as described below image:
This process, not only helped us to improve our application performance but also to maintain and prevent it from regressing.
Using this cycle we are able to improve the app start time and home page load time by ~40% along with significant improvement in metrics for other pages as well.
In this part of the blog series, we will go through the part of the Monitoring step.
Monitoring
This is the most important step, It helps us to keep an eye on the metrics required to represent the application performance. It enables us to identify the gap from the target and make sure that it doesn’t regress. It allows us to validate the production and pre-production build and notify us about any change that might result in bad performance well before merging.
There has always been a question asked, what do you mean by good performance? To answer this question, we came up with the following 3 metrics along with the targets:
App Start Time: Time to launch the application for 95 percentile of users until the first screen is interactive. This is the application-level metric. Lower the value, better is the performance. We are targeting it to be below 2.5 secs for 95 percentile of users.
Frame Performance Index (FPI): FPI is a metric that measures bad frames in a session. This metric defines the smoothness of the page. The formula to get the FPI is “100 — (janky frames / total frames * 100)”, here janky frames are the number of frames that took longer than 16 ms to render. A higher value reflects better performance in terms of smoothness. We are aiming to maintain it above 90% for all important pages.
Page Load Time (PLT): PLT is a metric to measure time duration from page opened until the user can interact. Lower the value, better is the performance. We defined less than 2 secs for 95 percentile of users as the target for all important pages.
Monitoring is important for both the production and pre-production environment, to make the improvement cycle effective. In this part, we will cover the production app monitoring.
How we capture the metrics for a production app?
We use Firebase performance monitoring to measure the metrics for a production application. If you have integrated Firebase Performance in your app, by default it captures some data like app start time, frames performance data per activity, and network data.
For PLT, we add the custom traces for all the activities we wanted to improve. To capture the PLT, we start the trace before super.onCreate() call in Activity onCreate function and stop after API response and rendering of the data on UI.
You can refer to the below sample code, to see the firebase performance monitoring start and stop implementation for capturing the PLT metric.
@Override
protected void onCreate(Bundle savedInstanceState) {
startHomePerformanceMonitoring(); super.onCreate(savedInstanceState); doSomeInit();
}private void setOnRecyclerViewLayoutReady(boolean isCache) {
homeRecyclerView.getViewTreeObserver()
.addOnGlobalLayoutListener(new
ViewTreeObserver.OnGlobalLayoutListener() {
@Override
public void onGlobalLayout() {
//At this point the layout is complete and the
//dimensions of recyclerView and any child views are known.
if (homePerformanceMonitoringListener != null) {
homePerformanceMonitoringListener.stopHomePerformanceMonitoring(isCache);
}
}
});
}
How we build performance monitoring Dashboard?
To check the performance data, we can directly view it on Firebase. But Firebase doesn’t allow us to view data for all the screens on one page and also charts are not displaying the health of metrics as per our target. To overcome this challenge and make the monitoring easy & effective, we need to view the data on one page and its health in comparison with our targets.
To build a monitoring dashboard, we enabled Firebase performance data export to BigQuery. We scan the last seven days data from BigQuery once in a daily and expose that data to DataStudio to display the charts with app start and per page metrics for a production application.
BigQuery charges you based on data scans and data stored. So to optimize the scans, we run scheduled queries and create a separate table using results. We run these queries once in a day. This helps us to reduce the cost of scanning Big Query data.
You can look at the sample big queries below to pull the data for FPI and duration traces. The following queries can be used by just changing the project id and BQ table name.
We connect the Data Studio with the tables created using the above queries and prepare the graph to reflect the performance of the Application. We have to build a single page dashboard for covering all important pages. We used a line chart along with a scorecard chart in Data Studio. ScoreCard Chart displays the latest version metric in red/green based on the target condition.
This dashboard helps us to view the performance of the application for all the important pages on one screen.
You can refer below the image of the App Start metric graph. we display similar graphs for FPI and PLT of all important pages in the same dashboard.
Conclusion
In this part, we described the stages being followed to improve the Android app performance, how and what all metrics we measure for a production application?
We discussed our in-house solution to monitor the production application performance metrics and why we need this.
In Part2 of this series, We will continue with the Monitoring step and will share, how we measure the Pre-Production builds and how we use the PR checker for performance validations.
Stay Tuned 🙌 Happy Reading 🙏
References
https://firebase.google.com/docs/perf-mon/get-started-android
