前言
本文整理自興盛優選體驗技術部文同學在QCon 2022廣州站的演講分享，主題為“智能化與低碼化的應用與探索”。
在進入正文之前，我想我們應該回溯下曆史也了解下背景，任何新技術方案和平台興起的背後都是由于某一些問題的産生進而推進得來的。前端技術發展至今，前輩們通過不斷的探索，挖掘出了多種技術方向，湧現出不同的技術方案，我們作為後輩作為受益者，在平日的工作中會通過工程化，視覺化，區塊化，微應用化等方案，去賦能于企業，賦能于産線。而面對日益複雜的業務場景，日益劇增的業務疊代以及頻繁的重複性結果傳遞，這造成了團隊的人力需求劇增，投入成本巨大等問題，我想這都是大家在現實工作中所面臨的共同問題。是以”低代碼“這一話題，就從曆史的輪子當中再次被提取了出來。目前低代碼的表現形式大家對其都褒貶不一，部分人認為它沒有實際用處，沒法給研發人員通用化提效，反而增加了大量的定制化工作，給其定性為“毒瘤”。而部分人認為它解決了業務線具體的生産需求，是一個有效的生産力工具。無論大家對其如何的評價都不可否定低代碼是一個較好的解決方案，每一個人每一件事站在的角度不一樣得出的結論也大不相同。在接下來的文章中我會具體的講解，針對低代碼這一話題我不同的看法及其整體布局。
低碼化的方案制定
關于低碼化方案制定我們從兩個部分展開分别是《展現形式》《方案抉擇》，通過這兩部分我們能夠比較清晰的看待低代碼以及在日常工作中如何決策平台建設工作。
展現形式
如上圖所示低代碼的特征是極具特色和明顯的，我們可以用三個次元看出與其他方案不同之處。第一部分為互動模式的改變。第二部分為元件模式的不同，低代碼平台中會預先制作好常用元件，預先存留好正常場景，進而來縮短輸出工期。這一部分是低代碼平台的特色也是其最受争議的子產品。在以往的模式内我們有視覺化所提供出來的通用元件庫，有區塊化提供出來的業務元件和模版物料，正常模式裡元件庫與區塊是高度靈活和抽象的。而低代碼平台元件和物料部分被固化，形成先天性的劣勢，進而造成靈活性不高拓展性不強等問題，是以它最适合運用在”通用性““重複性”較高的場景。第三部分是資料模式的不同，在低代碼中資料是被抽象成配置的，無論是元件的屬性還是元件的事件流轉，都是通過資料配置化結合配置可視化來進行處理。結合上述三個不同次元的分解，我們不難看出其在某一些方向的優勢和劣勢，低代碼它不可被萬能化它不是一個可被業務運用在任何場景之下的通用技術方案，我們應該合理把控合理規劃的去建設其核心能力以及平台。
了解完低代碼的核心特征後我想多數人對此都會有了一定的客觀印象，接下來我們從模式和角色上進行分析。如上圖所示，低碼模式主要分為四種，“ProCode”“LowCode”“NoCode”“AutoCode”，每一種模式在使用方式上都有所不同，研發難易程度也是從低到高呈現，它們都被應用在不同的場景之下。第二部分我們從使用角色上進行拆解，面對平台不同的使用角色決定了我們對于平台建設上不同的技術架構，在圖中我粗略的以三種角色進行概括，其分為“開發人員使用”“無編碼能力人員使用”“基于環節式驅動”每一種方式我們所提供的功能及低碼模式都不一樣。其中開發人員更适合 Pro-Code|Low-Code 的方式，平台需要具備更高的靈活性群組件的插拔式面對多樣的業務場景都有很好的承接性。營運人員、産品經理、設計師等角色他們不具備編碼能力，對于頁面的生産過程不具備一定的了解。是以更适合 No-Code|Auto-Code 的方式,平台内需要内置大量的場景子產品，元件和事件流轉方案，在使用的過程中能夠被使用者更好地了解以及快速的輸出産物，不必糾結于細節，能夠模版配置化最好。而最難的莫過于環節驅動下的需求，每一個環節使用角色不一樣，其呈現出一連一的特征，這時我們就要考慮混合的建設方式，用不同的模式來解決每一個環節的痛點，最終打通整體流程。
方案決策
對于我們在業務産線中，想要基于低代碼方案來布局平台解決問題時，我們最重要的不是關注平台功能本身而是需要決策平台的落地方式。前文中我有分析過目前低代碼的整體情況及其展現形式，跟大家說這些也并不是我寫這篇文章的初心，而是想通過一步一步的演進進而推導出決策的方法。如上圖所陳列的一樣“應對不同的場景與角色，使用不同的方案以及方案的下沉深度”。确定使用人群，聚焦業務形态，尋找平台閉環。當我們确立了平台準确目标後，平台建設基本上就有了初步的形态，反之低代碼的展現形式及相關布局方式不符合目前業務場景使用時，請勿生搬硬套，反而容易吃力不讨好。有了基本的形态那麼接下來我們才需要考慮具體的技術方案，目前市面上有較多的方案可供選擇。例如：阿裡系的LowCodeEngine，騰訊系的 TmagicEditor，百度系Amis等。這些不乏都是行業裡比較成熟的案例，它們經過了企業内部的推敲驗證，我們可大膽嘗試使用。而面對一些中大型廠商，會有一些獨特的場景需求及定制化工作，在擁有合适技術人選以及人力資源投入時，我們可以不使用開源方案，自己制定出符合企業内部特色的低代碼技術解決方案。
驚奇引擎
在我加入興盛優選體驗技術部前，我們團隊内已經存在一部分低代碼的産品，他們都被運用在不同的業務領域，有大屏可視化的，有中背景搭建的，有營銷側的，有表單類的。無一例外它們都具備一定的業務價值，解決着一定的業務問題。但是每一個平台都有各自的方法論和實作原理。每一個平台有各自不同的視覺呈現以及其不同的互動方式。它們都劃分在不同的團隊中由不同的人員維護管理。不可否認這确實挺鍛煉人的，畢竟會輸送出一批了解低代碼平台建設的人才。但在同一個企業之中各平台所面對的大多數使用者或許是同一批人，這極大的增加了使用者使用的成本以及使用者切換平台的連貫性。其次多個平台的底層實作原理都由不同的人維護，每一個平台的底層疊代更新在功能層面也沒法更好的進行共享。新來一個搭建需求又是另起爐竈，重複疊代。說白了”輪子不怕多，越多越好“的事實在大多數企業内部也同樣存在，甚至整個圈子裡也在不斷重複建設。
結合上面所闡述的問題以及對整個團隊低碼産品有了充分了解後，我們開始了相關能力的研發工作，最終形成了一套可多端（移動端+中背景+大屏）支撐通用性強的低代碼引擎，它由四個子產品組合而成分别是 《低代碼視覺體系的建設》《低代碼底層原理庫的建設》《通用化低代碼開箱即用的建設》《低代碼物料協定與物料模版的建設》我為其取名《驚奇引擎-Marvel》，上圖為驚奇引擎整體的架構圖，接下來我會依次介紹每一個組成部分。
Dlib 的組成部分
Dlibrary 為驚奇引擎提供底層能力支撐，它包含八個高度解耦的服務子產品，我們将正常低代碼平台中需被通用化的功能在此統一封裝且每一個子產品都具備獨立插拔的能力，具體子產品如下：
●component-loader： 物料加載器，提供物料的接入識别以及轉換能力，為低碼平台提供源源不斷的資産支撐。
●canvas-loader ： 畫布加載器，其中包含多畫布，卡尺，容器自适應，沙箱隔離等功能，為低代碼平台提供作業區域的的核心能力支撐。
●draggable-lib： 拖拽庫，拖拽庫中包含了拖拽容器及拖拽元素的元件級封裝，并提供自由拖拽模式，排序拖拽模式供不同互動形态使用，還包含元素距離檢測，覆寫檢測，邊界檢測，合并成組等常見功能。
●render：渲染器，渲染器是元件 &自定義設定器 &頁面的核心渲染能力的包裝。
●animation-timeline：動畫設定器，其基于時間軸的方式配置的動畫細節，内置了整個動畫編排規則及正常動畫庫。
●factorys： 資料工廠，其内部包含資料源，接口，變量等不同子產品的工廠服務，提供各子產品的資料建立，存儲，提取，更新，監聽等操作。
●hotkeys：熱鍵庫，我們針對鍵盤操作提供了一套高度封裝的方法，通過簡單的參數配置即可對接到低碼平台，使其快速擁有快捷操作等功能。
●tools： 工具庫，其内部封裝了在低代碼平台建設中常見的工具函數
區域展示-01
畫布核心
畫布是低代碼平台重互動區域，其作用就不言而喻了，很多人對畫布的概念不清晰，甚至很多平台沒有畫布的概念，從“區域展示-01”圖中可見畫布為低代碼平台中呈現在那一部分。我們将卡尺、參考線、沙箱隔離等功能融合在了畫布元件之中，通過屬性進行功能的控制。而整個畫布的核心實作原理主要通過控制畫布容器的 TransformMatrix 數值進而控制整個區域的移動、縮放、旋轉、傾斜。具體如上圖所示
拖拽核心
拖拽是低代碼平台最常見的互動形态，而常見平台内多為單一模式，也就是非自由模式及排序模式。從“區域展示-01”圖中可見拖拽為低代碼平台中呈現在那一部分。作為底層引擎我們當然需要符合不同場景的需求，例如大屏可視化搭建、海報搭建依賴于自由拖拽模式，營銷活動 h5 搭建、中背景搭建依賴于排序拖拽模式。拖拽核心也主要劃分為兩個部分拖拽元素主體，拖拽容器主體。具體實作原理如上圖所示。
渲染核心
渲染這一話題在低代碼平台内分為兩種分别是元件的渲染、頁面的渲染。上圖有分離拆解圖供大家可視了解。而驚奇的核心渲染邏輯分為四個步驟
《整合資料》我們基于頁面 Schema 來進行元件渲染映射表的生成，形成元件與遠端渲染位址的一一映射的資料源，接着在進行資料的清洗，頁面中可能會存在重複元件的現象而面對這種情況我們采取由高為先的模式進行存留，避免元件渲染時元件腳本未被按照順序加載。
《建立渲染層級順序》首先我們會擷取目前承接渲染頁面的裝置視寬視高，在根據元件的渲染順序擷取元件真實渲染的寬高值，在按照裝置視高進行計算按照一個可視版面進行分組，分組資料會預設往後多增加一位。在通過分組資料進行腳本位址字元混合為後期 CDNCombo 方案做準備。
《預加載腳本》從前兩個步驟擷取到的最終映射表資料我們将會進行腳本的加載群組件執行個體追加的操作，一個可視版面進行兩次操作預先 loader 下一個可視版面資源。
《渲染核心》基于高階元件的方式通過 schema 中對于元件屬性配置的資料進行 props 的擷取與綁定，事件的擷取與綁定。進而完成整體頁面以及元件的渲染。整個過程可能無法通過幾段話來概括，但流程和原理大緻如此。
物料接入的建設
關于物料這一層級是很多低代碼平台乃至低代碼引擎都為之頭疼的部分，因為物料資産不夠或物料的研發流程複雜而限制低碼平台的拓展面的情況數不勝數。為解決這一問題目前市面上最為常見的做法是根據平台性質而内置化豐富的元件物料。好一點的平台或引擎會提供一些物料接入的規則，按照規定的模式進行研發，平台側提供物料注冊函數。而驚奇的做法相對于這些方式而言會更為輕便，接下來我簡單闡述下驚奇的原理和過程。如上圖所示，驚奇提供了物料接入的可視化操作，使得驚奇引擎搭建出來的低代碼平台可以在不變更平台代碼的基礎上無需平台發版的基礎上，即可快速接入單一物料或物料組。
我們可以通過兩種方式進行物料輸入，第一種是 npm 的對接，你隻需提供包名包版本，component-loader 的 node 服務會自動解析這一個 npm 包并分析出此包為單或多的形态進而進行單元件接入流程或元件集接入流程，在服務中我們會建立一個類似真實渲染的環境沙箱進而來擷取元件的相關資訊例如元件的名稱、屬性、事件等資訊，最終自動生成一份符合驚奇可被接受的物料描述資料集，第二種是 cnd 資源的對接，核心邏輯與 npm 類似。具體每一個核心流程在上圖有詳細的諾列。除此之外針對物料的生産我們也提供了一套物料腳手架，腳手架中提供了項目的建立打包部署等功能。除此之外驚奇為每一個物料都提供可視化的管理版本能力，每一個元件的渲染都與物料版本，物料配置版本強關聯進而避免造成元件更新影響老項目使用等核心問題。
DPro 的組成部分
DPro 為驚奇引擎提供上層的能力支撐，目前 DPro 主要分為兩個主要部分，分别是一整套低代碼的視覺體系規範其中包含低代碼平台的視覺規範以及視覺元件。除此之外還提供通過視覺規範所衍生出來的低碼細粒度子產品化元件，具體情況下面如下。
低代碼視覺體系的建設
如上圖所示，目前視覺規範中包含了 1000+的低碼平台正常圖示資源、40 多個預設圖、八大子產品（接口管理、資料源管理、變量管理、代碼編輯器、事件流管理、動作管理、元件物料管理、模版管理）30+的正常子產品（通用屬性設定器，樣式設定器，菜單元件等）
低代碼開箱即用的建設
我們在腳手架中也提供了初始化低碼平台的功能，而 marvel-pro 的包提供了如下圖所諾列的相關元件。開發者無需考慮 Dlibrary 的核心實作隻需要通過 DPro 提供的子產品化元件，像搭積木一樣搭建出你所需要的低代碼平台，目前驚奇引擎在興盛内部支撐着會場搭建、中台搭建等場景，我們也在着手基于驚奇引擎提供服務一體化平台，為企業提供更強有力的支撐。
智能化方向的探索
近兩年前端智能化方向非常火熱各大廠都紛紛投入其中，在接觸這一方向之前我們其實也思考過智能化相關落地的場景，它所能帶來的實際價值，研究過目前市面上相關的産品其中就有《imgcook》《codefun》《deco》這些平台。現階段市面上智能化相關的産品大多數都是基于 D2C 這一個場景下衍生出來的。而對于我們團隊内部而言 D2C 并不是我們第一層級所需要的能力，如何找到一個恰到合适的落地點，如何用智能化方案賦能前端領域，增強前端建設的多樣性，也成了我們探究很久的話題。通過不懈的努力我們最終在團隊内部孵化出了第一款相關平台 MarvelDesign。
MarvelDesign 的誕生
MarvelDesign 是一款打通設計稿傳遞，頁面自動走查的內建平台，我們通過智能化的手段，幫助前端開發工程師，視覺設計師在工作中簡化協作步驟，簡化思考，提高輸出品質，在前端頁面還原階段，設計驗收階段提供不同的智能輔助能力進而起到降本增效的目的。整個平台由 figma 端的資料接收服務，設計稿解析服務，标注生成服務，自動走查服務組合而成。在整個平台中除了通用的畫闆标注能力，智能走查能力之外，我們還基于深度學習的方式研發了元件識别模型，圖示識别模型等，我們會将這些模型運用在設計稿标注生成階段，将設計稿中的圖層進行識别，來回報出這一圖層的類别，在與正常資産進行一一比對。下面都是平台的相關截圖。
figma 端插件
平台側相關子產品
設計稿标注子產品圖示圖像管理子產品及項目生成子產品
智能走查子產品
核心能力的剖析
MD-01
MD-02
如何解析設計稿并生成我們想要的産物呢 ？我們拿 figma 舉例，figma平台本身有第三方插件研發生态提供了豐富的 openapi 供開發者使用。如上圖-MD-01 所示，調用 OpenApi 我們能夠擷取到整個設計稿畫闆的原始資料結構其中包含了畫闆中每一個元素的細節資料。拿到資料就可以進行一些騷操作了，比如說你想基于這些資料的關聯關系生成代碼或者基于這些資料做标注生成等功能，這就看每一個團隊的核心需求了。那麼 MD 是如何基于這份資料來進行标注生成的呢？如上圖-MD-02 所示其基本步驟有五個《資料的清洗》《圖層的處理》《新結構的生成》《樣式的轉換》《資料的混淆》我們将 figma 拿到的資料進行一次清洗後得到一個更清晰的結構其中就包含了畫闆的基礎資訊，圖層的基本資訊與圖層的屬性資訊等，接下來進行圖層的處理，我們将不可見圖層無含義圖層資料進行删除（隐藏的圖層或沒有任何展示效果的圖層）在進行疊加圖層的處理為疊加圖層增加一個父容器圖層。處理好資料與關系後，我們就會針對每一個圖層進行分析，分析過程大緻會經過三個步驟“圖示識别”“元件識别”“循環節點識别”，處理好每一個圖層的的資訊後得到一份 MD 的新資料結構。最後我們可以根據這份新的資料來進行下一階段的處理如樣式轉換，代碼生成等。
在上部分有講到關于元件與圖示的識别，那麼我們是如何處理這塊的呢？我們基于深度學習的方式進行元件識别模型與圖示識别模型的訓練最終得到相對應的權重檔案，将其部署到雲伺服器後在通過接口服務提供相關識别能力支撐。
SD-01
SD-02
關于 AI-人工智能大家可能都有耳聞，AI 其實包含的東西有很多例如機器學習，深度學習等，它們之間有什麼差別呢？如上圖-SD-02 所示它們之間是一種包裹關系 AI > 機器學習 > 深度學習。用通俗易懂一點的方式來介紹一下，機器學習是人提前設定好标簽和特征，然後由計算機按照設定好的标簽特征去工作。 深度學習無需人工設定特征。基于提供的樣本資料集自動訓練模型計算權重偏量，找到各種資料的特征然後進行工作。那麼如果我們想基于深度學習來訓練一個自己的元件識别模型那麼需要怎麼做呢？如上圖 SD-01 所示，其整個過程分為 8 個步驟，我們挑一些重要的步驟講解一下。首先第一步是樣本的準備，樣本就是我們要提供給算法的訓練資料，我們可以通無頭浏覽器去跑一些站點收集一些元件不同形态的圖像，例如文本框的展現形式按鈕的展現形式，有了樣本後我們就會進行樣本打标操作，最後我們要按照比例整理好結構其中包含訓練資料集、驗證資料集、測試資料集。
有了樣本資料我們就需要進入到算法決策以及模型訓練等環節，想要完成元件識别這一功能，有兩種方式可供選擇分别是圖像分類，目标檢測。如上圖所示圖像分類又分為強監督細粒度圖像分類和弱監督細粒度圖像分類。目标檢測也分為 One Stage 檢測算法和 Two stage 檢測算法。MD 采取的是圖像分類算法，我們不需要在一張圖中檢測出該圖有哪一些命中目标，隻需要一對一的圖像識别即可。那麼如果你是直接進行設計稿圖像的識别那麼就需要使用目标檢測的方式來進行元件識别，這樣可以在設計稿圖像中識别出多個命中目标。目前市面上有兩個主流架構來進行深度學習和機器學習的研發分别是 TesorFlow&Pytorch，使用這些架構多多少少需要具備一定 python 的研發能力，作為前端來說這會有一定的學習成本，在這裡我推薦大家可以了解下阿裡開源的《Pipcook》它是一款能讓前端工程師更容易上手的架構，處理一些元件識别圖示識别等功能還是綽綽有餘。
智能 UI 走查的實作原理
智能走查的應用場景在那裡？我想大多數設計師朋友都能體會到，由于每一個前端工程師的能力都有差別那麼基于設計稿還原出來的頁面品質都有所不同，每一次項目上線之前設計師都會進行頁面的設計還原度測試，檢測頁面還原是否有問題比如說顔色的檢查，字型大小字重的檢查，間距的檢查，寬高的檢查等。這是一個沒有什麼技術含量卻非常花費時間精力的一項工作。那麼我們基于智能走查的方案能夠在頁面還原度驗收環節降低非常多的人力成本。那麼具體實作原理如下圖所示，整個自動走查的原理是基于圖像對比進行元素比對，在基于真實 dom 元素樣式表和與之比對的設計稿元素标注樣式表進行資料層面上的對比最終形成一份差異映射表。其中分為五個步驟《擷取頁面可視節點》《生成節點快照》《節點與圖層比對》《計算比對資料的樣式表差異》這一整個步驟中最為重要和有難度的的就是“節點比對”這一個環節。
針對”節點比對“我們可以通過圖像相似度對比的方式來進行處理其分為兩個步驟《圖像的指紋提取》《圖像指紋的比對》如上圖所示方案有很多不做一一講解，以均值雜湊演算法作為例子。一張圖檔就是一個二維資訊，它包含了不同頻率的成分亮度小的為低頻它描述大範圍資訊，亮度變化大的就是高頻區域他描述具體細節。高頻可以提供圖像的詳細資訊，低頻提供整體圖像架構，均值雜湊演算法就是利用圖像的低頻資訊進行處理。我們基于下圖 ZC-0 的步驟可以擷取到兩張圖像的指紋，在基于下圖 ZC-1 中的方式的得到兩個指紋的相似度值，最終可以得出可視節點與設計稿節點的比對度。在 MD 中我們采取的是混合提取與混合比對的模式來提高比對的準确度。整個過程包含了初篩，排序，複篩這三個過程具體如下圖 ZC-2，最終我們可以通過上述手段輸出設計稿自動走查的完成能力。
ZC-0
ZC-1
ZC-2
總結
目前智能化與低碼化在我們團隊内部都有很好的落地場景以及産品輸出，雖然每一個産品都會存在相關問題，但産品的完善是一步一步來的。未來我們也會在這兩個方向不斷輸出更多有價值的功能賦能于企業。如果你也面臨着一些相同問題或正在這兩個方向做相關産品布局，希望這一篇文章講述的過程和思路能給你帶來一些啟發。