Android应用开发：ImageLoader小陷阱——同一个URI

引言

ImageLoader是一个被广泛使用的用于图片加载的开源项目，项目地址： https://github.com/nostra13/Android-Universal-Image-Loader

关于ImageLoader的使用，作者的README写的已经非常详细了，我在这里就不再赘述。

Android应用都是分别运行在各自的dalvik虚拟机中，而由于手机内存大小的局限性，Android系统在设计之初就对每个应用所运行的虚拟机能够使用的内存进行了严格的限制（现在Android正转向ART的运行环境中，即便是运行环境发生了改变，这样的内存限制规则还是存在的）。AOSP的现行标准是，以720P的手机来说，若手机自身带有1G内存，则每个应用可用内存限制在96MB。若有2G内存，则限制为192MB（Google解释说这个内存足够5张800万像素的位图了）。一旦某个应用总体使用的内存超过了所在手机的限制，将引发OOM(Out of Memory)错误，这个错误对于应用程序来说是致命的，能够直接导致程序崩溃。这正是ImageLoader产生的背景，Android官方的开发指导上边用很大的章节（http://developer.android.com/intl/zh-cn/training/displaying-bitmaps/index.html）介绍了在开发过程中如何妥善处理Bitmap的加载以防止OOM的发生，亦或是从程序优化角度讲也是有必要的。即使你仔细看完了Android官方对于Bitmap的那些指导性文档，我也强烈建议你使用ImageLoader或Volley进行图片加载，拥抱开源是最正确的选择。

所谓陷阱

所谓陷阱其实更应该描述为开发过程中容易发生的误会。ImageLoader在之前的版本中对相同的URI并没有进行过滤，也就是说，对同一个URI进行多次请求，也就能得到多次完成的监听事件。而这在网络请求中，有可能造成多余操作，所以其作者在听取了使用者建议后在后续版本的更新中对相同URI的请求进行了过滤，也就是说同一个URI的请求，如果只是简单的使用

ImageLoader.getInstance().loadImage(uri, size, listener)

进行图片加载的话，无论请求多少次，都只会收到一次listener监听事件。所以说，如果你的应用中在同一列表或界面中有可能出现同样URI的图片，那么在使用ImageLoader的时候就需要注意了，如果按照默认的用法，那么最终只会有一个位置能够正常显示图片，其他的会是默认状态。

解决问题

解决办法ImageLoader的作者曾在用户开辟的issue中阐述过，不过随着版本的变迁，产生了小小的变化（其实就是一个类名的Rename）。

NonViewAware aware = new NonViewAware(size, ViewScaleType.CROP);
ImageLoader.getInstance().displayImage(uri, aware, listener);

这样，即使对同一个URI进行多次请求，listener监听事件也不会被过滤，每一个请求都会获得相应的回应。