前言

前面幾片文章主要介紹了下Picasso，相對來說Picasso源碼看起來會比較輕松，所以如果想研究圖片框架的話，建議先從Picasso下手，這樣會比較容易。

源碼分析

今天只分析最簡單的一行代碼，后面會慢慢深入。 雖然只有一行代碼，但是里面的整個邏輯確實非常復雜。

Glide.with(this).load("http://i.imgur.com/DvpvklR.png").into(ivTest) 復制代碼

對，這應該也是我們使用Glide時候最常用的一句代碼，下面我們就一步步跟入。

with

//------Glide.java------//with重載方法有很多，這里先講一個public static RequestManager with(@NonNull FragmentActivity activity) {return getRetriever(activity).get(activity);}private static RequestManagerRetriever getRetriever(@Nullable Context context) {return Glide.get(context).getRequestManagerRetriever();} 復制代碼

第一次觸發Glide.get方法，默認創建一個Glide對象，如下

public static Glide get(@NonNull Context context) {if (glide == null) {synchronized (Glide.class) {if (glide == null) {checkAndInitializeGlide(context);}}}return glide;}private static void checkAndInitializeGlide(@NonNull Context context) {isInitializing = true;initializeGlide(context);isInitializing = false;}private static void initializeGlide(@NonNull Context context) {initializeGlide(context, new GlideBuilder());}//一步步往下看，就到了這里，真正開始創建Glide對象的方法 private static void initializeGlide(@NonNull Context context, @NonNull GlideBuilder builder) {....//這里代碼很多，都省略，直接看最關鍵的一個方法，buildGlide glide = builder.build(applicationContext);....Glide.glide = glide;} 復制代碼

以上是查找的過程的代碼，不是特別重要，下面是GlideBuilder的build方法，非常重要。

Glide build(@NonNull Context context) {if (sourceExecutor == null) {sourceExecutor = GlideExecutor.newSourceExecutor();}if (diskCacheExecutor == null) {diskCacheExecutor = GlideExecutor.newDiskCacheExecutor();}if (animationExecutor == null) {animationExecutor = GlideExecutor.newAnimationExecutor();}if (memorySizeCalculator == null) {memorySizeCalculator = new MemorySizeCalculator.Builder(context).build();}if (connectivityMonitorFactory == null) {connectivityMonitorFactory = new DefaultConnectivityMonitorFactory();}if (bitmapPool == null) {int size = memorySizeCalculator.getBitmapPoolSize();if (size > 0) {bitmapPool = new LruBitmapPool(size);} else {bitmapPool = new BitmapPoolAdapter();}}if (arrayPool == null) {arrayPool = new LruArrayPool(memorySizeCalculator.getArrayPoolSizeInBytes());}if (memoryCache == null) {memoryCache = new LruResourceCache(memorySizeCalculator.getMemoryCacheSize());}if (diskCacheFactory == null) {diskCacheFactory = new InternalCacheDiskCacheFactory(context);}if (engine == null) {engine =new Engine(memoryCache,diskCacheFactory,diskCacheExecutor,sourceExecutor,GlideExecutor.newUnlimitedSourceExecutor(),GlideExecutor.newAnimationExecutor(),isActiveResourceRetentionAllowed);}RequestManagerRetriever requestManagerRetriever =new RequestManagerRetriever(requestManagerFactory);return new Glide(context,engine,memoryCache,bitmapPool,arrayPool,requestManagerRetriever,connectivityMonitorFactory,logLevel,defaultRequestOptions.lock(),defaultTransitionOptions);} 復制代碼

Glide對象里面存的東西很多，上面初始化了很多重要的東西，先不深入去看，但是根據名字也能大概的猜到對象的作用。

sourceExecutor 獲取源數據線程池

diskCacheExecutor 獲取diskcache線程池

animationExecutor 應該是跟動畫有關的線程池

memorySizeCalculator 應該是個工具類，來計算內存的大小

