2. 程式人生 > >React原始碼分析(一)-呼叫ReactDOM.render後發生了什麼

React原始碼分析(一)-呼叫ReactDOM.render後發生了什麼

阿新 • • 發佈：2018-12-15

所謂知其然還要知其所以然. 本系列文章將分析 React 15-stable的部分原始碼, 包括元件初始渲染的過程、元件更新的過程等. 這篇文章先介紹元件初始渲染的過程的幾個重要概念, 包括大致過程、建立元素、例項化元件、事務、批量更新策略等. 在這之前, 假設讀者已經:

  • 對React有一定了解
  • 知道React element、component、class區別
  • 瞭解生命週期、事務、批量更新、virtual DOM大致概念等

如何分析 React 原始碼

程式碼架構預覽

首先, 我們找到React在Github上的地址, 把15-stable版本的原始碼copy下來, 觀察它的整體架構, 這裡首先閱讀關於原始碼介紹的

官方文件, 再接著看.

我們 要分析的原始碼在 src 目錄下:

1
2
3
4
5
6
7
8
9
10

// src 部分目錄

├── ReactVersion.js    # React版本號
├── addons             # 外掛
├── isomorphic		   # 同構程式碼,作為react-core, 提供頂級API
├── node_modules
├── package.json
├── renderers          # 渲染器, 包括DOM,Native,art,test等
├── shared             # 子目錄之間需要共享的程式碼,提到父級目錄shared
├── test			   # 測試程式碼

分析方法

1、首先看一些網上分析的文章, 對重點部分的原始碼有個印象, 知道一些關鍵詞意思, 避免在無關的程式碼上迷惑、耗費時間;

2、準備一個demo, 無任何功能程式碼, 只安裝react,react-dom, Babel轉義包, 避免分析無關程式碼;

3、打debugger; 利用Chrome devtool一步一步走, 打斷點, 看呼叫棧,看函式返回值, 看作用域變數值;

4、利用編輯器查詢程式碼、閱讀程式碼等

正文

我們知道, 對於一般的React 應用, 瀏覽器會首先執行程式碼 ReactDOM.render來渲染頂層元件, 在這個過程中遞迴渲染巢狀的子元件, 最終所有元件被插入到DOM中. 我們來看看

呼叫ReactDOM.render 發生了什麼

大致過程(只展示主要的函式呼叫):

React 初始渲染

如果看不清這有向量圖

讓我們來分析一下具體過程:

1、建立元素

首先, 對於你寫的jsx, Babel會把這種語法糖轉義成這樣:

1
2
3
4
5
6
7
8
9
10
11

// jsx
ReactDOM.render(
    <C />,
    document.getElementById('app')
)

// 轉義後
ReactDOM.render(
  React.createElement(C, null), 
  document.getElementById('app')
);

沒錯, 就是呼叫React.createElement來建立元素. 元素是什麼? 元素只是一個物件描述了DOM樹, 它像這樣:

1
2
3
4
5
6
7
8
9
10
11

{
  $$typeof: Symbol(react.element)
  key: null
  props: {}        // props有child屬性, 描述子元件, 同樣是元素
  ref: null
  type: class C    // type可以是類(自定義元件)、函式(wrapper)、string(DOM節點)
  _owner: null
  _store: {validated: false}
  _self: null
  _source: null
}

React.createElement原始碼在ReactElement.js中, 其他邏輯比較簡單, 值得說的是props屬性, 這個props屬性裡面包含的就是我們給元件傳的各種屬性:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38

// jsx
return (
    <div className='container'>
          "dscsdcsd"
          <i onClick={(e) => console.log(e)}>{this.state.val}</i>
          <Children val={this.state.val}/>
	</div>
)

// bable 轉義後
// createElement(type, props, children)
return React.createElement(
    'div', { className: 'container' }, 
    '"dscsdcsd"',
    React.createElement('i', { onClick: e => console.log(e) }, this.state.val),
    React.createElement(Children, { val: this.state.val })
);

// 對應的元素樹
{
  $$typeof: Symbol(react.element)
  key: null
  props: {  // props有children屬性, 描述子元件, 同樣是元素
    children: [
      ""dscsdcsd"",
      // 子元素
	  {$$typeof: Symbol(react.element), type: "i", key: null, ref: null, props: {…}, …},
	  {$$typeof: Symbol(react.element), type: class Children, props: {…}, …}
    ]
    className: 'container'
  }  
  ref: null
  type: 'div'
  _owner: null
  _store: {validated: false}
  _self: null
  _source: null
}

