Fresco源碼分析之Controller

時間  2019-11-17
標籤 fresco 源碼 分析 controller 简体版
原文   原文鏈接

若是你是第一次看個人Fresco的源碼分析系列文章，這裏強烈推薦你先閱讀個人前面兩篇文章Fresco源碼分析之DraweeView與Fresco源碼分析之Hierarchy。好了，下面進入正題。在上篇文章中咱們提到，在Fresco中關於圖片的緩存、請求與顯示邏輯處理都在Controller中。那麼Controller究竟是如何貫穿這些功能的呢？咱們先從它的出生開始。php

Suppiler

PipelineDraweeControllerBuilderSupplier是一個供應商，主要實現了Supplier<T>接口，它只有一個方法T get()，用來獲取相關的提供實現。所以該供應類提供的就是PipelineDraweeControllerBuilder實例。java

@Override
  public PipelineDraweeControllerBuilder get() {
    return new PipelineDraweeControllerBuilder(
        mContext,
        mPipelineDraweeControllerFactory,
        mImagePipeline,
        mBoundControllerListeners);
  }
複製代碼

在生成的builder中有4個參數，第一個是Context再熟悉不過了；第二個是Controller的工廠；第三個是數據管道ImagePipeline；第四個是listener的set集合，主要用在圖片請求以後的監聽回調。下面詳細說明後面三個參數內容與做用。android

PipelineDraweeControllerFactory

在這個類中主要就兩個方法，分別爲internalCreateController與newController，對外的方法就一個newController。這個兩個方法都是用來建立PipelineDraweeController對象。其中newController內部就是調用了internalCreateController來進行建立PipelineDraweeController實例。git

protected PipelineDraweeController internalCreateController(
      Resources resources,
      DeferredReleaser deferredReleaser,
      DrawableFactory animatedDrawableFactory,
      Executor uiThreadExecutor,
      MemoryCache<CacheKey, CloseableImage> memoryCache,
      @Nullable ImmutableList<DrawableFactory> globalDrawableFactories,
      @Nullable ImmutableList<DrawableFactory> customDrawableFactories,
       Supplier<DataSource<CloseableReference<CloseableImage>>> dataSourceSupplier,
      String id,
      CacheKey cacheKey,
      Object callerContext) {
    PipelineDraweeController controller = new PipelineDraweeController(
        resources,
        deferredReleaser,
        animatedDrawableFactory,
        uiThreadExecutor,
        memoryCache,
        dataSourceSupplier,
        id,
        cacheKey,
        callerContext,
        globalDrawableFactories);
     controller.setCustomDrawableFactories(customDrawableFactories);
    return controller;
  }
複製代碼

其中DeferredReleaser是用來管理推遲資源釋放的。咱們在以前的文章已經提到，在onAttach中會進行加載資源，而onDetach中又會釋放資源。由於在Fresco中每每會在onDetach與onAttach之間頻繁切換(view的顯隱、繪製與Controller的設置都會調用)，而且它們都處於在同一個looper(其實就是主進程的looper)中。若是在onDetach時立刻釋放資源的話，這樣會形成資源的濫用，致使沒必要要的資源加載與釋放回收。因此就用了這個資源推遲釋放的機制(內部原理是使用了set集合的惟一性的特性)。github

dataSourceSupplier是DataSource的供應商，用來提供DataSource實例。而DataSource是用來獲取與存儲請求結果的，至關與圖片數據源。這些都會在後續的Controller中使用到。緩存

ImagePipeline

既然它是數據管道，天然是與網絡請求與緩存數據有關。其實咱們能夠把它理解爲多個管道的集合，最終顯示的圖片資源就是來自於它們中的其中一個。下面介紹其中的主要方法：bash

  • fetchDecodedImage() 發送請求，返回decode image的數據源。
  • fetchEncodedImage() 發送請求，返回encoded image的數據源。
  • prefetchToBitmapCache() 發送預處理請求，獲取預處理的bitmap緩存數據。
  • prefetchToDiskCache() 發送預處理請求，獲取預處理的磁盤緩存數據。
  • submitFetchRequest() 發送請求，獲取相應類型的數據源。
  • submitPrefetchRequest() 發送預處理請求，獲取相應類型的緩存數據。

