以下記錄的為開發(fā)過程中遇到的零散問題及解決方案。

登錄流程

小程序登錄流程

部分用戶沒有 unionId

如上面登錄邏輯梳理所述，進(jìn)入小程序時(shí)，如果判斷當(dāng)前進(jìn)行了用戶授權(quán)，會(huì)使用 wx.getUserInfo 獲取用戶加密信息 encryptedData 和 iv 以及 wx.login 返回的 code 調(diào)用后臺(tái)接口，后臺(tái)處理會(huì)調(diào)用微信接口，通常微信接口會(huì)返回用戶的 unionId，但發(fā)現(xiàn)有的用戶就沒有返回 unionId。在社區(qū)搜了一下這個(gè)問題，發(fā)現(xiàn)可能會(huì)存在微信接口沒有返回 unionId 的情況，但通過解密 encryptedData 一定能拿到 unionId，因此改變了獲取 unionId 的方式就解決了這個(gè)問題。

登錄加載慢

小程序線上環(huán)境，有部分用戶會(huì)登錄加載很慢，但是我自己沒有復(fù)現(xiàn)過這個(gè)現(xiàn)象，也沒辦法排查問題。后來發(fā)現(xiàn)本地使用** ngrok 進(jìn)行內(nèi)網(wǎng)穿透** 調(diào)試時(shí)，有時(shí)就會(huì)出現(xiàn)這個(gè)登錄加載慢的問題，經(jīng)過排查發(fā)現(xiàn)，前端在進(jìn)入小程序時(shí)，先使用 wx.login 獲取 code，然后調(diào)用后臺(tái) getInfo 接口拿到用戶 openId 進(jìn)行數(shù)據(jù)上報(bào)，同時(shí)也調(diào)用后臺(tái) login 接口進(jìn)行用戶登錄，這兩個(gè)后臺(tái)接口都調(diào)用了 https://api.weixin.qq.com/sns/jscode2session 接口獲取 session_key。后臺(tái)本身是做了通過將 code 值存入數(shù)據(jù)庫來防止重復(fù)使用 code 的兼容的，但是可能會(huì)存在同時(shí)進(jìn)入后臺(tái)的這兩個(gè)請(qǐng)求，還沒有完成存入數(shù)據(jù)庫的操作，后臺(tái)報(bào)了 code 被重復(fù)使用的錯(cuò)誤沒有繼續(xù)向下執(zhí)行，因此前端一直處于等待狀態(tài)，導(dǎo)致登錄加載卡死在等待中。

iOS 上頭像不顯示

問題：在【我的】頁面，進(jìn)入時(shí)查詢用戶信息，如果沒有用戶信息，顯示默認(rèn)頭像圖片，如果有用戶信息，顯示指定 url 的用戶頭像，但在 iOS 上返回用戶信息后仍然顯示默認(rèn)圖像，image 組件的 src 屬性是正確的頭像鏈接。

解決：在 iOS 上 image 組件在 src 變化后不一定能顯示更新后的圖片，使用兩個(gè) image 組件，根據(jù)有沒有 url 值決定顯示默認(rèn)頭像還是用戶頭像，就沒有問題了。

重復(fù)進(jìn)入頁面

問題：在網(wǎng)絡(luò)條件不好時(shí)可能存在點(diǎn)擊按鈕跳轉(zhuǎn)頁面，可能會(huì)多次跳轉(zhuǎn)同一個(gè)頁面，也要點(diǎn)擊多次返回才能返回到正確的頁面。

解決：在跳轉(zhuǎn)前判斷要進(jìn)入的頁面是否在路由棧已經(jīng)存在。示例代碼如下

Page({
    ...
    navigateToPage() {
        const pages = getCurrentPages();
        if (pages[pages.length - 1].route === 'pages/xxx/xxx') {
            return;
        }
        wx.navigateTo({
            url: '/pages/xxx/xxx',
        });
    },
    ...
});

網(wǎng)絡(luò)圖片存在緩存

小程序中使用的網(wǎng)絡(luò)圖片，如果 url 沒有發(fā)生變化，但后臺(tái)更新了圖片，使用小程序時(shí)可能會(huì)存在圖片沒有更新過來，把小程序從記錄中刪除了再打開，就可以了。也可以在使用圖片的 url 后面添加查詢參數(shù) url + '?' + Dare.parse(new Date()) 的方式不讓小程序緩存圖片。web-view 中打卡的網(wǎng)頁鏈接也可以這么處理。

一個(gè)值得思考的 bug

問題描述：A 頁面 -> B 頁面 -> C 頁面，在 C 頁面中，進(jìn)行背景音頻播放，并添加了背景音頻播放的監(jiān)聽，onPlay、onPause、onTimeUpdate、onEnded、onStop，這些監(jiān)聽中主要是更新當(dāng)前頁面的 data 值，來控制頁面中的顯示，如顯示播放/暫停按鈕，顯示當(dāng)前播放進(jìn)度等，并更新全局的當(dāng)前播放音頻的信息，在從 C 頁面返回到 B 頁面及 A 頁面時(shí)，會(huì)顯示一個(gè)懸浮播放的控件，顯示正在播放的背景音頻的信息及播放進(jìn)度。問題是在從 C 頁面返回后，如果是從背景音頻點(diǎn)擊的暫停，懸浮播放控件中顯示的當(dāng)前播放進(jìn)度會(huì)顯示從 C 頁面返回時(shí)的進(jìn)度，而不是當(dāng)前播放進(jìn)度。

分析原因：經(jīng)過大概1小時(shí)的 bug 追蹤，發(fā)現(xiàn)問題的原因是背景音頻播放的監(jiān)聽是在 C 頁面內(nèi)的，在 onPause 監(jiān)聽中，更新全局播放音頻信息的代碼是如下代碼中的第一段，但從 C 頁面返回后，C 頁面已經(jīng)銷毀了，這時(shí)再獲取 this.data.tipRecord 是銷毀頁面前的數(shù)據(jù)（剛開始這么寫的時(shí)候我以為會(huì)報(bào)錯(cuò)），也就是從 C 返回時(shí)的數(shù)據(jù)。將代碼修改為第二段，主要是更新全局提示記錄的處理是基于全局 store 中的數(shù)據(jù)，而不是當(dāng)前頁面的 data，該問題就解決了。

在 C 頁面中的音頻播放監(jiān)聽方法：

// 第一段，有問題的
this.backgroundAudioManager.onPause(() => {
    // 全局提示記錄處理，更新 store 中的全局信息
    this.setTipRecord({
        ...this.data.tipRecord,
        show: true,
        paused: true,
    });
});

// 第二段，修正后的
this.backgroundAudioManager.onPause(() => {
    // 獲取全局 store 中的音頻播放信息
    const storeData = this.store.getState();
    // 全局提示記錄處理，更新 store 中的全局信息
    this.setTipRecord({
        ...storeData.tipRecord,
        show: true,
        paused: true,
    });
});

微信用戶可能沒有頭像

在開發(fā)打卡生成圖片的功能時(shí)，很多都需要使用用戶的頭像，注意會(huì)存在沒有頭像的微信用戶，需要處理該種情況。