接着之前的《一种异步加载资源的方法(源于SDK文档)》,SDK文档在《Caching Bitmaps》中介绍了内存缓存与磁盘缓存的使用。
大家都知道,现在的手机屏幕分辨率是越来越大了,虽然之前我们介绍了异步加载图片的方法。但要知道,一个应用可用的内存是有限的。我们不可能将所有的内存都用来存储图片,也不可能为了内存而每次取图片时都上网下载(流量费是很贵滴,而且下载也很耗电啊)。
因此,对于已下载的图片,我们需要在本地维持一个缓存。
内存缓存
LurCache是一个内存缓存类(Android3.1引入,通过v4的支援包,可以在API Level 4以上使用)。它使用一个强连接的LinkedHashMap,将使用频率最高的图片缓存在内存中。
PS:在这之前,最流行的缓存方式是使用SoftReference与WeakReference。但从Android2.3开始,垃圾回收对于软引用与弱引用来说,变得越来越积极了。这也就造成了软引用与弱引用的效率变得很低(没几下就被回收了,然后又得再创建,和没缓存没太大区别)。同时,在Android3.0之前,Bitmap的数据是储存在所谓的native内存区中(可以想象成是用C语言申请的内存,很难被垃圾回收自动释放)。这也造成了应用非常容易发生内存溢出。
当然,要想使用LurCache,我们需要给定一个缓存大小。而要想确定缓存占多少内存,需要考虑以下条件:
- 应用的其他地方对内存的占用有多紧张?
- 有多少图片会同时在屏幕上显示?在它们显示时,要确保多少的其余图片可以马上显示而无明显延迟?
- 屏幕大小与密度如何?xhdpi的机子明显要比hdpi的机子需要更多的缓存。
- 每张图片大概有多大?
- 图片访问的频率是多少?有没有部分图片的访问频率远高于其他图片?如果是的话,你可能需要将这些图片进行缓存,甚至需要多个LurCache对象来缓存不同等级的图片。
- 你可以平衡质量与数量吗?有的时候,存储大量低分辨率的图片更有用。你可以在后台任务中加载高分辨率的。
没有绝对合适的大小或计算方法,你必须根据自身应用的特点来确定相应的解决方案。缓存太小,反而会由于频繁的重新创建而降低效率。缓存太大,自然也同样会造成内存溢出了。
以下是一个使用LurCache的例子,使用八分之一的可用内存作为缓存。在一个普通的hdpi的机子上,大概是4MB以上。
在一个800x480的屏幕上的全屏GridView显示的图片,大概需要1.5MB (800*480*4 bytes)的内存。也就是说,这个例子里的缓存,可以保存至少2.5屏的图片。
private
@Override
protected void
...
// 获取可用内存的最大值,超过这个数,就会产生OutOfMemory.
// 将其以KB为单位存储.
final int maxMemory = (int) (Runtime.getRuntime().maxMemory() / 1024);
// 使用八分之一的可用内存作为缓存.
final int cacheSize = maxMemory / 8;
new
@Override
protected int
// 缓存大小以KB为单位进行计算.
return bitmap.getByteCount() / 1024;
}
};
...
}
public void
if (getBitmapFromMemCache(key) == null) {
mMemoryCache.put(key, bitmap);
}
}
public
return
}
接着《一种异步加载资源的方法(源于SDK文档)》的例子,在加载图片时,先去缓存里查一下。如果缓存里有,直接设上去就行了。
public void loadBitmap(int
final
final
if (bitmap != null) {
mImageView.setImageBitmap(bitmap);
else
mImageView.setImageResource(R.drawable.image_placeholder);
new
task.execute(resId);
}
}
当然,BitmapWorkerTask也需要更新一下,当图片获取到后,将其加入缓存。
1. class BitmapWorkerTask extends
2. ...
3. // Decode image in background.
4. @Override
5. protected
6. final
7. 0], 100, 100);
8. 0]), bitmap);
9. return
10. }
11. ...
12. }
磁盘缓存
虽然内存缓存很有用,但光靠它还是不够的。像一些专门看图片的应用,里面的照片多了去了。很容易缓存就满了。或者当应用在后台被杀死时,内存缓存也会立刻清空。你还是得重新建立。
在这种情况下,就需要磁盘缓存来将图片保存到本地。这样,当内存缓存被清空时,可以通过磁盘缓存加快图片的加载。
以下的例子就是使用源码中提供的DiskLurCache来完成磁盘缓存的功能。
它并不是替代内存缓存,而是在内存缓存之外再额外备份了一次。
1. private
2. private final Object mDiskCacheLock = new
3. private boolean mDiskCacheStarting = true;
4. private static final int DISK_CACHE_SIZE = 1024 * 1024 * 10; // 10MB
5. private static final String DISK_CACHE_SUBDIR = "thumbnails";
6.
7. @Override
8. protected void
9. ...
10. // Initialize memory cache
11.
12. ...
13. // Initialize disk cache on background thread
14. this, DISK_CACHE_SUBDIR);
15. new
16. ...
17. }
18.
19. class InitDiskCacheTask extends
20. @Override
21. protected
22. synchronized
23. 0];
24. mDiskLruCache = DiskLruCache.open(cacheDir, DISK_CACHE_SIZE);
25. false; // Finished initialization
26. // Wake any waiting threads
27. }
28. return null;
29. }
30. }
31.
32. class BitmapWorkerTask extends
33. ...
34. // Decode image in background.
35. @Override
36. protected
37. final String imageKey = String.valueOf(params[0]);
38. // Check disk cache in background thread
39. Bitmap bitmap = getBitmapFromDiskCache(imageKey);
40. if (bitmap == null) {
41. // Not found in disk cache
42. // Process as normal
43. final
44. 0], 100, 100);
45. }
46. // Add final bitmap to caches
47. addBitmapToCache(imageKey, bitmap);
48. return
49. }
50. ...
51. }
52.
53. public void
54. // Add to memory cache as before
55. if (getBitmapFromMemCache(key) == null) {
56. mMemoryCache.put(key, bitmap);
57. }
58. // Also add to disk cache
59. synchronized
60. if (mDiskLruCache != null && mDiskLruCache.get(key) == null) {
61. mDiskLruCache.put(key, bitmap);
62. }
63. }
64. }
65.
66. public
67. synchronized
68. // Wait while disk cache is started from background thread
69. while
70. try
71. mDiskCacheLock.wait();
72. catch
73. }
74. }
75. if (mDiskLruCache != null) {
76. return
77. }
78. }
79. return null;
80. }
81.
82. // Creates a unique subdirectory of the designated app cache directory.
83. // Tries to use external
84. // but if not mounted, falls back on internal storage.
85. public static
86. // Check if media is mounted or storage is built-in, if so, try and use
87. // external cache dir
88. // otherwise use internal cache dir
89.
90. final
91. .getExternalStorageState()) || !isExternalStorageRemovable() ? getExternalCacheDir(
92. context).getPath() : context.getCacheDir().getPath();
93. return new
94. }
PS:即使是初始化磁盘缓存,也需要相应的磁盘操作。因此,使用了一个异步任务InitDiskCacheTask来进行。另外,为了防止在磁盘缓存建立成功前就去访问,在getBitmapFromDiskCache方法中,进行了wait操作。当磁盘缓存初始化后,如果提前访问了,相应的线程将被notifyAll唤醒。
处理Configuration Change
在程序运行时,我们经常会遇到Configuration Change,像横竖屏切换、语言改变等等。
而这些情况,往往会使得当前运行的Activity被销毁并重新创建。
为了防止在销毁与创建过程中重新建立缓存(耗时太久且影响效率,要是能直接保存就好了),我们可以通过Fragment。只要setRetainInstance(true)就行了。
如下图所示,在Activity的onCreate里,先判断相应的Fragment在不在FragmentManager里,要是在的话,直接获取相应的缓存对象。并且在Fragment的onCreate中setRetainInstance(true)。
1. private
2.
3. @Override
4. protected void
5. ...
6. RetainFragment mRetainFragment =
7. RetainFragment.findOrCreateRetainFragment(getFragmentManager());
8. mMemoryCache = RetainFragment.mRetainedCache;
9. if (mMemoryCache == null) {
10. new
11. // Initialize cache here as usual
12.
13. mRetainFragment.mRetainedCache = mMemoryCache;
14. }
15. ...
16. }
17.
18. class RetainFragment extends
19. private static final String TAG = "RetainFragment";
20. public
21.
22. public
23. }
24.
25. public static
26. RetainFragment fragment = (RetainFragment) fm.findFragmentByTag(TAG);
27. if (fragment == null) {
28. new
29. }
30. return
31. }
32.
33. @Override
34. public void
35. super.onCreate(savedInstanceState);
36. true);
37. }
38. }