背景

自2011年browserify誕生開始，到我們現在更為廣泛應用的webpack / rollup / parcel等構建工具的普及，構建及工程化已經變成了前端開發者的開發生態中不可或缺的部分。日常開發中，我們已經習慣跟隨ESMAScript或TypeScript的新特性，這些特性往往具有更簡單的語法、更高的執行效率，比較典型的例子就是ES6中class :

classPerson{constructor(name){this.name=name;}greeting(){return`Hi, this is ${this.name}.`;}}classManextendsPerson{}

但如果要用構建函數和原型鏈去實現兩個類的聲明並實現繼承，我相信大多數人會崩潰：

functionPerson(name){this.name=name;}Person.prototype.greeting=function(){return`Hi, this is${this.name}.`;}functionMan(name){Persona.call(this,name);}Man.prototype=Object.assign(Person.prototype);Man.prototype.constructor=Man;

問題在於，這些提效的新特性並不能100%的運行在所有的瀏覽器中，比如上個時代的噩夢- IE8.在這樣的背景之下，就誕生了6to5這樣的編譯器，來幫助我們把開發時的ES6的語法編譯成ES5的語法，從而執行在瀏覽器中，當然6to5也跟隨我們一起進化，變成了現在的babel .

但babel也不是萬能膏藥，雖然幫助我們解決了語法的問題，但也帶來了一些副作用，比如編譯後的代碼通常都會插入一些內置的函數或者Pollyfill，這也就造成了代碼體積的驟增，上文中我們class Person的源碼實現總共155B ,使用babel編譯成ES5的代碼後，體積變成了2.7K !

從我們認為的JavaScript 下一代的标准的開始-- ECMAScript 2015到現在已經過去5年多的時間了，ECMAScript每年都會不斷的推進語言標準的更新，而瀏覽器廠商除了參與標準的指定，也在不斷的跟進著新的語言標准在瀏覽器中的原生實現的支持。不知道你有沒有註意到，在2021年的今天， class的瀏覽器支持率已經達到了95% ,所有的主流瀏覽器都已支持class特性：

類似於class這類特性，如果瀏覽器已經支持了，但我們還是把編譯後的體積更大、執行更慢的ES5代碼交給瀏覽器，不管是構建、存儲、傳輸還是執行，無疑都是一種浪費。而這就關係到我們這篇文章的主題： Modern JavaScript .

什麼是Modern JavaScript

Modern JavaScript指的不是哪一個特定版本的ECMAScript標準，而是指的一系列已經被現代瀏覽器所支持的特性的集合。

我們常說的現代瀏覽器包括：Chrome, Edge, Firefox, Safari, 它們佔了瀏覽器市場份額的90% 以上，除此之外，還有一些基於跟上述瀏覽器相同渲染引擎的瀏覽器實現，比如UC, QQ 等也佔了5% 左右的份額。這也就意味著，我們廣泛使用的一些特性已經得到了95% 的支持，主要包括：

• 類class
• 箭頭函數arrow function
• 構造器generator
• 塊級作用域let / const
• 解構destructuring
• Rest參數rest and spread parameters
• 對像簡寫object shorthand
• Async函數async / await

Modern JavaScript 不是一個固定的特性集合，它是動態跟隨我們所定義的現代瀏覽器的的支持度的。就目前而言， ES2017是最接近Modern JavaScript的標準。

Legacy JavaScript

對應Modern JavaScript, 我們編譯完的ES5 的結果就可以稱為Legacy JavaScript, 它是我們向瀏覽器兼容器委屈求全的結果。

在現代瀏覽器中，這種轉換是得不償失：我們通過編譯讓我們的代碼支持度從95% 上升到了98%, 然而這卻給我們帶來了20% 的代碼體積的上升，同時代碼執行效率會變得更低。另外，在node_modules hell的加成下，這個影響可能是指數級的。

如何使用

1. 瀏覽器

<script type="module" />

現代瀏覽器支持通過<script type="module" />直接在瀏覽器中ES6+的代碼，因此我們可以通過這種方式來為現代瀏覽器加載Modern JavaScript,而小部分的老瀏覽器則由fallback邏輯兜底，加載執行Legacy JavaScript.

<scripttype="module"src="https://cdn/modern.js"/><scriptnomodulesrc="https://cdn/ledacy.js"/>

2. NPM

{ "exports": "./modern.js" }

在Node.js@12.7.0的版本中，引入了package.json中的exports字段，來增強原先僅能通過main聲明的包入口的功能。

{"main":"./index.js","exports":{".":"./index.js","./submodule":{"import":"./submodule/index.js","require":"./submodule/index.cjs"}}}

通過上面的入口聲明我們可以實現對外暴露默認入口以及submodule的入口，並且submodule可以根據是require還是import提供不同的實現：

importpkgfrom'pkg';importsubmodulefrom'pkg/submodule';constsubmodule=require('pkg/submodule');

exports除了提供了多入口以及條件入口等強大的功能外，也可以作為提供了Modern JavaScript實現的依據，因為Node.js@12.7.0已經支持ES2019了，所以在構建時如果檢測到node_modules中的模塊提供了exports entry,可以為它們單獨構建我們的Modern JavaScript Bundle.

3. Bundle

通過上述瀏覽器和NPM 包的對Modern JavaScript 特性的支持，我們已經解決了出口的問題，並且在不支持的場景下也都可以fallback 到Legacy JavaScript 來執行。

接下來只需要資源構建的問題即可，我們需要提供滿足95% 的現代瀏覽器可執行的Modern JavaScript Bundle 以及fallback 剩餘的老瀏覽器的Legacy JavaScript Bundle.

通過babel配合不同的browserslist targets就可以簡單的達成目標。當然也有一些現成的插件可以直接使用，比如optimize-plugin , babel-esm-plugin或者babel-preset-modern-browsers等。

而在構建模式上，我們可以選擇從源碼分別構建出Modern Bundle 和Legacy Bundle:

亦或是先從源碼構建出Modern Bundle, 然後從Modern Bundle 再構建出Legacy Bundle:

圖片來源: https:// web.dev/publish-modern- javascript/

Modern JavaScript 其實更像是一種理念，而不是一種技術，通過Modern JavaScript 可以讓開發者、用戶享受到技術進步帶來的福利，更甚者，Modern JavaScript 所帶來的存儲、傳輸、執行上的提升還能為地球節能減排。

擺脫ES5 的禁錮，向Modern JavaScript 轉型！

相關

* Transitioning to modern JavaScript

* Publish, ship, and install modern JavaScript for faster applications

* Serve modern code to modern browsers for faster page loads

* Bringing Modern JavaScript to Libraries

SEE Conf 2021將於2021年1月9日在杭州螞蟻Z空間舉辦。大會網站： https:// seeconf.antfin.com/

SEE Conf（支付寶體驗科技大會）是由螞蟻集團主辦的，集專業分享、展台等內容於一身的科技盛筵。 SEE 是Seeking Experience & Engineering 的縮寫，意為探索用戶體驗與工程實踐。我們希望通過SEE Conf, 與業界同行一起分享交流體驗科技的當前進展，探討切磋體驗科技的未來發展，共同努力促進體驗設計與技術的開放，讓生態繁榮共贏。

2020年1月初，SEE Conf 2020在西湖文體中心成功舉辦， 將設計與技術相融合，配合IMAX 大屏+ 杜比全景聲音效，給與會的近千位Developers & Designers 帶來了極致的體驗，在知乎引發了熱烈關注與討論。

一年時光彷若白駒過隙，如今我們又將迎來SEE Conf 2021 了～

SEE Conf 2021將於2021年1月9日在杭州螞蟻Z空間舉辦。下面讓我們來了解一下本屆SEE Conf 都有哪些看點吧～

主題&會場

本次的主題是「探索極致用戶體驗與最佳工程實踐」，會議時長為一天，仍以上午主會場+下午設計&技術分會場的形式開展，大家可以根據自己的興趣選聽。

除了主題演講之外，現場還有豐富的展台供大家互動、我們也邀請了樂隊現場表演～

重磅大咖

辛向陽

辛向陽，教授、博士生導師，XXY Innovation創始人，卡耐基梅隆大學設計哲學博士，四川美術學院特聘教授、澳門科技大學、江南大學、天津大學兼職教授。曾任江南大學設計學院院長、香港理工大學交互設計碩士課程主任等職務。具有跨機械、建築、平面設計、油畫、交互設計以及藝術史多個學科的教育和工作背景，主要研究交互、體驗、服務設計和組織創新等新興領域，提出了“交互五要素”、“行為邏輯”、“從用戶體驗到體驗設計”、服務設計“AC/EM”定位、“設計的蝴蝶效應：當生活方式成為設計對象”等交互與服務設計領域重要理論和方法。

辛向陽教授策劃和共同組織了交互設計國際大會、國際體驗設計大會、“設計教育再設計”、TTF轉型趨勢論壇等重要係列國際會議；應邀作為包括GMark、IXDA、紅星獎、台灣優秀工業設計大獎、台灣智造大獎等重要設計大賽評委；為寶潔公司總部、美國國家郵政局、香港特區政府、香港應用科技研究院、香港博愛醫院、GE、華為、長虹、騰訊、震旦、三星等公司提供過多種顧問獲研發服務；先後獲台灣工業設計十佳教育工作者、光華龍騰台灣設計貢獻獎銀質獎章、國際交互設計協會“交互設計未來之聲” 年度大獎、江蘇省歸僑僑眷先進個人、江蘇省教學成果一等獎、國家教學成果獎二等獎、光華設計基金會台灣設計貢獻獎金質獎章、“改革開放40年台灣設計40人”、“新台灣成立七十年台灣設計70人”等榮譽稱號。

辛向陽教授將為我們帶來「動機：戰略決策中的隱蔽因素」主題演講。

玉伯

作為體驗技術部的負責人，玉伯對於SEE Conf這個baby可謂關心備至，每一屆都會進行「體驗科技」主題分享，上一屆的「 體驗科技與好的產品」分享啟發了不少小伙伴（當然包括我啦嘿嘿）～

一起期待這次玉伯帶來的分享吧！

演講主題

主會場

• 開場主題演講
• 動機：戰略決策中的隱蔽因素
• Ant Design 資產工程化探索和實踐
• 圖釋萬物- AntV 圖可視分析解決方案
• 你不了解的Web動畫

設計分會場

• 普惠金融下的支付寶包容性設計
• 理財新趨勢：直播讓金融服務更普惠
• 新製造場景下的設計驅動：體驗直達一線
• 多元設計做物流數位化賦能-從軟硬一體到空間行為一致

技術分會場

• 企業級前端框架與工程化實踐
• 支付寶視覺稿轉代碼技術探索和實踐
• 支付寶小程序體驗優化實踐

更多演講主題盡請期待！

大會門票

本次門票統一定價為199元，技術場與設計場同價。

售票時間：即刻起至2021年1月8日

購票方式：直接掃描下方二維碼，或者點擊鏈接即可購票。

PS ：由於螞蟻Z空間園區容納人數有限，門票數量有限，感興趣的朋友請趕緊搶票哈，售完即止喲～

第一個使用TypeScript + Vue 3.0 Composition API 重構的組件庫Element Plus 發布了~

2016 年3 月13 日Element 悄然誕生，經歷了4 年的風雨洗禮，我們從一個餓了麼內部業務組件庫成長為Vue 生態裡最流行的UI 組件庫之一。

截至本文撰寫時，Element已獲得48200 Github Star， NPM下載量95萬次/每月的可喜成績。感謝超過530 名社區貢獻者的參與維護，和我們一同完成了4400 次commit 的更新迭代。

