The general discussion of Fresco online is that it performs better and Glide is easier to use. But is the answer really that obvious?
Like performance issues. Is Fresco really any better than Glide? After all, the Fresco package is larger, the threads are more open, and the image resampling needs to be manually provided with ResizeOptions. In addition, Fresco allocates more memory for caching, and the HARDWARE format is not enabled unless bitmap.config is actively specified. The most important thing I care about is that you have to manually provide ResizeOptions to perform the resampler, but manual execution is often unreliable, and if the developer is not qualified or not paying attention, it can easily lead to memory problems when loading large images. So, from the point of view of performance, especially if it is for more than 5.0 equipment, I think Glide is better, more safe.
At the same time, is Glide really easier to use than Fresco? Indeed, Fresco is much more complex than Glide when it comes to customizing image requests using Java code. However, most of the time, Fresco does the image request with SimpleDraweeView, plus rounded corners, placeholder, aspect ratio, etc. If you customize a generic style, Fresco code is much less than Glide. Glide each time to with, load, into, width to height ratio and other functions to their own implementation, the function of RoundedCorners does not support custom up and down around different locations using different radii, but also to create a RoundedCorners object, rather than directly set up, the code is more troublesome to write.
Overall, Fresco has more features like rounded corners, aspect ratio, progressive loading of JPeGs, progress bars during loading, retry after loading failures, and better support for phones under 5.0. Glide is more convenient, such as automatically scaling images according to ImageView size, automatically freeing memory during memory event callbacks, and so on. For performance and usage, the answer may not be as simple as discussed online, but also need to weigh.
| Fresco | Glide | |
|---|---|---|
| The code structure | It’s more complicated | It’s relatively clear and intuitive |
| View | Custom DraweeView | Use with ImageView |
| Obtain Bitmap | Slightly more complicated, you need to send a custom request to ImagePipeline | It’s easier to use CustomTarget or FutureTarget |
| The zoom | There are more options, but resampling is not performed by default. You need to manually set this parameter to True and provide RezieOptions | By default, images are automatically resampled based on the ImageView size |
| The layer | More layers, more features (such as progress bar display, retry click, etc.) | It is divided into three layers: placeholder, thumbnail and loading failure placeholder |
| Image format | Support GIF, WebP, video thumbnails, can add custom SVG decoder | Support GIF, WebP, SVG, video thumbnails |
| Transform operation | Supports circles, rounded corners, and rotation | Circles, rounded corners, and rotations are supported, but different radius of rounded corners in different positions is not supported |
| Progressive loading JPEG | support | Does not support |
| The cache | 1) Memory cache (active, inactive) 2) undecoded picture cache (byte stream) 3) disk cache (the cache is the original image data, you can manually set small files, large files are stored separately, but need to manually specify which are small files) | 1) Memory cache (active and inactive) 2) disk cache (image data after decoding and transformation) 3) Disk cache (original image data) |
| The cache size | 1) memory cache is generally ActivityManager. GetMemoryClass / 4 (2) not decoded picture buffer is usually 4 MB 3) disk cache is usually 40 MB | 1) Memory cache is calculated according to the resolution of the phone, usually multiplied by 2. 2) Disk cache is 250MB by default (shared by two levels of cache) |
| Caching algorithm | LRU (Disk caching by modifying the file LastModified attribute) | LRU (Disk caching via DiskLruCache) |
| Object pooling | Both have Bitmap object pools and array object pools | |
| Memory events | You need to manually call the trim method to free memory | Listening to ComponentCallbacks2, can automatically release memory |
| The life cycle | Listen for attach and detach events on DraweeView | Add Fragment to listen for the life cycle |
| The thread pool | There are more thread pools and more threads | There are three main thread pools and a relatively small number of threads |
| Bitmap format | The default is ARGB_8888, which can be manually set to HARDWARE | Config.hardware (8.0) is preferred, otherwise ARGB_8888 is used by default |
| Bitmap stored | Up to 5.0 use Native memory storage, and up to 5.0 use Java heap storage | GPU storage (8.0) is preferred for bitmaps, otherwise Java heap storage is used |