這裏用的最多的仍是fetchDecodedImage()微信

public DataSource<CloseableReference<CloseableImage>> fetchDecodedImage(
      ImageRequest imageRequest,
      Object callerContext,
      ImageRequest.RequestLevel lowestPermittedRequestLevelOnSubmit) {
    try {
      Producer<CloseableReference<CloseableImage>> producerSequence =
           mProducerSequenceFactory.getDecodedImageProducerSequence(imageRequest);
      return submitFetchRequest(
          producerSequence,
          imageRequest,
          lowestPermittedRequestLevelOnSubmit,
          callerContext);
    } catch (Exception exception) {
      return DataSources.immediateFailedDataSource(exception);
    }
  }
複製代碼

這裏主要涉及到Producer，這是一個生產者，內部只有一個公共接口方法void produceResults(Consumer consumer, ProducerContext context)，用來獲取數據源。其實咱們會發現submitFetchRequest方法中的producer傳入的實際上是一個隊列，由於內部會遞歸調用*produceResults()*來獲取最終的數據源。網絡

關於Producer後續有時間的話會單獨開篇文章詳細分析。ide

ControllerListener

若是你對ControllerListener不熟悉的話，那麼BaseControllerListener應該或多或少使用過吧。它其實就是ControllerListener的空實現。既然是監聽回調，那麼來看下它提供的回調方法與調用時機。

  • void onSubmit(String id, Object callerContext) 在發送請求的時候回調
  • void onFinalImageSet(String id, @Nullable INFO imageInfo, @Nullable Animatable animatable) 在最終設置image圖片時回調，其中imageInfo包含圖片的相關基本信息（width、height與quality）
  • void onIntermediateImageSet(String id, @Nullable INFO imageInfo) 在發送請求與最終圖片設置的過程當中回調
  • void onIntermediateImageFailed(String id, Throwable throwable) 在發送請求與最終失敗的過程當中回調
  • void onFailure(String id, Throwable throwable) 發送請求失敗時回調
  • void onRelease(String id) 資源釋放時回調

ControllerBuilder

既然是builder模式，最終的目的天然就是用來建立Controller，因此咱們能夠直接奔着它的目的來分析。在這裏Controller的builder類是PipelineDraweeControllerBuilder。咱們找到它的*build()發如今它的父類AbstractDraweeControllerBuilder中。但最終的建立實例方法仍是調用了obtainController()*抽象方法。因此通過反轉仍是回到了PipelineDraweeControllerBuilder，那麼咱們直接來看下它建立方式。

@Override
  protected PipelineDraweeController obtainController() {
    DraweeController oldController = getOldController();
    PipelineDraweeController controller;
    if (oldController instanceof PipelineDraweeController) {
      controller = (PipelineDraweeController) oldController;
      controller.initialize(
          obtainDataSourceSupplier(),
          generateUniqueControllerId(),
          getCacheKey(),
          getCallerContext(),
          mCustomDrawableFactories);
    } else {
      controller = mPipelineDraweeControllerFactory.newController(
          obtainDataSourceSupplier(),
          generateUniqueControllerId(),
          getCacheKey(),
          getCallerContext(),
          mCustomDrawableFactories);
    }
    return controller;
  }
複製代碼

經過上面的代碼，邏輯已經很明顯了。首先判斷是否已經存在Controller，若是存在的話就無需建立新的實例，只需調用initialize()方法進行重寫初始化；若是不存在，那麼就調用咱們文章以前分析的PipelineDraweeControllerFactory中的newController()來建立新的實例。這裏主要的參數仍是obtainDataSourceSupplier()，以前也簡單提到了，它是DataSource的供應者。那麼咱們來看下Supplier的建立

