文章来源于网络收集而来，版权归原创者所有，如有侵权请及时联系！

配置

发布于 2025-01-04 00:12:06 字数 10531 浏览 0 评论 0 收藏 0

为了 Glide 的配置可以正常的工作，库跟应用程序需要执行一序列的步骤。请注意，库不希望注册不需要的附加的组件。

库

库必须：

添加一个或多个 LibraryGlideModule 实现
添加 @GlideModule 注解给每个 LibraryGlideModule 实现
添加 Glide 注解处理器依赖关系

一个使用 OkHttp 集成库的 Glide 例子如下所示：

@GlideModule
public final class OkHttpLibraryGlideModule extends LibraryGlideModule {
  @Override
  public void registerComponents(Context context, Registry registry) {
    registry.replace(GlideUrl.class, InputStream.class, new OkHttpUrlLoader.Factory());
  }
}

使用 @GlideModule 注解需要 Glide 注解依赖库：

compile 'com.github.bumptech.glide:annotations:4.0.0-RC1'

应用程序

应用程序必须：

添加一个合适的 AppGlideModule 实现
添加一个或多个 LibraryGlideModule 实现
给 AppGlideModule 实现类和所有的 LibraryGlideModule 实现类添加 @GlideModule 注解
添加 Glide 注解处理类依赖关系
为 AppGlideModules 添加 proguard.cfg 的 keep

在 Glide 的 Flickr sample app 的一个 AppGlideModule 例子：

@GlideModule
public class FlickrGlideModule extends AppGlideModule {
  @Override
  public void registerComponents(Context context, Registry registry) {
    registry.append(Photo.class, InputStream.class, new FlickrModelLoader.Factory());
  }
}

包含 Glide 注解处理器要求 Glide 注解依赖和注解处理器：

compile 'com.github.bumptech.glide:annotations:4.0.0-RC1'
annotationProcessor 'com.github.bumptech.glide:compiler:4.0.0-RC1'

最后，您应该在 proguard.cfg 保持 AppGlideModule 实现：

-keep public class * extends com.bumptech.glide.module.AppGlideModule
-keep class com.bumptech.glide.GeneratedAppGlideModuleImpl

应用选项

Glide 允许应用程序使用 AppGlideModule 实现完全控制 Glide 的内存跟磁盘缓存用法。Glide 尝试给大多数应用程序提供合理的默认值，但是对于某些应用程序，需要自定义这些值。一定要衡量避免任何性能下降的修改。

内存缓存

默认情况下，Glide 使用 LruResourceCache ，一个内存缓存接口的默认实现使用固定的内存和 LRU 算法。 LruResourceCache 的大小由 Glide 的 MemorySizeCalculator 类决定，它可以查看设备内存是否不足以及屏幕的分辨率。

应用程序可以在 AppGlideModule 类的 applyOptions(Context, GlideBuilder) 方法中配置 MemorySizeCalculator 定制化内存缓存的大小。

@GlideModule
public class YourAppGlideModule extends AppGlideModule {
  @Override
  public void applyOptions(Context context, GlideBuilder builder) {
    MemorySizeCalculator calculator = new MemorySizeCalculator.Builder(context)
        .setMemoryCacheScreens(2)
        .build();
    builder.setMemoryCache(new LruResourceCache(calculator.getMemoryCacheSize()));
  }
}

应用程序可以直接覆盖缓存大小：

@GlideModule
public class YourAppGlideModule extends AppGlideModule {
  @Override
  public void applyOptions(Context context, GlideBuilder builder) {
    int memoryCacheSizeBytes = 1024 * 1024 * 20; // 20mb
    builder.setMemoryCache(new LruResourceCache(memoryCacheSizeBytes));
  }
}

应用程序可以提供他们自己的内存缓存实现类：

@GlideModule
public class YourAppGlideModule extends AppGlideModule {
  @Override
  public void applyOptions(Context context, GlideBuilder builder) {
    builder.setMemoryCache(new YourAppMemoryCacheImpl());
  }
}

磁盘缓存

Glide 使用 DiskLruCacheWrapper 作为默认的磁盘缓存。DiskLruCacheWrapper 是使用 LRU 算法的固定的磁盘缓存大小。默认的磁盘缓存大小是 250MB 并且在程序缓存文件夹的特定的目录。

如果显示的媒体文件是公开的，应用可以将位置改变为外部存储（包括没有认证的网站，搜索引擎等等）：

@GlideModule
public class YourAppGlideModule extends AppGlideModule {
  @Override
  public void applyOptions(Context context, GlideBuilder builder) {
    builder.setDiskCache(new ExternalDiskCacheFactory(context));
  }
}

应用程序可以改变磁盘缓存大小，不管是内部的还是外部的：

@GlideModule
public class YourAppGlideModule extends AppGlideModule {
  @Override
  public void applyOptions(Context context, GlideBuilder builder) {
    int diskCacheSizeBytes = 1024 * 1024 * 100; // 100 MB
    builder.setDiskCache(new InternalDiskCacheFactory(context, diskCacheSizeBytes));
  }
}

应用程序可以改变外部存储或者内部存储的缓存文件夹的名字：

@GlideModule
public class YourAppGlideModule extends AppGlideModule {
  @Override
  public void applyOptions(Context context, GlideBuilder builder) {
    int diskCacheSizeBytes = 1024 * 1024 * 100; // 100 MB
    builder.setDiskCache(
        new InternalDiskCacheFactory(context, "cacheFolderName", diskCacheSizeBytes));
  }
}

应用程序可以选择实现 DiskCache 接口并提供他们自己的 DiskCache.Factory 实例。Glide 使用工厂接口在后台线程开启磁盘缓存。缓存可以做 I/O 操作。例如：检查目标目录的存在没有违反在严格模式。

