整合營銷服務(wù)商
電腦端+手機(jī)端+微信端=數(shù)據(jù)同步管理
免費(fèi)咨詢熱線：
電腦端+手機(jī)端+微信端=數(shù)據(jù)同步管理
免費(fèi)咨詢熱線：
狐友作為搜狐的一款社交產(chǎn)品，在流量傳播上有著旺盛的需求點(diǎn)。而在流量傳播所需的眾多載體之中，海報(bào)圖片以其簡單的分享形式、可定制的視覺體驗(yàn)、自帶二維碼識別導(dǎo)流等特點(diǎn)，成為了社交產(chǎn)品高頻必備的流量載體。
作為狐友的前端開發(fā)，生成海報(bào)圖片就成為了我們工作中持續(xù)不斷的一個(gè)重要需求點(diǎn)。以下是狐友目前的產(chǎn)品前端服務(wù)矩陣和海報(bào)圖片的產(chǎn)品形式。
圖 1 狐友產(chǎn)品前端服務(wù)矩陣和海報(bào)圖片的產(chǎn)品形式
從上圖1可以看到，生成海報(bào)圖片對于狐友產(chǎn)品矩陣來說是一個(gè)高頻強(qiáng)需求。海報(bào)圖片作為分享載體，對于各平臺的分享流程對接也非常暢通和直觀，例如不同于小程序卡片分享只能拘泥于微信平臺，網(wǎng)頁分享的鏈接形式不夠直觀。
而在海報(bào)圖片這個(gè)重要環(huán)節(jié)，長期的主要技術(shù)手段一直是通過各客戶端開發(fā)在本地設(shè)備上進(jìn)行繪制，但這種方案存在如下的劣勢困擾著我們：
為了解決以上問題，我們開始著手調(diào)研并實(shí)踐落地了一套全新的海報(bào)圖片統(tǒng)一服務(wù)，命名為hy-ssr-img。
圖 2 狐友大前端海報(bào)生成各端開發(fā)狀態(tài)
海報(bào)圖片統(tǒng)一服務(wù)是一套基于Puppeteer的Node.js后端服務(wù)端（SSR）渲染頁面并截圖生成海報(bào)圖片的服務(wù)，這一服務(wù)解決了原有海報(bào)圖片生成的三大問題：
圖 3 海報(bào)圖片統(tǒng)一服務(wù)各端復(fù)用
那么，海報(bào)圖片統(tǒng)一服務(wù)是如何建立起來的呢？下面是從項(xiàng)目立項(xiàng)開始的具體設(shè)計(jì)方案。
首先，我們調(diào)研了業(yè)界現(xiàn)有的圖片渲染方案，如下表。通過下表的調(diào)研總結(jié)可以看出各個(gè)方案各有優(yōu)劣勢。由于復(fù)用提效是重要需求點(diǎn)，我們把方案鎖定了服務(wù)端渲染方向上，即入選方案為：
在對比兩種方案，以及參考相關(guān)業(yè)務(wù)實(shí)踐后，我們最終選用了最常見的【Node.js截圖方案】。因?yàn)榉?wù)端圖層渲染選用的圖形庫在排版表達(dá)力上遠(yuǎn)不及HTML+CSS在瀏覽器上的表達(dá)力，而且系統(tǒng)預(yù)期的使用對象是前端開發(fā)人員，并不是產(chǎn)品和運(yùn)營，所以服務(wù)端圖層渲染方案的拖拽方式并不是必選項(xiàng)，反而由于拖拽渲染表達(dá)力的限制，對于實(shí)現(xiàn)一些排版復(fù)雜的圖片非常吃力。而Node.js截圖方案則沒有這方面的問題，前端開發(fā)只需要常規(guī)開發(fā)頁面即可，然后交給Puppeteer渲染后進(jìn)行截圖形成最終用戶看到的海報(bào)圖片。
表 1 項(xiàng)目選型方案對比
在確定了【Node.js截圖方案】之后，我們對項(xiàng)目整體架構(gòu)流程進(jìn)行了設(shè)計(jì)，首先由于我們的應(yīng)用的后端Java接口服務(wù)已經(jīng)非常成熟，針對參數(shù)的合法性校驗(yàn)及加簽解簽等防護(hù)措施都已建立，所以我們在開發(fā)Node.js服務(wù)時(shí)就沒有必要再造輪子，那么怎么把這些基礎(chǔ)接口功能和Node.js服務(wù)聯(lián)系起來呢？我們決定把Node.js服務(wù)放到內(nèi)網(wǎng)，通過只允許后端服務(wù)直接訪問的方式來達(dá)到這一目的，這樣后端接口層就像一個(gè)盾牌，擋在用戶和Node.js服務(wù)之間，而我們就可以專注實(shí)現(xiàn)Node.js的截圖功能了。整體方案流程如下圖4：
圖 4 Node.js截圖方案整體流程方案
整體架構(gòu)流程方案確定后，我們就需要細(xì)化截圖相關(guān)的詳細(xì)流程方案。在經(jīng)過調(diào)研之后，我們發(fā)現(xiàn)常見的截圖開源方案在我們的使用場景中還有很多需要優(yōu)化的點(diǎn)和不滿足需求的部分，因此我們決定自研開發(fā)【僅首屏SSR渲染】方案。針對項(xiàng)目特點(diǎn)，每個(gè)海報(bào)圖片只有一張，所以不存在首屏渲染過后還要渲染第二頁的場景，因此該方案只包含首屏字符串渲染即可，不需要帶有常見 SSR 的客戶端激活渲染的打包構(gòu)建及執(zhí)行流程。 去掉常見SSR方案中的非首屏渲染邏輯后，頁面就只包含了首屏必要的渲染代碼（HTML + CSS），去除一切不需要的環(huán)節(jié)（JS執(zhí)行激活），保證頁面給到 Puppeteer渲染時(shí)是最簡化的狀態(tài)，盡可能減少網(wǎng)絡(luò)I/O和本地磁盤I/O，只包含單純的渲染過程，以加速渲染速度。以下是常見方案和自研方案的對比。
最常見的截圖方案是通過請求網(wǎng)頁地址，渲染后截圖，如圖5。
圖 5 Node.js截圖詳細(xì)流程常見方案
這種方案不管是CSR（客戶端渲染）方式，還是SSR（服務(wù)端渲染）方式，都還是有優(yōu)化空間。我們可以發(fā)現(xiàn)，Puppeteer請求網(wǎng)頁的網(wǎng)絡(luò)消耗是可以被節(jié)省下來的，如果我們直接使用在本地生成好的HTML和CSS，則請求網(wǎng)頁并下載所用的時(shí)間就可以節(jié)省下來，獲得更快的截圖速度。
另外頁面的動態(tài)渲染通過SSR來進(jìn)行，這樣完全不需要客戶端JS的存在，直接還可以省去加載客戶端JS的時(shí)間，獲得更優(yōu)的渲染速度，這種優(yōu)化后的Node.js截圖詳細(xì)流程方案如圖6所示。
圖 6 優(yōu)化后的Node.js截圖詳細(xì)流程方案
該方案還有技術(shù)細(xì)節(jié)需要設(shè)計(jì)，即如何完成SSR渲染首屏的工作，由于我們的技術(shù)棧是Vue，所以選用vue-server-renderer為基礎(chǔ)庫來完成這一過程，如圖7。
圖 7 僅首屏SSR渲染方案技術(shù)流程
整體架構(gòu)流程方案確定之后，我們就要進(jìn)行更細(xì)化的業(yè)務(wù)技術(shù)流程設(shè)計(jì)，這里有很多細(xì)節(jié)需要考慮：
為了解決這些問題，我們設(shè)計(jì)了如下的流程，如圖8。
圖 8 Node.js截圖服務(wù)業(yè)務(wù)技術(shù)流程
可以看到整個(gè)流程設(shè)計(jì)由接口同步請求和截圖異步任務(wù)兩大塊組成。我們把Node.js截圖服務(wù)當(dāng)做一個(gè)純渲染圖片的服務(wù)，用戶發(fā)起請求給后端服務(wù)時(shí)會攜帶渲染頁面所需要的動態(tài)參數(shù)，后端服務(wù)則負(fù)責(zé)參數(shù)校驗(yàn)等工作，并且下發(fā)給用戶一個(gè)異步任務(wù)ID。然后后端服務(wù)會請求截圖服務(wù)，截圖服務(wù)收到請求后并不會立刻截圖，而是直接返回后端服務(wù)，并開啟異步任務(wù)去進(jìn)行耗時(shí)的截圖服務(wù)，這樣就可以防止長鏈接堆積造成服務(wù)不可用的情況發(fā)生。之前下發(fā)給用戶側(cè)的異步任務(wù)ID就是異步截圖任務(wù)完成后通知后端服務(wù)的憑證，這樣當(dāng)截圖服務(wù)完成后就可以通知后端服務(wù)截圖完成狀態(tài)（截圖成功或者失敗），而用戶側(cè)則可通過輪詢后端服務(wù)接口得知截圖是否完成并使用海報(bào)圖片了，當(dāng)然可以設(shè)置一個(gè)超時(shí)時(shí)間來完成整個(gè)截圖服務(wù)的交互閉環(huán)。
對于海報(bào)圖片的緩存層也是要考慮的，因?yàn)楹芏鄨鼍跋掠脩粽埱蟮暮?bào)圖片是一模一樣的，比如我們的熱榜海報(bào)會在固定時(shí)間生成一次，那么緩存層可以有效緩解截圖耗時(shí)操作，并且為預(yù)生成海報(bào)圖片提供了基礎(chǔ)。比如我們會在特定時(shí)間通過代碼自動預(yù)渲染一批海報(bào)，當(dāng)?shù)谝粋€(gè)用戶來訪問時(shí)就不需要等待耗時(shí)的截圖服務(wù)，直接返回渲染好的海報(bào)圖片即可。那么命中緩存的條件是什么呢？對于長的一模一樣的海報(bào)圖片當(dāng)然希望只生成一次后都走緩存層。我們的設(shè)計(jì)中決定“圖片長相”的因素有兩個(gè)：
1．海報(bào)地址：對應(yīng)不同的海報(bào)樣式
2．海報(bào)參數(shù)：對應(yīng)同一個(gè)海報(bào)樣式中的不同數(shù)據(jù)
所以，我們通過hash(“海報(bào)地址”+“海報(bào)參數(shù)”)的方式得到緩存命中的key，以此來控制命中緩存。另外截圖服務(wù)生成海報(bào)圖片后會直接上傳到CDN進(jìn)行存儲，用戶側(cè)加載海報(bào)圖片的速度和穩(wěn)定性也得到了相應(yīng)的保障。
在業(yè)務(wù)技術(shù)流程方案確定后，就需要為此搭建一套工程化開發(fā)環(huán)境，來支持項(xiàng)目業(yè)務(wù)的具體開發(fā)。我們基于公司現(xiàn)有基礎(chǔ)設(shè)施以及技術(shù)棧，確定了以下主要技術(shù)選型：
如圖9，展示了通過以上技術(shù)棧及基礎(chǔ)設(shè)施組建的整個(gè)工程化方案。
圖 9 Node.js截圖服務(wù)工程化方案
這里需要說明是，一個(gè)海報(bào)圖片對應(yīng)一個(gè)頁面，一個(gè)頁面會有兩個(gè)入口文件：一個(gè)CSR（客戶端渲染）用于開發(fā)頁面時(shí)使用，一個(gè)SSR（服務(wù)端渲染）用于截圖時(shí)Puppeteer渲染頁面使用。這么設(shè)計(jì)的原因是，CSR渲染使用webpack-dev-server是現(xiàn)成的開源方案，對于開發(fā)時(shí)熱更新等支持不需要自定義開發(fā)，開箱即用，如果開發(fā)時(shí)也使用SSR進(jìn)行就需要進(jìn)行針對性的改造，由于開發(fā)體驗(yàn)上并沒有區(qū)別，我們就選用了更高效地搭建方式。而截圖時(shí)頁面渲染方式就是上文提到的【僅首屏 SSR 渲染】。
從用戶發(fā)起請求到海報(bào)圖片返回，這整個(gè)過程的耗時(shí)需要進(jìn)行“壓榨”，以獲得更好的用戶體驗(yàn)。以下是我們在開發(fā)過程中實(shí)踐和驗(yàn)證的相關(guān)重點(diǎn)優(yōu)化和部分效果收益。從第一版基礎(chǔ)開發(fā)到最后優(yōu)化完成的版本，截圖服務(wù)總用時(shí)從1300ms+降低到了600ms+（注：測試數(shù)據(jù)均取相同開發(fā)機(jī)10次執(zhí)行結(jié)果的平均值，渲染相同的海報(bào)圖片，圖片為超長圖且內(nèi)容豐富，長寬為：4967×750）。表2為各關(guān)鍵優(yōu)化點(diǎn)明細(xì)。
表 2 項(xiàng)目關(guān)鍵優(yōu)化實(shí)踐
為了方便使用海報(bào)圖片的開發(fā)人員，我們還配套開發(fā)了海報(bào)生成系統(tǒng)在線文檔。開發(fā)人員可以通過該系統(tǒng)查看現(xiàn)有的海報(bào)圖片以及相關(guān)參數(shù)字段，并可以通過右方的編輯器更改字段的值并實(shí)時(shí)得到新的渲染圖進(jìn)行預(yù)覽和下載。如圖10，開發(fā)人員可以在這個(gè)playground里進(jìn)行所見即所得的預(yù)覽及操作。
圖 10 海報(bào)在線文檔預(yù)覽系統(tǒng)
海報(bào)圖片服務(wù)作為一個(gè)后端服務(wù)，日志采集分析和監(jiān)控是必不可少的，我們可以通過日志得到以下信息：
所以，我們封裝了3種log日志用于海報(bào)圖片服務(wù)：
日志處理完成后，我們接入了公司現(xiàn)有日志基建服務(wù)來完成后續(xù)的日志采集、存儲和分析等功能，如圖11所示，通過這一套日志流程，我們就可以更加放心地上線并時(shí)刻關(guān)注我們服務(wù)的運(yùn)行情況，輕松做到快速排查和分析問題。
圖 11 海報(bào)系統(tǒng)日志服務(wù)
海報(bào)生成是一個(gè)耗時(shí)任務(wù)，其繪制速度依賴于服務(wù)器的CPU和內(nèi)存。經(jīng)過線上數(shù)據(jù)評估，截圖服務(wù)qps最大支持60即可，經(jīng)使用JMeter并發(fā)測試：
所以為了保證圖片的生成速度和穩(wěn)定性，使并發(fā)量少的時(shí)候圖片生成速度盡可能快，并發(fā)量大的時(shí)候圖片生成速度在可接受時(shí)間內(nèi)，采用了多實(shí)例加多進(jìn)程的部署方式，如圖12，項(xiàng)目部署于DomeOS平臺，部署了5臺 （CPU4核 + 內(nèi)存 6G） 實(shí)例，每個(gè)實(shí)例通過pm2啟動4個(gè)進(jìn)程。通過負(fù)載均衡可以使請求平均打到每個(gè)實(shí)例的每個(gè)進(jìn)程上，讓并發(fā)少的時(shí)候最快的生成圖片，并發(fā)大的時(shí)候充分利用所有實(shí)例，加快整體生成圖片時(shí)間。生成5000像素的圖片，當(dāng)并發(fā)數(shù)小于5時(shí)，圖片可以在1s左右返回，當(dāng)并發(fā)數(shù)為20，圖片可以在3s左右返回，當(dāng)并發(fā)數(shù)為60時(shí)，圖片可以在8s之內(nèi)返回。
圖 12 海報(bào)系統(tǒng)部署方案
截止到2023年初，海報(bào)圖片服務(wù)已上線海報(bào)10+個(gè)。每個(gè)海報(bào)只需開發(fā)1遍就可供給H5、小程序、Android和iOS共4端進(jìn)行使用。每天平均生成海報(bào)圖片6000+，每張海報(bào)圖片平均生成時(shí)間400ms左右，支持超長圖可達(dá)10000+像素。
隨著項(xiàng)目迭代，海報(bào)服務(wù)未來可能有更大的需求訴求，下面列出海報(bào)服務(wù)未來進(jìn)化的一些展望：
1、賦能外部開發(fā)人員
目前項(xiàng)目是以普通項(xiàng)目的開發(fā)模式進(jìn)行研發(fā)，如果提供給非內(nèi)部研發(fā)人員使用則有很多流程和規(guī)范上的問題難以解決。未來可以支持渲染遠(yuǎn)程組件，通過遠(yuǎn)程組件的方式下發(fā)給外部研發(fā)進(jìn)行開發(fā)，以此隔絕海報(bào)服務(wù)核心邏輯和業(yè)務(wù)方邏輯，使得業(yè)務(wù)方只需關(guān)心業(yè)務(wù)，也防止業(yè)務(wù)方無意間可能影響到海報(bào)核心邏輯。此外，在整個(gè)過程中還可以增加審核遠(yuǎn)程組件等項(xiàng)目管理能力。
2、賦能非研發(fā)人員
為了海報(bào)圖片渲染極具靈活性，我們把開發(fā)人員作為首要滿足對象。未來除了開發(fā)人員可以開發(fā)海報(bào)頁面，同時(shí)可以支持非研發(fā)人員通過拖拽編輯等低代碼方式完成海報(bào)圖片的生產(chǎn)，這樣針對簡單海報(bào)圖片的場景，運(yùn)營、產(chǎn)品等非研發(fā)人員也可以進(jìn)行海報(bào)圖片的制作，進(jìn)一步提高生產(chǎn)效能。
作者:狐友FE
來源:微信公眾號:搜狐技術(shù)產(chǎn)品
出處:https://mp.weixin.qq.com/s/D1N9qxHYGRBUlCGePvqj3w
之前做的 WordPress 插件，更多涉及的是管理功能，比如用戶管理，分類管理這些插件等等，這些主要這些功能比較純粹，然后 WPJAM Basic 已經(jīng)實(shí)現(xiàn)了 WordPress 后臺的各種底層類庫和交互組件，只要功能需求就能快速做好。
但是最近在更新 Autumn Pro 5.0 的功能的時(shí)候，也開始有所涉獵 WordPress 的前端開發(fā)。 我就把一些常用的前端功能整理成統(tǒng)一的插件，一是方便日后更新，也是方便其他主題的集成。
今天就來介紹這批插件中的第一個(gè)，一個(gè)全能的 WordPress 彈窗插件，也可以叫模態(tài)框插件，目前已經(jīng)實(shí)現(xiàn)了海報(bào) / 打賞 / 分享 / 搜索彈窗，接下來還會實(shí)現(xiàn)登錄 / 公告等彈窗，也提供彈窗接口，只要簡單幾行代碼也可以實(shí)現(xiàn)你自己的彈窗。
插件激活之后，在后臺「WPJAM」菜單下就又會有「頁面彈窗」的子菜單，當(dāng)然如果已經(jīng)使用 Autumn Pro 主題，這個(gè)在菜單在「Autumn」菜單下，總之不在「WPJAM」菜單，就是在主題設(shè)置菜單下，點(diǎn)擊進(jìn)去就進(jìn)入彈窗的設(shè)置頁面了：
如上圖所示，文章海報(bào)彈窗，需要你設(shè)置 logo 和標(biāo)語，然后選擇自動插入（Autumn Pro 主題已經(jīng)通過代碼插入，上面的自動插入選項(xiàng)也會沒有），就可以在頁面上顯示「生成海報(bào)」按鈕：
當(dāng)然其他主題你也可以自己通過 wpjam_get_poster_button($args=[]) 來手工插入，這里 $args 的默認(rèn)值是：['title'=>'生成海報(bào)', 'class'=>'poster-button', 'icon'=>'ri-image-line']，你也可以自定義修改它：
總之最后在頁面上出現(xiàn)「生成海報(bào)」按鈕，點(diǎn)擊它之后就會生成海報(bào)彈窗：
樣式還是可以的，當(dāng)然你也自己改一下 CSS，去調(diào)整海報(bào)的樣式，這里再多說兩句，海報(bào)是通過 HTML2Canvas 生成圖片的，這樣做好處，就是無需在服務(wù)端去生成海報(bào)圖片了，能夠顯著降低服務(wù)端的消耗，同時(shí)海報(bào)上的二維碼也是使用 jQuery.qrcode 前端 jQuery 插件實(shí)現(xiàn)，也不是服務(wù)端生成的圖片，更進(jìn)一步降低服務(wù)器的消耗，本來這些功能就應(yīng)該在前端實(shí)現(xiàn)的嘛，現(xiàn)在的瀏覽器能力也是越來越強(qiáng)了。
我們繼續(xù)看會最上面的設(shè)置圖，文章打賞彈窗需要設(shè)置「打賞標(biāo)題 / 標(biāo)語和收款碼」這三個(gè)選項(xiàng)，之后就會出現(xiàn)「打賞作者」的按鈕：
同樣它的自定義調(diào)用函數(shù)是wpjam_get_donate_button($args=[])，$args的默認(rèn)值是：['title'=>'打賞作者', 'class'=>'donate-button', 'icon'=>'ri-money-cny-circle-line']。
點(diǎn)擊之后的彈窗如下：
文章分享彈窗沒有設(shè)置選項(xiàng)，它的自定義調(diào)用函數(shù)是 wpjam_get_share_button($args=[])，$args 的默認(rèn)值是：['title'=>'分享', 'class'=>'share-button', 'icon'=>'ri-share-forward-2-fill']。
點(diǎn)擊生成的分享按鈕之后彈窗如下：
最后一個(gè)是文章搜索彈窗，通過它可以在后臺設(shè)置常用搜索詞：
搜索按鈕不能自動插入，它只能通過 wpjam_get_search_button($args=[]) 函數(shù)手動插入，$args 的默認(rèn)值是：['title'=>'', 'class'=>'search-button', 'icon'=>'ri-search-line']。
比如 Autumn 的搜索按鈕就如下：
點(diǎn)擊它之后就可以進(jìn)行文章搜索：
除了顯示搜索框和后臺設(shè)置的熱門搜索之外，還顯示當(dāng)前用戶的搜索歷史，是不是有種大站才有搜索的感覺，哈哈。
日常的工作中（比如微信小程序），我們經(jīng)常有這樣的需求，就是需要使用程序生成推廣海報(bào)，然后海報(bào)里要包含指定的二維碼，這樣用戶分享出去別人掃碼之后就可以確定用戶推薦關(guān)系。
單獨(dú)生成海報(bào)背景或者單獨(dú)生成二維碼通常還算比較簡單，但如果要將兩者結(jié)合到一起那還是需要花一點(diǎn)心思的。
那現(xiàn)在怎么解決呢？如何使用PHP在服務(wù)器生成推廣海報(bào)呢？對的，使用PHP中的GD庫。具體過程請往下看。
1、海報(bào)背景圖。背景圖一般存服務(wù)器，程序本地讀取；
2、推廣二維碼。可以是二維碼圖片鏈接，也可以是字符串圖像流。如果自己生成二維碼，詳見phpqrcode官網(wǎng)，地址：https://sourceforge.net/projects/phpqrcode。
3、開啟PHP的GD擴(kuò)展
首先熟悉一下幾個(gè)關(guān)鍵的PHP函數(shù)：
1、getimagesize：取得圖像大小。getimagesize() 函數(shù)將測定任何 GIF，JPG，PNG，SWF，SWC，PSD，TIFF，BMP，IFF，JP2，JPX，JB2，JPC，XBM或 WBMP 圖像文件的大小并返回圖像的尺寸以及文件類型和一個(gè)可以用于普通 HTML 文件中 IMG 標(biāo)記中的 height/width 文本字符串。如果不能訪問 filename 指定的圖像或者其不是有效的圖像，getimagesize() 將返回 FALSE 并產(chǎn)生一條 E_WARNING級的錯(cuò)誤。
2、image_type_to_extension：取得圖像類型的文件后綴。
3、imagesx：取得圖像寬度。
4、imagesy：取得圖像高度。
5、imagecreatetruecolor：新建一個(gè)真彩色圖像。imagecreatetruecolor() 返回一個(gè)圖像標(biāo)識符，代表了一幅大小為 x_size 和 y_size 的黑色圖像。是否定義了本函數(shù)取決于 PHP 和 GD 的版本。從 PHP 4.0.6 到 4.1.x 只要加載了 GD 模塊本函數(shù)一直存在，但是在沒有安裝 GD2 的時(shí)候調(diào)用，PHP 將發(fā)出致命錯(cuò)誤并退出。在 PHP 4.2.x 中此行為改為發(fā)出警告而不是錯(cuò)誤。其它版本只在安裝了正確的 GD 版本時(shí)定義了本函數(shù)。
6、imagecolordeallocate：取消圖像顏色的分配。
7、imagefill：區(qū)域填充。imagefill() 在 image 圖像的坐標(biāo) x，y（圖像左上角為 0, 0）處用 color 顏色執(zhí)行區(qū)域填充（即與 x, y 點(diǎn)顏色相同且相鄰的點(diǎn)都會被填充）。
8、imagecopyresampled：重采樣拷貝部分圖像并調(diào)整大小。imagecopyresampled() 將一幅圖像中的一塊正方形區(qū)域拷貝到另一個(gè)圖像中，平滑地插入像素值，因此，尤其是，減小了圖像的大小而仍然保持了極大的清晰度。
9、getimagesizefromstring：從字符串中獲取圖像尺寸信息。同 getimagesize() 函數(shù)。 區(qū)別是 getimagesizefromstring() 第一個(gè)參數(shù)是圖像數(shù)據(jù)的字符串表達(dá)，而不是文件名。
10、imagecopymerge：拷貝并合并圖像的一部分。
11、imagejpeg：輸出圖象到瀏覽器或文件。
12、imagedestroy：銷毀一圖像。
熟悉完了這十幾個(gè)核心方法后，我們就可以編碼了。核心代碼如下：
以上代碼是利用PHP生成推廣海報(bào)的主要部分，有了它我們就可以很容易的生成推廣海報(bào)了。
參考案例：
1、生成帶有二維碼的海報(bào)。
2、生成帶有圖像，昵稱和二維碼的海報(bào)。
從以上示例可以看出，只要我們定義好核心代碼之后，后面生成不同的推廣海報(bào)，只需要調(diào)整config配置參數(shù)即可。
*請認(rèn)真填寫需求信息，我們會在24小時(shí)內(nèi)與您取得聯(lián)系。