protected Supplier<DataSource<IMAGE>> getDataSourceSupplierForRequest(
      final REQUEST imageRequest,
      final CacheLevel cacheLevel) {
    final Object callerContext = getCallerContext();
    return new Supplier<DataSource<IMAGE>>() {
      @Override
      public DataSource<IMAGE> get() {
        return getDataSourceForRequest(imageRequest, callerContext, cacheLevel);
      }
      @Override
      public String toString() {
        return Objects.toStringHelper(this)
            .add("request", imageRequest.toString())
            .toString();
      }
    };
  }
複製代碼

在這個方法中，咱們一眼就看到了Supplier的建立，以前也提到它只有一個*get()方法，就是用來提供因此須要的DataSource。在這裏也是如此，這裏它調用了getDataSourceForRequest()方法，該方法是一個抽象方法，細節實現由它的子類實現，因此咱們能夠再次回到getDataSourceForRequest，在其中就可以搜索到getDataSourceForRequest()*方法

@Override
  protected DataSource<CloseableReference<CloseableImage>> getDataSourceForRequest(
      ImageRequest imageRequest,
      Object callerContext,
      CacheLevel cacheLevel) {
    return mImagePipeline.fetchDecodedImage(
        imageRequest,
        callerContext,
        convertCacheLevelToRequestLevel(cacheLevel));
  }
複製代碼

看到上面的方法實現方法是否眼熟呢？這也是咱們上面所提到的ImagePipleline中的方法，這裏就不在多作分析了。這樣Controller就與獲取數據的通道創建了聯繫。那麼下面咱們就轉戰到Controller中，看看它到底作了什麼。

Controller

PipelineDraweeController繼承於AbstractDraweeController，在PipelineDraweeController中主要的方法有三個

  • Drawable createDrawable(CloseableImage closeableImage) 這是內部類DrawableFactory中的方法，是一個工廠，不言而喻它是用來建立Drawable的，在數據源返回的時候回調，進而顯示到Hierarchy層。
  • getDataSource() 獲取數據源通道，與其創建聯繫。
  • void setHierarchy(@Nullable DraweeHierarchy hierarchy) 設置Hierarchy圖層，內部持有的實際上是SettableDraweeHierarchy接口對象。因此內部調用的也就是它的6個接口方法。以前的文章也有說起，用來控制圖片加載過程當中的顯示邏輯。

其他的邏輯處理都在它的父類AbstractDraweeController中。在以前咱們屢次說起到onAttach與onDetach方法，它們分別是處理數據加載與釋放。

onAttach

@Override
  public void onAttach() {
    if (FLog.isLoggable(FLog.VERBOSE)) {
      FLog.v(
          TAG,
          "controller %x %s: onAttach: %s",
          System.identityHashCode(this),
          mId,
          mIsRequestSubmitted ? "request already submitted" : "request needs submit");
    }
    //事件記錄器
 mEventTracker.recordEvent(Event.ON_ATTACH_CONTROLLER);
  Preconditions.checkNotNull(mSettableDraweeHierarchy);
    //取消資源推遲釋放機制，防止資源被釋放
    mDeferredReleaser.cancelDeferredRelease(this);
    mIsAttached = true;
    if (!mIsRequestSubmitted) {
      submitRequest();
    }
  }
複製代碼

在這個方法中mEventTracker是事件記錄器，默認是開啓的，若是要關閉則須要在*Fresco.initialize()以前調用DraweeEventTracker.disable()關閉；而後就是將其從資源推遲釋放機制中取消；最後就是調用submitRequest()*發送數據源請求。

