Join us for the monthly mini-profiles on Firebase team members, aka “Firebasers”, from all around the world! Learn about their backgrounds, how they got started with Firebase, what Firebase products they work on, their favorite ways to de-stress, advice, and more.
For our first feature, we’re happy to introduce you to a long standing member of the Firebase community. You may know his work from Firebase Release Notes, one of his talks at Google events, or used one of his many community responses from Stack Overflow. And now, we give you puf!
I was in the habit of answering questions on Stack Overflow to learn about interesting new technologies, when questions about Firebase started showing up. My answers got noticed, and that led to me becoming a member of the Firebase team at Google. And 7 years later, answering questions about Firebase on Stack Overflow is still one of my favorite things to do each day!
I just gave a talk at Flutter Vikings about synchronizing game state in a Flutter app, and, as part of the Flutter Puzzle Hack, about adding Firebase to your Flutter app. I'm also working with the Flutter GDEs to get more/better Flutter answers on Stack Overflow. Between that, answering questions on Stack Overflow, and the monthly Firebase Release Notes video, I keep busy. :)
Not sure if it counts as a nickname, but I am known as puf. While I respond to both Frank and puf equally, I'm usually the only puf in the room. I got the nickname in my teens, as I was really tired of all the variations of my last name, and I've been known as “puf” to most people since then.
I read a lot. I just finished The Lincoln Conspiracy and am halfway through Carve the Mark and The Brothers Karamazov.
You can find me on Twitter here.
Mobile users expect their apps to be fast and responsive, and apps with a slow startup time, especially during coldstart, can leave them feeling frustrated. Firebase Performance Monitoring is a tool that helps you gain insight about various app quality signals, including startup time of your application. This article gives a deep dive into the Firebase Performance Monitoring tool and its impact during an Android application’s cold start.
Modern Android applications perform multiple operations until the application becomes responsive to the user. “Startup time” of an application measures the time between when an application icon is tapped on the device screen, to when the application is responsive. Code executing during startup time includes the application's code, along with code from dependencies that are involved in app startup. Any code that executes until the first frame is drawn is reflected in the time to initial display metric.
Many libraries do not need to get initialized during the application startup phase. Some libraries, like Firebase Performance Monitoring, provide value by initializing during the startup phase. It is this early initialization that enables measurement of app start, CPU/Memory impact during early phases of startup, and performance of network requests during application startup. But, this could lead to an increase in the startup time of the application.
You can measure the impact of a library during your app’s startup by creating 2 versions of your app (with and w/o the library) and measuring the “time between Application launch to Activity firstFrameDrawn” in both to compare.
Firebase Performance Monitoring performs the following tasks during an application cold start:
Firebase Performance Monitoring does all these without developers needing to add any lines of code to their application.
There are many tools available to profile the performance of an application. We used the following tools for measuring the startup time and analyzing the impact of every single method in our library during application cold start.
Macrobenchmark is a recent tool launched at Google I/O '21 to measure the startup and runtime performance of your application on physical devices. We used this tool to measure the overall time taken by an application during a cold start.
Method tracing enables understanding all the classes/methods that were involved in the runtime of an application. This lists down the different methods that get executed at runtime and the duration each method takes for execution. Due to the overhead of method tracing, the duration of methods as specified in the trace file is bloated. Nonetheless, this duration can be used as a guiding metric to understand the impact of a method.
Using the method tracing APIs, we identified multiple opportunities within the application’s lifecycle events to reduce the impact of the library during application startup, including:
We optimized the library in all these phases. Some key optimizations include:
To benchmark the impact of Firebase Performance Monitoring, we built a simple Android application. Benchmarking performance depends on various factors. To make this measurement close to user needs, we measured the startup time with the following factors.
We ran the application with and without Firebase performance library to understand the startup time impact caused by the library. We used macrobenchmark to measure the duration of the startup time.
For an empty application with the above ground conditions, the table below captures the impact of the application startup before and after the optimizations.
With all the above changes, we have been able to reduce the impact of the library during startup time by more than 35%.
Application startup time improvement is a moving target for all developers. Though device hardware has been dramatically improving in recent years, the challenge of improved startup time performance continues to push barriers. We are continuously investing in reducing the startup time impact.
Update your Firebase Performance Monitoring SDK to the recent version to get these recent improvements on startup time, realtime metrics and alerts.