connectivityMonitorFactory 應該是連接監聽的一個工廠類

bitmapPool 存放bitmap的池

arrayPool 存放數組的池

memoryCache 資源緩存對象

diskCacheFactory disk cache工廠類

requestManagerRetriever requestManager訓練器

大概就這樣一個初步的印象，可能不正確，后面可以慢慢驗證。 下面繼續回到剛才的with的方法。

@NonNullprivate static RequestManagerRetriever getRetriever(@Nullable Context context) {return Glide.get(context).getRequestManagerRetriever();} 復制代碼

這里的getRequestManagerRetriever，其實就是build方法中直接new出來的RequestManagerRetriever

public static RequestManager with(@NonNull FragmentActivity activity) {return getRetriever(activity).get(activity);} 復制代碼

所以我們再跟進去看下RequestManagerRetriever的get方法

@NonNullpublic 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));}} ...@NonNullprivate RequestManager supportFragmentGet(@NonNull Context context,@NonNull FragmentManager fm,@Nullable Fragment parentHint,boolean isParentVisible) {//創建一個SupportRequestManagerFragment，來獲取生命周期的狀態，來對圖片進行管理（這個后面再深入，這里可以簡單理解為，就是為了利用Fragment的生命周期）SupportRequestManagerFragment current =getSupportRequestManagerFragment(fm, parentHint, isParentVisible);RequestManager requestManager = current.getRequestManager();//剛開始創建的SupportRequestManagerFragment的requestManager==nullif (requestManager == null) {Glide glide = Glide.get(context);requestManager =factory.build(glide, current.getGlideLifecycle(), current.getRequestManagerTreeNode(), context);current.setRequestManager(requestManager);}return requestManager;} 復制代碼

get方法有很多重載，這里我們就以參數為FragmentActivity為例子。 get方法主要是為了創建RequestManager.

回過頭再看Glide.with(this).load("http://i.imgur.com/DvpvklR.png").into(ivTest), 接下來就是調用了RequestManager對象的load方法

public RequestBuilder<Drawable> load(@Nullable String string) {return asDrawable().load(string);} ... @NonNull@CheckResultpublic RequestBuilder<Drawable> asDrawable() {return as(Drawable.class);} ...//調用了as方法，其實主要就是創建一個RequestBuilder對象，然后傳入最終要轉換成的資源類型，顯然默認是轉換為Drawable.class@NonNull@CheckResultpublic <ResourceType> RequestBuilder<ResourceType> as(@NonNull Class<ResourceType> resourceClass) {return new RequestBuilder<>(glide, this, resourceClass, context);} ...@NonNull@Override@CheckResultpublic RequestBuilder<TranscodeType> load(@Nullable String string) {return loadGeneric(string);} ...//調用load方法傳入url地址時，并沒有真正的去發生請求獲取到圖片，只是設置了一個參數 @NonNullprivate RequestBuilder<TranscodeType> loadGeneric(@Nullable Object model) {this.model = model;isModelSet = true;return this;} 復制代碼

這里的代碼其實比較簡單，沒有什么好介紹的，簡單的說就是使用了建造者模式，然后創建了一個新的對象RequestBuilder，然后傳入一些參數。既然是建造者模式，那么最后RequestBuilder肯定會生成一個Request。

接下來再回頭看

Glide.with(this).load("http://i.imgur.com/DvpvklR.png").into(ivTest) 復制代碼

下面就應該是調用RequestBuilder的into方法了

@NonNullpublic ViewTarget<ImageView, TranscodeType> into(@NonNull ImageView view) {...return into(glideContext.buildImageViewTarget(view, transcodeClass),/*targetListener=*/ null,requestOptions);} ... private <Y extends Target<TranscodeType>> Y into(@NonNull Y target,@Nullable RequestListener<TranscodeType> targetListener,@NonNull RequestOptions options) {...Request request = buildRequest(target, targetListener, options);//獲取到當前target綁定的request請求，如果現在正在運行的這個請求跟這個target之前綁定的請求是一樣的話，//就判斷下之前的請求是否有再運行，沒有運行就開始運行，有運行就不操作。并且回收當前要運行的Request對象Request previous = target.getRequest();if (request.isEquivalentTo(previous)&& !isSkipMemoryCacheWithCompletePreviousRequest(options, previous)) {request.recycle();...if (!Preconditions.checkNotNull(previous).isRunning()) {...previous.begin();}return target;}requestManager.clear(target);//讓target跟request綁定target.setRequest(request);//這里才是正在發起請求的地方requestManager.track(target, request);return target;} 復制代碼

into方法中有2句比較關鍵的地方，這里提取出來單獨來講。

1. Request request = buildRequest(target, targetListener, options); 2. requestManager.track(target, request); 復制代碼

先看1，在RequestBuilder中調用buildRequest，構建一個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) {...Request mainRequest =buildThumbnailRequestRecursive(target,targetListener,parentCoordinator,transitionOptions,priority,overrideWidth,overrideHeight,requestOptions);...return errorRequestCoordinator;} ...//顧名思義，創建一個縮略圖的Request，先判斷是否有設置縮放的一些熟悉 //如果沒有，就獲取一個沒有縮放的Request 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 if (thumbSizeMultiplier != null) {...Request thumbnailRequest =obtainRequest(target,targetListener,thumbnailOptions,coordinator,transitionOptions,getThumbnailPriority(priority),overrideWidth,overrideHeight);coordinator.setRequests(fullRequest, thumbnailRequest);return coordinator;} else {return obtainRequest(target,targetListener,requestOptions,parentCoordinator,transitionOptions,priority,overrideWidth,overrideHeight);}}//繞了半天，這里才是真正創建一個Request的地方 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());} 復制代碼

看一些優秀的三方源碼，總是這樣，方法重載很多，方法參數很多，很容易暈，大家要一步步往里面跟，總能看懂的。

這里我們最后找到的是創建了一個SingleRequest對象。當然如果說你在 Glide.with(this).load("http://i.imgur.com/DvpvklR.png").into(ivTest)設置了一些寬高，或者是縮放的屬性，那么走的分支可能就不是這個。后面我們再分析。先從最簡單的分支入手，一步步解析。

接下來我們繼續看第2句關鍵的代碼

requestManager.track(target, request); 復制代碼void track(@NonNull Target<?> target, @NonNull Request request) {...requestTracker.runRequest(request);}public void runRequest(@NonNull Request request) {requests.add(request);if (!isPaused) {//正常情況isPaused=false，走這個分支，開始請求request.begin();} else {request.clear();if (Log.isLoggable(TAG, Log.VERBOSE)) {Log.v(TAG, "Paused, delaying request");}pendingRequests.add(request);}} ...public void begin() {...status = Status.WAITING_FOR_SIZE;//這里先判斷overrideWidth，overrideHeight是否合法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());}...}復制代碼

我們這里直接看到begin方法

private static boolean isValidDimension(int dimen) {return dimen > 0 || dimen == Target.SIZE_ORIGINAL;} 復制代碼

由于我們并沒有設置寬高，所以返回false，走下面分支

target.getSize(this);public void getSize(@NonNull SizeReadyCallback cb) {sizeDeterminer.getSize(cb);}void getSize(@NonNull SizeReadyCallback cb) {int currentWidth = getTargetWidth();int currentHeight = getTargetHeight();if (isViewStateAndSizeValid(currentWidth, currentHeight)) {cb.onSizeReady(currentWidth, currentHeight);return;}if (!cbs.contains(cb)) {cbs.add(cb);}if (layoutListener == null) {ViewTreeObserver observer = view.getViewTreeObserver();layoutListener = new SizeDeterminerLayoutListener(this);observer.addOnPreDrawListener(layoutListener);}} 復制代碼

這里比較關鍵的就是target.getSize(this);方法中的參數this，這里的this是一個SizeReadyCallback . 而SingleRequest實現了SizeReadyCallback

這里就是等待layout布局后，ImageView有了width和height后就會進入SingleRequest的onSizeReady回調方法。

主要的通過

ViewTreeObserver observer = view.getViewTreeObserver();layoutListener = new SizeDeterminerLayoutListener(this);observer.addOnPreDrawListener(layoutListener); 復制代碼

這3句來監聽ImageView的布局之后的一個回調，也就是有了width和height之后的回調。

如果我們本身設置了縮放，或者是寬高屬性，那么Glide就會直接使用width和height當作參數，調用 onSizeReady.下面我們直接看。

public void onSizeReady(int width, int height) {...if (status != Status.WAITING_FOR_SIZE) {return;}status = Status.RUNNING;float sizeMultiplier = requestOptions.getSizeMultiplier();this.width = maybeApplySizeMultiplier(width, sizeMultiplier);this.height = maybeApplySizeMultiplier(height, sizeMultiplier);...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);...if (status != Status.RUNNING) {loadStatus = null;}...} 復制代碼

這里比較關鍵的地方

狀態的切換

調用engine.load

第1點就不說了，直接看上面代碼就好。 直接看第2點engine.load 我們首先看下engine這個對象是在哪里初始化的。

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());} 復制代碼

