正文

既然要分析DraweeView，那麼就先看一下DraweeView的主要整合體系，然後在詳細分析一下都做了些什麼事情。

在看潘永強部落格的時候，其中他提到：原始碼的分析分為廣度和深度，先廣度再深度，但是都要適當，避免陷入無止境的廣度和深度的細節中去。

從這麼多篇博文來看，原始碼的分析從上至下、先父類後子類、先構造再細節的分析思路是非常棒的。但是，每個人分析習慣不一樣，就我來說更喜歡先從更易接觸的類再深入父類、先看類註釋再看詳細的方法。後續的部落格也會基本按照此種思路。

SimpleDraweeView是官方文件中，我們最先接觸類，也是最易使用的類。那麼就從這個類入手，一步一步分析。先上一下繼承體系圖，雖不是從上至下的分析，但是也需要充分了解體系結構。

好的開發框架，在命名方面往往做的非常好，起到見名知意作用。那麼，我們就從自己的開發經驗推測一下每個類都做了什麼。

SimpleDraweeView是簡單控制元件的意思，既然是簡單，就會提供出簡單明瞭、便易使用的方法，我想setImageURI(Uri uri)就是這樣一個方法。

GenericDraweeView是通用控制元件的意思，通過上一篇文章知道，DraweeView體系中，持有了DraweeHierarchy和DraweeController的引用，那麼預設的東西，會不會是在這個類中提供的？。

DraweeView是什麼意思呢？，只從命名來看推測不出來什麼。

SimpleDrawee

要分析一個類，就先看他的類註釋。

/** 
* This view takes a uri as input and internally builds and sets a controller. 
* This class must be statically initialized in order to be used.
* If you are using the Fresco * image pipeline, use Fresco#initialize to do this. 
*/

1. 這個控制元件接收URI作為輸入，並在內部建立和設定一個控制器。
2. 這個類必須被靜態初始化才能夠被使用，如果你想使用Fresco預設的圖片管道來載入圖片，請使用Fresco的initlialize去做這件事。

相關注釋一定會體現為程式碼表示，我們很輕鬆就能夠找到做第一件事情的程式碼：

/**
  * Displays an image given by the uri.
  */
 public void setImageURI(Uri uri, @Nullable Object callerContext) {
     DraweeController controller = mSimpleDraweeControllerBuilder
             .setCallerContext(callerContext)
             .setUri(uri)
             .setOldController(getController())
             .build();
     setController(controller);
 }

通過uri展示一張圖片。在其內部，通過mSimpleDraweeControllerBuilder建造了一個DraweeController物件，並通過setController()方法，將控制器設定給了頂層的DraweeView類，當前從目前來看是這個樣子的。而一般以Builder結尾的都是使用了建造者模式的類。

這是一個學習設計模式的部落格。

mSimpleDraweeControllerBuilder是一個成員變數，搜尋一下它在哪裡被賦值的。

來到了init()方法，此方法被各個建構函式所呼叫。

private void init() {
    if (isInEditMode()) {
        return;
    }
    Preconditions.checkNotNull(sDraweeControllerBuilderSupplier, "SimpleDraweeView was not initialized!");
    mSimpleDraweeControllerBuilder = sDraweeControllerBuilderSupplier.get();
}

雖然，程式碼不多，還是值得解釋一下。isInEditMode()是判斷當前是否是預覽模式或者是編輯模式，通常在AndrdioStudio中預覽佈局時，會碰到自定義控制元件顯示不出來的情況，加上這句話就可以了。

而Preconditions.checkNotNull()是Fresco的工具類，從命名來看，就是檢查相關引用是否不為空，為空則直接報錯.

下面一句則是，從Supplier（提供者、供應商）中獲取一個SimpleDraweeContoller的建造器。特別說明的是，Supplier雖然不是某種設計模式之一，但是在Fresco被廣泛使用，它可是提供單個物件型別的類，在語義上它可能是一個工廠、建造、或其他任意的東西。

sDraweeControllerBuilderSupplier是一個靜態成員變數，它的初始化就聯絡到了本類所做的第二件事，使用Fresco.initialize(Context)來初始化本類。

