选项(Options)
Glide v4 中的一个比较大的改动是Glide库处理选项(centerCrop(), placeholder() 等)的方式。在 v3 版本中，选项由一系列复杂的异构建造者(multityped builders)单独处理。在新版本中，由一个单一类型的唯一一个建造者接管一系列选项对象。Glide 的generated API进一步简化了这个操作：它会合并传入建造者的选项对象和任何已包含的集成库里的选项，以生成一个流畅的 API。
RequestBuilder
对于这类方法：
listener()thumbnail()load()into()
在 Glide v4 版本中，只存在一个 RequestBuilder 对应一个你正在试图加载的类型(Bitmap, Drawable, GifDrawable 等)。 RequestBuilder 可以直接访问对这个加载过程有影响的选项，包括你想加载的数据模型（url, uri等），可能存在的缩略图请求，以及任何的监听器。RequestBuilder也是你使用 into()或者 preload() 方法开始加载的地方：
RequestBuilder<Drawable> requestBuilder = Glide.with(fragment) .load(url);requestBuilder .thumbnail(Glide.with(fragment) .load(thumbnailUrl)) .listener(requestListener) .load(url) .into(imageView);
请求选项
对于这类方法：
centerCrop()placeholder()error()priority()diskCacheStrategy()
大部分选项被移动到了一个单独的称为 RequestOptions 的对象中，
RequestOptions options = new RequestOptions() .centerCrop() .placeholder(R.drawable.placeholder) .error(R.drawable.error) .priority(Priority.HIGH);
RequestOptions 允许你一次指定一系列的选项，然后对多个加载重用它们：
RequestOptions myOptions = new RequestOptions() .fitCenter() .override(100, 100);Glide.with(fragment) .load(url) .apply(myOptions) .into(drawableView);Glide.with(fragment) .asBitmap() .apply(myOptions) .load(url) .into(bitmapView);
变换
Glide v4 里的 Transformations 现在会替换之前设置的任何变换。在 Glide v4 中，如果你想应用超过一个的 Transformation，你需要使用 transforms()方法：
Glide.with(fragment) .load(url) .apply(new RequestOptions().transforms(new CenterCrop(), new RoundedCorners(20))) .into(target);
或使用 generated API:
GlideApp.with(fragment) .load(url) .transforms(new CenterCrop(), new RoundedCorners(20)) .into(target);
解码格式
在 Glide v3， 默认的 DecodeFormat 是 DecodeFormat.PREFER_RGB_565，它将使用 [Bitmap.Config.RGB_565]，除非图片包含或可能包含透明像素。对于给定的图片尺寸，RGB_565 只使用 [Bitmap.Config.ARGB_8888] 一般的内存，但对于特定的图片有明显的画质问题，包括条纹(banding)和着色(tinting)。为了避免RGB_565的画质问题，Glide 现在默认使用 ARGB_8888。结果是，图片质量变高了，但内存使用也增加了。
要将 Glide v4 默认的 DecodeFormat 改回 DecodeFormat.PREFER_RGB_565，请在 AppGlideModule 中应用一个 RequestOption：
@GlideModulepublic final class YourAppGlideModule extends GlideModule {
@Override
public void applyOptions(Context context, GlideBuilder builder) {
builder.setDefaultRequestOptions(new RequestOptions().format(DecodeFormat.PREFER_RGB_565));
}}关于使用 AppGlideModules 的更多信息，请查阅 配置 页面。请注意，为了让 Glide 发现你的 AppGlideModule 实现，你必须确保添加了对 Glide 的注解解析器的依赖。关于如何设置这个库的更多信息，请查看 下载和设置。
过渡选项
对于这类方法：
crossFade()animate()
控制从占位符到图片和/或缩略图到全图的变换的选项，被移动到了 TransitionOptions 中。
要应用过渡（之前的动画），请使用下列选项中符合你请求的资源类型的一个：
如果你想移除任何默认的过渡，可以使用 TransitionOptions.dontTransition()]17 。
过渡动画通过 RequestBuilder 应用到请求上：
Glide.with(fragment) .load(url) .transition(withCrossFade(R.anim.fade_in, 300));
默认过渡
不同于 Glide v3，Glide v4 将不会默认应用交叉淡入或任何其他的过渡效果。每个请求必须手动应用过渡。
Generated API
为了让使用 Glide v4 更简单轻松，Glide 现在也提供了一套可以为应用定制化生成的 API。应用可以通过包含一个标记了 [AppGlideModule][2 的实现来访问生成的 API。如果你不了解这是怎么工作的，可以查看 Generated API 。
Generated API添加了一个 GlideApp 类，该类提供了对 RequestBuilder 和 RequestOptions 子类的访问。RequestOptions 的子类包含了所有 RequestOptions 中的方法，以及 GlideExtensions 中定义的方法。RequestBuilder 的子类则提供了生成的 RequestOptions 中所有方法的访问，而不需要你再手动调用 apply 。举个例子：
在没有使用 Generated API 时，请求大概长这样：
Glide.with(fragment) .load(url) .apply(centerCropTransform() .placeholder(R.drawable.placeholder) .error(R.drawable.error) .priority(Priority.HIGH)) .into(imageView);
使用 Generated API，RequestOptions 的调用可以被内联：
GlideApp.with(fragment) .load(url) .centerCrop() .placeholder(R.drawable.placeholder) .error(R.drawable.error) .priority(Priority.HIGH) .into(imageView);
你仍然可以使用生成的 RequestOptions 子类来应用相同的选项到多次加载中；但生成的 RequestBuilder 子类可能在多数情况下更为方便。
类型(Type)与目标(Target)
选择资源类型
Glide 允许你指定你想加载的资源类型。如果你指定了一个超类型，Glide 会尝试加载任何可用的子类型。比如，如果你请求的是 Drawable ，Glide 可能会加载一个 BitmapDrawable 或一个 GifDrawable 。而如果你请求的是一个 GifDrawable ，要么会加载出一个 GifDrawable，要么报错–只要图片不是 GIF 的话（即使它凑巧是一个完全有效的图片也是如此）。
默认请求的类型是 Drawable：
Glide.with(fragment).load(url)
如果要明确指定请求 Bitmap：
Glide.with(fragment).asBitmap()
如果要创建一个文件路径（本地图片的最佳选项）：
Glide.with(fragment).asFile()
如果要下载一个远程文件到缓存然后创建文件路径：
Glide.with(fragment).downloadOnly()// or if you have the url already:Glide.with(fragment).download(url);
Drawables
Glide v3 版本中的 GlideDrawable 类已经被移除，支持标准的Android Drawable。 GlideBitmapDrawable 也已经被删除，由 BitmapDrawable 代替之。
如果你想知道某个 Drawable 是否是动画(animated)，可以检查它是否为 Animatable 的实例。
boolean isAnimated = drawable instanceof Animatable;
Targets
onResourceReady 方法的签名做了一些修改。例如，对于 Drawables:
onResourceReady(GlideDrawable drawable, GlideAnimation<? super GlideDrawable> anim)
现在改为:
onResourceReady(Drawable drawable, Transition<? super Drawable> transition);
类似地, onLoadFailed 的签名也有一些变动：
onLoadFailed(Exception e, Drawable errorDrawable)
改为：
onLoadFailed(Drawable errorDrawable)
如果你想要获得更多导致加载失败的错误信息，你可以使用 RequestListener 。
取消请求
Glide.clear(Target) 方法被移动到了 RequestManager 中:
Glide.with(fragment).clear(target)
使用 RequestManager 清除之前由它启动的加载过程，通常能提高性能，虽然这并不是强制要求的。Glide v4 会为每一个 Activity 和 Fragment 跟踪请求，所以你需要在合适的层级去清除请求。
配置
在 Glide v3 中，配置使用一个或多个 GlideModule 来完成。而在 Glide v4 中，配置改为使用一个类似但稍微复杂的系统来完成。
关于这个新系统的细节，可以查看配置页面。
应用程序
在早期版本中使用了一个 GlideModule 的应用，可以将它转换为一个 AppGlideModule 。
在 Glide v3 中，你可能会有一个像这样的 GlideModule ：
public class GiphyGlideModule implements GlideModule {
@Override
public void applyOptions(Context context, GlideBuilder builder) {
builder.setMemoryCache(new LruResourceCache(10 * 1024 * 1024));
}
@Override
public void registerComponents(Context context, Registry registry) {
registry.append(Api.GifResult.class, InputStream.class, new GiphyModelLoader.Factory());
}}在 Glide v4 中，你需要将其转换成一个 AppGlideModule ，它看起来像这样：
@GlideModulepublic class GiphyGlideModule extends AppGlideModule {
@Override
public void applyOptions(Context context, GlideBuilder builder) {
builder.setMemoryCache(new LruResourceCache(10 * 1024 * 1024));
}
@Override
public void registerComponents(Context context, Registry registry) {
registry.append(Api.GifResult.class, InputStream.class, new GiphyModelLoader.Factory());
}}请注意，@GlideModule 注解不能省略。
如果你的应用拥有多个 GlideModule，你需要把其中一个转换成 AppGlideModule，剩下的转换成 LibraryGlideModule 。除非存在AppGlideModule ，否则程序不会发现 LibraryGlideModule ，因此您不能仅使用 LibraryGlideModule 。
程序库
拥有一个或多个 GlideModule 的程序库应该使用 LibraryGlideModule 。程序库不应该使用 AppGlideModule ，因为它在一个应用里只能有一个。因此，如果你试图在程序库里使用它，将不仅会妨碍这个库的用户设置自己的选项，还会在多个程序库都这么做时造成冲突。
例如，v3 版本中 Volley 集成库的 GlideModule ：
public class VolleyGlideModule implements GlideModule {
@Override
public void applyOptions(Context context, GlideBuilder builder) {
// Do nothing.
}
@Override
public void registerComponents(Context context, Registry registry) {
registry.replace(GlideUrl.class, InputStream.class, new VolleyUrlLoader.Factory(context));
}}在 v4 版本中可以转换成为一个 LibraryGlideModule ：
@GlideModulepublic class VolleyLibraryGlideModule extends LibraryGlideModule {
@Override
public void registerComponents(Context context, Registry registry) {
registry.replace(GlideUrl.class, InputStream.class, new VolleyUrlLoader.Factory(context));
}}清单解析
为了简化迁移过程，尽管清单解析和旧的 GlideModule 接口已被废弃，但它们在 v4 版本中仍被支持。AppGlideModule，LibraryGlideModule，与已废弃的 GlideModule 可以在一个应用中共存。
然而，为了避免检查元数据的性能天花板（以及相关的 bugs ），你可以在迁移完成后禁用掉清单解析，在你的 AppGlideModule 中复写一个方法：
@GlideModulepublic class GiphyGlideModule extends AppGlideModule {
@Override
public boolean isManifestParsingEnabled() {
return false;
}
...}using(), ModelLoader, StreamModelLoader.
ModelLoader
ModelLoader API 在 v4 版本中仍然存在，并且它的设计目标仍然和它在 v3 中一样，但有一些细节变化。
第一个细节，ModelLoader 的子类型如 StreamModelLoader ，现在已没有存在的必要，用户可以直接实现 ModelLoader 。例如，一个StreamModelLoader<File> 类现在可以通过 ModelLoader<File, InputStream> 的方式来实现和引用。
第二， ModelLoader 现在并不直接返回 DataFetcher，而是返回 LoadData 。[LoadData] 是一个非常简单的封装，包含一个磁盘缓存键和一个 DataFetcher 。
第三， ModelLoaders 有一个 handles() 方法，这使你可以为同一个类型参数注册超过一个的 ModelLoader 。
将一个 ModelLoader 从 v3 API转换到 v4 API ，通常是很简单直接的。如果你在你的 v3 ModelLoader 中只是简单滴返回一个 DataFetcher ：
public final class MyModelLoader implements StreamModelLoader<File> {
@Override
public DataFetcher<InputStream> getResourceFetcher(File model, int width, int height) {
return new MyDataFetcher(model);
}}那么你在 v4 替代类上需要做的仅仅只是封装一下这个 data fetcher ：
public final class MyModelLoader implements ModelLoader<File, InputStream> {
@Override
public LoadData<InputStream> buildLoadData(File model, int width, int height,
Options options) {
return new LoadData<>(model, new MyDataFetcher(model));
}
@Override
public void handles(File model) {
return true;
}}请注意，除了 DataFetcher 之外，模型也被传递给 LoadData 作为缓存键的一部分。这个规则为某些特殊场景提供了更多对磁盘缓存键的控制。大部分实现可以直接将 model 传入 LoadData ，就像上面这样。
如果你仅仅是想为某些 model（而不是所有）使用你的 ModelLoader，你可以在你尝试加载 model 之前使用 handles() 方法来检查它。如果你从 handles方法中返回了 false ，那么你的 ModelLoader 将不能加载指定的 model ，即使你的 ModelLoader 类型 (在这个例子里是 File 和 InputStream) 与之匹配。
举个例子，如果你在某个指定文件夹下写入了加密的图片，你可以使用 handles 方法来实现一个 ModelLoader 以从那个特定的文件夹下解密图片，但是并不用于加载其他文件夹下的 File ：
public final class MyModelLoader implements ModelLoader<File, InputStream> {
private static final String ENCRYPTED_PATH = "/my/encrypted/folder";
@Override
public LoadData<InputStream> buildLoadData(File model, int width, int height,
Options options) {
return new LoadData<>(model, new MyDataFetcher(model));
}
@Override
public void handles(File model) {
return model.getAbsolutePath().startsWith(ENCRYPTED_PATH);
}}using()
using API在 Glide v4 中被删除了，这是为了鼓励用户使用 AppGlideModule 一次性地 注册 所有组件，避免对象重用(re-use, 原文如此 –译者注)。你无需每次加载图片时都创建一个新的 ModelLoader ；你应该在 AppGlideModule 中注册一次，然后交给 Glide 在每次加载时检查 model (即你传入 load() 方法的对象)来决定什么时候使用你注册的 ``ModelLoader` 。
为了确保你仅为特定的 model 使用你的 ModelLoader ，请像上面展示的那样实现 handles 方法：检查每个 model ，但仅在应当使用你的 ModelLoader 时才返回 true 。