本文主要内容

照片墙应用介绍

缓存使用思路

多线程使用

杂谈

记得本人工作之后，手头上第一个活就是做一个本地壁纸展示程序，当时正流行1080P的屏幕，为了展示屏幕效果，壁纸图片巨大无比，轻松突破10M，而且内置壁纸还有15张左右，当时面临的两个问题，一个就是oom问题，另一个就是流畅度问题，虽然后来都解决了，但之后就对这种巨大的图片有点虚。。

惭愧的是，5年以后的今天才写了这篇文章，不忘初心方得始终，这个道理虽然简单但今天才真正明白

照片墙应用介绍

应用中需要显示大量的图片，图片从网络获取，效果如下图：

应用有两个问题：

流畅地显示

省流量

流畅性是所有应用都必须要有的，图片要从网上下载，下载过程必须放到工作线程当中来解决。另外图片也有可以有一部分保存在内存当中，直接从内存当中获取并显示，这才是最快的方式。

图片有很多，用户理论上只用下载一遍图片就行了，不能重复去下载，缓存可以帮助用户节省流量。

缓存使用思路

Android缓存原理一文中说明了缓存的原理以及使用方式，如有不明白可参考此文。

其实缓存思路特别简单，在需要使用图片的时候，先查内存缓存，如果没有再查硬盘缓存，还没有则去网络下载，下载完毕后加入硬盘缓存以及内存缓存，以备下次再用。缓存是不是已满，该如何删除交给缓存工具类决定，但大体思路一定是这样。

本文中也是这么做的，而且硬盘缓存读取相当于IO过程，较缓慢，也可以放到工作线程当中，于是就可以把查内存缓存以外的所有操作都放到工作线程当中完成。

照片墙的核心代码如下：

private void loadBitmaps(ImageView imageView, String url) {

try {

Bitmap bitmap = getBitmapFromMemoryCache(url);

if (bitmap == null) {

Task task = new Task(imageView, url);

mPools.submit(task);

} else {

if (imageView != null && bitmap != null) {

imageView.setImageBitmap(bitmap);

}

}

} catch (Exception e) {

// TODO: handle exception

}

}

如果从内存缓存中无法获取到图片，则向线程池中提交一个任务，在线程池中完成图片的获取。

class Task implements Runnable {

ImageView iv;

String imageUrl;

Task(ImageView view, String url) {

iv = view;

imageUrl = url;

}

@Override

public void run() {

FileDescriptor fileDescriptor = null;

FileInputStream fileInputStream = null;

Snapshot snapshot = null;

try {

final String key = hashKeyForDisk(imageUrl);

snapshot = mDiskLruCache.get(key);

if (snapshot == null) {

Editor editor = mDiskLruCache.edit(key);

if (editor != null) {

OutputStream outputStream = editor.newOutputStream(0);

if (downloadUrlToStream(imageUrl, outputStream)) {

editor.commit();

} else {

editor.abort();

}

}

snapshot = mDiskLruCache.get(key);

}

if (snapshot != null) {

fileInputStream = (FileInputStream) snapshot

.getInputStream(0);

fileDescriptor = fileInputStream.getFD();

}

Bitmap bitmap = null;

if (fileDescriptor != null) {

bitmap = BitmapFactory.decodeFileDescriptor(fileDescriptor);

}

if (bitmap != null) {

addBitmapToMemoryCache(key, bitmap);

Result result = new Result(iv, bitmap, imageUrl);

Message msg = Message.obtain(mHandler, MSG_SHOW_BITMAP, result);

msg.sendToTarget();

}

} catch (Exception e) {

Log.e("okunu", "run", e);

}

}

}

和前文所说思路一样，先从硬盘缓存中读取，如果没有再从网络中下载图片。一定不能忘记将图片添加进入硬盘缓存和内存缓存中来，这一步非常重要。

由于硬盘缓存的使用方法，在从网上下载图片的时候，是直接下载到缓存文件当中的，而不是先下载再复制一份到硬盘缓存当中，因为这样可以节省一次IO过程。

