摘要：場景為了多維度掌控嫌疑犯的犯罪特征數(shù)據(jù)，你警署最高長官想要獲取并實(shí)時監(jiān)控張三的貸款數(shù)額存貸比存款和貸款兩者比率的變化。

================前言===================

初衷：以系列故事的方式展現(xiàn) MobX 源碼邏輯，盡可能以易懂的方式講解源碼；

本系列文章：

《【用故事解讀 MobX源碼（一）】 autorun》

《【用故事解讀 MobX源碼（二）】 computed》

《【用故事解讀 MobX源碼（三）】 shouldCompute》

《【用故事解讀 MobX 源碼（四）】裝飾器 和 Enhancer》

《【用故事解讀 MobX 源碼（五）】 Observable》

文章編排：每篇文章分成兩大段，第一大段以簡單的偵探系列故事的形式講解（所涉及人物、場景都以 MobX 中的概念為原型創(chuàng)建），第二大段則是相對于的源碼講解。

本文基于 MobX 4 源碼講解

=======================================

在寫本文的時候，由于 MobX 以及升級到 4.x，API 有較大的變化，因此后續(xù)的文章默認(rèn)都將基于 4.x 以上版本進(jìn)行源碼閱讀。

前一篇文章仍然以 mobx v3.5.1 的源碼，autorun 邏輯在新版中沒有更改，因此源碼邏輯仍舊一致。

為了多維度掌控嫌疑犯的犯罪特征數(shù)據(jù)，你（警署最高長官）想要獲取并實(shí)時監(jiān)控張三的 貸款數(shù)額、存貸比（存款和貸款兩者比率） 的變化。

于是你就擬定了新的命令給執(zhí)行官 MobX：

var bankUser = mobx.observable({
  income: 3,
  debit: 2
});

var divisor = mobx.computed(() => {
  return bankUser.income / bankUser.debit;
});

mobx.autorun(() => {
  console.log("張三的貸款：", bankUser.debit, "；張三的存貸比: " + divisor);
});

相比上一次的命令，除了監(jiān)控張三貸款這項(xiàng)直接的指標(biāo)，還需要監(jiān)控 貸款比（divisor） 這項(xiàng)間接指標(biāo)。

執(zhí)行官 MobX 稍作思忖，要完成這個任務(wù)比之前的要難一點(diǎn)點(diǎn)，需要費(fèi)一點(diǎn)兒精力。

不過，這也難不倒能力強(qiáng)大的 MobX 執(zhí)行官，一番策略調(diào)整之后，重新拿出新的執(zhí)行方案。部署實(shí)施之后，當(dāng)張三去銀行存款、貸款后，這些變化都實(shí)時反饋出來了：

這次的部署和前一次相差不大，除了需要讓觀察員 O2（監(jiān)視 income）參與進(jìn)來之外，考慮到警署最高長官所需的 存貸比 （divisor），還得派出另一類職員 —— 會計(jì)師：

會計(jì)師：此類職員專門負(fù)責(zé)計(jì)算，從事 數(shù)據(jù)的再加工（此項(xiàng)任務(wù)中，就是搜集數(shù)據(jù)并計(jì)算 存貸比）

會計(jì)師是一個很有意思的角色，要想理解他們，必須得思考他們的數(shù)據(jù)“從哪兒來？到哪里去？” 這兩個問題：

從哪兒來：從觀察員那兒獲取，也可以從其他會計(jì)師那兒獲取；

到哪兒去：所生產(chǎn)的數(shù)據(jù)，要么是被探長消費(fèi)，要么被其他會計(jì)師所用；（當(dāng)然，沒有人消費(fèi)他所生產(chǎn)的數(shù)據(jù)也是可能的，不過這就得追究 MobX 執(zhí)行官的責(zé)任了，浪費(fèi)了人力資源）

引入了會計(jì)師角色之后，MobX 執(zhí)行官重新繪制了部署計(jì)劃圖：

解釋一下此計(jì)劃圖的意思：

明確此次任務(wù)是 當(dāng)張三賬戶存款或者貸款變更時，打印其貸款數(shù)額（debit）和存貸比（divisor）：

() => {
  console.log("張三的貸款：", bankUser.debit, "；張三的存貸比: " + divisor);
}

