# Fresco: Image Loading and Memory Management for Android

> Fresco is an Android image library from Meta that handles network loading, two-level caching and animated formats. It is built for apps that need to keep large image sets out of the Java heap.

**facebook/fresco** — An Android library for managing images and the memory they use.

- Repository: https://github.com/facebook/fresco
- Website: https://frescolib.org/
- Stars: 17,152 · Forks: 3,737
- Language: Kotlin
- License: MIT
- Published: 2026-09-21 · Updated: 2026-09-21 · Language: en
- Canonical page: https://hysenlabs.com/projects/facebook-fresco

## What Fresco Solves for Android Image Loading

Android apps that show images from the network run into two recurring problems: decoding work on the main thread, and bitmap memory that the garbage collector cannot reclaim fast enough. The README states that Fresco "takes care of image loading and display, so you don't have to," and that on Android 4.x and lower it places images in a special region of Android memory so the app runs faster and hits OutOfMemoryError less often. That last point is the design centre of the library: the bitmap memory lives outside the Java heap on older platforms, so a large grid of photos does not push the process into an allocation failure.

The audience is Android application developers who load images from the network, local storage or local resources and want a placeholder shown until the image arrives. It is not a drawing toolkit and it is not a general-purpose bitmap utility. If your app ships a fixed set of icons from res/drawable, Fresco is more machinery than the job needs.

## Two-Level Cache and the Drawee View Layer

The README describes two levels of cache: one in memory and another in internal storage. A request therefore has three possible sources in order of cost: the in-memory bitmap cache, the disk cache in internal storage, and the network or local resource. The disk cache is what makes a cold start on a previously seen image fast without a network round trip.

The repository layout shows the split clearly. The imagepipeline modules handle fetching, decoding and caching, while drawee is the view layer that draws the result. Drawee is a separate artifact because it is optional: you can use the pipeline directly and render into your own view. The animated-gif, animated-webp and animated-base modules exist because animated formats need their own decoders and their own drawable types, and animated-gif-lite is a smaller variant of the GIF path. The README also lists streaming of progressive JPEGs, which means a progressive file can be drawn as it arrives rather than after the last byte.

This structure has a cost. Drawee is not a drop-in ImageView replacement in the sense of keeping your existing layout untouched; the view hierarchy expects Drawee view types, and the controller that binds a URI to a view is a distinct object you create and hold. The README points to the website for the full details rather than documenting the view API inline, so the repository alone is not enough to learn the drawing side.

## Adding Fresco to a Gradle Build

The README gives one dependency line for Gradle projects. It goes in the dependencies section of your build.gradle file, and the version quoted in the README is 3.7.0, which matches the most recent release listed for the project.

```groovy
implementation 'com.facebook.fresco:fresco:3.7.0'
```

After syncing, the base artifact is on the classpath. The README does not spell out the initialization call or the layout XML in the repository text; for those it directs readers to the documentation site at frescolib.org, which is published in English and Chinese. Treat the website as the tutorial source and this repository as the code and the dependency coordinates.

The README also states the platform floor: Fresco can be included in any Android application and supports Android 2.3 (Gingerbread) and later. If your project's minSdkVersion is above that, the floor is irrelevant to you, but the special memory region behaviour described in the README is tied to Android 4.x and lower, so on modern devices you are relying on the cache design rather than the off-heap placement.

If you want the animated formats, the repository layout indicates separate modules for GIF and WebP support, but the README does not list their artifact coordinates. Check the documentation site before assuming the base artifact includes them.

## Where Fresco Is the Wrong Choice

The clearest limit is scope. Fresco is an Android library. The README says nothing about a server-side component, a desktop build or a cross-platform binding, and the repository is a Gradle multi-module Android project with a gradlew wrapper at the root. If your images need to render on iOS or in a web view, this code does not help you.

The second limit is the view layer. Because Drawee is a distinct drawing abstraction, adopting Fresco in an existing screen means changing layouts and introducing a controller object per view. For a screen with two static images, that is more churn than the caching saves.

A third limit is documentation depth inside the repository. The README is short and defers to the website for setup and API detail. The repository does contain a samples directory with subprojects such as samples/showcase, samples/zoomable, samples/gestures and samples/scrollperf, and those are the practical reference for wiring the library up. If you cannot read sample code to learn an API, the README alone will leave gaps.

