高德JS依賴分析工程及關鍵原理

時間 2019-12-01

原文原文鏈接

1、背景前端

高德 App 進行 Bundle 化後，因爲業務的複雜性，Bundle的數量很是多。而這帶來了一個新的問題——Bundle 之間的依賴關係錯綜複雜，須要進行管控，使 Bundle 之間的依賴保持在架構設計之下。node

而且，爲了保證 Bundle 能實現獨立運轉，在業務持續迭代的過程當中，須要逆向的依賴關係來迅速肯定迭代的影響範圍。同時，對於切面 API（即對容器提供的系統 API，相似瀏覽器中的 BOM API），也須要肯定每一個切面 API 的影響範圍以及使用趨勢，來做爲修改或下線某個 API 的依據。正則表達式

以組件庫爲例，因爲組件會被若干業務項目所使用，咱們對組件的修改會影響這些業務項目。在計劃修改前，須要根據正向的依賴關係（業務依賴組件）來算出逆向的依賴關係——該組件被哪些地方所依賴，從而肯定這個組件修改的影響範圍。算法

比文件更高的維度，是 Bundle 間的依賴。咱們有業務 Bundle，也有公共 Bundle。公共 Bundle 也分爲不一樣層級的 Bundle。數組

對於公用 Bundle，業務 Bundle 能夠依賴它，但公用 Bundle 不能反過來依賴業務 Bundle；一樣的，底層的 Bundle 也禁止依賴上層封裝的 Bundle。咱們須要經過依賴分析，來確保這些依賴按照上述規則進行設計。瀏覽器

2、實現關鍵步驟bash

實現 JS 依賴分析，整個實現過程大體以下圖所示：數據結構

下面挑一些關鍵步驟來展開介紹。

使用 AST 提取依賴路徑架構

要作文件級別的依賴分析，就須要提取每一個文件中的依賴路徑，提取依賴路徑有 2 個方法：函數

使用正則表達式，優勢是方便實現，缺點是難以剔除註釋，靈活度也受限；
先進行詞法分析和語法分析，獲得 AST（抽象語法樹）後，遍歷每一個語法樹節點，此方案的優勢是分析精確，缺點是實現起來要比純正則麻煩，若是對應語言沒有提供 parser API（如 Less），那就很差實現。

通常爲了保證準確性，能用第 2 個方案的都會用第 2 個方案。

以類 JS（.js、.jsx、.ts、.tsx）文件爲例，咱們能夠經過 TypeScript 提供的 API ts.createSourceFile 來對類 JS 文件進行詞法分析和語法分析，獲得 AST：

const ast = ts.createSourceFile(
  abPath,
  content,
  ts.ScriptTarget.Latest,
  false,
  SCRIPT_KIND[path.extname(abPath)]
);
複製代碼

獲得 AST 後，就能夠開始遍歷 AST 找到全部咱們須要的依賴路徑了。遍歷時，能夠經過使用 typeScript 模塊提供的 ts.forEachChild 來遍歷一個語法樹節點的全部子節點，從而實現一個遍歷函數 walk：

function walk (node: ts.Node) {
  ts.forEachChild(node, walk); // 深度優先遍歷

  // 根據不一樣類型的語法樹節點，進行不一樣的處理
  // 目的是找到 import、require 和 require.resolve 中的路徑
  // 上面 3 種寫法分爲兩類——import 聲明和函數調用表達式
  // 其中函數調用表達式又分爲直接調用（require）和屬性調用（require.resolve）
  switch (node.kind) {
    // import 聲明處理
    case ts.SyntaxKind.ImportDeclaration:
      // 省略細節……
      break;

    // 函數調用表達式處理
    case ts.SyntaxKind.CallExpression:
      // 省略細節
      break;
  }
}
複製代碼

經過這種方式，咱們就能夠精確地找到類 JS 文件中全部直接引用的依賴文件了。

固然了，在 case 具體實現中，除了用戶顯式地寫依賴路徑的狀況，用戶還有可能經過變量的方式動態地進行依賴加載，這種狀況就須要進行基於上下文的語義分析，使得一些常量能夠替換成字符串。

但並非全部的動態依賴都有辦法提取到，好比若是這個動態依賴路徑是 Ajax 返回的，那就沒有辦法了。不過無需過分考慮這些狀況，直接寫字符串字面量的方式已經能知足絕大多數場景了，以後計劃經過流程管控+編譯器檢驗對這類寫法進行限制，同時在運行時進行收集報警，要求必需顯式引用，以 100% 確保對切面 API 的引用是能夠被靜態分析的。

創建文件地圖進行尋路

咱們對於依賴路徑的寫法，有一套本身的規則：

引用類 JS 文件支持不寫擴展名；

引用本 Bundle 文件，可直接只寫文件名；

使用相對路徑；

引用公用 Bundle 文件，經過 @{fileName} 的方式引用，fileName 一樣是直接只寫該 Bundle 內的文件名。

這些方式要比 CommonJS 或 ECMAScript Module 的規劃要稍複雜一些，尤爲是「直接只寫文件名」這個規則。對於咱們來講，須要找到這個文件對應的真實路徑，才能繼續進行依賴分析。

要實現這個，作法是先構建一個文件地圖，其數據結構爲 { [fileName]: ‘relative/path/to/file’ } 。我使用了 glob 來獲得整個 Bundle 目錄下的全部文件樹節點，篩選出全部文件節點，將文件名做爲 key，相對於 Bundle 根目錄的路徑做爲 value，生成文件地圖。在使用時，「直接只寫文件名」的狀況就能夠直接根據文件名以 O(1) 的時間複雜度找到對應的相對路徑。

