Android Fast Image Loader

New approach to image loading that overcomes Android memory management limitation by leveraging size, density, config, aggressive bitmap reuse and super-fast disk loading, to provide the fastest and most lightweight image handling possible.

This library requires fine-tuning work, if you are just looking for simple library I would recommend: Picasso, Glide, Universal Image Loader or Volley.

Quick Start

compile  'com.theartofdev:fast-image-loader:0.8.+'

// initialize fast image loader to use thumbor image service
FastImageLoader.init(application)
        .setDefaultImageServiceAdapter(new ThumborAdapter("http://myThumbor.com/"))
        .setDebugIndicator(true);

// create image loading specification with specific image dimensions
FastImageLoader.buildSpec("ImageSpec")
        .setDimensionByResource(R.dimen.imageWidth, R.dimen.imageHeight)
        .build();

// replace ImageView with TargetImageView in the UI
((TargetImageView)findViewById(R.id.imageView)).loadImage(imageUri, "ImageSpec");

Features

• Smart memory and disk caching.
• Super-fast, asynchronous, disk cache loading.
• Asynchronous and parallel download.
• Low memory footprint and optimizations for memory pressure.
• Image services support ( Thumbor , imgIX , etc.)
• Highly customizable specification loading (size/format/density/bitmap config/etc.)
• Alternative specification loading.
• Pre-fetch download images.
• Advanced bitmaps reuse using inBitmap, reusing bitmaps on destroy and invisibility.
• Smart prioritization and canceling of image load requests, more than list item reuse.
• Placeholder, round rendering, download progress, fade-in animation support.
• Extensive extensibility.
• Logging and analytics hooks.
• Debug indicator (loaded from Memory/Disk/Network).

Leverage Size, Density and Config

There is a little benefit to download 1500x1500 pixel (450 ppi) image that will take 8.5 MB of memory to show 500x500 preview in a feed where the user scrolls quickly. It will be much better to decrees the image density by half and use 565 bitmap config lowering the memory footprint to 1 MB , empirically, without loss of quality.

Aggressive bitmap reuse

To limit the amount of memory allocated and GC work the library reused bitmaps as soon as they are no longer visible in the UI.

• Activity/Fragment images that have not been destroyed but are no longer visible (onStop has been called) are eligible for bitmap reuse.
• When the Activity/Fragment becomes visible again, if the bitmap was reused, the image is reload.
• After initial allocations, bitmap reuse prevents almost all subsequent allocations.
• High disk loading performance make this process seamless.

High disk cache performance

• Up to 5-8 times faster load of cached images from disk.
• Will add benchmark comparison…

License

The MIT License (MIT)
Copyright (c) 2015 Arthur Teplitzki
See license.md