Android file cache library

Top 10: Best Android Image Loading and Caching Libraries

Carlos Delgado

See our review from 10 of the Best Android Image Loading and Caching Libraries.

An application that doesn’t load images, is pretty weird and boring nowadays. Knowing how to display an image in your mobile application is one of the most common tasks for every developer. However, the way you work with them will be different for everyone, due to the way you code your app to handle the image. For example, website developers don’t need to take care of image caching because the browser does this automatically, but for an android developer, an image will be normally loaded again and again (if we are talking from a remote/web source) without really good performance. If you are willing to display efficiently images on your application, you need to take care of the image caching, specially when you work on a free application to organize photos.

In this top, we’ll share with you 10 of the most imponent image caching libraries to increase the performance and loading times of your Android Application.

10. Mirage

Mirage is an image loading library developed by the Android team at The Climate Corporation for loading, caching, and sync’ing for offline usage of images. Our main consideration for creating this system was to allow for explicit sync’ing of images for offline use. Libraries like Picasso didn’t fulfill our requirements because as stated «Picasso doesn’t have a disk cache. It delegates to whatever HTTP client».

9. Android Image Cache

An image download-and-cacher that also knows how to efficiently generate and retrieve thumbnails of various sizes. This library features:

• easily integrates into content-provider backed applications, providing an adapter that can read local and web URLs from a cursor
• automatic generation and caching of multiple sizes of images based on one downloaded asset
• provides a disk cache as well as a memory cache
• automatic disk cache management; no setup necessary, but parameters can be fine-tuned if desired
• designed to work with your existing setup: no extending a custom application or activity needed
• cursor adapter supports multiple image fields for each ImageView; skips fields that are null or empty
• cursor adapter has an automatic progress bar when loading the cursor

8. Shutterbug

Shutterbug is an Android library that lets you fetch remote images and cache them. It is particularly suited for displaying remote images in lists or grids as it includes a convenience subclass of ImageView ( FetchableImageView ) that make implementation a one-liner.

A dual memory and disk cache was implemented. It makes use of two backports of Android classes: LruCache for the memory part and DiskLruCache for the disk part. LruCache was introduced by API Level 12, but we provide it here as a standalone class so you can use the library under lower level APIs. Both LruCache and DiskLruCache are licensed under the Apache Software License, 2.0.

Shutterbug was inspired by SDWebImage which does the same thing on iOS. It uses the same structure and interface. People who are familiar with SDWebImage on iOS will feel at home with Shutterbug on Android.

7. Slight

Sligh is an easy, sample and flexible library for loading, caching and displaying images on Android written in Kotlin.

6. Ion

ION is an Android Asynchronous Networking and Image Loading library. This library features:

• Asynchronously download:
  • Images into ImageViews or Bitmaps (animated GIFs supported too)
  • JSON (via Gson)
  • Strings
  • Files
  • Java types using Gson
• Easy to use Fluent API designed for Android
  • Automatically cancels operations when the calling Activity finishes
  • Manages invocation back onto the UI thread
  • All operations return a Future and can be cancelled
• HTTP POST/PUT:
  • text/plain
  • application/json — both JsonObject and POJO
  • application/x-www-form-urlencoded
  • multipart/form-data
• Transparent usage of HTTP features and optimizations:
  • SPDY and HTTP/2
  • Caching
  • Gzip/Deflate Compression
  • Connection pooling/reuse via HTTP Connection: keep-alive
  • Uses the best/stablest connection from a server if it has multiple IP addresses
  • Cookies
• View received headers
• Grouping and cancellation of requests
• Download progress callbacks
• Supports file:/, http(s):/, and content:/ URIs
• Request level logging and profiling
• Support for proxy servers like Charles Proxy to do request analysis
• Based on NIO and AndroidAsync
• Ability to use self signed SSL certificates

5. Android Smart Image View

SmartImageView is a drop-in replacement for Android’s standard ImageView which additionally allows images to be loaded from URLs or the user’s contact address book. Images are cached to memory and to disk for super fast loading. This library features:

• Drop-in replacement for ImageView
• Load images from a URL
• Load images from the phone’s contact address book
• Asynchronous loading of images, loading happens outside the UI thread
• Images are cached to memory and to disk for super fast loading
• SmartImage class is easily extendable to load from other sources

4. Android Universal Image Loader