protected void submitRequest() {
    final T closeableImage = getCachedImage();
    //1.判斷內存緩存中是否存在
    if (closeableImage != null) {
      mDataSource = null;
      mIsRequestSubmitted = true;
      mHasFetchFailed = false;
       mEventTracker.recordEvent(Event.ON_SUBMIT_CACHE_HIT);
      //1.1數據獲取中通知回調
      getControllerListener().onSubmit(mId, mCallerContext);
      //1.2數據處理
      onNewResultInternal(mId, mDataSource, closeableImage, 1.0f, true, true);
      return;
    }
     mEventTracker.recordEvent(Event.ON_DATASOURCE_SUBMIT);
    //2.經過DataSource獲取數據源
    //2.1數據獲取中通知回調
    getControllerListener().onSubmit(mId, mCallerContext);
    mSettableDraweeHierarchy.setProgress(0, true);
    mIsRequestSubmitted = true;
    mHasFetchFailed = false;
    mDataSource = getDataSource();
    if (FLog.isLoggable(FLog.VERBOSE)) {
      FLog.v(
          TAG,
          "controller %x %s: submitRequest: dataSource: %x",
          System.identityHashCode(this),
          mId,
          System.identityHashCode(mDataSource));
    }
    final String id = mId;
    final boolean wasImmediate = mDataSource.hasResult();
    //內部請求數據回調，當數據源返回時回調
    final DataSubscriber<T> dataSubscriber =
        new BaseDataSubscriber<T>() {
          @Override
          public void onNewResultImpl(DataSource<T> dataSource) {
            // isFinished must be obtained before image, otherwise we might set intermediate result
            // as final image.
            boolean isFinished = dataSource.isFinished();
            float progress = dataSource.getProgress();
            T image = dataSource.getResult();
            //2.2數據處理
            if (image != null) {
              //成功處理
              onNewResultInternal(id, dataSource, image, progress, isFinished, wasImmediate);
            } else if (isFinished) {
              //失敗處理
              onFailureInternal(id, dataSource, new NullPointerException(), /* isFinished */ true);
            }
          }
          @Override
          public void onFailureImpl(DataSource<T> dataSource) {
            //失敗處理
            onFailureInternal(id, dataSource, dataSource.getFailureCause(), /* isFinished */ true);
          }
          @Override
          public void onProgressUpdate(DataSource<T> dataSource) {
            boolean isFinished = dataSource.isFinished();
            float progress = dataSource.getProgress();
            //數據進度處理
            onProgressUpdateInternal(id, dataSource, progress, isFinished);
          }
        };
    //數據源訂閱回調註冊
    mDataSource.subscribe(dataSubscriber, mUiThreadImmediateExecutor);
  }
複製代碼

邏輯方面的處理，上面代碼中已經詳細註釋了，總的來講就是先從內存中獲取若是存在就直接拿來用，不然就經過DataSource從網絡或者是本地資源中獲取。使用DataSource方式會使用到DataSubscriber，即訂閱方式。當數據源已經獲取到時，發送通知給訂閱者，所以分別回調訂閱者的方法。上述兩種方式只要成功了都會交由*onNewResultInternal()處理，而失敗則由onFailureInternal()處理，同時請求進度處理由onProgressUpdateInternal()*處理。

