Search for a command to run...
Hi Pierre-Yves Ricau! Thank you for writing this article and using Hashnode!
I'd like to suggest you add your social media links, like Twitter and Github (if you use these platforms), so people can find and follow you easier 😊.
Exactly one year ago, after 12 years in San Francisco, I moved back to France. Life since has been a whirlwind: selling the condo, moving a container overseas, rediscovering French culture (I had to r
The SQLDelight documentation provides this example: val players: Flow<List<HockeyPlayer>> = playerQueries.selectAll() .asFlow() .mapToList(Dispatchers.IO) This looks reasonable, right? In the Square Point Of Sale application, we recently ...
A failed experiment with dominator trees
In this article I run the new LeakCanary toolkit against the Slack Android app. Read on to learn a bunch! A new LeakCanary toolkit In two months, I will give a talk at Droidcon SF: Cutting Edges: universal heap trimming with LeakCanary 3 At Square, ...
Today I was mob programming with Square's Mobile & Performance Reliability team and we toyed with an interesting idea. Our codebase has classes that represent screens a user can navigate to. These classes are defined in modules, and these modules hav...
Header image: Caterpillar by Romain Guy.
In 2020 I started a series of Android performance deep dive blogs: Android Vitals. I'm currently working on releasing an Open Source library that helps with performance monitoring in production, and today I want to write a high level summary of what I've learnt and look at how we can properly measure Launch Response Time in production.
Note: until now I've been writing at dev.to/pyricau, this time I'm trying out Hashnode to see how it feels. Feedback welcome on whether I should continue here or back there.
system_server process tells your app process to start loading your APK code and resources and calls Application.onCreate() (learn more). This happens only once per process, and usually starts with a fork of the Zygote process, but not always. You can have a Process Start not triggered by an App Launch.App Launch is often called App Startup, but I like to avoid the verb Start, as bringing back an app from recent isn't really starting anything from a user standpoint.
In When did my app start? ⏱, I concluded that process start time should ideally be measured when your app code and resources load. You need to use a different approach depending on the API level:
Process.getStartUptimeMillis() not available yet).Process.getStartUptimeMillis() is sometimes way off. Use Process.getStartUptimeMillis() but filter out weird values (e.g. more than 1 min to get to Application.onCreate()) and fallback to the time ContentProvider.onCreate() is called.In Is this a cold start? 🦋 and Why did my process start? 🌄, I established how to detect that a process start is for an app launch:
Application.onCreate() or earlier is dequeued (learn more).In my experience it's also helpful to track different kinds of process starts / cold app launches to split the data:
At the beginning of this article, I defined App Launch as what happens when an Android application that wasn't visible is brought to the foreground. In practice, this means that:
Launch Response Time starts the time when the system triggers App Launch. I'm intentionally ignoring what happens right after a user taps a launcher icon because this is beyond our control. There are different types of App Launch, so their start time must be measured differently.
A Cold Launch is what happens when the App Launch requires a Process Start. In the Process Start section above, I already outlined how to detect a Cold Launch and measure its start time.
A Hot Launch is what happens when the process was alive and the activity that is being resumed needs to first be started, i.e. was previously stopped but not destroyed. As far as I know, the best way we have to measure its start time is by recording the time of the call to ActivityLifecycleCallbacks.onActivityPreStarted()).
A Warm Launch is what happens when the process was alive and the activity that is being resumed needs to first be created, i.e. it was previously destroyed or never created. As far as I know, the best way we have to measure its start time is by recording the time of the call to ActivityLifecycleCallbacks.onActivityPreCreated()).
Launch Response Time ends when the display has rendered the first frame of the window of the activity brought to the foreground. I'm ignoring the preview window rendering (can't use the app yet) and considering only the first drawn frame, but some apps might prefer waiting for extra async loading to finish.
We want to know when the display has rendered the first frame of the window of the resumed activity. Here's how we can do it:
onResume() we can register a OnPreDrawListener.TOTAL_DURATION measures time from the intended vsync start, not the actual vsync start, so without this we'd end up measuring a longer launch time.onPreDraw() callback to measure the end time, with the assumption that the front of queue message will be processed right after the current frame is done rendering. Starting with API 22, we should also call Message.setAsynchronous() to avoid that message being delayed by a Looper synchronization barrier.I hope you enjoyed this summary of a year of deep dives! A huge thank you to Romain Guy for helping me make sense of all the display stuff, Chet Haase and John Reck for answering my questions about JankStats implementation details, and Jun for helping me realize my deep dives were in dire need of a high level summary and for his great feedback on this blog before I hit publish.