Finally, the README does not document rollback or a migration path between major versions. The release list shows a long gap between v3.5.0 in November 2024 and v3.6.0 in January 2025, then v3.7.0 in June 2026. If you need a documented downgrade procedure, the README is silent on it and you would have to read the release notes on the repository.

## Fresco Compared with Glide and Coil

The natural alternatives for Android image loading are Glide and Coil, and the difference is architectural rather than cosmetic. Glide and Coil are built around a request builder that attaches to a standard ImageView, so the common case is one line at the call site and no new view types. Fresco instead separates the pipeline from a dedicated drawing view, which is more setup but gives the library control over when the bitmap is allocated and released.

That control is the point of the off-heap memory region described in the README for Android 4.x and lower. A library that draws into a standard ImageView has less room to move bitmap memory out of the Java heap. Whether that matters to you depends on your minimum SDK and how many images you display at once.

The second difference is format coverage. The README explicitly lists streaming progressive JPEGs and display of animated GIFs and WebPs as supported features, with dedicated modules in the repository for the animated paths. If animated content is a first-class requirement, that is a reason to look at Fresco specifically rather than treating all three libraries as interchangeable.

## Maintenance Status, Licence and Upgrade Cost

The repository is not archived, and the last push was on 2026-09-18, three days before the date used here. The release cadence visible in the release list is uneven: v3.5.0 on 2024-11-25, v3.6.0 on 2025-01-08, and v3.7.0 on 2026-06-12. A roughly seventeen-month gap between v3.6.0 and v3.7.0 means you should not plan around frequent point releases, and it also means the 3.7.0 line is the one to target if you are starting now.

Upgrade cost is mostly a function of the view layer. Because Drawee is separate from the pipeline, a major-version change can touch both the dependency line and the layout or controller code. The README does not describe the upgrade procedure, so budget time to read the release notes and the samples between versions rather than assuming a version bump is enough.

The licence is MIT, stated in the README and present as a LICENSE file at the repository root. MIT is permissive: it allows use in closed-source applications provided the copyright notice and permission notice are included. That is a general description of the licence text, not legal advice, and your own compliance review should read the LICENSE file rather than this paragraph.

## Conclusion

Adopt Fresco if your Android app loads many remote images, needs GIF or WebP playback, or targets devices where bitmap memory is tight and you want the library to own the cache. Do not adopt it if you only draw a handful of bundled resources, or if you are not willing to add the Drawee view layer to your layouts. Before committing, verify the current version on the releases page, check that the MIT licence text in LICENSE matches your compliance process, and confirm the Android SDK floor your project supports against the README's stated Android 2.3 (Gingerbread) and later.

## FAQ

### How do I install Fresco in an Android project?

Add the dependency line from the README to the dependencies section of your build.gradle file, which currently reads implementation 'com.facebook.fresco:fresco:3.7.0'. The README then directs you to the documentation site at frescolib.org for the full setup steps.

### How do I use Fresco to display images?

The README says Fresco loads images from the network, local storage or local resources and shows a placeholder until the image arrives, with two cache levels. The repository keeps the drawing layer in the drawee modules and ships sample projects such as samples/showcase for working code, while the README defers API detail to frescolib.org.

### Which Android versions does Fresco support?

The README states that Fresco can be included in any Android application and supports Android 2.3 (Gingerbread) and later. It also notes that on Android 4.x and lower, images are placed in a special region of Android memory to reduce OutOfMemoryError.

### Does Fresco support animated GIFs and WebP?

Yes. The README lists display of animated GIFs and WebPs among the supported features, and the repository contains animated-gif, animated-gif-lite, animated-webp and animated-drawable modules. The README does not list the artifact coordinates for those modules, so check the documentation site.

### What licence does Fresco use?

Fresco is MIT-licensed, as stated in the README and in the LICENSE file at the repository root. The project's homepage is frescolib.org.

## Sources

- [facebook/fresco on GitHub](https://github.com/facebook/fresco)
- [License: MIT](https://github.com/facebook/fresco/blob/main/LICENSE)
- [Project website](https://frescolib.org/)
- [README](https://github.com/facebook/fresco/blob/main/README.md)
- [Releases](https://github.com/facebook/fresco/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/facebook-fresco