將任務(wù)指派給執(zhí)行組中的探長 R1

派遣 2 名觀察組中的觀察員 O1、O2 分別監(jiān)察張三賬戶的 bankUser.income 屬性和 bankUser.debit 屬性；

派遣計(jì)算組中的會計(jì)師 C1 計(jì)算張三的貸款比，其所需數(shù)值來源于觀察員 O1、O2；

探長 R1 任務(wù)中所需的“張三的賬戶存款” 數(shù)值從觀察員 O2 那兒獲取；所需的 “張三的存貸比” 數(shù)值從會計(jì)師 C1 那兒獲取；

同時架設(shè)數(shù)據(jù)情報室，方便信息交換；

因?yàn)檫€是 autorun 命令，所以仍然執(zhí)行 A計(jì)劃方案（詳情參考上一篇《【用故事解讀 MobX源碼（一）】 autorun》）MobX 執(zhí)行官的部署方案從整體上看是一樣的，考慮到多了會計(jì)師這個角色的參與，所以特意在探長 獲取存貸比（divisor） 邏輯處空出一部分留給會計(jì)師讓它自由發(fā)揮：

這樣做，MobX 執(zhí)行官也為了在實(shí)際行動中向他的警署長官證實(shí)該 A計(jì)劃方案 的確擁有“良好的擴(kuò)展性”。

解開這層新增的會計(jì)師計(jì)算邏輯 “面紗”，圖示如下：

你會發(fā)現(xiàn)歷史總是驚人的相似，新增的會計(jì)師執(zhí)行計(jì)算任務(wù)的邏輯其實(shí) 探長 執(zhí)行任務(wù)的邏輯是一樣的，下圖中我特意用 相同的序號（不同的顏色形狀）標(biāo)示 出，序號所對應(yīng)含義如下：

設(shè)置成 正在執(zhí)勤人員

開始執(zhí)行任務(wù)

從觀察員或會計(jì)師那兒獲取執(zhí)行任務(wù)所需的數(shù)值，并同他們?nèi)〉寐?lián)系，

計(jì)算任務(wù)執(zhí)行完成后，更新與觀察員 O1、觀察員 O2 之間的聯(lián)系；

此執(zhí)行計(jì)算任務(wù)的邏輯，如果不告訴觀察員的話，觀察員還以為又來了一名“探長”上級。?

從部署圖里我們可以看出會計(jì)師具有兩面性；

對探長而言：會計(jì)師和觀察員地位差不多，都屬于“下級”，都需要將自己的信息及時反饋給探長；

對觀察員而言：會計(jì)師是屬于 “上級”，擁有部分類似探長執(zhí)行任務(wù)權(quán)力，只不過其任務(wù)類型只能是 計(jì)算類型的任務(wù)，執(zhí)行任務(wù)結(jié)束之后，像探長那樣和觀察員互相關(guān)聯(lián)起來，方便下一次的運(yùn)算；

自從有了會計(jì)師的參與，探長還是那個探長，但他的下級已經(jīng)不是之前的下級了。借助 A計(jì)劃任務(wù)的執(zhí)行，會計(jì)師 C1 在上報計(jì)算值的時候，會順?biāo)浦鄣貓?zhí)行計(jì)算任務(wù)，同時更新他的 ”關(guān)系網(wǎng)“。

會計(jì)師有一個特性就是比較懶：就算觀察員所觀察到的值變更了，他們也不會立即重新計(jì)算，而只在必要的時候（比如當(dāng)上級前來索取時）才會重新計(jì)算。

舉個例子，當(dāng)觀察員 O1 發(fā)現(xiàn)張三的賬戶存款從原來的 3 變成 6 ：

bankUser.income = 6;

這個時候會觸發(fā)一系列的 “漣漪”：

① 觀察員 O1 先注冊事務(wù)，相當(dāng)于到數(shù)據(jù)情報室”上班打卡“，聲明這次事件由 觀察員 O1 主導(dǎo)

② 告知其上級，也就是會計(jì)師 C1 ，說是張三存款（income）有變更

③ 會計(jì)師 C1 獲知消息后，”慵懶地“調(diào)整自己的狀態(tài)

④ 隨后會計(jì)師 C1 繼續(xù)往上級匯報，告知本會計(jì)師的值有更改（注意，此時會計(jì)師只是告訴上級自己的值有更改這一事實(shí)，但并沒有執(zhí)行計(jì)算任務(wù) ?。?/p>

⑤ 探長 R1 接收到會計(jì)師的反饋后，就向 MobX 執(zhí)行官申請要執(zhí)行任務(wù)！因?yàn)槠湎录墪?jì)師 C1 匯報說值有更改，說明這個時候應(yīng)該要重新執(zhí)行任務(wù)啦~

⑥ 執(zhí)行官 MobX 調(diào)閱數(shù)據(jù)情報室信息一看，發(fā)現(xiàn)目前觀察員 O1 正在執(zhí)行事務(wù)，就讓探長 R1 再等等，現(xiàn)在不是執(zhí)行任務(wù)的最佳時機(jī)，等到事務(wù)結(jié)束再說。

⑦ 不一會兒觀察員 O1 完成了自己的職責(zé)，”下班打卡“，在數(shù)據(jù)情報室中注銷事務(wù)

⑧ 這個時候，執(zhí)行官 MobX 才讓探長 R1 開始執(zhí)行任務(wù)

將上面的文字轉(zhuǎn)換成流程圖，可以清晰看到各角色在這次“漣漪”中所起到的作用：

這里需要注意 3 點(diǎn)：

當(dāng)觀察員O1 匯報張三存款有更改的時候，會計(jì)師 C1 并沒有立即重新計(jì)算值哦，僅僅是更改自身的狀態(tài)；

會計(jì)師告知上級（探長 R1）自己有值更改，探長申請執(zhí)行任務(wù)，不過 MobX 執(zhí)行官并沒有允許他這么做，而是讓他先等待一下，因?yàn)榇藭r 觀察員 O1 還在匯報工作。等觀察員 O1 工作匯報完畢，這個時候才讓探長執(zhí)行任務(wù)。因?yàn)橛锌赡苡衅渌?jì)算組職員也正在響應(yīng)該觀察值的更改，事情一件一件來，不要著急，這和 debounce 思想一致，減少不必要的計(jì)算。

只有在最后探長執(zhí)行任務(wù)時 需要用到會計(jì)師的值的時候，會計(jì)師才會去執(zhí)行計(jì)算操作。這就是典型的惰性求值思維。

會計(jì)師這種拖延到 只有被需要的時候才進(jìn)行計(jì)算 的行為，有沒有讓你回憶起學(xué)生時代寒假結(jié)束前一天瘋狂補(bǔ)作業(yè)的場景？?

當(dāng)執(zhí)行官 MobX 拿著這份執(zhí)行報告送達(dá)給你（警署最高長官），閱覽完畢：”不錯，這套方案的確部分證實(shí)了你之前所言的可擴(kuò)展性。但隨著職員的引入，運(yùn)轉(zhuǎn)機(jī)構(gòu)逐漸龐大，如何避免不必要的開銷的呢？“

”長官您高瞻遠(yuǎn)矚，這的確是一個問題。在井然有序的規(guī)則下，個別職員的運(yùn)作效率的確會打折扣。因此避免職員不必要的計(jì)算開銷，也是在我方案部署規(guī)劃之內(nèi)。正如您所見，上述方案中會計(jì)師的‘惰性’、探員在事務(wù)之后再進(jìn)行任務(wù)等機(jī)制，都是基于優(yōu)化性能所采取的措施?！?執(zhí)行官 MobX 稍作停頓，繼續(xù)道，”為了更好地闡述這套運(yùn)行方案的性能優(yōu)化機(jī)制，我明天呈上一份報告，好讓您得以全面了解。“

”Good Job！期待你的報告“。

那么，執(zhí)行官 MobX 是憑借什么機(jī)制減少開銷的呢？且聽下回分解。
（本節(jié)完，未完待續(xù)）

本節(jié)部分，仍然是就著上面的”故事“來講 MobX 中的源碼。

先羅列本文故事中新出現(xiàn)的 會計(jì)師 角色與 MobX 源碼概念映射關(guān)系：

探長、執(zhí)行官等角色的映射關(guān)系，參考上一篇《【用故事解讀 MobX源碼（一）】 autorun》

本文的重點(diǎn)內(nèi)容就是 computedvalue 的部分源碼（它在 autorun 等場景中的應(yīng)用）

autorun（A 計(jì)劃）的源碼在上一節(jié)講過，這里不再贅述。我們僅僅講解一下 computedValue 在 autorun 中的表現(xiàn)。

在故事中我們講到過，當(dāng)探長向會計(jì)師索要計(jì)算值的時候，此時懶惰的會計(jì)師為了 ”應(yīng)付交差“，這時候才開始計(jì)算，其計(jì)算的過程和探長執(zhí)行的任務(wù)流程幾乎一致。

從源碼角度去看一下其中的原因。

當(dāng)探長執(zhí)行任務(wù)：

() => {
  console.log("張三的貸款：", bankUser.debit, "；張三的存貸比: " + divisor);
}

任務(wù)中也涉及 bankUser.debit 變量和 divisor 變量；其中在獲取 bankUser.debit 變量之時會讓觀察員 O2 觸發(fā) reportObserved方法，這個上一篇文章著重講過，此處就不詳細(xì)展開了；而請求 divisor 數(shù)值的時候，則會觸發(fā)該值的 valueOf() 方法 —— 即調(diào)用會計(jì)師（computedValue）的 valueOf() 方法。

為什么調(diào)用就觸發(fā) valueOf() 方法呢？請看下方的“知識點(diǎn)”備注?

======== 插播知識點(diǎn) =========
任何原始值還是對象其實(shí)都包含 valueOf() 或 toString() 方法，valueOf() 會返回最適合該對象類型的原始值，toString() 將該對象的原始值以字符串形式返回。
這兩個方法一般是交由 JS 去隱式調(diào)用，以滿足不同的運(yùn)算情況。比如在數(shù)值運(yùn)算（如a + b）里會優(yōu)先調(diào)用 valueOf()，而在字符串運(yùn)算（如alert(c)）里，會優(yōu)先調(diào)用 toString() 方法
順帶附上兩篇 參考文章

js中 toString 和 valueOf 的區(qū)別？：知乎問答

valueOf() vs. toString() in Javascript：SF 上的回答，非常詳盡地告訴你其執(zhí)行結(jié)果

======== 完畢 ==========

一旦調(diào)用調(diào)用會計(jì)師的 valueOf 方法：

valueOf(): T {
    return toPrimitive(this.get())
}

其實(shí)就是調(diào)用 this.get() 方法，我們瞧一眼源碼；

這里有個分叉點(diǎn)，根據(jù) globalState.inBatch 決定到底是啟用 重量級計(jì)算 還是 輕量級計(jì)算：

當(dāng) globalState.inBatch 值大于 0，說明會計(jì)師被上級征調(diào)（處于上級事務(wù)中），比如此案例中，陷于 A 計(jì)劃（autorun ）的會計(jì)師，在上級探長 R1 需要查閱計(jì)算值時候，就會進(jìn)入重量級計(jì)算模式

當(dāng)會計(jì)師無上級征調(diào)的時候，globalState.inBatch 值為 0，就會進(jìn)入輕量級計(jì)算模式，簡化計(jì)算的邏輯。

但無論輕量級還是重量級計(jì)算，都會涉及到調(diào)用 computeValue() 方法來執(zhí)行計(jì)算任務(wù)。

調(diào)用的時候，如果是 重量級計(jì)算 則 track 這個 bool 值為 true，否則track 值為 false。

計(jì)算值有個屬性，this.derivation 就是會計(jì)師要計(jì)算數(shù)值時所依據(jù)的計(jì)算表達(dá)式，也就是而我們定義會計(jì)師時所傳入的匿名函數(shù)：

() => {
  return bankUser.income / bankUser.debit;
}

無論是 重量級計(jì)算 模式還是 輕量級計(jì)算 模式，最終都是會調(diào)用該計(jì)算表達(dá)式獲取計(jì)算值。

重量級計(jì)算 模式和 輕量級計(jì)算 模式兩者的差別只是在于前者在執(zhí)行該計(jì)算表達(dá)式之前會設(shè)置很多環(huán)境，后者直接就按這個表達(dá)式計(jì)算數(shù)值返回。

在上述的故事中，由于探長 R1 人物的存在，會計(jì)師會執(zhí)行 重量級計(jì)算 模式，接下來的源碼分析也走這條分支路線。（ 輕量級計(jì)算 模式的情況當(dāng)做課后思考題）。

在 重量級計(jì)算的時候，computeValue(true) 就會走和 探長 操作模式一樣 trackDerivedFunction 步驟。沒錯，探長和會計(jì)師調(diào)用的就是同一個方法，所以他們在執(zhí)行任務(wù)的時候，行為痕跡是一樣的，沒毛病。

如果忘記 trackDerivedFunction 方法內(nèi)容，請查看 《【用故事解讀 MobX源碼（一）】 autorun》的 ”2.2.2、trackDerivedFunction“ 部分

只不過會計(jì)師只能執(zhí)行計(jì)算類的任務(wù)（純函數(shù)）罷了，探長可以執(zhí)行任意類型的任務(wù)。

和探長一樣，會計(jì)師執(zhí)行計(jì)算任務(wù)完畢之后調(diào)用 bindDependencies 將綁定 觀察員 O1 和 觀察員 O2 ；而在執(zhí)行計(jì)算之后，會計(jì)師會調(diào)用 propagateChangeConfirmed 方法，更改自己和上級 探長 的狀態(tài) —— 這說明，對探長而言，會計(jì)師就相當(dāng)于 觀察員的角色，在探長執(zhí)行任務(wù)結(jié)束后像觀察員一樣需要上報自己的計(jì)算值，并和 探長 取得聯(lián)系；

這么看會計(jì)師還真 ”墻頭草，兩邊倒”。

至此，會計(jì)師這個角色以較低的成本就能完美地整合進(jìn)執(zhí)行官 MobX 所部署的 A 集合部署方案中。??

一旦張三的賬戶存款（income）發(fā)生變化，將會觸發(fā) MobX 所提供的 reportChanged 方法：

  public reportChanged() {
      startBatch()
      propagateChanged(this)
      endBatch()
  }

注意這里的 startBatch 和 endBatch 方法，說明觀察員 O1 發(fā)起事務(wù)了。

我們知道（不知道的請閱讀上一篇文章）該 reportChanged() 方法中的 propagateChanged() 會觸發(fā)上級的 onBecomeStale() 方法。

觀察員 O1 此時的上級是 會計(jì)師 C1，其所定義的 onBecomeStale 如下：

onBecomeStale() {
    propagateMaybeChanged(this)
}

看一下 propagateMaybeChanged(this) 源碼，也比較簡單，主要做了兩件事情，① 會計(jì)師會調(diào)整自身的狀態(tài)； ②然后觸發(fā)其上級（探長 R1）的 onBecomeStale() 方法。

可見觀察員 01 會引起會計(jì)師 C1 的響應(yīng)，而會計(jì)師會引起探長 R1 的響應(yīng)，這種響應(yīng)“漣漪”就是通過下級觸發(fā)上級的 onBecomeStale 方法形成的連鎖反應(yīng)。

不同上級（比如會計(jì)師和探長）的 onBecomeStale 定義不同。

探長的這個 onBecomeStale 方法在上一篇文章的 “3、響應(yīng)觀察值的變化 - propagateChanged” 中我們講過，探長將請求 MobX 請求重新執(zhí)行一遍 A 計(jì)劃方案。

然而，MobX 拒絕了這次請求，讓他再等待一下。??

這是因?yàn)樵?runReactions 方法中：

if (globalState.inBatch > 0 || globalState.isRunningReactions) return

由于此時 inBatch 是 1（因?yàn)橛^察員執(zhí)行了 startBatch()），所以會直接 return 掉。

直到觀察員執(zhí)行 endBatch() 的時候，除了會結(jié)束本次的上報事務(wù)，同時執(zhí)行官 MobX 會重新執(zhí)行 runReactions 方法，讓久等的探長去執(zhí)行任務(wù)：

探長在執(zhí)行任務(wù)的時候，就會打印張三的貸款（debit）、存貸比（divisor）了。

綜上，當(dāng)張三存款（income）變更，就能讓 A 計(jì)劃（autorun）自動運(yùn)行，探長會打印張三的貸款（debit）、存貸比（divisor）。

這里需要提及一下，關(guān)于會計(jì)師重新計(jì)算的時機(jī)，是在探長執(zhí)行 shouldCompute 的時候，探長發(fā)現(xiàn)會計(jì)師值 陳舊 了，就讓會計(jì)師重新計(jì)算：

看看這里，對計(jì)算值而言，isComputedValue()（如果是計(jì)算值）返回 true，就會執(zhí)行 obj.get() 方法，這個方法剛才剛講過，會讓會計(jì)師執(zhí)行 重量型計(jì)算操作，更新自己的計(jì)算值。

所以，這次計(jì)算時機(jī)并非等到探長執(zhí)行任務(wù)時（真正用到該值）的時候才讓其重新計(jì)算，和第一次 autorun 的時機(jī)不一致。

估計(jì)這是 MobX 考慮到會計(jì)師的值肯定需要更新的（已經(jīng)確定要被探長 R1 用到），還有可能會被其他上級引用，既然遲早要更新的，那就盡可能將更新前置，這樣在整體上能降低成本。

更新完之后，在探長執(zhí)行任務(wù)的時候，會計(jì)師匯報自己是最新的值了，就不用再重新計(jì)算一遍。

雖然懶，但是懶得有技巧。

至此，有關(guān)會計(jì)師的源碼解讀已經(jīng)差不多，后續(xù)有想到的再補(bǔ)充。

本文為了方便說明，所以多帶帶使用 mobx.computed 方法定義計(jì)算值，平時使用中更多則是直接應(yīng)用在 對象中屬性 上，使用 get 語法：

var bankUser = mobx.observable({
  income: 3,
  debit: 2,
  get divisor() {
    return this.income / this.debit;
  }
});

這僅僅是寫法上不一樣，源碼分析的思路是一致的。

問題：當(dāng)我們更改張三貸款數(shù)額 bankUser.debit = 4; 時，請從源碼角度解答 MobX 的執(zhí)行流程是如何的？

參考答案提示：

reportChanged() 
    => propagateChanged() 
    => propagateMaybeChanged() 
    => runReaction() 
    => track() 
    => get() 
    => computeValue() 
    => bindDependencies()

問題：如果不存在 autorun （即沒有探長參與，僅有觀察員和會計(jì)師），此時僅改變張三存款數(shù)值：

var bankUser = mobx.observable({
  income: 3,
  debit: 2
});

var divisor = mobx.computed(() => {
  return bankUser.income / bankUser.debit;
});

bankUser.income = 6; // 請問此時的執(zhí)行情況是什么樣的？

console.log("張三的存貸比：", divisor)

請問會計(jì)師會重新計(jì)算數(shù)值么？此時這套系統(tǒng)的執(zhí)行情況又會是怎么樣的呢？

參考答案提示：會計(jì)師此時執(zhí)行 輕量級計(jì)算模式。

此篇文章講解 MobX 中 計(jì)算值 （computedValue） 的概念，類比故事中的會計(jì)師角色?？偨Y(jié)一下 計(jì)算值 （computedValue）的特征：

計(jì)算值是基于現(xiàn)有狀態(tài)或其他計(jì)算值衍生出的數(shù)值，一般是通過 純函數(shù) 的方式衍生而得。

一旦觀察值更改之后，計(jì)算值是能夠重新執(zhí)行計(jì)算，不過并非立即執(zhí)行，而是 惰性 的 ———— 只有在必要的時候才會執(zhí)行計(jì)算。

對觀察值而言，計(jì)算值和 autorun（或reaction） 很像，之所以相似是在 執(zhí)行任務(wù) 時都涉及到調(diào)用 trackDerivedFunction 方法；而對 autorun（或reaction）而言，計(jì)算值和觀察值很相，都是數(shù)據(jù)提供者。

正如 官方文檔 而言，計(jì)算值是高度優(yōu)化過的，所以盡可能應(yīng)用他們。

下一篇文章將探討 MobX 中與 autorun 和 computed 相關(guān)的計(jì)算性能優(yōu)化的機(jī)制，看看 MobX 如何平衡復(fù)雜場景下狀態(tài)管理時的效率和性能。

下面的是我的公眾號二維碼圖片，歡迎關(guān)注，及時獲取最新技術(shù)文章。