一、高效加载大图片
我们在编写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类型，从而根据情况对图片进行压缩。如下代码所示：
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值：
1. public static int calculateInSampleSize(BitmapFactory.Options options,
2. int reqWidth, int reqHeight) {
3. // 源图片的高度和宽度
4. final int height = options.outHeight;
5. final int width = options.outWidth;
6. int inSampleSize = 1;
7. if (height > reqHeight || width > reqWidth) {
8. // 计算出实际宽高和目标宽高的比率
9. 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，就可以得到压缩后的图片了。
public static Bitmap decodeSampledBitmapFromResource(Resources res, int resId,
2. int reqWidth, int reqHeight) {
3. // 第一次解析将inJustDecodeBounds设置为true，来获取图片大小
4. final BitmapFactory.Options options = new BitmapFactory.Options();
5. options.inJustDecodeBounds = true;
6. BitmapFactory.decodeResource(res, resId, options);
7. // 调用上面定义的方法计算inSampleSize值
8. options.inSampleSize = calculateInSampleSize(options, reqWidth, reqHeight);
9. // 使用获取到的inSampleSize值再次解析图片
10. options.inJustDecodeBounds = false;
11. return BitmapFactory.decodeResource(res, resId, options);
12.} 下面的代码非常简单地将任意一张图片压缩成100*100的缩略图，并在ImageView上展示。
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来缓存图片的例子：
1. private LruCache<String, Bitmap> mMemoryCache;
2.
3. @Override
4. protected void onCreate(Bundle savedInstanceState) {
5. // 获取到可用内存的最大值，使用内存超出这个值会引起OutOfMemory异常。
6. // LruCache通过构造函数传入缓存值，以KB为单位。
7. int maxMemory = (int) (Runtime.getRuntime().maxMemory() / 1024);
8. // 使用最大可用内存值的1/8作为缓存的大小。
9. 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，否则开启一个后台线程来加载这张图片。
1. public void loadBitmap(int resId, ImageView imageView) {
2. final String imageKey = String.valueOf(resId);
3. final Bitmap bitmap = getBitmapFromMemCache(imageKey);
4. if (bitmap != null) {
5. imageView.setImageBitmap(bitmap);
6. } else {
7. imageView.setImageResource(R.drawable.image_placeholder);
8. BitmapWorkerTask task = new BitmapWorkerTask(imageView);
9. task.execute(resId);
10. }
11.}
BitmapWorkerTask 还要把新加载的图片的键值对放到缓存中。
1. class BitmapWorkerTask extends AsyncTask<Integer, Void, Bitmap> {
2. // 在后台加载图片。
3. @Override
4. protected Bitmap doInBackground(Integer... params) {
5. final Bitmap bitmap = decodeSampledBitmapFromResource(
6. getResources(), params[0], 100, 100);
7. addBitmapToMemoryCache(String.valueOf(params[0]), bitmap);
8. return bitmap;
9. }
10.} 掌握了以上两种方法，不管是要在程序中加载超大图片，还是要加载大量图片，都不用担心OOM的问题了!不过仅仅是理论地介绍不知道大家能不能完全理解，在后面的文章中我会演示如何在实际程序中灵活运用上述技巧来避免程序OOM
三、Android照片墙的实现：
照片墙这种功能现在应该算是挺常见了，在很多应用中你都可以经常看到照片墙的身影。它的设计思路其实也非常简单，用一个GridView控件当作“墙”，然后随着GridView的滚动将一张张照片贴在“墙”上，这些照片可以是手机本地中存储的，也可以是从网上下载的。制作类似于这种的功能的应用，有一个非常重要的问题需要考虑，就是图片资源何时应该释放。因为随着GridView的滚动，加载的图片可能会越来越多，如果没有一种合理的机制对图片进行释放，那么当图片达到一定上限时，程序就必然会崩溃。
今天我们照片墙应用的实现，重点也是放在了如何防止由于图片过多导致程序崩溃上面。主要的核心算法使用了Android中提供的LruCache类，这个类是3.1版本中提供的，如果你是在更早的Android版本中开发，则需要导入android-support-v4的jar包。
第一个要考虑的问题就是，我们从哪儿去收集这么多的图片呢？这里我从谷歌官方提供的Demo里将图片源取了出来，我们就从这些网址中下载图片，代码如下所示：
新建或打开activity_main.xml作为程序的主布局，加入如下代码：
1. <LinearLayout xmlns:android="http://schemas.android.com/apk/res/android"
2. xmlns:tools="http://schemas.android.com/tools"
3. android:layout_width="wrap_content"
4. android:layout_height="wrap_content" >
5.
6. <GridView
7. android:id="@+id/photo_wall"
8. android:layout_width="match_parent"
9. 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布局，加入如下代码：
1. <RelativeLayout xmlns:android="http://schemas.android.com/apk/res/android"
2. xmlns:tools="http://schemas.android.com/tools"
3. android:layout_width="wrap_content"
4. android:layout_height="wrap_content" >
5.
6. <ImageView
7. android:id="@+id/photo"
8. android:layout_width="90dip"
9. android:layout_height="90dip"
10. android:src="@drawable/empty_photo"
11. android:layout_centerInParent="true"
12. />
13.
14.</RelativeLayout> 在每一个子View中我们就简单使用了一个ImageView来显示一张图片。这样所有的布局就已经定义好了。
接下来新建PhotoWallAdapter做为GridView的适配器，代码如下所示：
1. public class PhotoWallAdapter extends ArrayAdapter<String> implements OnScrollListener {
2.
3. /**
4. * 记录所有正在下载或等待下载的任务。
5. */
6. private Set<BitmapWorkerTask> taskCollection;
7.
8. /**
9. * 图片缓存技术的核心类，用于缓存所有下载好的图片，在程序内存达到设定值时会将最少最近使用的图片移除掉。
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，代码如下所示：
1. public class MainActivity extends Activity {
2.
3. /**
4. * 用于展示照片墙的GridView
5. */
6. private GridView mPhotoWall;
7.
8. /**
9. * 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.
}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 = newBitmapFactory.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-1416.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方法中调用此回收方法。】
扫一扫
942
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