2、建立對應型別的React元件

創建出來的元素被當作引數和指定的 DOM container 一起傳進ReactDOM.render. 接下來會呼叫一些內部方法, 接著呼叫了 instantiateReactComponent, 這個函式根據element的型別例項化對應的component. 當element的型別為:

  • string時, 說明是文字, 建立ReactDOMTextComponent;
  • ReactElement時, 說明是react元素, 進一步判斷element.type的型別, 當為
    • string時, 為DOM原生節點, 建立ReactDOMComponent;
    • 函式或類時, 為react 元件, 建立ReactCompositeComponent

instantiateReactComponent函式在instantiateReactComponent.js :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32

/**
 * Given a ReactNode, create an instance that will actually be mounted.
 */
function instantiateReactComponent(node(這裡node指element), shouldHaveDebugID) {
  ...
  
  // 如果element為空
  if (node === null || node === false) {
    // 建立空component
    instance = ReactEmptyComponent.create(instantiateReactComponent);
  } else if (typeof node === 'object') {  // 如果是物件
      ...     // 這裡是型別檢查
   
    // 如果element.type是字串
    if (typeof element.type === 'string') {
      //例項化 宿主元件, 也就是DOM節點
      instance = ReactHostComponent.createInternalComponent(element);
    } else if (isInternalComponentType(element.type)) {
      // 保留給以後版本使用，此處暫時不會涉及到
    } else { // 否則就例項化ReactCompositeComponent
      instance = new ReactCompositeComponentWrapper(element);
    }
  // 如果element是string或number
  } else if (typeof node === 'string' || typeof node === 'number') {
    // 例項化ReactDOMTextComponent
    instance = ReactHostComponent.createInstanceForText(node);
  } else {
    invariant(false, 'Encountered invalid React node of type %s', typeof node);
  }
   ...
  return instance;
}

3、開啟批量更新以應對可能的setState

在呼叫instantiateReactComponent拿到元件例項後, React 接著呼叫了batchingStrategy.batchedUpdates並將元件例項當作引數執行批量更新(首次渲染為批量插入).

批量更新是一種優化策略, 避免重複渲染, 在很多框架都存在這種機制. 其實現要點是要弄清楚何時儲存更新, 何時批量更新.

在React中, 批量更新受batchingStrategy控制,而這個策略除了server端都是ReactDefaultBatchingStrategy:

不信你看, 在ReactUpdates.js中 :

1
2
3
4
5
6
7
8
9

var ReactUpdatesInjection = {
  ...
  // 注入批量策略的函式宣告
  injectBatchingStrategy: function(_batchingStrategy) {
    ... 
  
    batchingStrategy = _batchingStrategy;
  },
};

在ReactDefaultInjection.js中注入ReactDefaultBatchingStrategy :

1

ReactInjection.Updates.injectBatchingStrategy(ReactDefaultBatchingStrategy); // 注入

那麼React是如何實現批量更新的? 在ReactDefaultBatchingStrategy.js我們看到, 它的實現依靠了事務.

3.1 我們先介紹一下事務.

在 Transaction.js中, React 介紹了事務:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24

* <pre>
 *                       wrappers (injected at creation time)
 *                                      +        +
 *                                      |        |
 *                    +-----------------|--------|--------------+
 *                    |                 v        |              |
 *                    |      +---------------+   |              |
 *                    |   +--|    wrapper1   |---|----+         |
 *                    |   |  +---------------+   v    |         |
 *                    |   |          +-------------+  |         |
 *                    |   |     +----|   wrapper2  |--------+   |
 *                    |   |     |    +-------------+  |     |   |
 *                    |   |     |                     |     |   |
 *                    |   v     v                     v     v   | wrapper
 *                    | +---+ +---+   +---------+   +---+ +---+ | invariants
 * perform(anyMethod) | |   | |   |   |         |   |   | |   | | maintained
 * +----------------->|-|---|-|---|-->|anyMethod|---|---|-|---|-|-------->
 *                    | |   | |   |   |         |   |   | |   | |
 *                    | |   | |   |   |         |   |   | |   | |
 *                    | |   | |   |   |         |   |   | |   | |
 *                    | +---+ +---+   +---------+   +---+ +---+ |
 *                    |  initialize                    close    |
 *                    +-----------------------------------------+
 * </pre>