@GlideModule
public class YourAppGlideModule extends AppGlideModule {
  @Override
  public void applyOptions(Context context, GlideBuilder builder) {
    builder.setDiskCache(new DiskCache.Factory() {
        @Override
        public DiskCache build() {
          return new YourAppCustomDiskCache();
        }
    });
  }
}

注册组件

应用程序和库都可以注册一些继承 Glide 方法的组件，可用的组件包括：

ModelLoader 加载自定义模型（URL， URI，任意的 POJO）和数据（输入流，文件描述）
ResourceDecoder 解码新的资源（Drawable，Bitmap）或者新的数据类型（输入流，文件描述）
Encoder 写数据（输入流，文件描述）Glide 的磁盘缓存
ResourceTranscoder 从一种资源（BitmapResource）转换为其他类型的资源（DrawableResource）
ResourceEncoder 将资源（BitmapResource, DrawableResource）写入 Glide 的磁盘缓存

注册组件使用 Registry 类。比如：添加 ModelLoader 可以为自定义模型对象获得一个输入流。

@GlideModule
public class YourAppGlideModule extends AppGlideModule {
  @Override
  public void registerComponents(Context context, Registry registry) {
    registry.append(Photo.class, InputStream.class, new CustomModelLoader.Factory());
  }
}

任意数量的组件可以注册在单一的 GlideModule 。ModelLoader 和 ResourceDecoder 可以有多个相同类型参数的实现类。

注册的组件列表，包括那些 Glide 默认注册的和那些在模型中注册的定义的负载路径。每个附件路径是一步步模型提供的负载资源类型通过 as() 指定的类型。负载路径粗略符合下一步骤：

模型->数据（由 ModelLoader 处理）
数据->资源（由 ResourceDecoder 处理）
资源->转换资源（可选，由 ResourceTranscoder 处理）

Encoder 第一步时，写入数据到 Glide 磁盘缓存。 ResourceEncoder 在第二步时，写资源到 Glide 磁盘缓存。

当一个请求开启时，Glide 将尝试从模型到请求资源的所有可用的路径。只要有任何一个负载路径成功则请求成功。只有所有负载路径都失败请求才失败。

注册表中的 prepend()，append() 和 replace() 方法可用于设置 Glide 将尝试每个 ModelLoader 和 ResourceDecoder 的顺序。通过确保首先注册处理最常见类型的 ModelLoaders 和 ResourceDecoders，可以使请求更高效。组件排序还可以允许您注册处理模型或数据的特定子集的组件（即只有某些类型的 Uris 或仅某些图像格式），同时还具有附加的全部组件来处理其余部分。

模块类和注解

Glide v4 依赖于两个类 AppGlideModule 和 LibraryGlideModule 来配置 Glide 单例。允许这两个类注册其他组件，如：ModelLoaders，ResourceDecoders 等。只有 AppGlideModules 允许配置应用程序特定的设置，如缓存实现和大小。

AppGlideModule

所有应用程序必须添加 AppGlideModule 实现，即使应用程序没有更改任何其他设置或在 AppGlideModule 中实现任何方法。 AppGlideModule 实现作为一个信号，允许 Glide 的注解处理器与所有找到的 LibraryGlideModules 一起生成单个组合类。

在给定的应用程序中只能有一个 AppGlideModule 实现（在编译时有多个产生错误）。因此，库绝不能提供 AppGlideModule 实现。

@GlideModule

为了让 Glide 正确找到 AppGlideModule 和 LibraryGlideModule 实现，这两个类的所有实现都必须用 @GlideModule 注解。注解将允许 Glide 的注解处理器在编译时发现所有实现。

注解处理器

此外，为了找到 AppGlideModule 和 LibraryGlideModules，所有的库和应用程序还必须包含对 Glide 的注解处理器的依赖。

冲突

应用程序可能依赖于多个库，每个库可能包含一个或多个 LibraryGlideModules。在极少数情况下，这些 LibraryGlideModule 可能定义了冲突的选项，或者包括应用程序希望避免的行为。应用程序可以通过将 @Excludes 注解添加到其 AppGlideModule 来解决这些冲突或避免不必要的依赖关系。

例如，如果您依赖于您想要避免的 LibraryGlideModule 的库，请传入 com.example.unwanted.GlideModule：

@Excludes（ “com.example.unwanted.GlideModule”）
@GlideModule
public final class MyAppGlideModule extends AppGlideModule {}

您还可以排除多个模块：

@Excludes（{“com.example.unwanted.GlideModule”，“com.example.conflicing.GlideModule”}）
@GlideModule
public final class MyAppGlideModule extends AppGlideModule {}

如果您仍在从 Glide v3 迁移过程中，可以使用 @Excludes 来排除 LibraryGlideModules 和已弃用的 GlideModule 实现。

清单解析

为了保持与 Glide v3 的 GlideModules 的向后兼容性，Glide 仍然从应用程序和任何包含的库中分析 AndroidManifest.xml 文件，并将包括清单中列出的任何旧的 GlideModules。虽然此功能将在以后的版本中被删除，但我们现在已经保留了行为以减轻转换。

如果您已经迁移到 Glide v4 AppGlideModule 和 LibraryGlideModule，则可以完全禁用清单解析。这样做可以提高 Glide 的初始启动时间，并避免尝试解析元数据时出现一些潜在的问题。要禁用清单解析，请覆盖 AppGlideModule 实现中的 isManifestParsingEnabled() 方法：

@GlideModule
public final class MyAppGlideModule extends AppGlideModule {
  @Override
  public boolean isManifestParsingEnabled（）{
    return false;
  }
}

分享到QQ

分享到微博