另外还有一些小细节，比如最后如何刷新界面，首先在工作线程中是无法刷新UI的，所以在此处用handler，将结果返回主线程中处理。

if (msg.what == MSG_SHOW_BITMAP) {

Object obj = msg.obj;

if (obj != null) {

Result result = (Result) obj;

if (result.iv.getTag().equals(result.url)) {

result.iv.setImageBitmap(result.bitmap);

}

}

}

结果中包含图片、imageview以及url，为了防止图片显示错乱，还加以判定，只有imageview的tag等于此url的时候，才更新图片，如此则不会更新错乱。

多线程使用

在这种有大量耗时操作的时候，开启工作线程是非常必要的，但如何优雅地使用线程，其实仍然有门道。

android中有很多种开启工作线程的方式。

AsyncTask，封装地非常好，不同的回调函数还处于不同的线程当中，方便用户拿结果更新UI，但如果有多个AsyncTask实例在执行，它们是顺序执行，并不是想象中的多线程在多核CPU上同时执行。

Thread，原始的线程使用方式，如果构造太多，不优雅，线程不能得到复用，浪费资源，开启一个线程也是有开销的

HandlerThread，能够与handler结合，一种非常优雅的工作线程开启方式，不过不太适合大量任务的情况，这种只相当于线程池中只有一个线程在跑

线程池，重量级武器，适合大量任务的情况

android中开启工作线程包括但不限于以上4种，它们的优劣大致如上所述，需要我们根据不同的情形选用不同的方式，写出优雅的代码。

在照片墙应用中，明显是有大量任务需要工作线程来执行的，以上四种情况中，最适合的就是线程池了，它的速度效率是最高的，有兴趣的同学可以去做做实验，以四种不同方式来完成任务，看看哪个效率最高

杂谈

在文章一开始的时候，就聊到一个话题，OOM的问题，如果图片太大，如果防止OOM呢？

这个问题相信很多人都知道答案：

/**

* If set to true, the decoder will return null (no bitmap), but

* the out... fields will still be set, allowing the caller to

* query the bitmap without having to allocate the memory for its pixels.

*/

public boolean inJustDecodeBounds;

/**

* If set to a value > 1, requests the decoder to subsample the original

* image, returning a smaller image to save memory. The sample size is

* the number of pixels in either dimension that correspond to a single

* pixel in the decoded bitmap. For example, inSampleSize == 4 returns

* an image that is 1/4 the width/height of the original, and 1/16 the

* number of pixels. Any value <= 1 is treated the same as 1. Note: the

* decoder uses a final value based on powers of 2, any other value will

* be rounded down to the nearest power of 2.

*/

public int inSampleSize;

利用inJustDecodeBounds，计算出inSampleSize，相信这样的逻辑网上一找一大堆，本人在此不再复述。如果你的图片应用，图片都是大于5M以上的高清大图，那么一定要考虑这个方法了。

另外由url转化成hash key的时候，怎么这么费劲呢？

public String hashKeyForDisk(String key) {

String cacheKey;

try {

final MessageDigest mDigest = MessageDigest.getInstance("MD5");

mDigest.update(key.getBytes());

cacheKey = bytesToHexString(mDigest.digest());

Log.i("okunu", "cacheKey = " + cacheKey);

} catch (NoSuchAlgorithmException e) {

cacheKey = String.valueOf(key.hashCode());

}

return cacheKey;

}

private String bytesToHexString(byte[] bytes) {

StringBuilder sb = new StringBuilder();

for (int i = 0; i < bytes.length; i++) {

String hex = Integer.toHexString(0xFF & bytes[i]);

if (hex.length() == 1) {

sb.append('0');

}

sb.append(hex);

}

return sb.toString();

}

第一步，我们通常能理解，获取url的md5值，因为url中可能含有各种奇异字符，不适合作为key来使用，但bytesToHexString方法的作用是什么？

其实就是将byte数据转化成16进制，生成文件名而已。

代码已经上传到github当中，有需要的可以取用