關於資料視覺化第三方庫的選擇

最終需求與效果圖：我們需要向使用者展示目前使用者產品的風險情況，有沒有風險產生、產生於何地、是否被攔截等資訊。

說到資料視覺化，可謂是百花齊放，一時之間前端界出現了琳琅滿目的第三方庫： 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 元素會被及時銷毀。當更大量的攻擊產生時，我們會控制展示的數量，同時發出警告，因為這明顯已經屬於一種攻擊非常極端的情況了。

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