## 過去的 v1 時代

距離 BetterScroll v1 版本釋出，至今已經 3 年多，由於它在移動端良好的滾動體驗與效能以及多種滾動場景的支援，深受社群的青睞。使用者也可以基於 BetterScroll 抽象出各種複雜的業務滾動元件，期間依託於 BetterScroll，我們還開源了基於 Vue2.0 的移動端元件庫 [cube-ui](https://github.com/didi/cube-ui)。

目前 BetterScroll 的 star 數已經超過 1.1 萬，GitHub 有大約 3.2 萬倉庫使用了它。**滴滴**內部的業務，比如**國內司乘兩端**、**國外司乘兩端**等核心業務都大量使用 BetterScroll，它經受住了各種業務場景的考驗。

隨著大量的業務場景使用以及社群的反饋與建議，v1 版本也暴露了一些問題，主要分為如下四個方面：

- **包體積大，無法按需引用**
- **擴充套件困難，增強功能易侵入核心邏輯**
- **測試匱乏，穩定性保證差**
- **文件不夠友好，社群答疑成本高**

## v2 將至

先來看下最終的整體 BetterScroll v2 版本的架構圖：

![BetterScroll v2 架構圖](https://dpubstatic.udache.com/static/dpubimg/ad0386b2-9f9f-4c75-8b04-549386af5608.png)

從整體架構圖可以看出，目前整體 BetterScroll v2 版本除了實現核心滾動外，還額外提供很多外掛：

- **picker**
  gao仿 iOS 原生 Picker 元件
- **mouse-wheel**
  相容 PC 滑鼠滾輪場景
- **observe-dom**
  自動探測 scroll 區域 DOM 改變，並且呼叫 refresh 方法
- **pulldown**
  監聽下拉動作
- **pullup**
  監聽上拉觸底動作
- **scrollbar**
  仿原生瀏覽器，且樣式美觀的捲軸
- **slide**
  實現輪播圖互動效果
- **zoom**
  提供縮放能力
- **nested-scroll**
  協調雙層巢狀的滾動行為
- **infinity**
  無限滾動列表（多用於大量資料渲染，否則 coreScroll 即可滿足需求）

v2 版本的誕生就是為了解決 v1 暴露出來的問題，這裡我們將從上面的四個問題分別來揭秘重構過程中的思考與實踐。

### 1、包體積大

v1 的架構設計借鑑於 Vue 2.0 的程式碼組織方式，但是由於不同的 Feature(`picker、slide、scrollbar 等`) 都是與核心滾動寫在一起，導致無法**按需引入**。

> **備註**：此處的**按需引入**指的是使用者可能只需要實現簡單的列表滾動效果，卻*被迫*載入冗餘程式碼，比如所有 Feature 的程式碼，造成包體積過大的問題。

為了解決這個問題，我們就必須找到一種合理的方式將各個 Feature 程式碼單獨拆分，獨立引用，答案就是**外掛化**方案。那麼 v2 版本的一個核心關鍵點就是**如何設計外掛化的機制**，我們當時是從下面三個步驟來思考的：

1. 核心功能抽象，從核心滾動（CoreScroll）自頂向下地拆分出多個職能單一的類，進而將它們組合在一起構建完整核心邏輯；

![核心滾動類](https://dpubstatic.udache.com/static/dpubimg/32fa40e2-49e7-4461-9295-dc3d88624847.png)

由於拆分成細粒度的功能類，考慮到老使用者監聽事件或者獲取屬性都是操縱 CoreScroll，我們內部有統一的[事件冒泡層](https://github.com/ustbhuangyi/better-scroll/blob/dev/packages/core/src/utils/bubbling.ts)以及[屬性代理層](https://github.com/ustbhuangyi/better-scroll/blob/dev/packages/shared-utils/src/propertiesProxy.ts)，將內部類的事件或者屬性都代理到 CoreScroll 上。

2. 借鑑 **webpack tapable** 延伸出來的 `hooks` 的概念（並不需要 tapable 那麼強大），職能類之間透過 `hooks`(即 EventEmitter 經典的訂閱釋出者模式增強版) 來處理流程中鉤子邏輯；

3. 借鑑 **Vue 2.x** 外掛序號產生器制（程式碼如下），減少老使用者的心智負擔。

```js
    import BScroll from '@better-scroll/core'
    import Slide from '@better-scroll/slide'
   
    // 只需註冊外掛即可，無額外心智負擔
    BScroll.use(Slide)
   
    let bs = new BScroll('.wrapper', {
      slide: { /* 外掛配置項 */ }
    })
   ```

因此 v2 的整體雛形就已經好了，考慮到後期會有很多外掛實現不同的業務場景需求，v2 版本採用了 [Lerna](https://github.com/lerna/lerna) 來管理多個包，使用 `@better-scroll` 作為包的命名字首，這樣對於使用者來說有更好的辨識度。[TypeScript](https://www.typescriptlang.org/) 的靜態型別，加上整個的社群十分成熟豐富的生態，BetterScroll 本身 Feature 已經很多，且未來還會繼續增加，綜合看非常適合用 TypeScript 進行開發。

> TIPS:
>
> Lerna 發包失敗始終是開發者(包括作者)繞不過去的話題，目前也有很多 issue 與部落格在討論這個問題，供參考：[lerna 釋出失敗後的解決方案](https://github.com/huruji/blog/issues/67)、[lerna issue 1894](https://github.com/lerna/lerna/issues/1894)、[publish 失敗問題](https://github.com/9-web/zet-component/issues/41)

### 2、擴充套件困難

v1 版本新增 Feature 的時候，有些邏輯程式碼是與核心滾動程式碼糅合在一起，造成後期擴充套件可維護性都會慢慢降低，隨之而來的困擾也有包體積無限制的增加。那麼如果將 Feature 與 核心滾動 CoreScroll 部分進行徹底分離，將 Feature 做成外掛的模式，既能解決包體積的問題，擴充套件也變得相對容易，迭代的穩定性也變好了。

在 v2 版本中，一個外掛的一般實現如下：

```typescript
class InfinityScroll {
  static pluginName = 'infinity'
  constructor(public bscroll: BScroll) {
    // ...your own logic
  }
}
// 假設已經註冊了 InfinityScroll
new BScroll('.wrapper', {
  infinity: { /* 外掛配置項 */ }
  // infinity 要與外掛的 pluginName 對應上
})
```

外掛**必須**擁有一個靜態屬性 **pluginName**，這個屬性對應的值必須與初始化 BetterScroll 傳入的配置物件的 **key** 對應，否則內部查詢不到對應的外掛。這個方案充分考慮了開發者使用時候的成本，同時也儘量降低和 v1 版本的差異。

在實現了核心的外掛機制後，對於各種 Feature 則是透過一個個外掛的形式來豐富 BetterScroll 的整體生態。

### 3、測試匱乏

在 v1 版本中，測試覆蓋率不到 40%，可能也是因為 BetterScroll 在之前是一個巨大的類，編寫單元測試也逐漸地困難了起來，這樣在後期迭代升級的時候會埋下隱患，這也就是所說的**穩定性保證差**。

那麼在 v2 版本，為了保證整體功能的穩定性，控制發版質量，我們不但新增了**單元測試**，還額外引入了**功能測試**做進一步保障。

1. **單元測試**

之前參與的 [cube-ui](https://github.com/didi/cube-ui) 的單測是採用 `karma + mocha` 的方案，不過需要安裝**各種外掛**，還需要做不少配置。已經 0202 年了，最終調研對比發現在現有的 BetterScroll 場景中使用 [Jest](https://github.com/facebook/jest) 作為測試框架是合適的，它本身整合了 `Mock`、`Test Runner`、`Snapshot` 等強大的功能，基本上算是開箱即用，很好的滿足需要。

在編寫單元測試過程中，用的最多是強大的 [manual-mocks](https://jestjs.io/docs/en/manual-mocks) 能力。

舉個簡單的場景來深入淺出地闡述我們對**單元測試**的看法以及如何藉助 **Jest manual-mocks** 解決問題。

假如我們的原始碼檔案結構如下：

```markup
    - src
      - Core.ts
      - Helper.ts
   ```

`Core` 與 `Helper` 的程式碼如下：

```typescript
    // Core.ts 程式碼如下
   
    export default class Core {
      constructor (helper: Helper) {
        this.helper = helper
      }
   
      getHammer (type: string) {
        if (this.helper.isHammer(type)) {
          return ('Got hammer')
        } else {
          return ('No hammer is available')
        }
      }
    }
   
    // Helper.ts 程式碼如下
   
    export default class Helper {
      isHammer (type: string) {
        return type === 'hammer'
      }
    }
   ```

準備工作就緒，現在要開始測試 `Core#getHammer` 函式，這時我們核心開發成員之間發出了兩種不同的聲音。

**方案一**：匯入 `Helper` 原始程式碼（即 `src/Helper.ts`），讓其走全流程；

**方案二**：單元測試應該以函式或者類作為最小的粒度，做法傾向於傳統的測試行業的概念，認為 `Helper` 應該被 mock 掉（使用 `src/__mocks__/Helper.ts`），換句話來說， `Helper` 作為另外一個測試單元，它必須保證自己的功能完全正確，但對於 `Core.ts` 的單測，不應該引入原始的 `Helper`。

最後的最後，我們選擇了更為嚴謹的**方案二**。

藉助於 Jest [manual-mocks](https://jestjs.io/docs/en/manual-mocks) 的能力，編寫測試就變得更愉快與明確了。

1. 更改檔案結構

```diff
       src
       + __mocks__
       +   Helper.ts
       + __tests__
       +   Core.spec.ts
         Core.ts
         Helper.ts
      ```

加了目錄 `__mocks__` 以及 `__mocks__/Helper.ts` 檔案，並且加了測試目錄 `__tests__` 與 `Core.spec.ts`。

2. 完善 manual-mocks

```typescript
       // __mocks__/Helper.ts
       const Helper = jest.fn().mockImplementation(() => {
         return {
           isHammer: jest.fn().mockImplementation((type) => {
             return type === 'MockedHammer'
           })
         }
       })
       export default Helper
      ```

3. 編寫 Core.spec.ts

```typescript
       import Helper from '../Helper.ts'
       import Core from '../Core.ts'
       // 使用 '__mocks__/Helper.ts'
       // 引入的 Helper 就是 mock 處理過的～
       jest.mock('../Helper.ts')
      
       describe('Core tests', () => {
         it('should work well with "MockedHammer"', () => {
      
           const core = new Core(new Helper() // Mock 過後的 Helper)
      
           expect(core.getHammer('MockedHammer')).toBe('Got hammer') // 透過
         })
       })
      ```

從上述可以看出，我們利用 Jest 更改了 `Helper.ts` 的匯出，用的是 `__mocks__` 目錄下的，不再是原始的 `Helper.ts`，這樣各個模組自身需要保障自身邏輯正確性，同時對於異常分支的邏輯測試會變得更容易。

**很有趣, 對吧?**

2. **功能測試**

由於 BetterScroll 是一個與瀏覽器強相關的滾動庫，單元測試是用來保證單個模組的**輸入輸出**正確性，所以還需要其他的手段來保證核心滾動、外掛等的行為表現符合預期，因此我們就採用了 [jest-puppeteer](https://github.com/smooth-code/jest-puppeteer)，它的理念就是 **Run your tests using Jest & Puppeteer**，這裡有必要介紹一下 [Puppeteer](https://github.com/puppeteer/puppeteer)。

> Puppeteer is a Node library which provides a high-level API to control Chrome or Chromium over the [DevTools Protocol](https://chromedevtools.github.io/devtools-protocol/)

用我的工地英語翻譯一下就是：

> Puppeteer 是一個透過 DevTools 協議控制 Chrome 行為並且提供更優雅的 API 的 Node 類庫。

**DevTools** 這個協議很重要，接下來仍會提及到。

你開啟它的官網會發現，它的功能有很多，包括**生成 PDF**、**表單、UI 測試**、**谷歌外掛測試**等等，網上也有很多文章介紹如何使用它來做**爬蟲**。

下面擷取核心滾動的功能測試片段程式碼：

```typescript
    describe('CoreScroll/vertical', () => {
      beforeAll(async () => {
        await page.goto('http://0.0.0.0:8932/#/core/default')
      })
   
      it('should render corrent DOM', async () => {
        const wrapper = await page.$('.scroll-wrapper')
        const content = await page.$('.scroll-content')
   
        expect(wrapper).toBeTruthy()
        await expect(content).toBeTruthy()
      })
   
      it('should trigger eventListener when click wrapper DOM', async () => {
        let mockHandler = jest.fn()
        page.once('dialog', async dialog => {
          mockHandler()
          await dialog.dismiss()
        })
   
        // wait for router transition ends
        await page.waitFor(1000)
        await page.touchscreen.tap(100, 100)
   
        await expect(mockHandler).toHaveBeenCalled()
      })
    })
   ```

從上邊的示例程式碼可以看到，Puppeteer 的 API 都是非常語義化的，而且內部的 API 都是返回 Promise。

在逐漸豐富功能測試的時候，還是很愉快的，但是**難題**還是不期而遇。

**BetterScroll 功能測試強相關聯 Touch、Mouse、MouseWheel 等事件，然而此時的 Puppeteer(v1.17.0) 並沒有提供全部的介面。**

**既然 Puppeteer 是一個透過協議控制 Chrome 的類庫，那為啥不把它內部的實現先粗略的瞭解一下呢？**

秉著這個想法，在研究了 Puppeteer 的核心實現，最終整理發現，只要理清一條主線，其餘的是照葫蘆畫瓢、參考 [DevTools Protocol](https://chromedevtools.github.io/devtools-protocol/) 文件即可。

下面是簡略的流程圖。

![示例](https://dpubstatic.udache.com/static/dpubimg/a7c0a9df-8157-4db3-beb2-88cb31d95609.png)

**第一步**：利用 node 的 child_process 模組啟動 `Chromium`;

**第二步**：監聽命令列的輸出，獲取 `browserWSEndpoint`，它是一個 URL 地址，傳給 WebSocket，這樣 Puppeteer 與 Chromium 的雙向推送關係就建立了；

**第三步**：例項化 Connection，建立 Session 會話以及 例項化 Browser 類，那麼使用者操作的都是這個 browser 例項，比如開啟一個頁面標籤(`browser.newPage()`)。在例項化 Connection 的內部，其實有很多細節，[DevTools Protocol](https://chromedevtools.github.io/devtools-protocol/) 就是現成的 API 文件，換句話來說，只要我們按著這個 API 文件透過 WebSocket 給 Chromium 去發訊息，就能驅使它作出響應的行為。

接下來結合文件以及原始碼，我們發現只要傳送 `Input.synthesizePinchGesture` 以及 `Input.synthesizeScrollGesture` 訊息（[文件在這](https://chromedevtools.github.io/devtools-protocol/tot/Input#method-synthesizeScrollGesture)），就能驅使 Chromium 作出 scroll、 zoom、mouseWheel 等事件互動效果，那麼對於 BetterScroll 的各種外掛以及核心滾動的功能測試就手到擒來啦！

因此，我們對 Puppeteer 做了部分擴充套件，[extendTouch](https://github.com/ustbhuangyi/better-scroll/blob/dev/tests/util/extendTouch.ts)、[extendMouseWheel](https://github.com/ustbhuangyi/better-scroll/blob/dev/tests/util/extendMouseWheel.ts) 以滿足功能測試需要。

那麼功能測試的寫的任務就算可以全部完成啦。

功能測試算是告一段落了，但是**新問題**又出現了：跑功能測試，是依賴 examples 下的程式碼來啟動服務，然後在用 Puppeteer 去訪問示例程式碼的服務，最後跑所有的測試用例。也就意味著跑功能測試就需要先把服務準備好，再跑功能測試，這裡我們需要一種更為**工程化**的手段來解決這個問題！

這個問題的關鍵是**怎麼確保 examples 程式碼的服務啟動再跑功能測試**，那麼是不是可以從 `webpack` 下手，尤其是 `webpackDevServer`。透過研究它的原始碼實現，發現內部引用的 [webpack-dev-middleware](https://github.com/webpack/webpack-dev-middleware#waituntilvalidcallback)，其中有一個 API，叫做 `waitUntilValid`，接收一個 `callback`。這個 API 能保證服務已經啟動並且 bundle 是可訪問的。

那麼解決方案就如下，在 `vue.config.js` 注入 webpack 的 配置：

```js
    module.exports.configureWebpack = {
      devServer: {
        before (app, server) {
          server.middleware.waitUntilValid(() => {
            // 服務已經 ready，啟動 e2e 測試
            execa('npm', ['run', 'test:e2e'], { stdio: 'inherit' })
          })
        }
      }
    }
   ```

至此，這就是測試部分的探索以及實踐，做完這部分，對我們自身而言，有個最大的體會：**工程師的價值在於探索與解決問題**。

### 4、文件不夠友好

v1 版本的文件以及示例程式碼頗受吐槽，尤其是示例部分給了新入坑的小夥伴們很大的心智負擔，比如文件內部沒有實際程式碼片段、示例耦合各種無關的 Vue 邏輯。在 v2，這些問題將會得到改善。

首先由於我們的技術棧是 Vue，其周邊 [VuePress](https://vuepress.vuejs.org/) 則是一個很好用的文件框架，它將 Vue、webpack、Markdown 的能力發揮到極致，也能很好的定製主題、實現國際化，並且它外掛化的架構設計給 VuePress 帶來了很大的靈活性以及擴充套件能力，所以我們就選型了 VuePress 來完成相關 API 文件化。儘管 VuePress 開箱即用，基本滿足我們編寫文件的大部分要求，但仍然需要額外的一些擴充套件。

![示例](https://dpubstatic.udache.com/static/dpubimg/8c016f7b-1b71-48f2-982a-83f54ed0aebb.png)

這裡想要實現上面圖片的功能，要有**二維碼**，**元件的程式碼片段**，**要把 examples 目錄下的元件真正渲染在 markdown 裡面**。第一和第三點都特別好實現，VuePress 提供這能力，但是第二點，**在 markdown 同步展示 examples 元件對應的程式碼**，這是個棘手的問題。

那麼，深入研究 VuePress 的實現是必要的，VuePress 內部是使用 [markdown-it](https://github.com/markdown-it/markdown-it) 來編譯 `md` 副檔名的檔案。要解決這個問題，看來需要深入研究下 markdown-it 的底層實現，也順道產出了 [markdown-it 原始碼以及外掛的解讀系列](https://github.com/theniceangel/markdown-it-analysis)；發現基於 VuePress 的外掛機制可以滿足我們定製化的需求，因此寫了 [extract-code](https://github.com/ustbhuangyi/better-scroll/blob/dev/packages/vuepress-docs/docs/.vuepress/plugins/extract-code.js) 外掛，並約定 markdown 檔案只要如下的程式碼，那麼就會被 `extract-code` 處理。

```
// 抽取 default.vue 檔案的 template 標籤內容
<<< @/examples/vue/components/infinity/default.vue?template
// 抽取 default.vue 檔案的 script 標籤內容
<<< @/examples/vue/components/infinity/default.vue?script
```

如此一來，我們每次更改 examples 下面的示例程式碼，文件也會同步更新到對應的部分。

> 注意：
> 由於 VuePress 為了加快 markdown 檔案的編譯速度，內部使用 [cache-loader](https://github.com/webpack-contrib/cache-loader) 做快取，意思是如果 markdown 內容沒有發生變化，直接取快取的內容，雖然示例程式碼變化，但是對於 markdown 檔案來說，內容其實是未改變的。

> TIPS:
> 如果你不喜歡程式碼塊的主題，可以研究下大名鼎鼎的 [prism](https://github.com/PrismJS/prism)，因為 VuePress 的內部就是用這個外掛去做高亮的。

## 總結規劃

回顧我們在做 BetterScroll 2.0 版本的大體歷程，一路雖有坎坷，但更多的是收穫、總結和沉澱。

BetterScroll 2.0 目前經過了 20 多個 alpha 版本，已經發布了 beta 版本，但是卻是已經穩定了的版本，內部和社群已經有了大量的下載使用，未來我們會持續做一些事情：

1. 最佳化程式碼 & 包體積
2. 提供更多的外掛並且豐富示例 （歡迎 PR 或者提出你們的 ideas）
3. 完善文件以及暴露更多的細節
4. 測試完善

同時，也會在 BetterScroll 2.0 的基礎上產出新版本的元件庫，在原本已經最佳化、提效的基礎之上進行二次提效，助力業務。

希望能有越來越多的人使用，同時也有更多的你參與進來，一起共建，讓 BetterScroll 的整個生態變得 Better。
###作者：嵇智【滴滴出行資深軟體開發工程師】
- [	現在註冊滴滴雲，得8888元立減紅包](https://app.didiyun.com/#/auth/signup?channel=14816)
- [7月特惠，1C2G1M雲伺服器 9.9元/月限時搶](https://www.didiyun.com/?channel=14816)
- [滴滴雲使者專屬特惠，包年雲伺服器低至68元/年](https://www.didiyun.com/envoy/e-index.html?channel=14816)
- [輸入大師碼【7886】，GPU全線產品9折優惠](https://www.didiyun.com/production/gpu.html?channel=14816)

如何重構一個過萬Star開源專案—BetterScroll

相關文章