系統虛拟化已過時，Containers将主導未來的雲架構？

2013年7月初，百度商業前端資料可視化團隊釋出了開源JavaScript圖表庫ECharts的1.1.0版本，引起了廣泛關注。ECharts基于HTML5 Canvas，是一個純Javascript圖表庫，提供直覺，生動，可互動，可個性化定制的資料可視化圖表。

經ECharts開發者介紹，InfoQ編輯整理了一些有關這個圖表庫的相關資訊，分享給大家。

ECharts的目的

ECharts的開發是為了解決資料可視化的問題。它是一個web前端資料可視化的解決方案，面向前端開發人員使用，可以輸出具有可互動圖形使用者界面的資料可視化圖表。

資料可視化一路發展過來，從簡易圖表階段（缺乏視覺表現力），到注重視覺表現力的資訊設計階缺段（乏對資料的深入了解，往往産生視覺誤導），再到今天大家看到的很多沖擊力極強的資料可視化作品（如TED的無數作品，資料分析與視覺表現力充分結合），這顯然不會是終點。資料可視化在國際上正在進入一個新的階段，深度資料互動，在這個階段将打破平面的視覺效果，實作了人機互動式的跨平台操作，真正的将資料帶入到任何工作場合中，幫助人更好的掌握資料價值。業界領先的Tableau就是個很好的例子，或者如初創企業zoomdata所做的也能說明這一趨勢，而ECharts也正朝着這個目标出發。

ECharts的思路

如維克托 • 邁爾 - 舍恩伯格教授的《大資料時代》所述，大資料時代有幾個特點需要人們轉變思維或适應變化，其中很重要的一點就是“社會需要放棄它對因果關系的渴求，而僅需關注相關關系”。人們更需要關注“資料是什麼”。ECharts的特性設計正是以此為出發點，呈現資料真實的一面，并且提供了一些直覺、易用的互動方式以友善使用者對所展現資料進行挖掘、提取、修正或整合，通過系列選擇、區域縮放、數值篩選等不同方式讓使用者可以更加專注于他們所關心的地方，可以有更豐富的呈現方式解讀資料。

ECharts的實作

ECharts的實作，表面上是canvas，但ECharts内在的技術特征應該是資料驅動和基于消息的耦合剝離。通過底層canvas類庫ZRender，ECharts代碼裡幾乎可以無視canvas的存在。

熟悉KineticJS、EaselJS或者oCanvas的朋友應該對canvas基礎庫的概念不陌生。ZRender是一個輕量級的canvas類庫，MVC封裝，資料驅動，提供類Dom事件模型。這個canvas類庫讓開發者寫起canvas應用時就像寫web頁面一樣。此外，css style的樣式屬性定義，層疊，MVC架構（CURD、render & refresh），promise式的動畫接口，也都是如此設計。

ZRender同樣是百度商業前端資料可視化團隊的作品，裡面也有很多有意思的東西。

雖然說大資料的含義并不是“資料量大”，但大資料強調的考察對象從“随機樣本”到“總體”的轉變趨勢不可避免的帶來了需要展現大量資料的需求。這或許是ECharts技術選型上為什麼是canvas而不是svg的重要原因，在有限區域内顯示盡可能多的資料，ECharts的大規模散點圖充分利用了canvas的像素處理能力，這或許已經達到了現有web呈現能力的極限，而顯示性能跟顯示一張圖檔無異。抛開像素處理能力不說，同樣呈現普通的圖形，你很難想象浏覽器建立10萬個svg DOM會有多麼吃力，而用canvas渲染10萬個圓僅需500ms左右（chrome）。

在ECharts中涉及的一些技術細節：

• 依賴excanvas相容IE8-。
• 遵循AMD子產品化标準，圖表按需加載。
• 地圖由基于svg格式的矢量資料生成，底層ZRender會轉換成canvas的路徑。
• 旋轉、平移、動畫的實作，被轉成矩陣運算來解決。
• 反複渲染的性能問題，采用了分層重新整理和dirty flag進行了優化。
• 基于包圍盒和純數學方法解決同時大大優化了圖形hover判斷。
• 圖表和控件間采用消息中心進行通信協作。

ECharts的接口方法很簡單，但有一個很龐大的配置項集合。為了讓設定合理，犧牲了很多實作成本。ECharts團隊認為，接口設計的合理比起實作成本重要得多。