D3.js開發數據可視化，性能方面和highcharts,echarts對比區別是什麼？哪個性能更好的使用在PC端

12-29

最近想用d3.js做一些可視化的數據圖，糾結性能方面

都用過的飄過，用過=知道這個東西、寫過一些demo或者項目，但庫自身的源碼沒有深究。

Highcharts和echarts是一類東西，但跟d3.js維度不同。假如前面兩個能解決你的需求，那麼就可以先不考慮d3。英語好選highcharts，英語不好選echarts。當然最好要先評估一下它們對瀏覽器的兼容性，免得寫完了發現用戶那運行不了。

Highcharts和echarts基本上就是畫圖表用的，它們自帶的圖表類型能滿足你最好，滿足不了的話你就自求多福。

而d3.js 更自由些，你很容易去做出自己想要的效果，比如mind chart、heat chart、tile chart 之類的東西。某天客戶要求你做一個xx chart，你一看卧槽highcharts沒有，就只能找d3.js或者rapha?l js自己擼一個，美觀度和工作量都要自己把握。

而性能方面，簡單圖表都沒什麼問題，數據量大、複雜運算、動畫效果多的話，都快不了，區別就是svg性能更差，canvas能好不少罷了。

乾巴巴的對比可讀性並不高，也很難讓人有真實對比的聯想。我以我們工作中遇到的一個需求來對比講解。以下，GO~

---

我是豈安科技前端架構師靜~，也許很多人都會覺得奇怪，在我們這樣一個更多以後台數據分析為主的公司，為什麼需要一個專註於前端的團隊？在我們的項目中是如何實現數據可視化的呢？下面以這樣一個需求開始我們的講解：我們需要向用戶展示目前用戶產品的風險情況，有沒有風險產生、產生於何地、是否被攔截等信息。

最終效果圖：

技術選型

說到數據可視化，可謂是百花齊放，一時之間前端界出現了琳琅滿目的第三方庫： Highcharts ， Echarts ， Chart.js ， D3.js 等。但是，萬變不離其宗。

總的來說，所有的第三方庫都是基於這兩種瀏覽器圖形渲染技術實現的： Canvas 和 SVG 。

通過各種比較之後，我們最終選擇基於 D3.js 進行開發。

為什麼不選用更加豐富的圖形庫，比如 Echarts ？
——數據可視化看似簡單，但其中蘊含的科學可謂博大精深。

Echarts 提供的圖表的確可以滿足大部分的需求，遵循了數據可視化的一些經典範式。然而，每個不同的行業對於數據可視化都會有一些定製化的需求，希望能以一些帶有行業特徵的圖表向使用者展示數據背後隱藏的秘密。

因此，我們希望可以使用一個比較基礎的圖形庫，這個庫對一些基礎演算法進行了封裝。然後在此基礎之上，我們可以進行二次開發，定製適合的圖表向用戶展示更有針對性的數據。

為什麼不選用基於 Canvas 的庫？
——我們的應用存在大量的用戶交互場景。

在 Canvas 中，如果要為細粒度的元素添加事件處理器，必須涉及到邊緣檢測演算法，無疑為開發帶來了一定的難度，同時，採用這種方法並不一定精確。相比之下，SVG 是基於 DOM 操作的，支持更精確的用戶交互，無疑更適合我們這樣一個小規模的團隊。

所謂成也蕭何敗蕭何。這裡的蕭何源於 SVG 是基於 DOM 操作的。

眾所周知，頻繁的 DOM 操作十分消耗性能。對於用戶體驗的影響便是可能出現閃爍、卡頓等現象。幸好，偉大的前端界對於這個問題已經有了解決方案： Virtual DOM 技術。

所以我們要做的，就是選擇一個支持 Virtual Dom 技術的框架與 D3.js 結合使用。同時，我們的最終目標是將這些圖標封裝成可復用的組件。

因此，最終我們選擇了 facebook 出品的 React 。這是一個相對輕量、簡單、專註於 View 的庫。

實際問題

細心的讀者一定會提出這樣一個問題：既然是一個實時數據展示圖表，如何做到如此頻繁且流暢地渲染大量數據？其實很簡單，關鍵在於把握以下兩個階段：

1. 數據的獲取

在這裡，我們主要還是採用了客戶端主動輪詢拉取的方式。只要選定了採樣頻率，剩下的就是每隔一段時間從伺服器拉取數據了。