*Element 開發團隊40000 Github Star 慶祝會

Element Plus for Vue 3.0

2020 年，隨著Vue 3.0 不斷完善和發布，我們也緊張投入到Element 對Vue 3.0 的升級適配工作中。歷經6 個月共計23 個alpha 版本的迭代，終於，在今天， Element Plus for Vue 3.0 Beta 版本正式發布！

https:// github.com/element-plus /element-plus

Vue 3.0 的大版本升級，對生態組件庫來說也是一次丟掉歷史包袱前行的好機會，我們大刀闊斧對Element 進行了一次深度重構。

Element Plus for Vue 3.0 是一個使用TypeScript + Composition API 重構的全新項目。我們幾乎重寫了每一行Element 的代碼，用最Vue 3 的方式呈現了最完美的Element，主要有：

• 使用TypeScript 開發，提供完整的類型定義文件
• 使用Vue 3.0 Composition API 降低耦合，簡化邏輯
• 使用Vue 3.0 Teleport 新特性重構掛載類組件
• 使用Lerna 維護和管理項目
• 使用更輕量更通用的時間日期解決方案Day.js
• 升級適配popperjs, async-validator 等核心依賴
• 完善52 種國際化語言支持

除此以外，還有：

• 全新的視覺*
• 優化的組件API
• 更多自定義選項
• 更加詳盡友好的文檔

Q：Element Plus 和Element UI 是什麼關係? 為什麼又一個新項目？

正如vue-next之於vue ，一次100%的重構雖然解決了很多歷史遺留問題，但也不可避免的引入一些新的bug和問題，而獨立的issue和pr區可以減少大家使用和反饋的心智成本，也能更加方便我們定位問題，並行維護迭代。

Element will stay with Vue 2.x

For Vue 3.0, we recommend using Element Plus from the same team

具體可以參考Element的README https:// github.com/ElemeFE/elem ent/blob/dev/README.md

Q: 老Element 項目可以平滑升級到Vue 3.0 + Element Plus 嗎？

由於Vue 3.0 升級引入了部分API 的調整，老項目的升級不可避免的要做些許改動。但我們力爭把變更內容做到可控，只需要很少的調整就能完成項目升級。在今後Vue 3.0 的項目裡，還是熟悉的Element 的配方和味道。

Q: Element UI 還會維護嗎？

當然會！ (而且一直在正常迭代發布呀ヽ(✿ﾟ▽ﾟ)ノ)

每每看到社區類似的擔憂，對我們都是一種鞭策。作為一個負責任的開源項目，必然不會辜負大家的期待。隨著用戶的增多，肩上的壓力也越來越大，希望大家使用了Element 能真正為項目開發減負提效，這樣我們多加班，大家早下班，想到這，感覺胸前的紅領巾更鮮豔了。

開始體驗吧

有很多方式可以體驗Element Plus for Vue 3.0

• 手動安裝npm install element-plus ，詳見官網安裝指南
• 下載Webpack腳手架直接運行體驗
• 嚐鮮時下最炫酷的Vite打包腳手架
• 通過Vue CLI插件引入

What's Next for Element Plus?

• 一次重大視覺更新
• 2 個全新組件緊張研發中
• 訪問速度更快，功能更強大的官方網站

喜歡Element Plus嗎？來點個Star 支持鼓勵我們一下吧~

感謝大家4 年以來對Element 的關注，是你們的支持讓Element 不斷完善，力爭做到最好。我們也會不忘開源初心，反哺社區，未來將對社區更加開放，非常歡迎熱愛開源的你來和我們一起完善Element Plus —— 贈人玫瑰，手有餘香，開源社區的維護，不僅僅是靠一個團隊，一個公司，我們相信是靠所有熱愛開源，擁有開源精神，熱衷於分享和交流的朋友們。

G2Plot官網| GitHub開源地址https:// github.com/antvis/G2Plo t

G2 是一個基於圖形語法，面向數據分析的統計圖表引擎。 G2Plot 是在G2 基礎上，屏蔽複雜概念的前提下，保留G2 強大圖形能力，封裝出業務上常用的統計圖表庫。

G2Plot是一個基於配置、體驗優雅、面向數據分析的統計圖表庫，幫助開發者以最小成本繪製高質量統計圖表。

G2Plot 最初誕生於阿里經濟體BI 產品真實場景的業務訴求。

動態數據量、數據場景不確定是BI 產品和中台系統業務數據的一個普遍特徵，而這種特徵對統計圖表的功能和體驗提出了巨大的挑戰。如何能夠幫助報表系統和一線前端在復雜數據條件下快速高效地創建統計圖表，同時保證圖表在各種顯示空間和數據狀態下的可讀性和可用性？為解決這兩個痛點問題，AntV 與DeepInsight、QuickBI 和FBI，阿里經濟體多個優秀的數據BI 產品技術團隊聯手打造了G2Plot。

G2Plot 2.0 帶來了什麼？

G2Plot 2.0版本，我們開啟了全新技術架構，全面依賴G2。一圖一做擴展常見的業務圖表，也提供了自定義擴展能力，滿足自定義個性化圖表的訴求。下面讓我們來看下，主要帶來的重要的能力和特性。

開箱即用的統計圖表

2020年AntV的slogan是利業·立業，這也是G2棧今年一直在做的事情，立足業務，盈利業務。我們按照業務上優先級和使用量佔比，排列優先級，優先做了以下圖表：

折線圖、面積圖、柱形圖系列（堆積、分組、區間、百分比、條圖）、餅環圖、雙軸圖、散點圖、雷達圖、詞云圖、直方圖、瀑布圖、子彈圖、儀錶盤、水波圖、漏斗圖、mini 折柱餅、進度環/條圖、熱力圖、旭日圖...

其中上述頭部超過50% 在內部的重型BI 產品、搭建產品中實踐和使用，排除和解決基本的設計問題和技術漏洞。當然還有一些開發階段的圖表，大家可以試用並提出自己的需求，我們會開發階段充分參考大家的意見和建議。

全新啟航的技術架構

新的G2Plot 架構將全面依賴G2，G2Plot 層僅僅是基於G2 強大的圖形、交互、事件、動畫能力，去一圖一做的擴展不同的常見業務圖表。

整體核心架構開發一個圖表最主要的核心工作就是開發Adaptor，所以圖表，無論是常規統計圖表，還是開發擴展的自定義業務圖表，都按照這樣的模式開發，形成統一的開發心智。 **

這樣做將帶來：

1. 降低架構複雜圖，降低開發入門門檻，提升可維護性。
2. 充分利用和發揮G2 能力，保障技術概念上和G2 一模一樣，一次學習，整體技術棧收益，降低用戶使用門檻。
3. 通過一圖一做，來沉澱、打磨G2 的圖形、交互語法能力。

創意無限的開放能力

G2Plot 內置的是業務中使用量佔比超過90% 的常規統計圖表，而對於業務產品來說，定制不可避免，這個時候，用戶將面臨選擇：① 使用G2 去開發② 建議G2Plot 增加圖表，抑或是③ 使用其他圖表庫、或者自研...

而我們作為G2Plot 開發團隊，也陷入一些問題：

1. 這個圖表通用嗎？是不是太跟隨業務了？如何抽象配置項？
2. 開發者基於G2 開發了，能開源給其他需要的用戶使用嗎？

基於這些問題，我們將G2Plot 基於G2 開發圖表的Adaptor 模式直接開放出來，業務同學可以基於這一個模式去使用G2 封裝定製圖表，如果需要給其他業務復用，直接發包，在G2Plot 的模式上去使用。舉個例子：

以上是一個真實的基於G2 按照G2Plot 的模式開發一個QRCode 圖形能力，整體代碼100 行左右。基於這樣的模式，目前具備有以下的社區擴展，可以到如何開發自定義擴展圖表。

隨手查閱的交互文檔

G2 棧基於圖形語法，具備有很強的靈活性，G2 是麵粉，G2Plot 是麵條。而在靈活性的背後，確必然存在很大的學習成本。之前的G2 文檔是被吐槽最多的點。這一次針對G2, G2Plot 的特殊性，我們推出交互式文檔，嘗試去解決文檔問題，降低文檔查找的成本，幫助開發者提效。為完成這一目標，我們主要進行了以下三步改造：

第一步，教程瘦身，在教程部分重點講述相關的可視化概念及其配合用法，以達到“舉一”的作用，而將“反三”交給API文檔，盡量避免訊息重複透出使開發者在API 文檔和教程之間來回橫跳；

第二步，結構化API文檔，從使用視角出發，以調用模塊為單元全量羅列API內容。同時在文檔內還加入了可以執行的代碼區塊，看文檔的同時想試一下效果？ so easy～

第三步， Demo +文檔，除代碼區和預覽區外，將API文檔也放到一起，方便使用者在看demo的同時查閱文檔，避免反复橫跳。同時升級了代碼編輯器，可以進行代碼提示和類型查看。另外我們還有一個隱藏功能，可以選中- 右建- search in document 快速定位到相關描述哦。

匠心延續的體驗打磨

G2Plot 是一個注重細節體驗的通用統計圖表庫，在之前版本中和實際業務中，我們花費了大量精力打磨各個圖表的細節體驗。在v2 版本中，我們把通用的體驗優從業務實現抽取出來，通用化配置化，把大部分體驗優化方案內置到G2 中，讓G2 和G2Plot 的用戶都可以直接配置開啟各個圖表的體驗優化，用戶可以方便地通過配置和選項來開啟默認內置的體驗優化和優化方案。

• 坐標軸標籤優化

你是不是也遇到過在坐標軸數據密集或者動態變化的時候，坐標軸標籤出來重疊遮擋的問題？在實際業務場景中數據可能動態變化，設置固定的旋轉角度並不難一勞永逸的解決問題；因此在v2版本中，我們內置了自動抽樣隱藏( autoHide )、自動旋轉( autoRotate )等內置的佈局方案，用戶可簡單的通過配置開啟，在不同數據情況下動態的解決坐標軸標籤的重疊問題。

• 數據標籤優化

數據標籤是可視化圖標的一個重要組成部分，但在實際業務場景中，實際的業務圖表中的數據標籤卻體驗非常差，經常出現數據標籤和數據標籤之間的重疊遮擋，數據標籤配色造成的可閱讀體驗差等問題。此前，我們在實際業務中實踐了大量的數據標籤優化方案，在v2版本中，我們把比較通用的優化方案抽取內置到G2中，作為數據標籤的可選佈局方案，用戶可以通過layout配置來開啟希望使用的優化方案。在下面範例中:

• interval-hide-overlap: 適用與柱形圖和條形圖系列圖形，開啟後可避免數據標籤之間的遮擋問題
• adjust-color: 適用與所有含有內部數據標籤的圖形，開啟後可自動調整數據標籤文本顏色，提升可閱讀性
• pie-spider: 適用與餅圖，開啟後可適用餅圖數據標籤蜘蛛佈局

更多layout配置和使用可以參照G2Plot 文檔和範例。

還帶來什麼？

Ant Design Charts

Ant Design Charts基於G2Plot，彌補Ant Design組件庫在統計圖表上的缺失，作為Ant Design的官方圖表組件解決方案。在圖表能力上，和G2Plot 保持一致，不修改技術概念，不修改配置結構。不僅降低這個模塊的維護成本，同時降低開發者使用的開發理解成本。

節省400kb, 瘋狂瘦身

包大小是前端底層模塊，非常重要的指標。這次版本，我們將原包大小從1.3 Mb 降低到800 Kb 內，瘋狂減包接近40%。如果業務中只使用G2Plot 部分圖表，通過按需引入打包，將降低到更小。未來我們會繼續在G2 的基礎上進行進一步的精細化拆分，進一步降低包大小。

