摘要：三性能優化處理做工具類的項目，性能是非常大的挑戰，我總結了以下幾個常見的性能優化點數據緩存。防抖，節流，事件委托內存釋放。

1、功能介紹

2、技術架構

3、性能優化

4、細節分享

5、開源說明

很久沒寫過技術類的文章了，這次給大家分享一個近期的項目，采用react+mobx+jquery構建的大型工具類項目。查看項目網址。

如果用過易企秀，maka或者百度H5，搜狐快站的朋友應該對這個工具是非常熟悉的，用戶通過托拉拽等操作，即可輕松實現HTML5代碼的編輯工作，大大節約了開發成本，也可以對模板進行二次編輯，快速生成新的H5頁面，今天的主角是H5DS (全稱：HTML5 Design software) 這是一款WEB的H5制作工具。讓不會寫代碼的人也能輕松快速上手制作H5頁面。

做產品前，規劃很重要，這將直接決定項目的成敗！有的項目需要1年，2年或者更長的時間去規劃，規劃 好了才能厚積薄發！這時候我們需要逃離程序員的思維，不要單純的從程序開發的角度去看待整個項目！

產品思維：程序員在要求產品經理懂一些代碼的時候，作為程序員也要有產品思維，在做產品前，心里得有個譜，要做一個怎樣的產品（大型項目，小型項目，精品項目，隨便搞搞練手…）？面向的用戶群體（to C, to B，面向設計師，面向程序員…）？產品定位（面向高端用戶，面向低端用戶）？用戶群體的需求特征（懂程序？懂設計？…）？用戶的操作習慣（比如設計師大部分都會使用PS，是按照PS的設計風格來做？…）？等等，一大堆的問題，在做產品前，先盡量的總結這些疑問，然后給產品一個比較好的定位。

程序員思維：一款優秀的工具具備有高拓展性，方便易用，性能卓越，我們的目標不只是做工具，還要做一個vscode一樣的高擴展性的工具，如何解決高擴展性的問題？如何做編輯器的內核抽離？這些應該是程序員考慮的事情。

如何推廣？如何包裝？如何運營？如何讓這個項目火起來并被大家接受和認可？如何讓更多程序員參與其中？這些是站在一個運營人員的角度考慮的問題。

兼顧以上幾點，我們不僅是一個優秀的程序員，還是一個優秀的產品經理，更是一個接地氣的運營人員，當我們做項目的前期，無論是產品，程序員，運營推廣，這些方面的都得考慮到，雖然一個人不能做全部的工作，但是懂點不至于被別人忽悠。如果你的目標是做管理而不僅僅是一個程序員，那這些能力，多少應該掌握一點。

技術選型如下：

前端：react, mobx, less, jquery
后端：nodejs, mysql, ngnix
工具：babel, webpack, gulp, eslint
H5DS的技術選型基本上是JS的技術棧，只能說這套技術很前端。接下來我解釋下，為什么要這樣選型。

why react ?

整個H5頁面制作的思路是這樣的：生成后的H5頁面雖然是單頁，但是單頁下面還是有多個子頁面，我們可以大致的可以分為3個類。APP包含了整個頁面的內容。Page包含了單個子頁面的內容，Layer是每個子頁面里面的元素。這樣理解我們的思路就很清晰了。每個H5頁面對應有一個JSON文件，而JSON轉化為JSX模板，再通過renderToStaticMarkup將JSX轉化為HTML, 我覺得這幅圖是最有效的說明，react強大的服務端渲染函數，可以直接吧JSX轉化為HTML。沒有任何人說過，服務器渲染方法就只能在服務器端使用，這里我直接拿到前端使用，而且效果還非常棒，具體的方法renderToStaticMarkup

// 這個JSON 文件大致格式
{
  ...,
  "name": "H5頁面名稱",
  "desc": "H5頁面描述信息",
  "pic": "主圖URL",
  "pages": [ // H5由多個子頁面組成
    {
      ...,
      layers: [] // 子頁面由多個圖層組成
    }
  ]
}

// JSX -> HTML 的方法
import { renderToStaticMarkup } from "react-dom/server";
renderToStaticMarkup(JSX);

why mobx ?

我是個野蠻的開發者，喜歡用最簡單的代碼，去實現業務，而mobx更加靈活多變，沒有那么多限制和約束，而redux好比墨守成規的名門子弟，雖然約束是可以讓代碼更加規范，如果是以大量的代碼堆積出來的規范，我還是覺得已經脫離了技術的實際意義，同樣是增加維護成本的，我絕對不是一個合格的程序員，如果能 code less，do more，我寧愿犧牲規范不擇手段。

why jquery ?

之前很多朋友這樣對我說：用了react就不要用jquery了，jquery能做的事情react也能做，為什么還要用其他庫？一點也不規范。其實我的回答往往是這樣的：我比較任性，而且喜歡jquery！為什么都普遍認為jquery和react不要共存，大致有以下幾點：

從框架層面講，react可以通過state修改dom，數據會從Virtual DOM到真實的DOM走一遍，如果用了jquery是直接修改DOM，這樣導致的結果就是state和真實的DOM就不能對應起來了，react也就失去了他存在的意義。

從思想方面來講，jquery直接操作dom和react的思想所違背。

但是實際的業務千變萬化，有哪個框架能說自己能輕松實現所有業務？jquery是工具庫，react是ui庫，如果運用得當，個人覺得配合起來還是非常不錯的選擇！有時候用jquery操作DOM，在性能方面能完勝react。比如拖動排序功能！

技術選型的問題說完了，接下來聊聊整個項目的架構吧！

第三個模塊大家仔細看會發現，實際上是和中間的業務層獨立開的，這樣更有利于項目的擴展和二次開發。第三個模塊這里我們把他定義為內核，基于這個內核，我們可以做web層，server層，以及擴展layer層，內核更像ueditor那樣的存在，可以直接在項目中引用，讓內核不再依賴任何server，可以獨立使用。

做工具類的項目，性能是非常大的挑戰，我總結了以下幾個常見的性能優化點：

數據緩存。（indexeddb,localStorage,localSession）

交互優化。（防抖debounce，節流throttle，事件委托）

內存釋放。（componentWillUnmount，DOM釋放，引用地址釋放）

因為編輯器中，圖片裁剪是常用的功能，如果采用傳統裁剪模式（前端把裁剪信息傳到服務器，由服務器完成裁剪，返回新的url）對服務器的壓力非常大，為了節約這些性能開銷，我們自創了一個裁剪的方法，圖片裁剪后，并沒有直接丟到服務器去，該方法大大節約了服務器的開銷。具體業務流程如下：

拖動排序如果用純react去實現。業務應該是這樣的：

如果用jquery + react 去實現：

第二種結合jquery的方式，大大減少了react中render函數的執行，不用多次執行diff操作，實現了高性能的拖動方案。

我們固定了顯示區域大小為 320 x 514，要兼容所有機型，就要對其進行縮放處理，要么高100%，要么是寬100%，通過JS去計算顯示區域的縮放比例，然后居中處理，就可做到最大化的兼容各種機型。背景是全局的，示意圖分別表示手機常用尺寸的實例，高度超出的處理，寬度超出的處理，紅色部分是顯示區域，灰色部分是320*486的原始尺寸比例，黑色陰影部分是灰色部分進行scale縮放填充的區域。

項目已經在github( https://github.com/h5ds/h5ds ) 上面開源，供大家學習使用，擁抱開源是我們的選擇，但是希望大家能遵守使用規范，針對個人，我們是免費的，但是針對商業使用，我們是收費的，這個決定相信大家都能理解。

歡迎加入QQ群交流：549856478