bitmap缓存处理图片.docVIP

在您的UI中显示单个图片是非常简单的，如果您需要一次显示很多图片就有点复杂了。在很多情况下(例如使用 ListView, GridView 或者?ViewPager控件)，显示在屏幕上的图片以及即将显示在屏幕上的图片数量是非常大的(例如在图库中浏览大量图片)。 在这些控件中，当一个子控件不显示的时候，系统会重用该控件来循环显示 以便减少对内存的消耗。同时垃圾回收机制还会释放那些已经载入内存中的Bitmap资源(假设您没有强引用这些Bitmap)。一般来说这样都是不错的，但是在用户来回滑动屏幕的时候，为了保证UI的流畅性和载入图片的效率，您需要避免重复的处理这些需要显示的图片。 使用内存缓存和磁盘缓存可以解决这个问题，使用缓存可以让控件快速的加载已经处理过的图片。 本文介绍如何使用缓存来提高UI的载入输入和滑动的流畅性。 使用内存缓存 内存缓存提高了访问图片的速度，但是要占用不少内存。?LruCache类（在API 4之前可以使用Support Library?中的类 ）特别适合缓存Bitmap， 把最近使用到的Bitmap对象用强引用保存起来（保存到LinkedHashMap中），当缓存数量达到预定的值的时候，把不经常使用的对象删除。 注意:?过去，实现内存缓存的常用做法是使用SoftReference?或者WeakReference?bitmap 缓存，但是不推荐使用这种方式。从Android 2.3 (API Level 9) 开始，垃圾回收开始强制的回收掉 soft/weak 引用 从而导致这些缓存没有任何效率的提升。另外，在 Android 3.0 (API Level 11)之前，这些缓存的Bitmap数据保存在底层内存(native memory)中，并且达到预定条件后也不会释放这些对象，从而可能导致程序超过内存限制并崩溃。 在使用?LruCache?的时候，需要考虑如下一些因素来选择一个合适的缓存数量参数： 程序中还有多少内存可用 同时在屏幕上显示多少图片？要先缓存多少图片用来显示到即将看到的屏幕上？ 设备的屏幕尺寸和屏幕密度是多少？超高的屏幕密度(xhdpi 例如?Galaxy Nexus)设备显示同样的图片要比低屏幕密度(hdpi 例如?Nexus S)设备需要更多的内存。 图片的尺寸和格式决定了每个图片需要占用多少内存 图片访问的频率如何？一些图片的访问频率要比其他图片高很多？如果是这样的话，您可能需要把这些经常访问的图片放到内存中。 在质量和数量上如何平衡？有些情况下保存大量的低质量的图片是非常有用的，当需要的情况下使用后台线程来加入一个高质量版本的图片。 这里没有万能配方可以适合所有的程序，您需要分析您的使用情况并在指定自己的缓存策略。使用太小的缓存并不能起到应有的效果，而使用太大的缓存会消耗更多的内存从而有可能导致 java.lang.OutOfMemory 异常或者留下很少的内存供您的程序其他功能使用。 下面是一个使用?LruCache?缓存的示例: private?LruCachestring,?bitmap=?mMemoryCache;? ??????????????????????????????????????????????????????????????? @Override? protected?void?onCreate(Bundle?savedInstanceState)?{? ????...? ????//?Get?memory?class?of?this?device,?exceeding?this?amount?will?throw?an? ????//?OutOfMemory?exception.? ????final?int?memClass?=?((ActivityManager)?context.getSystemService(? ????????????Context.ACTIVITY_SERVICE)).getMemoryClass();? ??????????????????????????????????????????????????????????????? ????//?Use?1/8th?of?the?available?memory?for?this?memory?cache.? ????final?int?cacheSize?=?1024?*?1024?*?memClass?/?8;? ??????????????????????????????????????????????????????????????? ????mMemoryCache?=?new?LruCachestring,?bitmap=(cacheSize)?