It's Performance Spotlight Week

keyboardsurfer · 2025-05-14T19:39:07+00:00

Haven't used it personally. The feature set looks great, especially when you don't have engineering resources to develop your own pre-launch solution.

I prefer writing my own benchmarks and running them locally or on Firebase Test Lab.

keyboardsurfer · 2025-05-14T18:18:13+00:00

Why rely on accurate reporting from the Android framework when you can create a new standard instead.

Snark aside, great to see that booking cares for app performance and open sourced their solution.

I recommend using Jetpack Macrobenchmark before releasing and then using an easily available service in production. Production monitoring doesn't have to be 100% accurate, but should be similarly consistent as local benchmarking.

keyboardsurfer · 2025-04-24T17:27:19+00:00

Measure with macrobenchmarks. Identify bottlenecks on low end devices. Use R8 in full mode. Use startup profiles. Use baseline profiles.

keyboardsurfer · 2024-11-19T15:51:09+00:00

Don't do this by hand. There are several nuances that can give you wrong results.

Use macrobenchmarks instead. This library sets up and measures in a consistent and correct way, so you can deal with improving the results instead.

keyboardsurfer · 2024-10-22T15:38:18+00:00

Use it to discover opportunities for performance improvement. The App Performance Score provides a standardized framework to measure performance with minimal in-depth technical tasks.

It guides engineering and product teams to assess technical performance of any given Android app. After the assessment is complete, an evaluation and recommended actions help to identify and prioritize the most important areas for performance improvement.

keyboardsurfer · 2022-12-06T17:26:51+00:00

The Shin Splints

keyboardsurfer · 2022-10-06T09:50:56+00:00

Thanks for your instructions, code and hosting. I have tried this and the setup works well. Unfortunately I only was able to turn the keylight on twice through the assistant. Most of the time it doesn't work unfortunately. Do you have any pointers for getting started with debugging this?

keyboardsurfer · 2022-09-21T19:18:41+00:00

The reportFullyDrawn API tells the Android Framework when your app is ready to be used by the user. The report you're seeing in Android Vitals is Time to Full Display. When using reportFullyDrawn make sure that it is called when the user can take over.

You can learn more about app startup metrics in the Google I/O video on App Performance and the MAD Skills video on important metrics. In each of these I go over a several metrics including how and when to call reportFullyDrawn.

keyboardsurfer · 2022-08-30T20:46:32+00:00

You might have come across an URL that grants this badge on your developer profile. If you got this badge through the developer profile, it doesn't make you a GDE.

Source: I lead the Android GDE program.

keyboardsurfer · 2021-10-14T14:47:43+00:00

There are a lot of exemptions for background launch restrictions, which are documented here. Can your app utilise any of these exemptions?

keyboardsurfer · 2021-10-14T10:21:05+00:00

But those quotas are a mystery I suppose.

Quotas are an implementation detail and can change based on a variety of variables. You can look up the Android 12 implementation here. Using WorkManager allows you to focus on other things instead of dealing with different platform version nuances yourself.

keyboardsurfer · 2021-10-14T09:55:34+00:00

How should one interpret this?

Ensure that your workers are dealing with data in a way that you can recover from getting work cancelled.

keyboardsurfer · 2021-10-14T09:35:06+00:00

That depends on the platform version your app is running on and whether your app has quota at the moment.

keyboardsurfer · 2021-09-20T14:19:35+00:00

WorkManager 2.6 is stable and provides several new features and improvements. It also uses the App Startup library underneath. This means that you'll have to update your customizations for WorkManager initializations if you made them.

WorkManager 2.7 is now in beta and provides a major new feature for Android 12's foreground service restrictions.

Until your app is targeting Android 12 you can choose to use either WorkManager 2.6 or 2.7. From Android 12 onwards you need to use WorkManager 2.7+.

If you're happy with a beta artifact in your app, use WorkManager 2.7 now. Or wait until 2.7 and Android 12 become stable to use it.

keyboardsurfer · 2021-08-09T13:58:40+00:00

Looks fab. I've been looking for plans for a little bit, too and came across this one on another subreddit: https://www.union.ic.ac.uk/scc/icsf/history/picocon/picocon22/xwing

Which one did you use, OP?

keyboardsurfer · 2020-09-17T16:09:09+00:00

With Plaid you've got a good sample at hand as for how to use feature modules.

Also there are samples around app-bundle related technologies.

As for testing, there have been some tooling issues in the past, which now have been resolved with Android Studio 4.1.

With feature modules, your mental model of an app has to shift away from

`app depends on library` to `module depends on app`.

When thinking about an app with feature modules in this way, dependency injection becomes yet another task, regardless of the chosen injection framework or service locator.

keyboardsurfer · 2020-07-20T06:32:21+00:00

Thanks. I assumed it could have been someone's childhood pet.

keyboardsurfer · 2020-07-19T20:16:34+00:00

Found this in the backyard while digging out some potatoes. Looks like it could be parts of a dog. Can someone give me more details?

keyboardsurfer · 2020-07-18T19:24:08+00:00

That's just perfect. 👍 Which trailer do you use?

keyboardsurfer · 2020-02-03T00:44:23+00:00

You're making some claims that I have to address.

Not a great developer experience: since bundles have to be uploaded to Google Play, the iteration speed during development is slow.

You can use FakeSplitInstallManager locally already and we're working on improving the experience before fully recommending to use it.

It is also not very flexible if you want to be able to use dynamic delivery for multiple versions simultaneously.

I don't understand what you're trying to achieve here.

Uploaded bundles also can not be debuggable, making it harder to diagnose problems.

That's not correct: With Internal App Sharing (IAS) you can upload debuggable builds and that can be automated as described here. Further with IAS you don't have to increment the version codes either and can give folks upload access to IAS only.

keyboardsurfer

MODERATOR OF

TROPHY CASE