既然需要適當在廣度上擴充套件，就接著看一下Fresco類。根據類的註釋，可以知道：

1. 這個類是Fresco的切入點。
2. 在使用這個類之前，你必須初始化此類。而一種簡單初始化的方式就是呼叫Fresco.initialize(Context)。

既然有簡單的，那麼就有非簡單的，一共有兩種方式：

/** Initializes Fresco with the default config. */
 public static void initialize(Context context) {
   ImagePipelineFactory.initialize(context);
   initializeDrawee(context);
 }

 /** Initializes Fresco with the specified config. */
 public static void initialize(Context context, ImagePipelineConfig imagePipelineConfig) {
   ImagePipelineFactory.initialize(imagePipelineConfig);
   initializeDrawee(context);
 }

其中提到了預設的配置和指定的配置，這裡不做過多的深入，對於指定的配置（也就兩個引數的方法），你只需要知道在ImagePipelineConfig中有著大量的引數配置，以保證Fresco框架的可配置化，由於內部引數過多使用了建造者模式來解耦程式碼。

見名知意，ImagePipelineFactory.initialize(context)就是對配置初始化，這裡就先略過了。

這樣就引申到了initializeDrawee(Context context)方法：

private static void initializeDrawee(Context context) {
  sDraweeControllerBuilderSupplier = new PipelineDraweeControllerBuilderSupplier(context);
  SimpleDraweeView.initialize(sDraweeControllerBuilderSupplier);
}

這段程式碼非常重要，它決定了Fresco使用的預設控制器是名為：PipelineDraweeController的類，先簡略看一下類註釋，該Controller是圖片載入器與Model的橋樑，也就是說，如何使用ImagePipeline載入圖片，並交給Model都是在這個類中控制的。當然，這也符合MVC模式的設計。

Drawee controller that bridges the image pipeline with {@link SettableDraweeHierarchy}.

接著就呼叫到了SimpleDraweeView靜態初始化的方法。這樣，從Fresco初始化到SimpleDraweeView的初始化至呼叫setImageUri()顯示一張圖片的流程就基本完整了。

給出一個示意圖，這個圖既非UML圖、也非流程圖，僅僅表達一些程式碼過程，個人覺得使用圖形更形象一些：

GenericDraweeView

從類註釋入手可以瞭解，本類的功能主要是通過解析XML的屬性來構建出一個通用的Hierarchy並進行設定。此外，還提供了一個設定控制元件寬高比的方法。

本類比較簡單，核心的方法在於inflateHierarchy(Context context, @Nullable AttributeSet attrs)。

方法只做的三件事：
1. 解析XML屬性
2. 使用建造者模式構建GenericDraweeHierarchy
3. 將Hierarchy設定給DraweeView體系

  private void inflateHierarchy(Context context, @Nullable AttributeSet attrs) {
  Resources resources = context.getResources();

  // 解析XML屬性
  if (attrs != null) {
  }

  // 使用建造者模式，構建Hierarchy
  GenericDraweeHierarchyBuilder builder = new GenericDraweeHierarchyBuilder(resources);
  // ... ... 

  // 為DraweeView體系設定hierarchy
  setHierarchy(builder.build());
}

到此，值得注意的是。與DraweeView有關的DraweeHierarchy和DraweeController均已出現，DraweeHierarchy對應的預設實現類是：GenericDraweeHierarchy；DraweeController對應的預設實現類是：PipelineDraweeController。

此外，本類做的第二件事，請參考博文：控制寬高比

DraweeView

先上一張圖，更簡潔的表達目的和想做的事。

還是先從類的註釋入手吧。從註釋中可以瞭解到如下幾件事：

1. 該控制元件用於展示從DraweeHierarchy獲取的影象。
2. 使用此控制元件之前，應該先為其設定DraweeHierarchy。由於建立一個DraweeHierarchy是一個昂貴的操作，推薦在建立的時候只做一次。
3. 為了展示一張圖片，DraweeController必須被設定。
4. Note：雖然這個控制元件是ImageView的直接子類，但是不支援ImageView的眾多方法。