可以看出來是前面構建SingleRequest對象的時候glideContext.getEngine()傳入的一個參數。

glideContext =new GlideContext(context,arrayPool,registry,imageViewTargetFactory,defaultRequestOptions,defaultTransitionOptions,engine,logLevel); 復制代碼

而glideContext中的engine也是參數傳入的。 最終找到

@NonNullGlide build(@NonNull Context context) {...if (engine == null) {engine =new Engine(memoryCache,diskCacheFactory,diskCacheExecutor,sourceExecutor,GlideExecutor.newUnlimitedSourceExecutor(),GlideExecutor.newAnimationExecutor(),isActiveResourceRetentionAllowed);}...return new Glide(context,engine,memoryCache,bitmapPool,arrayPool,requestManagerRetriever,connectivityMonitorFactory,logLevel,defaultRequestOptions.lock(),defaultTransitionOptions);} 復制代碼

是在創建Glide的時候new出來的一個Engine，不自己傳入的話，會默認構建一個。然后供后面使用。 下面我們繼續看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) {...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);...return new LoadStatus(cb, engineJob);} 復制代碼

代碼很多，我們就看重點幾個地方。 先通過參數，生成key，通過key，去獲取緩存數據，如果有緩存就直接調用SingleRequest的onResourceReady方法。

