不知道是什么時候？也許是春節(jié)期間？小程序的繪圖api默默新增了兩個接口：

官方?jīng)]有發(fā)文說明，而是偷偷放在開發(fā)文檔里，程序員同學(xué)真調(diào)皮， 這兩個在花叔看來相當(dāng)實(shí)用的功能，卻發(fā)布得這么低調(diào)， 接下來從不同角度說說這是什么。

一.屏顯原理

在介紹這兩個接口前，需要介紹顯示屏顯示圖片的基礎(chǔ)邏輯，顯示器屏幕要展現(xiàn)一張圖片，會用許許多多像素點(diǎn)并按照矩陣的方式去排列，把某個圖片放大到不能再放大，就會發(fā)現(xiàn)這些像素點(diǎn)具備不同的顏色和透明度，計算機(jī)用三原色加透明度去記錄這些信息。

例如我們常見的紅色，計算機(jī)可以通過以下方式記錄數(shù)據(jù)rgba（255,0,0,1）

二.小程序接口邏輯

這兩個接口相當(dāng)于提供像素點(diǎn)信息的讀寫操作，通過 wx.canvasGetImageData獲取特定像素點(diǎn)的位置以及rgba值，然后基于這些數(shù)據(jù)，經(jīng)過加工后又可以經(jīng)過wx.canvasPutImageData把新的像素點(diǎn)填充回去。

三.實(shí)際案例應(yīng)用場景？

顯而易見，圖片濾鏡功能特別合適。然而，大伙去小程序里搜索一下“濾鏡”，

你會發(fā)現(xiàn)很多類似的圖片濾鏡小程序，那么有同學(xué)就疑惑了，他們那么快就用上了這兩個接口么？

未必吧，因?yàn)樵谶@個接口出來前能通過另一種方式來實(shí)現(xiàn)濾鏡功能，這種老方式是先把圖片上傳到一個遠(yuǎn)程服務(wù)器上，然后服務(wù)器通過后臺腳本的圖形處理庫來對圖片進(jìn)行像素點(diǎn)數(shù)據(jù)修改（比如php的gd圖形庫），然后再把處理好的圖片存在服務(wù)器上，之后小程序通過download file的接口去下載。

這種方式把像素處理的邏輯交給后臺服務(wù)器，而現(xiàn)在有了文章開頭提到的兩個新接口后，可以把這部分處理邏輯交給小程序前端。

四.為啥呢？

把沉重的處理邏輯都交給遠(yuǎn)程服務(wù)器做，首先圖片需要傳來傳去，速度慢是必然的了，而且不大穩(wěn)定；再有就是像素級處理邏輯交給后臺服務(wù)器做，后臺服務(wù)器的運(yùn)行壓力會很大。

但換成上述提到的小程序接口實(shí)現(xiàn)方式就不一樣了。

即使算法信息存在服務(wù)器，因?yàn)樗惴ū旧頂?shù)據(jù)量不大，傳遞給用戶各自的手機(jī)時所耗時間成本也不高，自然速度就會快；然后像素點(diǎn)的邏輯運(yùn)算壓力分?jǐn)偨o各個用戶的手機(jī)，那自然服務(wù)器就不用承載過多的運(yùn)算負(fù)荷。

如果算法不做強(qiáng)硬的加密，還能直接存儲在小程序前端，這樣連跟服務(wù)器的交互都免了，體驗(yàn)會非?？臁?/p>

所以，這接口在極大限度地降低開發(fā)者運(yùn)營成本（服務(wù)器圖形計算很耗資源）和開發(fā)門檻的同時，能使得前端交互體驗(yàn)更好。

這算是填補(bǔ)了小程序?qū)D像分析的缺口，未來一定還有更多的應(yīng)用場景，想象一下AI圖像分析和OCR文本分析都能直接在小程序的前端上做時，作為前端開發(fā)的同學(xué)應(yīng)該會有點(diǎn)興奮。

最后花叔在想...小程序現(xiàn)在是已經(jīng)做到了圖片的像素點(diǎn)分析和處理，那么視頻幀的像素點(diǎn)分析和處理應(yīng)該也快了吧？

然后....AR滿足條件了...

還是挺期待的。

思維導(dǎo)圖高級版小程序?qū)で蠊娞柦壎?，APPID為：  wx368bd706303f88b6 ，公眾號可在mp后臺直接進(jìn)行綁定，花叔會第一時間確認(rèn)。

本文來自花叔的MinProgram公眾號

不用問，可隨意轉(zhuǎn)載