2. 程式人生 > >React原始碼分析(三)-全面剖析元件更新機制

React原始碼分析(三)-全面剖析元件更新機制

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

React 把元件看作狀態機(有限狀態機), 使用state來控制本地狀態, 使用props來傳遞狀態. 前面我們探討了 React 如何對映狀態到 UI 上(初始渲染), 那麼接下來我們談談 React 時如何同步狀態到 UI 上的, 也就是:

React 是如何更新元件的?

React 是如何對比出頁面變化最小的部分?

這篇文章會為你解答這些問題.

在這之前

你已經瞭解了React (15-stable版本)內部的一些基本概念, 包括不同型別的元件例項、mount過程、事務、批量更新的大致過程(還沒有? 不用擔心, 為你準備好了從原始碼看元件初始渲染、接著從原始碼看元件初始渲染;

準備一個demo, 除錯原始碼, 以便更好理解;

Keep calm and make a big deal !

React 是如何更新元件的?

TL;DR

  • 依靠事務進行批量更新;
  • 一次batch(批量)的生命週期就是從ReactDefaultBatchingStrategy事務perform之前(呼叫ReactUpdates.batchUpdates)到這個事務的最後一個close方法呼叫後結束;
  • 事務啟動後, 遇到 setState 則將 partial state 存到元件例項的_pendingStateQueue上, 然後將這個元件存到dirtyComponents 陣列中, 等到 ReactDefaultBatchingStrategy
    事務結束時呼叫runBatchedUpdates批量更新所有元件;
  • 元件的更新是遞迴的, 三種不同型別的元件都有自己的updateComponent方法來決定自己的元件如何更新, 其中 ReactDOMComponent 會採用diff演算法對比子元素中最小的變化, 再批量處理.

這個更新過程像是一套流程, 無論你通過setState(或者replaceState)還是新的props去更新一個元件, 都會起作用.

那麼具體是什麼?

讓我們從這套更新流程的開始部分講起…

呼叫 setState 之前

首先, 開始一次batch的入口是在ReactDefaultBatchingStrategy

裡, 呼叫裡面的batchedUpdates便可以開啟一次batch:

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

// 批處理策略
var ReactDefaultBatchingStrategy = {
  isBatchingUpdates: false, 
  batchedUpdates: function(callback, a, b, c, d, e) {
    var alreadyBatchingUpdates = ReactDefaultBatchingStrategy.isBatchingUpdates;
    ReactDefaultBatchingStrategy.isBatchingUpdates = true; // 開啟一次batch

    if (alreadyBatchingUpdates) {
      return callback(a, b, c, d, e);
    } else {
      // 啟動事務, 將callback放進事務裡執行
      return transaction.perform(callback, null, a, b, c, d, e);  
    }
  },
};

在 React 中, 呼叫batchedUpdates有很多地方, 與更新流程相關的如下

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

// ReactMount.js
ReactUpdates.batchedUpdates(
      batchedMountComponentIntoNode,  // 負責初始渲染
      componentInstance,
      container,
      shouldReuseMarkup,
      context,
);

// ReactEventListener.js
dispatchEvent: function(topLevelType, nativeEvent) {
    ...
    try {
      ReactUpdates.batchedUpdates(handleTopLevelImpl, bookKeeping);  // 處理事件
    } finally {
      TopLevelCallbackBookKeeping.release(bookKeeping);
    }
},

第一種情況, React 在首次渲染元件的時候會呼叫batchedUpdates, 然後開始渲染元件. 那麼為什麼要在這個時候啟動一次batch呢? 不是因為要批量插入, 因為插入過程是遞迴的, 而是因為元件在渲染的過程中, 會依順序呼叫各種生命週期函式, 開發者很可能在生命週期函式中(如componentWillMount或者componentDidMount)呼叫setState. 因此, 開啟一次batch就是要儲存更新(放入dirtyComponents), 然後在事務結束時批量更新. 這樣以來, 在初始渲染流程中, 任何setState都會生效, 使用者看到的始終是最新的狀態.

第二種情況, 如果你在HTML元素上或者元件上綁定了事件, 那麼你有可能在事件的監聽函式中呼叫setState, 因此, 同樣為了儲存更新(放入dirtyComponents), 需要啟動批量更新策略. 在回撥函式被呼叫之前, React事件系統中的dispatchEvent函式負責事件的分發, 在dispatchEvent中啟動了事務, 開啟了一次batch, 隨後呼叫了回撥函式. 這樣一來, 在事件的監聽函式中呼叫的setState就會生效.

也就是說, 任何可能呼叫 setState 的地方, 在呼叫之前, React 都會啟動批量更新策略以提前應對可能的setState

那麼呼叫 batchedUpdates 後發生了什麼?

React 呼叫batchedUpdates時會傳進去一個函式, batchedUpdates會啟動ReactDefaultBatchingStrategyTransaction事務, 這個函式就會被放在事務裡執行:

1
2
3
4
5
6
7
8
9

// ReactDefaultBatchingStrategy.js
var transaction = new ReactDefaultBatchingStrategyTransaction(); // 例項化事務
var ReactDefaultBatchingStrategy = {
  ...
  batchedUpdates: function(callback, a, b, c, d, e) {
    ...
      return transaction.perform(callback, null, a, b, c, d, e);  // 將callback放進事務裡執行
   	...
};

ReactDefaultBatchingStrategyTransaction這個事務控制了批量策略的生命週期:

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

// ReactDefaultBatchingStrategy.js
var FLUSH_BATCHED_UPDATES = {
  initialize: emptyFunction,
  close: ReactUpdates.flushBatchedUpdates.bind(ReactUpdates),  // 批量更新
};
var RESET_BATCHED_UPDATES = {
  initialize: emptyFunction,
  close: function() {
    ReactDefaultBatchingStrategy.isBatchingUpdates = false;  // 結束本次batch
  },
};
var TRANSACTION_WRAPPERS = [FLUSH_BATCHED_UPDATES, RESET_BATCHED_UPDATES];

無論你傳進去的函式是什麼, 無論這個函式後續會做什麼, 都會在執行完後呼叫上面事務的close方法, 先呼叫flushBatchedUpdates批量更新, 再結束本次batch.

呼叫 setState 後發生了什麼

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

// ReactBaseClasses.js :
ReactComponent.prototype.setState = function(partialState, callback) {
  this.updater.enqueueSetState(this, partialState);
  if (callback) {
    this.updater.enqueueCallback(this, callback, 'setState');
  }
};

// => ReactUpdateQueue.js:
enqueueSetState: function(publicInstance, partialState) {
    // 根據 this.setState 中的 this 拿到內部例項, 也就是元件例項
	var internalInstance = getInternalInstanceReadyForUpdate(publicInstance, 'setState');
    // 取得元件例項的_pendingStateQueue
    var queue =
      internalInstance._pendingStateQueue ||
      (internalInstance._pendingStateQueue = []);
    // 將partial state存到_pendingStateQueue
    queue.push(partialState);
	// 呼叫enqueueUpdate
    enqueueUpdate(internalInstance);
 }

// => ReactUpdate.js:
function enqueueUpdate(component) {
  ensureInjected(); // 注入預設策略
    
    // 如果沒有開啟batch(或當前batch已結束)就開啟一次batch再執行, 這通常發生在非同步回撥中呼叫 setState 	 // 的情況
  if (!batchingStrategy.isBatchingUpdates) {
    batchingStrategy.batchedUpdates(enqueueUpdate, component);
    return;
  }
    // 如果batch已經開啟就儲存更新
  dirtyComponents.push(component);
  if (component._updateBatchNumber == null) {
    component._updateBatchNumber = updateBatchNumber + 1;
  }
}

也就是說, 呼叫 setState 會首先拿到內部元件例項, 然後把要更新的partial state存到其_pendingStateQueue中, 然後標記當前元件為dirtyComponent, 存到dirtyComponents陣列中. 然後就接著繼續做下面的事情了, 並沒有立即更新, 這是因為接下來要執行的程式碼裡有可能還會呼叫 setState, 因此只做儲存處理.

什麼時候批量更新?

首先, 一個事務在執行的時候(包括initialize、perform、close階段), 任何一階段都有可能呼叫一系列函式, 並且開啟了另一些事務. 那麼只有等後續開啟的事務執行完, 之前開啟的事務才繼續執行. 下圖是我們剛才所說的第一種情況, 在初始渲染元件期間 setState 後, React 啟動的各種事務和執行的順序:

從圖中可以看到, 批量更新是在ReactDefaultBatchingStrategyTransaction事務的close階段, 在flushBatchedUpdates函式中啟動了ReactUpdatesFlushTransaction事務負責批量更新.

怎麼批量更新的?

開啟批量更新事務、批量處理callback

我們接著看flushBatchedUpdates函式, 在ReactUpdates.js中

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

var flushBatchedUpdates = function () {
  // 啟動批量更新事務
  while (dirtyComponents.length || asapEnqueued) {
    if (dirtyComponents.length) {
      var transaction = ReactUpdatesFlushTransaction.getPooled();
      transaction.perform(runBatchedUpdates, null, transaction);
      ReactUpdatesFlushTransaction.release(transaction);
    }
// 批量處理callback
    if (asapEnqueued) {
      asapEnqueued = false;
      var queue = asapCallbackQueue;
      asapCallbackQueue = CallbackQueue.getPooled();
      queue.notifyAll();
      CallbackQueue.release(queue);
    }
  }
};

遍歷dirtyComponents

flushBatchedUpdates啟動了一個更新事務, 這個事務執行了runBatchedUpdates進行批量更新:

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

// ReactUpdates.js
function runBatchedUpdates(transaction) {
  var len = transaction.dirtyComponentsLength;
  // 排序保證父元件優先於子元件更新
  dirtyComponents.sort(mountOrderComparator);

  // 代表批量更新的次數, 保證每個元件只更新一次
  updateBatchNumber++;
  // 遍歷 dirtyComponents
  for (var i = 0; i < len; i++) {
    var component = dirtyComponents[i];
      
    var callbacks = component._pendingCallbacks;
    component._pendingCallbacks = null;
    ...
    // 執行更新
    ReactReconciler.performUpdateIfNecessary(
      component,
      transaction.reconcileTransaction,
      updateBatchNumber,
    );
    ...
    // 儲存 callback以便後續按順序呼叫
    if (callbacks) {
      for (var j = 0; j < callbacks.length; j++) {
        transaction.callbackQueue.enqueue(
          callbacks[j],
          component.getPublicInstance(),
        );
      }
    }
  }
}

前面 setState 後將元件推入了dirtyComponents, 現在就是要遍歷dirtyComponents陣列進行更新了.

根據不同情況執行更新

ReactReconciler會呼叫元件例項的performUpdateIfNecessary. 如果接收了props, 就會呼叫此元件的receiveComponent, 再在裡面呼叫updateComponent更新元件; 如果沒有接受props, 但是有新的要更新的狀態(_pendingStateQueue不為空)就會直接呼叫updateComponent來更新:

1
2
3
4
5
6
7
8
9
10

// ReactCompositeComponent.js
performUpdateIfNecessary: function (transaction) {
    if (this._pendingElement != null) {
        ReactReconciler.receiveComponent(this, this._pendingElement, transaction, 				this._context);
    } else if (this._pendingStateQueue !== null || this._pendingForceUpdate) {
        this.updateComponent(transaction, this._currentElement, this._currentElement, 			this._context, this._context);
    } else {
        this._updateBatchNumber = null;
    }
}

呼叫元件例項的updateComponent

接下里就是重頭戲updateComponent了, 它決定了元件如果更新自己和它的後代們. 需要特別注意的是, React 內部三種不同的元件型別, 每種元件都有自己的updateComponent, 有不同的行為.

對於 ReactCompositeComponent (向量圖):

updateComponent所做的事情 :

  • 呼叫此層級元件的一系列生命週期函式, 並且在合適的時機更新props、state、context;
  • re-render, 與之前 render 的 element 比較, 如果兩者key && element.type 相等, 則進入下一層進行更新; 如果不等, 直接移除重新mount

對於 ReactDOMComponent:

updateComponent所做的事情 :

  • 更新這一層級DOM元素屬性;
  • 更新子元素, 呼叫 ReactMultiChild 的 updateChildren, 對比前後變化、標記變化型別、存到updates中(diff演算法主要部分);
  • 批量處理updates

對於 ReactDOMTextComponent :

上面只是每個元件自己更新的過程, 那麼 React 是如何一次性更新所有元件的 ? 答案是遞迴.

遞迴呼叫元件的updateComponent

觀察 ReactCompositeComponent 和 ReactDOMComponent 的更新流程, 我們發現 React 每次走到一個元件更新過程的最後部分, 都會有一個判斷 : 如果 nextELement 和 prevElement key 和 type 相等, 就會呼叫receiveComponent. receiveComponent和updateComponent一樣, 每種元件都有一個, 作用就相當於updateComponent 接受了新 props 的版本. 而這裡呼叫的就是子元素的receiveComponent, 進而進行子元素的更新, 於是就形成了遞迴更新、遞迴diff. 因此, 整個流程就像這樣(向量圖) :

這種更新完一級、diff完一級再進入下一級的過程保證 React 只遍歷一次元件樹就能完成更新, 但代價就是隻要前後 render 出元素的 type 和 key 有一個不同就刪除重造, 因此, React 建議頁面要儘量保持穩定的結構.

React 是如何對比出頁面變化最小的部分?

你可能會說 React 用 virtual DOM 表示了頁面結構, 每次更新, React 都會re-render出新的 virtual DOM, 再通過 diff 演算法對比出前後變化, 最後批量更新. 沒錯, 很好, 這就是大致過程, 但這裡存在著一些隱藏的深層問題值得探討 :

  • React 是如何用 virtual DOM 表示了頁面結構, 從而使任何頁面變化都能被 diff 出來?
  • React 是如何 diff 出頁面變化最小的部分?

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
25
26
27
28
29
30

class C extends React.Component {
    render () {
        return (
            <div className='container'>
                  "dscsdcsd"
                  <i onClick={(e) => console.log(e)}>{this.state.val}</i>
                  <Children val={this.state.val}/>
            </div>
        )
    }
}
// virtual DOM(React element)
{
  $$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: ReactCompositeComponentWrapper {...} // class C 例項化後的物件
  _store: {validated: false}
  _self: null
  _source: null
}

每個標籤, 無論是DOM元素還是自定義元件, 都會有 key、type、props、ref 等屬性.

  • key 代表元素唯一id值, 意味著只要id改變, 就算前後元素種類相同, 元素也肯定不一樣了;
  • type 代表元素種類, 有 function(空的wrapper)、class(自定義類)、string(具體的DOM元素名稱)型別, 與key一樣, 只要改變, 元素肯定不一樣;
  • props 是元素的屬性, 任何寫在標籤上的屬性(如className=’container’)都會被存在這裡, 如果這個元素有子元素(包括文字內容), props就會有children屬性, 儲存子元素; children屬性是遞迴插入、遞迴更新的依據;

也就是說, 如果元素唯一識別符號或者類別或者屬性有變化, 那麼它們re-render後對應的 key、type 和props裡面的屬性也會改變, 前後一對比即可找出變化. 綜上來看, React 這麼表示頁面結構確實能夠反映前後所有變化.

那麼 React 是如何 diff 的?

React diff 每次只對同一層級的節點進行比對 :

上圖的數字表示遍歷更新的次序.

從父節點開始, 每一層 diff 包括兩個地方

  • element diff—— 前後 render 出來的 element 的對比, 這個對比是為了找出前後節點是不是同一節點, 會對比前後render出來的元素它們的 key 和 type. element diff 包括兩個地方, 元件頂層DOM元素對比和子元素的對比:

    元件頂層DOM元素對比 :

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

    // ReactCompositeComponent.js/updateComponent => _updateRenderedComponent
_updateRenderedComponent: function(transaction, context) {
    // re-render 出element
	var nextRenderedElement = this._renderValidatedComponent();
	// 對比前後變化
    if (shouldUpdateReactComponent(prevRenderedElement, nextRenderedElement)) {
      // 如果 key && type 沒變進行下一級更新
      ReactReconciler.receiveComponent(...);
    } else {
      // 如果變了移除重造
      ReactReconciler.unmountComponent(prevComponentInstance, false);
      ...
      var child = this._instantiateReactComponent(...);
  
      var nextMarkup = ReactReconciler.mountComponent(...);
      this._replaceNodeWithMarkup(...);
    }
}

    子元素的對比:

    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

    // ReactChildReconciler.js
updateChildren: function(...) {
    ...
    for (name in nextChildren) {  // 遍歷 re-render 出的elements
      ...
      if (
        prevChild != null &&
        shouldUpdateReactComponent(prevElement, nextElement)
      ) {
        // 如果key && type 沒變進行下一級更新
        ReactReconciler.receiveComponent(...);  
        nextChildren[name] = prevChild;  // 更新完放入 nextChildren, 注意放入的是元件例項
      } else {
        // 如果變了則移除重建                               
        if (prevChild) {
          removedNodes[name] = ReactReconciler.getHostNode(prevChild);
          ReactReconciler.unmountComponent(prevChild, false);
        }
        var nextChildInstance = instantiateReactComponent(nextElement, true);
        nextChildren[name] = nextChildInstance;
          
        var nextChildMountImage = ReactReconciler.mountComponent(...);
        mountImages.push(nextChildMountImage);
      }
    }
    // 再除掉 prevChildren 裡有, nextChildren 裡沒有的元件
    for (name in prevChildren) {
      if (
        prevChildren.hasOwnProperty(name) &&
        !(nextChildren && nextChildren.hasOwnProperty(name))
      ) {
        prevChild = prevChildren[name];
        removedNodes[name] = ReactReconciler.getHostNode(prevChild);
        ReactReconciler.unmountComponent(prevChild, false);
      }
    }
  },

    shouldComponentUpdate 函式:

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

    function shouldUpdateReactComponent(prevElement, nextElement) {
  
  var prevEmpty = prevElement === null || prevElement === false;
  var nextEmpty = nextElement === null || nextElement === false;
  if (prevEmpty || nextEmpty) {
    return prevEmpty === nextEmpty;
  }

  var prevType = typeof prevElement;
  var nextType = typeof nextElement;
  // 如果前後變化都是字串、數字型別的則允許更新
  if (prevType === 'string' || prevType === 'number') {
    return nextType === 'string' || nextType === 'number';
  } else {
    // 否則檢查 type && key
    return (
      nextType === 'object' &&
      prevElement.type === nextElement.type &&
      prevElement.key === nextElement.key
    );
  }
}

    element diff 檢測 type && key 都沒變時會進入下一級更新, 如果變化則直接移除重造新元素, 然後遍歷同級的下一個.

  • subtree diff ——元件頂層DOM元素包裹的所有子元素(也就是props.children裡的元素)與之前版本的對比, 這個對比是為了找出同級所有子節點的變化, 包括移除、新建、同級範圍的移動;

    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

    // ReactMultiChild.js
_updateChildren: function(...) {
      var prevChildren = this._renderedChildren;
      var removedNodes = {};
      var mountImages = [];
      // 拿到更新後子元件例項
      var nextChildren = this._reconcilerUpdateChildren();
      ...
      // 遍歷子元件例項
      for (name in nextChildren) {
   		...
        var prevChild = prevChildren && prevChildren[name];
        var nextChild = nextChildren[name];
        // 因為子元件的更新是在原元件例項上更改的, 因此與之前的元件作引用比較即可判斷
        if (prevChild === nextChild) {
            // 發生了移動
          updates = enqueue(
            updates,
            this.moveChild(prevChild, lastPlacedNode, nextIndex, lastIndex),
          );
          lastIndex = Math.max(prevChild._mountIndex, lastIndex);
          prevChild._mountIndex = nextIndex;
        } else {
          ...
          // 有新的元件
          updates = enqueue(
            updates,
            this._mountChildAtIndex(
              nextChild,
              mountImages[nextMountIndex],
              lastPlacedNode,
              nextIndex,
              transaction,
              context,
            ),
          );
          nextMountIndex++;
        }
        nextIndex++;
        lastPlacedNode = ReactReconciler.getHostNode(nextChild);
      }
      // Remove children that are no longer present.
      for (name in removedNodes) {
          // removedNodes 記錄了所有的移除節點
        if (removedNodes.hasOwnProperty(name)) {
          updates = enqueue(
            updates,
            this._unmountChild(prevChildren[name], removedNodes[name]),
          );
        }
      }
      if (updates) {
        processQueue(this, updates); // 批量處理
      }
      this._renderedChildren = nextChildren;
    },

    React 會將同一層級的變化標記, 如 MOVE_EXISTING、REMOVE_NODE、TEXT_CONTENT、INSERT_MARKUP 等, 統一放到 updates 陣列中然後批量處理.

And that‘s it !

React 是一個激動人心的庫, 它給我們帶來了前所未有的開發體驗, 但當我們沉浸在使用 React 快速實現需求的喜悅中時, 有必要去探究兩個問題 : Why and How?

為什麼 React 會如此流行, 原因是什麼? 元件化、快速、足夠簡單、all in js、容易擴充套件、生態豐富、社群強大…

React 反映了哪些思想/理念/思路 ? 狀態機、webComponents、virtual DOM、virtual stack、非同步渲染、多端渲染、單向資料流、反應式更新、函數語言程式設計…

React 這些理念/思路受什麼啟發 ? 怎麼想到的 ? 又怎麼實現的? …

相關推薦

React原始碼分析(三)-全面剖析元件更新機制

React 把元件看作狀態機(有限狀態機), 使用state來控制本地狀態, 使用props來傳遞狀態. 前面我們探討了 React 如何對映狀態到 UI 上(初始渲染), 那麼接下來我們談談 React 時如何同步狀態到 UI 上的, 也就是: React 是如何更新

React原始碼分析(二)-元件的初始渲染

上一篇文章講到了React 呼叫ReactDOM.render首次渲染元件的前幾個過程的原始碼, 包括建立元素、根據元素例項化對應元件, 利用事務來進行批量更新. 我們還穿插介紹了React 事務的實現以及如何利用事務進行批量更新的實現. 這篇文章我們接著分析後面的過程,

React原始碼分析2 — 元件和物件的建立（createClass，createElement）

1 元件的建立 React受大家歡迎的一個重要原因就是可以自定義元件。這樣的一方面可以複用開發好的元件，實現一處開發，處處呼叫，另外也能使用別人開發好的元件，提高封裝性。另一方面使得程式碼結構很清晰，元件間耦合減少，方便維護。ES5建立元件時，呼叫React.

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

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

React-Native-原始碼分析三-JSX如何渲染成原生頁面(下)

前文中這次會反推JSX如何最終變化為原生控制元件的過程，上面這部分算是原生的繪製已經結束，下面開始到JS程式碼中找，JSX佈局如何傳達到原生的。 經驗之談：要憑藉我的半吊子js和C水平要去扒拉React-Native js部分的程式碼，也是夠吃力的，但是我找到

NSQ原始碼分析(三)——disQueue

disQueue是Topic以及Channel中的記憶體訊息滿了以後，訊息存放的實現方法，diskQueue實現了檔案系統支援的FIFO佇列，disQueue也是BackendQueue介面的實現，diskQueue在檔案讀寫給我們提供了很好的學習示例。 BackendQueue介面 //

區塊鏈教程Fabric1.0原始碼分析configupdate處理通道配置更新

　　區塊鏈教程Fabric1.0原始碼分析configupdate處理通道配置更新，2018年下半年，區塊鏈行業正逐漸褪去發展之初的浮躁、迴歸理性，表面上看相關人才需求與身價似乎正在回落。但事實上，正是初期泡沫的漸退，讓人們更多的關注點放在了區塊鏈真正的技術之上。 Fabric 1.0原始碼筆記 之 Ord

Django rest framework 限制訪問頻率(原始碼分析三)

  基於  當用發出請求時 首先執行dispatch函式，當執行當第二部時： #2.處理版本資訊 處理認證資訊 處理許可權資訊 對使用者的訪問頻率進行限制 self.initial(request, *args, **kwargs)

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

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

React原始碼分析之事件系統

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

Vue provide/inject 部分原始碼分析 實現響應式資料更新

下面是我自己曾經遇到 一個問題，直接以自己QA的形式來寫吧 官網給出例項，說本身是不支援資料響應式的， 但是可以傳入響應式資料，那麼provide,inject就可以實現響應式。我這裡理解應該沒錯哈，有不對的地方請指出。 我自己寫的demo,做了如下更改 parent 頁面： export def

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

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

原始碼分析三、Map（3）-TreeMap

一、概述 通過IDEA看下TreeMap的繼承關係，繼承抽象父類AbstractMap，實現了NavigableMap介面，SortedMap介面，TreeMap是一種有序的Map，從其實現的介面就能看出來。 那麼，首先來看下實現的兩類介面： SortedMap：實

RabbitMQ客戶端原始碼分析(三)之Command

RabbitMQ-java-client版本 com.rabbitmq:amqp-client:4.3.0 RabbitMQ版本宣告: 3.6.15 Command Command介面是AMQP方法-引數的容器介面，帶有可選的內容頭(content

JDK1.8集合框架原始碼分析三-------------HashMap

1.HashMap的一些重要成員屬性       1.1) 預設的初始容量 DEFAULT_INITIAL_CAPACITY = 1 << 4，官方建議必須時2的次方數       1.2) 負載因子

原始碼分析篇之String原始碼分析三

    上期已經討論了比較器的相關的問題。同時也提出問題明明父類已經實現了某個介面，子類為什麼還是要實現同樣的介面呢。這究竟有什麼意義呢。通過使用度孃的多次探究之後最終我還是沒有發現說它有什麼特別的含義。我認為的最大的含義就是告訴使用者這個類實現了這樣的一個介面。方便使用者進

spring原始碼分析三 bean的載入

配置檔案 <?xml version="1.0" encoding="UTF-8"?> <beans xmlns="http://www.springframework.org/schema/beans" xmlns:xsi="h

Spring 原始碼分析(三) —— AOP（一）AOP原理

AOP概論         AOP（Aspect-Oriented Programming，面向切面的程式設計），談起AOP，則一定會追溯到OOP（Object Oriented Programming,面向物件程式設計），因為AOP可以說是對OOP的補充和完善，而這一切的

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

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

Android觸控式螢幕事件派發機制詳解與原始碼分析三(Activity篇)

PS一句：最終還是選擇CSDN來整理髮表這幾年的知識點，該文章平行遷移到CSDN。因為CSDN也支援MarkDown語法了，牛逼啊！ 【工匠若水 http://blog.csdn.net/yanbober】 該篇承接上一篇《Android觸控式螢幕事件派發機制詳解與原始碼分析