简介：
Glide最简单的使用案例就是从远程服务器或者本地文件系统加载图片，把它们放在磁盘与内存缓存中，然后加载到view上。它可以用在全是图片的app中，Glide为包含图片的滚动列表做了尽可能流畅的优化。
对象池
Glide原理的核心是为bitmap维护一个对象池。对象池的主要目的是通过减少大对象的分配以重用来提高性能（至于对象池的概览，可以查看这个Android performance pattern视频）。
Dalvik和ART虚拟机都没有使用compacting garbage collector，compacting garbage collector是一种模式，这种模式中GC会遍历堆，同时把活跃对象移到相邻内存区域，让更大的内存块可以用在后续的分配中。因为安卓没有这种模式，就可能会出现被分配的对象分散在各处，对象之间只有很小的内存可用。如果应用试图分配一个大于邻近的闲置内存块空间的对象，就会导致OutOfMemoryError，然后崩溃，即使总的空余内存空间大于对象的大小。
使用对象池还可以帮助提高滚动的性能，因为重用bitmap意味着更少的对象被创建与回收。垃圾回收会导致“停止一切(Stop The World)”事件，这个事件指的是回收器执行期间，所有线程（包括UI线程）都会暂停。这个时候，图像帧无法被渲染同时UI可能会停滞，这在滚动期间尤其明显。
主要特点：
(1)支持Memory和Disk图片缓存。
(2)支持gif和webp格式图片。
(3)根据Activity/Fragment生命周期自动管理请求。
(4)使用BitmapPool可以使Bitmap复用。
(5)对于回收的Bitmap会主动调用recycle，减小系统回收压力。
导入库
在项目中添加依赖非常简单：
Gradle:
//Picasso：
dependencies {compile 'com.squareup.picasso:picasso:2.5.1' }
//Glide：
dependencies {
compile 'com.github.bumptech.glide:glide:3.5.2'
compile 'com.android.support:support-v4:22.0.0'
}
OrMaven:
<dependency>
<groupId>com.github.bumptech.glide</groupId>
<artifactId>glide</artifactId>
<version>3.7.0</version>
</dependency>
<dependency>
<groupId>com.google.android</groupId>
<artifactId>support-v4</artifactId>
<version>r7</version>
</dependency>Glide需要 AndroidSupport Library v4 包
使用方法：
Picasso
.with(context) .load("http://inthecheesefactory.com/uploads/source/glidepicasso/cover.jpg")
.into(ivImg);
Glide
.with(context) .load("http://inthecheesefactory.com/uploads/source/glidepicasso/cover.jpg")
.into(ivImg);
Activity/Fragment作为with()参数的好处是：
图片加载会和Activity/Fragment的生命周期保持一致，比如Paused状态在暂停加载，在Resumed的时候又自动重新加载。建议传参的时候传递Activity和Fragment给Glide，而不是Context。
这就是加载一张图片的全部要求。就像安卓中的很多地方一样，with()方法中的context到底是哪种类型是不清楚的。有一点很重要需要记住，就是传入的context类型影响到Glide加载图片的优化程度，Glide可以监视activity的生命周期，在activity销毁的时候自动取消等待中的请求。但是如果你使用Application context，你就失去了这种优化效果。
优化特性
类似的是，如果相关的item已经滚出了屏幕的范围，Glide会自动取消列表中的悬着的图片请求。因为绝大多数开发者都会在adapter中利用view的回收，Glide做到这点是通过在ImageView上设置一个tag，在加载另外一张图片之前检查这个tag，如果存在就取消第一次请求。
Glide提供了几个让你感觉图片加载速度变快的特性。第一个就是在图片显示在屏幕上之前就预先取出图片。它提供了一个ListPreloader类，它被应该事先取出的item数目实例化。然后通过setOnScrollListener(OnScrollListener).被传递给ListView。你想在ListView之外也能预先取出图片吗？没问题，使用前面的builder对象就可以了，只需调用builder.downloadOnly()。
downloadOnly见：https://github.com/bumptech/glide/wiki/Loading-and-Caching-on-Background-Threads。
我们发现了Glide提供的可以大大提高性能，稳定性的功能，以及安卓图片加载领域的一些设计哲学。这些特性和优化确实可以很好的将图片加载的体验变成一种享受。
默认Bitmap格式是RGB_565
1920x1080像素的图片加载到768x432的ImageView中效果：
（ARGB一种色彩模式，也就是RGB色彩模式附加上Alpha（透明度）通道，常见于32位位图的存储结构。
内存开销要小一半
实际需求对图片的质量有更高要求时，可以创建一个GlideModule子类，把Bitmap的格式转换到ARGB_8888：
public class GlideConfiguration implements GlideModule {
@Override
public void applyOptions(Context context, GlideBuilder builder) {
// Apply options to the builder here.
builder.setDecodeFormat(DecodeFormat.PREFER_ARGB_8888);
}
@Override
public void registerComponents(Context context, Glide glide) {
// register ModelLoaders here.
}
}<meta-data android:name="com.inthecheesefactory.lab.glidepicasso.GlideConfiguration"
android:value="GlideModule"/>
看看内存开销图，虽然看起来这次 Glide 的内存开销接近于上次的两倍，但是Picasso的内存开销仍然远大于Glide。
磁盘缓存
Picasso和Glide在磁盘缓存策略上有很大的不同。加载同一张高清图片，检查缓存目录时发现：Glide缓存的图片和ImageView的尺寸相同，而Picasso缓存的图片和原始图片的尺寸相同。
Glide则不同，它会为每种大小的ImageView缓存一次。尽管一张图片已经缓存了一次，但假如要在另外一个地方再次以不同尺寸显示，需要重新下载，调整成新尺寸的大小，然后将这个尺寸的也缓存起来。
可以改变这种行为：既缓存全尺寸又缓存其他尺寸
Glide.with(this)
.load("http://nuuneoi.com/uploads/source/playstore/cover.jpg")
.diskCacheStrategy(DiskCacheStrategy.ALL)
.into(ivImgGlide);下次在任何ImageView中加载图片的时候，全尺寸的图片将从缓存中取出，重新调整大小，然后缓存。
Glide的这种方式优点是加载显示非常快。
在磁盘缓存策略上各有所长，应该根据自己的需求选择最合适的。
Glide快但需要更大的空间缓存。
常用特性：
.load()加载资源：1,drawable资源。2，本地File文件。3，uri。4，网络图片url
.placeholder()图片占位符，
.error()图片加载失败时显示
.crossFade()显示图片时执行淡入淡出的动画默认300ms
.dontAnimate()不执行显示图片时的动画
.override()设置图片的大小
.centerCrop()和fitCenter()图片的显示方式
.animate()view动画2个重构方法
.transform()bitmap转换
.bitmapTransform()bitmap转换。比如:旋转,方法,缩小,高斯模糊等等(转换后你就不能使用.centerCrop() .fitCenter() 了。)
.priority(Priority.HIGH)//当前线程的优先级
.thumbnail(0.1f)缩略图，3个重构方法：优先显示原始图片的百分比(10%)
.listener()异常监听
.into();将图片显示到控件，3个构造方法
源码解析
总体设计：
基本概念：
RequestManager：请求管理，每一个Activity都会创建一个RequestManager，根据对应Activity的生命周期管理该Activity上所以的图片请求。
Engine：加载图片的引擎，根据Request创建EngineJob和DecodeJob。
EngineJob：图片加载。
DecodeJob：图片处理
总体流程图：
核心类介绍
1.Gilde：用于保存整个框架中的配置
重要方法：
public static RequestManager with(FragmentActivity activity) {
RequestManagerRetriever retriever = RequestManagerRetriever.get();
return retriever.get(activity);
}
............................
主要原理是创建一个自定义Fragment，然后通过自定义Fragment生命周期操作RequestManager，从而达到管理Request。
2. RequestManagerRetriever
RequestManager supportFragmentGet(Context context, FragmentManager fm) {
SupportRequestManagerFragment current = getSupportRequestManagerFragment(fm);
RequestManager requestManager = current.getRequestManager();
if (requestManager == null) {
requestManager = new RequestManager(context, current.getLifecycle(), current.getRequestManagerTreeNode());
current.setRequestManager(requestManager);
}
return requestManager;
}这里判断是否只当前RequestManagerFragment是否存在RequestManager，保证一个Activity对应一个RequestManager， 这样有利于管理一个Activity上所有的Request。创建RequestManager的时候会将RequestManagerFragment中的回调接口赋值给RequestManager，达到RequestManager监听RequestManagerFragment的生命周期。
3 RequestManager
成员变量：
(1)Lifecycle lifecycle,用于监听RequestManagerFragment生命周期。
(2)RequestTracker requestTracker, 用于保存当前RequestManager所有的请求和带处理的请求。
重要方法：
@Override
//开始暂停的请求
public void onStart() {
resumeRequests();
}
//停止所有的请求
@Override
public void onStop() {
pauseRequests();
}
//关闭所以的请求
@Override
public void onDestroy() {
requestTracker.clearRequests();
}
//创建RequestBuild
public DrawableTypeRequest<String> load(String string) {
return (DrawableTypeRequest<String>) fromString().load(string);
}
public <Y extends Target<TranscodeType>> Y into(Y target) {
...
Request previous = target.getRequest();
//停止当前target中的Request。
if (previous != null) {
previous.clear(); //这个地方很关键，见Request解析
requestTracker.removeRequest(previous);
previous.recycle();
}
...
return target;
}4 .DrawableRequestBuilder
用于创建Request。 这里面包括很多方法，主要是配置加载图片的url、大小、动画、ImageView对象、自定义图片处理接口等。
5. Request
主要是操作请求，方法都很简单。
@Override
public void clear() {
...
if (resource != null) {
//这里会释放资源
releaseResource(resource);
}
...
}这里的基本原理是当有Target使用Resource（Resource见下文）时，Resource中的引用记数值会加一，当释放资源Resource中的引用记数值减一。当没有Target使用的时候就会释放资源，放进Lrucache中。
6.Engine
请求引擎，主要做请求的开始的初始化。
load方法
(1)获取MemoryCache中缓存 首先创建当前Request的缓存key，通过key值从MemoryCache中获取缓存，判断缓存是否存在。
private EngineResource<?> loadFromCache(Key key, boolean isMemoryCacheable) {
....
EngineResource<?> cached = getEngineResourceFromCache(key);
if (cached != null) {
cached.acquire();
activeResources.put(key, new ResourceWeakReference(key, cached, getReferenceQueue()));
}
return cached;
}
@SuppressWarnings("unchecked")
private EngineResource<?> getEngineResourceFromCache(Key key) {
Resource<?> cached = cache.remove(key);
final EngineResource result;
...
return result;
}优点：
> 正使用的Resource将会在activeResources中，不会出现在cache中，当MemoryCache中缓存饱和的时候或者系统内存不足的时候，清理Bitmap可以直接调用recycle,不用考虑Bitmap正在使用导致异常，加快系统的回收。
(2)获取activeResources中缓存
activeResources通过弱引用保存recouse ，也是通过key获取缓存。
private EngineResource<?> loadFromActiveResources(Key key, boolean isMemoryCacheable)
(3)判断当前的请求任务是否已经存在
EngineJob current = jobs.get(key);
if (current != null) {
current.addCallback(cb);
return new LoadStatus(cb, current);
}(4)执行请求任务
EngineJob engineJob = engineJobFactory.build(key, isMemoryCacheable);
DecodeJob<T, Z, R> decodeJob = new DecodeJob<T, Z, R>(key, width, height, fetcher, loadProvider, transformation,
transcoder, diskCacheProvider, diskCacheStrategy, priority);
EngineRunnable runnable = new EngineRunnable(engineJob, decodeJob, priority);
jobs.put(key, engineJob);
engineJob.addCallback(cb);
engineJob.start(runnable);7.EngineRunnable
请求执行Runnable，主要功能请求资源、处理资源、缓存资源。
private Resource<?> decodeFromCache() throws Exception {
Resource<?> result = null;
try {
result = decodeJob.decodeResultFromCache();
} catch (Exception e) {
if (Log.isLoggable(TAG, Log.DEBUG)) {
Log.d(TAG, "Exception decoding result from cache: " + e);
}
}
if (result == null) {
result = decodeJob.decodeSourceFromCache();
}
return result;
}
private Resource<?> decodeFromSource() throws Exception {
return decodeJob.decodeFromSource();
}加载DiskCache和网络资源。加载DiskCache包括两个，因为Glide默认是保存处理后的资源（压缩和裁剪后），缓存方式可以自定义配置。如果客户端规范设计，ImageView大小大部分相同可以节省图片加载时间和Disk资源。
8.DecodeJob
public Resource<Z> decodeResultFromCache() throws Exception
public Resource<Z> decodeSourceFromCache() throws Exception从缓存中获取处理后的资源。上面有关Key的内容，Key是一个对象，可以获取key和orginKey。decodeResultFromCache就是通过key获取缓存，decodeSourceFromCache()就是通过orginKey获取缓存。
private Resource<Z> transformEncodeAndTranscode(Resource<T> decoded)
处理和包装资源；缓存资源。
/保存原资源
private Resource<T> cacheAndDecodeSourceData(A data) throws IOException
//保存处理后的资源
private void writeTransformedToCache(Resource<T> transformed)9.Transformation
Resource<T> transform(Resource<T> resource, int outWidth, int outHeight);10.ResourceDecoder
用于将文件、IO流转化为Resource
11.BitmapPool
用于存放从LruCache中remove的Bitmap， 用于后面创建Bitmap时候的重复利用。
其他
Glide 是一个android平台上的快速和高效的开源的多媒体资源管理库,提供多媒体文件的压缩,内存和磁盘缓存,资源池的接口
Glide 支持获取,解压展示视频,图像和GIFs, Glide有一个可弹性的api可以让开发者自定义网络栈技术,默认使用HttpUrlConnection ,你可以替换为 Google’s Volley或者 OkHttp
Volley
如果你想使用Volley
Gradle
dependencies{
compile'com.github.bumptech.glide:volley-integration:1.0.+'
compile'com.mcxiaoke.volley:library:1.0.+'
}
然后在你的Activity或者程序中,注册Volley为基本模块
public void onCreate() {
Glide.get(this).register(GlideUrl.class, InputStream.class,
new VolleyUrlLoader.Factory(yourRequestQueue));
...
} OkHttp
Gradle:
dependencies{
compile'com.github.bumptech.glide:okhttp-integration:1.0.+'
compile'com.squareup.okhttp:okhttp:2.0.+'
} 然后在你的Activity或者程序中,注册OKHttp为基本模块
public void onCreate() {
Glide.get(this).register(GlideUrl.class, InputStream.class,
new OkHttpUrlLoader.Factory(yourOkHttpClient));
...
}
5608
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
