【每日出擊運簽】小程序“踩坑”總結

發表時間：2021-3-26

發布人：葵宇科技

浏覽次數：34

最近剛好接手支持了每日出擊運簽的小程序，在小程序完成以後，整理了一下(xià)初次接手小程序的一些體驗，所以有了現在這篇小總結。在小程序需求的進行期間，十分感謝澤賢，小蘇，俞煥，花(huā)花(huā)的指導~

話不多說，立馬送上小程序碼，大家可(kě)以掃碼體驗一下(xià)

每日出擊運簽小程序主要劃分為幾個(gè)功能模塊：

搖一搖
抽簽并顯示運簽結果
保存圖片
預約功能
簽到功能
積分功能
評論功能

下(xià)面重點介紹一下(xià)搖一搖、抽簽并顯示運簽結果、保存圖片三個(gè)功能。

關(guān)于搖一搖功能

花(huā)叔早前已經寫過文(wén)章（鍊接如(rú)下(xià)：http://www.ifanr.com/minapp/880378）介紹過搖一搖的實現思路(lù)了，這裡簡單歸納一下(xià)搖一搖功能的幾個(gè)主要的思路(lù)。

準備：

需要設置一組變量，保存搖一搖x,y,z三軸的數值，需要設置一個(gè)變量來記錄搖一搖的時間。

實現注意事項：

我們需要定一個(gè)阈值，作為搖一搖的判斷基準。
需要通(tōng)過公式來計算單位時間内運動(dòng)的路(lù)程，也就是我們想要的速度。如(rú)果這個(gè)速度超過了我們定下(xià)來的阈值，那麼就算作用戶已經搖一搖

//計算 公式的意思是 單位時間内運動(dòng)的路(lù)程，即為我們想要的速度
var speed = Math.abs(x + y + z - lastX - lastY - lastZ) / diffTime * 10000;

另外我們需要注意兩個(gè)小程序提供的API：

wx.onAccelerometerChange(CALLBACK)：用于監聽加速度數據，在發生有加速度的動(dòng)作的時候，執行搖一搖的判斷邏輯

wx.stopAccelerometer：在搖一搖的邏輯執行期間，需要停止監聽加速度數據，避免多次觸發搖一搖

為了給予用戶更好的搖一搖反饋，建議在執行搖一搖以後設置振動(dòng)反饋，這個(gè)小程序API裡面也帶有相關(guān)的接口：wx.vibrateShort(OBJECT)

關(guān)于抽簽并顯示運簽結果的功能

每日出擊運簽的小程序其中(zhōng)有一個(gè)需求是抽簽并顯示運簽結果。在用戶每天進入小程序的時候，通(tōng)過搖一搖，得到一個(gè)抽簽結果，如(rú)圖所示：

關(guān)于這塊功能，這裡需要着重介紹vine在實現小程序的過程中(zhōng)比較關(guān)注的兩個(gè)點，一個(gè)是随機顯示抽簽結果，一個(gè)是用于顯示簽紙(zhǐ)的動(dòng)畫效果。

随機顯示抽簽結果
這個(gè)小程序中(zhōng)，随機顯示抽簽結果的需求具體如(rú)下(xià)：

随機出現五個(gè)運簽結果，大吉、吉、平、兇、大兇；不同結果對應下(xià)面不同文(wén)案；每個(gè)用戶每天隻能獲取同一個(gè)結果。随機文(wén)案，每個(gè)用戶在用完庫存前不重複
這裡我們可(kě)以提煉出兩個(gè)關(guān)鍵點：一個(gè)是每個(gè)用戶每天獲取的結果不變，一個(gè)是，在庫存用完前不重複出現文(wén)案
也就是說，我們需要把用戶的抽簽結果和(hé)用戶id關(guān)聯起來。另外我們需要準備儲存抽簽結果的數組，每天從數組裡面取出一個(gè)值作為抽簽結果，從而保證在庫存用完前不重複出現文(wén)案。貼代碼：

// 打亂數組順序 
function shuffle(a) {
var j, x, i;
for (i = a.length - 1; i > 0; i--) {
j = Math.floor(random() * (i + 1));
x = a[i];
a[i] = a[j];
a[j] = x;
}
}

var m_w = 123456789;
var m_z = 987654321;
var mask = 0xffffffff;

function seed(i) {
m_w = i;
m_z = 987654321;
}