此外，對於「引用類 JS 文件支持不寫擴展名」這個規則，須要遍歷每一個可能的擴展名，對路徑進行補充後查找對應路徑，複雜度會高一些。

依賴是圖的關係，需先建節點後建關係

在最開始實現依賴關係時，因爲做爲前端的慣性思惟，會認爲「一個文件依賴另外一些文件」是一個樹的關係，在數據結構上就會天然地使用相似文件樹中 children: Node[] 的方式——鏈式樹結構。而實際上，依賴是會出現這種狀況的：

若是使用樹的方式來維護，那麼 utils.js 節點就會分別出如今 page.jsx 和 comp.jsx 的 children 中，出現冗餘數據，在實際項目中這種狀況會很是多。

但若是僅僅是體積的問題，可能還沒那麼嚴重，頂多費點空間成本。但咱們又會發現，文件依賴還會出現這種循環依賴狀況：

寫 TypeScript 時在進行類型聲明的時候，就常常會有這樣循環依賴的狀況。甚至兩個文件之間也會循環依賴。這是合理的寫法。

可是，這種寫法對於直接使用鏈式樹結構來講，若是建立鏈式樹的算法是「在建立節點時，先建立子節點，待子節點建立返回後再完成自身的建立」的話，就不可能實現了，由於咱們會發現，假如這樣寫就會出現無限依賴：

const fooTs = new Node({
  name: 'foo.ts',
  children: [
    new Node({ 
      name: 'bar.ts', 
      children: [
        new Node({
          name: 'baz.ts',
          children: [
            new Node({
              name: 'foo.ts', // 和最頂的 foo.ts 是同一個
              children: [...] // 無限循環……
            })
          ]
        })
      ]
    })
  ]
})
複製代碼

此問題的根本緣由是，這個關係是圖的關係，而不是樹的關係，因此在建立這個數據結構時，不能使用「在建立節點時，先建立子節點，待子節點建立返回後再完成自身的建立」算法，必須把思路切換回圖的思路——先建立節點，再建立關係。

採用這種作法後，就至關於使用的是圖的鄰接鏈表結構了。咱們來看看換成「先建立節點，再建立關係」後的寫法：

// 先建立各節點，而且將 children 置爲空數組
const fooTs = new Node({
  name: 'foo.ts',
  children: []
});

const barTs = new Node({
  name: 'bar.ts',
  children: []
});

const bazTs = new Node({
  name: 'baz.ts',
  children: []
});


// 而後再建立關係
fooTs.children.push(barTs);
barTs.children.push(bazTs);
bazTs.children.push(fooTs);
複製代碼

使用這種寫法，就能夠完成圖的建立了。

可是，這種數據結構只能存在於內存當中，沒法進行序列化，由於它是循環引用的。而沒法進行序列化就意味着沒法進行儲存或傳輸，只能在本身進程裏玩這樣子，這顯然是不行的。

因此還須要對數據結構進行改造，將鄰接鏈表中的引用換成子指針表，也就是爲每一個節點添加一個索引，在 children 裏使用索引來進行對應：

const graph = {
  nodes: [
    { id: 0, name: 'foo.ts', children: [1] },
    { id: 1, name: 'bar.ts', children: [2] },
    { id: 2, name: 'baz.ts', children: [0] }
  ]
}
複製代碼

這裏會有同窗問：爲何咱們不直接用 nodes 的下標，而要再添加一個跟下標數字同樣的 id 字段？緣由很簡單，由於下標是依賴數組自己的順序的，若是一旦打亂了這個順序——好比使用 filter 過濾出一部分節點出來，那這些下標就會發生變化。而添加一個 id 字段看起來有點冗餘，但卻爲後面的算法下降了不少複雜度，更加具有可擴展性。

用棧來解決循環引用（有環有向圖）的問題

當咱們須要使用上面生成的這個依賴關係數據時，若是須要進行 DFS（深度遍歷）或 BFS（廣度遍歷）算法進行遍歷，就會發現因爲這個依賴關係是循環依賴的，因此這些遞歸遍歷算法是會死循環的。要解決這個問題很簡單，有三個辦法：

在已有圖上添加一個字段來進行標記每次進入遍歷一個新節點時，先檢查以前是否遍歷過。但這種作法會污染這個圖。
建立一個新的一樣依賴關係的圖，在這個新圖中進行標記這種作法雖然能實現，但比較麻煩，也浪費空間。
使用棧來記錄遍歷路徑咱們建立一個數組做爲棧，用如下規則執行：每遍歷一個節點，就往棧裏壓入新節點的索引（push）；每從一個節點中返回，則移除棧中的頂部索引（pop）；每次進入新節點前，先檢測這個索引值是否已經在棧中存在（使用 includes），若存在則回退。

這種方式適用於 DFS 算法。

3、總結

依賴關係是源代碼的另外一種表達方式，也是把控巨型項目質量極爲有利的工具。咱們能夠利用依賴關係挖掘出無數的想象空間，好比無用文件查找、版本間變更測試範圍精確化等場景。若結合 Android、iOS、C++ 等底層依賴關係，就能夠計算出更多的分析結果。

目前，依賴關係掃描工程是迭代式進行的，咱們採用敏捷開發模式，從一些簡單、粗略的 Bundle 級依賴關係，逐漸精確化到文件級甚至標識符級，在落地的過程當中根據不一樣的精確度來逐漸知足對精度要求不一樣的需求，使得整個過程均可得到不一樣程度的收益和反饋，驅使咱們不斷持續迭代和優化。