//生成key，其實可以理解為就是一個字符串，然后key-value，獲取到對應的緩存EngineKey key = keyFactory.buildKey(model, signature, width, height, transformations,resourceClass, transcodeClass, options); //然后調用 loadFromActiveResources //然后調用 loadFromCache復制代碼

如果緩存中都沒有數據，那么就繼續下面

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);}復制代碼

先從jobs里面通過key獲取前面已經加入的EngineJob。如果有，就直接current.addCallback(cb);。 意思就是說，前面如果已經執行過一個任務了，就會把任務添加到jobs，如果后面遇到相同的任務了，就直接在jobs里面獲取，可以把jobs就認為是一個HashMap，根據key來保存。

如果說，是第一次運行任務，也就是加載圖片，那么current==null，繼續往下走。

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);...return new LoadStatus(cb, engineJob); 復制代碼

創建2個對象，EngineJob和DecodeJob。 jobs.put(key, engineJob);這里是為了后面如果是加載相同的圖片的話，這里會直接獲取到EngineJob然后去處理，而不是每次都新建一個。

接下來繼續engineJob.start(decodeJob);

public void start(DecodeJob<R> decodeJob) {this.decodeJob = decodeJob;GlideExecutor executor = decodeJob.willDecodeFromCache()? diskCacheExecutor: getActiveSourceExecutor();executor.execute(decodeJob);} ... boolean willDecodeFromCache() {Stage firstStage = getNextStage(Stage.INITIALIZE);return firstStage == Stage.RESOURCE_CACHE || firstStage == Stage.DATA_CACHE;} 復制代碼