React 把要呼叫的函式封裝一層wrapper, 這個wrapper一般是一個物件, 裡面有initialize方法, 在呼叫函式前呼叫;有close方法, 在函式執行後呼叫. 這樣封裝的目的是為了, 在要呼叫的函式執行前後某些不變性約束條件(invariant)仍然成立.

這裡的不變性約束條件(invariant), 我把它理解為 “真命題”, 因此前面那句話意思就是, 函式呼叫前後某些規則仍然成立. 比如, 在調和(reconciliation)前後保留UI元件一些狀態.

React 中, 事務就像一個黑盒, 函式在這個黑盒裡被執行, 執行前後某些規則仍然成立, 即使函式報錯. 事務提供了函式執行的一個安全環境.

繼續看Transaction.js對事務的抽象實現:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95

// 事務的抽象實現, 作為基類
var TransactionImpl = {
  // 初始化/重置例項屬性, 給例項新增/重置幾個屬性, 例項化事務時會呼叫
  reinitializeTransaction: function () {
    this.transactionWrappers = this.getTransactionWrappers();
    if (this.wrapperInitData) {
      this.wrapperInitData.length = 0;
    } else {
      this.wrapperInitData = [];
    }
    this._isInTransaction = false;
  },

  _isInTransaction: false,

  // 這個函式會交給具體的事務例項化時定義, 初始設為null
  getTransactionWrappers: null,
  // 判斷是否已經在這個事務中, 保證當前的Transaction正在perform的同時不會再次被perform
  isInTransaction: function () {
    return !!this._isInTransaction;
  },
  
  // 頂級API, 事務的主要實現, 用來在安全的視窗下執行函式
  perform: function (method, scope, a, b, c, d, e, f) {
    var ret;
    var errorThrown;
    try {
      this._isInTransaction = true;
      errorThrown = true;
      this.initializeAll(0);  // 呼叫所有wrapper的initialize方法
      ret = method.call(scope, a, b, c, d, e, f); // 呼叫要執行的函式
      errorThrown = false;
    } finally {
      // 呼叫所有wrapper的close方法, 利用errorThrown標誌位保證只捕獲函式執行時的錯誤, 對initialize	  // 和close丟擲的錯誤不做處理
      try {
        if (errorThrown) {
          try {
            this.closeAll(0);
          } catch (err) {}
        } else {
          this.closeAll(0);
        }
      } finally {
        this._isInTransaction = false;
      }
    }
    return ret;
  },
    
  // 呼叫所有wrapper的initialize方法的函式定義
  initializeAll: function (startIndex) {
    var transactionWrappers = this.transactionWrappers; // 得到wrapper
    // 遍歷依次呼叫
    for (var i = startIndex; i < transactionWrappers.length; i++) {
      var wrapper = transactionWrappers[i];
      try {
        ...
        this.wrapperInitData[i] = wrapper.initialize ? wrapper.initialize.call(this):null;
      } finally {
        if (this.wrapperInitData[i] === OBSERVED_ERROR) {
          try {
            this.initializeAll(i + 1);
          } catch (err) {}
        }
      }
    }
  },

  // 呼叫所有wrapper的close方法的函式定義
  closeAll: function (startIndex) {
    ...
    var transactionWrappers = this.transactionWrappers; // 拿到wrapper
    // 遍歷依次呼叫
    for (var i = startIndex; i < transactionWrappers.length; i++) {
      var wrapper = transactionWrappers[i];
      var initData = this.wrapperInitData[i];
      var errorThrown;
      try {
        ...
        if (initData !== OBSERVED_ERROR && wrapper.close) {
          wrapper.close.call(this, initData);
        }
        errorThrown = false;
      } finally {
        if (errorThrown) {
          ...
          try {
            this.closeAll(i + 1);
          } catch (e) {}
        }
      }
    }
    this.wrapperInitData.length = 0;
  }
};