private void onNewResultInternal(
      String id,
      DataSource<T> dataSource,
      @Nullable T image,
      float progress,
      boolean isFinished,
      boolean wasImmediate) {
    // ignore late callbacks (data source that returned the new result is not the one we expected)
    if (!isExpectedDataSource(id, dataSource)) {
      logMessageAndImage("ignore_old_datasource @ onNewResult", image);
      releaseImage(image);
      dataSource.close();
      return;
    }
    mEventTracker.recordEvent(
        isFinished ? Event.ON_DATASOURCE_RESULT : Event.ON_DATASOURCE_RESULT_INT);
    // create drawable
    Drawable drawable;
    try {
      drawable = createDrawable(image);
    } catch (Exception exception) {
      logMessageAndImage("drawable_failed @ onNewResult", image);
      releaseImage(image);
      onFailureInternal(id, dataSource, exception, isFinished);
      return;
    }
    T previousImage = mFetchedImage;
    Drawable previousDrawable = mDrawable;
    mFetchedImage = image;
    mDrawable = drawable;
    try {
      // set the new image
      if (isFinished) {
        logMessageAndImage("set_final_result @ onNewResult", image);
        mDataSource = null;
        //經過hierarchy（GenericDraweeHierarchy）來設置image
        mSettableDraweeHierarchy.setImage(drawable, 1f, wasImmediate);
        getControllerListener().onFinalImageSet(id, getImageInfo(image), getAnimatable());
        // IMPORTANT: do not execute any instance-specific code after this point
      } else {
        logMessageAndImage("set_intermediate_result @ onNewResult", image);
        mSettableDraweeHierarchy.setImage(drawable, progress, wasImmediate);
         getControllerListener().onIntermediateImageSet(id, getImageInfo(image));
        // IMPORTANT: do not execute any instance-specific code after this point
      }
    } finally {
      if (previousDrawable != null && previousDrawable != drawable) {
        releaseDrawable(previousDrawable);
      }
      if (previousImage != null && previousImage != image) {
        logMessageAndImage("release_previous_result @ onNewResult", previousImage);
        releaseImage(previousImage);
      }
    }
  }
複製代碼

這裏咱們主要就看裏面的兩個try。
第一個使用createDrawable(image)將拿到的數據源轉變成Drawable，這個方法的具體實現是在子類中實現(上面也有說起)。
第二個分爲兩種狀況，一方面若是數據源已經所有獲取完，則直接調用SettableDraweeHierarchy接口的setImage()方法將圖片設置到Hierarchy圖層上，同時調用Listener的回調方法onFinalImageSet();另外一方面若是數據源還在獲取中，也是調用SettableDraweeHierarchy接口的*setImage()方法，只是其中的參數progress根據進度來設置而已，因爲還處於資源獲取中因此調用onIntermediateImageSet()*回調。
這樣Controller就與Hierarchy聯繫起來了，將須要的圖片設置到顯示的圖片中。

對於SettableDraweeHierarchy中的這些方法若是不理解的能夠回過頭去看我以前的這篇文章Fresco源碼分析之Hierarchy

因爲源碼太多，對於*onFailureInternal()與onProgressUpdateInternal()*這裏就不貼出源碼來進行分析了。原理與調用的方法基本相似，若是想看源碼的能夠點這裏

onDetach

@Override
  public void onDetach() {
    if (FLog.isLoggable(FLog.VERBOSE)) {
      FLog.v(TAG, "controller %x %s: onDetach", System.identityHashCode(this), mId);
    }
    mEventTracker.recordEvent(Event.ON_DETACH_CONTROLLER);
    mIsAttached = false;
    mDeferredReleaser.scheduleDeferredRelease(this);
  }
複製代碼

相對於以前的分析*onDetach()*就簡單多了，這裏它只是對資源進行釋放，釋放的策略也是推遲釋放策略DeferredReleaser。

End

本篇文章主要分析了Fresco中的Controller相關處理邏輯，它控制着Hierarchy顯示邏輯，同時它是數據源的獲取橋樑經過DataSource來連接數據源的獲取。那麼問題又來了，DataSource又是如何產生的呢？同時它的內部邏輯又是如何的呢？這就涉及到Producer了，敬請關注下篇文章Fresco源碼分析之Producer

Fresco源碼分析系列Github地址

Recommend

Fresco源碼分析之DraweeView

Fresco源碼分析之Hierarchy

Android共享動畫兼容實現

Kotlin最佳實踐

Android高仿微信之mvp實現(四)

php與android的簡單交互

tensorflow-梯度降低,有這一篇就足夠了

博客

相關文章
相關標籤/搜索
每日一句
    每一个你不满意的现在，都有一个你没有努力的曾经。
本站公眾號
   歡迎關注本站公眾號,獲取更多信息
聯繫我們 最近搜索 最新文章 沪ICP备13005482号-10 MyBatis教程 SQL 教程 MySQL教程 Java 教程 Thymeleaf 教程 Hibernate教程 Spring教程 Redis教程