图片的缓存
高效加载大图片
我们在编写Android程序的时候经常要用到许多图片，不同图片总是会有不同的形状、不同的大小，但在大多数情况下，这些图片都会大于我们程序所需要的大小。比如说系统图片库里展示的图片大都是用手机摄像头拍出来的，这些图片的分辨率会比我们手机屏幕的分辨率高得多。大家应该知道，我们编写的应用程序都是有一定内存限制的，程序占用了过高的内存就容易出现OOM(OutOfMemory)异常。我们可以通过下面的代码看出每个应用程序最高可用内存是多少。
- int maxMemory = (int) (Runtime.getRuntime().maxMemory() / 1024);
- Log.d("TAG", "Max memory is " + maxMemory + "KB");
因此在展示高分辨率图片的时候，最好先将图片进行压缩。压缩后的图片大小应该和用来展示它的控件大小相近，在一个很小的ImageView上显示一张超大的图片不会带来任何视觉上的好处，但却会占用我们相当多宝贵的内存，而且在性能上还可能会带来负面影响。下面我们就来看一看，如何对一张大图片进行适当的压缩，让它能够以最佳大小显示的同时，还能防止OOM的出现。
BitmapFactory这个类提供了多个解析方法(decodeByteArray, decodeFile, decodeResource等)用于创建Bitmap对象，我们应该根据图片的来源选择合适的方法。比如SD卡中的图片可以使用decodeFile方法，网络上的图片可以使用decodeStream方法，资源文件中的图片可以使用decodeResource方法。这些方法会尝试为已经构建的bitmap分配内存，这时就会很容易导致OOM出现。为此每一种解析方法都提供了一个可选的BitmapFactory.Options参数，将这个参数的inJustDecodeBounds属性设置为true就可以让解析方法禁止为bitmap分配内存，返回值也不再是一个Bitmap对象，而是null。虽然Bitmap是null了，但是BitmapFactory.Options的outWidth、outHeight和outMimeType属性都会被赋值。这个技巧让我们可以在加载图片之前就获取到图片的长宽值和MIME类型，从而根据情况对图片进行压缩。如下代码所示：
[java] view plaincopy
- BitmapFactory.Options options = new BitmapFactory.Options();
- options.inJustDecodeBounds = true;
- BitmapFactory.decodeResource(getResources(), R.id.myimage, options);
- int imageHeight = options.outHeight;
- int imageWidth = options.outWidth;
- String imageType = options.outMimeType;
为了避免OOM异常，最好在解析每张图片的时候都先检查一下图片的大小，除非你非常信任图片的来源，保证这些图片都不会超出你程序的可用内存。
现在图片的大小已经知道了，我们就可以决定是把整张图片加载到内存中还是加载一个压缩版的图片到内存中。以下几个因素是我们需要考虑的：
- 预估一下加载整张图片所需占用的内存。
- 为了加载这一张图片你所愿意提供多少内存。
- 用于展示这张图片的控件的实际大小。
- 当前设备的屏幕尺寸和分辨率。
比如，你的ImageView只有128*96像素的大小，只是为了显示一张缩略图，这时候把一张1024*768像素的图片完全加载到内存中显然是不值得的。
那我们怎样才能对图片进行压缩呢？通过设置BitmapFactory.Options中inSampleSize的值就可以实现。比如我们有一张2048*1536像素的图片，将inSampleSize的值设置为4，就可以把这张图片压缩成512*384像素。原本加载这张图片需要占用13M的内存，压缩后就只需要占用0.75M了(假设图片是ARGB_8888类型，即每个像素点占用4个字节)。下面的方法可以根据传入的宽和高，计算出合适的inSampleSize值：
[java] view plaincopy
- public static int calculateInSampleSize(BitmapFactory.Options options,
- int reqWidth, int reqHeight) {
- // 源图片的高度和宽度
- final int height = options.outHeight;
- final int width = options.outWidth;
- int inSampleSize = 1;
- if (height > reqHeight || width > reqWidth) {
- // 计算出实际宽高和目标宽高的比率
- final int heightRatio = Math.round((float) height / (float) reqHeight);
- 10. final int widthRatio = Math.round((float) width / (float) reqWidth);
- 11. // 选择宽和高中最小的比率作为inSampleSize的值，这样可以保证最终图片的宽和高
- 12. // 一定都会大于等于目标的宽和高。
- 13. inSampleSize = heightRatio < widthRatio ? heightRatio : widthRatio;
- 14. }
- 15. return inSampleSize;
16. }
使用这个方法，首先你要将BitmapFactory.Options的inJustDecodeBounds属性设置为true，解析一次图片。然后将BitmapFactory.Options连同期望的宽度和高度一起传递到到calculateInSampleSize方法中，就可以得到合适的inSampleSize值了。之后再解析一次图片，使用新获取到的inSampleSize值，并把inJustDecodeBounds设置为false，就可以得到压缩后的图片了。
[java] view plaincopy
- public static Bitmap decodeSampledBitmapFromResource(Resources res, int resId,
- int reqWidth, int reqHeight) {
- // 第一次解析将inJustDecodeBounds设置为true，来获取图片大小
- final BitmapFactory.Options options = new BitmapFactory.Options();
- options.inJustDecodeBounds = true;
- BitmapFactory.decodeResource(res, resId, options);
- // 调用上面定义的方法计算inSampleSize值
- options.inSampleSize = calculateInSampleSize(options, reqWidth, reqHeight);
- // 使用获取到的inSampleSize值再次解析图片
- 10. options.inJustDecodeBounds = false;
- 11. return BitmapFactory.decodeResource(res, resId, options);
12. }
下面的代码非常简单地将任意一张图片压缩成100*100的缩略图，并在ImageView上展示。
[java] view plaincopy
- mImageView.setImageBitmap(
- decodeSampledBitmapFromResource(getResources(), R.id.myimage, 100, 100));
使用图片缓存技术
在你应用程序的UI界面加载一张图片是一件很简单的事情，但是当你需要在界面上加载一大堆图片的时候，情况就变得复杂起来。在很多情况下，（比如使用ListView, GridView 或者 ViewPager 这样的组件），屏幕上显示的图片可以通过滑动屏幕等事件不断地增加，最终导致OOM。
为了保证内存的使用始终维持在一个合理的范围，通常会把被移除屏幕的图片进行回收处理。此时垃圾回收器也会认为你不再持有这些图片的引用，从而对这些图片进行GC操作。用这种思路来解决问题是非常好的，可是为了能让程序快速运行，在界面上迅速地加载图片，你又必须要考虑到某些图片被回收之后，用户又将它重新滑入屏幕这种情况。这时重新去加载一遍刚刚加载过的图片无疑是性能的瓶颈，你需要想办法去避免这个情况的发生。
这个时候，使用内存缓存技术可以很好的解决这个问题，它可以让组件快速地重新加载和处理图片。下面我们就来看一看如何使用内存缓存技术来对图片进行缓存，从而让你的应用程序在加载很多图片的时候可以提高响应速度和流畅性。
内存缓存技术对那些大量占用应用程序宝贵内存的图片提供了快速访问的方法。其中最核心的类是LruCache (此类在android-support-v4的包中提供) 。这个类非常适合用来缓存图片，它的主要算法原理是把最近使用的对象用强引用存储在 LinkedHashMap 中，并且把最近最少使用的对象在缓存值达到预设定值之前从内存中移除。
在过去，我们经常会使用一种非常流行的内存缓存技术的实现，即软引用或弱引用 (SoftReference or WeakReference)。但是现在已经不再推荐使用这种方式了，因为从 Android 2.3 (API Level 9)开始，垃圾回收器会更倾向于回收持有软引用或弱引用的对象，这让软引用和弱引用变得不再可靠。另外，Android 3.0 (API Level 11)中，图片的数据会存储在本地的内存当中，因而无法用一种可预见的方式将其释放，这就有潜在的风险造成应用程序的内存溢出并崩溃。
为了能够选择一个合适的缓存大小给LruCache, 有以下多个因素应该放入考虑范围内，例如：
- 你的设备可以为每个应用程序分配多大的内存？
- 设备屏幕上一次最多能显示多少张图片？有多少图片需要进行预加载，因为有可能很快也会显示在屏幕上？
- 你的设备的屏幕大小和分辨率分别是多少？一个超高分辨率的设备（例如 Galaxy Nexus) 比起一个较低分辨率的设备（例如 Nexus S），在持有相同数量图片的时候，需要更大的缓存空间。
- 图片的尺寸和大小，还有每张图片会占据多少内存空间。
- 图片被访问的频率有多高？会不会有一些图片的访问频率比其它图片要高？如果有的话，你也许应该让一些图片常驻在内存当中，或者使用多个LruCache 对象来区分不同组的图片。
- 你能维持好数量和质量之间的平衡吗？有些时候，存储多个低像素的图片，而在后台去开线程加载高像素的图片会更加的有效。
并没有一个指定的缓存大小可以满足所有的应用程序，这是由你决定的。你应该去分析程序内存的使用情况，然后制定出一个合适的解决方案。一个太小的缓存空间，有可能造成图片频繁地被释放和重新加载，这并没有好处。而一个太大的缓存空间，则有可能还是会引起 java.lang.OutOfMemory 的异常。
下面是一个使用 LruCache 来缓存图片的例子：
[java] view plaincopy
- private LruCache<String, Bitmap> mMemoryCache;
- @Override
- protected void onCreate(Bundle savedInstanceState) {
- // 获取到可用内存的最大值，使用内存超出这个值会引起OutOfMemory异常。
- // LruCache通过构造函数传入缓存值，以KB为单位。
- int maxMemory = (int) (Runtime.getRuntime().maxMemory() / 1024);
- // 使用最大可用内存值的1/8作为缓存的大小。
- int cacheSize = maxMemory / 8;
- 10. mMemoryCache = new LruCache<String, Bitmap>(cacheSize) {
- 11. @Override
- 12. protected int sizeOf(String key, Bitmap bitmap) {
- 13. // 重写此方法来衡量每张图片的大小，默认返回图片数量。
- 14. return bitmap.getByteCount() / 1024;
- 15. }
- 16. };
17. }
- 18.
19. public void addBitmapToMemoryCache(String key, Bitmap bitmap) {
- 20. if (getBitmapFromMemCache(key) == null) {
- 21. mMemoryCache.put(key, bitmap);
- 22. }
23. }
- 24.
25. public Bitmap getBitmapFromMemCache(String key) {
- 26. return mMemoryCache.get(key);
27. }
在这个例子当中，使用了系统分配给应用程序的八分之一内存来作为缓存大小。在中高配置的手机当中，这大概会有4兆(32/8)的缓存空间。一个全屏幕的 GridView 使用4张 800x480分辨率的图片来填充，则大概会占用1.5兆的空间(800*480*4)。因此，这个缓存大小可以存储2.5页的图片。
当向 ImageView 中加载一张图片时,首先会在 LruCache 的缓存中进行检查。如果找到了相应的键值，则会立刻更新ImageView ，否则开启一个后台线程来加载这张图片。
[java] view plaincopy
- public void loadBitmap(int resId, ImageView imageView) {
- final String imageKey = String.valueOf(resId);
- final Bitmap bitmap = getBitmapFromMemCache(imageKey);
- if (bitmap != null) {
- imageView.setImageBitmap(bitmap);
- } else {
- imageView.setImageResource(R.drawable.image_placeholder);
- BitmapWorkerTask task = new BitmapWorkerTask(imageView);
- task.execute(resId);
- 10. }
11. }
BitmapWorkerTask 还要把新加载的图片的键值对放到缓存中。
[java] view plaincopy
- class BitmapWorkerTask extends AsyncTask<Integer, Void, Bitmap> {
- // 在后台加载图片。
- @Override
- protected Bitmap doInBackground(Integer... params) {
- final Bitmap bitmap = decodeSampledBitmapFromResource(
- getResources(), params[0], 100, 100);
- addBitmapToMemoryCache(String.valueOf(params[0]), bitmap);
- return bitmap;
- }
10. }
掌握了以上两种方法，不管是要在程序中加载超大图片，还是要加载大量图片，都不用担心OOM的问题了!不过仅仅是理论地介绍不知道大家能不能完全理解，在后面的文章中我会演示如何在实际程序中灵活运用上述技巧来避免程序OOM
Android照片墙的实现：
照片墙这种功能现在应该算是挺常见了，在很多应用中你都可以经常看到照片墙的身影。它的设计思路其实也非常简单，用一个GridView控件当作“墙”，然后随着GridView的滚动将一张张照片贴在“墙”上，这些照片可以是手机本地中存储的，也可以是从网上下载的。制作类似于这种的功能的应用，有一个非常重要的问题需要考虑，就是图片资源何时应该释放。因为随着GridView的滚动，加载的图片可能会越来越多，如果没有一种合理的机制对图片进行释放，那么当图片达到一定上限时，程序就必然会崩溃。
今天我们照片墙应用的实现，重点也是放在了如何防止由于图片过多导致程序崩溃上面。主要的核心算法使用了Android中提供的LruCache类，这个类是3.1版本中提供的，如果你是在更早的Android版本中开发，则需要导入android-support-v4的jar包。
第一个要考虑的问题就是，我们从哪儿去收集这么多的图片呢？这里我从谷歌官方提供的Demo里将图片源取了出来，我们就从这些网址中下载图片，代码如下所示：
新建或打开activity_main.xml作为程序的主布局，加入如下代码：
[html] view plaincopy
- <LinearLayout xmlns:android="http://schemas.android.com/apk/res/android"
- xmlns:tools="http://schemas.android.com/tools"
- android:layout_width="wrap_content"
- android:layout_height="wrap_content" >
- <GridView
- android:id="@+id/photo_wall"
- android:layout_width="match_parent"
- android:layout_height="wrap_content"
- 10. android:columnWidth="90dip"
- 11. android:stretchMode="columnWidth"
- 12. android:numColumns="auto_fit"
- 13. android:verticalSpacing="10dip"
- 14. android:gravity="center"
- 15. ></GridView>
- 16.
17. </LinearLayout>
可以看到，我们在这个布局文件中仅加入了一个GridView，这也就是我们程序中的“墙”，所有的图片都将贴在这个“墙”上。
接着我们定义GridView中每一个子View的布局，新建一个photo_layout.xml布局，加入如下代码：
[html] view plaincopy
- <RelativeLayout xmlns:android="http://schemas.android.com/apk/res/android"
- xmlns:tools="http://schemas.android.com/tools"
- android:layout_width="wrap_content"
- android:layout_height="wrap_content" >
- <ImageView
- android:id="@+id/photo"
- android:layout_width="90dip"
- android:layout_height="90dip"
- 10. android:src="@drawable/empty_photo"
- 11. android:layout_centerInParent="true"
- 12. />
- 13.
14. </RelativeLayout>
在每一个子View中我们就简单使用了一个ImageView来显示一张图片。这样所有的布局就已经定义好了。
接下来新建PhotoWallAdapter做为GridView的适配器，代码如下所示：
[java] view plaincopy
- public class PhotoWallAdapter extends ArrayAdapter<String> implements OnScrollListener {
- /**
- * 记录所有正在下载或等待下载的任务。
- */
- private Set<BitmapWorkerTask> taskCollection;
- /**
- * 图片缓存技术的核心类，用于缓存所有下载好的图片，在程序内存达到设定值时会将最少最近使用的图片移除掉。
- 10. */
- 11. private LruCache<String, Bitmap> mMemoryCache;
- 12.
- 13. /**
- 14. * GridView的实例
- 15. */
- 16. private GridView mPhotoWall;
- 17.
- 18. /**
- 19. * 第一张可见图片的下标
- 20. */
- 21. private int mFirstVisibleItem;
- 22.
- 23. /**
- 24. * 一屏有多少张图片可见
- 25. */
- 26. private int mVisibleItemCount;
- 27.
- 28. /**
- 29. * 记录是否刚打开程序，用于解决进入程序不滚动屏幕，不会下载图片的问题。
- 30. */
- 31. private boolean isFirstEnter = true;
- 32.
- 33. public PhotoWallAdapter(Context context, int textViewResourceId, String[] objects,
- 34. GridView photoWall) {
- 35. super(context, textViewResourceId, objects);
- 36. mPhotoWall = photoWall;
- 37. taskCollection = new HashSet<BitmapWorkerTask>();
- 38. // 获取应用程序最大可用内存
- 39. int maxMemory = (int) Runtime.getRuntime().maxMemory();
- 40. int cacheSize = maxMemory / 8;
- 41. // 设置图片缓存大小为程序最大可用内存的1/8
- 42. mMemoryCache = new LruCache<String, Bitmap>(cacheSize) {
- 43. @Override
- 44. protected int sizeOf(String key, Bitmap bitmap) {
- 45. return bitmap.getByteCount();
- 46. }
- 47. };
- 48. mPhotoWall.setOnScrollListener(this);
- 49. }
- 50.
- 51. @Override
- 52. public View getView(int position, View convertView, ViewGroup parent) {
- 53. final String url = getItem(position);
- 54. View view;
- 55. if (convertView == null) {
- 56. view = LayoutInflater.from(getContext()).inflate(R.layout.photo_layout, null);
- 57. } else {
- 58. view = convertView;
- 59. }
- 60. final ImageView photo = (ImageView) view.findViewById(R.id.photo);
- 61. // 给ImageView设置一个Tag，保证异步加载图片时不会乱序
- 62. photo.setTag(url);
- 63. setImageView(url, photo);
- 64. return view;
- 65. }
- 66.
- 67. /**
- 68. * 给ImageView设置图片。首先从LruCache中取出图片的缓存，设置到ImageView上。如果LruCache中没有该图片的缓存，
- 69. * 就给ImageView设置一张默认图片。
- 70. *
- 71. * @param imageUrl
- 72. * 图片的URL地址，用于作为LruCache的键。
- 73. * @param imageView
- 74. * 用于显示图片的控件。
- 75. */
- 76. private void setImageView(String imageUrl, ImageView imageView) {
- 77. Bitmap bitmap = getBitmapFromMemoryCache(imageUrl);
- 78. if (bitmap != null) {
- 79. imageView.setImageBitmap(bitmap);
- 80. } else {
- 81. imageView.setImageResource(R.drawable.empty_photo);
- 82. }
- 83. }
- 84.
- 85. /**
- 86. * 将一张图片存储到LruCache中。
- 87. *
- 88. * @param key
- 89. * LruCache的键，这里传入图片的URL地址。
- 90. * @param bitmap
- 91. * LruCache的键，这里传入从网络上下载的Bitmap对象。
- 92. */
- 93. public void addBitmapToMemoryCache(String key, Bitmap bitmap) {
- 94. if (getBitmapFromMemoryCache(key) == null) {
- 95. mMemoryCache.put(key, bitmap);
- 96. }
- 97. }
- 98.
- 99. /**
- 100. * 从LruCache中获取一张图片，如果不存在就返回null。
- 101. *
- 102. * @param key
- 103. * LruCache的键，这里传入图片的URL地址。
- 104. * @return 对应传入键的Bitmap对象，或者null。
- 105. */
- 106. public Bitmap getBitmapFromMemoryCache(String key) {
- 107. return mMemoryCache.get(key);
- 108. }
- 109.
- 110. @Override
- 111. public void onScrollStateChanged(AbsListView view, int scrollState) {
- 112. // 仅当GridView静止时才去下载图片，GridView滑动时取消所有正在下载的任务
- 113. if (scrollState == SCROLL_STATE_IDLE) {
- 114. loadBitmaps(mFirstVisibleItem, mVisibleItemCount);
- 115. } else {
- 116. cancelAllTasks();
- 117. }
- 118. }
- 119.
- 120. @Override
- 121. public void onScroll(AbsListView view, int firstVisibleItem, int visibleItemCount,
- 122. int totalItemCount) {
- 123. mFirstVisibleItem = firstVisibleItem;
- 124. mVisibleItemCount = visibleItemCount;
- 125. // 下载的任务应该由onScrollStateChanged里调用，但首次进入程序时onScrollStateChanged并不会调用，
- 126. // 因此在这里为首次进入程序开启下载任务。
- 127. if (isFirstEnter && visibleItemCount > 0) {
- 128. loadBitmaps(firstVisibleItem, visibleItemCount);
- 129. isFirstEnter = false;
- 130. }
- 131. }
- 132.
- 133. /**
- 134. * 加载Bitmap对象。此方法会在LruCache中检查所有屏幕中可见的ImageView的Bitmap对象，
- 135. * 如果发现任何一个ImageView的Bitmap对象不在缓存中，就会开启异步线程去下载图片。
- 136. *
- 137. * @param firstVisibleItem
- 138. * 第一个可见的ImageView的下标
- 139. * @param visibleItemCount
- 140. * 屏幕中总共可见的元素数
- 141. */
- 142. private void loadBitmaps(int firstVisibleItem, int visibleItemCount) {
- 143. try {
- 144. for (int i = firstVisibleItem; i < firstVisibleItem + visibleItemCount; i++) {
- 145. String imageUrl = Images.imageThumbUrls[i];
- 146. Bitmap bitmap = getBitmapFromMemoryCache(imageUrl);
- 147. if (bitmap == null) {
- 148. BitmapWorkerTask task = new BitmapWorkerTask();
- 149. taskCollection.add(task);
- 150. task.execute(imageUrl);
- 151. } else {
- 152. ImageView imageView = (ImageView) mPhotoWall.findViewWithTag(imageUrl);
- 153. if (imageView != null && bitmap != null) {
- 154. imageView.setImageBitmap(bitmap);
- 155. }
- 156. }
- 157. }
- 158. } catch (Exception e) {
- 159. e.printStackTrace();
- 160. }
- 161. }
- 162.
- 163. /**
- 164. * 取消所有正在下载或等待下载的任务。
- 165. */
- 166. public void cancelAllTasks() {
- 167. if (taskCollection != null) {
- 168. for (BitmapWorkerTask task : taskCollection) {
- 169. task.cancel(false);
- 170. }
- 171. }
- 172. }
- 173.
- 174. /**
- 175. * 异步下载图片的任务。
- 176. *
- 177. * @author guolin
- 178. */
- 179. class BitmapWorkerTask extends AsyncTask<String, Void, Bitmap> {
- 180.
- 181. /**
- 182. * 图片的URL地址
- 183. */
- 184. private String imageUrl;
- 185.
- 186. @Override
- 187. protected Bitmap doInBackground(String... params) {
- 188. imageUrl = params[0];
- 189. // 在后台开始下载图片
- 190. Bitmap bitmap = downloadBitmap(params[0]);
- 191. if (bitmap != null) {
- 192. // 图片下载完成后缓存到LrcCache中
- 193. addBitmapToMemoryCache(params[0], bitmap);
- 194. }
- 195. return bitmap;
- 196. }
- 197.
- 198. @Override
- 199. protected void onPostExecute(Bitmap bitmap) {
- 200. super.onPostExecute(bitmap);
- 201. // 根据Tag找到相应的ImageView控件，将下载好的图片显示出来。
- 202. ImageView imageView = (ImageView) mPhotoWall.findViewWithTag(imageUrl);
- 203. if (imageView != null && bitmap != null) {
- 204. imageView.setImageBitmap(bitmap);
- 205. }
- 206. taskCollection.remove(this);
- 207. }
- 208.
- 209. /**
- 210. * 建立HTTP请求，并获取Bitmap对象。
- 211. *
- 212. * @param imageUrl
- 213. * 图片的URL地址
- 214. * @return 解析后的Bitmap对象
- 215. */
- 216. private Bitmap downloadBitmap(String imageUrl) {
- 217. Bitmap bitmap = null;
- 218. HttpURLConnection con = null;
- 219. try {
- 220. URL url = new URL(imageUrl);
- 221. con = (HttpURLConnection) url.openConnection();
- 222. con.setConnectTimeout(5 * 1000);
- 223. con.setReadTimeout(10 * 1000);
- 224. con.setDoInput(true);
- 225. con.setDoOutput(true);
- 226. bitmap = BitmapFactory.decodeStream(con.getInputStream());
- 227. } catch (Exception e) {
- 228. e.printStackTrace();
- 229. } finally {
- 230. if (con != null) {
- 231. con.disconnect();
- 232. }
- 233. }
- 234. return bitmap;
- 235. }
- 236.
- 237. }
- 238.
239. }
PhotoWallAdapter是整个照片墙程序中最关键的一个类了，这里我来重点给大家讲解一下。首先在PhotoWallAdapter的构造函数中，我们初始化了LruCache类，并设置了最大缓存容量为程序最大可用内存的1/8，接下来又为GridView注册了一个滚动监听器。然后在getView()方法中，我们为每个ImageView设置了一个唯一的Tag，这个Tag的作用是为了后面能够准确地找回这个ImageView，不然异步加载图片会出现乱序的情况。之后调用了setImageView()方法为ImageView设置一张图片，这个方法首先会从LruCache缓存中查找是否已经缓存了这张图片，如果成功找到则将缓存中的图片显示在ImageView上，否则就显示一张默认的空图片。
看了半天，那到底是在哪里下载图片的呢？这是在GridView的滚动监听器中进行的，在onScrollStateChanged()方法中，我们对GridView的滚动状态进行了判断，如果当前GridView是静止的，则调用loadBitmaps()方法去下载图片，如果GridView正在滚动，则取消掉所有下载任务，这样可以保证GridView滚动的流畅性。在loadBitmaps()方法中，我们为屏幕上所有可见的GridView子元素开启了一个线程去执行下载任务，下载成功后将图片存储到LruCache当中，然后通过Tag找到相应的ImageView控件，把下载好的图片显示出来。
由于我们使用了LruCache来缓存图片，所以不需要担心内存溢出的情况，当LruCache中存储图片的总大小达到容量上限的时候，会自动把最近最少使用的图片从缓存中移除。
最后新建或打开MainActivity作为程序的主Activity，代码如下所示：
[java] view plaincopy
- public class MainActivity extends Activity {
- /**
- * 用于展示照片墙的GridView
- */
- private GridView mPhotoWall;
- /**
- * GridView的适配器
- 10. */
- 11. private PhotoWallAdapter adapter;
- 12.
- 13. @Override
- 14. protected void onCreate(Bundle savedInstanceState) {
- 15. super.onCreate(savedInstanceState);
- 16. setContentView(R.layout.activity_main);
- 17. mPhotoWall = (GridView) findViewById(R.id.photo_wall);
- 18. adapter = new PhotoWallAdapter(this, 0, Images.imageThumbUrls, mPhotoWall);
- 19. mPhotoWall.setAdapter(adapter);
- 20. }
- 21.
- 22. @Override
- 23. protected void onDestroy() {
- 24. super.onDestroy();
- 25. // 退出程序时结束所有的下载任务
- 26. adapter.cancelAllTasks();
- 27. }
- 28.
29. }
MainActivity中的代码非常简单，没什么需要说明的了，在Activity被销毁时取消掉了所有的下载任务，避免程序在后台耗费流量。另外由于我们使用了网络功能，别忘了在AndroidManifest.xml中加入网络权限的声明。
« 能够对图片的优化进行相应的处理
1、利用“三级缓存”实现图片的优化
第一次是要从服务器获取的，以后每次显示图片，首先判断内存中获取，如果没有，再从本地缓存目录中获取，如果还没有，最后就需要发送请求从服务器获取。服务器端下载的图片是使用Http的缓存机制，每次执行将本地图片的时间发送给服务器，如果返回码是304，说明服务端的图片和本地的图片是相同的，直接使用本地保存的图片，如果返回码是200，则开始下载新的图片并实现缓存。在从服务器获取到图片后，需要再在本地和内存中分别存一份，这样下次直接就可以从内存中直接获取了，这样就加快了显示的速度，提高了用户的体验。
2、图片过大导致内存溢出：
模拟器的RAM比较小，由于每张图片先前是压缩的情况，放入到Bitmap的时候，大小会变大，导致超出RAM内存
★android 中用bitmap 时很容易内存溢出，报如下错误：Java.lang.OutOfMemoryError : bitmap size exceeds VM budget
解决：
方法1： 主要是加上这段：等比例缩小图片
BitmapFactory.Options options = new BitmapFactory.Options();
options.inSampleSize = 2;
1）通过getResource()方法获取资源：
//解决加载图片 内存溢出的问题
//Options 只保存图片尺寸大小，不保存图片到内存
BitmapFactory.Options opts = new BitmapFactory.Options();
//缩放的比例，缩放是很难按准备的比例进行缩放的，其值表明缩放的倍数，SDK中建议其值是2的指数值,值越大会导致图片不清晰
opts.inSampleSize = 2;
Bitmap bmp = null;
bmp = BitmapFactory.decodeResource(getResources(), mImageIds[position],opts);
...
//回收
bmp.recycle();
2）通过Uri取图片资源
private ImageView preview;
BitmapFactory.Options options = new BitmapFactory.Options();
options.inSampleSize = 2;//图片宽高都为原来的二分之一，即图片为原来的四分之一
Bitmap bitmap = BitmapFactory.decodeStream(cr.openInputStream(uri), null, options);
preview.setImageBitmap(bitmap);
以上代码可以优化内存溢出，但它只是改变图片大小，并不能彻底解决内存溢出。
3）通过路径获取图片资源
private ImageView preview;
private String fileName= "/sdcard/DCIM/Camera/2010-05-14 16.01.44.jpg";
BitmapFactory.Options options = new BitmapFactory.Options();
options.inSampleSize = 2;//图片宽高都为原来的二分之一，即图片为原来的四分之一
Bitmap b = BitmapFactory.decodeFile(fileName, options);
preview.setImageBitmap(b);
filePath.setText(fileName);
方法2：对图片采用软引用，及时地进行recyle()操作
SoftReference<Bitmap> bitmap;
bitmap = new SoftReference<Bitmap>(pBitmap);
if(bitmap != null){
if(bitmap.get() != null && !bitmap.get().isRecycled()){
bitmap.get().recycle();
bitmap = null;
}
}
1、为何使用软引用：
由于创建的集合中存的都是强引用的对象，对于强引用的对象，垃圾回收器是绝对不会回收这个强引用的对象的，除非手动将对象置为null，垃圾回收器才会在适当的时候将其回收掉。当内存不足的时候，即使抛出了OOM异常，程序终止了也不会回收这个强引用对象。所以为了避免在低内存下缓存图片而导致OOM异常的出现，需要降低对象的引用级别，这就涉及到了软引用。
简单来说，软引用就相当于一个“袋子”，而强引用就相当于袋子中的内容，可以比喻为将手机(内容)存入到袋子中，即用软引用包裹强引用。软引用SoftReference的特点就在于它的实例保存了对一个java对象的软引用，该软引用的存在并不妨碍垃圾回收线程对该java对象的回收。SoftReference保存了对一个java对象的软引用后，在垃圾回收此java对象之前，SoftReference所提供的的get()方法返回的是java对象的强引用；一旦垃圾线程回收该java对象之后，get()返回的是null。
2、软引用的特点：
1）、在内存空间充足时，即使一个对象具有软引用，垃圾回收器也不会回收它。
2）、当内存不足时，会在出现OOM异常之前回收掉这些对象的内存空间。
3）、只要垃圾回收器没回收这个对象，则程序就可以继续使用这个对象，因此软引用可用来实现内存敏感的高速缓存。
4）、软引用和引用队列ReferenceQueue联合使用时，当软引用所引用的对象被垃圾回收器回收后，java虚拟机就会将这个软引用加入到与之关联的引用队列中。
需要说明的是，对于强引用对象（如new一个对象），如果被软引用所引用后，不为null时是作为强可及对象存在的，如果为null后，是作为软可及对象存在的；当垃圾回收的时候，不会因为这个对象被软引用所引用而保留该对象的。而是会在OOM异常之前优先回收掉长时间闲置的软可及对象，尽可能保留“新”的软可及对象。如果想重新获得对该实例的强引用，可以通过调用软引用的get()方法获得对象后继续使用。
3、引用队列ReferenceQueue：
虽然SoftReference对象具有保存软引用的特性，但是也还是具有java对象的一般性的。也就是说当软引用所引用的对象被回收之后，这个软引用的对象实际上并没有什么存在的价值了，这就需要一个适当的清除机制，避免由于大量的SoftReference对象的存在而带来新的内存泄露的问题。这就需要将这些“空袋子”回收掉，这就需要使用引用队列ReferenceQueue这个类。
使用方法：就是将创建的强引用和引用队列作为参数传递到软引用的构造方法中，从而实现在SoftReference所引用的object在被垃圾回收器回收的同时，这个软引用对象会被加入到引用队列ReferenceQueue之中。我们可以通过ReferenceQueue的poll()方法监控到是否有非强可及对象被回收了。当队列为空时，说明没有软引用加入到队列中，即没有非强可及引用被回收，否则poll()方法会返回队列中前面一个Reference对象。通过这个方法，我们就可以将无引用对象的软引用SoftReference回收掉，这就避免了大量SoftReference未被回收导致的内存泄露。
4、构建高级缓存：
在应用之中，当我们将图片加载到内存中，需要考虑内存的优化问题，同样会涉及到OOM的问题。如果图片过多的话，内存就吃不消了，这就需要考虑应用如何在低内存的情况下运行了，需要为应用构建高级缓存，来保证在低内存的情况下也能正常运行。首先，在缓存图片的时候，需要判断手机的当前可用内存是否充足，如果内存不足，就需要使用缓存的Map来存储，保证在高速缓存下运行。但是在java中并没有提供软引用的Map集合，只提供了一个WeakHashMap这个针对弱引用提供的实现类。这时候就需要我们手动创建一个具体的实现类，作为软引用的集合来使用。
1、自定义软引用集合，继承HashMap<K, V>，这就相当于一个“袋子”
2、在构造函数中初始化：
临时集合：创建一个临时的HashMap，其中的V应当作为软引用存在，即使用自定义的软引用的类[此类是加入队列的软引用]。可以理解为将手机（强引用）放入袋子（软引用）中，在将袋子贴上一个标签，放入队列中存储。
引用队列：创建存放软引用的队列ReferenceQueue。
3、重写用到集合的方法：put、get、以及containsKey等用到的方法（即在实际使用中用到了哪些方法），在put方法中，需要先创建一个软引用对象，接收传入的value，即包裹强引用对象；将这个软引用加入到临时的集合中，这样就可以操作软引用的集合了。同样的get方法也是从这个临时存储软引用的集合中取值。
4、回收“空袋子”。当强引用对象被回收后，软引用也需要被回收掉：通过调用引用队列中的poll方法，不断的循环，检测队列是否为空，即检测队列中是否有“空袋子”软引用，如果有则从临时的集合中移除掉。在get和containKey方法中调用此回收方法。】
« 掌握OOM异常的处理，并可以对应用进行相应的优化
一、内存溢出如何产生的
Android的虚拟机是基于寄存器的Dalvik，它的最大堆大小一般是16M，有的机器为24M。因此我们所能利用的内存空间是有限的。如果我们的内存占用超过了一定的水平就会出现OutOfMemory的错误。
内存溢出的几点原因总结：
1、资源释放问题：
程序代码的问题，长期保持某些资源（如Context）的引用，造成内存泄露，资源得不到释放
2、对象内存过大问题：
保存了多个耗用内存过大的对象（如Bitmap），造成内存超出限制
3、static：
static是Java中的一个关键字，当用它来修饰成员变量时，那么该变量就属于该类，而不是该类的实例。所以用static修饰的变量，它的生命周期是很长的，如果用它来引用一些资源耗费过多的实例（Context的情况最多），这时就要谨慎对待了。
public class ClassName {
private static Context mContext;
//省略
}
以上的代码是很危险的，如果将Activity赋值到mContext的话。那么即使该Activity已经onDestroy，但是由于仍有对象保存它的引用，因此该Activity依然不会被释放。
我们举Android文档中的一个例子。
private static Drawable sBackground;
@Override
protected void onCreate(Bundle state) {
super.onCreate(state);
TextView label = new TextView(this);
label.setText("Leaks are bad");
if (sBackground == null) {
sBackground = getDrawable(R.drawable.large_bitmap);
}
label.setBackgroundDrawable(sBackground);
setContentView(label);
}
sBackground, 是 一个静态的变量，但是我们发现，我们并没有显式的保存Contex的引用，但是，当Drawable与View连接之后，Drawable就将View设 置为一个回调，由于View中是包含Context的引用的，所以，实际上我们依然保存了Context的引用。这个引用链如下：
Drawable->TextView->Context
所以，最终该Context也没有得到释放，发生了内存泄露。
针对static的解决方案：
第一、应该尽量避免static成员变量引用资源耗费过多的实例，比如Context。
第二、Context尽量使用Application Context，因为Application的Context的生命周期比较长，引用它不会出现内存泄露的问题。
第三、使用WeakReference代替强引用。比如可以使用WeakReference<Context> mContextRef;
该部分的详细内容也可以参考Android文档中Article部分。
4、线程导致内存溢出：
线程产生内存泄露的主要原因在于线程生命周期的不可控。我们来考虑下面一段代码。
public class MyActivity extends Activity {
@Override
public void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.main);
new MyThread().start();
}
private class MyThread extends Thread{
@Override
public void run() {
super.run();
//do somthing
}
}
}
这段代码很平常也很简单，是我们经常使用的形式。我们思考一个问题：假设MyThread的run函数是一个很费时的操作，当我们开启该线程后，将设备的横屏变为了竖屏，一 般情况下当屏幕转换时会重新创建Activity，按照我们的想法，老的Activity应该会被销毁才对，然而事实上并非如此。
由于我们的线程是Activity的内部类，所以MyThread中保存了Activity的一个引用，当MyThread的run函数没有结束时，MyThread是不会被销毁的，因此它所引用的老的Activity也不会被销毁，因此就出现了内存泄露的问题。
有些人喜欢用Android提供的AsyncTask，但事实上AsyncTask的问题更加严重，Thread只有在run函数不结束时才出现这种内存泄露问题，然而AsyncTask内部的实现机制是运用了ThreadPoolExcutor,该类产生的Thread对象的生命周期是不确定的，是应用程序无法控制的，因此如果AsyncTask作为Activity的内部类，就更容易出现内存泄露的问题。
针对这种线程导致的内存泄露问题的解决方案：
第一、将线程的内部类，改为静态内部类。
第二、在线程内部采用弱引用保存Context引用。
二、避免内存溢出的方案：
1、图片过大导致内存溢出：
模拟器的RAM比较小，由于每张图片先前是压缩的情况，放入到Bitmap的时候，大小会变大，导致超出RAM内存
★android 中用bitmap 时很容易内存溢出，报如下错误：Java.lang.OutOfMemoryError : bitmap size exceeds VM budget
解决：
方法1： 主要是加上这段：等比例缩小图片
BitmapFactory.Options options = new BitmapFactory.Options();
options.inSampleSize = 2;
1）通过getResource()方法获取资源：
//解决加载图片 内存溢出的问题
//Options 只保存图片尺寸大小，不保存图片到内存
BitmapFactory.Options opts = new BitmapFactory.Options();
//缩放的比例，缩放是很难按准备的比例进行缩放的，其值表明缩放的倍数，SDK中建议其值是2的指数值,值越大会导致图片不清晰
opts.inSampleSize = 2;
Bitmap bmp = null;
bmp = BitmapFactory.decodeResource(getResources(), mImageIds[position],opts);
...
//回收
bmp.recycle();
2）通过Uri取图片资源
private ImageView preview;
BitmapFactory.Options options = new BitmapFactory.Options();
options.inSampleSize = 2;//图片宽高都为原来的二分之一，即图片为原来的四分之一
Bitmap bitmap = BitmapFactory.decodeStream(cr.openInputStream(uri), null, options);
preview.setImageBitmap(bitmap);
以上代码可以优化内存溢出，但它只是改变图片大小，并不能彻底解决内存溢出。
3）通过路径获取图片资源
private ImageView preview;
private String fileName= "/sdcard/DCIM/Camera/2010-05-14 16.01.44.jpg";
BitmapFactory.Options options = new BitmapFactory.Options();
options.inSampleSize = 2;//图片宽高都为原来的二分之一，即图片为原来的四分之一
Bitmap b = BitmapFactory.decodeFile(fileName, options);
preview.setImageBitmap(b);
filePath.setText(fileName);
方法2：对图片采用软引用，及时地进行recyle()操作
SoftReference<Bitmap> bitmap;
bitmap = new SoftReference<Bitmap>(pBitmap);
if(bitmap != null){
if(bitmap.get() != null && !bitmap.get().isRecycled()){
bitmap.get().recycle();
bitmap = null;
}
}
具体见“各种引用的简单了解”中的示例
2、复用listView：
方法：对复杂的listview进行合理设计与编码：
Adapter中：
@Override
public View getView(int position, View convertView, ViewGroup parent) {
ViewHolder holder;
if(convertView!=null && convertView instanceof LinearLayout){
holder = (ViewHolder) convertView.getTag();
}else{
convertView = View.inflate(MainActivity.this, R.layout.item, null);
holder = new ViewHolder();
holder.tv = (TextView) convertView.findViewById(R.id.tv);
convertView.setTag(holder);
}
holder.tv.setText("XXXX");
holder.tv.setTextColor(Color.argb(180, position*4, position*5, 255-position*2));
return convertView;
}
class ViewHolder{
private TextView tv;
}
3、界面切换
方法1：单个页面，横竖屏切换N次后 OOM
1、看看页面布局当中有没有大的图片，比如背景图之类的。
去除xml中相关设置，改在程序中设置背景图（放在onCreate()方法中）：
Drawable bg = getResources().getDrawable(R.drawable.bg);
XXX.setBackgroundDrawable(rlAdDetailone_bg);
在Activity destory时注意，bg.setCallback(null); 防止Activity得不到及时的释放
2. 跟上面方法相似，直接把xml配置文件加载成view 再放到一个容器里
然后直接调用 this.setContentView(View view);方法，避免xml的重复加载
方法2： 在页面切换时尽可能少地重复使用一些代码
比如：重复调用数据库，反复使用某些对象等等......
4、内存分配：
方法1：Android堆内存也可自己定义大小和优化Dalvik虚拟机的堆内存分配
注意若使用这种方法：project build target 只能选择 <= 2.2 版本，否则编译将通不过。 所以不建议用这种方式
private final static int CWJ_HEAP_SIZE= 6*1024*1024;
private final static float TARGET_HEAP_UTILIZATION = 0.75f;
VMRuntime.getRuntime().setMinimumHeapSize(CWJ_HEAP_SIZE);
VMRuntime.getRuntime().setTargetHeapUtilization(TARGET_HEAP_UTILIZATION);
常见的内存使用不当的情况
1、查询数据库没有关闭游标
程序中经常会进行查询数据库的操作，但是经常会有使用完毕Cursor后没有关闭的情况。如果我们的查询结果集比较小，对内存的消耗不容易被发现，只有在常时间大量操作的情况下才会复现内存问题，这样就会给以后的测试和问题排查带来困难和风险。
Cursor cursor = null;
try {
cursor = getContentResolver().query(uri ...);
if (cursor != null && cursor.moveToNext()) {
... ...
}
} finally {
if (cursor != null) {
try {
cursor.close();
} catch (Exception e) {
//ignore this
}
}
}
2、构造Adapter时，没有使用缓存的 convertView
以构造ListView的BaseAdapter为例，在BaseAdapter中提供了方法：
public View getView(int position, View convertView, ViewGroup parent)
来向ListView提供每一个item所需要的view对象。初始时ListView会从BaseAdapter中根据当前的屏幕布局实例化一定数量的 view对象，同时ListView会将这些view对象缓存起来。当向上滚动ListView时，原先位于最上面的list item的view对象会被回收，然后被用来构造新出现的最下面的list item。这个构造过程就是由getView()方法完成的，getView()的第二个形参 View convertView就是被缓存起来的list item的view对象(初始化时缓存中没有view对象则convertView是null)。
由此可以看出，如果我们不去使用convertView，而是每次都在getView()中重新实例化一个View对象的话，即浪费资源也浪费时间，也会使得内存占用越来越大。ListView回收list item的view对象的过程可以查看：
public View getView(int position, View convertView, ViewGroup parent) {
View view = null;
if (convertView != null) {
view = convertView;
populate(view, getItem(position));
...
} else {
view = new Xxx(...);
...
}
return view;
}
3、Bitmap对象不在使用时调用recycle()释放内存
有时我们会手工的操作Bitmap对象，如果一个Bitmap对象比较占内存，当它不在被使用的时候，可以调用Bitmap.recycle()方法回收此对象的像素所占用的内存，但这不是必须的，视情况而定。可以看一下代码中的注释：
4、释放对象的引用
当一个生命周期较短的对象A，被一个生命周期较长的对象B保有其引用的情况下，在A的生命周期结束时，要在B中清除掉对A的引用。
示例A：
public class DemoActivity extends Activity {
... ...
private Handler mHandler = ...
private Object obj;
public void operation() {
obj = initObj();
...
[Mark]
mHandler.post(new Runnable() {
public void run() {
useObj(obj);
}
});
}
}
我们有一个成员变量 obj，在operation()中我们希望能够将处理obj实例的操作post到某个线程的MessageQueue中。在以上的代码中，即便是 mHandler所在的线程使用完了obj所引用的对象，但这个对象仍然不会被垃圾回收掉，因为DemoActivity.obj还保有这个对象的引用。 所以如果在DemoActivity中不再使用这个对象了，可以在[Mark]的位置释放对象的引用，而代码可以修改为：
... ...
public void operation() {
obj = initObj();
...
final Object o = obj;
obj = null;
mHandler.post(new Runnable() {
public void run() {
useObj(o);
}
}
}
... ...
示例B:
假设我们希望在锁屏界面(LockScreen)中，监听系统中的电话服务以获取一些信息(如信号强度等)，则可以在LockScreen中定义一个 PhoneStateListener的对象，同时将它注册到TelephonyManager服务中。对于LockScreen对象，当需要显示锁屏界 面的时候就会创建一个LockScreen对象，而当锁屏界面消失的时候LockScreen对象就会被释放掉。
但是如果在释放LockScreen对象的时候忘记取消我们之前注册的PhoneStateListener对象，则会导致LockScreen无法被垃 圾回收。如果不断的使锁屏界面显示和消失，则最终会由于大量的LockScreen对象没有办法被回收而引起OutOfMemory,使得 system_process进程挂掉。
5、其他
Android应用程序中最典型的需要注意释放资源的情况是在Activity的生命周期中，在onPause()、onStop()、 onDestroy()方法中需要适当的释放资源的情况。由于此情况很基础，在此不详细说明，具体可以查看官方文档对Activity生命周期的介绍，以 明确何时应该释放哪些资源。
