摘要：提供的圖表的確可以滿足大部分的需求，遵循了數(shù)據(jù)可視化的一些經(jīng)典范式。數(shù)據(jù)可視化已然成為了新的風(fēng)向標(biāo)。數(shù)據(jù)團(tuán)隊(duì)的前端要做的就是用最科學(xué)的方法向用戶展示最形象的圖表，而這，也是我們前行的目標(biāo)。

也許很多人都會(huì)覺得奇怪，在這樣一個(gè)更多以后臺(tái)數(shù)據(jù)分析為主的公司，為什么需要一個(gè)專注于前端的團(tuán)隊(duì)？今天這篇文章就來(lái)講述那些年我們錯(cuò)過的前端數(shù)據(jù)可視化，以此來(lái)解答這個(gè)問題。

那么，在我們的項(xiàng)目中是如何實(shí)現(xiàn)數(shù)據(jù)可視化的呢？下面以這樣一個(gè)需求開始我們的講解：我們需要向用戶展示目前用戶產(chǎn)品的風(fēng)險(xiǎn)情況，有沒有風(fēng)險(xiǎn)產(chǎn)生、產(chǎn)生于何地、是否被攔截等信息。

最終效果圖：

說到數(shù)據(jù)可視化，可謂是百花齊放，一時(shí)之間前端界出現(xiàn)了琳瑯滿目的第三方庫(kù)： Highcharts ， Echarts ， Chart.js ， D3.js 等。但是，萬(wàn)變不離其宗。

總的來(lái)說，所有的第三方庫(kù)都是基于這兩種瀏覽器圖形渲染技術(shù)實(shí)現(xiàn)的： Canvas 和 SVG 。

通過各種比較之后，我們最終選擇基于 D3.js 進(jìn)行開發(fā)。

“
*為什么不選用更加豐富的圖形庫(kù)，比如 Echarts ？
——數(shù)據(jù)可視化看似簡(jiǎn)單，但其中蘊(yùn)含的科學(xué)可謂博大精深。*
”

Echarts 提供的圖表的確可以滿足大部分的需求，遵循了數(shù)據(jù)可視化的一些經(jīng)典范式。然而，每個(gè)不同的行業(yè)對(duì)于數(shù)據(jù)可視化都會(huì)有一些定制化的需求，希望能以一些帶有行業(yè)特征的圖表向使用者展示數(shù)據(jù)背后隱藏的秘密。

因此，我們希望可以使用一個(gè)比較基礎(chǔ)的圖形庫(kù)，這個(gè)庫(kù)對(duì)一些基礎(chǔ)算法進(jìn)行了封裝。然后在此基礎(chǔ)之上，我們可以進(jìn)行二次開發(fā)，定制適合的圖表向用戶展示更有針對(duì)性的數(shù)據(jù)。

“
*為什么不選用基于 Canvas 的庫(kù)？
——我們的應(yīng)用存在大量的用戶交互場(chǎng)景。*
”

在 Canvas 中，如果要為細(xì)粒度的元素添加事件處理器，必須涉及到邊緣檢測(cè)算法，無(wú)疑為開發(fā)帶來(lái)了一定的難度，同時(shí)，采用這種方法并不一定精確。相比之下，SVG 是基于 DOM 操作的，支持更精確的用戶交互，無(wú)疑更適合我們這樣一個(gè)小規(guī)模的團(tuán)隊(duì)。

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

眾所周知，頻繁的 DOM 操作十分消耗性能。對(duì)于用戶體驗(yàn)的影響便是可能出現(xiàn)閃爍、卡頓等現(xiàn)象。幸好，偉大的前端界對(duì)于這個(gè)問題已經(jīng)有了解決方案：?Virtual DOM 技術(shù)。

所以我們要做的，就是選擇一個(gè)支持 Virtual Dom 技術(shù)的框架與 D3.js 結(jié)合使用。同時(shí)，我們的最終目標(biāo)是將這些圖標(biāo)封裝成可復(fù)用的組件。

因此，最終我們選擇了 facebook 出品的 React 。這是一個(gè)相對(duì)輕量、簡(jiǎn)單、專注于 View 的庫(kù)。

細(xì)心的讀者一定會(huì)提出這樣一個(gè)問題：既然是一個(gè)實(shí)時(shí)數(shù)據(jù)展示圖表，如何做到如此頻繁且流暢地渲染大量數(shù)據(jù)？其實(shí)很簡(jiǎn)單，關(guān)鍵在于把握以下兩個(gè)階段：

數(shù)據(jù)的獲取。

在這里，我們主要還是采用了客戶端主動(dòng)輪詢拉取的方式。只要選定了采樣頻率，剩下的就是每隔一段時(shí)間從服務(wù)器拉取數(shù)據(jù)了。

當(dāng)然，這種方式的缺點(diǎn)也顯而易見：由于延時(shí)造成的數(shù)據(jù)滯后，并且隨著時(shí)間的推移，這種滯后會(huì)越來(lái)越嚴(yán)重。

為了解決這一問題，我們會(huì)在一段時(shí)間之后進(jìn)行數(shù)據(jù)實(shí)時(shí)性的校正。

數(shù)據(jù)的渲染。

需求中，攻擊情況需要依據(jù)時(shí)間順序進(jìn)行展示，表現(xiàn)為一條從攻擊源到攻擊目標(biāo)的運(yùn)動(dòng)軌跡。如果一段時(shí)間內(nèi)產(chǎn)生了大量的攻擊，那么頁(yè)面中的 DOM 元素會(huì)迅速增加，渲染速度變慢，出現(xiàn)卡頓現(xiàn)象。

為了解決這一問題，當(dāng)每一條運(yùn)動(dòng)軌跡展示完畢的時(shí)候，相應(yīng)的 DOM 元素會(huì)被及時(shí)銷毀。當(dāng)更大量的攻擊產(chǎn)生時(shí)，我們會(huì)控制展示的數(shù)量，同時(shí)發(fā)出警告，因?yàn)檫@明顯已經(jīng)屬于一種攻擊非常極端的情況了。

事實(shí)上，對(duì)于實(shí)時(shí)數(shù)據(jù)的處理，前文所述的方法并不是最佳實(shí)踐，只能說是一種降級(jí)方案。我們的長(zhǎng)遠(yuǎn)目標(biāo)是要做到真正的實(shí)時(shí)數(shù)據(jù)展示，因此下一步我們會(huì)實(shí)時(shí)數(shù)據(jù)推送技術(shù)，敬請(qǐng)期待。

大數(shù)據(jù)時(shí)代，前端也迎來(lái)了新的挑戰(zhàn)。數(shù)據(jù)可視化已然成為了新的風(fēng)向標(biāo)。數(shù)據(jù)團(tuán)隊(duì)的前端要做的就是：用最科學(xué)的方法向用戶展示最形象的圖表，而這，也是我們前行的目標(biāo)。

反爬蟲
文章來(lái)源：http://bigsec.com/

張靜 豈安科技前端架構(gòu)師?
三年互聯(lián)網(wǎng)前端開發(fā)經(jīng)驗(yàn)，曾參與多個(gè)大型應(yīng)用的前端開發(fā)，負(fù)責(zé)豈安科技產(chǎn)品的前端架構(gòu)設(shè)計(jì)與開發(fā)。