Glide4.9.0-原理篇

Glide4.9.0-原理篇

简介

Glide是一个快速高效的Android图片加载库，注重于平滑的滚动。Glide提供了易用的API，高性能、可扩展的图片解码管道（decode pipeline），以及自动的资源池技术。
虽然Glide 的主要目标是让任何形式的图片列表的滚动尽可能地变得更快、更平滑，但实际上，Glide几乎能满足你对远程图片的拉取/缩放/显示的一切需求。这里是基于目前最新的Glide4.9.0来介绍。

基本用法

1.添加依赖

目前最新的是4.9.0

dependencies {
  implementation 'com.github.bumptech.glide:glide:4.9.0'
  annotationProcessor 'com.github.bumptech.glide:compiler:4.9.0'
}

2.加载图片

Glide的图片加载方法很简单，通过context然后加载url，将其放到imageView中显示出来。当然由于Glide是有缓存机制的，因此这个加载过程在第一次是比较明显的，之后的加载会很快的。

    Glide.with(mContext).load(URL).into(imageView);

with()

先是调用Glide.with()。这里with()方法中可传参有context、activity、fragment、FragmentActivity、View。with()方法主要是先去初始化Glide，并且创建RequestMannager对象，并绑定了SupportRequestManagerFragment生命周期函数。

来看源码如下：

  /**
   * Begin a load with Glide by passing in a context.
   *
   * 
 Any requests started using a context will only have the application level options applied
   * and will not be started or stopped based on lifecycle events. In general, loads should be
   * started at the level the result will be used in. If the resource will be used in a view in a
   * child fragment, the load should be started with {@link #with(android.app.Fragment)}} using that
   * child fragment. Similarly, if the resource will be used in a view in the parent fragment, the
   * load should be started with {@link #with(android.app.Fragment)} using the parent fragment. In
   * the same vein, if the resource will be used in a view in an activity, the load should be
   * started with {@link #with(android.app.Activity)}}. 
   *
   * 
 This method is appropriate for resources that will be used outside of the normal fragment
   * or activity lifecycle (For example in services, or for notification thumbnails). 
   *
   * @param context Any context, will not be retained.
   * @return A RequestManager for the top level application that can be used to start a load.
   * @see #with(android.app.Activity)
   * @see #with(android.app.Fragment)
   * @see #with(android.support.v4.app.Fragment)
   * @see #with(android.support.v4.app.FragmentActivity)
   */
  @NonNull
  public static RequestManager with(@NonNull Context context) {
    return getRetriever(context).get(context);
  }

详细的流程实现如下：

getRequestManagerFragment()方法的调用流程如下：


首先先根据tag调用findFragmentByTag()查找fragment；若找不到，则从SupportRequestManagerFragments队列中找；若还找不到，则会新建一个SupportRequestManagerFragment，并将这个新建的fragment放入到SupportRequestManagerFragments队列中。
调用lifecycleListener的onStart()，将Fragment和Activity绑定。之后使用handler发送ID_REMOVE_SUPPORT_FRAGMENT_MANAGER消息将从队列中移除Fragment




build()方法的实现流程如下：

通过getRequestManagerFragment()获取到SupportRequestManagerFragment对象，然后获取SupportRequestManagerFragment对象的Lifecycle对象。然后调用到build()方法去创建RequestManager对象的时候会将这个Lifecycle对象作为参数传入。
而RequestManager类实现了LifecycleListener接口，通过lifecycle.addListener(this)方法添加了监听器 ，并且实现接口方法onStart()/onStop()。
因此当SupportRequestManagerFragment的生命周期发生变化的时候，就会去调用Lifecycle对象中的生命周期方法，而该生命周期方法的实现是在RequestManager。这就使得Fragment生命周期和Glide请求之间形成互相监听绑定。原因：由于Glide无法监听Activity状态，而fragment和activity生命周期是同步的，因此通过一个Fragment 子类SupportRequestManagerFragment来实现监听，这样如果activity销毁了，那么就能通知调用stop方法停止加载了。

load()

接着来看RequestManager.load()，源码如下：

  /**
   * Equivalent to calling {@link #asDrawable()} and then {@link RequestBuilder#load(String)}.
   *
   * @return A new request builder for loading a {@link Drawable} using the given model.
   */
  @NonNull
  @CheckResult
  @Override
  public RequestBuilder<Drawable> load(@Nullable String string) {
    return asDrawable().load(string);
  }

