2. 程式人生 > >Fresco 原始碼分析 —— 整體架構

Fresco 原始碼分析 —— 整體架構

阿新 • • 發佈：2021-01-09

Fresco 是我們專案中圖片載入專用框架。雖然我不是負責 Fresco 框架，但是由本人負責組裡的圖片載入瀏覽等工作，因此瞭解 Fresco 的原始碼有助於我今後的工作，也可以學習 Fresco 的原始碼設計精髓。

由於 Fresco 原始碼比較多，僅憑一篇文章是無法將其說清楚的，因此會當做一個系列，詳細介紹 Fresco 原始碼。本系列文章也會參考網上關於 Fresco 原始碼解析的文章，儘可能準確的去描述 Fresco 的實現原理，如有錯誤之處歡迎指出，歡迎交流學習。

Fresco 是一個強大的圖片載入元件。使用它之後，你不需要再去關心圖片的載入和顯示這些繁瑣的事情！ 支援 Android 2.3 及以後的版本。如果需要了解 Fresco 的使用可以訪問 Fresco 使用文件 。

Fresco是一個功能完善的圖片載入框架，在Android開發中有著廣泛的應用，那麼它作為一個圖片載入框架，有哪些特色讓它備受推崇呢？

  • 完善的記憶體管理功能，減少圖片對記憶體的佔用，即便在低端機器上也有著不錯的表現。

  • 自定義圖片載入的過程，可以先顯示低清晰度圖片或者縮圖，載入完成後再顯示高清圖，可以在載入的時候縮放和旋轉圖片。

  • 自定義圖片繪製的過程，可以自定義谷中焦點、圓角圖、佔位圖、overlay、進圖條。

  • 漸進式顯示圖片。

  • 支援Gif。

  • 支援Webp。

  • ......

Fresco 的組成結構還是比較清晰的，大致如下圖所示:

      

其實這兩張圖來自不同的文章，但是我覺得兩者的分層實際上基本是一樣的。只是一個比較概括，一個比價具體，將兩者擺在一起，更有助於大家去理解其實現細節。當然除了 UI 和載入顯示部分外，還有 Gif，動態圖片等內容，以及對應圖片解碼編碼邏輯等。這部分不打算去講解，因為這部分雖然也是原始碼很重要的一部分，但是這部分需要相關專業知識才好說明白，此外且涉及到 C++ 程式碼。

下面結合程式碼分別解釋一下上面各模組的作用以及大概的工作原理。

DraweeView

它繼承自 ImageView，是 Fresco 載入圖片各個階段過程中圖片顯示的載體，比如在載入圖片過程中它顯示的是佔位圖、在載入成功時切換為目標圖片。不過後續官方可能不再讓這個類繼承 ImageView，所以該類並不支援 ImageView 的 setImageXxx, setScaleType 以及其他類似的方法。目前 DraweeView 與 ImageView 唯一的交集是:它利用 ImageView 

來顯示 Drawable :

//DraweeView.setController()
public void setController(@Nullable DraweeController draweeController) {
    mDraweeHolder.setController(draweeController);
    super.setImageDrawable(mDraweeHolder.getTopLevelDrawable());  //super 就是 ImageView
}

//DraweeHolder.getTopLevelDrawable()
public @Nullable Drawable getTopLevelDrawable() {
    return mHierarchy == null ? null : mHierarchy.getTopLevelDrawable(); // mHierarchy 是 DraweeHierachy，
}

DraweeView.setController() 會在 Fresco 載入圖片時會呼叫。其實在這裡可以看出 Fresco 的圖片顯示原理是 : 利用 ImageView 顯示DraweeHierachy 的 TopLevelDrawable。上面這段程式碼引出了 UI 層中另外兩個關鍵類: DraweeHolder 和 DraweeHierachy。

DraweeHierachy

可以說它是 Fresco 圖片顯示的實現者。它的輸出是 Drawable，這個 Drawable 會被 DraweeView 拿來顯示(上面已經說了)。它內部有多個 Drawable，當前顯示在 DraweeView 的 Drawable 叫做 TopLevelDrawable。在不同的圖片載入階段，TopLevelDrawable 是不同的(比如載入過程中是 placeholder，載入完成是目標圖片)。具體的 Drawable 切換邏輯是由它來具體實現的。