這里判斷了下是使用diskCacheExecutor還是getActiveSourceExecutor()， 其實第一次看源碼的時候，我們可以先來走一遍完整的流程，這2者具體的區別我們先不要太在意。

這2者其實都是一個ExecutorService，是用來處理線程的。

那我們繼續。

class DecodeJob<R> implements DataFetcherGenerator.FetcherReadyCallback,Runnable,Comparable<DecodeJob<?>>,Poolable 復制代碼

DecodeJob實現了Runnable接口 這里調用

executor.execute(decodeJob); 復制代碼

其實就是在線程池中找一個線程來執行decodeJob中的run方法。

@Overridepublic void run() {...DataFetcher<?> localFetcher = currentFetcher;try {if (isCancelled) {notifyFailed();return;}runWrapped();} catch (Throwable t) {...} }//通過狀態來獲取不同的生成器，來生成資源 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 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);}} 復制代碼

上面最重要的方法就是runWrappeed。 主要3點。

獲取當前狀態的下一個狀態，然后賦值給當前狀態

獲取與當前匹配的Generator

運行生成器來獲取資源。

我們先來看第一點，也就是getNextStage方法，通過當前狀態，來獲取后面的一個狀態。其實很簡單。 狀態的順序就是

INITIALIZE(初始化)-> RESOURCE_CACHE(獲取內存緩存)-> DATA_CACHE(獲取磁盤緩存)-> SOURCE(真正去請求資源)-> FINISHED(完成) 復制代碼

正常情況下，就會按這樣步驟一個個來，但是有些時候我們會設置不緩存的一些參數，那么就會跳過某個步驟。

在代碼中也有體現

case INITIALIZE:return diskCacheStrategy.decodeCachedResource()? Stage.RESOURCE_CACHE : getNextStage(Stage.RESOURCE_CACHE); 復制代碼

初始化后應該是從獲取資源緩存，但是diskCacheStrategy.decodeCachedResource()返回false的話，那么就直接獲取getNextStage(Stage.RESOURCE_CACHE)，也就是資源緩存的下一個狀態。

DiskCacheStrategy代表緩存的策略，一共有

DiskCacheStrategy.ALL

DiskCacheStrategy.NONE

DiskCacheStrategy.DATA

DiskCacheStrategy.RESOURCE

DiskCacheStrategy.AUTOMATIC

我們這里來看下DiskCacheStrategy.NONE

public static final DiskCacheStrategy NONE = new DiskCacheStrategy() {public boolean isDataCacheable(DataSource dataSource) {return false;}public boolean isResourceCacheable(boolean isFromAlternateCacheKey, DataSource dataSource, EncodeStrategy encodeStrategy) {return false;}public boolean decodeCachedResource() {return false;}public boolean decodeCachedData() {return false;}}; 復制代碼

這里就都返回false。不允許獲取緩存數據。

下面來看第2點，獲取Generator

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);}} 復制代碼

通過不同的stage獲取到不同的Generator。一開始獲取到ResourceCacheGenerator。

下面看第3點，runGenerators

private void runGenerators() {...while (!isCancelled && currentGenerator != null&& !(isStarted = currentGenerator.startNext())) {stage = getNextStage(stage);currentGenerator = getNextGenerator();if (stage == Stage.SOURCE) {reschedule();return;}}} 復制代碼

這里代碼很簡單，取消的情況先不考慮,主要是這句代碼

!(isStarted = currentGenerator.startNext()) 復制代碼

Generator中注冊了很多ModelLoader<File, ?>，ModelLoader<File, ?>可以生成對應的處理資源的LoadData, 不同的LoadData只能加載自己能加載到的資源。