UIL is a powerful and flexible library for loading, caching and displaying images on Android. UIL aims to provide a powerful, flexible and highly customizable instrument for image loading, caching and displaying. It provides a lot of configuration options and good control over the image loading and caching process. This library features:

• Multithread image loading (async or sync)
• Wide customization of ImageLoader’s configuration (thread executors, downloader, decoder, memory and disk cache, display image options, etc.)
• Many customization options for every display image call (stub images, caching switch, decoding options, Bitmap processing and displaying, etc.)
• Image caching in memory and/or on disk (device’s file system or SD card)
• Listening loading process (including downloading progress)
• Android 2.0+ support.

3. Fresco by Facebook

An Android library for managing images and the memory they use. Fresco takes care of image loading and display, so you don’t have to. It will load images from the network, local storage, or local resources, and display a placeholder until the image has arrived. It has two levels of cache; one in memory and another in internal storage. In Android 4.x and lower, Fresco puts images in a special region of Android memory. This lets your application run faster — and suffer the dreaded OutOfMemoryError much less often. Fresco also supports:

• streaming of progressive JPEGs
• display of animated GIFs and WebPs
• extensive customization of image loading and display
• and much more!

2. Picasso

Picasso is a powerful image downloading and caching library for Android. Images add much-needed context and visual flair to Android applications. Picasso allows for hassle-free image loading in your application—often in one line of code! Many common pitfalls of image loading on Android are handled automatically by Picasso:

• Handling ImageView recycling and download cancelation in an adapter.
• Complex image transformations with minimal memory use.
• Automatic memory and disk caching.

Adapter re-use is automatically detected and the previous download canceled. If you would like to contribute code you can do so through GitHub by forking the repository and sending a pull request.

1. Glide

Glide is a fast and efficient open source media management and image loading framework for Android that wraps media decoding, memory and disk caching, and resource pooling into a simple and easy to use interface. Glide supports fetching, decoding, and displaying video stills, images, and animated GIFs. Glide includes a flexible API that allows developers to plug in to almost any network stack. By default Glide uses a custom HttpUrlConnection based stack, but also includes utility libraries plug in to Google’s Volley project or Square’s OkHttp library instead.

Glide’s primary focus is on making scrolling any kind of a list of images as smooth and fast as possible, but Glide is also effective for almost any case where you need to fetch, resize, and display a remote image. Glide takes in to account two key aspects of image loading performance on Android:

• The speed at which images can be decoded.
• The amount of jank incurred while decoding images.

For users to have a great experience with an app, images must not only appear quickly, but they must also do so without causing lots of jank and stuttering from main thread I/O or excessive garbage collections.

Glide takes a number of steps to ensure image loading is both as fast and as smooth as possible on Android:

• Smart and automatic downsampling and caching minimize storage overhead and decode times.
• Aggressive re-use of resources like byte arrays and Bitmaps minimizes expensive garbage collections and heap fragmentation.
• Deep lifecycle integration ensures that only requests for active Fragments and Activities are prioritized and that Applications release resources when neccessary to avoid being killed when backgrounded.

Honorable mentions

An image loading library for Android backed by Kotlin Coroutines. Coil is:

• Fast: Coil performs a number of optimizations including memory and disk caching, downsampling the image in memory, re-using Bitmaps, automatically pausing/cancelling requests, and more.
• Lightweight: Coil adds

1500 methods to your APK (for apps that already use OkHttp and Coroutines), which is comparable to Picasso and significantly less than Glide and Fresco.

Easy to use: Coil’s API leverages Kotlin’s language features for simplicity and minimal boilerplate.

Modern: Coil is Kotlin-first and uses modern libraries including Coroutines, OkHttp, Okio, and AndroidX Lifecycles.

Coil is an acronym for: Coroutine Image Loader.

If you know another awesome image caching library for Android, please share it with the community in the comment box.

Источник

Data and file storage overview

Android uses a file system that’s similar to disk-based file systems on other platforms. The system provides several options for you to save your app data:

• App-specific storage: Store files that are meant for your app’s use only, either in dedicated directories within an internal storage volume or different dedicated directories within external storage. Use the directories within internal storage to save sensitive information that other apps shouldn’t access.
• Shared storage: Store files that your app intends to share with other apps, including media, documents, and other files.
• Preferences: Store private, primitive data in key-value pairs.
• Databases: Store structured data in a private database using the Room persistence library.

