Glide学習ノート

Anatomy of a load

The set of registered components, including both those registered by default in Glide and those registered in Modules are used to define a set of load paths. Each load path is a step by step progression from the the Model provided to load() to the Resource type specified by as(). A load path consists (roughly) of the following steps:
1. Model -> Data (handled by ModelLoaders)
->Encoders
2. Data -> Resource (handled by ResourceDecoders)
->ResourceEncoders
3. Resource -> Transcoded Resource (optional, handled by ResourceTranscoders).

Encoders can write Data to Glide’s disk cache cache before step 2. ResourceEncoders can write Resource’s to Glide’s disk cache before step 3.
When a request is started, Glide will attempt all available paths from the Model to the requested Resource type. A request will succeed if any load path succeeds. A request will fail only if all available load paths fail.

bitmapを自動的に回収するにはどうすればいいですか?

Glide              ，   ImageView，             ImageView。

into:
Sets the 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.

public  Target buildTarget(ImageView view, Class clazz):
Sets the android resource id to use in conjunction with View.setTag(int, Object) to store temporary state allowing loads to be automatically cancelled and resources re-used in scrolling lists.

To detect View reuse in android.widget.ListView or any android.view.ViewGroup that reuses views, this class uses the View.setTag(Object) method to store some metadata so that if a view is reused, any previous loads or resources from previous loads can be cancelled or reused.

ライフサイクルに従って自動的にロードを停止するにはどうすればいいですか?
A view-less Fragment used to safely store an RequestManager that can be used to start, stop and manage Glide requests started for targets the fragment or activity this fragment is a child of.

@TargetApi(Build.VERSION_CODES.JELLY_BEAN_MR1)
RequestManagerFragment getRequestManagerFragment(
    final android.app.FragmentManager fm, android.app.Fragment parentHint) {
  RequestManagerFragment current = (RequestManagerFragment) fm.findFragmentByTag(FRAGMENT_TAG);
  if (current == null) {
    current = pendingRequestManagerFragments.get(fm);
    if (current == null) {
      current = new RequestManagerFragment();
      current.setParentFragmentHint(parentHint);
      pendingRequestManagerFragments.put(fm, current);
      fm.beginTransaction().add(current, FRAGMENT_TAG).commitAllowingStateLoss();//    Fragment Activity       
      handler.obtainMessage(ID_REMOVE_FRAGMENT_MANAGER, fm).sendToTarget();
    }
  }
  return current;
}

public RequestManagerFragment() {
  this(new ActivityFragmentLifecycle());
}

ダウンロードインタフェースをカスタマイズしますか?

  ModelLoader，   stream

キャッシュ?
Glideのキャッシュ実装はPicassoに基づいている.キャッシュ実装のサイズは、デバイスのディスクサイズに依存します.

By default, Glide checks multiple layers of caches before starting a new request for an image:
1. Active resources - Is this image displayed in another View right now?
2. Memory cache - Was this image recently loaded and still in memory?
3. Resource - Has this image been decoded, transformed, and written to the disk cache before?
4. Data - Was the data this image was obtained from written to the disk cache before?

The first two steps check to see if the resource is in memory and if so, return the image immediately. The second two steps check to see if the image is on disk and return quickly, but asynchronously.

Cache Keysの生成

In Glide 4, all cache keys contain at least two elements:
1. The model the load** is requested for (File, Uri, Url) (If you are using a custom model, it needs to correctly implements hashCode() and equals()
2. An optional Signature

In fact, the cache keys for steps 1-3 (Active resources, memory cache, resource disk cache) also include a number of other pieces of data including:
1. The width and height
2. The optional Transformation
3. Any added Options
4. The requested data type (Bitmap, GIF, etc)

The keys used for active resources and the memory cache also differ slightly from those used from the resource disk cache to accomodate in memory Options like those that affect the configuration of the Bitmap or other decode time only parameters.
To generate the name of disk cache keys on disk, the individual elements of the keys are hashed to create a single String key, which is then used as the file name in the disk cache.