function random() {
m_z = (36969 * (m_z & 65535) + (m_z >> 16)) & mask;
m_w = (18000 * (m_w & 65535) + (m_w >> 16)) & mask;
var result = ((m_z << 16) + m_w) & mask;
result /= 4294967296;
return result + 0.5;
}

//獲取用戶id     
var userid = parseInt(gbConfig.user_id, 16);
seed(userid);
// 随機生成抽簽描述
var qian = [1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30];
var result = [];
for (var i = 0; i < 10; i++) {
shuffle(qian);
result = result.concat(qian);
}

// 随機生成抽簽結果
var luck = [1, 2, 3, 4, 5];
var luckarr = [];
for (var i = 0; i < 60; i++) {
shuffle(luck);
luckarr = luckarr.concat(luck);
}

2.簽紙(zhǐ)顯示的動(dòng)畫效果
這次小程序，在上線前添加了簽紙(zhǐ)顯示的動(dòng)畫效果，以加強“抽簽”的用戶感受。簽紙(zhǐ)以滾軸的形式向下(xià)展開，慢慢呈現出簽紙(zhǐ)的結果。關(guān)于動(dòng)畫效果，最容易被使用的實現方式應該就是css3動(dòng)畫以及序列幀。這裡嘗試了三套方案，最終選擇了最後一套。下(xià)面分别來介紹一下(xià)這三套方案。第一：使用傳統的序列幀方式。嘗試使用傳統的序列幀，通(tōng)過逐幀動(dòng)畫，慢慢鋪開簽紙(zhǐ)，逐幀動(dòng)畫如(rú)下(xià)：

在通(tōng)過減幀以後，得到了8張序列幀圖，vine發現，8張序列幀圖通(tōng)過拼接得到的雪(xuě)碧圖會非常大（達到了1M左右的大小），所以再次進行減幀得到由4張序列幀圖拼接而成的雪(xuě)碧圖（也有500+kb左右）。但是在實際放到頁面上面的時候發現，4張序列幀圖幀數太少(shǎo)，造成了動(dòng)畫卡頓不流暢的情況，而且在低端安卓機上面，這組序列幀動(dòng)畫完全無法流暢進行。所以第一套方案放棄。第二：把8張序列幀圖分開加載，4張為一組，拼接成一張雪(xuě)碧圖，一共兩張雪(xuě)碧圖，如(rú)下(xià)：

vine的處理方式是：先加載第一張雪(xuě)碧圖，在第一張雪(xuě)碧圖逐幀動(dòng)畫結束後，切換到第二張雪(xuě)碧圖，無縫連接播放第二組逐幀動(dòng)畫。結果在低端安卓機上面出現了同樣的情況，動(dòng)畫播放非常卡頓，而且在圖片切換的過程中(zhōng)出現了空白。于是第二套方案失敗。第三：在vine百思不得其解的時候，突然發現，這套序列幀有一個(gè)特點：它的簽紙(zhǐ)和(hé)卷軸并不是立體的！也就是說，這裡其實可(kě)以不需要序列幀來實現簽紙(zhǐ)打開的效果，隻需要最後一張圖就可(kě)以了：

關(guān)于保存圖片的功能
保存圖片的功能是這次小程序中(zhōng)的一個(gè)大難點，這裡非常感謝澤賢和(hé)小蘇提供的建議。下(xià)面來介紹一下(xià)保存圖片的功能到底是什麼：

通(tōng)過點擊分享按鈕，可(kě)以生成一張和(hé)簽紙(zhǐ)類似的圖片，用戶可(kě)以長按保存這張圖片到手機本地。從而達到轉發分享的目的。

而這個(gè)保存，所需要的就是canvas。小程序API提供了canvas的接口：

通(tōng)過這個(gè)接口，我們可(kě)以把當前畫布指定區域的内容導出成指定大小的圖片，然後再調用小程序的預覽接口進行圖片預覽以及保存：

但是在這裡，vine遇到了幾個(gè)問(wèn)題：

多次點擊保存按鈕觸發canvas，導緻手機滑動(dòng)的時候非常卡頓
生成預覽圖片時間非常慢
三星note5保存圖片尺寸的問(wèn)題

下(xià)面來介紹一下(xià)這兩個(gè)問(wèn)題相應的解決措施：