95%+ 單元測試覆蓋率

代碼質量和穩定性，不論是底層模塊，還是產品業務，對技術同學來說，都是無限追求。為了解決之前版本帶來的穩定性問題，我們在2.0 開始之初，就強制要求有效的單元測試覆蓋率，並且在後續的迭代中，不斷提升覆蓋率要求

目前的CI覆蓋率狀況： 97%+

除此之外，我們近期會開發自動化回歸腳本，在每次發布版本前，回歸網站上的DEMO 範例，進行像素級的自動對比，來決定此次發布是否帶來重大問題，是否符合質量要求。

深思熟慮的圖表配置

在一圖一做，封裝圖表過程中，我們看到很多的圖表，具備相同的數據表達能力，自然在配置上也會體現出類似的感覺。我們在圖表配置API 上，盡量做到統一，讓開發者在熟悉一些圖表之後，對於新圖表，下意識認知上，可以基本知道如何去配置，這也是在解決之前版本中，不同圖表配置項各自獨立不同帶來的問題。包括：

• 顏色、style 配置統一
• 餅環圖、水波圖、儀錶盤、進度環圖中的統計文本類配置統一
• 多圖層圖形配置統一（對於多圖層配置，我們統一定義為: GeometryOptions，統一且方便擴展，如雙軸圖、對稱條形圖中使用多View 圖層，多Geometry 能力來渲染）

實驗室：多圖層圖表

G2Plot 是基於G2，按照圖表分類學來進行一圖一做，降低使用門檻的同時，也限制了底層G2 的自定義能力。為了對圖形語法非常熟悉的同學，我們通過MultiView 多圖層圖表完全透漏出G2 80%+ 的圖形語法配置能力。

諾貝爾獎可視化（G2Plot 多圖層實驗室繪製）

這個可以用來做什麼？

1. 多圖層層疊圖表，例如：嵌套餅圖、折線圖+統計區間...
2. 多維圖
3. 組合圖：餅+柱混合圖

如下圖所示的一些複雜場景都可以使用MultiView Plot 來配置式的繪製。

目前在實驗室階段，具體使用方式請看官網DEMO

升級指南

2.0 版本和之前的版本，在核心架構和概念，有了非常大的轉變，我們深知這樣的break change 會帶來多大的業務升級迭代成本。但是我們還是堅定的要做這個事情，保證不給後續留下業務包袱，保證後續的可持續迭代。

為了降低之前老用戶的升級成本，我們非常用心的寫了CHANGELOG 和升級指南，幫助大家升級到最新的穩定、持續迭代的2.0 版本。

升級指南地址見： https:// g2plot.antv.vision/zh/d ocs/manual/upgrade

最後

非常感謝你的耐心閱讀。帶著我們對業務，對技術架構的理解，我們將G2Plot從1.0升級到2.0，歡迎在GitHub給我們反饋問題，更加歡迎有興趣的同學來參入貢獻。

附

AntV 2020 品牌日的發布詳情

• 利業·立業- AntV與業務的故事
• 技術專文
• G2Plot 2.0全新來襲
• F2Native 1.0新的起點
• G6 4.0圖可視分析如此簡單
• X6 1.0抱歉來晚
• L7 2.3業務為本完善生態
• AVA 1.0你的圖表參謀
• 設計專文
• 2020，貼地飛行的AntV設計

AntV 項目鏈接

歡迎關注我們的GitHub 項目，點亮star 了解我們的實時動態，期待PR：

• AntV官網： https:// antv.vision/
• G2 ： https:// github.com/antvis/g2 G2是一套基於可視化編碼的圖形語法，以數據驅動，具有高度的易用性和擴展性，用戶無需關注各種繁瑣的實現細節，一條語句即可構建出各種各樣的可交互的統計圖表。
• G2Plot： https:// github.com/antvis/g2plo t G2Plot的定位是開箱即用、易於配置、具有良好視覺和交互體驗的通用圖表庫。
• F2 ： https:// github.com/antvis/f2 F2是一個專注於移動，開箱即用的可視化解決方案，完美支持H5環境同時兼容多種環境（node,小程序，weex）。完備的圖形語法理論，滿足各種可視化需求。專業的移動設計指引為你帶來最佳的移動端圖表體驗。
• F2Native ： https:// github.com/antvis/F2Nat ive F__2Native是一個專注於客戶端，開箱即用、高性能的可視化解決方案，完備的圖形語法理論，滿足你的各種需求，專業的移動設計指引為你帶來最佳的移動端圖表體驗。
• G6 ： https:// github.com/antvis/g6 G6是AntV旗下的圖可視化與圖分析引擎， G來自於Graphic、Graph ，意味著我們要基於圖分析技術做圖可視化；6來自於《 六度分隔理論》，表達了我們對關係數據、關係網絡的敬畏和著迷。
• Graphin： https:// github.com/antvis/graph in Graphin是一個基於G6封裝的關係可視分析工具__，簡單，高效，開箱即用，取自Graph Insight，圖的分析洞察。
• X6 ： https:// github.com/antvis/X6 X6是AntV旗下的圖編輯引擎，提供了一系列開箱即用的交互組件和簡單易用的節點定制能力，方便我們快速搭建DAG圖、ER圖、流程圖等應用。
• L7 ： https:// github.com/antvis/l7 L7是一個基於WebGL的開源大規模地理空間數據可視分析開發框架。 L7中的L代表Location，7代表世界七大洲，寓意能為全球位置數據提供可視分析的能力。
• AVA ： https:// github.com/antvis/AVA AVA是為了更簡便的可視分析而生的智能可視化框架。
• G ： https:// github.com/antvis/g G是AntV幾個產品共同的底層2D渲染引擎，高效易用，專注於圖形的渲染、拾取、事件以及動畫機制，給上層G2、F2、G6提供統一的渲染機制。
• ChartCube ： https://chartcube.alipay.com ChartCube是一個可以快速完成圖表製作的在線工具，只需要三步就可以創建出高品質的圖表。

先介紹下大背景，我們是Ant Codespaces 團隊，主要為螞蟻的工程師們提供雲上研發能力。我們對外透出的是一個典型的B/S應用，用戶無需在本地下載任何軟件，在瀏覽器中就能完成標準技術棧場景下的研發工作，於此同時問題隨之而來。

Web應用相比於Native應用存在一個顯著的缺點：鍵盤事件會衝突，現像是部分快捷鍵組合在Web應用中會“失效”，舉幾個例子：如Cmd + W 、 Cmd + N 、 Cmd + T等等組合，這些事件不做額外處理是無法被Web 應用所正常響應的。

究其原因，可以歸於“ Web App還未來得及處理Keyborads Event，Browser已經做出了對應的響應並產生了副作用”，比如當Cmd + W被瀏覽器響應後，其副作用為關閉當前tab頁，頁面都被關閉了，Web App 自然也就被關了。

Ant Codespaces 作為研發上雲的重要組成部分，而快捷鍵又是工具產品提效的重要方式之一，因此在快捷鍵這件事上我們需要給用戶提供不落後於本地IDE 的按鍵組合功能與體驗。

既然我們遇到了這個問題，那麼友商是怎麼做的？

Github Codespaces

Github Codespaces 巧妙避開了這部分衝突的快捷鍵，用戶可以自己到相關配置界面中去設置自己想要的快捷鍵（但此時用戶無法設置成與瀏覽器衝突的組合）

Theia

Theia提供了Alt + W作為代替Cmd + W的默認組合

Coding

Coding 同上，也是避開衝突+ 自主設置

試用了一圈外部產品後，我枯了。不出意外的發現友商們在解決此類問題時採用了一種通用的解決方案：避開與瀏覽器衝突的快捷鍵組合。

這種方式雖然能解決問題，但代價是需要改變本地用戶的使用習慣，功能上是有了，但體驗上產生了差異。

隨後到Theia 老師處取了取經，也沒有發現太好的辦法

快捷鍵背後的心智模型

既然業界已經有了通用的“方案”，為何還要繼續糾結這個問題？

從我切身體驗來看，我在今年6 月份來到黃龍，當我將研發活動從本地VSCode 遷移到Cloud IDE 時，最難受的是：部分高頻快捷鍵操作與我腦海裡的第一反應不一致，典型的如關閉文件Cmd + W ，即便已經過了100多天，我依舊不想用非Cmd + W組合來關閉文件。

同時，糾結這一點的用戶不止我一個，我們也收到了一些來自用戶的反饋，期望能解決高頻快捷鍵的一致性問題。

這是一個很合理的訴求，當我們在macOS上下載一個Native App時，自然而然的會認為Cmd + W是「關閉XX」， Cmd + N是「新建XX」，這是一種約定俗成的guide line。當然軟件開發者們也可以不遵守這個，甚至是反其道行之，那相對應的就會增加用戶使用成本，從而戴上真難用的帽子。

快捷鍵對工具類軟件的重要性

在特定的場景下，如果操作鼠標或是操作鍵盤都能達成某一目的，那麼大概率操作鍵盤會比純操作鼠標速度來的更快。 （當然還有一些場景可能是純鼠標更快，比如macOS 用觸發角鎖屏）

作為工程師，我們可以聯想一些日常研發活動時的一些場景，比如跳行、搜索、關閉/新開文件.... 無論是用Sublime 還是VSCode ，這些功能都可以用鍵盤或是鼠標做到，但很多同學會選擇使用鍵盤來喚醒對應的功能。

甚至很多效率工具的核心能力之一是將鼠標操作轉用鍵盤操作來代替，比如Alfred、Spectacle 等等等等。

同樣我們也可以聯想一下行業外的其他角色是如何工作的。比如照相館老闆使用Photoshop，他們鍵盤上部分按鍵都快包漿了，可想而知他們有多依賴快捷鍵的能力，沒有快捷鍵固然還能繼續工作，但是效率上會降低很多，而時間就是金錢。

因此可以草率的得出一條結論：遵循心智模型的快捷鍵組合能提升軟件使用的效率。

為什麼要用草率這個詞，因為這句話是我自己編的: )

所以我們不但要解決快捷鍵的“功能有無”問題，也要盡可能的解決快捷鍵“體驗一致”問題。

所有衝突的快捷鍵都會失靈嗎？

並不是

從現像上看，大體上可以分為兩類快捷鍵：

1. 能被preventDefault
2. 不能被preventDefault

可以被preventDefault的這部分組合很好解，以Cmd + S舉例，

在一個沒有額外處理鍵盤事件的Web應用裡， Cmd + S會觸發瀏覽器的网页保存，見：

當通過以下代碼取消默認事件後，我們可以愉快的在listener 中加入callback

document.addEventListener("keydown",(e)=>{if(e.keyCode===83&&e.metaKey){e.preventDefault();alert("I AM CMD_S");}});

看看效果：

這背後發生的故事就不在本文展開了，相信各位前端老法師們比我更懂Events

不能被preventDefault 的快捷鍵該如何是好

觀察上述行為後，可以發現當CMD + S未被取消默認事件時，會先執行cb，隨後再是執行默認事件（可以在此同款demo中感受一下）：

當preventDefault 後，自然就變成了：

那麼，把事件CMD + S換為CMD + W會發生什麼？

將上述demo 改寫後試下：

 document.addEventListener("keydown", (e) => { if (e.keyCode === 69 && e.metaKey) { e.preventDefault(); alert("I AM CMD_W"); } });

