从源码角度深刻理解Glide4（上）
谈到Glide，从英文字面意思有滑行、滑动的意思；而Android从开发的角度咱们知道它是一款图片加载框架，这里引用官方文档的一句话“Glide是一个快速高效的Android图片加载库，注重于平滑的滚动”，从官方文档介绍咱们了解到用Glide框架来加载图片是快速而且高效的，接下来就来经过简单使用Glide和源码理解两个方面看看Glide是不是快速和高效（文中代码基于Glide 4.8版本）。html
Glide简单使用
-
1.使用前须要添加依赖java
implementation 'com.github.bumptech.glide:glide:4.8.0' //使用Generated API须要引入 annotationProcessor 'com.github.bumptech.glide:compiler:4.8.0' 复制代码 -
2.简单加载网络图片到ImageView，能够看到简单一句代码就能将网络图片加载到ImageView，也可使用Generated API方式android
//直接使用 Glide.with(Context).load(IMAGE_URL).into(mImageView) //使用Generated API， 做用范围Application 模块内使用 //建立MyAppGlideModule类加上@GlideModule注解，make project 就能使用 GlideApp @GlideModule public final class MyAppGlideModule extends AppGlideModule {} //Generated API加载图片 GlideApp.with(Context).load(IMAGE_URL).into(mImageView); 复制代码 -
3.当加载网络图片的时候，网络请求是耗时操做，因此图片不可能立刻就加载出来，网络请求这段时间ImageView是空白的，因此咱们可使用一个占位符显示图片来优化用户体验，占位符有三种git
- 加载占位符（placeholder）
- 错误占位符（error）
- 后备回调符（Fallback）
//添加占位图 RequestOptions requestOptions = new RequestOptions() .placeholder(R.drawable.ic_cloud_download_black_24dp) .error(R.drawable.ic_error_black_24dp) .diskCacheStrategy(DiskCacheStrategy.NONE);//不使用缓存 Glide.with(Context).load(IMAGE_URL).apply(requestOptions).into(mImageView); //Generated API 方式(和Glide3 同样) GlideApp.with(Context).load(IMAGE_URL) .placeholder(R.drawable.ic_cloud_download_black_24dp) .error(R.drawable.ic_error_black_24dp) .diskCacheStrategy(DiskCacheStrategy.NONE) .into(mImageView); // 后备回调符(Fallback) Generated API 方式才有，在应用设置用户头像场景中，若是用户不设置，也就是为null的状况，可使用后备回调符显示默认头像 private static final String NULL_URL=null; GlideApp.with(Context).load(NULL_URL) .fallback(R.drawable.ic_account_circle_black_24dp) .into(mImageView); 复制代码 -
4.指定加载图片的大小（override）github
RequestOptions requestOptions = new RequestOptions().override(200,100); Glide.with(Context).load(IMAGE_URL).apply(requestOptions).into(mImageView); //Generated API 方式 GlideApp.with(Context).load(IMAGE_URL) .override(200,100) .into(mImageView); 复制代码 -
5.缩略图 (Thumbnail)缓存
- 这个其实和占位符（placeholder）有些类似，可是占位符只能加载本地资源，而缩略图能够加载网络资源，thumbnail方法与咱们的主动加载并行运行，若是主动加载已经完成，则缩略图不会显示
//缩略图Options RequestOptions requestOptions = new RequestOptions() .override(200,100) .diskCacheStrategy(DiskCacheStrategy.NONE); Glide.with(Context) .load(IMAGE_URL) .thumbnail( Glide.with(this) .load(IMAGE_URL) .apply(requestOptions)) .into(mImageView); //Generated API 方式 GlideApp.with(Context). load(IMAGE_URL). thumbnail( GlideApp.with(this) .load(IMAGE_URL).override(200,100) .diskCacheStrategy(DiskCacheStrategy.NONE)).into(mImageView); 复制代码 -
6.图像变化bash
-
Glide中内置了三种图片的变化操做，分别是CenterCrop（图片原图的中心区域进行裁剪显示），FitCenter（图片原始长宽铺满）和CircleCrop（圆形裁剪）网络
//显示圆形裁剪到ImageView RequestOptions requestOptions = new RequestOptions() .circleCrop() .diskCacheStrategy(DiskCacheStrategy.NONE); Glide.with(Context) .load(IMAGE_URL) .apply(requestOptions) .into(mImageView); //RequestOptions都内置了使用者三种变化的静态方法 Glide.with(Context) .load(IMAGE_URL) .apply(RequestOptions.circleCropTransform()) .into(mImageView); //Generated API 方式 GlideApp.with(Context).load(IMAGE_URL) .circleCrop() .diskCacheStrategy(DiskCacheStrategy.NONE) .into(mImageView); 复制代码 -
若是想要更酷炫的变化，可使用第三方框架glide-transformations来帮助咱们实现，而且变化是能够组合的app
//第三方框架glide-transformations引入 implementation 'jp.wasabeef:glide-transformations:4.0.0' //使用glide-transformations框架 变换图片颜色和加入模糊效果 RequestOptions requestOptions=new RequestOptions() .placeholder(R.drawable.ic_cloud_download_black_24dp) .transforms(new ColorFilterTransformation(Color.argb(80, 255, 0, 0)),new BlurTransformation(30)) .diskCacheStrategy(DiskCacheStrategy.NONE); Glide.with(Context).load(IMAGE_URL). apply(requestOptions). into(mImageView); //Generated API 方式 GlideApp.with(Context).load(IMAGE_URL) .transforms(new ColorFilterTransformation(Color.argb(80, 255, 0, 0)),new BlurTransformation(30)) .placeholder(R.drawable.ic_cloud_download_black_24dp) .diskCacheStrategy(DiskCacheStrategy.NONE) .into(mImageView); 复制代码
-
更多效果能够查看官方例子框架
-
-
7.加载目标（Target）
-
Target是介于请求和请求者之间的中介者的角色，into方法的返回值就是target对象，以前咱们一直使用的 into(ImageView) ，它实际上是一个辅助方法，它接受一个 ImageView 参数并为其请求的资源类型包装了一个合适的 ImageViewTarget
//加载 Target<Drawable> target = Glide.with(Context) .load(url) .into(new Target<Drawable>() { ... }); //清除加载 Glide.with(Context).clear(target); 复制代码 -
当咱们使用Notification显示应用通知，若是想要自定义通知的界面，咱们须要用到RemoteView，若是要给RemoteView设置ImageView，根据提供的setImageViewBitmap方法，若是通知界面须要加载网络图片，则须要将网络图片转换成bitmap，通常咱们能够根据获取图片连接的流来转换成bitmap，或者使用本文的主题使用Glide框架，这些都是耗时操做，感受操做起来很麻烦，而Glide框架很贴心的给我提供了NotificationTarget(继承SimpleTarget)，相对于咱们加载目标变成Notification
/** * 新建 NotificationTarget 对象参数说明，与Glide3不一样，Glide4的asBitmap()方法必须在load方法前面 * @param context 上下文对象 * @param viewId 须要加载ImageView的view的 id * @param remoteViews RemoteView对象 * @param notification Notification对象 * @param notificationId Notification Id */ String iamgeUrl = "http://p1.music.126.net/fX0HfPMAHJ2L_UeJWsL7ig==/18853325881511874.jpg?param=130y130"; NotificationTarget notificationTarget = new NotificationTarget(mContext,R.id.notification_Image_play,mRemoteViews,mNotification,notifyId); Glide.with(mContext.getApplicationContext()) .asBitmap() .load(iamgeUrl) .into( notificationTarget ); //Generated API 方式 GlideApp.with(mContext.getApplicationContext()) .asBitmap() .load(iamgeUrl) .into( notificationTarget ); 复制代码
-
-
8.回调监听
- 使用Glide加载图片，虽然在加载中或者加失败都有占位符方法处理，可是咱们仍是但愿能够知道图片究竟是加载成功仍是失败，Glide也给咱们提供了监听方法来知道图片究竟是加载成功仍是失败，结合listener和into方法来使用回调
Glide.with(this).load(IMAGE_URL). listener(new RequestListener<Drawable>() { @Override public boolean onLoadFailed(@Nullable GlideException e, Object model, Target<Drawable> target, boolean isFirstResource) { Toast.makeText(getApplicationContext(),"图片加载失败",Toast.LENGTH_SHORT).show(); return false; } @Override public boolean onResourceReady(Drawable resource, Object model, Target<Drawable> target, DataSource dataSource, boolean isFirstResource) { Toast.makeText(getApplicationContext(),"图片加载成功",Toast.LENGTH_SHORT).show(); return false; } }).into(mImageView);*/ //Generated API 方式 GlideApp.with(this).load(IMAGE_URL) .listener(new RequestListener<Drawable>() { @Override public boolean onLoadFailed(@Nullable GlideException e, Object model, Target<Drawable> target, boolean isFirstResource) { Toast.makeText(getApplicationContext(),"图片加载失败",Toast.LENGTH_SHORT).show(); return false; } @Override public boolean onResourceReady(Drawable resource, Object model, Target<Drawable> target, DataSource dataSource, boolean isFirstResource) { Toast.makeText(getApplicationContext(),"图片加载成功",Toast.LENGTH_SHORT).show(); return false; } }).into(mImageView); 复制代码- 能够看到监听实现的方法都有布尔类型的返回值，返回true，则表明处理了该回调事件，false则不进行处理，若是onResourceReady方法返回true，则into方法就不会执行，也就是图片不会加载到ImageView，同理onLoadFailed方法返回true，则error方法不会执行。
Glide还有其余的一些使用方法，这里就不继续展开了，有兴趣的能够自行继续研究。
Glide源码解析
Glide加载图片到ImageView基本流程图
Glide加载图片到ImageView源码分析
- 在上一节简单的列出了一些Glide的使用方法，能用不表明你已经懂了，接下来就经过理解源码的方式来对Glide是如何工做的作深一层次理解，首先从最简单使用开始
Glide.with(Context).load(IMAGE_URL).into(mImageView);
复制代码
with方法
- 来吧，开始是Glide的with()方法，直接上源码
/** Glide类的with()方法*/
@NonNull
public static RequestManager with(@NonNull Context context) {
return getRetriever(context).get(context);
}
@NonNull
public static RequestManager with(@NonNull Activity activity) {
return getRetriever(activity).get(activity);
}
@NonNull
public static RequestManager with(@NonNull FragmentActivity activity) {
return getRetriever(activity).get(activity);
}
@NonNull
public static RequestManager with(@NonNull Fragment fragment) {
return getRetriever(fragment.getActivity()).get(fragment);
}
@SuppressWarnings("deprecation")
@Deprecated
@NonNull
public static RequestManager with(@NonNull android.app.Fragment fragment) {
return getRetriever(fragment.getActivity()).get(fragment);
}
@NonNull
public static RequestManager with(@NonNull View view) {
return getRetriever(view.getContext()).get(view);
}
复制代码
- 经过源码，能够看到with有不一样参数类型的重载方法，每一个方法首先都是调用 getRetriever()方法
/** Glide类的getRetriever()方法*/
private static RequestManagerRetriever getRetriever(@Nullable Context context) {
// Context could be null for other reasons (ie the user passes in null), but in practice it will
// only occur due to errors with the Fragment lifecycle.
Preconditions.checkNotNull(
context,
"You cannot start a load on a not yet attached View or a Fragment where getActivity() "
+ "returns null (which usually occurs when getActivity() is called before the Fragment "
+ "is attached or after the Fragment is destroyed).");
return Glide.get(context).getRequestManagerRetriever();
}
复制代码
- Glide的get方法中经过new GlideBuilder()获取了Glide对象，并经过Glide的getRequestManagerRetriever()的方法最终获得RequestManagerRetriever对象，接下来咱们看看RequestManagerRetriever对象的get方法
/** RequestManagerRetriever类的get()方法*/
@NonNull
public RequestManager get(@NonNull Context context) {
if (context == null) {
throw new IllegalArgumentException("You cannot start a load on a null Context");
} else if (Util.isOnMainThread() && !(context instanceof Application)) {
if (context instanceof FragmentActivity) {
return get((FragmentActivity) context);
} else if (context instanceof Activity) {
return get((Activity) context);
} else if (context instanceof ContextWrapper) {
return get(((ContextWrapper) context).getBaseContext());
}
}
return getApplicationManager(context);
}
@NonNull
public RequestManager get(@NonNull FragmentActivity activity) {
if (Util.isOnBackgroundThread()) {
return get(activity.getApplicationContext());
} else {
assertNotDestroyed(activity);
FragmentManager fm = activity.getSupportFragmentManager();
return supportFragmentGet(
activity, fm, /*parentHint=*/ null, isActivityVisible(activity));
}
}
@NonNull
public RequestManager get(@NonNull Fragment fragment) {
Preconditions.checkNotNull(fragment.getActivity(),
"You cannot start a load on a fragment before it is attached or after it is destroyed");
if (Util.isOnBackgroundThread()) {
return get(fragment.getActivity().getApplicationContext());
} else {
FragmentManager fm = fragment.getChildFragmentManager();
return supportFragmentGet(fragment.getActivity(), fm, fragment, fragment.isVisible());
}
}
@SuppressWarnings("deprecation")
@NonNull
public RequestManager get(@NonNull Activity activity) {
if (Util.isOnBackgroundThread()) {
return get(activity.getApplicationContext());
} else {
assertNotDestroyed(activity);
android.app.FragmentManager fm = activity.getFragmentManager();
return fragmentGet(
activity, fm, /*parentHint=*/ null, isActivityVisible(activity));
}
}
@SuppressWarnings("deprecation")
@NonNull
public RequestManager get(@NonNull View view) {
if (Util.isOnBackgroundThread()) {
return get(view.getContext().getApplicationContext());
}
Preconditions.checkNotNull(view);
Preconditions.checkNotNull(view.getContext(),
"Unable to obtain a request manager for a view without a Context");
Activity activity = findActivity(view.getContext());
// The view might be somewhere else, like a service.
if (activity == null) {
return get(view.getContext().getApplicationContext());
}
// Support Fragments.
// Although the user might have non-support Fragments attached to FragmentActivity, searching
// for non-support Fragments is so expensive pre O and that should be rare enough that we
// prefer to just fall back to the Activity directly.
if (activity instanceof FragmentActivity) {
Fragment fragment = findSupportFragment(view, (FragmentActivity) activity);
return fragment != null ? get(fragment) : get(activity);
}
// Standard Fragments.
android.app.Fragment fragment = findFragment(view, activity);
if (fragment == null) {
return get(activity);
}
return get(fragment);
}
复制代码
- 一样，RequestManagerRetriever对象的get方法也有不一样类型参数的重载，分别针对Application、Activity、Fragmenet、view作了不一样的处理，先看Context参数的get方法，在该方法中它把Context的参数分红了两个类型，一个Application类型的Context，另外一个是非Application类型的Context。若是是Application类型的Context，则建立的Glide的生命周期则跟随ApplicationContext的生命周期，也就是下面的getApplicationManager所作的事情。
/** RequestManagerRetriever类的getApplicationManager()方法*/
@NonNull
private RequestManager getApplicationManager(@NonNull Context context) {
// Either an application context or we're on a background thread. if (applicationManager == null) { synchronized (this) { if (applicationManager == null) { // Normally pause/resume is taken care of by the fragment we add to the fragment or // activity. However, in this case since the manager attached to the application will not // receive lifecycle events, we must force the manager to start resumed using // ApplicationLifecycle. // TODO(b/27524013): Factor out this Glide.get() call. Glide glide = Glide.get(context.getApplicationContext()); applicationManager = factory.build( glide, new ApplicationLifecycle(), new EmptyRequestManagerTreeNode(), context.getApplicationContext()); } } } return applicationManager; } 复制代码
- 接着，若是是非Application类型的，Activity、Fragmenet属于非Application；若是是Activity类型的Context，当前再也不主线程，则继续跟随Application生命周期，不然给当前Activity添加一个隐藏的Fragment，而后Glide生命周期跟随这个隐藏的Fragment，分析到这里，咱们再看Fragmenet类型的Context，或者是View类型，也是添加了一个隐藏的Fragment。这是为何呢？首先Fragment的生命周期是和Activity同步的，Activity销毁Fragment也会销毁，其次，这也方便Glide知道本身何时须要中止加载，若是咱们打开一个Activity并关闭它，若是Glide生命周期跟随Application，则Activity虽然已经销毁，可是应用还没退出，则Glide还在继续加载图片，这显然是不合理的，而Glide很巧妙的用一个隐藏Fragment来解决生命周期的监听。
/** RequestManagerRetriever类的fragmentGet()方法*/
@SuppressWarnings({"deprecation", "DeprecatedIsStillUsed"})
@Deprecated
@NonNull
private RequestManager fragmentGet(@NonNull Context context,
@NonNull android.app.FragmentManager fm,
@Nullable android.app.Fragment parentHint,
boolean isParentVisible) {
RequestManagerFragment current = getRequestManagerFragment(fm, parentHint, isParentVisible);
RequestManager requestManager = current.getRequestManager();
if (requestManager == null) {
// TODO(b/27524013): Factor out this Glide.get() call.
Glide glide = Glide.get(context);
requestManager =
factory.build(
glide, current.getGlideLifecycle(), current.getRequestManagerTreeNode(), context);
current.setRequestManager(requestManager);
}
return requestManager;
}
/** RequestManagerRetriever类的getRequestManagerFragment()方法*/
@SuppressWarnings("deprecation")
@NonNull
private RequestManagerFragment getRequestManagerFragment(
@NonNull final android.app.FragmentManager fm,
@Nullable android.app.Fragment parentHint,
boolean isParentVisible) {
RequestManagerFragment current = (RequestManagerFragment) fm.findFragmentByTag(FRAGMENT_TAG);
if (current == null) {
current = pendingRequestManagerFragments.get(fm);
if (current == null) {
current = new RequestManagerFragment();
current.setParentFragmentHint(parentHint);
if (isParentVisible) {
current.getGlideLifecycle().onStart();
}
pendingRequestManagerFragments.put(fm, current);
fm.beginTransaction().add(current, FRAGMENT_TAG).commitAllowingStateLoss();
handler.obtainMessage(ID_REMOVE_FRAGMENT_MANAGER, fm).sendToTarget();
}
}
return current;
}
复制代码
- 通过对into方法的分析，最终获取的是跟随对应Context对象生命周期的RequestManager对象。
load方法
- 通过上一小节的分析，Glide.with方法最终获取的是RequestManager对象，因此继续看RequestManager对象里面load方法，
/** RequestManager 类的as()方法*/
@NonNull
@CheckResult
public <ResourceType> RequestBuilder<ResourceType> as(
@NonNull Class<ResourceType> resourceClass) {
return new RequestBuilder<>(glide, this, resourceClass, context);
}
/** RequestManager 类的as()方法*/
@NonNull
@CheckResult
public RequestBuilder<Drawable> asDrawable() {
return as(Drawable.class);
}
/** RequestManager 类的部分load()方法*/
@NonNull
@CheckResult
@Override
public RequestBuilder<Drawable> load(@Nullable Bitmap bitmap) {
return asDrawable().load(bitmap);
}
@NonNull
@CheckResult
@Override
public RequestBuilder<Drawable> load(@Nullable Drawable drawable) {
return asDrawable().load(drawable);
}
@NonNull
@CheckResult
@Override
public RequestBuilder<Drawable> load(@Nullable String string) {
return asDrawable().load(string);
}
//省略其余参数类型 load() 方法
.......
复制代码
- 经过以上load方法，能够发现虽然RequestManager对象的load方法有多个类型参数的重载，可是无论load方法传递什么类型参数，该方法都是调用RequestBuilder对象的load方法
/** RequestBuilder 类的load()方法*/
@NonNull
@CheckResult
@SuppressWarnings("unchecked")
@Override
public RequestBuilder<TranscodeType> load(@Nullable Object model) {
return loadGeneric(model);
}
/** RequestBuilder对象 类的loadGeneric()方法*/
@NonNull
private RequestBuilder<TranscodeType> loadGeneric(@Nullable Object model) {
this.model = model;
isModelSet = true;
return this;
}
复制代码
- 经过以上RequestBuilder对象的load()方法，咱们能够明白无论RequestManager对象的load方法方法传递什么类型的加载资源参数，RequestBuilder对象都把它当作时Object对象，并在loadGeneric方法中赋值给RequestBuilder对象的model对象。
- 经过查看RequestBuilder对象，咱们还注意到apply(RequestOptions)这个方法，前面咱们的例子中使用缓存，加载图像大小，设置加载占位符和错误占位符都须要新建RequestOptions对象，并设置咱们的配置，如今咱们分析的加载并无apply一个RequestOptions对象，则Glide会使用requestOptions.clone()去加载默认配置，这里就先不进行展开了，先继续关注接下来的into方法。
/** RequestBuilder 类的apply方法*/
@NonNull
@CheckResult
public RequestBuilder<TranscodeType> apply(@NonNull RequestOptions requestOptions) {
Preconditions.checkNotNull(requestOptions);
this.requestOptions = getMutableOptions().apply(requestOptions);
return this;
}
@SuppressWarnings("ReferenceEquality")
@NonNull
protected RequestOptions getMutableOptions() {
return defaultRequestOptions == this.requestOptions
? this.requestOptions.clone() : this.requestOptions;
}
复制代码
- 通过以上对with()方法和load方法的分析，通过这两步以后获得了RequestBuilder对象，也就说明真正的图片加载操做是在into方法来完成，也就是RequestBuilder对象的into方法。
into方法
- 经过上一小节的分析，通过load方法以后获取的对象是RequestBuilder，而且咱们将load方法的参数赋值给了RequestBuilder对象的model参数，接下来就到了Glide最核心的方法，也就是RequestBuilder对象的into方法
获取DrawableImageViewTarget
/** RequestBuilder 类的into方法*/
@NonNull
public ViewTarget<ImageView, TranscodeType> into(@NonNull ImageView view) {
Util.assertMainThread();
Preconditions.checkNotNull(view);
RequestOptions requestOptions = this.requestOptions;
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.
}
}
return into(
glideContext.buildImageViewTarget(view, transcodeClass),
/*targetListener=*/ null,
requestOptions);
}
复制代码
- RequestBuilder 对象的into方法中首先获取传递进来的ImageView的ScaleType，让Glide加载出来的ImageView保持同样的ScaleType变化，而后咱们看到最后一句话，该方法返回了RequestBuilder 对象的另外一个into方法，先看glideContext.buildImageViewTarget()作了什么操做
/** GlideContext 类的 buildImageViewTarget方法*/
@NonNull
public <X> ViewTarget<ImageView, X> buildImageViewTarget(
@NonNull ImageView imageView, @NonNull Class<X> transcodeClass) {
return imageViewTargetFactory.buildTarget(imageView, transcodeClass);
}
public class ImageViewTargetFactory {
@NonNull
@SuppressWarnings("unchecked")
public <Z> ViewTarget<ImageView, Z> buildTarget(@NonNull ImageView view,
@NonNull Class<Z> clazz) {
if (Bitmap.class.equals(clazz)) {
return (ViewTarget<ImageView, Z>) new BitmapImageViewTarget(view);
} else if (Drawable.class.isAssignableFrom(clazz)) {
return (ViewTarget<ImageView, Z>) new DrawableImageViewTarget(view);
} else {
//省略代码
.....
}
}
}
复制代码
- 经过以上源码，以前咱们看RequestBuilder源码中as方法传入的是Drawable.class，因此以上的buildImageViewTarget方法最终返回的是DrawableImageViewTarget对象，接着咱们继续看第一步into方法返回into方法中作了什么操做
构建Request
/** RequestBuilder 类的into方法返回的into方法*/
private <Y extends Target<TranscodeType>> Y into(
@NonNull Y target,
@Nullable RequestListener<TranscodeType> targetListener,
@NonNull RequestOptions options) {
Util.assertMainThread();
Preconditions.checkNotNull(target);
if (!isModelSet) {
throw new IllegalArgumentException("You must call #load() before calling #into()");
}
options = options.autoClone();
Request request = buildRequest(target, targetListener, options);
//省略部分代码
......
requestManager.clear(target);
target.setRequest(request);
requestManager.track(target, request);
return target;
}
复制代码
- 经过以上源码，咱们应该先明白Request类是一个接口，他抽象了Glide加载图片请求(Request类源码这里就不贴了)，它是一个很是重要的类，这里咱们先看看buildRequest(target, targetListener, options)方法是如何建立Request对象的
private Request buildRequest(
Target<TranscodeType> target,
@Nullable RequestListener<TranscodeType> targetListener,
RequestOptions requestOptions) {
return buildRequestRecursive(
target,
targetListener,
/*parentCoordinator=*/ null,
transitionOptions,
requestOptions.getPriority(),
requestOptions.getOverrideWidth(),
requestOptions.getOverrideHeight(),
requestOptions);
}
private Request buildRequestRecursive(
Target<TranscodeType> target,
@Nullable RequestListener<TranscodeType> targetListener,
@Nullable RequestCoordinator parentCoordinator,
TransitionOptions<?, ? super TranscodeType> transitionOptions,
Priority priority,
int overrideWidth,
int overrideHeight,
RequestOptions requestOptions) {
//省略部分代码 error Request build
.....
Request mainRequest =
buildThumbnailRequestRecursive(
target,
targetListener,
parentCoordinator,
transitionOptions,
priority,
overrideWidth,
overrideHeight,
requestOptions);
if (errorRequestCoordinator == null) {
return mainRequest;
}
//省略部分代码 error Request build
.....
}
private Request buildThumbnailRequestRecursive(
Target<TranscodeType> target,
RequestListener<TranscodeType> targetListener,
@Nullable RequestCoordinator parentCoordinator,
TransitionOptions<?, ? super TranscodeType> transitionOptions,
Priority priority,
int overrideWidth,
int overrideHeight,
RequestOptions requestOptions) {
if (thumbnailBuilder != null) {
//省略部分代码 缩略图操做
.....
} else {
// Base case: no thumbnail.
return obtainRequest(
target,
targetListener,
requestOptions,
parentCoordinator,
transitionOptions,
priority,
overrideWidth,
overrideHeight);
}
}
private Request obtainRequest(
Target<TranscodeType> target,
RequestListener<TranscodeType> targetListener,
RequestOptions requestOptions,
RequestCoordinator requestCoordinator,
TransitionOptions<?, ? super TranscodeType> transitionOptions,
Priority priority,
int overrideWidth,
int overrideHeight) {
return SingleRequest.obtain(
context,
glideContext,
model,
transcodeClass,
requestOptions,
overrideWidth,
overrideHeight,
priority,
target,
targetListener,
requestListeners,
requestCoordinator,
glideContext.getEngine(),
transitionOptions.getTransitionFactory());
}
复制代码
- 经过上面的源码，咱们能够看到buildRequest方法调用了buildRequestRecursive方法，在buildRequestRecursive方法中大部分代码都在处理缩略图（thumbnail），咱们主流程中没有设置缩略图，这里就不进行展开分析，接着buildRequestRecursive方法又调用了obtainRequest方法，obtainRequest方法传递了很是多参数，好比有咱们熟悉的RequestOptions，设置图片尺寸的 overrideWidth， overrideHeight，还有第一步into方法中的target对象，也就是DrawableImageViewTarget对象，model也就是咱们load传入的图片地址，也就说明无论load方法仍是apply方法传入的参数最终都给到了这里传入SingleRequest.obtain方法，咱们继续看看SingleRequest类
public final class SingleRequest<R> implements Request,
SizeReadyCallback,
ResourceCallback,
FactoryPools.Poolable {
//省略部分代码
......
/**SingleRequest类的 obtain方法*/
public static <R> SingleRequest<R> obtain(
Context context,
GlideContext glideContext,
Object model,
Class<R> transcodeClass,
RequestOptions requestOptions,
int overrideWidth,
int overrideHeight,
Priority priority,
Target<R> target,
RequestListener<R> targetListener,
@Nullable List<RequestListener<R>> requestListeners,
RequestCoordinator requestCoordinator,
Engine engine,
TransitionFactory<? super R> animationFactory) {
@SuppressWarnings("unchecked") SingleRequest<R> request =
(SingleRequest<R>) POOL.acquire();
if (request == null) {
request = new SingleRequest<>();
}
request.init(
context,
glideContext,
model,
transcodeClass,
requestOptions,
overrideWidth,
overrideHeight,
priority,
target,
targetListener,
requestListeners,
requestCoordinator,
engine,
animationFactory);
return request;
}
//省略部分代码
......
}
复制代码
- 经过SingleRequest对象的obtain方法，咱们能够看到request = new SingleRequest<>()；也就是最终咱们构建的Request是SingleRequest对象，并在init方法中将上一步obtainRequest方法传递进来的各类参数进行赋值。
Request执行
- 构建完成Request对象，接下来继续看刚刚的into方法下面的操做
requestManager.clear(target);
target.setRequest(request);
requestManager.track(target, request);
return target
复制代码
- 首先RequestManager对象清除target，此时不懂你是否还记得RequestManager，该对象是第一步with方法以后获得的，接着是将咱们上一步获得的SingleRequest对象设置给target，接着又执行了RequestManager.track方法，继续跟进该方法看看
/** RequestManager 类的track方法*/
void track(@NonNull Target<?> target, @NonNull Request request) {
targetTracker.track(target);
requestTracker.runRequest(request);
}
/** RequestTracker 类的runRequest方法*/
private final List<Request> pendingRequests = new ArrayList<>();
public void runRequest(@NonNull Request request) {
requests.add(request);
if (!isPaused) {
request.begin();
} else {
request.clear();
if (Log.isLoggable(TAG, Log.VERBOSE)) {
Log.v(TAG, "Paused, delaying request");
}
pendingRequests.add(request);
}
}
复制代码
- 经过上面的源码，RequestManager对象的track方法中执行了RequestTracker 类的runRequest方法，该方法中简单判断当前Glide是否在暂停状态，不是暂停状态则执行Request的begin方法，不然将这个Request加入到请求队列ListpendingRequests中.
后备回调符、加载占位符和错误占位符加载
- 接下来咱们看看Request的begin方法到底干了啥，要找到begin方法实现，根据前面分析，咱们则应该去看SingleRequest对象的begin方法
/** SingleRequest 类的begin方法*/
@Override
public void begin() {
assertNotCallingCallbacks();
stateVerifier.throwIfRecycled();
startTime = LogTime.getLogTime();
if (model == null) {
if (Util.isValidDimensions(overrideWidth, overrideHeight)) {
width = overrideWidth;
height = overrideHeight;
}
int logLevel = getFallbackDrawable() == null ? Log.WARN : Log.DEBUG;
onLoadFailed(new GlideException("Received null model"), logLevel);
return;
}
if (status == Status.RUNNING) {
throw new IllegalArgumentException("Cannot restart a running request");
}
if (status == Status.COMPLETE) {
onResourceReady(resource, DataSource.MEMORY_CACHE);
return;
}
status = Status.WAITING_FOR_SIZE;
if (Util.isValidDimensions(overrideWidth, overrideHeight)) {
onSizeReady(overrideWidth, overrideHeight);
} else {
target.getSize(this);
}
if ((status == Status.RUNNING || status == Status.WAITING_FOR_SIZE)
&& canNotifyStatusChanged()) {
target.onLoadStarted(getPlaceholderDrawable());
}
if (IS_VERBOSE_LOGGABLE) {
logV("finished run method in " + LogTime.getElapsedMillis(startTime));
}
}
private void onLoadFailed(GlideException e, int maxLogLevel) {
//省略部分代码
.......
if (!anyListenerHandledUpdatingTarget) {
setErrorPlaceholder();
}
//省略部分代码
.......
}
复制代码
- 经过以上begin方法源码，若是model为空，也就是咱们load传入的图片地址为空，则会调用onLoadFailed方法，而onLoadFailed方法又调用了setErrorPlaceholder方法，接着看看该方法中作了什么操做
/** SingleRequest 类的setErrorPlaceholder方法*/
private 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);
}
private Drawable getErrorDrawable() {
if (errorDrawable == null) {
errorDrawable = requestOptions.getErrorPlaceholder();
if (errorDrawable == null && requestOptions.getErrorId() > 0) {
errorDrawable = loadDrawable(requestOptions.getErrorId());
}
}
return errorDrawable;
}
复制代码
- 经过以上源码，若是咱们传入图片地址为空，则首先查看是否有后备回调符设置，而后是错误占位符，最后是加载占位符，最终调用target.onLoadFailed方法，也就是ImageViewTarget的onLoadFailed方法
public abstract class ImageViewTarget<Z> extends ViewTarget<ImageView, Z>implements Transition.ViewAdapter {
//省略部分代码
.......
public void setDrawable(Drawable drawable) {
view.setImageDrawable(drawable);
}
@Override
public void onLoadStarted(@Nullable Drawable placeholder) {
super.onLoadStarted(placeholder);
setResourceInternal(null);
setDrawable(placeholder);
}
@Override
public void onLoadFailed(@Nullable Drawable errorDrawable) {
super.onLoadFailed(errorDrawable);
setResourceInternal(null);
setDrawable(errorDrawable);
}
//省略部分代码
.......
}
复制代码
- 经过以上源码，我想你应该已经明白了后备回调符、错误占位符加载，这里还有一个疑问，加载占位符呢？咱们回到以前SingleRequest对象的begin方法，相信你会立刻看到在加载状态为RUNNING的时候调用了target.onLoadStarted，也实现了加载中的占位符，到这里咱们已经分析完了后备回调符、加载占位符和错误占位符加载底层实现逻辑。
加载图片网络请求
- 前面分析完各类占位符实现，咱们再次回到SingleRequest对象的begin方法，咱们能够注意到onSizeReady()和target.getSize()这两句就是加载图片的入口，若是咱们在使用glide的时候设置图片加载的大小尺寸，则会调用target.getSize()
/** ViewTarget 类的etSize方法*/
void getSize(@NonNull SizeReadyCallback cb) {
int currentWidth = getTargetWidth();
int currentHeight = getTargetHeight();
if (isViewStateAndSizeValid(currentWidth, currentHeight)) {
cb.onSizeReady(currentWidth, currentHeight);
return;
}
//省略部分代码
......
}
复制代码
- 经过以上源码，target.getSize()会根据ImageView的宽高来得出图片的加载宽高，最终target.getSize()仍是会调用onSizeReady()方法，因此咱们就直接来看看SingleRequest对象onSizeReady()方法中作了什么操做。
/** SingleRequest 类的onSizeReady方法*/
@Override
public void onSizeReady(int width, int height) {
stateVerifier.throwIfRecycled();
if (IS_VERBOSE_LOGGABLE) {
logV("Got onSizeReady in " + LogTime.getElapsedMillis(startTime));
}
if (status != Status.WAITING_FOR_SIZE) {
return;
}
status = Status.RUNNING;
float sizeMultiplier = requestOptions.getSizeMultiplier();
this.width = maybeApplySizeMultiplier(width, sizeMultiplier);
this.height = maybeApplySizeMultiplier(height, sizeMultiplier);
if (IS_VERBOSE_LOGGABLE) {
logV("finished setup for calling load in " + LogTime.getElapsedMillis(startTime));
}
loadStatus = engine.load(
glideContext,
model,
requestOptions.getSignature(),
this.width,
this.height,
requestOptions.getResourceClass(),
transcodeClass,
priority,
requestOptions.getDiskCacheStrategy(),
requestOptions.getTransformations(),
requestOptions.isTransformationRequired(),
requestOptions.isScaleOnlyOrNoTransform(),
requestOptions.getOptions(),
requestOptions.isMemoryCacheable(),
requestOptions.getUseUnlimitedSourceGeneratorsPool(),
requestOptions.getUseAnimationPool(),
requestOptions.getOnlyRetrieveFromCache(),
this);
// This is a hack that's only useful for testing right now where loads complete synchronously // even though under any executor running on any thread but the main thread, the load would // have completed asynchronously. if (status != Status.RUNNING) { loadStatus = null; } if (IS_VERBOSE_LOGGABLE) { logV("finished onSizeReady in " + LogTime.getElapsedMillis(startTime)); } } 复制代码
- 在onSizeReady方法中，主要调用了engine.load()方法并返回加载状态，engine.load方法继续接收咱们以前传入的各类参数，其中也有咱们model对象，也就是以前load方法传入的图片地址。首先咱们须要了解engine是什么，顾名思义，engine的英文意思是发动机，而在Glide框架中他就是负责启动图片加载的发动机，主要负责启动加载，咱们在前面with方法获取glide对象中获得了engine对象（这里就不贴源码了），咱们接着看engine.load()方法进行什么操做
/** Engine 类的load方法*/
public <R> LoadStatus load(GlideContext glideContext, Object model,Key signature,int width,int height,Class<?> resourceClass,Class<R> transcodeClass, Priority priority,DiskCacheStrategy diskCacheStrategy, Map<Class<?>, Transformation<?>> transformations,boolean isTransformationRequired,boolean isScaleOnlyOrNoTransform,Options options,boolean isMemoryCacheable,boolean useUnlimitedSourceExecutorPool,boolean useAnimationPool,boolean onlyRetrieveFromCache,ResourceCallback cb) {
Util.assertMainThread();
long startTime = VERBOSE_IS_LOGGABLE ? LogTime.getLogTime() : 0;
EngineKey key = keyFactory.buildKey(model, signature, width, height, transformations,
resourceClass, transcodeClass, options);
EngineResource<?> active = loadFromActiveResources(key, isMemoryCacheable);
if (active != null) {
cb.onResourceReady(active, DataSource.MEMORY_CACHE);
if (VERBOSE_IS_LOGGABLE) {
logWithTimeAndKey("Loaded resource from active resources", startTime, key);
}
return null;
}
EngineResource<?> cached = loadFromCache(key, isMemoryCacheable);
if (cached != null) {
cb.onResourceReady(cached, DataSource.MEMORY_CACHE);
if (VERBOSE_IS_LOGGABLE) {
logWithTimeAndKey("Loaded resource from cache", startTime, key);
}
return null;
}
EngineJob<?> current = jobs.get(key, onlyRetrieveFromCache);
if (current != null) {
current.addCallback(cb);
if (VERBOSE_IS_LOGGABLE) {
logWithTimeAndKey("Added to existing load", startTime, key);
}
return new LoadStatus(cb, current);
}
EngineJob<R> engineJob =
engineJobFactory.build(
key,
isMemoryCacheable,
useUnlimitedSourceExecutorPool,
useAnimationPool,
onlyRetrieveFromCache);
DecodeJob<R> decodeJob =
decodeJobFactory.build(
glideContext,
model,
key,
signature,
width,
height,
resourceClass,
transcodeClass,
priority,
diskCacheStrategy,
transformations,
isTransformationRequired,
isScaleOnlyOrNoTransform,
onlyRetrieveFromCache,
options,
engineJob);
jobs.put(key, engineJob);
engineJob.addCallback(cb);
engineJob.start(decodeJob);
if (VERBOSE_IS_LOGGABLE) {
logWithTimeAndKey("Started new load", startTime, key);
}
return new LoadStatus(cb, engineJob);
}
/** DecodeJob 类的继承关系*/
class DecodeJob<R> implements DataFetcherGenerator.FetcherReadyCallback,
Runnable,
Comparable<DecodeJob<?>>,
Poolable
复制代码
- 经过以上源码，Engine对象的load方前面一段代码都是在处理缓存问题，这里先不进行展开，继续走咱们加载图片的主线，往下看咱们看到构建了一个EngineJob对象，还构建了一个DecodeJob对象，构建DecodeJob对象又继续接收咱们以前传入的各类参数，由DecodeJob对象的继承关系咱们能够知道它是Runnable对象，接着咱们看到engineJob的start()方法，它直接传入了DecodeJob对象
/** EngineJob 类的start方法*/
public void start(DecodeJob<R> decodeJob) {
this.decodeJob = decodeJob;
GlideExecutor executor = decodeJob.willDecodeFromCache()
? diskCacheExecutor
: getActiveSourceExecutor();
executor.execute(decodeJob);
}
/** GlideExecutor 类的newSourceExecutor方法*/
public static GlideExecutor newSourceExecutor(
int threadCount, String name, UncaughtThrowableStrategy uncaughtThrowableStrategy) {
return new GlideExecutor(
new ThreadPoolExecutor(
threadCount /* corePoolSize */,
threadCount /* maximumPoolSize */,
0 /* keepAliveTime */,
TimeUnit.MILLISECONDS,
new PriorityBlockingQueue<Runnable>(),
new DefaultThreadFactory(name, uncaughtThrowableStrategy, false)));
}
复制代码
- 经过以上源码，EngineJob对象的start方法首先仍是判断缓存，最终获取的GlideExecutor就是一个线程池执行器（Executor），GlideExecutor中有各类方法得到缓存线程池，还有资源线程池（SourceExecutor），以上源码贴出资源线程池。实际上EngineJob对象的start方法就是用来在线程池中启动DecodeJob这个Runnable对象，也就是说EngineJob的主要做用是开启线程来加载图片，接着咱们来看看DecodeJob对象的run方法。
/** DecodeJob 类的run方法*/
public void run() {
DataFetcher<?> localFetcher = currentFetcher;
try {
if (isCancelled) {
notifyFailed();
return;
}
runWrapped();
} catch (Throwable t) {
//省略部分代码
.......
} finally {
if (localFetcher != null) {
localFetcher.cleanup();
}
GlideTrace.endSection();
}
}
/** DecodeJob 类的runWrapped方法*/
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);
}
}
/** DecodeJob 类的getNextStage方法*/
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);
}
}
/** DecodeJob 类的getNextGenerator方法*/
private DataFetcherGenerator getNextGenerator() {
switch (stage) {
case RESOURCE_CACHE:
return new ResourceCacheGenerator(decodeHelper, this);
case DATA_CACHE:
return new DataCacheGenerator(decodeHelper, this);
case SOURCE:
return new SourceGenerator(decodeHelper, this);
case FINISHED:
return null;
default:
throw new IllegalStateException("Unrecognized stage: " + stage);
}
/** DecodeJob 类的runGenerators方法*/
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;
}
}
//省略部分代码
.......
}
复制代码
- 上面咱们再次贴出了一堆代码，咱们来好好梳理一下逻辑，DecodeJob对象的run方法中逻辑很简单，就是调用了自身的runWrapped方法，runWrapped方法中首先判断Stage枚举，前面在建立DecodeJob对象时候设置初始状态为Stage.INITIALIZE，而后接着调用getNextStage方法，这里咱们仍是继续跳过缓存，因此getNextStage方法最终返回的是Stage.SOURCE状态，接着在getNextGenerator()方法中咱们获取就是SourceGenerator对象，也就是run方法中的第一句话DataFetcher<?> localFetcher = currentFetcher中localFetcher就是咱们刚刚得到的SourceGenerator对象，接着继续执行runGenerators()方法，在该方法的while循环判断条件执行了currentGenerator.startNext()方法，也就是SourceGenerator对象的startNext()方法
/** SourceGenerator 类的startNext()方法*/
@Override
public boolean startNext() {
//省略部分代码，跳过缓存部分判断
........
loadData = null;
boolean started = false;
while (!started && hasNextModelLoader()) {
loadData = helper.getLoadData().get(loadDataListIndex++);
if (loadData != null
&& (helper.getDiskCacheStrategy().isDataCacheable(loadData.fetcher.getDataSource())
|| helper.hasLoadPath(loadData.fetcher.getDataClass()))) {
started = true;
loadData.fetcher.loadData(helper.getPriority(), this);
}
}
return started;
}
/** DecodeHelper 类的getLoadData() 方法*/
List<LoadData<?>> getLoadData() {
if (!isLoadDataSet) {
isLoadDataSet = true;
loadData.clear();
List<ModelLoader<Object, ?>> modelLoaders = glideContext.getRegistry().getModelLoaders(model);
//noinspection ForLoopReplaceableByForEach to improve perf
for (int i = 0, size = modelLoaders.size(); i < size; i++) {
ModelLoader<Object, ?> modelLoader = modelLoaders.get(i);
LoadData<?> current =
modelLoader.buildLoadData(model, width, height, options);
if (current != null) {
loadData.add(current);
}
}
}
return loadData;
}
/** HttpGlideUrlLoader 类的buildLoadData 方法*/
@Override
public LoadData<InputStream> buildLoadData(@NonNull GlideUrl model, int width, int height,
@NonNull Options options) {
// GlideUrls memoize parsed URLs so caching them saves a few object instantiations and time
// spent parsing urls.
GlideUrl url = model;
if (modelCache != null) {
url = modelCache.get(model, 0, 0);
if (url == null) {
modelCache.put(model, 0, 0, model);
url = model;
}
}
int timeout = options.get(TIMEOUT);
return new LoadData<>(url, new HttpUrlFetcher(url, timeout));
}
复制代码
- 经过上面源码，咱们接着看到loadData=helper.getLoadData().get(loadDataListIndex++)这一句代码，helper就是DecodeHelper对象，在咱们前面建立DecodeJob对象的时候已经把它建立，以前咱们在load步骤中传入的model是图片url地址，因此通过DecodeHelper 类的getLoadData() 方法（更细的代码这里就不进行展开了），最终获取的ModelLoader<Object, ?> modelLoader对象则为HttpGlideUrlLoader对象，也就是laodData对象，因此modelLoader.buildLoadData建立则在HttpGlideUrlLoader对象的buildLoadData中实现，上方贴出的该方法源码中把咱们model赋值给GlideUrl对象，也就是将其做为URL地址来进行处理，则通过modelLoader.buildLoadData获取的loadData.fetcher则对应HttpUrlFetcher对象，因此loadData.fetcher.loadData调用的就是HttpUrlFetcher对象loadData方法，
/**HttpUrlFetcher类的loadData方法 **/
@Override
public void loadData(@NonNull Priority priority,
@NonNull DataCallback<? super InputStream> 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));
}
}
}
/**HttpUrlFetcher类的loadDataWithRedirects方法 **/
private InputStream loadDataWithRedirects(URL url, int redirects, URL lastUrl,
Map<String, String> headers) throws IOException {
if (redirects >= MAXIMUM_REDIRECTS) {
throw new HttpException("Too many (> " + MAXIMUM_REDIRECTS + ") redirects!");
} else {
// Comparing the URLs using .equals performs additional network I/O and is generally broken.
// See http://michaelscharf.blogspot.com/2006/11/javaneturlequals-and-hashcode-make.html.
try {
if (lastUrl != null && url.toURI().equals(lastUrl.toURI())) {
throw new HttpException("In re-direct loop");
}
} catch (URISyntaxException e) {
// Do nothing, this is best effort.
}
}
urlConnection = connectionFactory.build(url);
for (Map.Entry<String, String> headerEntry : headers.entrySet()) {
urlConnection.addRequestProperty(headerEntry.getKey(), headerEntry.getValue());
}
urlConnection.setConnectTimeout(timeout);
urlConnection.setReadTimeout(timeout);
urlConnection.setUseCaches(false);
urlConnection.setDoInput(true);
// Stop the urlConnection instance of HttpUrlConnection from following redirects so that
// redirects will be handled by recursive calls to this method, loadDataWithRedirects.
urlConnection.setInstanceFollowRedirects(false);
// Connect explicitly to avoid errors in decoders if connection fails.
urlConnection.connect();
// Set the stream so that it's closed in cleanup to avoid resource leaks. See #2352. stream = urlConnection.getInputStream(); if (isCancelled) { return null; } final int statusCode = urlConnection.getResponseCode(); if (isHttpOk(statusCode)) { return getStreamForSuccessfulRequest(urlConnection); } else if (isHttpRedirect(statusCode)) { String redirectUrlString = urlConnection.getHeaderField("Location"); if (TextUtils.isEmpty(redirectUrlString)) { throw new HttpException("Received empty or null redirect url"); } URL redirectUrl = new URL(url, redirectUrlString); // Closing the stream specifically is required to avoid leaking ResponseBodys in addition // to disconnecting the url connection below. See #2352. cleanup(); return loadDataWithRedirects(redirectUrl, redirects + 1, url, headers); } else if (statusCode == INVALID_STATUS_CODE) { throw new HttpException(statusCode); } else { throw new HttpException(urlConnection.getResponseMessage(), statusCode); } } 复制代码
- 经过以上源码，HttpUrlFetcher对象的loadData方法首先调用自身loadDataWithRedirects方法，接着咱们看到该方法源码，这里使用了HttpURLConnection来执行了网络请求，看到这里心里仍是有点开心的，前面看了这么多源码，终于看到Glide的网络请求了，开心以后还没完呢，还得接着往下看，执行完网络请求成功，loadDataWithRedirects方法中网络请求成功调用getStreamForSuccessfulRequest返回了一个InputStream流(记住这个InputStream，很关键)，而后执行了一个callback回调，而这个回调对象就是咱们以前在SourceGenerator对象中调用loadData方法传入SourceGenerator对象自己，因此callback.onDataReady()调用的就是SourceGenerator对象的onDataReady方法
/**SourceGenerator类的onDataReady方法 **/
@Override
public void onDataReady(Object data) {
DiskCacheStrategy diskCacheStrategy = helper.getDiskCacheStrategy();
if (data != null && diskCacheStrategy.isDataCacheable(loadData.fetcher.getDataSource())) {
dataToCache = data;
// We might be being called back on someone else's thread. Before doing anything, we should // reschedule to get back onto Glide's thread.
cb.reschedule();
} else {
cb.onDataFetcherReady(loadData.sourceKey, data, loadData.fetcher,
loadData.fetcher.getDataSource(), originalKey);
}
}
复制代码
- 经过以上源码，不走缓存的状况下则调用cb.onDataFetcherReady，这个cb也就是前面咱们new SourceGenerator对象传入的 DecodeJob对象，也就是调用DecodeJob对象onDataFetcherReady方法
/**DecodeJob类的onDataFetcherReady方法 **/
@Override
public void onDataFetcherReady(Key sourceKey, Object data, DataFetcher<?> fetcher,
DataSource dataSource, Key attemptedKey) {
this.currentSourceKey = sourceKey;
this.currentData = data;
this.currentFetcher = fetcher;
this.currentDataSource = dataSource;
this.currentAttemptingKey = attemptedKey;
if (Thread.currentThread() != currentThread) {
runReason = RunReason.DECODE_DATA;
callback.reschedule(this);
} else {
GlideTrace.beginSection("DecodeJob.decodeFromRetrievedData");
try {
decodeFromRetrievedData();
} finally {
GlideTrace.endSection();
}
}
}
复制代码
- 经过以上源码，onDataFetcherReady方法中将以前网络请求获得的流赋值给当前的DecodeJob对象的currentData，其余数据都赋值给对应字段，最终调用的是decodeFromRetrievedData方法
加载图片（解码，转码）
/**DecodeJob类的decodeFromRetrievedData方法 **/
private void decodeFromRetrievedData() {
if (Log.isLoggable(TAG, Log.VERBOSE)) {
logWithTimeAndKey("Retrieved data", startFetchTime,
"data: " + currentData
+ ", cache key: " + currentSourceKey
+ ", fetcher: " + currentFetcher);
}
Resource<R> resource = null;
try {
resource = decodeFromData(currentFetcher, currentData, currentDataSource);
} catch (GlideException e) {
e.setLoggingDetails(currentAttemptingKey, currentDataSource);
throwables.add(e);
}
if (resource != null) {
notifyEncodeAndRelease(resource, currentDataSource);
} else {
runGenerators();
}
}
/**DecodeJob类的decodeFromData方法 **/
private <Data> Resource<R> decodeFromData(DataFetcher<?> fetcher, Data data,
DataSource dataSource) throws GlideException {
try {
if (data == null) {
return null;
}
long startTime = LogTime.getLogTime();
Resource<R> result = decodeFromFetcher(data, dataSource);
if (Log.isLoggable(TAG, Log.VERBOSE)) {
logWithTimeAndKey("Decoded result " + result, startTime);
}
return result;
} finally {
fetcher.cleanup();
}
}
/**DecodeJob类的decodeFromFetcher方法 **/
private <Data> Resource<R> decodeFromFetcher(Data data, DataSource dataSource)
throws GlideException {
LoadPath<Data, ?, R> path = decodeHelper.getLoadPath((Class<Data>) data.getClass());
return runLoadPath(data, dataSource, path);
}
复制代码
- 经过以上源码，decodeFromRetrievedData方法调用了decodeFromFetcher方法，在该方法中首先经过decodeHelper.getLoadPath获取LoadPath对象，LoadPath对象实际上是根据咱们传入的处理数据来返回特定的数据解码转码处理器，咱们跟进decodeHelper.getLoadPath看看
/** DecodeHelper类的getLoadPath方法*/
<Data> LoadPath<Data, ?, Transcode> getLoadPath(Class<Data> dataClass) {
return glideContext.getRegistry().getLoadPath(dataClass, resourceClass, transcodeClass);
}
/** Registry类的getLoadPath方法*/
@Nullable
public <Data, TResource, Transcode> LoadPath<Data, TResource, Transcode> getLoadPath(
@NonNull Class<Data> dataClass, @NonNull Class<TResource> resourceClass,
@NonNull Class<Transcode> transcodeClass) {
//省略部分代码
.......
List<DecodePath<Data, TResource, Transcode>> decodePaths =
getDecodePaths(dataClass, resourceClass, transcodeClass);
if (decodePaths.isEmpty()) {
result = null;
} else {
result =
new LoadPath<>(
dataClass, resourceClass, transcodeClass, decodePaths, throwableListPool);
}
loadPathCache.put(dataClass, resourceClass, transcodeClass, result);
}
return result;
}
/** Registry类的getDecodePaths方法*/
@NonNull
private <Data, TResource, Transcode> List<DecodePath<Data, TResource, Transcode>> getDecodePaths(
@NonNull Class<Data> dataClass, @NonNull Class<TResource> resourceClass,
@NonNull Class<Transcode> transcodeClass) {
//省略部分代码，去除干扰
List<ResourceDecoder<Data, TResource>> decoders =
decoderRegistry.getDecoders(dataClass, registeredResourceClass);
ResourceTranscoder<TResource, Transcode> transcoder =
transcoderRegistry.get(registeredResourceClass, registeredTranscodeClass);
@SuppressWarnings("PMD.AvoidInstantiatingObjectsInLoops")
DecodePath<Data, TResource, Transcode> path =
new DecodePath<>(dataClass, registeredResourceClass, registeredTranscodeClass,
decoders, transcoder, throwableListPool);
decodePaths.add(path);
}
return decodePaths;
}
/** Registry类的getDecoders方法*/
public synchronized <T, R> List<ResourceDecoder<T, R>> getDecoders(@NonNull Class<T> dataClass,
@NonNull Class<R> resourceClass) {
List<ResourceDecoder<T, R>> result = new ArrayList<>();
for (String bucket : bucketPriorityList) {
List<Entry<?, ?>> entries = decoders.get(bucket);
if (entries == null) {
continue;
}
for (Entry<?, ?> entry : entries) {
if (entry.handles(dataClass, resourceClass)) {
result.add((ResourceDecoder<T, R>) entry.decoder);
}
}
}
// TODO: cache result list.
return result;
}
复制代码
- 经过以上源码，咱们接着前面跟进DecodeHelper.getLoadPath方法，它调用了Registry对象的getLoadPath方法，Registry对象的getLoadPath方法又调用了自身的getDecodePaths方法，如今我前面提到过得咱们网络请求获取的是InputStream流，因此上面源码getDecodePaths方法中Data泛型就是InputStream，在根据getDecoders方法遍历获得解码器ResourceDecoder能处理InputStream流的有StreamBitmapDecoder和StreamGifDecoder，StreamGifDecoder处理的是Gif，咱们这里处理图片就之能是StreamBitmapDecoder，它将InputStream流解码成bitmap，而后能将bitmap转换成Drawable的转码器ResourceTranscoder对象则是BitmapDrawableTranscoder，最后getDecodePaths将咱们刚刚分析获得的解码器和转码器传递给了新建的DecodePath对象，DecodePath对象就是用来帮助咱们进行解码和转码的。
- 接着咱们继续上一步的decodeFromFetcher方法，该方法返回的runLoadPath最终调用了上面得到的DecodePath对象的decode方法
/**DecodePath类的decode方法**/
public Resource<Transcode> decode(DataRewinder<DataType> rewinder, int width, int height,
@NonNull Options options, DecodeCallback<ResourceType> callback) throws GlideException {
Resource<ResourceType> decoded = decodeResource(rewinder, width, height, options);
Resource<ResourceType> transformed = callback.onResourceDecoded(decoded);
return transcoder.transcode(transformed, options);
}
/**DecodePath类的decodeResource方法**/
@NonNull
private Resource<ResourceType> decodeResource(DataRewinder<DataType> rewinder, int width,
int height, @NonNull Options options) throws GlideException {
List<Throwable> exceptions = Preconditions.checkNotNull(listPool.acquire());
try {
return decodeResourceWithList(rewinder, width, height, options, exceptions);
} finally {
listPool.release(exceptions);
}
}
/**DecodePath类的decodeResourceWithList方法**/
@NonNull
private Resource<ResourceType> decodeResourceWithList(DataRewinder<DataType> rewinder, int width,
int height, @NonNull Options options, List<Throwable> exceptions) throws GlideException {
Resource<ResourceType> result = null;
//省略部分代码
........
ResourceDecoder<DataType, ResourceType> decoder = decoders.get(i);
try {
DataType data = rewinder.rewindAndGet();
if (decoder.handles(data, options)) {
data = rewinder.rewindAndGet();
result = decoder.decode(data, width, height, options);
}
//省略部分代码
........
return result;
}
复制代码
- 经过以上源码，DecodePath对象的decode方法调用了decodeResource方法，decodeResource又调用了decodeResourceWithList方法，通过前面分析，decodeResourceWithList方法中得到的decoder就是前面提到的解码器StreamBitmapDecoder对象，因此咱们接着看StreamBitmapDecoder的decode方法
/**StreamBitmapDecoder类的decode方法**/
@Override
public Resource<Bitmap> decode(@NonNull InputStream source, int width, int height,
@NonNull Options options)
throws IOException {
// Use to fix the mark limit to avoid allocating buffers that fit entire images.
final RecyclableBufferedInputStream bufferedStream;
final boolean ownsBufferedStream;
if (source instanceof RecyclableBufferedInputStream) {
bufferedStream = (RecyclableBufferedInputStream) source;
ownsBufferedStream = false;
} else {
bufferedStream = new RecyclableBufferedInputStream(source, byteArrayPool);
ownsBufferedStream = true;
}
ExceptionCatchingInputStream exceptionStream =
ExceptionCatchingInputStream.obtain(bufferedStream);
MarkEnforcingInputStream invalidatingStream = new MarkEnforcingInputStream(exceptionStream);
UntrustedCallbacks callbacks = new UntrustedCallbacks(bufferedStream, exceptionStream);
try {
return downsampler.decode(invalidatingStream, width, height, options, callbacks);
} finally {
exceptionStream.release();
if (ownsBufferedStream) {
bufferedStream.release();
}
}
}
复制代码
- 经过以上源码，StreamBitmapDecoder的decode方法中只是对InputStream进行包装（装饰模式），可让Glide进行更多操做，最终调用了downsampler.decode，这个downsampler对象则是Downsampler对象（英文注释：Downsamples, decodes, and rotates images according to their exif orientation.），英文注释大体意思是对图像exif格式进行采样、解码和旋转。而咱们这里调用了它的decode方法，也就是对咱们前面包装的流进行解码
/**Downsampler类的decode方法**/
public Resource<Bitmap> decode(InputStream is, int requestedWidth, int requestedHeight,
Options options, DecodeCallbacks callbacks) throws IOException {
//省略部分代码
try {
Bitmap result = decodeFromWrappedStreams(is, bitmapFactoryOptions,
downsampleStrategy, decodeFormat, isHardwareConfigAllowed, requestedWidth,
requestedHeight, fixBitmapToRequestedDimensions, callbacks);
return BitmapResource.obtain(result, bitmapPool);
} finally {
releaseOptions(bitmapFactoryOptions);
byteArrayPool.put(bytesForOptions);
}
}
/**Downsampler类的decodeFromWrappedStreams方法**/
private Bitmap decodeFromWrappedStreams(InputStream is,
BitmapFactory.Options options, DownsampleStrategy downsampleStrategy,
DecodeFormat decodeFormat, boolean isHardwareConfigAllowed, int requestedWidth,
int requestedHeight, boolean fixBitmapToRequestedDimensions,
DecodeCallbacks callbacks) throws IOException {
//省略部分代码
.........
Bitmap downsampled = decodeStream(is, options, callbacks, bitmapPool);
callbacks.onDecodeComplete(bitmapPool, downsampled);
//省略部分代码
.........
Bitmap rotated = null;
if (downsampled != null) {
//缩放效正处理
downsampled.setDensity(displayMetrics.densityDpi);
rotated = TransformationUtils.rotateImageExif(bitmapPool, downsampled, orientation);
if (!downsampled.equals(rotated)) {
bitmapPool.put(downsampled);
}
}
return rotated;
}
/**Downsampler类的decodeStream方法**/
private static Bitmap decodeStream(InputStream is, BitmapFactory.Options options,
DecodeCallbacks callbacks, BitmapPool bitmapPool) throws IOException {
if (options.inJustDecodeBounds) {
is.mark(MARK_POSITION);
} else {
callbacks.onObtainBounds();
}
int sourceWidth = options.outWidth;
int sourceHeight = options.outHeight;
String outMimeType = options.outMimeType;
final Bitmap result;
TransformationUtils.getBitmapDrawableLock().lock();
try {
result = BitmapFactory.decodeStream(is, null, options);
} catch (IllegalArgumentException e) {
//省略部分代码
.........
return result;
}
复制代码
- 经过以上源码，Downsampler对象的decode方法首先调用了decodeFromWrappedStreams方法，在decodeFromWrappedStreams方法中又调用了decodeStream方法，在该方法中调用用了BitmapFactory.decodeStream，到这里咱们终于看到了Glide将InputStream流解析成了bitmap，而最终Downsampler对象的decode方法返回的Resource对象就是BitmapResource对象
- 通过前面的分析，Glide已经将InputStream解码完成，这时咱们还得再次回到DecodePath对象的decode方法，解码完成还需转码，这里再次贴一下ecodePath对象的decode方法，前面已经分析了转码器为BitmapDrawableTranscoder对象，因此咱们继续看BitmapDrawableTranscoder对象transcode作了什么操做
/**DecodePath类的decode方法**/
public Resource<Transcode> decode(DataRewinder<DataType> rewinder, int width, int height,
@NonNull Options options, DecodeCallback<ResourceType> callback) throws GlideException {
Resource<ResourceType> decoded = decodeResource(rewinder, width, height, options);
Resource<ResourceType> transformed = callback.onResourceDecoded(decoded);
return transcoder.transcode(transformed, options);
}
/**BitmapDrawableTranscoder类的transcode方法**/
public Resource<BitmapDrawable> transcode(@NonNull Resource<Bitmap> toTranscode,
@NonNull Options options) {
return LazyBitmapDrawableResource.obtain(resources, toTranscode);
}
/**LazyBitmapDrawableResource类的obtain方法**/
@Nullable
public static Resource<BitmapDrawable> obtain(
@NonNull Resources resources, @Nullable Resource<Bitmap> bitmapResource) {
if (bitmapResource == null) {
return null;
}
return new LazyBitmapDrawableResource(resources, bitmapResource);
}
复制代码
- 经过以上源码，BitmapDrawableTranscoder对象transcode方法最终返回了LazyBitmapDrawableResource对象，也就是将咱们解码拿到的BitmapResource对象转换成了LazyBitmapDrawableResource对象
到此，Glide整个图片解码转码已近完成，接着咱们再回到DecodeJob对象的decodeFromRetrievedData方法
图片显示
/**DecodeJob类的decodeFromRetrievedData方法**/
private void decodeFromRetrievedData() {
Resource<R> resource = null;
try {
resource = decodeFromData(currentFetcher, currentData, currentDataSource);
} catch (GlideException e) {
e.setLoggingDetails(currentAttemptingKey, currentDataSource);
throwables.add(e);
}
if (resource != null) {
notifyEncodeAndRelease(resource, currentDataSource);
} else {
runGenerators();
}
}
/**DecodeJob类的notifyEncodeAndRelease方法**/
private void notifyEncodeAndRelease(Resource<R> resource, DataSource dataSource) {
//省略部分代码
.....
Resource<R> result = resource;
//省略部分代码
.....
notifyComplete(result, dataSource);
stage = Stage.ENCODE;
//省略部分代码
.....
}
/**DecodeJob类的notifyComplete方法**/
private void notifyComplete(Resource<R> resource, DataSource dataSource) {
setNotifiedOrThrow();
callback.onResourceReady(resource, dataSource);
}
复制代码
- 经过以上源码，DecodeJob对象的decodeFromRetrievedData方法调用notifyEncodeAndRelease方法，将咱们上一步获取的LazyBitmapDrawableResource传入notifyComplete方法中，在notifyComplete调用了callback.onResourceReady，而这个callback对象就是EngineJob对象（它实现了DecodeJob.Callback接口），也许到这里你已经忘了EngineJob对象是什么，前面咱们开启线程执行加载的start方法就在EngineJob对象中，因此咱们去看看EngineJob对象的onResourceReady方法
private static final Handler MAIN_THREAD_HANDLER =
new Handler(Looper.getMainLooper(), new MainThreadCallback());
/**EngineJob类的onResourceReady方法**/
@Override
public void onResourceReady(Resource<R> resource, DataSource dataSource) {
this.resource = resource;
this.dataSource = dataSource;
MAIN_THREAD_HANDLER.obtainMessage(MSG_COMPLETE, this).sendToTarget();
}
/**EngineJob类的handleMessage方法**/
@Override
public boolean handleMessage(Message message) {
EngineJob<?> job = (EngineJob<?>) message.obj;
switch (message.what) {
case MSG_COMPLETE:
job.handleResultOnMainThread();
break;
case MSG_EXCEPTION:
job.handleExceptionOnMainThread();
break;
case MSG_CANCELLED:
job.handleCancelledOnMainThread();
break;
default:
throw new IllegalStateException("Unrecognized message: " + message.what);
}
return true;
}
/**EngineJob类的handleResultOnMainThread方法**/
@Synthetic
void handleResultOnMainThread() {
//省略部分代码
......
engineResource = engineResourceFactory.build(resource, isCacheable);
hasResource = true;
//省略部分代码
......
for (int i = 0, size = cbs.size(); i < size; i++) {
ResourceCallback cb = cbs.get(i);
if (!isInIgnoredCallbacks(cb)) {
engineResource.acquire();
cb.onResourceReady(engineResource, dataSource);
}
}
//省略部分代码
......
}
/**EngineJob类的addCallback方法**/
private final List<ResourceCallback> cbs = new ArrayList<>(2);
void addCallback(ResourceCallback cb) {
Util.assertMainThread();
stateVerifier.throwIfRecycled();
if (hasResource) {
cb.onResourceReady(engineResource, dataSource);
} else if (hasLoadFailed) {
cb.onLoadFailed(exception);
} else {
cbs.add(cb);
}
}
复制代码
- 经过以上源码，前面咱们在Engine类的Load方法中已经将SingleRequest这个对象经过EngineJob对象的addCallback方法加入到了cbs这个List当中，EngineJob对象的onResourceReady方法中将咱们加载好的图片对象经过Hanlder将数据又传递到了主线程（主线程更新UI），也就是handleResultOnMainThread方法中根据咱们刚刚的分析经过cb.onResourceReady将数据回调通知，cb对象就是SingleRequest对象，咱们接着看SingleRequest对象的onResourceReady回调方法
/**SingleRequest类的onResourceReady回调方法**/
@SuppressWarnings("unchecked")
@Override
public void onResourceReady(Resource<?> resource, DataSource dataSource) {
//省略部分代码
.......
Object received = resource.get();
//省略部分代码
.......
onResourceReady((Resource<R>) resource, (R) received, dataSource);
}
/**SingleRequest类的onResourceReady方法**/
private void onResourceReady(Resource<R> resource, R result, DataSource dataSource) {
//省略部分代码
.......
status = Status.COMPLETE;
this.resource = resource;
//省略部分代码
.......
if (!anyListenerHandledUpdatingTarget) {
Transition<? super R> animation =
animationFactory.build(dataSource, isFirstResource);
target.onResourceReady(result, animation);
}
}
//省略部分代码
.......
}
复制代码
经过以上源码，这时候咱们已经能够看到长征胜利的曙光了，SingleRequest对象的onResourceReady回调方法中调用了resource.get()，而这个resource就是前面咱们通过解码、转码获取的LazyBitmapDrawableResource对象，而后又调用了SingleRequest对象的onResourceReady私有方法，在该方法中又调用了target.onResourceReady方法，在咱们最开始进入into方法的时候咱们已经分析过建立的target对象就是DrawableImageViewTarget对象，它继承了抽象类ImageViewTarget，因此咱们看看抽象类ImageViewTarget的onResourceReady方法
/** LazyBitmapDrawableResource类的get()方法**/
@NonNull
@Override
public BitmapDrawable get() {
return new BitmapDrawable(resources, bitmapResource.get());
}
/** ImageViewTarget类的onResourceReady方法**/
@Override
public void onResourceReady(@NonNull Z resource, @Nullable Transition<? super Z> transition) {
if (transition == null || !transition.transition(resource, this)) {
setResourceInternal(resource);
} else {
maybeUpdateAnimatable(resource);
}
}
/** ImageViewTarget类的setResourceInternal方法**/
private void setResourceInternal(@Nullable Z resource) {
// Order matters here. Set the resource first to make sure that the Drawable has a valid and
// non-null Callback before starting it.
setResource(resource);
maybeUpdateAnimatable(resource);
}
protected abstract void setResource(@Nullable Z resource);
复制代码
- 经过以上源码，LazyBitmapDrawableResource对象的get()方法获取了BitmapDrawable（实际就是Drawable对象），ImageViewTarget对象的onResourceReady方法经过前面分析被调用，而后该方法再调用了ImageViewTarget对象setResourceInternal方法，setResourceInternal方法最终setResource方法，setResource在ImageViewTarget对象是抽象方法，它在DrawableImageViewTarget对象中实现，最后咱们看看DrawableImageViewTarget对象setResource方法
@Override
protected void setResource(@Nullable Drawable resource) {
view.setImageDrawable(resource);
}
复制代码
到此，咱们的万里长征终于结束了，Glide的简单加载图片流程已经分析完了。
最后说点
- 最后我仍是想要把那句简单的代码给贴出来
Glide.with(Context).load(IMAGE_URL).into(mImageView);
复制代码
-
就是这样一句简单的代码，它背后所走的逻辑却让人头皮发麻，此时我只想说一句话“read the fuck source code”。前面咱们只是分析了Glide简单的加载图片流程，它的缓存使用，回调等功能原理还没分析到，这只能等到下篇文章了。文章中若是有错误，请你们给我提出来，你们一块儿学习进步，若是以为个人文章给予你帮助，也请给我一个喜欢和关注，同时也欢迎访问个人我的博客。
-
对本文感兴趣的朋友请继续阅读从源码角度深刻理解Glide（下）
-
参考连接
相关文章
- 1. 从源码角度深刻理解Glide4（下）
- 2. 从源码角度深刻理解Retrofit2
- 3. 从源码角度深刻理解OKHttp3
- 4. 从源码角度深刻理解Handler处理机制
- 5. 从源码角度深刻分析ant
- 6. 从Java角度深刻理解Kotlin
- 7. 从 Java 角度深刻理解 Kotlin
- 8. Android 源码系列之<四>从源码的角度深刻理解LayoutInflater.Factory之主题切换(上)
- 9. 从源码角度理解postInvalidate和Invalidate
- 10. 从源码角度完全理解ReentrantLock
- 更多相关文章...
- • TCP滑动窗口机制深度剖析 - TCP/IP教程
- • PHP 获取图像宽度与高度 - PHP参考手册
- • 算法总结-深度优先算法
- • Scala 中文乱码解决
相关标签/搜索
每日一句
-
每一个你不满意的现在，都有一个你没有努力的曾经。
最新文章
- 1. Duang!超快Wi-Fi来袭
- 2. 机器学习-补充03 神经网络之**函数(Activation Function)
- 3. git上开源maven项目部署 多module maven项目（多module maven+redis+tomcat+mysql）后台部署流程学习记录
- 4. ecliple-tomcat部署maven项目方式之一
- 5. eclipse新导入的项目经常可以看到“XX cannot be resolved to a type”的报错信息
- 6. Spark RDD的依赖于DAG的工作原理
- 7. VMware安装CentOS-8教程详解
- 8. YDOOK：Java 项目 Spring 项目导入基本四大 jar 包 导入依赖，怎样在 IDEA 的项目结构中导入 jar 包 导入依赖
- 9. 简单方法使得putty（windows10上）可以免密登录树莓派
- 10. idea怎么用本地maven
欢迎关注本站公众号,获取更多信息
