public class Glide extends Object implements ComponentCallbacks2
RequestBuilder
and maintaining an Engine
, BitmapPool
,
DiskCache
and MemoryCache
.TRIM_MEMORY_BACKGROUND, TRIM_MEMORY_COMPLETE, TRIM_MEMORY_MODERATE, TRIM_MEMORY_RUNNING_CRITICAL, TRIM_MEMORY_RUNNING_LOW, TRIM_MEMORY_RUNNING_MODERATE, TRIM_MEMORY_UI_HIDDEN
Modifier and Type | Method and Description |
---|---|
void |
clearDiskCache()
Clears disk cache.
|
void |
clearMemory()
Clears as much memory as possible.
|
static Glide |
get(Context context)
Get the singleton.
|
ArrayPool |
getArrayPool() |
BitmapPool |
getBitmapPool()
Returns the
BitmapPool used to
temporarily store Bitmap s so they can be reused to avoid garbage
collections. |
Context |
getContext() |
static File |
getPhotoCacheDir(Context context)
Returns a directory with a default name in the private cache directory of the application to
use to store retrieved media and thumbnails.
|
static File |
getPhotoCacheDir(Context context,
String cacheName)
Returns a directory with the given name in the private cache directory of the application to
use to store retrieved media and thumbnails.
|
Registry |
getRegistry() |
RequestManagerRetriever |
getRequestManagerRetriever()
Internal method.
|
static void |
init(Context context,
GlideBuilder builder) |
static void |
init(Glide glide)
Deprecated.
Use
init(Context, GlideBuilder) to get a singleton compatible with
Glide's generated API.
This method will be removed in a future version of Glide. |
void |
onConfigurationChanged(Configuration newConfig) |
void |
onLowMemory() |
void |
onTrimMemory(int level) |
void |
preFillBitmapPool(PreFillType.Builder... bitmapAttributeBuilders)
Pre-fills the
BitmapPool using the given
sizes. |
MemoryCategory |
setMemoryCategory(MemoryCategory memoryCategory)
Adjusts Glide's current and maximum memory usage based on the given
MemoryCategory . |
static void |
tearDown() |
void |
trimMemory(int level)
Clears some memory with the exact amount depending on the given level.
|
static RequestManager |
with(Activity activity)
|
static RequestManager |
with(Context context)
Begin a load with Glide by passing in a context.
|
static RequestManager |
with(Fragment fragment)
|
static RequestManager |
with(Fragment fragment)
|
static RequestManager |
with(FragmentActivity activity)
Begin a load with Glide that will tied to the give
FragmentActivity 's lifecycle and that uses the given
FragmentActivity 's default options. |
static RequestManager |
with(View view)
|
@Nullable public static File getPhotoCacheDir(@NonNull Context context)
context
- A context.getPhotoCacheDir(android.content.Context, String)
@Nullable public static File getPhotoCacheDir(@NonNull Context context, @NonNull String cacheName)
context
- A context.cacheName
- The name of the subdirectory in which to store the cache.getPhotoCacheDir(android.content.Context)
@NonNull public static Glide get(@NonNull Context context)
@Deprecated public static void init(Glide glide)
init(Context, GlideBuilder)
to get a singleton compatible with
Glide's generated API.
This method will be removed in a future version of Glide.
public static void init(@NonNull Context context, @NonNull GlideBuilder builder)
public static void tearDown()
@NonNull public BitmapPool getBitmapPool()
BitmapPool
used to
temporarily store Bitmap
s so they can be reused to avoid garbage
collections.
Note - Using this pool directly can lead to undefined behavior and strange drawing errors.
Any Bitmap
added to the pool must not be currently in use in any other
part of the application. Any Bitmap
added to the pool must be removed
from the pool before it is added a second time.
Note - To make effective use of the pool, any Bitmap
removed from
the pool must eventually be re-added. Otherwise the pool will eventually empty and will not
serve any useful purpose.
The primary reason this object is exposed is for use in custom
ResourceDecoder
s and
Transformation
s. Use outside of these classes is not generally
recommended.
public void preFillBitmapPool(@NonNull PreFillType.Builder... bitmapAttributeBuilders)
BitmapPool
using the given
sizes.
Enough Bitmaps are added to completely fill the pool, so most or all of the Bitmaps currently in the pool will be evicted. Bitmaps are allocated according to the weights of the given sizes, where each size gets (weight / prefillWeightSum) percent of the pool to fill.
Note - Pre-filling is done asynchronously using and
MessageQueue.IdleHandler
. Any currently running pre-fill will be cancelled
and replaced by a call to this method.
This method should be used with caution, overly aggressive pre-filling is substantially
worse than not pre-filling at all. Pre-filling should only be started in onCreate to avoid
constantly clearing and re-filling the
BitmapPool
. Rotation should be carefully
considered as well. It may be worth calling this method only when no saved instance state
exists so that pre-filling only happens when the Activity is first created, rather than on
every rotation.
public void clearMemory()
public void trimMemory(int level)
ComponentCallbacks2.onTrimMemory(int)
public void clearDiskCache()
This method should always be called on a background thread, since it is a blocking call.
@NonNull public RequestManagerRetriever getRequestManagerRetriever()
@NonNull public MemoryCategory setMemoryCategory(@NonNull MemoryCategory memoryCategory)
MemoryCategory
.
The default MemoryCategory
is MemoryCategory.NORMAL
.
MemoryCategory.HIGH
increases Glide's maximum memory usage by up to 50% and
MemoryCategory.LOW
decreases Glide's maximum memory usage by 50%. This method should be
used to temporarily increase or decrease memory usage for a single Activity or part of the app.
Use GlideBuilder.setMemoryCache(MemoryCache)
to put a permanent memory size if you want
to change the default.
@NonNull public static RequestManager with(@NonNull Context 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 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 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 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).
context
- Any context, will not be retained.with(android.app.Activity)
,
with(android.app.Fragment)
,
with(android.support.v4.app.Fragment)
,
with(android.support.v4.app.FragmentActivity)
@NonNull public static RequestManager with(@NonNull Activity activity)
Activity
's lifecycle
and that uses the given Activity
's default options.activity
- The activity to use.@NonNull public static RequestManager with(@NonNull FragmentActivity activity)
FragmentActivity
's lifecycle and that uses the given
FragmentActivity
's default options.activity
- The activity to use.@NonNull public static RequestManager with(@NonNull Fragment fragment)
Fragment
's lifecycle
and that uses the given Fragment
's default options.fragment
- The fragment to use.@NonNull public static RequestManager with(@NonNull Fragment fragment)
Fragment
's lifecycle and that uses the given
Fragment
's default options.fragment
- The fragment to use.@NonNull public static RequestManager with(@NonNull View view)
Fragment
,
Fragment
, or Activity
that contains the View.
A Fragment
or Fragment
is assumed to contain a View if the View
is a child of the View returned by the Fragment.getView()
} method.
This method will not work if the View is not attached. Prefer the Activity and Fragment variants unless you're loading in a View subclass.
This method may be inefficient aways and is definitely inefficient for large hierarchies. Consider memoizing the result after the View is attached or again, prefer the Activity and Fragment variants whenever possible.
When used in Applications that use the non-support Fragment
classes,
calling this method will produce noisy logs from FragmentManager
. Consider
avoiding entirely or using the Fragment
s from the support library instead.
If the support FragmentActivity
class is used, this method will only attempt to
discover support Fragment
s. Any non-support Fragment
s attached
to the FragmentActivity
will be ignored.
view
- The view to search for a containing Fragment or Activity from.public void onTrimMemory(int level)
onTrimMemory
in interface ComponentCallbacks2
public void onConfigurationChanged(Configuration newConfig)
onConfigurationChanged
in interface ComponentCallbacks
public void onLowMemory()
onLowMemory
in interface ComponentCallbacks