直接翻車，說明CMD + W類的事件和CMD + S類的事件有著本質差別，我們可以在原有的流程圖上繼續做一個推測，當瀏覽器對這部分優先級更高的快捷鍵做出不可逆的副作用響應時，listener 的cb 即便preventDefault 也將變得無能為力，因為更高優先級的副作用已經產生了：

那！怎！麼！辦！啊！

問題不大，辦法總歸是有的，無非是權衡一下投入和產出。

從流程圖上看這個問題的話，思路上大概是在emit keybords events與browser do sth.之間加點騷東西，一是讓不可逆的副作用不再產生，二是讓listener的cb正常執行。只要能滿足這兩點，這事情基本上就成了，剩下的就看研發成本與實現方式。

有了大致的思路後，繼續尋找實現思路的方式，大概分為三個方向：

1. 寫一個native bridge，用來代理系統級的事件，再通過某種方式與瀏覽器通信（類似Postman Capture requests and cookies的實現方式）
2. 增加Electron 版本的IDE，理論上VSC 的快捷鍵能力都能實現了
3. 通過Chrome Extension 來代理快捷鍵

方式	複雜度	優點	缺點
Native Bridge		1. 系統級能力，想做的能力基本都能做，沒有做不到只有想不到	1. 需要用戶額外安裝native bridge 與chrome extension 2. 需要考慮跨平台2. 複雜度較高
Electron App		1. 跨平台 2. 在現有Web 應用的基礎上追加Electron ，成本比樓上更小	1. 需要用戶額外在本地安裝使用Electron App，與現階段Cloud IDE 的定位與場景不符 2. 開了electron 的口子，後續的系統級API 如果runtime 未提供，則依舊無法避免跨平台研發成本
Chrome Extension		1. 跨平台 2. 開發量小	1. 用戶需要安裝對應的Chrome Extension 2. 能捕獲大部分事件，但仍有一部分事件會逃逸3. 對瀏覽器有約束

我認為工程師的使命是在有限的複雜度中尋找最優解，當梳理完三種思路後，基本就將Chrome Extension作為當下的首選實現方案。

一方面Chrome Extension能解決用戶的幾個強訴求組合（如關閉文件CMD + W ，新建文件CMD + N ，新開Tab CMD + T ），解決這幾個按鍵就基本搞定了絕大部分用戶。那麼還剩下一些Chrome Extension也無法攔到的組合，比如CMD + Q （請不要在此時按這個組合，會錯過文末的彩蛋），熟悉macOS快捷鍵的同學應該都知道，這是強退應用的快捷鍵，理論上它的心智就是強退應用，攔不攔都無所謂了，逃逸就逃逸吧。

另一方面我們的Cloud IDE 不同於其他中後台產品，我們只需要兼容到Chrome@latest，為此方案提供了最佳的宿主環境。

基於Chrome Extension 的快捷鍵衝突解決方案

綜上所述，基本上這個方案的主旋律已經定調了：

1. 在方案足夠輕，複雜度足夠低的前提下，ROI 才足夠高
2. 無需考慮跨平台
3. 允許逃逸一部分不那麼常用的組合

具體思路

用一句話概括這個方案的實現思路：在目標應用的tab 裡觸發鍵盤事件時，屏蔽瀏覽器的原生行為，走web 應用預期的行為。

如何屏蔽？

從這句話中，我們可以看到，“屏蔽瀏覽器的原生行為” 是此方案的大前提，那麼問題來了，Chrome Extension 可以做到麼？
可以

擴展用的很溜的同學應該接觸過這個入口，很多擴展是提供快捷鍵自定義能力的，用於通過某個組合來執行對應的command，經過實測發現，像CMD + N CMD + W等組合可以被擴展快捷鍵override，雖然Chrome 的官方文檔並沒有提到通過擴展快捷鍵override browser 的快捷鍵是一個feature，但至少從眼前的行為來看，這條路子是可行的。

因此最開始的流程圖就變成了：

那麼這麼做會有什麼新的問題麼？

有的

可以看到這個流程圖中缺少了一個環節， browser do sth.沒有了。

有人可能會有疑問：我們確實是想把browser 響應的事件去掉呀，為什麼會有問題呢？

將上圖再擴充一下就清晰了：

從擴充後的流程圖中不難發現，實際上我們仍然需要那部分被override 的browser 行為，因為用戶的瀏覽器除了跑我們的Web 應用之外，還需要滿足其他的日常瀏覽需求，如果只是因為想在Cloud IDE里通過CMD + T打開文件tab，從而失去了Browser原生的快速新建頁籤的能力，那就又繞回了這個問題的起點。

預期是什麼？

預期就像圖中所描述的，當前tab 為我們想要override 的tab 時，broswer 行為不生效，當前tab 為其他頁面時，繼續保留browser 的行為。

可以完美做到麼？

做不到，但是可以假裝做得到

先祭出一張Chrome Extension 的架構圖：

由圖可見，Chrome Extension 有幾個核心的概念：

1. Background
2. Popup
3. Content Scripts
4. Injected Scripts

概念不一一展開介紹了，撿兩個我們用到的概念說一說。

background js為開發者提供了豐富的Chrome API調用能力，常見的如开关页面，跳转tab等基本能力都能通過Chrome API模擬出來，因此可以patch瀏覽器的原生事件。

流程圖再次變化一下：

那還有什麼問題麼？

還有問題

以Cloud IDE關閉文件的組合鍵舉例CMD + OPT + W ，我們雖然通過Chrome Extension攔截了CMD + W ，但是web應用的listener是註冊在CMD + OPT +W上的，也就是說我們光攔事件沒有用，還需要將對應在web 應用中的事件補上，而content js 是tab 級別並且能獲取到對應頁面的上下文的，因此可以通過content js 來patch 應用註冊的事件。

流程圖繼續演進：

為什麼採用這種方式？

一方面我們的Web 應用是一個架構很複雜的應用，不希望因這個方案帶來侵入性的改造，避免衍生出更多的邏輯分支與環境概念。另一方面，它是一種通用的解決思路，不單單是用來解決Cloud IDE 遇到的問題，其他的Web 應用都可以無痕接入類似的方案。

最後看看代碼實現，以CMD + N新建文件舉例：

對於backgound js而言，我們需要模擬新开window行為，這個能力Chrome API已經提供了，即：

chrome.windows.create()

對應的content js，我們需要將web 應用註冊的事件補發，即：

將backgroud 與content 中的patch 組合起來，註冊到擴展對應的快捷鍵中：

看看最終效果

使用方案前

使用方案後

啊！終於可以“關閉”文件了～

最後！

我們是螞蟻研發效能部，致力於為螞蟻和多家金融企業提供核電級的全生命週期研發產品，研發效能部的產品涵蓋了螞蟻的整個研發活動，包含代碼服務（託管、審核、掃描、搜索、構建、內容挖掘）、代碼編輯（Cloud IDE）、CI/CD、測試集成、環境搭建、全鏈路鏈條、配置管理、資源調度，以及基於研發活動完整生命週期的數據產品。加入我們，一起打造螞蟻集團下一代基於雲原生的研發效能平台。

（PS 我們正在嘗試小流量WFH，每周有一天的時間可以不限地點辦公，或許是國內為數不多的在後疫情時期依舊對遠程工作保持高效探索的神秘部門，相信很多工程師們會喜歡這種體驗）

最後的最後！

我是小旋風，一個從未接過單的順風車司機，如果您遠道而來，我可以到機場接您到黃龍，這一切都是免費的，甚至還能倒擼一發冰美。

蕭山-> 黃龍接機熱線熱郵：chaxuan.wh@antgroup.com

接機暗號：你們那兒還招人不。

暗號是什麼不重要，交通方式也不重要，title 也不重要，base 在哪也不重要，重要的是在探索的過程中發現有趣的事遇到志同道合的人。

最後的最後的最後！

附上JD：

1. 資深全棧工程師
2. 代碼平台技術專家
3. 平台型產品專家
4. 雲原生容器專家
5. 高級開發工程師
6. 分佈式計算架構專家
7. 資深IDE研發工程師
8. 代碼智能化工程師
9. 編譯器研發工程師

本文整理自Moment.js官方英文公告https:// momentjs.com/docs/# /-project-status/

Moment.js 宣布停止開發，進入維護狀態。

這是一個大而全的時間日期庫，極大方便了我們在JavaScript 中計算時間和日期，每週下載量超過1200 萬，已成功用於數百萬個項目中。

但是，作為一個誕生於2011 年的元老級明星項目，以現在的眼光來看Moment.js 並非完美無缺，官方總結了兩大問題：

1.可變對象

Moment 對像是可變對象（mutable），簡單點說，任何時間上的加減等計算都改變了其本身。這種設計讓代碼變的十分不可控，而且很容易帶來各種隱蔽且難以調試的bug。以至於我們在每步修改之前，都要先調用.clone克隆一次才能放心操作。

2.包體積過大

因為Momnet.js將全部的功能和所有支持的語言都打到一個包裡，包的大小也是到了280.9 kB這樣一個誇張的數字，而且對於Tree shaking無效。如果要使用時區相關的功能，包體積更是有467.6 kB的大小。簡單點說，我們可能只需要一個.format格式化時間的方法，用戶就需要加載數百kB的庫，這是十分不划算的。

最新版本的Chrome 開發者工具也開始建議用戶更換Moment.js 為同類更小的庫。

現在，Moment.js 停止開發了，那我們接下來該用什麼呢？

官方給了3 種替代方案：

1.不使用庫

對於一些簡單的時間處理需求，其實JavaScript自帶的Date和Intl對象完全可以滿足。強大的Intl對象可以展示不同時區不同語言的時間日期格式，在多數現代瀏覽器上已經有很好的支持。

2. Temporal

也許今後的某一天，我們再也不需要使用任何庫，被看作是未來的全新內置的時間日期方案Temporal 很值得期待。這是一個JS 語言內置的重新設計的時間和日期API，現在可以通過實驗性的polyfill 來嘗試Temporal，但離生產上大規模可用還有很長的路要走。

3.其他替代庫

官方推薦了Luxon，Day.js，date-fns 等更先進設計更優秀的時間日期庫。相比之下可能Day.js 是最值得嘗試的一個。

Day.js

官方推薦語：Day.js 被設計為Moment.js 的極簡替代品，擁有幾乎一樣的API。如果你習慣使用Moment 的API 並希望快速入門，請考慮使用Day.js。

上面說到了官方總結的Moment.js 的兩點設計缺陷，可變對象降低了代碼的維護性，過大的包體積影響了影響了整個項目的加載速度。

而將近3萬Github Star的Day.js的設計理念與這份總結不謀而合。在保持了優秀的API設計不變的同時，引入不可變對象（immutable）減少了開發時所需的心智成本，同時簡化邏輯使整個包體積僅有2 kB大小。

Day.js 是一個輕量的JavaScript 時間日期處理庫，和Moment.js 的API 設計保持完全一樣. 如果你曾經用過Moment.js, 那麼你已經知道如何使用Day.js

Day.js 基本用法如下，相同的API，相同的鍊式操作，熟悉的味道。

dayjs() .startOf('month') .add(1, 'day') .set('year', 2018) .format('YYYY-MM-DD HH:mm:ss');

• 和Moment.js 相同的API 和用法
• 僅2kB 大小的微型庫
• 不可變數據(Immutable)
• 支持鍊式操作(Chainable)
• I18n 國際化
• 支持全球時區轉換

感謝Moment.js前輩的付出，讓我們的開發體驗變的更好，期待接過接力棒的Day.js能讓時間日期處理再也不是難題，也期待未來JavaScript內置的時間日期新方案能讓我們使用Vanilla js 解決一切問題。

Node native addon，過去和現狀

