1. 從“artcraft”這個名字說起它到底想解決什么問題第一次看到“artcraft”這個標題我腦子里蹦出來的第一反應是“藝術(shù)”加“手藝”一個把創(chuàng)意和動手能力揉在一起的東西。后來跟幾個做獨立開發(fā)的朋友聊發(fā)現(xiàn)大家對這個詞的理解出奇地一致它不是一個具體的工具名而是一類項目的統(tǒng)稱——用代碼去生成、處理、編排視覺內(nèi)容。你可以把它理解成一個“數(shù)字手工作坊”輸入的是邏輯和參數(shù)輸出的是圖像、動畫、排版或者交互式的視覺作品。這類項目最吸引人的地方在于它把過去只有設計師在專業(yè)軟件里才能完成的事情變成了程序員可以用自己熟悉的思維方式去操控的流程。比如批量生成風格統(tǒng)一的封面圖、根據(jù)數(shù)據(jù)動態(tài)渲染圖表海報、把一套設計規(guī)范自動應用到幾十個頁面上這些在傳統(tǒng)工作流里需要大量重復勞動的事情用 artcraft 的思路來做往往就是幾十行代碼的事。我之所以想認真聊聊這個方向是因為過去大半年里我陸陸續(xù)續(xù)用類似的思路做了好幾個小項目踩了不少坑也攢了一些確實能省時間的經(jīng)驗。這篇文章適合兩類人看一類是有點編程基礎、想把手伸到視覺創(chuàng)作領域但不知道從哪下手的開發(fā)者另一類是做設計或內(nèi)容相關的工作、想了解怎么用代碼把自己從重復勞動里解放出來的朋友。不需要你是圖形學專家也不需要你精通設計軟件只要你能看懂基本的代碼邏輯剩下的東西都可以邊做邊學。2. 整體設計思路為什么我選擇“代碼生成視覺”這條路2.1 核心邏輯把視覺元素拆成可編程的原子artcraft 類項目最底層的思維方式是把一個完整的視覺作品拆解成一個個可以獨立控制的原子單元。一張海報在你眼里可能是一個整體但在代碼的世界里它是背景色、若干文字塊、幾個圖形元素、一層濾鏡效果按照特定坐標和層級關系組合出來的結(jié)果。這個拆解過程聽起來簡單但實際操作時你會發(fā)現(xiàn)拆得好不好直接決定了后續(xù)的可維護性和擴展性。我剛開始做這類項目的時候犯過一個很典型的錯誤把整個畫面當成一個整體來處理每次調(diào)整都去改一堆硬編碼的坐標和尺寸。結(jié)果就是第一版做出來還行一旦要改個尺寸或者換個配色整個代碼就得推倒重來。后來我學乖了強制自己用“組件化”的思路來組織代碼——每個視覺元素都是一個獨立的函數(shù)或類接收參數(shù)、返回渲染結(jié)果元素之間的位置關系用相對布局來描述而不是絕對坐標。這個轉(zhuǎn)變帶來的好處是巨大的改一個按鈕的樣式所有用到這個按鈕的地方自動更新?lián)Q一套配色方案只需要改一個配置對象。提示如果你之前沒有接觸過聲明式的 UI 描述方式可以把它想象成寫 HTML 和 CSS 的關系。HTML 負責結(jié)構(gòu)CSS 負責樣式兩者分離之后改樣式不會影響結(jié)構(gòu)。artcraft 項目里也應該遵循類似的原則把“畫什么”和“怎么畫”分開。2.2 技術(shù)選型為什么我最終選了這套組合市面上能做代碼生成視覺的技術(shù)方案很多從最底層的 Canvas API 到高層的圖形庫各有各的適用場景。我前后試過四五種不同的組合最后穩(wěn)定下來的方案是Canvas 2D 一個輕量級的布局引擎 配置驅(qū)動的樣式系統(tǒng)。下面這張表是我對幾種常見方案的對比你可以根據(jù)自己的需求來選。方案上手難度靈活性適合場景我的評價純 Canvas API中等極高需要精細控制每一個像素靈活但開發(fā)效率低適合底層庫開發(fā)SVG DOM 操作低中等圖標、簡單圖表、交互式圖形調(diào)試方便但復雜場景性能會瓶頸服務端圖像庫中等中等批量生成、無需交互的靜態(tài)圖適合自動化流水線但調(diào)試體驗差聲明式圖形框架低高大多數(shù) artcraft 類項目開發(fā)效率最高推薦首選我最終選擇 Canvas 2D 作為渲染底座是因為它在瀏覽器環(huán)境里的兼容性和性能表現(xiàn)最均衡。布局引擎我選了一個很輕量的方案核心功能就是計算元素的位置和尺寸不涉及任何渲染邏輯。樣式系統(tǒng)則是完全配置驅(qū)動的所有顏色、字體、間距都放在一個獨立的配置文件里代碼里只引用變量名。這套組合的好處是渲染層、布局層、樣式層各司其職任何一層的改動都不會波及其他層。2.3 數(shù)據(jù)流設計從輸入到輸出的完整鏈路一個 artcraft 項目的完整數(shù)據(jù)流我習慣把它分成四個階段輸入解析、布局計算、渲染繪制、輸出導出。輸入解析階段負責把用戶提供的參數(shù)或者外部數(shù)據(jù)轉(zhuǎn)換成內(nèi)部的數(shù)據(jù)結(jié)構(gòu)布局計算階段根據(jù)這些數(shù)據(jù)和預設的布局規(guī)則算出每個元素應該在什么位置、占多大空間渲染繪制階段把計算好的布局信息轉(zhuǎn)換成實際的繪制指令輸出導出階段則負責把渲染結(jié)果保存成圖片或者導出成其他格式。這個鏈路里最容易出問題的是布局計算階段。因為視覺元素之間往往存在復雜的依賴關系比如一個文字塊的高度取決于它的內(nèi)容長度和字體大小而它下面的元素的位置又取決于這個文字塊的高度。如果處理不好這種依賴關系就會出現(xiàn)元素重疊或者間距不均勻的問題。我的經(jīng)驗是盡量用“約束布局”的思路來描述元素之間的關系而不是手動計算每一個坐標。比如“這個元素在另一個元素下方 20 像素處”就是一個約束布局引擎會自動處理依賴關系。3. 核心細節(jié)解析那些文檔里不會告訴你的關鍵點3.1 坐標系與單位新手最容易翻車的地方幾乎所有剛接觸 artcraft 類項目的人都會在坐標系上栽跟頭。Canvas 的默認坐標系原點在左上角x 軸向右延伸y 軸向下延伸這和我們在數(shù)學課上學的笛卡爾坐標系正好相反。更麻煩的是不同庫和框架對坐標系的處理方式還不一樣有的支持自定義原點位置有的支持縮放和旋轉(zhuǎn)如果不搞清楚當前使用的坐標系規(guī)則畫出來的東西位置會完全對不上。我的建議是在項目初期就統(tǒng)一約定一套坐標系規(guī)范并且寫進項目文檔里。比如約定所有坐標都相對于父容器的左上角所有尺寸都使用邏輯像素而不是物理像素旋轉(zhuǎn)角度統(tǒng)一使用弧度制而不是角度制。這些約定看起來是小事但能省掉后面大量的調(diào)試時間。另外涉及到高分辨率屏幕適配的時候記得處理設備像素比否則在高分屏上渲染出來的圖像會模糊。注意如果你在布局計算階段使用了相對坐標在渲染階段一定要記得轉(zhuǎn)換成絕對坐標。我見過太多項目因為混淆了相對坐標和絕對坐標導致元素位置飄忽不定。3.2 文字排版比想象中復雜得多的細節(jié)文字排版是 artcraft 項目里最容易被低估的部分。很多人覺得不就是畫幾個字嗎能有多難。但實際操作起來你會發(fā)現(xiàn)文字的對齊方式、行高、字間距、換行規(guī)則、字體回退機制每一個細節(jié)都可能出問題。特別是當文字內(nèi)容來自外部數(shù)據(jù)、長度不可控的時候如何保證排版的美觀和可讀性就成了一個真正的挑戰(zhàn)。我處理文字排版的經(jīng)驗是把文字塊當成一個有彈性的容器而不是一個固定尺寸的盒子。文字塊的高度應該由內(nèi)容決定寬度則由外部約束決定。當文字內(nèi)容超出容器寬度時自動換行當文字內(nèi)容超出容器高度時要么截斷并顯示省略號要么自動縮小字號。這兩種策略各有適用場景需要根據(jù)具體需求來選擇。另外中英文混排的時候要特別注意中文沒有單詞邊界的概念換行規(guī)則和英文完全不同如果使用的庫沒有內(nèi)置中文換行支持就需要自己實現(xiàn)一套斷行邏輯。3.3 顏色與樣式配置驅(qū)動的威力前面提到過我強烈建議把顏色和樣式從代碼里抽離出來放到獨立的配置文件里。這個做法帶來的好處在你需要批量生成不同風格的作品時會體現(xiàn)得淋漓盡致。比如你要為同一個內(nèi)容生成淺色和深色兩個版本的海報如果樣式是硬編碼在代碼里的你就得寫兩套渲染邏輯但如果樣式是配置驅(qū)動的你只需要準備兩份配置文件渲染邏輯完全不用改。配置驅(qū)動的另一個好處是它讓非技術(shù)人員也能參與到創(chuàng)作過程中來。設計師可以修改配置文件里的顏色和字體不需要懂代碼就能調(diào)整最終效果。我甚至見過有團隊把配置文件做成了一個簡單的可視化編輯器運營人員可以直接在界面上調(diào)顏色、改文案然后一鍵生成圖片。這種工作流的效率提升是巨大的。樣式屬性推薦配置方式常見坑點顏色使用語義化命名如 primary、secondary直接寫十六進制值后期難以維護字體定義字體棧包含回退字體只指定單一字體在缺少該字體的環(huán)境顯示異常間距使用統(tǒng)一的間距比例尺到處寫魔法數(shù)字視覺節(jié)奏混亂圓角定義幾檔預設值每個元素單獨設置風格不統(tǒng)一3.4 性能優(yōu)化什么時候該關心什么時候不用管性能優(yōu)化這個話題我的態(tài)度是先跑通再優(yōu)化。很多新手在項目剛開始就擔心性能問題花大量時間研究各種優(yōu)化技巧結(jié)果功能還沒做完就放棄了。實際上對于大多數(shù) artcraft 類項目來說只要不是要實時渲染幾百個動態(tài)元素性能都不會是瓶頸?，F(xiàn)代瀏覽器的 Canvas 渲染性能已經(jīng)相當不錯了生成一張靜態(tài)圖片通常只需要幾毫秒到幾十毫秒。真正需要關心性能的場景主要有兩個一是需要實時交互的場景比如用戶拖動滑塊時畫面要即時更新二是需要批量生成大量圖片的場景比如一次要生成上千張不同尺寸的封面圖。對于第一種場景優(yōu)化的重點是減少不必要的重繪只更新變化的部分對于第二種場景優(yōu)化的重點是復用計算資源避免重復的布局計算和樣式解析。我個人的經(jīng)驗是先把功能做完整然后用性能分析工具找出真正的瓶頸再針對性地優(yōu)化不要憑感覺瞎猜。4. 實操過程從零搭建一個 artcraft 項目的完整記錄4.1 環(huán)境準備與項目初始化假設你現(xiàn)在要從零開始做一個 artcraft 項目第一步是搭好開發(fā)環(huán)境。我習慣用 Node.js 作為運行環(huán)境配合一個支持熱更新的開發(fā)服務器這樣改代碼之后瀏覽器會自動刷新省去手動刷新的麻煩。項目結(jié)構(gòu)我一般會這樣組織artcraft-project/ ├── src/ │ ├── renderer/ # 渲染相關代碼 │ ├── layout/ # 布局計算相關代碼 │ ├── components/ # 可復用的視覺組件 │ └── index.js # 入口文件 ├── config/ │ ├── theme.js # 樣式配置 │ └── presets.js # 預設參數(shù) ├── assets/ │ └── fonts/ # 字體文件 └── package.json這個結(jié)構(gòu)的好處是職責清晰渲染、布局、組件各放在不同的目錄里找代碼的時候不用翻半天。配置文件單獨放在 config 目錄下方便非技術(shù)人員修改。字體等靜態(tài)資源放在 assets 目錄里構(gòu)建的時候會被自動處理。初始化項目的時候我建議先把渲染引擎的基本框架搭起來能畫出一個最簡單的矩形或者文字確認整個鏈路是通的然后再逐步添加復雜功能。這個“先跑通最小閉環(huán)”的思路能幫你盡早發(fā)現(xiàn)環(huán)境配置上的問題避免寫了一堆代碼之后才發(fā)現(xiàn)某個依賴裝不上。4.2 核心渲染循環(huán)的實現(xiàn)渲染循環(huán)是 artcraft 項目的心臟它的職責是協(xié)調(diào)布局計算和實際繪制。我實現(xiàn)渲染循環(huán)的基本思路是這樣的首先收集所有需要渲染的元素然后按照層級關系排序接著依次計算每個元素的位置和尺寸最后調(diào)用底層繪圖 API 把元素畫出來。這個過程可以用一個簡化的偽代碼來描述function render(scene, context) { // 第一步解析場景描述得到元素列表 const elements parseScene(scene); // 第二步計算布局得到每個元素的絕對位置和尺寸 const layoutResult computeLayout(elements, context); // 第三步按層級順序繪制元素 layoutResult.forEach(element { drawElement(element, context); }); // 第四步返回渲染結(jié)果供導出使用 return context.canvas; }這個流程看起來簡單但每一步都有很多細節(jié)需要處理。比如在解析場景描述的時候要處理元素的繼承關系子元素默認繼承父元素的某些樣式屬性在計算布局的時候要處理約束沖突當多個約束條件互相矛盾時需要有明確的優(yōu)先級規(guī)則在繪制元素的時候要處理裁剪和遮罩確保超出容器范圍的內(nèi)容不會被畫出來。我踩過的一個坑是早期版本里我把布局計算和繪制邏輯混在一起導致每次調(diào)整布局都要重新繪制性能很差。后來把兩者拆開之后布局計算的結(jié)果可以緩存起來只有數(shù)據(jù)變化時才重新計算繪制則可以在每次需要的時候快速執(zhí)行。這個拆分帶來的性能提升非常明顯特別是在需要頻繁更新畫面的場景下。4.3 組件化開發(fā)從重復代碼到可復用模塊當你做了幾個 artcraft 項目之后會發(fā)現(xiàn)很多視覺元素是反復出現(xiàn)的標題、副標題、正文、分割線、標簽、按鈕等等。如果每次做新項目都重新寫一遍這些元素的渲染邏輯效率太低了。我的做法是把這些常見的視覺元素抽象成獨立的組件每個組件負責自己的渲染邏輯對外只暴露簡單的參數(shù)接口。舉個例子一個“標題”組件可能接收這些參數(shù)文字內(nèi)容、字號、顏色、對齊方式、最大寬度。組件內(nèi)部會根據(jù)這些參數(shù)計算出文字的實際渲染位置處理換行和截斷然后調(diào)用底層的文字繪制 API。使用這個組件的時候你不需要關心文字是怎么畫的只需要告訴它“畫什么”和“大概長什么樣”就行了。組件化開發(fā)的關鍵在于設計好組件的接口。接口太簡單靈活性不夠稍微特殊一點的需求就滿足不了接口太復雜學習成本高用起來還不如直接寫代碼。我的經(jīng)驗是從最常用的場景出發(fā)設計接口遇到特殊需求時再考慮擴展。不要一開始就試圖設計一個能處理所有情況的萬能組件那樣往往會過度設計。提示組件之間的組合方式也很重要。我習慣用“容器組件 內(nèi)容組件”的模式來組織容器組件負責布局和間距內(nèi)容組件負責具體的視覺呈現(xiàn)。這樣拆分之后換一種布局方式不需要改內(nèi)容組件換一種內(nèi)容樣式也不需要改容器組件。4.4 導出與后處理讓作品真正能用起來渲染出來的畫面最終是要拿去用的所以導出功能同樣重要。最常見的導出需求是保存成 PNG 或 JPEG 圖片Canvas 原生提供了 toDataURL 和 toBlob 兩個方法來實現(xiàn)這個功能。但實際使用的時候有幾個細節(jié)需要注意一是導出圖片的尺寸和分辨率默認導出的是邏輯像素尺寸如果需要更高分辨率的圖片需要在導出前臨時放大畫布二是導出圖片的質(zhì)量JPEG 格式可以設置壓縮質(zhì)量PNG 格式則支持透明背景三是導出圖片的元數(shù)據(jù)有些場景下需要保留或者清除圖片的元信息。除了基本的圖片導出有時候還需要做一些后處理比如添加水印、拼接多張圖片、生成不同尺寸的縮略圖等等。這些操作可以在渲染完成后、導出之前進行也可以導出之后用圖像處理庫來處理。我個人的偏好是在渲染階段就把所有視覺元素都處理好導出階段只做格式轉(zhuǎn)換這樣邏輯更清晰也更容易調(diào)試。5. 常見問題與排查技巧實錄5.1 畫面模糊高分屏適配的坑這是被問得最多的問題之一為什么我渲染出來的圖片在手機上看起來很模糊原因幾乎總是出在設備像素比的處理上。在高分屏設備上一個邏輯像素對應多個物理像素如果畫布的尺寸沒有按照設備像素比進行縮放瀏覽器就會把低分辨率的畫布拉伸到高分辨率顯示導致模糊。解決方法是在初始化畫布的時候把畫布的物理尺寸設置為邏輯尺寸乘以設備像素比然后用 CSS 把畫布的顯示尺寸設置回邏輯尺寸最后對繪圖上下文進行縮放。這樣繪制出來的內(nèi)容就是按物理像素渲染的在高分屏上會非常清晰。具體的代碼邏輯是這樣的const dpr window.devicePixelRatio || 1; const logicalWidth 800; const logicalHeight 600; canvas.width logicalWidth * dpr; canvas.height logicalHeight * dpr; canvas.style.width logicalWidth px; canvas.style.height logicalHeight px; context.scale(dpr, dpr);這段代碼看起來簡單但很多人會忘記最后一步的 scale 調(diào)用結(jié)果就是畫布尺寸對了但繪制的內(nèi)容還是按邏輯像素來的依然模糊。5.2 文字截斷內(nèi)容超出容器時的處理策略文字內(nèi)容超出容器范圍是另一個高頻問題。處理策略主要有三種截斷加省略號、自動縮小字號、自動擴展容器。這三種策略各有適用場景選擇哪種取決于具體的業(yè)務需求。截斷加省略號適合標題或者摘要類的文字保證布局的整齊自動縮小字號適合按鈕或者標簽類的文字保證內(nèi)容完整顯示自動擴展容器適合正文類的文字保證可讀性。實現(xiàn)截斷加省略號的時候要注意中英文的差異英文按單詞截斷中文按字符截斷混排的時候需要更復雜的邏輯來判斷截斷位置。我實現(xiàn)過一個通用的文字截斷函數(shù)核心思路是不斷嘗試縮短文字內(nèi)容直到渲染寬度小于容器寬度為止。這個函數(shù)在處理大量文字的時候性能不太好所以實際項目中我會加一個緩存機制相同內(nèi)容和參數(shù)的截斷結(jié)果直接復用。5.3 布局錯亂約束沖突的排查思路布局錯亂是 artcraft 項目里最難排查的問題之一因為它的表現(xiàn)往往是“某個元素位置不對”但原因可能出在完全不相干的地方。我的排查思路是從外到內(nèi)、從簡到繁先檢查最外層容器的尺寸和位置是否正確再逐層往里檢查每個元素的布局約束是否合理最后檢查是否存在互相矛盾的約束條件。一個常見的約束沖突場景是父容器的高度由子元素決定但子元素的高度又依賴于父容器的高度。這種循環(huán)依賴會導致布局引擎無法計算出確定的結(jié)果表現(xiàn)就是元素位置飄忽不定或者直接消失。解決方法是打破循環(huán)依賴要么給父容器一個固定高度要么讓子元素的高度不依賴于父容器。問題表現(xiàn)可能原因排查方法元素位置偏移坐標系混淆或父元素定位錯誤逐層打印元素的計算位置元素尺寸異常約束條件沖突或單位錯誤檢查寬高約束的優(yōu)先級元素重疊層級順序錯誤或絕對定位沖突檢查元素的 z-index 和定位方式內(nèi)容被裁剪容器溢出隱藏或裁剪區(qū)域設置錯誤檢查 overflow 相關配置5.4 字體加載異步加載帶來的時序問題自定義字體是 artcraft 項目里提升視覺效果的重要手段但字體加載是異步的如果處理不好時序問題就會出現(xiàn)“字體還沒加載完就開始渲染”的情況導致最終畫面用的是回退字體。解決方法是使用 Font Loading API 或者字體加載庫在字體加載完成之后再觸發(fā)渲染。我習慣在項目初始化階段就把所有需要的字體加載好加載完成后再啟動渲染流程。如果字體文件比較大可以考慮只加載實際用到的字符子集減少加載時間。另外記得設置合理的字體回退棧萬一自定義字體加載失敗至少還能用系統(tǒng)字體正常顯示。6. 進階技巧讓 artcraft 項目更上一層樓6.1 模板系統(tǒng)批量生成不同內(nèi)容的作品當你需要為不同的內(nèi)容生成風格一致的作品時模板系統(tǒng)就派上用場了。模板系統(tǒng)的核心思想是把視覺結(jié)構(gòu)和具體內(nèi)容分離結(jié)構(gòu)部分定義一次內(nèi)容部分每次替換。實現(xiàn)方式可以很簡單比如用占位符標記內(nèi)容位置渲染時替換成實際內(nèi)容也可以很復雜比如支持條件渲染、循環(huán)渲染、嵌套模板等高級特性。我做過一個批量生成社交媒體封面的項目就是基于模板系統(tǒng)的思路。定義好封面的布局模板然后從數(shù)據(jù)源讀取標題、副標題、作者信息等內(nèi)容逐個填充到模板里生成圖片。整個過程完全自動化幾百張封面圖幾分鐘就能生成完。這個項目讓我深刻體會到artcraft 類項目的真正價值不在于生成單張精美的圖片而在于把視覺創(chuàng)作變成可批量、可復用的流程。6.2 動態(tài)數(shù)據(jù)綁定讓畫面隨數(shù)據(jù)變化動態(tài)數(shù)據(jù)綁定是另一個讓 artcraft 項目變得強大的特性。簡單來說就是畫面上的某些元素不是固定的而是根據(jù)外部數(shù)據(jù)實時變化的。比如一個數(shù)據(jù)可視化海報柱狀圖的高度取決于實際數(shù)據(jù)值一個天氣卡片背景顏色取決于當前溫度。實現(xiàn)動態(tài)數(shù)據(jù)綁定的關鍵是建立數(shù)據(jù)模型和視覺元素之間的映射關系數(shù)據(jù)變化時自動觸發(fā)重新渲染。我實現(xiàn)數(shù)據(jù)綁定的方式比較樸素就是維護一個數(shù)據(jù)對象每次數(shù)據(jù)變化時重新執(zhí)行整個渲染流程。對于簡單的場景這種方式完全夠用對于復雜的場景可能需要引入更精細的更新策略只重新渲染受影響的部分。不過我的經(jīng)驗是除非性能真的成為問題否則全量重新渲染是最簡單也最不容易出錯的方案。6.3 插件化架構(gòu)方便擴展新功能如果你打算把 artcraft 項目做成一個長期維護的工具插件化架構(gòu)值得考慮。核心框架只負責最基礎的渲染和布局功能具體的視覺元素、導出格式、后處理效果都通過插件來提供。這樣做的最大好處是新增功能不需要修改核心代碼降低了引入 bug 的風險也方便社區(qū)貢獻。設計插件系統(tǒng)的時候關鍵是定義好插件接口。接口要足夠簡單讓插件開發(fā)者容易上手同時要足夠靈活能覆蓋大多數(shù)擴展需求。我一般會定義幾個關鍵的生命周期鉤子比如“渲染前”、“渲染后”、“導出前”等插件可以在這些鉤子上注冊自己的處理邏輯。7. 我個人的一些經(jīng)驗和建議做 artcraft 類項目這段時間最大的體會是視覺編程和傳統(tǒng)編程的思維方式確實不一樣但并沒有想象中那么難。傳統(tǒng)編程處理的是邏輯和數(shù)據(jù)視覺編程處理的是空間和感知。剛開始的時候你會覺得坐標、尺寸、顏色這些東西很瑣碎但做多了之后你會逐漸建立起一種“空間感”看到需求就能在腦子里大概勾勒出布局方案。另一個體會是不要追求一步到位。我見過太多人想做一個“完美的” artcraft 框架結(jié)果花大量時間在設計架構(gòu)上真正能跑起來的東西卻沒多少。我的建議是從最簡單的需求開始先做一個能畫出基本圖形和文字的小工具然后根據(jù)實際需求逐步擴展。每次擴展都解決一個具體的問題這樣積累下來的代碼才是真正有用的。最后分享一個我覺得很實用的小技巧給渲染結(jié)果加一個調(diào)試模式。在調(diào)試模式下把每個元素的邊界框、布局約束、層級關系都可視化出來這樣排查布局問題的時候會直觀很多。這個功能實現(xiàn)起來很簡單但在實際開發(fā)中能省下大量時間。我現(xiàn)在的每個 artcraft 項目都會默認帶上這個調(diào)試模式通過一個配置項來控制開關。這個方向后續(xù)還可以往很多地方擴展比如結(jié)合數(shù)據(jù)可視化做動態(tài)圖表、結(jié)合圖像處理做風格遷移、結(jié)合交互設計做可配置的視覺編輯器。核心思路都是一樣的把視覺元素變成可編程的模塊用代碼來編排和生成。掌握了這個思路剩下的就是根據(jù)具體需求去組合和創(chuàng)造了。