1. 又拍云的图片尺寸问题
又拍云会对我们上传的图片进行处理。然后会生成多种尺寸：110,160,210,240,320,480,640,720,1200。
每种尺寸对应于不同的url。
eg：
http://img2048.static.suishenyun.net/d62bb1e1bf1e2c6b8fb0dd004a952a01/4414fc28822e3643ff90a7e68305e12a.jpg!w480.jpg
2. 简单的解决方案
为了利用又拍云自动帮我们处理出来的不同尺寸图片。在每次加载图片的时候根据当前显示View的尺寸加载合适的尺寸
2.1 这里有三个没解决的问题：
不同尺寸的图片会在sd卡上存不同cache，比如由于我们先加载了640尺寸的图片，后面加载480尺寸还是无法公用640尺寸的图片cache,导致还得重新请求一次网络。实际上我们可以通过处理得到480尺寸的图片。
对于发带图片帖子的这种逻辑处理逻辑处理不方便。因为上传图片后，很有可能不知道图片的显示尺寸。无法把这张本地图片放置到对应位置的cache上去（虽然我们现在上传上去后，会直接显示的是本地图片，但这个有点治标不治本。第二次进来时候或者下拉刷新后 还是会从网上load这张图片）。
图片尺寸的获取，不是所有的ImageView在setImageUrl时候都可以获取尺寸，有的量不到尺寸，也就是在一个还没有渲染 并且也没有设置固定size的ImageVIew上设置Url（比Adapter里面的初次createView 然后立即设置Url就会出现量不到尺寸的问题）
总结一些：又拍云会帮我们处理出来不同尺寸的图片。在小的地方我们可以仅仅加载小尺寸的图片，提高了展示速度。但是对于同一张图片，在不同地方展示不同尺寸的逻辑处理不够完美。所以以前在wecal里面会发现一个问题：同一个头像，已经展示过了，在下一个页面里用另个尺寸展示的时候还是会有点慢。
3. 对于又拍云的图片完美解决方案
核心需要在内存和sd卡缓存逻辑能够识别出不同尺寸的不同图片。也就是要每一url对应于一组cache。
代码实现上就是要把当前的url的cache对应到一组cache 上去。
3.1 Memery cache逻辑
对于内存cache 建议还是按照以前的逻辑走，但是可以加上对于一个尺寸的的图片可以使用相近已经缓存尺寸的图片。
3.2 Disk cache逻辑
对于Disk cache 。如果需要加载一个小尺寸的图片，但是发现只有大尺寸图片，我们可以直接使用大图压缩出小图，返回过去。
3.3 2G网络模式
在低速网络情况下，对于disk cache，如果发现没有当前尺寸的图片的情况下，可以使用任意尺寸的缓存转化。
5. 推荐一个图片压缩库
Luban：https://github.com/Curzibn/Luban 大小仅仅是15K
根据我的测试一般可以在不明显影响图片展示效果的条件减少图片体积2/3。使用它后发图片备注速度飞快。（在wecal里面默认发送压缩后的图片，也提供发送原图的可选项）
相关推荐
Glide的ModuleLoader：https://github.com/bumptech/glide/wiki/Downloading-custom-sizes-with-Glide
Android图片缓存之Glide进阶： http://www.cnblogs.com/whoislcj/p/5565012.html
ModelLoader: https://muyangmin.github.io/glide-docs-cn/tut/custom-modelloader.html#%E5%9C%A8-modelloader-%E4%B8%AD%E5%A4%84%E7%90%86%E8%87%AA%E5%AE%9A%E4%B9%89%E5%B0%BA%E5%AF%B8