N-API也發布一段時間了，社區中有很多Native addon也慢慢遷移到了N-API，比如bcrypt , sse4_crc32等。 N-API彌補了之前nan最痛的跨V8版本ABI不兼容的問題。

想了解NodeJS native addon相關接口的同學可以看@死月絲卡蕾特大佬的部落格從暴力到NAN再到NAPI——Node.js原生模塊開發方式變遷。

但即使是遷移到了N-API，編寫native addon 也有一些編寫代碼之外的痛點。

分發困難

目前主流的native addon 有以下幾種分發方式:

1. 分發源碼

需要使用的用戶自行安裝node-gyp ， cmake g++等構建工具，在開發階段這些都不是什麼問題，但隨著Docker的普及，在特定的Docker環境中安裝一堆編譯工具鏈實在是很多團隊的噩夢。而且這個問題如果處理不好的話，還會白白增加Docker image的體積(其實這個問題是可以通過構建Docker image之前就在一個專門的Builder image裡面編譯完來解決，但是我在各種公司聊下來鮮有團隊會這樣做)。

2. 只分發JavaScript 代碼，postinstall 下載對應產物

有些native addon 的構建依賴實在是太複雜了，讓普通的Node 開發者在開發階段安裝全套的編譯工具不太現實。還有一種情況是，native addon 本身太複雜了，可能編譯一次需要非常多的時間，庫的作者肯定不希望大家在使用他的庫的時候僅安裝就要花掉半小時吧。

所以還有一種比較流行的方式是通過CI工具，在各個平台(win32/darwin/linux)的CI任務中預編譯native addon，進行分發的時候只分發對應的JavaScript代碼，而預編譯的addon文件通過postinstall腳本從CDN下載下來。比如社區中有一個比較流行的用來幹這個事情的工具： node-pre-gyp 。這個工具會根據使用者的配置自動將CI中編譯出來的native addon上傳到特定的地方，然後在安裝的時候從上傳的地方下載下來。

這種分發方式看起來無懈可擊，但其實有幾個沒辦法繞過去的問題:

• 諸如node-pre-gyp這種工具會在項目裡增加很多運行時無關的依賴。
• 無論上傳到哪個CDN ，都很難兼顧國內/海外用戶。回想起了你卡在postinstall從某個Github release下載文件等1小時最後失敗了的慘痛回憶嗎？誠然在國內搭建對應的binary mirror 可以部分緩解這個問題，但是mirror 不同步/缺失的情況也時有發生。
• 私有網絡不友好。很多公司的CI/CD 機器可能都沒法訪問外網（他們會有配套的私有NPM，沒有的話也沒有討論的意義），更別說從某些CDN 下載native addon。

3. 不同平台的native addon 通過不同的npm package 分發

最近前端很火的新一代構建工具esbuild就採用了這種方式。每一個native addon 對應一個npm package。然後通過postinstall腳本去安裝當前系統對應的native addon package。

還有一種方式是暴露給用戶安裝使用的package將所有的native package作為optionalDependencies ，然後通過package.json中的os與cpu字段，讓npm/yarn/pnpm在安裝的時候自動選擇(其實是不符合系統要求的就安裝失敗了)安裝哪一個native package，比如:

{"name":"@node-rs/bcrypt","version":"0.5.0","os":["linux","win32","darwin"],"cpu":["x64"],"optionalDependencies":{"@node-rs/bcrypt-darwin":"^0.5.0","@node-rs/bcrypt-linux":"^0.5.0","@node-rs/bcrypt-win32":"^0.5.0"}}{"name":"@node-rs/bcrypt-darwin","version":"0.5.0","os":["darwin"],"cpu":["x64"]}{"name":"@node-rs/bcrypt-linux","version":"0.5.0","os":["linux"],"cpu":["x64"]}{"name":"@node-rs/bcrypt-win32","version":"0.5.0","os":["win32"],"cpu":["x64"]}

這種方式是對使用native addon的用戶侵擾最小的分發方式， @ffmpeg-installer/ffmpeg就採用了這種方式。

但是這種方式會對native addon 的作者帶來額外的工作量，包括需要編寫一些管理Release binary 和一堆package 的工具，這些工具一般都非常難以調試（一般會跨好幾個系統與好幾個CPU 架構）。

這些工具需要管理整個addon 在開發-> 本地release version -> CI -> artifacts -> deploy 整個階段的流轉過程。除此之外，還要編寫/調試大量的CI/CD 配置，這些都十分費時費力。

生態和工具鏈

目前大部分的NodeJS addon 基本都使用C/C++ 開發。 C/C++ 生態非常的繁榮，基本上你想做任何事情都能找到對應的C/C++ 庫。但C/C++ 的生態因為缺乏統一的構建工具鏈以及包管理工具，導致這些第三方庫在實際封裝和使用上會遇到一些其它的問題:

• 使用多個不一樣構建工具鏈的庫的時候可能會很難搞定編譯，比如這幾年以來我一直都在嘗試封裝skia 到nodejs binding, 但是skia 的編譯。 。實在是一言難盡的複雜，所以一直都在遇到這樣或者那樣的問題。
• 由於沒有好用的包管理器，很多優質的C/C++ 代碼都是作為一個大型項目的一部分存在的，而不是獨立成一個庫。這種情況下想要使用可能只能以Copy代碼的形式: bcrypt.cc ，這樣對項目後期的升級和維護都帶來了一些問題。

When Rust meets N-API

Rust相信不用我過多介紹(能點進來這篇文章的應該對Rust都有一定的了解了吧)。

用Rust替代C/C++看起來是一個很美好的選擇，Rust有現代化的包管理器: Cargo ，經過這麼多年的發展在生態上尤其是與NodeJS重疊的服務端開發、跨平台CLI工具、跨平台GUI (electron)等領域有了非常多的沉澱。比起C/C++生態， Rust生態的包屬於只要有，都可以直接用的狀態，而C/C++生態中的第三方代碼則屬於肯定有，但不一定能直接用的狀態。這種狀態下，用Rust開發Node addon少了很多選擇，也少了很多選擇的煩惱。

在正式決定開始使用Rust + N-API開發NodeJS addon之前，還有一些問題需要討論:

N-API 的Rust binding

NodeJS 官方為N-API 提供了相應的頭文件，作為開發Node addon 時所需。而Rust沒有辦法直接使用C的頭文件，所以我們需要將node.h暴露的API先封裝成Rust可以使用的Rust binding .

在Rust生態中，有官方維護的bindgen來自動生成頭文件對應的Rust binding ，這個工具非常適合node.h這樣非常純粹的C API頭文件，如果是C++ API則會復雜很多。

但是這樣生成出來的Rust binding一般都是unsafe的並且會充滿底層的指針操作，這顯然不利於我們進一步封裝native addon，也享受不到Safe Rust帶來的種種好處。

在早夭的xray項目中，最早的編輯器架構並非後來的類似LSP的Client/Server架構，而是NodeJS直接調用Rust編寫的addon。所以在早期，xray有一個非常粗糙的Rust N-API實現。

幾年前我將這些代碼從xray項目的Git的歷史中找回來了，並且加以封裝和改進： napi-rs ，將大部分常用的N-API接口封裝成了Safe Rust接口，並為它們編寫了全方位的單元測試，它可以作為使用Rust編寫native addon的重要基石。

選擇分發方式

Rust作為出了名的編譯極緩慢的語言，分發源碼顯然是不現實的，而且也不可能要求使用的開發者全部都安裝Rust全家桶。

通過postinstall下載作為一種比較簡單但是對使用者極不友好的方式，我覺得也不應該繼續提倡使用。

那最終對於使用Rust編寫的NodeJS native addon ，我們最好的選擇就是使用不同平台分別分發addon的形式。

在napi-rs項目中，我封裝了簡單的cli工具，用來幫助使用napi-rs的開發者管理從本地開發到CI發布的全流程。下面我們來用一個簡單而實際的例子介紹一下如何使用Rust和napi-rs開發、測試、發布一個NodeJS native addon。

用Rust能做哪些事情

我們編寫一個native addon，肯定是想要加速一些計算的過程，然而這種加速並不是沒有代價的。

Native code在一些純計算的場景比js快非常多，但是一旦使用N-API與node的js引擎打交道，就會有非常大的開銷(相對計算而言)。

比如在js裡面設置一個對象的屬性會比在native裡面使用N-API設置一個對象的屬性快好幾倍

constobj={}obj.a=1letmutresult=env.create_object()?;result.set_named_property("code",env.create_uint32(1)?)?;Ok(result)

所以在封裝native addon的時候，我們應該盡量避免N-API的調用，不然native邏輯為你減少的運行時間又全部被N-API調用給加回去了。

使用N-API中需要注意的性能點實在是太多了，這裡就不展開來講了，後面有時間了或許會寫一系列文章介紹各種使用場景下如何選擇最優的方式調用N-API來達到更好的性能。

但是有一些N-API的調用其實是必不可少的，比如從參數中的Js值裡面獲取對應的native值，或者把native值轉換成Js值返回:

#[js_function(1)] // -> arguments length fn add_one ( ctx : CallContext ) -> Result < JsNumber > { let input : JsNumber = ctx . get ( 0 ) ? ; // get first argument let input_number : u32 = input . try_into () ? ; // get u32 value from JsNumber, call `napi_get_value_uint32` under the hood ctx . env . create_u32 ( input_number + 1 ) // convert u32 to JsNumber, call `napi_create_uint32` under the hood }

所以一個典型的native addon至少需要兩次N-API調用(即使返回undefined也要調用napi_get_undefined )。在你打算開始編寫一個native addon的時候，要時刻計算native帶來的加速是否能抵消其中的N-API調用的開銷。像上面例子中的add_one方法，肯定是比Js版本要慢非常多的。 Github上有一個項目對比了不同封裝方式中典型的N-API的調用開銷: rust-node-perf 。

這裡近似認為a + b這個操作對於純Js和native代碼來說執行時間近似相等:

| Framework | Relative Exec Time | Effort | | ----------------------------- | ------------------ | -------- | | node.js | 1 | n/a | | wasm-pack (nodejs target) | 1.5386953312994696 | low | | rust-addon | 2.563630295032209 | high | | napi-rs | 3.1991337066589773 | mid | | neon | 13.342197321199631 | mid | | node-bindgen | 13.606728128895583 | low |

可以看到napi-rs比直接使用JavaScript慢了3倍多。

這也是為什麼大家都知道native addon 比純JavaScript 快很多，但很少有人在項目中大規模使用的原因。在N-API的調用開銷和v8引擎已經非常快的前提下，大部分的純計算的場景也不適合使用native addon來替換Js，甚至是你還能看到一些地方提到用JavaScript替換了native模塊之後，性能有了質的提升： https:// github.com/capnproto/no de-capnp#this-implementation-is-slow

再比如我最早用N-API封裝addon的時候有一個失敗的嘗試: @node-rs/simd-json 。我將simd-json封裝成了native addon，希望得到一個比Node自帶的JSON.parse更快的API，但實際測下來native parse的部分快的突破了天際，而將native struct轉變成Js Object中間的N-API call所需要的時間在數量級上遠超parse一個JSON字符串的時間。

已有的一個SIMD json port也有這個問題: simdjson_nodejs#5

那麼到底哪些功能適合用native addon 來完成呢？

• 簡單的輸入輸出但是中間邏輯複雜的計算邏輯，比如直接用到CPU simd指令的@node-rs/crc32 ,或者加密算法@node-rs/bcrypt ,中文分詞@node-rs/jieba 。這些庫的邏輯都有一個共同點：輸入輸出都非常簡單(避免額外的N-API調用)，中間計算邏輯非常複雜。
• 一些需要調用系統級API能力的庫，比如之前提到的SIMD指令，還有類似GPU調用等。