在這個類中，即將接觸到一個其背後的男人DraweeHolder類，可以說DraweeView類中所做的所有操作，都是直接或者間接和DraweeHolder有關係的。DraweeView從其體系中獲取到的DraweeHierarchy和DraweeController的資訊都被其轉交到了DraweeHolder類中。其實，這個就是一個解耦操作。假設，你想要自定一個控制元件，只想使用DraweeHierarchy和DraweeController的功能，難道還自己持有這兩個類的引用？ Just So So。DraweeHolder幫你省去了很多麻煩。

先看一下DraweeHolder是如何被建立的。

private void init(Context context) {
  ...
  mDraweeHolder = DraweeHolder.create(null, context);
  ...
}

看樣子平平無償，瀏覽該類的其他方法你會發現，大部分的操作都是將資訊轉交給DraweeHolder的操作。但是，請不要忽略以下兩個方法：

public void setController(@Nullable DraweeController draweeController) {
  mDraweeHolder.setController(draweeController);
  // 重點
  super.setImageDrawable(mDraweeHolder.getTopLevelDrawable());
}
public void setHierarchy(DH hierarchy) {
  mDraweeHolder.setHierarchy(hierarchy);
  // 重點
  super.setImageDrawable(mDraweeHolder.getTopLevelDrawable());
}

注意到了兩個重點沒？mDraweeHolder.getTopLevelDrawable()獲取到的就是DraweeHierarchy.getTopLevelDraweeable()。

從之前的分析可以得知，setHierarchy()是先被呼叫而後才是setController()，
通過super.setImageDrawable(mDraweeHolder.getTopLevelDrawable())這句話，就將Fresco的圖片顯示與ImageView結合了起來，這也是圖片能夠顯示的原因。

如果你自定義控制元件了，千萬不要忘記模仿這兩個方法加上同樣的語句哦。

既然，DraweeView已經將職責都轉交給了DraweeHolder類，那麼就來看看DraweeHolder類做了些什麼。

還是先從類註釋入手：

1. 這個類持有了DraweeController和DraweeHierarchy
2. 這個類便於自定義控制元件使用

在瀏覽類的所有方法時，onAttach()和onDetach()方法引起了我的注意。

public void onAttach() {
    mEventTracker.recordEvent(Event.ON_HOLDER_ATTACH);
    mIsHolderAttached = true;
    attachOrDetachController();
}

public void onDetach() {
    mEventTracker.recordEvent(Event.ON_HOLDER_DETACH);
    mIsHolderAttached = false;
    attachOrDetachController();
}

通過註釋可以知道onAttach()的核心作用是獲取DraweeController以顯示影象；onDetach()的核心作用是釋放用於顯示影象的資源。他們都共同呼叫了attachOrDetachController()方法。

 private void attachOrDetachController() {
     if (mIsHolderAttached && mIsVisible && mIsActivityStarted) {
         attachController();
     } else {
         detachController();
     }
 }

你會發現，當同時滿足onAttach()被呼叫、控制元件可見時、Activity啟動時才會呼叫attachController()方法，既然需要同時滿足這麼多條件，想來這一定是個非常重要的方法。

可以說，Fresco核心載入的邏輯都是由這段程式碼引出的。

private void attachController() {
    if (mIsControllerAttached) {
        return;
    }
    mEventTracker.recordEvent(Event.ON_ATTACH_CONTROLLER);
    mIsControllerAttached = true;
    if (mController != null && mController.getHierarchy() != null) {
        mController.onAttach();
    }
}

private void detachController() {
    if (!mIsControllerAttached) {
        return;
    }
    mEventTracker.recordEvent(Event.ON_DETACH_CONTROLLER);
    mIsControllerAttached = false;
    if (mController != null) {
        mController.onDetach();
    }
}

其中mIsControllerAttached是保證核心邏輯在一個控制元件中只被執行一次。在attachController()方法中，如果同時滿足了DraweeController不為空和DraweeHierarchy不為空，才會呼叫DraweeController的onAttach()方法。

到了這裡，你是不是非常好奇在DraweeController的onAttach()的方法中，到底做了怎麼樣重要的邏輯？ (^__^) 嘻嘻……

最後

DraweeView的體系分析就基本完成了，如果覺得對您有幫助，多多留言哦。