這只是React事務的抽象實現(基類), 還需要例項化事務並對其加強的配合, 才能發揮事務的真正作用. 另外, 在React 中, 一個事務裡開啟另一個事務很普遍, 這說明事務是有粒度大小的, 就像程序和執行緒一樣.

3.2 批量更新依靠了事務

剛講到, 在React中, 批量更新受batchingStrategy控制,而這個策略除了server端都是ReactDefaultBatchingStrategy, 而在ReactDefaultBatchingStrategy.js中, 批量更新的實現依靠了事務:

ReactDefaultBatchingStrategy.js :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51

...
var Transaction = require('Transaction');// 引入事務
...

var RESET_BATCHED_UPDATES = {   // 重置的 wrapper
  initialize: emptyFunction,
  close: function() {
    ReactDefaultBatchingStrategy.isBatchingUpdates = false;  // 事務結束即一次batch結束
  },
};

var FLUSH_BATCHED_UPDATES = {  // 批處理的 wrapper
  initialize: emptyFunction,
  close: ReactUpdates.flushBatchedUpdates.bind(ReactUpdates),
};

// 組合成 ReactDefaultBatchingStrategyTransaction 事務的wrapper
var TRANSACTION_WRAPPERS = [FLUSH_BATCHED_UPDATES, RESET_BATCHED_UPDATES]; 

// 呼叫 reinitializeTransaction 初始化
function ReactDefaultBatchingStrategyTransaction() {
  this.reinitializeTransaction();
}

// 引數中依賴了事務
Object.assign(ReactDefaultBatchingStrategyTransaction.prototype, Transaction, {
  getTransactionWrappers: function() {
    return TRANSACTION_WRAPPERS;
  },
});

var transaction = new ReactDefaultBatchingStrategyTransaction(); // 例項化這類事務

// 批處理策略
var ReactDefaultBatchingStrategy = {
  isBatchingUpdates: false, // 是否處在一次BatchingUpdates標誌位

  // 批量更新策略呼叫的就是這個方法
  batchedUpdates: function(callback, a, b, c, d, e) {
    var alreadyBatchingUpdates = ReactDefaultBatchingStrategy.isBatchingUpdates;
	// 一旦呼叫批處理, 重置isBatchingUpdates標誌位, 表示正處在一次BatchingUpdates中
    ReactDefaultBatchingStrategy.isBatchingUpdates = true;

    // 避免重複分配事務
    if (alreadyBatchingUpdates) {
      return callback(a, b, c, d, e);
    } else {
      return transaction.perform(callback, null, a, b, c, d, e);  // 將callback放進事務裡執行
    }
  },
};

那麼, 為什麼批量更新的實現依靠了事務呢? 還記得實現批量更新的兩個要點嗎?

  • 何時儲存更新
  • 何時批處理

對於這兩個問題, React 在執行事務時呼叫wrappers的initialize方法, 建立更新佇列, 然後執行函式, 接著 :

  • 何時儲存更新—— 在執行函式時遇到更新請求就存到這個佇列中
  • 何時批處理—— 函式執行後呼叫wrappers的close方法, 在close方法中呼叫批量處理函式

口說無憑, 得有證據. 我們拿ReactDOM.render會呼叫的事務ReactReconcileTransaction來看看是不是這樣:

ReactReconcileTransaction.js 裡有個wrapper, 它是這樣定義的(英文是官方註釋) :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

var ON_DOM_READY_QUEUEING = {
  /**
   * Initializes the internal `onDOMReady` queue.
   */
  initialize: function() {
    this.reactMountReady.reset();
  },

  /**
   * After DOM is flushed, invoke all registered `onDOMReady` callbacks.
   */
  close: function() {
    this.reactMountReady.notifyAll();
  },
};

我們再看ReactReconcileTransaction事務會執行的函式mountComponent, 它在

ReactCompositeComponent.js :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27

/*
   * Initializes the component, renders markup, and registers event listeners.
*/
  mountComponent: function(
    transaction,
    hostParent,
    hostContainerInfo,
    context,
  ) {
    ...
    
    if (inst.componentDidMount) {
          if (__DEV__) {
            transaction.getReactMountReady().enqueue(() => { // 將要呼叫的callback存起來
              measureLifeCyclePerf(
                () => inst.componentDidMount(),
                this._debugID,
                'componentDidMount',
              );
            });
          } else {
            transaction.getReactMountReady().enqueue(inst.componentDidMount, inst);
          }
      }
      
     ...
    }