所以下面讓我們到crates.io中找一個簡單的支持SIMD功能庫，將它封裝成node native addon，來演示一下如何快樂的使用Rust + N-API做一些高性能並且實用的工具庫。

@napi-rs/fast-escape

先上鍊接:

在crates.io裡面搜索SIMD ，按全時期下載量排序，找到比較流行的使用了SIMD技術的庫，然後逐個查看。前面2頁的庫要么已經被我封裝過了（逃要么輸入輸出太複雜不適合封裝，要么已經有現成的Node stdlib可以用了，翻到第三頁看到第一個v_htmlescape ，一看就適合用來封裝成addon:

• 用到了SIMD 技術，計算過程可以加速很多
• 輸入輸出簡單，進一個字符串出一個字符串，不會有太多的N-API call來消耗性能

我們從package-template模版項目new一個新項目出來，package-template中已經設置好了各種依賴/CI配置和命令，直接在src/lib.rs中開始寫代碼就行了:

#[macro_use]externcratenapi;#[macro_use]externcratenapi_derive;usenapi::{CallContext,Env,JsString,Module,Result};usev_htmlescape::escape;register_module!(escape,init);fninit(module:&mutModule)->Result<()>{module.create_named_method("escapeHTML",escape_html)?;Ok(())}#[js_function(1)]fnescape_html(ctx:CallContext)->Result<JsString>{letinput=ctx.get::<JsString>(0)?;ctx.env.create_string_from_std(escape(input.as_str()?).to_string())}

這就是一個最小可以使用的的native addon 代碼了，代碼分2 個部分:

1. register_module宏接受2個參數，第一個是module的名字，可以任意命名，這裡命名為escape ，第二個參數接受一個rust function ，它有唯一一個參數： Module ，這個參數代表了NodeJS中的module對象，我們可以通過設置module.exports對象設置需要導出的東西，而如果要導出函數則有一個helper方法: module.create_named_method來直接導出。
2. #[js_function(1)]宏用來定義一個JsFunction ，被定義的Rust function有唯一一個CallContext參數，我們從JavaScript代碼中傳入的參數可以通過ctx::get(n)方法獲取。 #[js_function()]宏裡面的參數定義了這個函數有幾個參數，當ctx.get傳入的值大於實際傳入的參數個數的時候會拋一個Js異常。

在運行yarn build之後，我們可以在js裡面這樣調用這裡的escape_html函數:

const{escapeHTML}=require('./index')console.log(escapeHTML('<div>1</div>'))// <div>1</div>

這裡的yarn build其實做了很多事情:

• 運行cargo build ，將lib.rs編譯成了動態鏈接庫，放在了./target/release/escape.[dll|so|dylib]
• 運行napi build --release --platform ，這個命令將上一步的(lib)escape.[dll|so|dylib]從target/release目錄拷貝到當前目錄下，並重命名為escape.[darwin|win32|linux].node

然後index.js中調用@node-rs/helper裡面的loadBinding方法，自動從正確的地方加載native addon:

const { loadBinding } = require ( '@node-rs/helper' ) /** * __dirname means load native addon from current dir * 'escape' means native addon name is `escape` * the first arguments was decided by `napi.name` field in `package.json` * the second arguments was decided by `name` field in `package.json` * loadBinding helper will load `escape.[PLATFORM].node` from `__dirname` first * If failed to load addon, it will fallback to load from `@napi-rs/escape-[PLATFORM]` */ module . exports = loadBinding ( __dirname , 'escape' , '@napi-rs/escape' )

這樣我們就能愉快的通過index.js使用封裝好的escapeHTML函數了。

那麼這個封裝能比純JavaScript版本快多少呢？寫一個簡單的benchmark測試一下: bench 。這裡選取了大神sindresorhus的escape-goat作為性能比較的基準:

napi x 799 ops/sec ±0.38% ( 93 runs sampled ) javascript x 586 ops/sec ±1.40% ( 81 runs sampled ) Escape html benchmark # Large input bench suite: Fastest is napi napi x 2,158,169 ops/sec ±0.59% ( 93 runs sampled ) javascript x 1,951,484 ops/sec ±0.31% ( 92 runs sampled ) Escape html benchmark # Small input bench suite: Fastest is napi

我們測試兩個場景的性能: 小規模輸入和大規模輸入。小規模輸入是一行字符串: <div>{props.getNumber()}</div>大規模輸入是一個1610行的HTML，可以看到不同輸入規模下我們的native addon性能都要優於純JavaScript版本。

經驗告訴我，輸入如果是Buffer ，性能會更優一些(N-API的JsBuffer相關API調用開銷要明顯小於字符串API)，所以我們再加一個接受Buffer的API:

...module.create_named_method("escapeHTMLBuf",escape_html_buf)?;#[js_function(1)]fnescape_html_buf(ctx:CallContext)->Result<JsString>{letinput=ctx.get::<JsBuffer>(0)?;letinput_buf:&[u8]=&input;ctx.env.create_string_from_std(escape(unsafe{str::from_utf8_unchecked(input_buf)}).to_string())}

再來測試一下性能，運行yarn bench ：

napi x 799 ops/sec ±0.38% ( 93 runs sampled ) napi#buff x 980 ops/sec ±1.39% ( 92 runs sampled ) javascript x 586 ops/sec ±1.40% ( 81 runs sampled ) Escape html benchmark # Large input bench suite: Fastest is napi#buff napi x 2,158,169 ops/sec ±0.59% ( 93 runs sampled ) napi#buff x 2,990,077 ops/sec ±0.73% ( 93 runs sampled ) javascript x 1,951,484 ops/sec ±0.31% ( 92 runs sampled ) Escape html benchmark # Small input bench suite: Fastest is napi#buff

果然， Buffer風格的API性能更好一些。

而一般高強度的計算任務，我們一般都希望把它spawn到另一個線程，以免阻塞主線程的執行。 （ escape這個例子可能不太合適，因為這裡的計算開銷還是挺小的)。使用napi-rs也可以比較輕鬆的完成這個任務:

module.create_named_method("asyncEscapeHTMLBuf",async_escape_html_buf)?;structEscapeTask<'env>(&'env[u8]);impl<'env>TaskforEscapeTask<'env>{typeOutput=String;typeJsValue=JsString;fncompute(&mutself)->Result<Self::Output>{Ok(escape(unsafe{str::from_utf8_unchecked(self.0)}).to_string())}fnresolve(&self,env:&mutEnv,output:Self::Output)->Result<Self::JsValue>{env.create_string_from_std(output)}}#[js_function(1)]fnasync_escape_html_buf(ctx:CallContext)->Result<JsObject>{letinput=ctx.get::<JsBuffer>(0)?;lettask=EscapeTask(input.data);ctx.env.spawn(task)}

在上面的代碼中，我們定義了一個EscapeTask結構，然後實現napi中的Task trait ， Task trait需要實現4個部分:

• type Output在libuv線程池中計算返回的值，一般是Rust值
• type JsValue計算完成後Promise resolve的值
• compute方法，定義了在libuv線程池中的計算邏輯
• resolve方法，將計算完畢的Output轉化成Js值，最後被Promise resolve

而在新定義的js_function async_escape_html_buf中，我們只需要構造剛才的EscapeTask ，然後使用spawn方法就能得到一個Promise對象:

lettask=EscapeTask(input.data);ctx.env.spawn(task)

在js中，我們可以這樣使用:

const{asyncEscapeHTMLBuf}=require('./index')asyncEscapeHTMLBuf(Buffer.from('<div>1</div>')).then((escaped)=>console.log(escaped))// <div>1</div>

到這里為止，我們的一個簡單的native addon 就編寫完畢了，而發布這個包，只需要以下幾步:

• commit 剛才變更的代碼
• 運行npm version [patch | minor | major | ...]命令
• git push --follow-tags

倉庫中配置好的Github actions會自動幫你將native模塊分別通過不同的npm包發布Build log

當然如果你真的要做這些事情，有幾個前置修改需要做:

• 全局替換pacakge-tempalte到你的包名(後面會提供CLI來幫你做這件事情)
• 修改.github/workflows/CI.yml中Upload artifact步驟中的package-template ，新的值需要和package.json中的napi.name字段保持一致(後面也會提供CLI來幫你做這件事)
• 如果你的包名不在@scope下，需要保證package-name-darwin , package-name-win32 , package-name-linux , package-name-linux-musl這幾個包你都有發布權限

至此，一個簡單的native addon就封裝完成了，大家可以使用yarn add @napi-rs/escape來試玩一下剛才封裝的這個native addon。

END

napi-rs從誕生到現在，已經形成了一定規模的生態了， node-rs倉庫集中封裝了一些常見的native addon (deno_lint目前還在非常初始的階段)， swc-node已經有很多項目用起來了，而由於swc-node的成功， swc的作者最近也從neon遷移到了napi-rs上: https:// github.com/swc-project/ swc/pull/1009

這次migrate讓swc的API性能快了2倍swc#852 (這也是目前napi-rs對比neon的優勢之一)，並且在CI和發布管理上節省了很多代碼量。

最後歡迎大家試用napi-rs ，包括strapi在內的很多大型NodeJS項目(包括字節跳動內部的NodeJS基礎庫，支撐的總QPS可能超過10w)已經用上napi-rs封裝的庫了，所以它在代碼上已經production ready 了。

後面我會持續建設它的文檔和周邊工具鏈，讓它更好用更易用，所以大家也不要忘了給個Star或者Sponsor !

招聘

我所在的團隊是字節跳動IES 前端架構，基礎體驗方向。 IES 中文名稱是互娛研發，也就是抖音、tiktok 等超大體量產品所在的部門。我們團隊計劃在前端、hybrid 、flutter、自研引擎、小程序、NodeJS 等多個方面做很多關於性能、體驗、監控相關的事情。

最近我們有計劃通過swc和N-API做一些源碼掃描的工具，預計可以比基於acorn的掃描邏輯快10~100倍。後面的規劃中，也會有大量涉及到Rust與前端/NodeJS結合的領域可以去開拓，歡迎大家踴躍聯繫我給我投簡歷！ ！ ！

我的個人微信在: https:// github.com/Brooooooklyn

你也可以直接通過我的內推鏈接投遞: https:// job.toutiao.com/s/JSea1 oG

也可以發郵件到我的郵箱投遞: lynweklm@gmail.com

就剛才，HR小姐姐Lark小窗我：

寸志同學～～我來求助，我們現在上海前端校招進展特別緩慢，能不能……

我有點意外，我們

字節跳動廣告系統團隊成立於2014年，依托今日頭條的海量數據，專注於為全國客戶提供最佳的商業推廣方式與方案，並不斷努力改善用戶的產品體驗，其開發的廣告系統支撐著頭條系所有產品的商業化變現。到目前為止，廣告系統團隊已經積聚了上百名優秀的研發人才，打造出了海內外領先的訊息流廣告系統，每天支撐著公司數億的穩定收入。連續三年，收入以每年3倍速度增長，前景非常廣闊！

怎麼出現招聘進展緩慢的情況？ ？ ？

所以，各大高校的童鞋們，各路大佬們，我必須再強調一下我們部門的優勢，我喜歡這裡，推薦大家來的原因：

• 為什麼選擇廣告行業？

（1）廣告變現對於很多互聯網公司來說是非常重要的變現方式，屬於核心領域且發展持久，是全世界互聯網公司最主流的收入來源，也成為頂尖人才的匯聚之地。前沿技術首先應用於廣告行業，使其成為一個高投入高回報的領域。在這裡你可以獲得廣闊的成長空間，大牛的輔導，實踐應用科技行業的各類最新技術。

