解决Picasso占用内存,使用Picasso在加载超过2M左右的图片时完全不能显示图片问题（不同的手机可能不同）

前言：
在众多网络加载图片框架中，UniversalImageLoader，Glide，Fresco等框架，比较了前景（Glide支持动态图，Fresco功能非常强大），内存管理，是否轻量级（fresco虽然强大，但是依赖太多了，方法数有5000多个），最终选择使用Glide。

不得不承认，glide和picasso用法上很像，glide加载图片比较流畅，自带渐变效果，生命周期管理上非常不错，但是也存在一些比较奇葩的问题在GridView或者ListView的Adapter中使用Glide加载图片，图片被拉伸问题,另外还有另一个我百思不得其解的问题，当我跳转其他的Activity，回来的时候，内存使用只升不降（偶尔会降一点点），当图片过多，列表页面滑动太快的时候也存在oom（OutOfMemoryException）的风险，总体来说Glide也是非常优秀的

既然Picasso那么占用内存，为什么我决定重新使用它？

Picasso相对Glide，方法数不足Glide的1/3（Picasso 2.5.2版本 849个方法，Glide 3.7.0版本有2879个方法，遇到过64k的同学会关注这个），Picasso不能加载动态图（通过第三方也可以实现），如果能解决Picasso的内存问题，使用Picasso相对Glide更轻量级些，当然会选择Picasso

如何解决Picasso占用内存问题？

在之前的测试中，Picasso加载小图片的内存占用和其他几个图片加载框架相比是不分上下的，但是在加载大图Picasso相对于其他几个框架却有着几倍的差距，在加载超过2M左右的图片就可能完全不能显示图片的情况（不同的手机可能不同），是不是只要减少图片的size就可以控制内存的占用率了

Picasso.with( context )
.load(url)
.resize(screenWidth/2，screenWidth/4*3)
.centerCrop()
.into(imageView);

果然，加上resize这个属性加载大图毫无压力，内存也非常平稳，甚至在图片非常多的时候，Picasso的内存占用率比Glide都要小得多。

### 图片裁剪###

在列表页尽量使用裁剪后的图片，在查看大图模式下才加载完整的图片。
图片裁剪示例

Picasso.with( imageView.getContext() )
.load(url)
.resize(dp2px(250),dp2px(250))
.centerCrop()
.into(imageView);

picasso默认情况下会使用全局的ApplicationContext，即开发者传进去Activity，picasso也会通过activity获取ApplicationContext。

* 查看大图放弃memory cache

Picasso默认会使用设备的15%的内存作为内存图片缓存，且现有的api无法清空内存缓存。我们可以在查看大图时放弃使用内存缓存，图片从网络下载完成后会缓存到磁盘中，加载会从磁盘中加载，这样可以加速内存的回收。

Picasso.with(getApplication())
.load(mURL)
.memoryPolicy(NO_CACHE, NO_STORE)
.into(imageView);

其中memoryPolicy的NO_CACHE是指图片加载时放弃在内存缓存中查找，NO_STORE是指图片加载完不缓存在内存中。

* RecyclableImageView

重写ImageView的onDetachedFromWindow方法，在它从屏幕中消失时回调，去掉drawable引用，能加快内存的回收。

public class RecyclerImageView extends ImageView
{
...

@Override
protected void onDetachedFromWindow() {
super.onDetachedFromWindow();
setImageDrawable(null);
}
}