也可以看到load()方法中传入的参数有多个类型：bitmap、Drawable、String、Uri、File、Integer（如resourceid）。最后调用到RequestBuilder类中的loadGeneric()方法，将传入的参数赋值给RequestBuiler.model，同时isModelSet置为true，最终返回的是一个RequestBuilder对象。

into()

最后看RequestBuilder.into()，源码如下：

  /**
   * Sets the {@link ImageView} the resource will be loaded into, cancels any existing loads into
   * the view, and frees any resources Glide may have previously loaded into the view so they may be
   * reused.
   *
   * @see RequestManager#clear(Target)
   *
   * @param view The view to cancel previous loads for and load the new resource into.
   * @return The
   * {@link com.bumptech.glide.request.target.Target} used to wrap the given {@link ImageView}.
   */
  @NonNull
  public ViewTarget<ImageView, TranscodeType> into(@NonNull ImageView view) {
    Util.assertMainThread();
    Preconditions.checkNotNull(view);

    BaseRequestOptions<?> requestOptions = this;
    if (!requestOptions.isTransformationSet()
        && requestOptions.isTransformationAllowed()
        && view.getScaleType() != null) {
      // Clone in this method so that if we use this RequestBuilder to load into a View and then
      // into a different target, we don't retain the transformation applied based on the previous
      // View's scale type.
      switch (view.getScaleType()) {
        case CENTER_CROP:
          requestOptions = requestOptions.clone().optionalCenterCrop();
          break;
        case CENTER_INSIDE:
          requestOptions = requestOptions.clone().optionalCenterInside();
          break;
        case FIT_CENTER:
        case FIT_START:
        case FIT_END:
          requestOptions = requestOptions.clone().optionalFitCenter();
          break;
        case FIT_XY:
          requestOptions = requestOptions.clone().optionalCenterInside();
          break;
        case CENTER:
        case MATRIX:
        default:
          // Do nothing.
      }
    }

详细的流程实现如下：

上面的流程图先到SingleRequest@begin()中的这段代码：

  public synchronized void begin() {
    assertNotCallingCallbacks();
    stateVerifier.throwIfRecycled();
    startTime = LogTime.getLogTime();
    if (model == null) {
      if (Util.isValidDimensions(overrideWidth, overrideHeight)) {
        width = overrideWidth;
        height = overrideHeight;
      }
      // Only log at more verbose log levels if the user has set a fallback drawable, because
      // fallback Drawables indicate the user expects null models occasionally.
      int logLevel = getFallbackDrawable() == null ? Log.WARN : Log.DEBUG;
      onLoadFailed(new GlideException("Received null model"), logLevel);
      return;
    }

   ...

我们接着继续：

部分方法说明：

1. ImageViewTargetFactory@buildTarget() ,传参clazz的传递是其实就是Bitmap.class/Drawable.class/File.class

1. SingleRequest@setErrorPlaceholder()

这里就能看到，先是判断model是否为空，为空则调用getFallbackDrawable(),获取fallbackDrawable；如果没有获取到fallbackDrawable，则会调用getErrorDrawable()，获取errorDrawable；如果没有获取到errorDrawable，则会调用getPlaceholderDrawable(),获取placeholderDrawable。
发现了没有:这里就是占位符、错误符、后备回调符的加载实现的地方。

  private synchronized void setErrorPlaceholder() {
    if (!canNotifyStatusChanged()) {
      return;
    }

    Drawable error = null;
    if (model == null) {
      error = getFallbackDrawable();
    }
    // Either the model isn't null, or there was no fallback drawable set.
    if (error == null) {
      error = getErrorDrawable();
    }
    // The model isn't null, no fallback drawable was set or no error drawable was set.
    if (error == null) {
      error = getPlaceholderDrawable();
    }
    target.onLoadFailed(error);
  }

1. SourceGenerator@startNext()

  @Override
  public boolean startNext() {
    ......
    while (!started && hasNextModelLoader()) {
      loadData = helper.getLoadData().get(loadDataListIndex++);
      ....
    }
    return started;
  }

这里主要看一下loadData的获取流程：
通过getLoadData()获取LoadData，这里仅以输入为string类型的URL为例（当然输入类型不一样，所调用的fetcher也不同，但是实现逻辑基本是一样的）。

--> DecodeHelper.getLoadData()

 --> Registry.getModelLoaders()

 --> ModelLoaderRegistry.getModelLoaders()

 --> ModelLoaderRegistry.getModelLoadersForClass()
	
	这里是通过遍历multiModelLoaderFactory

 --> Glide.Glide().append()

	Glide的构造函数中会调用Registry.append()

 --> ModelLoaderRegistry.append()

	这时我们来看，如果我们传入的URL，那么这是一个String，那有可能是：

    .append(String.class, InputStream.class, new DataUrlLoader.StreamFactory())
    .append(String.class, InputStream.class, new StringLoader.StreamFactory())
    .append(String.class, ParcelFileDescriptor.class, new StringLoader.FileDescriptorFactory())

	先来看DataUrlLoader的handlers()方法，需要String以"data:image"开头，很明显我们传入的URL不是这个样子的，第三个是序列化的String也不是的。那只能是第二个StringLoader

 --> StringLoader.StreamFactory()

	工厂类创建一个的modelLoader，这时再去Glide的构造函数中查找可以看到.append(Uri.class, InputStream.class, new UrlUriLoader.StreamFactory())；同样去看他的工厂类实现是创建一个的modelLoader,再去查找：
	.append(GlideUrl.class, InputStream.class, new HttpGlideUrlLoader.Factory())

	因此我们找到了modelLoader为HttpGlideUrlLoader

--> ModelLoader.buildLoadData()

--> HttpGlideUrlLoader.buildLoadData()

	这里获取传递过来的String，并且将DataFetcher设置为HttpUrlFetcher。这就使得后面在接口DataFetcher.loadData()方法的实现类是HttpUrlFetcher.loadData()

1. Downsampler@decodeFromWrappedStreams()

这个方法就是真正的解码实现。

3.占位符

Glide允许用户指定三种不同类型的占位符，分别在三种不同场景使用：占位符、错误符、后备回调符。

占位符placeload：

**占位符是当请求正在执行时被展示的 Drawable 。当请求成功完成时，占位符会被请求到的资源替换。**如果被请求的资源是从内存中加载出来的，那么占位符可能根本不会被显示。如果请求失败并且没有设置error Drawable ，则占位符将被持续展示。类似地，如果请求的url/model为null，并且 error Drawable和 fallback drawable 都没有设置，那么占位符也会继续显示。


实现如下：

RequestOptions requestOptions = new RequestOptions().placeholder(R.mipmap.loading);
Glide.with(context)
     .load(IMAGE_URL)
     .apply(requestOptions)
     .into(imageView);

### 错误符error： **error Drawable在请求永久性失败时展示。**error Drawable 同样也在请求的url/model为null，且并没有设置 fallback drawable时展示。


实现如下：

    RequestOptions requestOptions = new RequestOptions().placeholder(R.mipmap.loading)
            .error(R.mipmap.error);

		Glide.with(context)
      		 .load(IMAGE_URL)
       		 .apply(requestOptions)
       		 .into(imageView);

后备回调符 fallback：

fallback drawable在请求的url/model为null时展示。设计fallback drawable的主要目的是允许用户指示null是否为可接受的正常情况。例如，一个null的个人资料 url 可能暗示这个用户没有设置头像，因此应该使用默认头像。然而，null也可能表明这个元数据根本就是不合法的，或者取不到。 默认情况下Glide将null作为错误处理，所以可以接受null的应用应当显式地设置一个fallback drawable 。


实现如下：

    RequestOptions requestOptions = new RequestOptions().placeholder(R.mipmap.loading)
            .error(R.mipmap.error)
            .fallback(R.mipmap.fallback);

		Glide.with(context)
      		 .load(IMAGE_URL)
       		 .apply(requestOptions)
       		 .into(imageView);

Glide中的大部分设置项都可以通过RequestOptions类和apply()方法来应用到程序中。

4.缓存

默认情况下，Glide 会在开始一个新的图片请求之前检查以下多级的缓存：

1. 活动资源 (Active Resources) - 现在是否有另一个 View 正在展示这张图片？
2. 内存缓存 (Memory cache) - 该图片是否最近被加载过并仍存在于内存中？
3. 资源类型（Resource） - 该图片是否之前曾被解码、转换并写入过磁盘缓存？
4. 数据来源 (Data) - 构建这个图片的资源是否之前曾被写入过文件缓存？

前两步检查图片是否在内存中，如果是则直接返回图片。后两步则检查图片是否在磁盘上，以便快速但异步地返回图片。
如果四个步骤都未能找到图片，则Glide会返回到原始资源以取回数据（原始文件，Uri, Url等）。

(1).缓存KEY

这里Kye的生成实现是在Engine.load()中

	 EngineKey key = keyFactory.buildKey(model, signature, width, height, transformations,
        resourceClass, transcodeClass, options);

往下流程看到EngineKey的构造函数，可以看到传参有：
model（请求加载的URL、File、）、
singature（签名）、
width（宽度）、
height（高度）、
transformations(变换)、
resourceClass(要转换的资源类型)、
transcodeClass(要解码的资源，对应的参数传入是RequestManager.asBitmap())、
options（额外添加的选项，用以适应内存）

key至少要包含model和singature这两个元素。在EngineKey类中有2个重写方法equals和hasCode，其实就是用来判断key的每一个元素是否相同，只要有一个不同就不是同一个Key。

  @Override
  public boolean equals(Object o) {
    if (o instanceof EngineKey) {
      EngineKey other = (EngineKey) o;
      return model.equals(other.model)
          && signature.equals(other.signature)
          && height == other.height
          && width == other.width
          && transformations.equals(other.transformations)
          && resourceClass.equals(other.resourceClass)
          && transcodeClass.equals(other.transcodeClass)
          && options.equals(other.options);
    }
    return false;
  }

  @Override
  public int hashCode() {
    if (hashCode == 0) {
      hashCode = model.hashCode();
      hashCode = 31 * hashCode + signature.hashCode();
      hashCode = 31 * hashCode + width;
      hashCode = 31 * hashCode + height;
      hashCode = 31 * hashCode + transformations.hashCode();
      hashCode = 31 * hashCode + resourceClass.hashCode();
      hashCode = 31 * hashCode + transcodeClass.hashCode();
      hashCode = 31 * hashCode + options.hashCode();
    }
    return hashCode;
  }

(2).缓存类型

A.内存缓存

Glide使用LruResourceCache，这是MemoryCache接口的一个缺省实现，使用固定大小的内存和 LRU 算法。LruResourceCache的大小由 Glide 的MemorySizeCalculator类来决定，这个类主要关注设备的内存类型，设备 RAM 大小，以及屏幕分辨率。
默认情况下Glide是开启内存缓存的，因为BaseRequestOption.isCacheable是为true。若我们不需要内存缓存，则可以调用skipMemoryCache(true)。这样在Engine@load()方法的时候传入的isMemoryCacheable为false。这样在调用loadFromActiveResources()/loadFromCache()的时候会直接返回空，就不会从缓存中加载资源了。

    RequestOptions requestOptions = new RequestOptions().placeholder(R.mipmap.loading)
            .error(R.mipmap.error)
            .fallback(R.mipmap.fallback)
            .skipMemoryCache(true);

a.内存缓存读取逻辑
如上面所说，在图片加载的时候调用到loadFromActiveResources()/loadFromCache()来实现/跳过内存缓存。

先来看loadFromActiveResources()的源码，这里有看到一个弱引用Hashmap ResourceWeakReference来缓存EngineResource对象。

  @Nullable
  private EngineResource<?> loadFromActiveResources(Key key, boolean isMemoryCacheable) {
    if (!isMemoryCacheable) {
      return null;
    }
    EngineResource<?> active = activeResources.get(key);
    if (active != null) {
      active.acquire();
    }

    return active;
  }
  ....
  final Map<Key, ResourceWeakReference> activeEngineResources = new HashMap<>();
  ....
  @Nullable
  synchronized EngineResource<?> get(Key key) {
    ResourceWeakReference activeRef = activeEngineResources.get(key);
    if (activeRef == null) {
      return null;
    }

    EngineResource<?> active = activeRef.get();
    if (active == null) {
      cleanupActiveReference(activeRef);
    }
    return active;
  }

接着看loadFromCache()方法。这里getEngineResourceFromCache()函数获取的cache即是memoryCache，对应的LruResourceCache。获取到图片缓存后，调用activate()生成一个弱引用HashMap：activeEngineResources，并将图片缓存放到activeEngineResources中;而上面的loadFromActiveResources()方法就是从弱引用activeEngineResources中获取图片缓存。这就使得在activeEngineResources中的对象不会被LRU 算法回收。

	private EngineResource<?> loadFromCache(Key key, boolean isMemoryCacheable) {
    if (!isMemoryCacheable) {
      return null;
    }

    EngineResource<?> cached = getEngineResourceFromCache(key);
    if (cached != null) {
      cached.acquire();
      activeResources.activate(key, cached);
    }
    return cached;
	}

	private EngineResource<?> getEngineResourceFromCache(Key key) {
    Resource<?> cached = cache.remove(key);

    final EngineResource<?> result;
    if (cached == null) {
      result = null;
    } else if (cached instanceof EngineResource) {
      // Save an object allocation if we've cached an EngineResource (the typical case).
      result = (EngineResource<?>) cached;
    } else {
      result = new EngineResource<>(
          cached, /*isMemoryCacheable=*/ true, /*isRecyclable=*/ true, key, /*listener=*/ this);
    }
    return result;
	}

上面的cache是怎么来的？

这就印证了最开始说的，内存缓存是使用LruResourceCache


b.内存缓存写入逻辑
之前有讲到过RequestBuilder.into()的逻辑，最后的方法是在 DecodeJob@notifyEncodeAndRelease()。跟一下后续的流程。可以看到会将engineResource对象put到弱引用hashMap：activeEngineResources中。这样再下次调用的时候就会先从activeEngineResources中engineResource获取对象

c.关键类EngineResource

acquire()：当调用此方法后会将计数器acquired自增1；
ResourceListener：监听器接口；
relese()：释放资源，同时将计数器acquired自减1；

因此当acquired大于0的时候，说明资源正在使用；若acquired为0的时候会触发监听器接口函数onResourceReleased()会先将缓存图片从缓存中移除，然后将这个对象put到。这样正在使用中的图片放到弱引用对象中；不使用的会先缓存起来。

public class Engine implements EngineJobListener,
    MemoryCache.ResourceRemovedListener,
    EngineResource.ResourceListener {
  ....
	@Override
	public synchronized void onResourceReleased(Key cacheKey, EngineResource<?> resource) {
    activeResources.deactivate(cacheKey);
    if (resource.isMemoryCacheable()) {
      cache.put(cacheKey, resource);
    } else {
      resourceRecycler.recycle(resource);
    }
  }
  ...
}

B.磁盘缓存

Glide 使用DiskLruCacheWrapper作为默认的磁盘缓存。DiskLruCacheWrapper是一个使用 LRU 算法的固定大小的磁盘缓存。默认磁盘大小为250M，位置是在应用的缓存文件夹中的一个特定目录。路径为：/data/data/{包名}/cache/image_manager_disk_cache 。

public interface DiskCache {

  /**
   * An interface for lazily creating a disk cache.
   */
  interface Factory {
    /** 250 MB of cache. */
    int DEFAULT_DISK_CACHE_SIZE = 250 * 1024 * 1024;
    String DEFAULT_DISK_CACHE_DIR = "image_manager_disk_cache";

    /** Returns a new disk cache, or {@code null} if no disk cache could be created. */
    @Nullable
    DiskCache build();
  }
  ....
}

public final class InternalCacheDiskCacheFactory extends DiskLruCacheFactory {
  ....
  public InternalCacheDiskCacheFactory(final Context context, final String diskCacheName,
                                       long diskCacheSize) {
    super(new CacheDirectoryGetter() {
      @Override
      public File getCacheDirectory() {
        File cacheDirectory = context.getCacheDir();
        if (cacheDirectory == null) {
          return null;
        }
        if (diskCacheName != null) {
          return new File(cacheDirectory, diskCacheName);
        }
        return cacheDirectory;
      }
    }, diskCacheSize);
  }
  ....
}  

这些在Glide初始化的时候已经创建完成的。


a.缓存策略

	private void runWrapped() {
    switch (runReason) {
      case INITIALIZE:
        stage = getNextStage(Stage.INITIALIZE);
        currentGenerator = getNextGenerator();
        runGenerators();
        break;
      case SWITCH_TO_SOURCE_SERVICE:
        runGenerators();
        break;
      case DECODE_DATA:
        decodeFromRetrievedData();
        break;
      default:
        throw new IllegalStateException("Unrecognized run reason: " + runReason);
    }
	}

	.......

	private void runGenerators() {
    currentThread = Thread.currentThread();
    startFetchTime = LogTime.getLogTime();
    boolean isStarted = false;
    while (!isCancelled && currentGenerator != null
        && !(isStarted = currentGenerator.startNext())) {
      stage = getNextStage(stage);
      currentGenerator = getNextGenerator();

      if (stage == Stage.SOURCE) {
        reschedule();
        return;
      }
    }

	.......

	private Stage getNextStage(Stage current) {
    switch (current) {
      case INITIALIZE:
        return diskCacheStrategy.decodeCachedResource()
            ? Stage.RESOURCE_CACHE : getNextStage(Stage.RESOURCE_CACHE);
      case RESOURCE_CACHE:
        return diskCacheStrategy.decodeCachedData()
            ? Stage.DATA_CACHE : getNextStage(Stage.DATA_CACHE);
      case DATA_CACHE:
        // Skip loading from source if the user opted to only retrieve the resource from cache.
        return onlyRetrieveFromCache ? Stage.FINISHED : Stage.SOURCE;
      case SOURCE:
      case FINISHED:
        return Stage.FINISHED;
      default:
        throw new IllegalArgumentException("Unrecognized stage: " + current);
    }
	}

这里都会调用到DiskCacheStrategy的decodeCachedResource()/decodeCachedData(),这两个方法是抽象方法，具体实现是：

public abstract class DiskCacheStrategy {
 public static final DiskCacheStrategy AUTOMATIC = new DiskCacheStrategy() {
    @Override
    public boolean isDataCacheable(DataSource dataSource) {
      return dataSource == DataSource.REMOTE;
    }

    @Override
    public boolean isResourceCacheable(boolean isFromAlternateCacheKey, DataSource dataSource,
        EncodeStrategy encodeStrategy) {
      return ((isFromAlternateCacheKey && dataSource == DataSource.DATA_DISK_CACHE)
          || dataSource == DataSource.LOCAL)
          && encodeStrategy == EncodeStrategy.TRANSFORMED;
    }

    @Override
    public boolean decodeCachedResource() {
      return true;
    }

    @Override
    public boolean decodeCachedData() {
      return true;
    }
	};
  ....
}

这里一共有五种缓存策略：

ALL、结合DATA和RESORCE的策略

NONE：不缓存

DATA：解码前将资源写入磁盘，缓存原始图片

RESOURCE：解码后将资源写入磁盘，缓存转换后的图片

AUTOMATIC：这是默认缓存策略。它会尝试对本地和远程图片使用最佳的策略。当你加载远程数据（比如，从URL下载）时，AUTOMATIC 策略仅会存储未被你的加载过程修改过(比如，变换，裁剪)的原始数据，因为下载远程数据相比调整磁盘上已经存在的数据要昂贵得多。对于本地数据，AUTOMATIC 策略则会仅存储变换过的缩略图，因为即使你需要再次生成另一个尺寸或类型的图片，取回原始数据也很容易。(这段来自官网描述)

因此实现磁盘缓存的方式就是加载不同的缓存策略：

        requestOptions = new RequestOptions().placeholder(R.mipmap.ic_launcher)
        .diskCacheStrategy(DiskCacheStrategy.RESOURCE);

b.磁盘缓存写入逻辑

还记得在into()流程中，实现网络请求的方法吗？没错，是在HttpUrlFetcher@loadData()中：

  @Override
  public void loadData(@NonNull Priority priority,
      @NonNull DataCallback callback) {
    long startTime = LogTime.getLogTime();
    try {
      InputStream result = loadDataWithRedirects(glideUrl.toURL(), 0, null, glideUrl.getHeaders());
      callback.onDataReady(result);
    } catch (IOException e) {
      if (Log.isLoggable(TAG, Log.DEBUG)) {
        Log.d(TAG, "Failed to load data for url", e);
      }
      callback.onLoadFailed(e);
    } finally {
      if (Log.isLoggable(TAG, Log.VERBOSE)) {
        Log.v(TAG, "Finished http url fetcher fetch in " + LogTime.getElapsedMillis(startTime));
      }
    }
  }

上面可以看到会通过调用loadDataWithRedirects来获取输入流。之后会通过回调方法onDataReady传入这个输入流。我们需要看下onDataReady做了什么！

class SourceGenerator implements DataFetcherGenerator,
    DataFetcher.DataCallback