（2）廣告業務相比C端業務具有更高的業務壁壘，可以更好的積累自己的業務方向的競爭優勢。後續職業生涯的發展，走技術專家路線能走出成績走出深度的畢竟是少數，那麼自己的競爭力如何構建？深入某個具有足夠深度和壁壘的業務方向業務是個可行的方案。大流量(億級)，高並發，複雜系統架構設計，智能算法設計，複雜廣告場景等，都可以施展技術提供用武之地。

• 為什麼要選擇來頭條做廣告？

（1）字節跳動是首創訊息流廣告的公司，擁有著完備的廣告系統產業鏈並在今日頭條，抖音，西瓜視頻和國際化產品上廣泛應用，創造多個行業最佳。

（2）頭條廣告系統匯聚大量行業top人才，在這裡，有著完備的廣告系統技術產業鏈，最複雜的廣告場景，最大的數據量級。在和優秀的人做有挑戰的事的同時，提升自己的技術深度與廣度。

• 對個人技術的提高？

技術的深度和廣度，是由業務複雜性和業務的發展速度決定的。我們的廣告後台是一個從十億廣告規模到千億廣告規模快速發展的系統，這個過程和技術，如同造火箭一般。對技術的要求和提升具體來說有這些方面：

1.面對複雜的業務系統，在快速迭代的場景下，穩定性可靠性要求極高，這裡面的技術都是很深的，積累下來一定是專家級水平；

2.我們後台語言主要使用號稱工程最友好的語言go，用過的人都說好；

3.廣告系統是敏捷開發模式，快速迭代，CI CD，基本是業界最先進的開發發布模式；

4.廣告後台也有高並發，比如打包服務，廣告庫數據服務，高並發的在線服務，近在線的數據服務，都很有挑戰，有極大的發揮空間。

我打賭，你來字節跳動上班，一定會像我一樣地開心：

自由平等的工作環境

我們在全球180多個城市設有office，這次秋招，我們在北京、上海、深圳、杭州、成都、廣州、武漢、南京、廈門、無錫等多個城市都有許多崗位可以投遞！

靈活的辦公時間，上班不打卡

上下班無需打卡，效率為先，你的工作時間由你來安排

輕鬆的辦公環境，工位不設限

開放式工位，獨立討論區，靈感碰撞不受空間束縛

平等的工作氛圍，溝通無“大小”

大家互相之間以“同學”相稱，不講title，坦誠的溝通風格幫你更自在地工作

鼓勵多元，擁抱文化多樣性

為不同性格、年齡、文化和職業背景的同學，創造多元兼容的環境

行吧，餐廳美食、健身游泳……的圖我就不發了，先觀摩一下我們的新辦公室吧！

不廢話了，咱們進入正題，想做前端的童鞋，一定要掃碼給我們投遞簡歷哦！

http:// qr21.cn/AWxJte (二維碼自動識別)

除了前端，還挺有各種火熱校招職位等待你的投遞，掃碼查看

https:// job.toutiao.com/campus/ m/invite?referral_code=GXQKUDG (二維碼自動識別)

也歡迎加我微信island205諮詢各種校招問題，也可以把簡歷通過微信或者郵箱cunzhi@bytedance.com發給我，幫你內推！

導語：前端智能化，就是通過AI/CV技術，使前端工具鏈具備理解能力，進而輔助開發提升研發效率，比如實現基於設計稿智能佈局和組件智能識別等。

本文要介紹的是前端智能化的一類實踐：通過計算機視覺和機器學習實現自動提取圖片中的UI樣式的能力。

具體效果如上圖，當用戶框選圖片中包含組件的區域，算法能準確定位組件位置，並有效識別組件的UI樣式。

樣式提取方案

本文基於OpenCV -Python實現圖像的樣式檢測，主要分為三步： 1.從圖片檢測並分離組件區域； 2.基於組件區域進行形狀檢測； 3.對符合規則形狀的組件進行樣式計算。

1. 從圖片分離組件區域

組件區域分離主要是通過圖像分割算法，識別組件區域（前景）和背景區域，本文主要從用戶框選操作上考慮，採用了可交互可迭代的Grab Cut算法。 Grab cut算法允許用戶框選作為前景輸入，利用混合高斯模型GMM，找到前景和背景的最佳分割路徑，具體可參考文章： 圖像分割——Grab Cut算法

如上圖，通過調用OpenCV的cv2.grabCut方法時，我們將組件前景框(x, y, width, height)作為方法入參，識別出的組件像素被存儲在mask遮罩。

代碼實現

defextract(img,rect):"""輸入框選區，輸出GrabCut遮罩"""x,y,w,h=rectroi_img=img[y:y+h,x:x+h]mask=np.zeros(roi_img.shape[:2],np.uint8)#初始化遮罩層bgdModel=np.zeros((1,65),np.float64)fgdModel=np.zeros((1,65),np.float64)#函數的返回值是更新的mask, bgdModel, fgdModelcv2.grabCut(img,mask,rect,bgdModel,fgdModel,4,cv2.GC_INIT_WITH_RECT)mask=np.where((mask==2)|(mask==0),0,255).astype("uint8")returnmask

通過這一步，我們從背景分離出目標遮罩，它是包含了N個組件區域的二值圖。

2. 組件的形狀檢測

接下來，我們需要通過形狀檢測從遮罩區篩選出多個可用樣式還原的組件，比如矩形、帶圓角矩形和圓形。具體分為兩步：1) 提取組件外輪廓2) 霍夫檢測識別輪廓形狀

2.1 外輪廓提取

第一步是通過前面圖割遮罩進行外輪廓提取，排除組件內部其它線條帶來的影響。輪廓提取主要使用Suzuki85輪廓跟踪算法，該算法基於二值圖像拓補，能確定連通域的包含關係。

這裡採用的是Canny邊緣檢測來得到圖像邊緣圖，再通過Suzuki85算法cv2.findContours從圖像邊緣提取外輪廓。

代碼實現

defseparate(img,th=5):"""輸入組件區域遮罩，輸出多個組件外輪廓列表"""new_img=cv2.Canny(img,50,150)new_img=image_morphology(new_img)cnts,_=cv2.findContours(new_img,cv2.RETR_EXTERNAL,cv2.CHAIN_APPROX_NONE)data=[]forcntincnts:x,y,w,h=cv2.boundingRect(cnt)if(w<th)|(h<th):"""剔除噪點"""continuedata.append((cnt,x,y,w,h))returndata

這一步我們得到了圖像中所有組件的外輪廓以及具體的坐標x,y和寬高w,h 。

2.2 形狀檢測

第二步則是對每個組件外輪廓進行圖形類型識別，其中除了矩形、圓形是樣式可還原圖形，其它都不可還原，我們的目標就是檢測出這兩種基本圖形。

這裡運用霍夫變換(Hough Transform)方法，它是一種識別幾何形狀的算法，主要採用投票機制從多個特徵點擬合圖像中線段和曲線的參數方程。

2.2.1 矩形檢測

檢測矩形主要分兩步：1）通過霍夫直線變換檢測外輪廓的邊；2）根據邊（線段）集合判斷是否符合矩形特徵。

OpenCV提供線段檢測方法cv2.HoughLinesP ，輸入外輪廓，輸出檢測到的線段，具體代碼實現如下：

# 检测矩形defdetectRectangle(img,width,height):minLineLength=10maxLineGap=4# 霍夫直线变换输出检测到的线段数组lines=cv2.HoughLinesP(img,1,np.pi/180,100,minLineLength,maxLineGap)segments=lines.reshape(lines.shape[0],4)# 将线段数组进行进一步检测，判断是否命中矩形规则returnjudgeRectangle(segments,width,height)

取到線段集合後，我們再判斷是否滿足矩形邊的特徵： 1. 存在兩條水平方向線段和兩條垂直方向線段1. 上線段到下線段距離≈組件高度，左線段到右線段距離≈組件寬度

代碼實現

"""判斷是否為矩形"""defjudgeRectangle(lines,width,height,x=0,y=0):th=2horizontal_segments=lines[np.where(abs(lines[:,1]-lines[:,3])<th)]vertical_segments=lines[np.where(abs(lines[:,0]-lines[:,2])<th)]isRect=Falseh=w=Noneifhorizontal_segments.size!=0:horizontal_centers=(horizontal_segments[:,1]/2+horizontal_segments[:,3]/2)top=horizontal_centers.min()bottom=horizontal_centers.max()h=bottom-topifabs(h-height)>th:returnFalse,None,None#如果兩線間隔非圖形高度，則不規則圖片isRect=Trueh=int(round(h))ifvertical_segments.size!=0:vertical_centers=vertical_segments[:,0]/2+vertical_segments[:,2]/2left=vertical_centers.min()right=vertical_centers.max()w=right-leftifabs(w-width)>th:returnFalse,None,NoneisRect=Truew=int(round(w))returnisRect,w,h

2.2.2 圓形檢測

圓形檢測可使用霍夫圓環檢測法，對應OpenCV的HoughCircles方法，輸入二值圖，如果存在圓形，則返回圓形和半徑。代碼實現如下：

#檢測圓形defdetectCircle(img,width,height):circles=cv2.HoughCircles(img,cv2.HOUGH_GRADIENT,1,20,param1=30,param2=15,minRadius=10,maxRadius=0)ifcirclesisNone:returnFalse[radius,rx,ry]=circles[0]returnjudgeCircle(radius,rx,ry,width,height)defjudgeCircle(r,rx,ry,w,h,x=0,y=0,th=4):return((abs(w-h)<th)&(abs(r-w/2)<th)&(abs(rx-x-w/2)<th)&(abs(ry-y-h/2)<th))

通過這一步，我們篩選出屬於矩形或圓形的組件，以及組件的寬高、圓形以及對應的半徑，下一步，我們將針對這兩種基本圖形進行樣式檢測。

3. 組件的樣式計算

組件樣式計算主要對邊框、圓角、背景三種常用樣式分別計算。

3.1 圓角計算

在樣式定義中，圓角被限制在矩形的四個頂點處，圓角弧度取決於它的半徑，因此圓角計算的主要目標就是識別圓角的半徑。根據圓角的4個方位，我們將組件區域劃分為4塊進行逐塊分析。一開始，我們採用直接對圓弧點進行圓的曲線擬合，但由於圓角點的數據過於集中，擬合圓的誤差很大，如圖：

我們知道，圓角經過十字對稱後能構造出一個圓形，因此，只要我們確定了“圓角”的候選區域，構造十字軸對稱圖，就可以根據圓形擬合準確判斷是否為滿足圓角特徵了。具體步驟如下：

1. 假設存在圓角，用面積推算圓角半徑，確定“候選區域”
2. 構造“候選區域”水平-豎直軸對稱圖形，對圖形進行霍夫圓環檢測，驗證是否為圓角

3.1.1 圓角半徑推算

我們假設存在圓角，半徑為R，如下圖黃色色塊區域，是組件框與填充組件的差集。

同時，黃色塊也是以邊長R為正方形與半徑R為1/4圓的差集，即s = R² - π × R² × ¼ ，於是聯立方程，可求解圓角半徑R，代碼如下：

這一步我們根據面積差集計算出半徑R，通過R，我們裁剪出“候選區域”，進行下一步驗證。

3.1.2 候選區域驗證

這一步先構造軸對稱圖像，主要是在水平和豎直方向依次做翻轉+拼接操作。

