最近，微信小程序 掃碼簽到工具 正式上線了。

回首過去一個(gè)月的歷程，是時(shí)候該停下來做個(gè)階段性的總結(jié)了，回顧得失，以便持續(xù)改進(jìn)。這篇文章，就總結(jié)一下過去跳過的那些坑吧。

這些坑大致可以歸為如下幾類：

• 小程序某些技術(shù)細(xì)節(jié)與常用技術(shù)存在不一致。文檔中雖有提及，如果不仔細(xì)看容易跳坑。

• 小程序的文檔太簡略，沒有注明支持哪些功能，哪些不支持，只有用了才知道。

• 小程序的bug。

列舉一下幾個(gè)比較典型的坑吧。  

小程序支持通過post獲取小程序碼（有點(diǎn)像菊花）。嘗試通過 wx.request 向微信服務(wù)器獲取 小程序碼 的圖片，結(jié)果發(fā)現(xiàn)返回的結(jié)果無法顯示。開始懷疑代碼有問題，調(diào)試之后，發(fā)現(xiàn)微信服務(wù)器返回的結(jié)果正確，而小程序會(huì)自動(dòng)把二進(jìn)制結(jié)果轉(zhuǎn)碼。更郁悶的是，這種轉(zhuǎn)碼丟失了文件內(nèi)容，并且轉(zhuǎn)換是不可逆的。

于是，我們改方案，把服務(wù)器當(dāng)中轉(zhuǎn)站，讓小程序使用 wx.downloadFile 從服務(wù)器下載圖片。在收到小程序下載圖片的請(qǐng)求之后，服務(wù)器直接和微信服務(wù)器獲取小程序碼的圖片，然后以附件的形式返回給小程序。

問題解決。

①掃碼簽到中用到了二維碼。

在開始的版本中，我們準(zhǔn)備在Canvas上直接繪制二維碼，接著使用 wx.canvasToTempImage 函數(shù)保存為image文件，然后通過Image組件加載。

經(jīng)過調(diào)試，一切順利。運(yùn)行的時(shí)候呢，發(fā)現(xiàn)有時(shí)候 在繪制完圖片之后，調(diào)用 wx.canvasToTempImage 函數(shù)失敗。這種情況在調(diào)試無法重現(xiàn)，運(yùn)行的時(shí)候偶爾出現(xiàn)，不穩(wěn)定。

仔細(xì)檢查了代碼，沒問題啊。Google之后，有網(wǎng)友提出了解決方案，在drawImage完成之后，最好等3秒鐘再調(diào)用 wx.canvasToTempImage ，以保證保存成功。 

② Canvas和Image都不支持Base64圖片，Image無法保存。

最初的方案中，我們自己生成二維碼，后來為了兼容微信的“掃一掃”功能，我們決定改用小程序碼。

開始，我們把Image的src設(shè)置為Base64格式，從服務(wù)器上通過request獲取圖片的Base64編碼。小程序開發(fā)工具和iPhone上面測(cè)試都沒有問題，唯獨(dú)Android手機(jī)上無法正常顯示圖片。哦，原來在Android上，Canvas和Image都不支持Base64圖片?？墒?..小程序開發(fā)文檔中并沒有這方面的說明啊。 

怎么解決Android手機(jī)上的這個(gè)問題呢？如果把Image改成URL形式呢，小程序無法保存圖片，以致即使是相同的圖片，每次都要從服務(wù)器獲取，這又加重了服務(wù)器的負(fù)擔(dān)。這樣吧，使用 wx.downloadFile 把文件下載到本地，然后再處理。 

上文提到，最初我們使用的簽到二維碼是自己生成的二維碼 (QRCode) ，正方形的那種。識(shí)別率高，缺點(diǎn)是不支持微信“掃一掃”。在使用過程中，我們發(fā)現(xiàn)，相當(dāng)數(shù)量的用戶看見二維碼，第一反應(yīng)會(huì)使用微信“掃一掃”去掃二維碼。為了滿足這個(gè)需求，那就把二維碼替換成微信的小程序碼（有點(diǎn)像菊花）吧。

可是，和方形二維碼相比，識(shí)別小程序碼的成功率非常低。小程序碼距離遠(yuǎn)點(diǎn)、稍微有些變形或方向沒有對(duì)正都可能造成識(shí)別失敗。一種典型的使用場景是：簽到發(fā)起者把小程序碼投影到大屏幕上，由于投影儀的分辨率和電腦不一致，圖片可能產(chǎn)生變形。這種情況下，簽到者怎么掃都無法識(shí)別。 而以上所有這些，對(duì)于方形的二維碼，全都不是問題。

由于小程序碼的實(shí)現(xiàn)和識(shí)別原理沒有開放，我們也沒法采取圖片糾錯(cuò)、還原等措施改善識(shí)別效果。

魚和熊掌，真的很難兼得。

關(guān)于轉(zhuǎn)發(fā)，在官方文檔里是這么寫的。

于是，在實(shí)現(xiàn)中，我們定義了此方法，把方法體留空。然后紕漏出現(xiàn)了，當(dāng)用戶簽到之后再分享，收到的人一點(diǎn)擊分享的鏈接會(huì)進(jìn)入簽到狀態(tài)。

查了很久，才發(fā)現(xiàn)原因是在分享的時(shí)候，把當(dāng)前頁面加載時(shí)候的參數(shù)也給分享過去了，可是，onShareAppMessage函數(shù)里面什么都沒做啊。

看來，什么都不做的話，它就會(huì)默認(rèn)分享頁面加載時(shí)的參數(shù)。為了修復(fù)這個(gè)bug，就嘗試return一個(gè)object，并給這個(gè)object賦值path和title兩個(gè)參數(shù)。

終于解決了。

除了上面提到的之外，還有不少微小的bug，不一而足。雖然很快就解決了，相對(duì)開發(fā)源生代碼而言，還是有些影響開發(fā)效率的。

過去的這一個(gè)月，有些累。 

相對(duì)之前鋪天蓋地的小程序宣傳，其實(shí)它沒我們想象中的那么好。當(dāng)然，不得不承認(rèn)，微信平臺(tái)的龐大用戶量和小程序無需下載的便利性，這是國內(nèi)其他任何平臺(tái)無法做到的。

對(duì)于 掃碼簽到工具 這種輕量級(jí)的應(yīng)用，開發(fā)微信小程序或許是比較好的選擇。

至于復(fù)雜的應(yīng)用，是否要開發(fā)小程序版本，可能就得慎重了。