public boolean startNext() {...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;} 復制代碼

最終調用的是LoadData的fetcher的loadData方法。 這里的fetcher是HttpUrlFetcher(為什么是這個后面可以再深入講，先走完整個流程)。

public void loadData(@NonNull Priority priority,@NonNull DataCallback<? super InputStream> callback) {...InputStream result = loadDataWithRedirects(glideUrl.toURL(), 0, null, glideUrl.getHeaders());callback.onDataReady(result);...} 復制代碼

loadDataWithRedirects這個方法就不深入介紹了，使用了HttpURLConnection去請求資源。 請求完成后，調用了onDataReady方法，把結果往上傳。

這里我們就要一步步往上找到回調方法。

首先剛才在SourceGenerator調用的

loadData.fetcher.loadData(helper.getPriority(), this); 復制代碼

會發現，參數 DataCallback就是SourceGenerator。

所以回調的其實是SourceGenerator的onDataReady方法

@Overridepublic void onDataReady(Object data) {...dataToCache = data;cb.reschedule();...} 復制代碼

這里又有一個cb也就是Callback，繼續往前找，發現是DecodeJob, 所以這里又調用了，DecodeJob.reschedule();

public void reschedule() {runReason = RunReason.SWITCH_TO_SOURCE_SERVICE;callback.reschedule(this);} 復制代碼

DecodeJob中又調用了callback.reschedule,其實這里的callback是EngineJob。很多優秀的三方庫就是這樣，繞來繞去的，看起來比較費勁。

@Overridepublic void reschedule(DecodeJob<?> job) {getActiveSourceExecutor().execute(job);} 復制代碼

這里會發現一個很奇怪的東西，因為在前面我們已經介紹過了，入口就是執行DecodeJob的run方法，然后執行完成之后一步步回調，這里竟然又去執行DecodeJob的run，死循環么，當然不是，我們繼續往下看。

之后的流程跟前面都一樣，這里就不再贅述了，然后又到了SourceGenerator的startNext方法

public boolean startNext() {if (dataToCache != null) {Object data = dataToCache;dataToCache = null;cacheData(data);}if (sourceCacheGenerator != null && sourceCacheGenerator.startNext()) {return true;}..return started;} ... private void cacheData(Object dataToCache) {...sourceCacheGenerator =new DataCacheGenerator(Collections.singletonList(loadData.sourceKey), helper, this);} 復制代碼

這個時候跟之前就不一樣了，因為數據請求已經回來了，dataToCache!=null，然后調用cacheData方法，把數據緩存起來。 調用cacheData方法之后，最后創建了一個DataCacheGenerator。然后調用startNext方法。

public boolean startNext() {while (modelLoaders == null || !hasNextModelLoader()) {sourceIdIndex++;if (sourceIdIndex >= cacheKeys.size()) {return false;}Key sourceId = cacheKeys.get(sourceIdIndex);@SuppressWarnings("PMD.AvoidInstantiatingObjectsInLoops")Key originalKey = new DataCacheKey(sourceId, helper.getSignature());cacheFile = helper.getDiskCache().get(originalKey);if (cacheFile != null) {this.sourceKey = sourceId;modelLoaders = helper.getModelLoaders(cacheFile);modelLoaderIndex = 0;}}loadData = null;boolean started = false;while (!started && hasNextModelLoader()) {ModelLoader<File, ?> modelLoader = modelLoaders.get(modelLoaderIndex++);loadData =modelLoader.buildLoadData(cacheFile, helper.getWidth(), helper.getHeight(),helper.getOptions());if (loadData != null && helper.hasLoadPath(loadData.fetcher.getDataClass())) {started = true;loadData.fetcher.loadData(helper.getPriority(), this);}}return started;} 復制代碼

