Application performance is critical for a good user experience. Slow startups, dropped frames and poor responsiveness are all key drivers of user frustration and, ultimately, attrition.<\/p>\n
Performance consciousness during application development, and use of appropriate data structures, algorithms, caching strategies, and so on, are fundamental parts of mitigating these issues. However, it is equally important to understand the underlying representations of compiled application code, and the manner in which it is loaded and executed, such that build tools and runtimes can be configured and tuned optimally.<\/p>\n
Over the past few years at Meta, we have developed infrastructure for profile-guided compiler and runtime optimizations targeting our Android applications. A major component of this infrastructure is the Android Runtime\u2019s Baseline Profiles feature, which we have leveraged extensively to significantly improve the performance of our Android applications.<\/p>\n
In this post, we\u2019ll describe some performance considerations related to the Android Runtime (ART), explore some related performance challenges we have faced in our apps, and explain how we utilized Baseline Profiles to overcome them.<\/p>\n
ART Performance Considerations<\/p>\n
On Android, the preferred, and thus dominant, languages for user application development are Kotlin and Java. Kotlin\/Java code is compiled to Dalvik bytecode (\u201cDex code\u201d) and packaged into \u201c.dex\u201d files, which are organized into classes and methods reflecting their original sources.<\/p>\n
Before any dex code associated with a method can be executed by the Android Runtime, its parent class must be loaded by the runtime. This happens when a class is first accessed during application execution, and involves locating the class\u2019 metadata, registering it with ART, initializing static data, and anything else required to interact with the class.<\/p>\n
Once its parent class is loaded, its methods may be executed. Dex code is, of course, not machine code that can be directly executed on hardware, and thus the Android Runtime must perform this translation. By default, at runtime, methods in dex code will simultaneously be executed via interpretation and profiled to determine if they are hot. Once a method is determined to be hot, it is compiled to machine code via ART\u2019s just-in-time compiler, and the compiled version is executed thereafter. (Executing machine code is generally significantly faster than interpretation.)<\/p>\n
Both class loads and the interpretation\/profiling stage of dex method execution have runtime cost, which often result in temporary, but user-perceptible, performance degradation.\u00a0 Furthermore, classes must be re-loaded following every app cold start. Cold starts<\/a> happen when the system starts the app for the first time. After a cold start, the app is in memory, and subsequent starts are much faster. (Note that this is somewhat mitigated by \u201cruntime app images\u201d on Android 14+.) ART does have a means of persisting compiled methods across cold starts (this is simplified\u2014they are not strictly \u201cpersisted,\u201d and require a background dexopt run between cold starts), but they must be re-profiled and re-compiled following an app version update.<\/p>\n Meta\u2019s Mobile App Challenges<\/p>\n Meta\u2019s mobile applications are the primary point of access for most of our users, the majority of which use Android. Our mobile apps face several challenges in balancing shipping velocity with our performance goals. Startup performance, in particular, is especially important, as it can have a disproportionate impact on user experience.<\/p>\n Maintaining a minimal set of classes loaded on startup is a key focus for startup performance. As our apps continue to add new features, such as Instagram Reels or Messenger\u2019s End-to-End Encryption, the startup classes set grows as well. Besides user-visible features, critical functionality such as crash reporting, login authentication, and performance logging are all involved in startup. Facebook and Instagram, for example, each load more than 20,000 classes on startup, and several thousand more for feed scrolling.<\/p>\n We also care about improving performance for user journeys after startup. These user journeys measure key parts of the user experience, such as scrolling the user\u2019s feed, or the time it takes to fetch and render a photo. Additionally, these journeys typically specify both the user\u2019s behavior, such as scrolling or navigating, as well as where it\u2019s happening. For example, a user scrolling their feed is considered separately from scrolling their inbox, and navigating to a profile is considered separately from navigating to a feed. We prioritize optimizing different user journeys for each app, and regularly revisit whether new ones should be added, or existing ones removed.<\/p>\n Optimizing user journeys requires understanding exactly what classes get loaded. For this, we collect profiles of class load sequences from many different users, and look for what they have in common. We\u2019ve found that these profiles can look dramatically different across different users, even for the same user journey. Moreover, the exact same user can still have a different profile of class loads on another day, with different code paths taken due to experimentation<\/a>, and can be different again the next week, as both the code and user behavior changes. Our monorepo sees thousands of commits each day. There is no easy one-size-fits-all solution here.<\/p>\n In total, we have a large, growing, and dynamic set of code to manage. We need a solution that can intelligently adapt to frequent code changes between each release, can quickly generate compiled code and profiles, and can benefit both startup and other user journeys.<\/p>\n ART Install-Time Optimizations<\/p>\n Since Android 9, ART has offered the following install-time optimizations:<\/p>\n AOT compilation means that specified methods will be compiled to machine code by ART before the app runs for the first time. This eliminates the overhead involved in interpreting and profiling the method\u2019s initial execution.<\/p>\n An app image<\/a> is a file containing a partial representation of the in-memory ART data structures, which would be created or populated by class loads for specified classes. When an app is started with an app image, it is mapped into the process\u2019 heap, and\u00a0 any necessary fixups are applied. The end result is that many classes may be effectively loaded extremely quickly at startup, and any later runtime cost associated with loading these classes is eliminated.<\/p>\n These optimizations can be triggered by supplying a special profile to ART at app install time.\u00a0 There are two main mechanisms for this: Cloud Profiles and Baseline Profiles.<\/p>\n Cloud Profiles<\/p>\n Cloud Profiles are aggregations of profiling data from many different users collected by Google Play during the initial rollout of an app version. After the Cloud Profile has been created, all subsequent users installing that app version via Google Play will receive that Cloud Profile, which will be used by ART for AOT compilation and app image creation.<\/p>\n Cloud Profiles have several downsides<\/a>, however:<\/p>\n Baseline Profiles<\/p>\n Baseline Profiles<\/a> are similar to Cloud Profiles, as they also trigger ART install-time optimizations, with a few key differences. Whereas Cloud Profiles are generated by Google Play through collecting and aggregating data from early users of an app version, Baseline Profiles are generated and provided by application developers. Developers can simply package their Baseline Profile inside their corresponding APK or AAB. When both Cloud Profiles and Baseline Profiles are available, they can be used in tandem<\/a>.<\/p>\n Baseline Profiles give full control of install time optimizations to application developers, and are available to users immediately. This allows developers to control install-time optimizations in a way which is much more tuned to the specific needs of their app than Cloud Profiles, including the ability to optimize for scenarios beyond startup.<\/p>\n Google offers some mechanisms of generating baseline profiles from benchmarks (e.g. Macrobenchmark). However, they can also be generated by directly specifying classes and methods in a well-specified format<\/a> to a tool called profgen<\/a>, which offers flexibility.<\/p>\n Next, we will look at how Baseline Profiles have been a very beneficial technology for the performance of Meta\u2019s apps, solving many of the challenges with ART.<\/p>\n How We\u2019ve Created Baseline Profiles at Meta<\/p>\n Earlier, we described challenges we have faced with our Android applications\u2019 performance. In particular, we mentioned how our apps\u2019 startups can load tens of thousands of classes on each cold start, and how our weekly shipping wipes all compiled code on every update.<\/p>\n We have long been aware of and focused on these challenges, particularly related to cold start. In the past, we have seen major performance gains via ordering classes within the underlying dex file according to their typical load position during startup, due to improved locality of reference. We call this \u201cInterdex Ordering,\u201d which is done via InterdexPass in Redex<\/a>, our bytecode optimizer.\u00a0 (Google\u2019s analog of this in R8 is called \u201cstartup profiles.\u201d). ART\u2019s install-time optimizations complement and improve upon this optimization by entirely eliminating the loading cost for some of these classes, and ensuring that their hot methods are compiled before the first run of the app version.<\/p>\n Previously, we mentioned how developers do not directly control the Cloud Profile\u2019s contents. This particularly impacted Meta, as once a startup exceeds five seconds, the Android Runtime automatically considers the startup to be complete. This caused the Cloud Profile to insufficiently mark which classes were necessary for startup. While Cloud Profiles have undoubtedly helped here, the control and flexibility of Baseline Profiles have allowed us to fully realize the potential of these optimizations and measure large performance wins.<\/p>\n To create our Baseline Profiles, we use data from a variety of sources, which we process and aggregate together, based on configurations that are subject to continuous experimentation and tuning.<\/p>\n Collecting Profile Data<\/p>\n In our initial Baseline Profiles experiments, we simply used the static profiles for the AndroidX libraries that are shipped alongside them. Today, we have a sophisticated set of collection technologies we use together to produce profiles for our apps.<\/p>\n Benchmarks are one approach to collecting profile data. At Meta, we leverage some local benchmarks in Baseline Profile creation for some of our apps, using internal tooling we have written to collect class and method usage information. However, for apps like Facebook and Instagram, benchmarks are not sufficiently representative of production behaviour. For more complex apps like these, we additionally collect class and method usage data from users to obtain a more complete picture.<\/p>\n\n
\n
![\"\"](\"https:\/\/www.europesays.com\/uk\/wp-content\/uploads\/2025\/10\/image1.png\")
Diagram showing the flow for Baseline and Cloud Profiles in Google Play. \u201cImproving App Performance with Baseline Profiles\u201d by Kateryna Semenova, Rahul Ravikumar, and Chris Craik, 28 Jan. 2022. Android Developers Blog.<\/a><\/p>\n
![\"\"](\"https:\/\/www.europesays.com\/uk\/wp-content\/uploads\/2025\/10\/image2_81e361.png\")
<\/p>\n