This chapter is from the book
This chapter is from the book
This chapter is from the book
Optimizing Images
There are a few big things you can do to speed up your use of images. First, you can shrink the image file sizes by stripping out metadata and adjusting the compression. Second, you can size them correctly (loading an image that’s bigger than it is displayed is obviously slower than loading one that’s exactly the size that will be displayed). Finally, you can keep them in memory to avoid loading them again.
Shrinking Images
Many people aren’t aware that images can contain a lot more data than they need. For instance, JPEGs can be “progressive,” which means they actually store multiple versions of the image at progressively higher levels of detail. This was particularly helpful for old webpages on dialup, when you wanted some sense of what the image was before all of it could be downloaded on the slow connection, but it causes the images to be much larger and Android doesn’t use this extra data because the full image is already on the local disk. JPEGs can also store metadata in EXIF or XMP formats. These are two different formats for storing information about the photo such as when it was taken, what camera was used, and even how long the photo was exposed. That data is great for photographers but it adds bulk to the image that isn’t helpful for our app, so it can be stripped out. Another common inclusion in JPEGs is actually a thumbnail of the image. This is intended to help file browsers and cameras themselves to display a thumbnail without having to read in massive images and scale them; it can be stripped out as well.
You can also adjust the compression of the image. Although a more compressed image will still take up the same amount of memory once it is decompressed and decoded, it can significantly decrease the loading time because the amount of data read from disk can be substantially decreased. JPEG is a lossy format, which means you lose image detail by compressing it, but you can decrease file sizes substantially with only minor changes in compression. Typically, the compression level is described in terms of quality where 100 is highest quality and least compression. Although you might want to keep quality closer to 100 for your own personal photos, that isn’t necessary for most app images like what are in the woodworking tools app. The amount of compression you can use while maintaining quality will vary depending on what is in the image (e.g., details like thin letters will look poor faster than something like a tree in the background), but you can generally start at a quality level of 90 and see how it looks.
By stripping out all this extra data and changing the quality level to 90, we decrease the hero image sizes in the woodworking tools app substantially. For instance, the image of the clamps was 493KB and it is now 272KB. The smallest image (in terms of file size) was the drill at 165KB and even it shrank down to 64KB. Testing the app again shows that the time to decode the images has gone from about 60 milliseconds to about half that (with a fair bit of variation). Photoshop makes this pretty easy by picking “Save for Web” and ensuring that the quality is set how you want, it is not progressive, and no metadata is enabled. The process in GIMP is slightly different, starting with the “Export As” command that will give you an “Export Image as JPEG” dialog when saving as a JPEG; the dialog has “Advanced Options” where you want to make sure the image is not progressive, does not contain EXIF or XMP data, and does not have an embedded thumbnail.
Although these images are JPEGs, the same idea of shrinking down the file size applies to PNGs. PNGs are lossless, so you should always use the maximum compression. PNGs can be 8-bit (256 colors), 24-bit (red, green, and blue channels of 256 values each), or 32-bit (adding the alpha channel with 256 values). You can also save them with custom palettes, which can significantly shrink down the overall size. Many graphics programs support shrinking PNGs quite a bit themselves, so look for those options (such as a “save for web” feature). There are also third-party tools like “pngcrush,” which will try many different ways of compressing and shrinking the image to give you a smaller file size.
Using the Right Sizes
Our “hero” images are being used as thumbnails, so they’re actually significantly larger than what is displayed. The screen has a 16sp space on the left, center, and right of the thumbnail grid. In the case of the Nexus 5 (an XXHDPI device, which means the spaces are 48px), the spaces use a total of 144px. With a screen width of 1080px, we can subtract the 144px of space and divide the remainder by 2 (because there are two thumbnails in each row) to determine the thumbnails will be 468px in each dimension. That means we’re loading a 1080 × 607 image (roughly 650,000px) when we really just need a 468 × 468 image (about 220,000px). If we run the same numbers for a Nexus 4, which is an XHDPI device with a screen width of 768px, we need an image that’s 336px (about 110,000px). That means a Nexus 5 is loading almost three times as many pixels as needed and a Nexus 4 is loading almost six times as many pixels as needed! Not only is using larger images than necessary slower to load, it’s slower to blur and takes up more memory.
There is a simple method we can use to handle this. First, we will create a few sizes to handle the most typical device configurations. Then we’ll store all of these in the drawables-nodpi folder with a filename that indicates the size (for instance, hero_image_clamps_468.png) because we don’t want Android to scale these images. It’s a good idea to make sure the original images have updated names (e.g., hero_image_clamps_1080.png) to be consistent, and don’t forget to make sure the images you save out have any extra data stripped (they should not be progressive JPEGs, they shouldn’t have EXIF data, XMP data, or thumbnails embedded). Removing the extra data helps keep your APK smaller and also slightly decreases the loading time for the images. After that we just need some simple code to pick the best size.
Listing 10.2 demonstrates a simple BitmapUtils class that picks the best sized image. You might be wondering if there’s a way to construct the drawable resource ID from a string. For instance, you could store the string “hero_image_clamps_” and then concatenate the appropriate size, then get the resource that references. Indeed, that is possible. With a reference to your resources like you get from getResources(), you can use the getIdentifier method, but that method actually uses reflection to figure out which resource you’re referencing, so it is slow (defeating the purpose of optimizing this code in the first place). You should typically avoid using that method.
Listing 10.2 A BitmapUtils Class
public class BitmapUtils {
private static final int THUMBNAIL_SIZE_336 = 336;
private static final int THUMBNAIL_SIZE_468 = 468;
public static int getScreenWidth(@NonNull Context context) {
WindowManager windowManager = (WindowManager) context.getSystemService(Context.WINDOW_SERVICE);
Display display = windowManager.getDefaultDisplay();
Point point = new Point();
display.getSize(point);
return point.x;
}
/**
* Returns a resource ID to a smaller version of the drawable, when possible.
*
* This is intended just for the hero images. If a smaller size of the resource ID cannot
* be found, the original resource ID is returned.
*
* @param resourceId int drawable resource ID to look for
* @param desiredSize int desired size in pixels of the drawable
* @return int drawable resource ID to use
*/
@DrawableRes
public static int getPresizedImage(@DrawableRes int resourceId, int desiredSize) {
switch (resourceId) {
case R.drawable.hero_image_clamps_1080:
if (desiredSize <= THUMBNAIL_SIZE_336) {
return R.drawable.hero_image_clamps_336;
} else if (desiredSize <= THUMBNAIL_SIZE_468) {
return R.drawable.hero_image_clamps_468;
}
break;
case R.drawable.hero_image_saw_1080:
if (desiredSize <= THUMBNAIL_SIZE_336) {
return R.drawable.hero_image_saw_336;
} else if (desiredSize <= THUMBNAIL_SIZE_468) {
return R.drawable.hero_image_saw_468;
}
break;
case R.drawable.hero_image_drill_1080:
if (desiredSize <= THUMBNAIL_SIZE_336) {
return R.drawable.hero_image_drill_336;
} else if (desiredSize <= THUMBNAIL_SIZE_468) {
return R.drawable.hero_image_drill_468;
}
break;
case R.drawable.hero_image_sander_1080:
if (desiredSize <= THUMBNAIL_SIZE_336) {
return R.drawable.hero_image_sander_336;
} else if (desiredSize <= THUMBNAIL_SIZE_468) {
return R.drawable.hero_image_sander_468;
}
break;
case R.drawable.hero_image_router_1080:
if (desiredSize <= THUMBNAIL_SIZE_336) {
return R.drawable.hero_image_router_336;
} else if (desiredSize <= THUMBNAIL_SIZE_468) {
return R.drawable.hero_image_router_468;
}
break;
case R.drawable.hero_image_lathe_1080:
if (desiredSize <= THUMBNAIL_SIZE_336) {
return R.drawable.hero_image_lathe_336;
} else if (desiredSize <= THUMBNAIL_SIZE_468) {
return R.drawable.hero_image_lathe_468;
}
break;
case R.drawable.hero_image_more_1080:
if (desiredSize <= THUMBNAIL_SIZE_336) {
return R.drawable.hero_image_more_336;
} else if (desiredSize <= THUMBNAIL_SIZE_468) {
return R.drawable.hero_image_more_468;
}
break;
}
return resourceId;
}
}Testing out loading images that are the correct size for a Nexus 5 shows that we drop from the 30 milliseconds we saw after shrinking the file sizes in the previous section to just 7 milliseconds! This has also made our blurring code significantly faster (down from 30 milliseconds to about 15 milliseconds) because it’s operating on fewer pixels. Overall, it is still taking about 22 milliseconds to get the view, so it’s still slow, but the improvements so far have been substantial.
Before we move on, it’s worth noting that you can also tackle this by loading the images at a smaller size using the BitmapFactory class, which supports subsampling. By subsampling, you can read a fraction of the number of pixels. For instance, if you have an image that was 1000px wide but you only need it at 500px wide, you can read every other pixel. This isn’t as efficient as providing correctly sized images, but it is more universal.
The general idea is that you read in just the metadata about the image (which includes the dimensions) by making use of the Options class. Create a new instance of the Options class and set inJustDecodeBounds to true. Now when you decode the image with decodeResources, you use the Options object to tell it that you only want the bounds (the size of the image). The Options object will now have its outWidth, outHeight, and outMimeType set to the values of the actual image (and BitmapFactory will return null).
Once you know how big the image is, you figure out how to subsample the image. The BitmapFactory class works in powers of 2, so you can subsample every second pixel, every fourth pixel, every eighth pixel, and so forth. Using a simple while loop, we can double the sample size until the resulting image will be just larger than the desired width. Listing 10.3 shows a simple implementation of this method.
Listing 10.3 The getSizedBitmap Method
public static Bitmap getSizedBitmap(@NonNull Resources res, @DrawableRes int resId, int desiredWidth) {
// Load just the size of the image
BitmapFactory.Options options = new BitmapFactory.Options();
options.inJustDecodeBounds = true;
BitmapFactory.decodeResource(res, resId, options);
// Options now has the bounds; prepare it for getting the actual image
options.inSampleSize = 1;
options.inJustDecodeBounds = false;
if (options.outWidth > desiredWidth) {
final int halfWidth = options.outWidth / 2;
while (halfWidth / options.inSampleSize > desiredWidth) {
options.inSampleSize *= 2;
}
}
return BitmapFactory.decodeResource(res, resId, options);
}This is a simple way of making your image loading more efficient and this technique can be used throughout your app; however, it isn’t as efficient as having your images exactly the correct size. Testing image loading with this method, the average speed is around 15 milliseconds (with a fair bit of variation), compared to the 30 milliseconds without this method or the 7 milliseconds with properly sized images.
Using an Image Cache
Every time you load an image from disk, it has to be decoded again. As we’ve seen, this process is often very slow. Worse, we can be loading the same image multiple times because the view that was displaying it goes off the screen and garbage collection is triggered and later it comes back on screen. An image cache allows you to specify a certain amount of memory to use for images, and the typical pattern is an LRU (least-recently-used) cache. As you put images in and ask for images out, the cache keeps track of that usage. When you put in a new image and there isn’t enough room for it, the cache will evict the images that haven’t been used for the longest amount of time, so that images you just used (and are most likely to still be relevant) stay in memory. When you load images, they go through the image cache, which will keep them in memory as long as the cache has room. That means the view going off screen and coming back on might not cause the image to have to be read from disk, which can save several milliseconds.
You can use the LruCache class that is in the support library to work with any version of Android. It has two generics, one for the keys and one for the values (the objects you cache). For images, you’ll typically have a string key (such as a URL and filename), but you can use whatever makes sense for your needs. Because the LruCache class is designed to work in many situations, the concept of “size” can be defined by you. By default, the size of the cache is determined by the number of objects, but that doesn’t make sense for our use. A single large image will take up a lot more memory than several smaller ones, so we can make the size measured in kilobytes. We need to override the sizeOf method to return the number of kilobytes a given entry is. We also need to decide on the maximum size of the cache. This will depend heavily on the type of app you’re developing, but we can make this a portion of the overall memory available to our app. Let’s start with an eighth of the total memory. We can also place an upper limit on the size of 16mb so that our app is well behaved on devices that give each VM much more memory that we necessarily need. Listing 10.4 shows this simple class.
Listing 10.4 The BitmapCache Class
public class BitmapCache extends LruCache<String, Bitmap> {
public static final String TAG = "BitmapCache";
private static final int MAXIMUM_SIZE_IN_KB = 1024 * 16;
public BitmapCache() {
super(getCacheSize());
}
@Override
protected int sizeOf(String key, Bitmap bitmap) {
return bitmap.getByteCount() / 1024;
}
/**
* Returns the size of the cache in kilobytes
*
* @return int total kilobytes to make the cache
*/
private static int getCacheSize() {
// Maximum KB available to the VM
final int maxMemory = (int) (Runtime.getRuntime().maxMemory() / 1024);
// The smaller of an eighth of the total memory or 16MB
final int cacheSize = Math.min(maxMemory / 8, MAXIMUM_SIZE_IN_KB);
Log.v(TAG, "BitmapCache size: " + cacheSize + "kb");
return cacheSize;
}
}We can create the BitmapCache in our BitmapUtils class and then add some simple methods for interacting with it. In the case of our grid of images, we actually care more about the versions of the images that have been blurred along the bottom already, so we can directly cache those. Listing 10.5 shows the BitmapUtils methods we’ve added and Listing 10.6 shows the updated methods in CaptionedImageView.
Listing 10.5 The BitmapUtils Class Updated to Use the Cache
publicclass BitmapUtils {
private static final int THUMBNAIL_SIZE_336 = 336;
private static final int THUMBNAIL_SIZE_468 = 468;
private static final BitmapCache BITMAP_CACHE = new BitmapCache();
public synchronized static void cacheBitmap(@NonNull String key, @NonNull Bitmap bitmap) {
BITMAP_CACHE.put(key, bitmap);
}
public synchronized static Bitmap getBitmap(@NonNull String key) {
return BITMAP_CACHE.get(key);
}
public synchronized static Bitmap getBitmap(@NonNull Resources res, @DrawableRes int resId) {
String key = String.valueOf(resId);
Bitmap bitmap = BITMAP_CACHE.get(key);
if (bitmap == null) {
bitmap = BitmapFactory.decodeResource(res, resId);
BITMAP_CACHE.put(key, bitmap);
}
return bitmap;
}
public static int getScreenWidth(@NonNull Context context) {
WindowManager windowManager = (WindowManager) context.getSystemService(Context.WINDOW_SERVICE);
Display display = windowManager.getDefaultDisplay();
Point point = new Point();
display.getSize(point);
return point.x;
}
/**
* Returns a resource ID to a smaller version of the drawable, when possible.
*
* This is intended just for the hero images. If a smaller size of the resource ID cannot
* be found, the original resource ID is returned.
*
* @param resourceId int drawable resource ID to look for
* @param desiredSize int desired size in pixels of the drawable
* @return int drawable resource ID to use
*/
@DrawableRes
public static int getPresizedImage(@DrawableRes int resourceId, int desiredSize) {
switch (resourceId) {
case R.drawable.hero_image_clamps_1080:
if (desiredSize <= THUMBNAIL_SIZE_336) {
return R.drawable.hero_image_clamps_336;
} else if (desiredSize <= THUMBNAIL_SIZE_468) {
return R.drawable.hero_image_clamps_468;
}
break;
case R.drawable.hero_image_saw_1080:
if (desiredSize <= THUMBNAIL_SIZE_336) {
return R.drawable.hero_image_saw_336;
} else if (desiredSize <= THUMBNAIL_SIZE_468) {
return R.drawable.hero_image_saw_468;
}
break;
case R.drawable.hero_image_drill_1080:
if (desiredSize <= THUMBNAIL_SIZE_336) {
return R.drawable.hero_image_drill_336;
} else if (desiredSize <= THUMBNAIL_SIZE_468) {
return R.drawable.hero_image_drill_468;
}
break;
case R.drawable.hero_image_sander_1080:
if (desiredSize <= THUMBNAIL_SIZE_336) {
return R.drawable.hero_image_sander_336;
} else if (desiredSize <= THUMBNAIL_SIZE_468) {
return R.drawable.hero_image_sander_468;
}
break;
case R.drawable.hero_image_router_1080:
if (desiredSize <= THUMBNAIL_SIZE_336) {
return R.drawable.hero_image_router_336;
} else if (desiredSize <= THUMBNAIL_SIZE_468) {
return R.drawable.hero_image_router_468;
}
break;
case R.drawable.hero_image_lathe_1080:
if (desiredSize <= THUMBNAIL_SIZE_336) {
return R.drawable.hero_image_lathe_336;
} else if (desiredSize <= THUMBNAIL_SIZE_468) {
return R.drawable.hero_image_lathe_468;
}
break;
case R.drawable.hero_image_more_1080:
if (desiredSize <= THUMBNAIL_SIZE_336) {
return R.drawable.hero_image_more_336;
} else if (desiredSize <= THUMBNAIL_SIZE_468) {
return R.drawable.hero_image_more_468;
}
break;
}
return resourceId;
}
public static Bitmap getSizedBitmap(@NonNull Resources res, @DrawableRes int resId, int desiredWidth) {
// Load just the size of the image
BitmapFactory.Options options = new BitmapFactory.Options();
options.inJustDecodeBounds = true;
BitmapFactory.decodeResource(res, resId, options);
// Options now has the bounds; prepare it for getting the actual image
options.inSampleSize = 1;
options.inJustDecodeBounds = false;
if (options.outWidth > desiredWidth) {
final int halfWidth = options.outWidth / 2;
while (halfWidth / options.inSampleSize > desiredWidth) {
options.inSampleSize *= 2;
}
}
return BitmapFactory.decodeResource(res, resId, options);
}
}Listing 10.6 The Updated CaptionedImageView Methods
public void setImageResource(@DrawableRes int drawableResourceId) {
TraceCompat.beginSection("BLUR — setImageResource");
mDrawableResourceId = drawableResourceId;
Bitmap bitmap = BitmapUtils.getBitmap(getResources(), mDrawableResourceId);
mDrawable = new BitmapDrawable(getResources(), bitmap);
mImageView.setImageDrawable(mDrawable);
updateBlur();
TraceCompat.endSection();
}
private void updateBlur() {
if (!(mDrawable instanceof BitmapDrawable)) {
return;
}
final int textViewHeight = mTextView.getHeight();
final int imageViewHeight = mImageView.getHeight();
if (textViewHeight == 0 || imageViewHeight == 0) {
return;
}
// Get the Bitmap
final BitmapDrawable bitmapDrawable = (BitmapDrawable) mDrawable;
final Bitmap originalBitmap = bitmapDrawable.getBitmap();
// Determine the size of the TextView compared to the height of the ImageView
final float ratio = (float) textViewHeight / imageViewHeight;
// Calculate the height as a ratio of the Bitmap
final int height = (int) (ratio * originalBitmap.getHeight());
final int width = originalBitmap.getWidth();
final String blurKey = getBlurKey(width);
Bitmap newBitmap = BitmapUtils.getBitmap(blurKey);
if (newBitmap != null) {
mImageView.setImageBitmap(newBitmap);
return;
}
// The y position is the number of pixels height represents from the bottom of the Bitmap
final int y = originalBitmap.getHeight() — height;
TraceCompat.beginSection("BLUR — createBitmaps");
final Bitmap portionToBlur = Bitmap.createBitmap(originalBitmap, 0, y, originalBitmap.getWidth(), height);
final Bitmap blurredBitmap = Bitmap.createBitmap(portionToBlur.getWidth(), height, Bitmap.Config.ARGB_8888);
TraceCompat.endSection();
// Use RenderScript to blur the pixels
TraceCompat.beginSection("BLUR — RenderScript");
RenderScript rs = RenderScript.create(getContext());
ScriptIntrinsicBlur theIntrinsic = ScriptIntrinsicBlur.create(rs, Element.U8_4(rs));
TraceCompat.beginSection("BLUR — RenderScript Allocation");
Allocation tmpIn = Allocation.createFromBitmap(rs, portionToBlur);
// Fix internal trace that isn't ended
TraceCompat.endSection();
Allocation tmpOut = Allocation.createFromBitmap(rs, blurredBitmap);
// Fix internal trace that isn't ended
TraceCompat.endSection();
TraceCompat.endSection();
theIntrinsic.setRadius(25f);
theIntrinsic.setInput(tmpIn);
TraceCompat.beginSection("BLUR — RenderScript forEach");
theIntrinsic.forEach(tmpOut);
TraceCompat.endSection();
TraceCompat.beginSection("BLUR — RenderScript copyTo");
tmpOut.copyTo(blurredBitmap);
TraceCompat.endSection();
new Canvas(blurredBitmap).drawColor(mScrimColor);
TraceCompat.endSection();
// Create the new bitmap using the old plus the blurred portion and display it
TraceCompat.beginSection("BLUR — Finalize image");
newBitmap = originalBitmap.copy(Bitmap.Config.ARGB_8888, true);
final Canvas canvas = new Canvas(newBitmap);
canvas.drawBitmap(blurredBitmap, 0, y, new Paint());
BitmapUtils.cacheBitmap(blurKey, newBitmap);
mTextView.setBackground(null);
mImageView.setImageBitmap(newBitmap);
TraceCompat.endSection();
}Given that on a typical device six of the seven images in the woodworking tools app are available on the first screen (once the spacing is back to normal); you might consider precaching the seventh image. By precaching them all, you will slightly increase the loading time of the app, but you will ensure that the scrolling is smooth. If you had even more images to handle, you might even move the image loading and blurring to a background thread. Although RenderScript is extremely fast, it still takes time pass the data to the GPU, process it, and pass that data back, so it’s not a bad idea to push that work to a background thread if you’re going to be doing it often.