背景
周末在家呆著無聊刷小??的過程時河质,無意中被推薦了一個H5的營銷方案所吸引:利用電子印章結合H5頁面結合的方式冀惭,實現(xiàn)線上+線下的拓客引流震叙。形式如下圖所示。
雖然這種電子印章的形式不是第一次見到散休,但看到真的有人在專營這方面的營銷方案媒楼,著實激起了我的好奇心。雖然之前沒做過這方面的業(yè)務戚丸,但是作為偽資深の二次元划址,這個交互方式我熟啊! 這不就是Amiibo么,現(xiàn)在瀏覽器/微信對NFC都支持到這個程度了么限府?好奇心促使我開始著手探究視頻中的實現(xiàn)方案夺颤。
探索方案
【初探】NFC API
首先,我先查詢了下NFC API的MDN介紹:Web NFC API 允許通過輕量級 NFC 數(shù)據(jù)交換格式 (NDEF) 消息在 NFC 上交換數(shù)據(jù)谣殊。 部分瀏覽器支持,仍是一項實驗性的能力牺弄,文檔建議使用前查一下對應的瀏覽器兼容性表姻几。
看一下目前API支持的能力:
API | 功能 |
---|---|
NDEFMessage |
表示可以通過NDEFReader 對象從兼容標簽接收或發(fā)送到兼容標簽的 NDEF 消息的接口。消息由元數(shù)據(jù)和 NDEF 記錄組成势告。 |
NDEFReader (實驗性) |
支持從兼容的 NFC 標簽讀取和寫入消息的接口蛇捌。消息表示為NDEFMessage 對象。 |
NDEFRecord |
表示可以包含在 NDEF 消息中的 NDEF 記錄的接口咱台。 |
/** API 示例使用方式 讀寫案例 **/
async function readTag() {
if ("NDEFReader" in window) {
const ndef = new NDEFReader();
try {
await ndef.scan();
ndef.onreading = event => {
const decoder = new TextDecoder();
for (const record of event.message.records) {
consoleLog("Record type: " + record.recordType);
consoleLog("MIME type: " + record.mediaType);
consoleLog("=== data ===\n" + decoder.decode(record.data));
}
}
} catch(error) {
consoleLog(error);
}
} else {
consoleLog("Web NFC is not supported.");
}
}
async function writeTag() {
if ("NDEFReader" in window) {
const ndef = new NDEFReader();
try {
await ndef.write("What Web Can Do Today");
consoleLog("NDEF message written!");
} catch(error) {
consoleLog(error);
}
} else {
consoleLog("Web NFC is not supported.");
}
}
function consoleLog(data) {
var logElement = document.getElementById('log');
logElement.innerHTML += data + '\n';
}
案例參考 https://whatwebcando.today/nfc.html
络拌。同時,MDN 上還附帶著 Web NFC 的實現(xiàn)標準回溺〈好常看著這些能力實現(xiàn)一個觸碰蓋章的能力感覺綽綽有余啊。
不對遗遵,它是不是還讓我查看兼容性來著萍恕?
[圖片上傳失敗...(image-4bea68-1680960959238)]
[圖片上傳失敗...(image-ff02d4-1680960959238)]
看完之后,直呼好家伙车要! 這實驗性的范圍也太局限了基本只支持了Chrome 89之后 以及個別瀏覽器允粤。基本處于一個不能上生產的情況翼岁,這似乎和我的預期相距甚遠类垫,我陷入了短暫的思考。
補充一句琅坡,當然我也看了下微信對于近場通信的支持:支持 HCE(基于主機的卡模擬)模式悉患,即將安卓手機模擬成實體智能卡。 支持 NFC 讀寫榆俺,即手機作為讀卡器使用购撼。同樣是不符合對這一能力的預期的跪削。
【回首】WEB API:Multi-touch interaction
在首輪沒有想到解決方案的情況下,我查看了下營銷團隊的官網(wǎng)迂求,也就是這一看讓這個探究過程出現(xiàn)了轉機碾盐。我發(fā)現(xiàn)這個業(yè)務場景的適用范圍是:任何場景,微信揩局、App毫玖、網(wǎng)站都可以執(zhí)行。所以它應該是一個相對通用的方案凌盯,不會受到平臺付枫、兼容性等因素的影響。所以驰怎。阐滩。。會不會是县忌?同時記錄了多個觸摸點 或者 繪制了某個特殊圖形掂榔?
復習一下Touch的相關API:
API | 功能 |
---|---|
TouchEvent |
表示位于表面上的一個觸摸點的某個狀態(tài)發(fā)生改變時產生的事件。 |
Touch |
表示用戶與觸摸表面間的一個單獨的接觸點症杏。 |
TouchList |
表示一組 Touch装获,用于多點觸控的情況。 |
看起來似乎可行厉颤,無論是MDN Touch的介紹穴豫,還是 TouchList 的介紹,都證明記錄同時觸摸點是完全可行的逼友。又看了下 Touch Events # dom-touchlist-length實現(xiàn)確實可以拿到每個觸摸點的位置精肃,那么現(xiàn)在只需要判斷,繪制的點/形狀是否符合標準就可以了帜乞。
此時剛好看到一位前輩的文章肋杖,他也是通過Touch的相關能力實現(xiàn)的,詳細介紹了電子印章的實現(xiàn)挖函,以及向量對比時的一些方案状植。個人覺得很牛逼,我就不做無用功了怨喘,這里簡單摘錄一些他的過程此處附上他的github 津畸, (侵刪哈):
H5印章實體大概就是有一些圓點凸起的方塊,每個凸起的地方使用導電橡膠材料制作(類似電容筆)必怜,這樣平整放置在屏幕上時就能在屏幕上形成多個觸控點肉拓,模擬 手指多點觸控的交互。
在給用戶蓋印的過程中(采集新的點位信息)梳庆,會存在一些不確定性
- 因為需要通過手機屏幕采集觸摸點暖途,而不同型號的手機屏幕尺寸/分辨率都存在差異卑惜,同一個印章蓋上去,每次拿到的坐標數(shù)都有可能不同
- 每次蓋章時驻售,章的方向和手機的方向可能會有所不同
基于以上幾點露久,我們計算相似性的算法就要忽略點位整體的方向和絕對尺寸。也就是證相似而不是全等欺栗。
github文章后續(xù)使用 余弦相似性 和 差值相關性 的方法通過向量解決了 點 => 圖形
的相似問題毫痕,有興趣的朋友可以到上/下面的文章鏈接中詳細了解,我這里就不蹭方案了迟几。當然證明向量的相似的方案不完全固定消请,穩(wěn)定且效率高的方案可以由感興趣的朋友自行探索,本篇文章就不做多余擴展了类腮。同時也附上一些方案的鏈接拋磚引玉臊泰。
后來,我在營銷團隊的官網(wǎng)上也發(fā)現(xiàn)了多點觸碰的專利等字樣蚜枢,相關實現(xiàn)方案也就不言而喻了缸逃。
【終局】一點思考
寫到這,電子印章的技術實現(xiàn)就已經(jīng)基本結束祟偷。前端通過巧妙技術實現(xiàn)助力了更加豐富的營銷場景察滑,從而實現(xiàn)技術業(yè)務雙贏打厘⌒蕹Γ回顧此次探索的過程,其實是一次完整的輸入 => 校驗
的過程户盯,在不同場景下我們接觸過許多的輸入方式嵌施,無論是屏幕點擊、符箓繪制莽鸭、圖片識別 亦或是 言出法隨都能給用戶耳目一新的感覺吗伤。當然,也希望本篇文章的拋轉能夠給各位鐵子更多的實現(xiàn)思路與前端學習的動力硫眨。