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