而上述wrapper定義的close方法呼叫的this.reactMountReady.notifyAll()在這

CallbackQueue.js :

1
2
3
4
5
6
7
8
9
10
11
12
13
14

/**
   * Invokes all enqueued callbacks and clears the queue. This is invoked after
   * the DOM representation of a component has been created or updated.
   */
  notifyAll() {
      ...
      // 遍歷呼叫儲存的callback
      for (var i = 0; i < callbacks.length; i++) {
        callbacks[i].call(contexts[i], arg);
      }
      callbacks.length = 0;
      contexts.length = 0;
    }
  }

即證.

你竟然讀到這了

好累(笑哭), 先寫到這吧. 我本來還想一篇文章就把元件初始渲染的過程和元件更新的過程講完, 現在看來要分開講了… React 細節太多了, 蘊含的資訊量也很大…說博大精深一點不誇張…向React的作者們以及社群的人們致敬!

我覺得讀原始碼是一件很費力但是非常值得的事情. 剛開始讀的時候一點頭緒也沒有, 不知道它是什麼樣的過程, 不知道為什麼要這麼寫, 有時候還會因為斷點沒打好繞了很多彎路…也是硬著頭皮一遍一遍看, 結合網上的文章, 就這樣雲裡霧裡的慢慢摸索, 不斷更正自己的認知.後來看多了, 就經常會有大徹大悟的感覺, 零碎的認知開始連通起來, 逐漸摸清了來龍去脈.

現在覺得確實很值得, 自己學到了不少. 看原始碼的過程就感覺是跟作者們交流討論一樣, 思想在碰撞! 強烈推薦前端的同學們閱讀React原始碼, 大神們智慧的結晶!

未完待續…

相關推薦

React原始碼分析(一)-呼叫ReactDOM.render後發生了什麼

所謂知其然還要知其所以然. 本系列文章將分析 React 15-stable的部分原始碼, 包括元件初始渲染的過程、元件更新的過程等. 這篇文章先介紹元件初始渲染的過程的幾個重要概念, 包括大致過程、建立元素、例項化元件、事務、批量更新策略等. 在這之前, 假設讀者已經:

React 原始碼分析-呼叫ReactDOM.render後發生了什麼

我們知道, 對於一般的React 應用, 瀏覽器會首先執行程式碼 ReactDOM.render來渲染頂層元件, 在這個過程中遞迴渲染巢狀的子元件, 最終所有元件被插入到DOM中. 我們來看看 呼叫ReactDOM.render 發生了什麼 大致過程(只展示主要的函式呼叫): 1、

react native之知乎日報原始碼分析一

一、說明 react native出現有一段時間了，最近國內學習react native的人也越來越多。react native開發的資料也很多，具體可以參考：https://github.com/ele828/react-native-guide。 大家可

React Native 4 for Android原始碼分析 一《JNI智慧指標之介紹篇》

導讀 React Native 釋出以來將近一年多了，也被抄的火爆到不行，包括RN的中文網和各種資料也很多，加之SE5，Se6語法升級，學習成本並不在RN環境搭建和入門，關鍵還是對JS的掌握入門，不管你是用Native開發，h5開發，還是React

React原始碼分析6 -- 元件通訊，refs，key，ReactDOM

1 元件間通訊 父元件向子元件通訊 React規定了明確的單向資料流，利用props將資料從父元件傳遞給子元件。故我們可以利用props，讓父元件給子元件通訊。故父元件向子元件通訊還是很容易實現的。引申一點，父元件怎麼向孫子元件通訊呢？可以利用props

NSQ原始碼分析(一)——nsqd的初始化及啟動流程

nsq原始碼地址：https://github.com/nsqio/nsq 版本1.1.0  NSQ原始碼分析系列是我通過閱讀nsq的原始碼及結合網上的相關文章整理而成，由於在網上沒有找到很詳細和完整的文章，故自己親自整理了一份。如果有錯誤的地方，還請指正，希望這系列的文章給您帶來

CTS 原始碼分析(一) --CTS概況

1、什麼是CTS？      Compatibility Test Suite 相容性測試套件 說白了，就是一套工具。一套軟體組成的測試工具。 2、哪裡有這套工具？       &nb