它是由 DraweeController 直接持有的，因此對於不同圖片顯示的切換操作具體是由 DraweeController 來直接操作的。

DraweeHolder

可以把它理解為 DraweeView、DraweeHierachy 和 DraweeController 這 3 個類之間的粘合劑， DraweeView 並不直接和 DraweeController 和 DraweeHierachy 直接接觸，所有的操作都是通過它傳過去。這樣，後續將 DraweeView 的父類改為 View，也不會影響到其他類。DraweeView 作為 View 可以感知點選和生命週期，通過 DraweeHolder 來控制其他兩個類的操作。

想想如果是你，你會抽出 DraweeHolder 這樣一個類嗎？實際上，這裡對我們平時開發也是有所借鑑，嚴格控制每一個類之間的關係，可以引入一些一些中間類，讓類與類之間的關係耦合度降低，方便日後迭代。

具體引用關係如下圖: 

它的主要功能是: 接收 DraweeView 的圖片載入請求，控制 ProducerSequence 發起圖片載入和處理流程，監聽 ProducerSequence 載入過程中的事件(失敗、完成等)，並更新最新的 Drawable 到 DraweeHierachy。

DraweeController 的構造邏輯

在 Fresco 中 DraweeController 是通過 PipelineDraweeControllerBuilderSupplier 獲取的。Fresco在初始化時會呼叫下面的程式碼:

// Fresco.java
private static void initializeDrawee(Context context, @Nullable DraweeConfig draweeConfig) {
    sDraweeControllerBuilderSupplier = new PipelineDraweeControllerBuilderSupplier(context, draweeConfig);
    SimpleDraweeView.initialize(sDraweeControllerBuilderSupplier);
}

