前端生成海報圖技術選型與問題解決
一、引言
絕大多數的電商平臺都會設計分享裂變的功能，激勵用戶進行分享，這是一種拉新促活的常見措施。提到分享裂變，就免不了需要生成用戶專屬的分享鏈接或者專屬海報。當然分享推廣的形式多種多樣，有文本鏈接、網頁鏈接、圖片邀請碼、小程序、音視頻等等。
本篇文章主要聚焦海報圖分享這個形式，探討純前端在H5&小程序內，合成海報到下載到本地、分享至社交平臺整個流程中可能遇到的問題，以及如何解決。
二、選型參考
2.1 實現方式
根據海報圖生成渠道的差異，可以將海報圖生成分為：客戶端生成、前端生成和服務端生成，以下是從技術實現、兼容性、生成速度和功能受限四個維度進行的對比：
- 對于排版復雜的場景： 建議使用服務端Node.js渲染的方式【如Puppeteer圖片生成】；
- 對于排版簡單，但用戶請求并發大的場景：建議使用前端或客戶端生成海報圖；
- 對于需多端投放，樣式動態更新的場景：建議使用前端生成海報圖；
- 對于疊加用戶交互的場景：建議使用客戶端原生繪制的方式生成。
本篇文章著重聚焦前端H5 & 小程序內生成海報圖的技術實現，如果大家對服務端、客戶端生成海報圖的方案感興趣，文末有相關鏈接可供參考。
2.2 H5 生成海報圖技術選型
H5 生成海報圖常推薦的方案有三種：
（1）html2canvas：基于頁面中存在且可用的DOM結構、樣式，構建“截圖”，繪制到canvas畫布中。
下面是html2canvas的技術解析，詳細講解可以參考文末鏈接。
（2）dom-to-image：將DOM 節點序列化為XML，包裝到SVG中，再轉為圖片。
下面是dom-to-image的技術解析，詳細講解可以參考文末鏈接。
（3）canvas 純原生繪制
以下是示例代碼，這里不做贅述
html2canvas和dom-to-image都是用于在canvas的基礎上封裝的庫，由于底層實現方式的不同，它們各有優缺點，以下是從幾個維度進行的優缺點對比。
那么如何快速的確認當前的項目應該用哪個組件庫呢，有沒有必要逐個去驗證，這里給到幾點建議：
- 如果需要處理的頁面比較復雜或者需要支持SVG圖片渲染，在html2canvas中可能更好一些。
- 如果需要穩定的文字、圖片渲染能力或者處理結構化數據的能力，在dom-to-image中可能更好一些。
- 如果頁面基本是圖片資源，那么使用原生canvas性能是最好的。
2.3 小程序生成海報圖技術選型
與H5類似，小程序生成海報圖在項目中常用的也有三種方案：
（1）wxml-to-canvas：利用微信小程序提供的canvas組件，將指定的wxml轉化成canvas繪圖，然后再將其導出為圖片
（2）Painter：利用JSX語法，將繪圖的操作轉化成繪制命令，并生成對應的canvas繪圖
下圖來源于Painter 2.0官方介紹
（3）Canvas/Canvas2D
以下是小程序2D Canvas 官方示例代碼，詳見微信小程序基礎能力/畫布
- 從技術實現上看，wxml-to-canvas 是基于2d類型的Canvas組件能力，對基礎庫有要求，需在2.7.0以上。在canvas2d的基礎上，封裝了繪制text、image和view的能力，提供wxml繪制到canvas和導出圖片的方法。Painter不僅支持2d類型的canvas，同時兼容了低版本canvas組件。同時支持更多復雜樣式的繪制，對于網絡素材實現了一套LRU存儲機制，無需重復下載圖片，并增加了容錯機制。
- 從使用方法上看，wxml-to-canvas使用相對較簡單，只需要在小程序中引入wxml-to-canvas庫，然后傳入需要生成海報圖的wxml代碼和畫布的寬高即可。而Painter需要在小程序中使用類JSX的語法繪制所有圖形，覆蓋小程序頁面中相應的canvas組件。
針對兩種不同庫，wxml-to-canvas更適合將已有的wxml結構轉換為圖片，對于復雜的定制化設計需要在wxml中拼接、排版的海報來說，并不是最佳選擇。Painter則更適合在小程序中進行復雜繪制操作。
但從另一個角度看,如果對繪制性能要求比較高的業務來說，wxml-to-canvas 相比Painter更符合訴求。當然，如果僅涉及圖片間的快速組合，也可以使用canvas原生繪制的能力，只是要關注圖像繪制和canvas導出的實際問題。
前面兩個章節，主要解決在繪制選型上的疑慮，下一步面對的就是如何解決實現過程中出現的問題。
三、H5 常見問題
3.1 設計還原效果
設計還原除了關注最基礎的字體樣式、排版，同時也要兼顧深色模式適配、字號大小適配、頁面縮放、瀏覽器兼容性。這些因素無疑給前端生成海報圖帶來巨大的壓力，下面我也將從提到的這些方面進行展開，也可以作為大家選型參考或者解決方案的參考。
當業務需求涉及復雜的文本排版，那么建議直接放棄canvas原生繪制，難度大風險大耗時長。第三方庫處理邏輯大同小異，本質上都是基于DOM 轉為 canvas，但并不是真正的瀏覽器截圖，都會存在一些共性問題。
3.1.1 字體樣式
如下圖所示，當前設備生效的是特殊字體，那么生成海報圖得到的有可能是特殊字體，出現與設計不符，不同用戶生成的海報圖效果不一致的情況。
如何規避這個問題呢？復制DOM并隱藏，對復制的DOM嵌入網絡字體包，保證設計效果。如果是固定文案，也可以采用嵌入圖片的方式。
3.1.2 排版
排版常遇到的問題是文本換行、超長字符打點，通常也會疊加系統字號大小、頁面縮放一起出現。
問題1: 文本換行打點怎么辦？
- 第三方庫中一般會有文本換行相關的處理：
類似html-to-canvas它的處理基于"CanvasRenderingContext2D.measureText()"，在繪制時測量每個字符的寬度，進行渲染位置的更新。基于這個處理方案，超長字符打點的問題是很難解決的。
而dom-to-canvas是基于svg轉圖片的方式，天然的具有文本排版處理的能力，這也是這個庫的優勢所在。
問題2: 那如果疊加頁面縮放呢？
一般h5都具有頁面縮放適配的能力，復制DOM也會繼承該處理，不會有太大的影響。
問題3: 如果頁面有設置大字號模式，DOM在不同字號大小下展示樣式有區別，但是需要導出圖片樣式保持一致呢？
那么就需要在復制DOM時，針對字號大小進行逆向處理，比如系統字體將字號放大1.25倍，在該場景下，復制DOM時就需要對字號進行縮小1.25倍。
3.1.3 適配
深色模式適配，分為兩種：
- 一種是系統級別的反色：系統級別的反色不會侵入到DOM，復制的DOM仍然與淺色模式下一致，導出的圖片也不會受到影響。
- 一種是自定義樣式的反色：自定義的反色對DOM樣式有侵入，復制DOM及其樣式，導出的圖片可能受影響，如下圖所示。只需要在復制DOM時將侵入的樣式或者控制深色模式的判斷條件去除即可。
兼容性適配，與canvas和foreignObject的兼容性相關，一般來說，不建議在Android低版本中使用，性能較差。
3.2 跨域問題
只要使用canvas繪制圖片，必然繞不過的就是跨域的問題，解決跨域問題有以下幾種思路：
- 代理服務器：通過配置服務器代理，將原本跨域的圖片請求轉為同域的圖片請求。從根源上解決跨域問題。針對圖片來源單一可控的場景、具備代理配置的能力的業務場景，建議采用該方案。
- 解決資源跨域：前提需要有權限訪問被請求的跨域服務器，可以通過設置服務器上的 CORS頭信息“Access-Control-Allow-Origin: * 或者特定域名”來實現，然后再解決資源的跨域問題。下面就聚焦這個場景，展開介紹下：
3.2.1 crossOrigin
在請求圖片時，需要增加屬性 img.crossOrigin = 'anonymous' ，告知跨域服務器，本次請求可以匿名訪問，不需要提供憑證。代碼示例如下圖所示：
設置這個就可以一勞永逸了嗎，并不是，還可能出現圖片緩存引起的請求跨域問題：在同一個頁面中，如果canvas需要繪制的圖片已經加載過了，瀏覽器會默認緩存下來，當canvas使用這張圖片時，瀏覽器會直接返回緩存的圖片。這時被緩存后的圖片就不展示CORS請求響應頭攜帶Access-Control-Allow-Origin的要求了，就會導致報錯。
解決方案最簡單的是給跨域請求追加時間戳，但這個方案會造成資源重復請求，也可能會有緩存擊穿的風險。
3.2.2 ajax+Blob/base64
通過額外發一次請求，將圖片轉為blob或者直接用base64的圖片格式，避免單張圖片頻繁請求。但如果涉及到的圖片比較多，也會帶來內存壓力問題，需要注意資源及時釋放。代碼示例如下圖所示：
3.3 生成性能
- 控制復制DOM的數量 原因：海報圖的生成耗時與復制dom的數量成正比。
- 如果采用的是iframe啟用的方式，減少iframe啟動次數。
- 一般組件庫是基于一個DOM生成一張海報圖，如果一次需要生成多張海報圖，可以合并DOM，啟用一次iframe，批量生成多張圖片。
- 分割操作，將文本相關耗時的操作前置，最后簡單的圖片+圖片的合并，使用canvas原生繪制，也是一種提升性能的方案。
四、小程序常見問題
4.1 元素繪制
不論是使用哪種方案，在小程序繪制海報圖時，需要提前設定好繪制的尺寸，甚至wxml-to-canvas要求為每個元素設置固定的寬度和高度，否則會出現布局錯誤。所以自適應高度在小程序端是不存在的，對于排版樣式就進行了初步限定。
同時，元素之間是存在層級關系的，與書寫的結構強關聯，這個要尤為注意。
對于元素及其樣式的支持是有限的，不同庫的支持程度也是不一致的，可根據業務進行選擇，這里簡單舉例對比下：
4.2 存儲問題
以下是wxml-to-canvas的源碼，在繪制圖片時，往往是繪制網絡圖片，需要從遠程拉取圖片，轉為本地臨時文件存儲【wx.downloadFile】，canvas繪制取臨時文件地址【tempFilePath】，然后進行繪制。保存圖片時再將canvas導出為臨時文件【wx.canvasToTempFilePath】。
若在小程序內觸發保存圖片到本地【wx.saveImageToPhotosAlbum】，需要進行權限校驗，這部分需要業務自行處理，如下所示。
如果選擇使用Painter庫繪制海報圖，且為了提升性能開啟了LRU存儲機制，這時就要關注緩存文件的有效性，官方也在小程序 LRU 存儲設計中進行了重點講解。
4.3 生成性能
研究過Painter源碼的同學可能關注到在canvas導出圖片的函數中，存在一個300ms的延遲，這個是為什么呢？300ms這個延遲可以去掉嗎？
答案是：這個邏輯下不可以省略！否則可能出現圖片缺失的問題。
Painter提供了canvas2d 接口和canvas舊接口兩套邏輯，而延遲300ms出現在舊接口邏輯體系中。這是因為舊接口使用的是downloadFile將網絡圖片緩存到本地后再進行drawImage，而整個繪制-導出過程中沒有監聽圖片加載完成的步驟，因此有概率出現圖片未加載完成就直接繪制的情況，進而出現內容缺失。雖然加入了定時器延長時間，但不同的機器不同的圖片繪制時間不同，設定單一的延遲等待并不能從根本上解決問題，反而影響生成圖片的性能。
相應的，在canvas2d的體系中則可以通過 Canvas.createImage 創建圖片對象，并監聽圖片的load事件，在回調之后執行ctx.drawImage繪制到canvas中，這樣就可以有效的解決上述問題。
針對這種場景，如果有其他比較好的解決方案，歡迎讀者在評論區留言。
ps: 微信官方正在推出Skyline/snapshot的截圖組件，也可以實現wxml/wxss導出圖片的功能，詳見微信小程序Skyline /snapshot
五、思考總結
本文主要聚焦前端生成海報圖的技術選型，不同選型可能出現的問題及其解決思路。期望通過本篇文章，能夠讓讀者在接收到相關需求時，對于一些容易踩坑的點做好前期評估。如果當前正在開發相關的需求，遇到相似的問題能夠提供一些解決思路。
同時如果大家有更好的解決方案，歡迎在評論區留言。
當然，隨著AI技術的發展，生成海報圖可能不再需要通過代碼邏輯實現。可以通過數據模型訓練，更加智能化的快速生成營銷海報圖，那么以上的問題將不再是問題。我們也將持續關注在ToC業務中相關的實現方案，與大家一起探討。
參考連接：
