## 一、背景   目前公司的```電子合同```採用```表單設計器```+```合同業務```配合實現，做了半年多後終於上線，但是下邊員工普遍反映卡頓，甚至卡死，爆棧。尤其是新增和修改合同頁面，因為這部分資料量大，邏輯複雜，很容易崩潰，所以決定進行效能優化。 ## 二、業務場景介紹   先來了解一下我們是怎麼實現：   1. 因為我們公司合同變換頻繁，條款之間還有邏輯，所以做了個```基礎服務```（說白了就是元件庫），為合同提供模板   2. 表單設計器作為基礎服務，打包成了元件庫，嵌入到合同專案，包括合同生成元件（拖拽生成合同模板）和合同預覽元件（載入資料庫中的合同模板資料）   3. 合同專案有一個模組管理頁面，可以對多個模板進行維護，比如可以選擇啟用哪個模板。   4. 合同的管理員負責維護模板，可以用表單設計器拖拽生成合同模板，提交後落入資料庫，每個合同型別可以同時啟用一個模板。   5. 最終下邊員工用的就是啟用的模板（尤其是這部門卡頓） **下面是電子合同的巨集觀泳道圖：**  ## 三、頁面介紹 1. 合同模板管理頁  2. 新增模板頁面  3. 新建合同頁面  4. 合同填寫頁面    好了，基本的業務邏輯和頁面就介紹這麼多，特別卡頓的頁面就是第四個頁面，下面我們分析一下卡頓的原因。 ## 四、卡頓分析   1. 首先就是表單設計器的問題最嚴重，因為每一個元件需要很多配置項才能夠支撐元件的渲染，而一個合同是由上千個元件組成，經過測試，一個合同模板需要5MB的儲存空間(資料庫用的是MongoDB，儲存格式為字串，幾乎不影響)，下面是一個輸入框的配置    2. 表單設計器的實現用了大量的閉包管理業務，我們都知道，閉包是特別耗記憶體的。   3. 合同模板巨複雜，由上萬個元件拼接而成，我把模板資料down下來看了一下，大約是16000多個元件，大小為3.4MB。   4. 因為表單設計器中包括```id,model,事件id```都是前端隨機生成的，採用```隨機字串+時間戳```的形式，一共46位。   5. 合同專案屬於大型專案，業務場景及其複雜，包括合同管理，附件管理，合同列表，新增頁面，審批頁面等等，我計算了一下，光路由頁面就有三十多個，```頁面，元件，樣式,業務```巨多，如果不做處理，不卡才怪 ## 五、效能優化 #### 1. 第一次嘗試   說一下我的優化思路：首先，電子合同由表單設計器和合同業務兩個專案共同完成，合同模板載入慢的原因是瀏覽器渲染了大量的模板資料，這些模板資料是由多個組組成的（大約12個），我第一想到的就是```分組渲染```，先載入一個組，先讓使用者看到頁面，然後在繼續載入，一個一個,最終載入完成。這也是被大家認可的方案。   然後我就開始實現這個分組渲染，做了大概有二十多天吧，一點效果沒出來。   先看一下渲染的程式碼： ``` ```   上面就是所有組載入的程式碼，這是一個```v-for```,做分組渲染，我想到使用```vue的非同步元件```實現，但是這是一個迴圈，所有的元件註冊的都是同一個名字，這顯然是不能用非同步元件的，除非註冊的是不同名字的元件，但是我想了很長時間都做出來效果，所以這二十多天，失敗了。 #### 2.第二次嘗試   上邊說了，模板載入慢是因為瀏覽器渲染了大量的資料，我們知道，js是單執行緒的，也就是說，所有任務只能在一個執行緒上完成，一次只能做一件事。前面的任務沒做完，後面的任務只能等著。因此js處理資料的能力有限，所以在朋友的建議下調研了一把```webworker```。   webworker的作用，就是為js創造多執行緒環境，允許主執行緒建立Worker執行緒，將一些任務分配給後者執行。在主執行緒執行的同時，Worker執行緒在後臺執行，兩者互不干擾。   看了一把文件我第一時間覺得這個方案不可行。說到底我們就是想要webworker為我們開闢縣城用來處理大量資料，但是webworker處理的大資料，不是指資料量非常大，而是要從計算量來看，通常用時不能控制在毫秒級內的運算都可以考慮放在web worker中執行。而我們的合同模板資料恰恰是資料量大，並不需要做特別大的運算。   第二次嘗試失敗。 #### 3.第三次嘗試   後來在同事的建議下決定採用```ssr```,也就是```服務端預渲染```。我們平常寫的vue專案打包後生成```dist```,運維會把這個資料夾放在伺服器中，我們看到的頁面其實就是生成執行的```render函式```，這是比較耗時的。   所謂的服務端渲染，就是在```服務端```生成靜態頁面，然後交給```客戶端```渲染。   自己從零搭建一套服務端渲染的應用是相當複雜的，所以我最終選用了```nuxt```框架。關於nuxt框架我不多做介紹，可以自己去看文件[（傳送門）](https://nuxtjs.org/)。這個框架有自己的腳手架，也是vue官方推薦的。   經過了一週的時間，完成了從vue向nuxt的遷移，大部門頁面速度有了明顯的提升。   **除了我們想優化的新增合同頁面。**   經過分析，合同專案用到的元件庫有```element-UI```和我問自己的表單設計器，element只有部門元件支援ssr，像是```表格和樹```是不支援ssr的，所以就不存在服務端渲染了。   我也曾嘗試過弄一把表單設計器，讓它支援ssr，但是並沒有效果，如果有誰知道，可以聯絡我。   很顯然，第三次也失敗了。 #### 4.第四次嘗試   命運總是很捉弄人，優化了一個多月的合同，速度並沒有顯著的提升，領導很著急，我也很著急。   突然有一天，我在回家的途中，記得那天風雨交加，雷霆大作，一聲巨雷轟天響，把我好的idea都劈出來了。我一下子想到了分組載入的實現。 先來看一把程式碼的實現（只展示了部分程式碼）： ```