如圖，得到對稱圖形後，我們沿用上文的霍夫圓環變換來檢測是否存在圓形，如果存在，則圓角也存在，反之亦然。

代碼實現

#推算可能的圓角半徑defgetCornerRadius(img):cornerRadius=0corner_mask_size=img[img[:,:,3]!=1].size#ifcorner_mask_size>=0:cornerRadius=round(math.sqrt((corner_mask_size/3)/(1-np.pi/4)))returncornerRadius#驗證候選區域是否為圓角，以左上圓角為例defvertifyCorner(img,cornerRadius):cornerArea=img[:cornerRadius,:cornerRadius]#裁剪出候選區域binary_image=np.zeros(cornerArea.shape[0:2],dtype=np.uint8)#構造二值圖binary_image[cornerArea[:,:,3]!=0]=255horizontal=cv2.flip(img,1,dst=None)#水平鏡像img=cv2.hconcat([img,horizontal])#水平拼接vertical=cv2.flip(img,0,dst=None)#垂直鏡像img=cv2.vconcat([img,vertical])#垂直拼接img=cv2.copyMakeBorder(img,5,5,5,5,cv2.BORDER_CONSTANT,value=[0])circles=cv2.HoughCircles(img,cv2.HOUGH_GRADIENT,1,20)ifcirclesisNone:returnFalseelse:returnTrue

3.2 邊框計算

對於邊框的計算，我們同樣是先確定邊框的描述特徵：A. 邊框內的顏色連續與相近；B. 外輪廓和內輪廓是形狀相似的。基於這個特徵，我制定了以下步驟：

1. 色塊分離：對圖像基於顏色聚類，相近色區聚類同一色塊
2. 內外輪廓相似度計算：遍歷不同色塊，提取每個色塊內外輪廓，併計算其相似度

3.2.1 色塊分離

邊框具有顏色相近的特徵，我們通過聚類算法對目標圖像讓顏色相近的區域歸類，這裡採用k-means算法聚類，聚類特徵基於圖像的HSV色彩空間。

代碼實現

"""k-means聚類"""defimage_kmeansSegement(img,k=6):#將圖片從RGB空間轉為HSVimg=cv2.cvtColor(img,cv2.COLOR_BGR2HSV)data=img.reshape((-1,3))data=np.float32(data)# MAX_ITER最大迭代次數，EPS最高精度criteria=(cv2.TERM_CRITERIA_EPS+cv2.TERM_CRITERIA_MAX_ITER,10,1.0)num_clusters=kret,label,center=cv2.kmeans(data,num_clusters,None,criteria,num_clusters,cv2.KMEANS_RANDOM_CENTERS)center=cv2.cvtColor(np.array([center],dtype=np.uint8),cv2.COLOR_HSV2BGR)[0]labels=label.flatten()returnlabels,center

3.2.2 內外輪廓相似度計算

這一步是遍歷k個候選色塊，對色塊分別進行外輪廓和內輪廓提取，再判斷色塊內外輪廓是否形狀相似。其中外輪廓的提取直接復用前面的cv2.findContours方法，輸入色塊，輸出外輪廓填充圖。內輪廓則需要分兩步，首先對外輪廓填充圖與色塊填充圖進行差運算得到“內域”，再對內域進行cv2.findContours 。

拿到內外輪廓後，我使用感知哈希pHash +漢明距離進行相似度計算，它主要通過顏色低採樣將圖片統一縮小到32×32尺寸並輸出圖像簽名，很好地解決相似形狀中大小不一致帶來的誤差。

代碼實現

"""驗證每個色塊是否存在邊框特徵B"""defborderExtract(labels,center,img_filled):#遍歷k-means分離的k個色塊foriinrange(labels.max()):area=np.zeros((labels.size),dtype=np.uint8)area[labels==i]=255area=area.reshape(img_filled.shape)#獲取當前色塊外輪廓，用白色填充outter_filled,*_=image_contours(area)#獲取當前色塊內輪廓，用白色填充result=outter_filled-arearesult[result<0]=0inner_filled,*_=image_contours(result)#判斷外輪廓和內輪廓是否相似ifisSimilar(outter_filled,inner_filled)&isSimilar(img_filled,filled1):s1=np.where(filled1>0)[0].sizes2=np.where(filled2>0)[0].sizescale=(1.0-math.sqrt(s2/s1))*0.5_drawBorder(filled1-filled2,center[i])returnscale,center[i],filled2returnNone"""使用pHash算法計算輪廓之間相似度"""defisSimilar(img1,img2,th=0.8):HASH1=PHash.pHash(img1)HASH2=PHash.pHash(img2)distance,score=PHash.hammingDist(HASH1,HASH2)print(score)returnscore>th

總結

本文通過OpenCV系列算法分別實現簡單組件區域的分離和样式的檢測，對於組件的區域檢測，目前是通過手工框選的手段確定組件區域，如果要完全自動化實現Pixels to Code，還需要藉助深度卷積網絡進行組件檢測與識別。

本人將於9月5號參與騰訊live開發者大會，屆時將介紹更多前端智能化實踐內容，歡迎有興趣童鞋前來觀摩

更多文章歡迎關注

相關資料

最全綜述|圖像分割算法： https:// zhuanlan.zhihu.com/p/70 758906

pHash圖像相似度比較算法彙總： https:// blog.csdn.net/mago2015/ article/details/81137089

機器學習算法實踐——K-Means算法與圖像分割： https:// blog.csdn.net/google198 90102/article/details/52911835

霍夫變換： https:// en.wikipedia.org/wiki/H ough_transform

Suzuki85輪廓跟踪算法： https:// blog.csdn.net/yiqiudrea m/article/details/76864722

前言

我們都知道，目前傳統的SPA 網頁在完成腳本加載後，通常還需要進行接口請求，拿到遠端數據後才能進行完整地內容呈現

而在接口請求的過程中，為了過渡無數據的空白場景，並提示用戶“數據請求中”，常用的方法為做一個loading 動畫效果

而在用戶胃口越來越刁的今天，一個簡單的loading 效果已經不太能安撫用戶了，而骨架屏就是一種安撫用戶的進階方案

最終成品鏈接（懶人用）： auto-skeleton-plugin

什麼是骨架屏？

簡單來說，骨架屏就是在還未產生可閱讀內容時，先將網頁的大致結構框架呈現給用戶，以達到安撫用戶等待過程中的不耐煩心理、提升用戶存留的效果

骨架屏的實現，通常有兩種方式

1. 手動書寫骨架
2. 自動生成骨架

手動寫骨架的方式，好處是可以做出高定制性的骨架效果，缺點是開發成本大，效率低，但本文不對此方式進行展開

那麼如何實現自動骨架屏的效果呢？一個簡單的方式是：將已有內容的樣式進行調整，生成對應的骨架效果，例如以下代碼，可以將所有文字內容，變成骨架條塊

functiongenerateSkeleton(){//文字節點;[...document.querySelectorAll('*')].filter((node)=>!['script','style','html','body','head','title'].includes(node.tagName.toLowerCase())).map((node)=>[...node.childNodes].filter((node)=>nodeinstanceofText)).flat(Infinity).forEach((node)=>{letspan=document.createElement('span')node.parentNode.insertBefore(span,node)span.appendChild(node)span.style=`background: #f2f2f2;color: transparent !important;`})}

這樣，只要我們完善不同內容如圖片、圖標等元素的骨架化過程，就可以得到一個相對可用的內容骨架化效果了

自動骨架化的好處是，生成骨架的效率高，開發成本很低，但缺點是定制性相對較差，需要根據已有內容來確定骨架效果

但這有一個問題，我們期望是在應用剛打開時，還未請求數據前就呈現骨架，目前顯然是做不到的

而我們可以藉助“預渲染”來實現期望的效果

什麼是預渲染？

預渲染類似服務端渲染，它的過程大概是這樣的：在應用完成打包後，立刻啟動一個headless瀏覽器進行頁面訪問，再將訪問的結果輸出成html文件的渲染過程

通俗地說就是：打包完後本地先訪問看一看，看到啥就“截個屏”存起來，然後輸出一個html 文件，覆蓋原本構建生成的index.html

這樣，用戶訪問打包好的index.html 時，看到的就是一個有內容的網頁

那麼，借助預渲染，我們可以將上述自動骨架屏的過程，放在headless瀏覽器加載出網頁內容後，具備內容後再將內容骨架化，再輸出成html，就可以實現用戶訪問時，還未請求數據前，先呈現骨架的效果

自動骨架屏的過程實現

我們可以參考一個常用的預渲染的webpack插件prerender-spa-plugin來實現這個過程

查閱源碼可知，這個插件並未實現核心渲染過程，其實只是將prerenderer包裝成了webpack插件的形式，並承擔了將最終結果輸出成html產物文件的功能

關鍵源碼： https:// github.com/chrisvfritz/ prerender-spa-plugin/blob/master/es6/index.js#L65-L70

...constPrerenderer=require('@prerenderer/prerenderer')...functionPrerenderSPAPlugin(...args){...constafterEmit=(compilation,done)=>{constPrerendererInstance=newPrerenderer(this._options)PrerendererInstance.initialize().then(()=>{returnPrerendererInstance.renderRoutes(this._options.routes||[])})...}...}...module.exports=PrerenderSPAPlugin

prerenderer承擔的則是使用headless瀏覽器訪問網頁，並輸出訪問結果的功能，其官方內置了兩種可選的headless瀏覽器： puppeteer和jsdom

由於puppeteer需要下載的內容較大，我們考慮使用較輕量的jsdom來完成這個效果

在翻閱了部分renderer-jsdom的源碼後，可以找到headless瀏覽器採集網頁內容的部分

關鍵源碼： https:// github.com/JoshTheDerf/ prerenderer/blob/master/renderers/renderer-jsdom/es6/renderer.js#L25-L38

我們只需要在採集網頁內容前，對內容進行骨架化，就可以得到期望的效果

constJSDOM=require('jsdom/lib/old-api.js').jsdom...constgetPageContents=function(window,options,originalRoute){...returnnewPromise((resolve,reject)=>{...functioncaptureDocument(){//此處可在輸出html結果前，先對網頁內容進行骨架化// generateSkeleton就是上邊咱們整理出來的dom操作實現自動骨架化過程generateSkeleton(window)constresult={...html:serializeDocument(window.document)}...returnresult}...}...}classJSDOMRenderer{...asyncrenderRoutes(routes,Prerenderer){...constresults=Promise.all(routes.map(route=>limiter(()=>{returnnewPromise((resolve,reject)=>{JSDOM.env({url:`http://127.0.0.1:${rootOptions.server.port}${route}`,...})}).then(window=>{returngetPageContents(window,this._rendererOptions,route)})})))...returnresults}...}module.exports=JSDOMRenderer

至此，簡易自動骨架屏效果的方案已經敘述完成，整個過程，需要我們自己動手的主要是骨架化過程的部分，其餘之處，都可通過參考已有過程實現來完成，那麼具體過程實現，此處就不再繼續展開了，動手能力強的小伙伴，大概可以自己一把梭出來

結尾

預渲染方案待展開的功能還是有不少的，例如

1. 如何內聯樣式？ （這條比較容易做到，借助jsdom 自身的resourceLoader 足矣）
2. 如何保留關鍵樣式，去除無用樣式？ （有一定難度，可參考uncss ，配合postcss實現）
3. 預渲染性能是否充足，能否用來做SSR? （jsdom渲染速度較快，此處進行了實踐santi ）

以下是上述方案的自動骨架插件實現，目前自動骨架化的過程比較簡陋，只具備了基礎的可用性，也希望能得到大家的幫助，共同完善自動骨架化的過程