多次點擊保存按鈕觸發canvas，導緻手機滑動(dòng)的時候非常卡頓

canvas隻在需要觸發的時候渲染，在用戶沒有點擊保存按鈕的時候，默認不渲染canvas。代碼如(rú)下(xià)：由于小程序和(hé)MVVM框架類似，無法直接操作dom，所以vine采取了在樣式上面添加狀态，通(tōng)過修改showcanvas變量的值，來控制canvas的顯示和(hé)隐藏。在執行畫圖操作的時候使變量值為false，顯示canvas，在繪制完成的時候更改變量值，隐藏canvas

<canvas class='{{showcanvas ? "hidcanvas" : "showcanvas"}}' style="width: 750px; height: 1334px;position:fixed;left:100000rpx;top:-100000rpx;" canvas-id="shareQRcode"></canvas>

生成預覽圖片時間非常慢

生成預覽圖片時間非常慢，目前判斷的原因是，直接預覽canvas臨時路(lù)徑的圖片耗時比較久。那麼應該如(rú)何優化這個(gè)過程呢(ne)？

小程序的API提供了幾個(gè)關(guān)于文(wén)件的接口：

我們可(kě)以通(tōng)過這幾個(gè)接口優化目前的預覽方式。在這其中(zhōng)vine做了兩種不同的嘗試。

第一，在執行wx.previewImage的success的回調的時候，把previewImage生成的臨時路(lù)徑保存下(xià)來，下(xià)次再點擊預覽的時候，直接獲取本地已保存的文(wén)件列表wx.getSavedFileList，取得最近保存下(xià)來的文(wén)件的本地路(lù)徑，進行預覽。這麼做的想法主要是為了解決canvas渲染的問(wèn)題，每天隻渲染一次，後續都是通(tōng)過預覽本地圖片鍊接達到生成圖片的目的。梳理一下(xià)流程：

初次渲染：canvasToTempFilePath -> previewImage -> saveFile

二次渲染：getSavedFileList -> previewImage

可(kě)惜理想始終是豐滿的，在實際操作的過程中(zhōng)vine發現，通(tōng)過這樣的方式預覽圖片的時候，一直處于loading的狀态，無法生成初次渲染的圖片。vine非常苦惱，至今沒能找到原因。

于是vine想了另一種辦法，調整了預覽的順序如(rú)下(xià)：

初次渲染：canvasToTempFilePath -> saveFile -> previewImage

二次渲染：getSavedFileList -> previewImage

這時候vine發現，先把canvas生成的臨時路(lù)徑保存到本地，再預覽，這種方法是可(kě)行的！而且在二次渲染的過程中(zhōng)，由于隻是讀取小程序本地的圖片路(lù)徑，無需再次調用canvas繪圖，二次預覽的時間大大減少(shǎo)。

在這裡我們需要注意官方文(wén)檔中(zhōng)提到的一點：小程序本地文(wén)件存儲的大小限制為10M。所以我們需要調用wx.removeSavedFiled的方法删除我們不需要的圖片（當天之前存下(xià)來的圖片都是我們無需保存到本地的圖片，可(kě)以删除）

三星note5保存圖片尺寸的問(wèn)題

在數量龐大版本不一的安卓手機上，vine收到反饋，三星note5在保存圖片的時候會遇到圖片底部被裁減的情況。在通(tōng)過多次修改以及對比類似的小程序以後發現，note5用canvas繪制的圖片有一個(gè)最大的範圍是750*1150，超出這個(gè)範圍的圖片，底部就會被裁減。為什麼會有這個(gè)最大範圍vine目前還沒探索出結論，希望遇到過這個(gè)問(wèn)題的大神可(kě)以和(hé)vine交流一下(xià)心得，手動(dòng)比心！~

最後梳理一下(xià)小程序項目的一些注意點：

小程序需要申請小程序公司主體的賬号，拿到appid，給到後台同學配置接口
小程序的體驗需要上傳體驗版本，獲取體驗者的微信号，到小程序管理後台開通(tōng)體驗者權限
小程序開發過程中(zhōng)需要的單位為rpx，兼容問(wèn)題較少(shǎo)
在小程序的需求中(zhōng)，需要仔細查看文(wén)檔中(zhōng)提到的版本以及兼容問(wèn)題，做好降級處理：https://mp.weixin.qq.com/debug/wxadoc/dev/framework/compatibility.html