The characteristics of these options are summarized in the following table:

Type of content	Access method	Permissions needed	Can other apps access?	Files removed on app uninstall?
App-specific files	Files meant for your app’s use only	From internal storage, getFilesDir() or getCacheDir() From external storage, getExternalFilesDir() or getExternalCacheDir()	Never needed for internal storage Not needed for external storage when your app is used on devices that run Android 4.4 (API level 19) or higher	No	Yes
Media	Shareable media files (images, audio files, videos)	MediaStore API	READ_EXTERNAL_STORAGE when accessing other apps’ files on Android 11 (API level 30) or higher READ_EXTERNAL_STORAGE or WRITE_EXTERNAL_STORAGE when accessing other apps’ files on Android 10 (API level 29) Permissions are required for all files on Android 9 (API level 28) or lower	Yes, though the other app needs the READ_EXTERNAL_STORAGE permission	No
Documents and other files	Other types of shareable content, including downloaded files	Storage Access Framework	None	Yes, through the system file picker	No
App preferences	Key-value pairs	Jetpack Preferences library	None	No	Yes
Database	Structured data	Room persistence library	None	No	Yes

The solution you choose depends on your specific needs:

How much space does your data require? Internal storage has limited space for app-specific data. Use other types of storage if you need to save a substantial amount of data. How reliable does data access need to be? If your app’s basic functionality requires certain data, such as when your app is starting up, place the data within internal storage directory or a database. App-specific files that are stored in external storage aren’t always accessible because some devices allow users to remove a physical device that corresponds to external storage. What kind of data do you need to store? If you have data that’s only meaningful for your app, use app-specific storage. For shareable media content, use shared storage so that other apps can access the content. For structured data, use either preferences (for key-value data) or a database (for data that contains more than 2 columns). Should the data be private to your app? When storing sensitive data—data that shouldn’t be accessible from any other app—use internal storage, preferences, or a database. Internal storage has the added benefit of the data being hidden from users.

Categories of storage locations

Android provides two types of physical storage locations: internal storage and external storage. On most devices, internal storage is smaller than external storage. However, internal storage is always available on all devices, making it a more reliable place to put data on which your app depends.

Removable volumes, such as an SD card, appear in the file system as part of external storage. Android represents these devices using a path, such as /sdcard .

Apps themselves are stored within internal storage by default. If your APK size is very large, however, you can indicate a preference within your app’s manifest file to install your app on external storage instead:

Permissions and access to external storage

On earlier versions of Android, apps needed to declare the READ_EXTERNAL_STORAGE permission to access any file outside the app-specific directories on external storage. Also, apps needed to declare the WRITE_EXTERNAL_STORAGE permission to write to any file outside the app-specific directory.

More recent versions of Android rely more on a file’s purpose than its location for determining an app’s ability to access, and write to, a given file. In particular, if your app targets Android 11 (API level 30) or higher, the WRITE_EXTERNAL_STORAGE permission doesn’t have any effect on your app’s access to storage. This purpose-based storage model improves user privacy because apps are given access only to the areas of the device’s file system that they actually use.

Android 11 introduces the MANAGE_EXTERNAL_STORAGE permission, which provides write access to files outside the app-specific directory and MediaStore . To learn more about this permission, and why most apps don’t need to declare it to fulfill their use cases, see the guide on how to manage all files on a storage device.

Scoped storage

To give users more control over their files and to limit file clutter, apps that target Android 10 (API level 29) and higher are given scoped access into external storage, or scoped storage, by default. Such apps have access only to the app-specific directory on external storage, as well as specific types of media that the app has created.

Use scoped storage unless your app needs access to a file that’s stored outside of an app-specific directory and outside of a directory that the MediaStore APIs can access. If you store app-specific files on external storage, you can make it easier to adopt scoped storage by placing these files in an app-specific directory on external storage. That way, your app maintains access to these files when scoped storage is enabled.

To prepare your app for scoped storage, view the storage use cases and best practices guide. If your app has another use case that isn’t covered by scoped storage, file a feature request. You can temporarily opt-out of using scoped storage.

View files on a device

To view the files stored on a device, use Android Studio’s Device File Explorer.

Additional resources

For more information about data storage, consult the following resources.

Videos

Content and code samples on this page are subject to the licenses described in the Content License. Java is a registered trademark of Oracle and/or its affiliates.

Источник