這里的代碼呢，其實跟前面的SourceGenrator差不多，由于前面已經緩存了數據，所以cacheFile!=null，獲取到的modelLoader其實是ByteBufferFileLoader，然后fetcher是ByteBufferFetcher，所以

public void loadData(@NonNull Priority priority,@NonNull DataCallback<? super ByteBuffer> callback) {ByteBuffer result;try {result = ByteBufferUtil.fromFile(file);} catch (IOException e) {...callback.onLoadFailed(e);return;}callback.onDataReady(result);} 復制代碼

直接加載文件，返回二進制數組，然后調用回調函數。這里的callback其實就是DataCacheGenerator，跟前面一樣的，就是不停往前面找。仔細點，還是很簡單的。

@Overridepublic void onDataReady(Object data) {cb.onDataFetcherReady(sourceKey, data, loadData.fetcher, DataSource.DATA_DISK_CACHE, sourceKey);} 復制代碼

這里cb是DecodeJob。

public void onDataFetcherReady(Key sourceKey, Object data, DataFetcher<?> fetcher,DataSource dataSource, Key attemptedKey) {...runReason = RunReason.DECODE_DATA;callback.reschedule(this);... 復制代碼

又開始了，設置了一下值runReason = RunReason.DECODE_DATA，又調用了callback也就是EngineJob的reschedule方法。

這里我就不繼續往前找了，最后還是調用了DecodeJob的run方法

public void run() {...runWrapped();...} private void runWrapped() {switch (runReason) {...case DECODE_DATA:decodeFromRetrievedData();break;...}} private void decodeFromRetrievedData() {...Resource<R> resource = null;try {resource = decodeFromData(currentFetcher, currentData, currentDataSource);...if (resource != null) {notifyEncodeAndRelease(resource, currentDataSource);} else {runGenerators();}}private void notifyEncodeAndRelease(Resource<R> resource, DataSource dataSource) {....notifyComplete(result, dataSource); ...}private void notifyComplete(Resource<R> resource, DataSource dataSource) {...callback.onResourceReady(resource, dataSource);} 復制代碼

這里就比較簡單了，獲取到資源然后解碼后，調用callback也就是EngineJob 的onResourceReady方法

public void onResourceReady(Resource<R> resource, DataSource dataSource) {...MAIN_THREAD_HANDLER.obtainMessage(MSG_COMPLETE, this).sendToTarget();}public boolean handleMessage(Message message) {...switch (message.what) {case MSG_COMPLETE:job.handleResultOnMainThread();...}void handleResultOnMainThread() {...cb.onResourceReady(engineResource, dataSource);...} 復制代碼

這里的cb其實就是SingleRequest了。

public void onResourceReady(Resource<?> resource, DataSource dataSource) {...onResourceReady((Resource<R>) resource, (R) received, dataSource);}private void onResourceReady(Resource<R> resource, R result, DataSource dataSource) {...target.onResourceReady(result, animation);...} 復制代碼

這里的target其實就是ImageViewTarget

public void onResourceReady(@NonNull Z resource, @Nullable Transition<? super Z> transition) {...setResourceInternal(resource);...} private void setResourceInternal(@Nullable Z resource) {...setResource(resource);...}protected abstract void setResource(@Nullable Z resource); 復制代碼

可以看出setResource是一個抽象方法。 由于之前傳入的是Drawable.class 所以這里的實現是DrawableImageViewTarget

protected void setResource(@Nullable Drawable resource) {view.setImageDrawable(resource);} 復制代碼

這里的view其實就是我們的ImageView

到這里，最簡單的Glide加載網絡圖片的流程已經走完。

如果對整個流程不懂的同學，其實是可以debug一下，然后一步一步跟進去。但是由于流程跳來跳去的，可能斷點不是很好打。 大家可以先看下我的整個流程，了解大概之后就可以自己打斷點了。

后續還會繼續深入Glide源碼。有興趣的同學可以關注下。

總結

以上是生活随笔為你收集整理的Glide-源码分析(一)的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。