sDraweeControllerBuilderSupplier 是靜態變數，也就是說其在只會初始一次。所有的 DraweeController 都是通過呼叫 sDraweecontrollerbuildersupplier.get() 得到的。

  private void init(Context context, @Nullable AttributeSet attrs) {
    try {
      if (FrescoSystrace.isTracing()) {
        FrescoSystrace.beginSection("SimpleDraweeView#init");
      }
      if (isInEditMode()) {
        getTopLevelDrawable().setVisible(true, false);
        getTopLevelDrawable().invalidateSelf();
      } else {
        Preconditions.checkNotNull(
            sDraweecontrollerbuildersupplier, "SimpleDraweeView was not initialized!");
        mControllerBuilder = sDraweecontrollerbuildersupplier.get(); // 呼叫一次就會建立一個新的例項
    }
    // ...... 省略其他程式碼  
}

Fresco 每次圖片載入都會對應到一個 DraweeController，一個DraweeView的多次圖片載入可以複用同一個DraweeController:

SimpleDraweeView.java

public void setImageURI(Uri uri, @Nullable Object callerContext) {
    DraweeController controller =
        mControllerBuilder
            .setCallerContext(callerContext)
            .setUri(uri) //設定新的圖片載入路徑
            .setOldController(getController())  //複用 controller
            .build(); 
    setController(controller);
}

所以一般情況下 : 一個 DraweeView 對應一個 DraweeController。

通過 DataSource 發起圖片載入

在前面已經說了 DraweeController 是直接持有 DraweeHierachy，所以它觀察到 ProducerSequence 的資料變化是可以很容易更新到 DraweeHierachy（具體程式碼先不展示了）。那它是如何控制 ProducerSequence 來載入圖片的呢？其實 DraweeController 並不會直接和 ProducerSequence 發生關聯。對於圖片的載入，它直接接觸的是 DataSource，由 DataSource 進而來控制 ProducerSequence 發起圖片載入和處理流程。下面就跟隨原始碼來看一下 DraweeController 是如果通過 DataSource 來控制 ProducerSequence 發起圖片載入和處理流程的。

// AbstractDraweeController.java
protected void submitRequest() {
    mDataSource = getDataSource(); 
    final DataSubscriber<T> dataSubscriber = new BaseDataSubscriber<T>() { //可以簡單的把它理解為一個監聽者
        @Override
        public void onNewResultImpl(DataSource<T> dataSource) { //圖片載入成功
            ...
        }
        ...
    };
    ...
    mDataSource.subscribe(dataSubscriber, mUiThreadImmediateExecutor); //mUiThreadImmediateExecutor是指 dataSubscriber 回撥方法執行的執行緒，這裡是主執行緒
}

那 DataSource 是什麼呢？ getDataSource()最終會呼叫到:

// PipelineDraweeControllerBuilder 
 protected DataSource<CloseableReference<CloseableImage>> getDataSourceForRequest(
      DraweeController controller,
      String controllerId,
      ImageRequest imageRequest,
      Object callerContext,
      AbstractDraweeControllerBuilder.CacheLevel cacheLevel) {
    return mImagePipeline.fetchDecodedImage(
        imageRequest,
        callerContext,
        convertCacheLevelToRequestLevel(cacheLevel),
        getRequestListener(controller),
        controllerId);
  }

 

// CloseableProducerToDataSourceAdapter<T>
public static <T> DataSource<CloseableReference<T>> create(
      Producer<CloseableReference<T>> producer,
      SettableProducerContext settableProducerContext,
      RequestListener2 listener) {
   
    CloseableProducerToDataSourceAdapter<T> result =
        new CloseableProducerToDataSourceAdapter<T>(producer, settableProducerContext, listener);return result;
  }

所以 DraweeController 最終拿到的 DataSource 是 CloseableProducerToDataSourceAdapter。這個類在構造的時候就會啟動圖片載入流程(它的構造方法會呼叫producer.produceResults(...)，這個方法就是圖片載入的起點，我們後面再看)。

這裡我們總結一下 Fresco 中 DataSource 的概念以及作用: 在 Fresco 中 DraweeController 每發起一次圖片載入就會建立一個 DataSource，這個 DataSource 用來提供這次請求的資料(圖片)。DataSource 只是一個介面，至於具體的載入流程 Fresco 是通過 ProducerSequence 來實現的。

Fresco圖片載入前的邏輯

瞭解了上面的知識後，我們過一遍圖片載入的原始碼(從 UI 到 DraweeController)，來理一下目前所瞭解的各個模組之間的聯絡。我們在使用 Fresco 載入圖片時一般是使用這個API: SimpleDraweeView.setImageURI(imageLink)，這個方法最終會呼叫到:

// SimpleDraweeView.java
public void setImageURI(Uri uri, @Nullable Object callerContext) {
    DraweeController controller = mControllerBuilder
            .setCallerContext(callerContext)
            .setUri(uri)
            .setOldController(getController())
            .build();    //這裡會複用 controller
    setController(controller);
}

public void setController(@Nullable DraweeController draweeController) {
    mDraweeHolder.setController(draweeController);
    super.setImageDrawable(mDraweeHolder.getTopLevelDrawable());  
}

即每次載入都會使用 DraweeControllerBuilder 來 build 一個 DraweeController。其實這個 DraweeController 預設是複用的，這裡的複用針對的是同一個 SimpleDraweeView

 。然後會把 DraweeController 設定給 DraweeHolder，並在載入開始預設是從 DraweeHolder 獲取 TopLevelDrawable 並展示到 DraweeView。繼續看一下 DraweeHolder 的邏輯:

// DraweeHolder.java
public @Nullable Drawable getTopLevelDrawable() {
    return mHierarchy == null ? null : mHierarchy.getTopLevelDrawable();
}


/** Sets a new controller. */
public void setController(@Nullable DraweeController draweeController) {
  boolean wasAttached = mIsControllerAttached;
  if (wasAttached) {
    detachController();
  }

  // Clear the old controller
  if (isControllerValid()) {
    mEventTracker.recordEvent(Event.ON_CLEAR_OLD_CONTROLLER);
    mController.setHierarchy(null);
  }
  mController = draweeController;
　// 注意這裡是只有確定已經 attached 才會呼叫，也就是才回去載入圖片
  if (wasAttached) {
    attachController();
  }
}

在DraweeHolder.setController() 中把 DraweeHierachy 設定給 DraweeController，並重新 attachController()，attachController()主要呼叫了DraweeController.onAttach():

// AbstractDraweeController.java
public void onAttach() {
    ...
    mIsAttached = true;
    if (!mIsRequestSubmitted) {
      submitRequest();
    }
}

protected void submitRequest() {
    mDataSource = getDataSource(); 
    final DataSubscriber<T> dataSubscriber = new BaseDataSubscriber<T>() { //可以簡單的把它理解為一個監聽者
        @Override
        public void onNewResultImpl(DataSource<T> dataSource) { //圖片載入成功
            ...
        }
        ...
    };
    ...
    mDataSource.subscribe(dataSubscriber, mUiThreadImmediateExecutor); //mUiThreadImmediateExecutor是指 dataSubscriber 回撥方法執行的執行緒，這裡是主執行緒
}

即通過submitRequest()提交了一個請求，這個方法我們前面已經看過了，它所做的主要事情就是，構造了一個DataSource。這個 DataSource 我們經過追蹤，它的例項實際上是CloseableProducerToDataSourceAdapter。CloseableProducerToDataSourceAdapter 在構造時就會呼叫 producer.produceResults(...)，進而發起整個圖片載入流程。

用下面這張圖總結從SimpleDraweeView->DraweeController的圖片載入邏輯:

到這裡我們梳理完了 Fresco 在真正發起圖片載入前所走的邏輯，那麼 Fresco 的圖片載入流程是如何控制的呢？到底經歷了哪些步驟呢？

Producer

Fresco中有關圖片的記憶體快取、解碼、編碼、磁碟快取、網路請求都是在這一層實現的，而所有的實現的基本單元是 Producer，所以我們先來理解一下 Producer:

看一下它的定義:

/**
 * <p> Execution of image request consists of multiple different tasks such as network fetch,
 * disk caching, memory caching, decoding, applying transformations etc. Producer<T> represents
 * single task whose result is an instance of T. Breaking entire request into sequence of
 * Producers allows us to construct different requests while reusing the same blocks.
 */
public interface Producer<T> {

  /**
   * Start producing results for given context. Provided consumer is notified whenever progress is made (new value is ready or error occurs).
   */
  void produceResults(Consumer<T> consumer, ProducerContext context);
}

結合註釋我們可以這樣定義 Producer 的作用：一個 Producer 用來處理整個 Fresco 圖片處理流程中的一步，比如從網路獲取圖片、記憶體獲取圖片、解碼圖片等等。而對於 Consumer 可以把它理解為監聽者，看一下它的定義:

public interface Consumer<T> {
/**
   * Called by a producer whenever new data is produced. This method should not throw an exception.
   *
   * <p>In case when result is closeable resource producer will close it after onNewResult returns.
   * Consumer needs to make copy of it if the resource must be accessed after that. Fortunately,
   * with CloseableReferences, that should not impose too much overhead.
   *
   * @param newResult
   * @param status bitwise values describing the returned result
   * @see Status for status flags
   */
  void onNewResult(T newResult, @Status int status);

  /**
   * Called by a producer whenever it terminates further work due to Throwable being thrown. This
   * method should not throw an exception.
   *
   * @param t
   */
  void onFailure(Throwable t);

  /** Called by a producer whenever it is cancelled and won't produce any more results */
  void onCancellation();

  /**
   * Called when the progress updates.
   *
   * @param progress in range [0, 1]
   */
  void onProgressUpdate(float progress);
}

Producer 的處理結果可以通過 Consumer 來告訴外界，比如是失敗還是成功。

Producer 的組合

一個 ProducerA 可以接收另一個 ProducerB 作為引數，如果 ProducerA 處理完畢後可以呼叫 ProducerB 來繼續處理。並傳入 Consumer 來觀察 ProducerB 的處理結果。比如Fresco 在載入圖片時會先去記憶體快取獲取，如果記憶體快取中沒有那麼就網路載入。這裡涉及到兩個 Producer 分別是 BitmapMemoryCacheProducer 和 NetworkFetchProducer，假設BitmapMemoryCacheProducer 為 ProducerA，NetworkFetchProducer 為 ProducerB。我們用虛擬碼看一下他們的邏輯:

// BitmapMemoryCacheProducer.java

public class BitmapMemoryCacheProducer implements Producer<CloseableReference<CloseableImage>> {

    private final Producer<CloseableReference<CloseableImage>> mInputProducer;

    // 我們假設 inputProducer 在這裡為NetworkFetchProducer
    public BitmapMemoryCacheProducer(...,Producer<CloseableReference<CloseableImage>> inputProducer) { 
        ...
        mInputProducer = inputProducer;
    }

    @Override
    public void produceResults(Consumer<CloseableReference<CloseableImage>> consumer,...) {
        CloseableReference<CloseableImage> cachedReference = mMemoryCache.get(cacheKey);

        if (cachedReference != null) { //從快取中獲取成功，直接通知外界
            consumer.onNewResult(cachedReference, BaseConsumer.simpleStatusForIsLast(isFinal));
            return; //結束處理流程
        }

        Consumer<CloseableReference<CloseableImage>> wrappedConsumer = wrapConsumer(consumer..); //包了一層Consumer，即mInputProducer產生結果時，它自己可以觀察到
        mInputProducer.produceResults(wrappedConsumer, producerContext); //網路載入
    }
}

 

// NetworkFetchProducer.java

public class NetworkFetchProducer implements Producer<EncodedImage> {

   // 它並沒有 inputProducer, 對於 Fresco 的圖片載入來說如果網路都獲取失敗，那麼就是圖片載入失敗了

    @Override
    public void produceResults(final Consumer<CloseableReference<CloseableImage>> consumer,..) {

       // 網路獲取
       //   ...
        if(獲取到網路圖片){
            notifyConsumer(...); //把結果通知給consumer，即觀察者
        }
        ...
    }
}

程式碼可能不是很好理解，可以結合下面這張圖來理解這個關係:

Fresco 可以通過組裝多個不同的 Producer 來靈活的定義不同的圖片處理流程的，多個 Producer 組裝在一塊稱為 ProducerSequence (Fresco 中並沒有這個類哦)。一個ProducerSequence 一般定義一種圖片處理流程，比如網路載入圖片的 ProducerSequence 叫做 NetworkFetchSequence，它包含多個不同型別的 Producer。

網路圖片載入的處理流程

在 Fresco 中不同的圖片請求會有不同的 ProducerSequence 來處理，比如網路圖片請求:

// ProducerSequenceFactory.java
private Producer<CloseableReference<CloseableImage>> getBasicDecodedImageSequence(ImageRequest imageRequest) {
    switch (imageRequest.getSourceUriType()) {
        case SOURCE_TYPE_NETWORK: return getNetworkFetchSequence();
        ...
} 

所以對於網路圖片請求會呼叫 getNetworkFetchSequence:

/**
* swallow result if prefetch -> bitmap cache get -> background thread hand-off -> multiplex ->
* bitmap cache -> decode -> multiplex -> encoded cache -> disk cache -> (webp transcode) ->
* network fetch.
*/
private synchronized Producer<CloseableReference<CloseableImage>> getNetworkFetchSequence() {
    ...
    mNetworkFetchSequence = new BitmapCacheGetToDecodeSequence(getCommonNetworkFetchToEncodedMemorySequence());
    ...
    return mNetworkFetchSequence;
}

getNetworkFetchSequence 會經過重重呼叫來組合多個 Producer。這裡我就不追程式碼邏輯了，直接用下面這張圖來描述 Fresco 網路載入圖片的處理流程:

 

可以看到 Fresco 的整個圖片載入過程還是十分複雜的。並且上圖我只是羅列一些關鍵的 Producer，其實還有一些我沒有畫出來。 

總結

為了輔助理解，再提供一張總結的流程圖，將上面整個過程都放在裡面了。後續的系列文章會詳細介紹 UI 和圖片載入過程，希望通過閱讀其原始碼來詳細瞭解內部的程式碼邏輯以及設計思路。

其實我們在閱讀別人原始碼的時候，除了要知道具體的細節之外，也要注意別人的模組設計，借鑑其設計思想。然後想想如果是你在設計的時候，你會怎麼劃分模組，如何將不同的模組聯絡起來。

當模組劃分後，裡面的子模組又是如何劃分的，它們之間協作關係如何保持。

 

參考文章

Android開源框架原始碼鑑賞：Fresco

Fresco架構設計賞析&nb

相關推薦

Fresco 原始碼分析 —— 整體架構

Fresco 是我們專案中圖片載入專用框架。雖然我不是負責 Fresco 框架，但是由本人負責組裡的圖片載入瀏覽等工作，因此瞭解 Fresco 的原始碼有助於我今後的工作，也可以學習 Fresco 的原始碼設計精髓。 由於 Fresco 原始碼比較多，僅憑一篇文章是無法將其說清楚的，因此會當做一個系列，詳細介

Jquery原始碼分析-整體結構

　　最近在學習Jquery的最新的原始碼，Jquery-3.3.1版本。網上有很多對jquery解析的文章。但是我還是要自己去嘗試著看一篇jquery的原始碼。本系列部落格用來記錄其中的過程，並同大家分享。本次學習Jquery原始碼是結合Jquery API來學習的。結合API來學習，首先會讓我理解Jquer

【深入淺出jQuery】原始碼淺析--整體架構

原文：http://www.cnblogs.com/coco1s/p/5261646.html 最近一直在研讀 jQuery 原始碼，初看原始碼一頭霧水毫無頭緒，真正靜下心來細看寫的真是精妙，讓你感嘆程式碼之美。 其結構明晰，高內聚、低耦合，兼具優秀的效能與便利的擴充套件性，在瀏覽器的相容性

fresco原始碼分析-記憶體回收

           我覺得記憶體管理是三方相簿最重要的點， 而且該知識點能夠應用到專案裡， 所以著重看了一下fresco是如何回收記憶體的。      fresco記憶體釋放分為2種方式： 1、按照LruCach的方式釋放引用計數為0物件， fresco內部邏輯實現； 2、

區塊鏈系列----比特幣go語言原始碼-BTCD整體架構

前言 筆者一直致力於區塊鏈底層技術研究。本文將講下第一代區塊鏈(比特幣)，go語言版本BTCD原始碼整體架構。 如果你是剛入門區塊鏈技術，那麼筆者建議可以先學習下blockchain_go。 blockchain_go:一個簡單的go語言實現的區塊鏈工程（

GeoMesa原始碼學習--整體架構

 GeoMesa是一款開源的基於分散式計算系統的面向海量時空資料查詢與分析的工具包，它支援多種可擴充套件的、基於雲端的資料儲存架構，包括Apache Accumulo, HBase，Cassandra，Google Bigtable，以及用於流計算的Apache Kafka 。同時GeoM

CI框架原始碼研讀(整體架構)

部落格搬家：http://chanyaw.cn  有人說phper的深入要從研讀mvc框架開始，我跳了一個常用的CI框架入手，一是因為 CI框架簡單輕巧，二是原來用的最多的就是CI框架了。  1、首先來看CI的整體架構圖： 上圖中是我最新下載CI3.0版本，ap

Fresco原始碼分析之DraweeView

在Android中圖片載入的框架很多，例如：Fresco、Picasso、Glide與Imageloader。它們都有各自的優點，但總的來說，使用起來方便簡單、可配置性高與提供良好的快取機制。由於平常主要用的還是Fresco，所以這裡有必要對Fresco的原理進

MyBatis 原始碼分析----MyBatis 整體架構概要說明

MyBatis整體架構 MyBatis的整體架構分為三層1：基礎支援層，2：核心處理層，3：介面層   1:基礎支援層： 1-1反射模組： 該模組對Java 原生的反射進行了良好的封裝，提供了更加簡潔易用的API ，方便上層使呼叫，並且對反射操作進行了

jQuery原始碼分析系列 : 整體架構

query這麼多年了分析都寫爛了，老早以前就拜讀過， 不過這幾年都是做移動端，一直御用zepto, 最近抽出點時間把jquery又給掃一遍 我也不會照本宣科的翻譯原始碼，結合自己的實際經驗一起拜讀吧！ github上最新是jquery-master，加入了AMD規範了，我就以官方最新2.0.3為準 整體架構

Spring 原始碼分析(三) —— AOP（二）Spring AOP 整體架構

Spring AOP 架構         先是生成代理物件，然後是攔截器的作用，最後是編織的具體實現。這是AOP實現的三個步驟，當然Spring AOP也是一樣。         而從Spring AOP整體架構上看，其核心都是建立在代理上的。當我們建立增強例項時，我們

jQuery 事件機制原始碼分析1——jQuery事件機制整體架構

之前在網上搜索過一些內容大多都是寫的零散寫出一些方法感覺不是很系統，要不就是文不對題，後來自己debug 一番大概搞清楚了，決定寫個文章記錄下來。 需要說明的有以下幾點： 1 本文不會教你如何使用.on .off .trigger 等方法  2  基於原始碼分析基於

kubernetes原始碼閱讀之整體架構分析

Kubernetes是Google開源的Docker容器叢集管理系統，為容器化的應用提供資源排程、部署執行、服務發現、擴容縮容等整一套功能。 整個k8s架構圖如下所示 整個k8s架構包括兩個元件：master（APIs、scheduler、replication con

OkHttp 3.7原始碼分析（一）——整體架構

OkHttp是一個處理網路請求的開源專案,是Android端最火熱的輕量級框架,由移動支付Square公司貢獻用於替代HttpUrlConnection和Apache HttpClient。隨著OkHttp的不斷成熟，越來越多的Android開發者使用OkHtt

muduo庫的原始碼分析1--整體架構

最近，學習了陳碩大俠的《Linux多執行緒服務端程式設計：使用muduo C++網路庫》很受啟發。但是在學習muduo原始碼的過程中，還是感覺程式碼架構比較複雜，一個是和boost相關的內容比較多，對現代C++程式設計理念不瞭解的人，可能感覺莫名其妙。（關於什麼

SpringMVC原始碼剖析（一）SpringMVC整體架構分析和建立

先看一下Servlet的繼承結 前面的Servlet體系我都有講過HttpServlet實現了根據動作分發請求 其他結構重要的類為HttpServletBean，FrameworkServlet ,DispatcherServlet 在Spring中實現了XXXAware

Bind-9.6.0-P1原始碼分析之一:整體架構(初稿)

轉載至：不知轉載源 一、 說明 這是bind解析程式的入口 事件bind程式也事件驅動型，以任務作為主要的執行。 當一個解析請求到來時，就會通過事件的產生來觸發任務dispatch處理。這樣的處理有相應 if (event->ev_action !

Tomcat原始碼分析 （二）----- Tomcat整體架構及元件

前言 Tomcat的前身為Catalina，而Catalina又是一個輕量級的Servlet容器。在美國，catalina是一個很美的小島。所以Tomcat作者的寓意可能是想把Tomcat設計成一個優雅美麗且輕量級的web伺服器。Tomcat從4.x版本開始除了作為支援Servlet的容器外，額外加入了

Tomcat原始碼分析二：先看看Tomcat的整體架構

Tomcat原始碼分析二：先看看Tomcat的整體架構 Tomcat架構圖 我們先來看一張比較經典的Tomcat架構圖： 從這張圖中，我們可以看出Tomcat中含有Server、Service、Connector、Container等元件，接下來我們一起去大致的看看這些元件的作用和他們之間的相互聯絡。在這

Spring 源碼分析（一）--整體架構和環境搭建

spring 事件傳播 com 之間 環境搭建 core模塊 batis bsp 元數據 本系統分析的spring源碼版本為4.3.8。 （一）整體架構 這些模塊被分為以下幾個部分 （1）Core Container Core容器（核心容器）包含Core，Bean