Ad preloading is an ad loading feature in GMA Next-Gen SDK that loads ads in the background and caches the ads before showing. To improve performance using ad preloading, disable custom caching and delegate that responsibility to GMA Next-Gen SDK.
Ad preloading in GMA Next-Gen SDK automates ad loading and caching.
Ad preloading provides the following benefits:
- Reference management: maintains references until ads are shown.
- Automatic reloading: loads a new ad when one is retrieved from the cache.
- Managed retries: loads a new ad when one fails to load.
- Expiration handling: refreshes ads before expiring.
- Cache optimization: optimizes the cache order to deliver the highest priority ad.
Compare ad preloading and single load
Use ad preloading as the default integration for full-screen ads in your app.
The following compares ad preloading and single load ad requests:
Ad preloading
Use ad preloading for the following advantages:
- Automated lifecycle management: Delegate ad caching, expiration tracking, failed request retries, and ad refreshes to GMA Next-Gen SDK without writing or maintaining custom lifecycle code. When you get a preloaded ad from the cache to show, GMA Next-Gen SDK automatically loads a replacement ad.
- Ads ready at transition points: Preload ads ahead of time to display ads when users move between levels or screens.
- Optimized ad selection: Let GMA Next-Gen SDK store multiple ads per preload configuration and serve the highest-priority ad from the cache each time you show an ad.
Single-load
Use single-load ad requests only when you need direct control over individual ad requests, for example:
- Inbound mediation: If you mediate GMA Next-Gen SDK through a third-party mediation platform, such as partner bidding, use single-load ad requests. For details, see About partner bidding. Because the third-party mediation SDK manages waterfalls, caching, and refresh cycles, GMA Next-Gen SDK expects a single ad request for each adapter load call.
- Custom ad requests: If you set custom
AdRequestparameters that change before each request, use single-load ad requests. Updating aPreloadConfigurationobject restarts preloading and clears your cached ads.
Compare ad lifecycle behaviors
The following table compares how ad preloading and single-load handle ad lifecycle behaviors:
| Behavior | Ad preloading | Single-load API |
|---|---|---|
| Store ads | Stores loaded ads in an internal cache until you call the pollAd method. |
Your app must store the loaded ad object reference in a member variable until you show the ad. |
| Reload ads | Automatically loads a replacement ad when you retrieve an ad from the cache. | Your app must manually call the load method after the user dismisses an ad or the ad fails to show. |
| Failed request retries | Automatically retries failed requests using exponential backoff. | Requires custom retry logic to handle failed requests. |
| Expiration and refreshes | Tracks ad expiration and automatically refreshes expired ads in the cache. | Your app must track expiration times and request an ad manually. |
| Cache optimization | Stores multiple ads per preload configuration and serves the highest-priority ad first. | Loads one ad per request with no built-in queue or cache ordering. |
Ad preloading lifecycle
Ad preloading replaces manual ad loading calls with the following lifecycle steps:
- Start ad preloading: Call the
startmethod once per preload configuration. For implementation details, see App open, Interstitial, Rewarded, or Rewarded interstitial. - Get and show the preloaded ad: Call the
pollAdmethod, and then call theshowmethod. For implementation details, see App open, Interstitial, Rewarded, or Rewarded interstitial. - Optional: Stop preloading ads: Call the
destroyordestroyAllmethod. For implementation details, see App open, Interstitial, Rewarded, or Rewarded interstitial.
Preload cache limits
Buffer size controls the number of preloaded ads held in memory for a preload configuration. By default, Google optimizes buffer size to balance memory consumption and ad serving latency.
GMA Next-Gen SDK enforces an app-wide limit on the total number of preloaded ads across all ad units and preload IDs:
- Default app-wide limit: GMA Next-Gen SDK holds a maximum of six preloaded ads in memory across all formats and preload IDs.
- Recommended buffer size: We recommend keeping a buffer size of two for each preload ID.
Next steps
GMA Next-Gen SDK supports ad preloading for full-screen ad formats. Banner and
native ad formats don't use ad preloading. Banner ads refresh automatically
based on your ad unit configuration, and native ads use the NativeAdLoader
class.
Integrate ad preloading for your chosen ad format or optimize launch latency: