這個遞歸不太難

這個遞歸不太難

相信你們都知道什麼是遞歸，但在實際開發的時候用過多少次遞歸呢？

程序的世界有句話叫「人用循環，神用遞歸」，不少狀況下咱們都會優先使用循環而不是遞歸。我和幾個朋友聊過，他們的見解是：「相比循環而言，遞歸性能更差，並且更不可控，容易出問題。」

捕獲關鍵詞「問題」，啓動「解決」模式...

1、先熱個身

數學家高斯的在念小學的時候，他的數學老師出了一道題：對天然數1到100求和。高斯用首尾相加的辦法很快的算出了答案，不過咱們此次要扮演高斯的同窗，老老實實的從1加到100。

首先試一下循環的思路：

function sum(n) {
    let count = 0;
    for (let i = 1; i <= n; i++) {
    	count += i;
    }
    return count;
}
sum(100); // 5050

能夠看到循環體只有一行代碼

count += i;

若是把 count 當成是一個函數的返回值，一個基本的遞歸邏輯就成型了：

function sum(n) {
    return n + sum(n-1);
}
// 這裏的 sum(n-1) 不能寫成 sum(n--)

但僅僅這樣是不夠的，還差一個關鍵代碼塊——開關

遞歸自己是一個無限循環，須要添加控制條件，讓程序在合適的時候退出循環

function sum(n) {
		if (n === 1) {
			return n;
		}
    return n + sum(n-1);
}
sum(100); // 5050

試試 sum(20000) 的結果是多少？

2、三大要素

上面的例子已經完成了一個簡單的遞歸，回頭總結一下，咱們主要作了兩件事：

1. 遞歸的拆解 —— 提取重複的邏輯，縮小問題規模
2. 遞歸的出口 —— 明確遞歸的結束條件

其實在這以前，咱們還作了一件事，這件事很重要，但經常會被咱們忽略掉：

3. 遞歸的定義 —— 明確函數的功能

這三大要素是寫遞歸的必要條件，而其中的第三點，是寫好一個遞歸的必要條件。

---

以經典的樹組件做爲案例，來印證一下這三要素。

樹組件的主要功能，就是將一個規範的具備層級的數組，渲染成樹列表

由此咱們能明確這個函數的主要功能：接收一個數組入參，返回一個完整的樹組件

好像大概可能應該也許有點問題？

仍是先來觀察數組吧。每一個元素的 title 和 key 是固定的，只是非葉子節點有 children。而 children 內部的結構也是 title 和 key，加一個可能有的 children。

這樣一來就能很容易的提取出重複的邏輯：渲染樹節點，以 children 做爲遞歸結束的判斷條件。

爲了更好的 UI 展現，還須要記錄樹節點的層級來計算當前節點的縮進。

咱們只是在渲染樹節點，而不是渲染整個樹！

之因此能渲染出整個樹，是由於在函數執行的過程當中，產生了不少的樹節點，這些樹節點組成了一個樹。

因此咱們這個函數功能應該是：接收一個數組做爲必要參數，和一個數值做爲可選參數，並返回一個樹節點。

從新捋一下思路，這個渲染樹組件的函數就清晰多了：

renderTree = (list, level = 1) => {
  return list.map(x => {
    const { children, id } = x || {};
    if (children) { // 遞歸的結束條件
      return (
        <TreeNode key={`${id}`} level={level}>
          {/* 調用自身，造成遞歸 */}
          {renderTreeNodes(children, level + 1)}
        </TreeNode>
      );
    }
    // 遞歸的出口
    return <TreeNode key={`${id}`} level={level}></TreeNode>
  })
}

3、遞歸優化 - 手動緩存

當咱們去分析一個循環的時候，能清晰的看出這個函數的內部邏輯和執行次數。

而遞歸則否則，它的結構更加簡潔，但也增長了理解成本。好比下面這個遞歸，你能一眼看出它的執行次數麼？

function Fibonacci (n) {
  return n <= 2 ? 1 : Fibonacci(n - 1) + Fibonacci(n - 2);
}

這就是著名的 Fibonacci 數列，我盡力避免拿它舉例，後來發現這個例子最爲簡單直觀。

Fibonacci 數列：1, 1, 2, 3, 5, 8, 13, 21...

f(n) = f(n-1) + f(n-2)

咱們試着執行一下 Fibonacci(10)，並記錄該函數的調用次數

竟然執行了 109 次？

其實回頭分析一下 Fibonacci 這個函數就能發現，執行的時候存在不少的重複計算，好比計算 Fibonacci(5)：

-- f(5)
| -- f(4)
| | -- f(3)
| | | -- f(2)
| | | -- f(1)
| | -- f(2)
| -- f(3)
| | -- f(2)
| | -- f(1)

葉子節點會被重複計算，層次越深，計算的次數就越多

這裏有兩個優化思路，第一種是從當前的邏輯上，添加一層緩存，若是當前入參已經計算過，就直接返回結果。

// 緩存函數
function memozi(fn){
	const obj = {};
  return function(n){
    obj[n] = obj[n] || fn(n);
    return obj[n];
  }
}

const Fibonacci = memozi(function(n) {
  return n <= 2 ? 1 : Fibonacci(n - 1) + Fibonacci(n - 2);
})

只執行了10次！這已經達到了循環的執行次數。

這是一種空間換時間的思想，增長了額外的變量來記錄狀態，不過函數的實際調用次數並無減小，只是在 memozi 函數中作了判斷。

怎麼才能真正實現 O(n) 的時間複雜度呢？

4、遞歸優化 - 自下而上

上面全部的遞歸都是自上而下的遞歸，從 n 開始，一直計算到最小值。但在 Fibonacci 的例子中，若是須要計算 f(n)，就須要先計算 f(n-1)，因此必定會存在重複計算的狀況。

能不能從最小值開始計算呢？

在明確了 f(n) = f(n-1) + f(n-2) 規則的前提下，同時又知道 f(1) = 1, f(2) = 1，那就能推斷出 f(3) = 2，乃至 f(4), f(5)...

從而獲得一個基本邏輯：

function foo(x = 1, y = 1) {
  return foo(y, x + y);
}

這裏的 x 和 y 就是對應 n=1 和 n=2 的時候的值，而後逐步計算出 n=3, n=4... 的值。

而後加入 n <= 2 的邊界，獲得最終的遞歸函數：

function Fibonacci(n, x = 1, y = 1) {
  return n <= 2 ? y : Fibonacci(n - 1, y, x + y);
}

咱們僅僅是稍微調整了函數的邏輯，就達到了 O(n) 的時間複雜度。這種自下而上的思想，實際上是動態規劃的體現。

---

動態規劃是一種尋求最優解的數學方法，它常常會被當作一種算法，但它其實並不像「二分查找」、「冒泡排序」同樣有着固定的範式。實際上動態規劃是一種方法論，它提供的是一種解決問題的思路。

簡單來講，動態規劃將一個複雜的問題分解成若干個子問題，經過綜合子問題的最優解來獲得原問題的最優解。並且動態規劃是自下而上求解，先計算子問題，再由這些子問題計算父問題，直至求解出原問題的解，將時間複雜度優化爲 O(n)。

動態規劃有三個重要概念：

1. 最優子結構
2. 邊界

光看名詞就以爲有點似曾相識。沒錯，這就是前文提到的遞歸三要素中的「縮小問題規模」和「結束條件」。

而動態規劃的第三個概念，纔是其核心所在：

3. 狀態轉移方程

所謂狀態轉移方程，就是子問題與父問題之間的關係，或者說：如何用子問題推導出父問題。

一般咱們用遞歸都是自上而下，是先遇到了父問題，再去解決子問題。而動態規劃是先解決子問題，再經過狀態轉移方程求解出父問題，也就是自下而上。這種自下而上的遞歸也被稱爲「遞推」。

---

動態規劃的適用範圍，也是自下而上的適用範圍：

1. 存在最優子結構

   做爲整個過程的最優策略，應當具備這樣的特質：不管過去的狀態和決策如何，相對於前面的決策所造成的狀態而言，餘下的決策序列必然構成最優子策略。

   也就是說，一個最優策略的子策略也是最優的。

2. 無後效性

   若是某階段狀態給定後，則在這個階段之後過程的發展不受這個階段之前各段狀態的影響。

   也就是說，計算f(i)，不須要f(i+1)...f(n)的值，也不會修改f(1)...f(i-1)的值（1 < i < n）。

只要知足這兩點，就能夠用自下而上的思路來優化。

不過上面自下而上求解 Fibonacci 數列的函數，除了動態規劃以外，還使用了尾調用。

5、遞歸優化 - 尾調用

函數在調用的時候，會在調用棧 (call stack) 中存有記錄，每一條記錄叫作一個調用幀 (call frame)。每調用一個函數，就向棧中 push 一條記錄，函數執行結束後依次向外彈出，直到清空調用棧。