智聯招聘爬蟲原始碼分析(一)

    最近一直在關注秋招，雖然還沒輪到我，不過提前準備總是好的。近期聽聞今年秋招形勢嚴峻，為了更好的準備將來的實習、工作，我決定在招聘網站上爬取一些與資料有關的崗位資訊，藉以給自己將來的職業道路選擇提供參考。   一、原理   &n

Django rest framework 的認證流程(原始碼分析一)

一、基本流程舉例: urlpatterns = [ url(r'^admin/', admin.site.urls), url(r'^users/', views.HostView.as_view()), ] urls

go原始碼分析(一) 通過除錯看go程式初始化過程

參考資料：Go 1.5 原始碼剖析 （書籤版）.pdf 編寫go語言test.go package main import ( "fmt" ) func main(){ fmt.Println("Hello World") }  帶除錯的編譯程式碼 go build -

yb-framework原始碼分析(一)

前言 　　本人非科班出身的java小白一枚,兩年多開發經驗。由於最近部落格看的比較多，聽聞某位大牛曾言:種樹的時機最好是十年前,其次是現在,寫部落格也是這樣。加上最近喜歡研究現公司的框架原始碼，發現大體能知道思路但是很難清晰的掌握，而寫部落格是一個鍛鍊自己的表達能力、記錄學習成果以及有利於幫助自己理清思路的

Glide 原始碼分析(一)：圖片壓縮

關於圖片的那點事兒 Q: 一張大小為 55KB, 解析度為 1080 * 480 的 PNG 圖片，它載入近記憶體時所佔的大小是多少呢？ 圖片記憶體大小 圖片佔用記憶體大小 = 解析度 * 畫素點大小 其中資料格式不同畫素點大小也不同： ALPHA_8: 1B RGB_565: 2B

dubbo原始碼分析-服務呼叫流程-筆記

消費端呼叫過程流程圖 消費端的呼叫過程 消費端介面例項： 服務端接收訊息處理過程 NettyHandler. messageReceived 接收訊息的時候，通過NettyHandler.messageReceived作為入口 @Override public vo

epoll原始碼分析(一)

epoll原始碼分析(一) 文章目錄 epoll原始碼分析(一) @[toc] 主要資料結構 epoll_create()函式實現 總結 主要資料結構

React原始碼分析之事件系統

React原始碼分析之事件系統(轉載自阿里雲) react自己實現了一套高效的事件系統，包括了事件的註冊、儲存、分發、和重用，在DOM事件體系基礎上做了很大改進，減少了記憶體消耗，簡化了事件邏輯，並最大化的解決了IE等瀏覽器的事件不相容問題。與傳統的DOM體系相比，它有如下特點：

Android7.1 [Camera] cam_board.xml 檔案解析原始碼分析(一)

        原始碼平臺：rk3399           RK支援了很多個攝像頭，在驅動目錄hardware/rockchip/camer

RxJava2原始碼分析一

       RxJava 在最近兩年迅速火爆起來，最近學習RxJava2，免不了需要學習它的原始碼，寫下部落格記錄學習結果。        RxJava 的設計理念基於觀察者模式，這裡就需要先了解一下它所涉及的

Glide原始碼分析(一)---基本

吐槽 中秋節啊，自己身為一個單身程式猿又不回家，還是在實驗室學個新的框架吧，畢竟這個框架很實用，之前自己都還沒用過，就很尷尬。 那中秋快樂啊 本文思維導圖 Glide是什麼 答曰：一種安卓平臺上的圖形載入框架，一種很好很好用的框架 然後網上說了下picasso

Glide 原始碼分析(一)

Glide原始碼分析 寫在前面 在專案開發中一直使用Glide進行圖片的載入顯示，知道如何使用，但不清楚Glide內部是如何實現的。所以一直想看看Glide的原始碼實現是如何做的，終於有時間和機會了，寫下來做個筆記，也給大家學習下。 Glide載入基本步驟 一般

Spring-BeanFactory原始碼分析(一)

前言 Spring 版本：5.0.9.RELEASE 正式進入Spring 原始碼分析這個模組了，對於spring這個龐大的工程，如果要一點點的完全分析是非常困難的，對於應用型框架，我還是偏向於掌握思想或者設計，而不是記住程式碼，對於初次看spring原始