當然，這種方式的缺點也顯而易見：由於延時造成的數據滯後，並且隨著時間的推移，這種滯後會越來越嚴重。

為了解決這一問題，我們會在一段時間之後進行數據實時性的校正。

2. 數據的渲染

需求中，攻擊情況需要依據時間順序進行展示，表現為一條從攻擊源到攻擊目標的運動軌跡。如果一段時間內產生了大量的攻擊，那麼頁面中的 DOM 元素會迅速增加，渲染速度變慢，出現卡頓現象。

為了解決這一問題，當每一條運動軌跡展示完畢的時候，相應的 DOM 元素會被及時銷毀。當更大量的攻擊產生時，我們會控制展示的數量，同時發出警告，因為這明顯已經屬於一種攻擊非常極端的情況了。

未來展望

事實上，對於實時數據的處理，前文所述的方法並不是最佳實踐，只能說是一種降級方案。我們的長遠目標是要做到真正的實時數據展示。

哈哈看到 @魯小夫說的「卧槽highcharts沒有，就只能找d3.js或者rapha?l js自己擼一個」，一口水噴到屏幕上。。。

我默默的來安利一個可以幫助擼d3.js的網站。 Search the Blocks。可以按圖表類型搜索，如：bar chart, donut chart。還可以搜API （如, d3.layout.force），或自己喜歡的作者github id（如：mbostock）。也可以在這個網站上在瀏覽器中直接fork一個block，很容易的實驗和修改。這樣擼起d3.js來可能和highcharts一樣快啦！:D

另外關於d3.js性能－最近也有比較流行把react和d3一起用的。利用react的virtual dom，只用d3計算。

都用過的路過，echarts和highcharts是一類的東西，但echarts是免費的，highcharts商業使用需要授權，還有echarts可以不經過伺服器直接保存為圖片。echarts視覺效果一般是要美於hichcharts的，echarts在大數據方面性能是比較好的，如果數據量比較大，可以考慮echarts。如果是一些簡單的數據，而客戶對界面定製較多，可以考慮使用highcharts。畢竟highcharts基於svg，方便自己定製。而echars是基於canvas,如果熟悉canvas,可以看看百度zrender,進行一定的定製開發也是可以的。

而d3.js可能適合那些高度定製的項目，不管怎麼說，能不用盡量少用，坑太多。請高手忽略最後一句。

d3.v3及之前版本是基於SVG的，數據量多的話就呵呵～
BUT
d3.v4出來了，支持Canvas+SVG，如果計算比較密集，那用Canvas畫，妥妥的。如果數據量不是很大，並且注重交互，那就上SVG。或者兩者結合。
………………………………
不小心挖了個墳

畢業論文的neo4j資料庫要用 D3來實現。我也是醉了。我覺得d3的效果挺好看。。。來自一個膚淺的菜鳥

d3做圖可以定製，但是學習成本比echarts高得多後者拿起來就能用而且兼容到ie6 highcharts效果不行

看了上面各種對比，吐槽一下

d3: 看不懂貝塞爾曲線，局部曲率，顯著性水平、極坐標……和英語是我的鍋咯

ps: D3這個大庫代碼組織的非常好，有紮實數理基礎的都不會很難hold住，相比之下，p5雖然也有大量統計和處理介面，但是組織地就明顯不如（D3源自Stanford的博士論文，p5源自MIT），可以說這兩個是相當有核心競爭力的，也比較底層，幫你封裝的都是曲線、二項分布之類的數學抽象，門檻也能篩出高水平使用者；此外的各種chart只是根據Spec寫出大眾功能的，開箱即用，但也分分鐘可以被其他的代替（只是用的爽不爽的主觀問題），對比類似於VS和Vim。有條件還是應當學d3，v4基於canvas，hold住了封個MyChart不是問題

請問一下，用磚頭和用預製板蓋房子哪個好？

我認為用轉頭更靈活預製板不專業

這兩個應該不是一個層面的東西更底層直接操作svg就好基本上ps輸出 snap.svg做就好

highchants更高層一些

性能方面數據量多 svg方向的d3壓力很大幾百萬個數據點就不用想了一定要用基於canvas的echarts

@大大啊大大「D3源自Stanford的博士論文」，啥論文呀？