function foo () { console.log('wise'); }
function bar () { foo(); }
function baz () { bar(); }

baz();

形成這種結果是由於每一個函數在調用另外一個函數的時候，並無 return 該調用，因此 JS 引擎會認爲你尚未執行完，會保留你的調用幀。

若是對上面的例子作以下修改：

function foo () { console.log('wise'); }
function bar () { return foo(); }
function baz () { return bar(); }

baz();

上面的改動實際上是函數式編程中的一個重要概念，當一個函數執行時的最後一個步驟是返回另外一個函數的調用，這就叫作尾調用(PTC)。若是是在遞歸裏面使用，即在函數的末尾調用自身，就是尾遞歸。

---

回頭來看最開始的求 1~n 之和的例子：

function sum(n) {
		if (n === 1) {
			return n;
		}
    return n + sum(n-1);
}
sum(100); // 5050

若是執行 sum(20000) 會棧溢出（爆棧）:

Uncaught RangeError: Maximum call stack size exceeded

將這個遞歸升級爲尾遞歸：

function sum(n, count = 0) {
		if (n === 1) {
			return count + n;
		}
    return sum(n-1, count+n);
}

如今調用棧中的調用幀始終只有一條，相對節省內存，這樣的遞歸就靠譜了許多

---

尾調用對遞歸的意義重大，但在實際運用的時候卻備受阻礙。

首先須要使用嚴格模式"use strict"，其次主流瀏覽器只有 Safari 支持尾調用（上面的截圖就是在 Safari 截的），Chrome 和 Firefox 甚至 node 都不支持尾調用優化。

Chrome V8 團隊給出的解釋是：

1. 因爲尾調用消除調用幀是隱式的，這意味着開發者可能很難發現一些無限循環的遞歸，若是它們剛好出如今末尾，由於這些遞歸的堆棧將再也不溢出。
2. 尾調用會丟失堆棧信息，這將致使執行流中的堆棧信息丟失，這將影響程序調試和錯誤收集。

不過即便如此，Chrome 和 Mozilla 依然承認尾調用優化所帶來的的性能提高，只是在引擎層面尚未找到一個很安全可靠的方案來支持尾調用優化。微軟曾經提議從語法上來指定尾調用（相似於 return continue 這樣的特殊語句），不過最終方案仍在討論中。

雖然大部分的瀏覽器還不支持尾遞歸，但咱們在開發的時候依然能夠優先使用尾調用，畢竟運行的效果是同樣的，而一旦程序在支持尾遞歸的環境下運行，就會有更快的運行速度。更重要的是，當咱們嘗試使用尾遞歸的時候，一般會天然而然的用到自下而上的思想。

6、小結

咱們通常認爲遞歸會比循環的性能要差，是由於函數調用自己是有開銷的。

但若是能實現尾遞歸，那麼遞歸的效率應該至少和循環同樣好。

對於不能使用尾調用的遞歸，即便寫成了循環的形式，也只是拿一個棧來模擬遞歸的過程。會帶來必定的效率提高，但也會形成代碼的冗餘。

關於循環和（優化以後的）遞歸之間的取捨，我以爲能夠從如下幾個方面判斷：

1. 遞歸的優勢是代碼簡潔，邏輯清晰。缺點是調用幀致使的執行效率太低，並且不如循環容易理解；
2. 遞歸和循環徹底能夠互換，但遞歸能夠處理的問題，若是經過循環去解決，一般須要額外的低效處理；
3. 若是邏輯相對簡單，使用循環也很簡潔，能夠優先考慮循環；
4. 在沒法使用尾遞歸的環境，循環永遠是優先考慮的解決方案，但若是能接受遞歸的性能開銷，建議使用遞歸。

我認爲遞歸實際上是一種思惟方式。所謂的「遞歸比循環慢」，指的是遞歸的各類實現。

掌握遞歸的意義不在於編碼自己，而在於知道如何編碼。

Premature optimization is the root of all evil.

過早優化是萬惡之源。

—— 《計算機編程藝術》Donald Knuth

參考資料：

《遞歸優化：尾調用和Memoization》—— LumiereXyloto

《尾調用優化》—— 阮一峯

《【譯】V8 團隊眼中的 ES六、ES7及將來》—— 奇舞團

《什麼是動態規劃（Dynamic Programming）？動態規劃的意義是什麼？》—— 苗華棟