根據(jù)返回?cái)?shù)據(jù)動(dòng)態(tài)生成分享是很常見的場景。比如在起點(diǎn)讀書小程序中,每本書都需要生成一個(gè)動(dòng)態(tài),包含:書名、作者、類別和當(dāng)前頁面小程序二維碼,這幾個(gè)內(nèi)容都是會(huì)動(dòng)態(tài)改變的。
那如何抽象化&高性能的實(shí)現(xiàn)這一類需求呢?方案對(duì)比,目前業(yè)界已經(jīng)有很多實(shí)現(xiàn)動(dòng)態(tài)的方案,主要分為兩種:客戶端實(shí)現(xiàn)和服務(wù)端實(shí)現(xiàn),下面根據(jù)我們的調(diào)研和實(shí)踐經(jīng)驗(yàn),分別介紹下這兩種實(shí)現(xiàn)方式和它們的優(yōu)缺點(diǎn)。
客戶端實(shí)現(xiàn)-html2canvas,實(shí)現(xiàn)過生成動(dòng)態(tài)功能的同學(xué)肯定對(duì) html2canvas 不會(huì)陌生,一個(gè)函數(shù)就能將 html 繪制到 canvas 中去,再通過canvas 的 toDataUrl 方法就能獲取到信息了。整體流程大致是這樣,但只要用過 html2canvas 的人肯定知道,這個(gè)過程并沒有這么絲滑。正如它的 readme 里說的那樣,它并不一定能百分之100 html 元素在網(wǎng)頁中的樣子。表現(xiàn)出來的問題有很多, 兼容性,在不同端上的表現(xiàn)不一致、一些屬性不支持。
服務(wù)端實(shí)現(xiàn):Puppeteer,既然 html2canvas 有這么多坑,那我們能不能放棄在 Canvas 中做渲染這個(gè)方案,而是直接把 html 在網(wǎng)頁中顯示出來,然后直接截個(gè)圖就好了。Puppeteer 就可以幫我們實(shí)現(xiàn)。Puppeteer 其實(shí)就是一個(gè)可以被代碼操控的 Chrome 瀏覽器,你可以通過 Puppeteer 的 api 來打開一個(gè) Chrome 的 Tab,渲染 Html,再截個(gè)圖。這樣我們就統(tǒng)一了的生成環(huán)境,解決了兼容性問題。
總結(jié)與展望,目前 Golang + Nodejs 方案,針對(duì)不那么復(fù)雜的動(dòng)態(tài),提高了生成需求的效率,節(jié)省開發(fā)時(shí)長,性能上也得到了保障。 |
 |
|