現(xiàn)在各種小程序風(fēng)靡，這邊H5的需求還沒有搞定，產(chǎn)品又要求做小程序版本，做可以，關(guān)鍵是618前上線，我……
whatever，618要做推廣，日期訂了，剩下的就只能是排期，定方案，盡可能完成。
最后和產(chǎn)品商量之后的決定是：小程序中特有的營銷推廣的頁面，用小程序編寫，剩下的黃金流程，內(nèi)嵌H5解決。
聽起來好像很簡單，but，沒有想象中那么簡單。

判斷是否在小程序中

這個問題，網(wǎng)上一搜，答案很多，有說用UA的，有說用微信注入的JS對象的，有說用原生提供判斷方法的。
UA的有一個很大的問題，iOS判斷不了，它是沒有miniProgram這個字段的。在開發(fā)工具和Android中是可以的。
而__wxjs_environment這個對象，在測試的一臺三星上也不行，Android6.0系統(tǒng)。
而微信提供的原生方法，wx.miniProgram.getEnv。在小程序和微信瀏覽器打開，是沒有問題的。
但是在瀏覽器里面，回調(diào)不執(zhí)行啊啊啊?。。?！
這就導(dǎo)致了一個問題，如果在瀏覽器中打開，因?yàn)榛卣{(diào)沒有執(zhí)行，所以需要再執(zhí)行一遍，不在小程序時的代碼邏輯。
如果只是簡單的顯示隱藏，就還好，小程序里多走一遍也沒有關(guān)系，但是，如果是一些對執(zhí)行次數(shù)敏感的代碼，就會有問題。
我們做了檢測，雖然是回調(diào)，但是在小程序里，回調(diào)函數(shù)的執(zhí)行總是排在前面。所以，前期決定先定義一個Flag，如果執(zhí)行過一遍的代碼，F(xiàn)lag置為false，就不再執(zhí)行了。
在后續(xù)開發(fā)中，還是覺得這個方案不大穩(wěn)妥，雖然不清楚微信的JS引擎如何解析JS代碼，但是總歸也是要回歸標(biāo)準(zhǔn)的，回調(diào)的代碼極有可能在后面才執(zhí)行。
我提出一個方案，沒有必要非要判斷在小程序內(nèi)，因?yàn)樾〕绦虻腢A雖然在iOS中沒有miniProgram的字段，但是卻有microMessage的字段。
我們逆向思維一下，只要判斷這個代碼不在微信中即可，根據(jù)microMessage這個字段。

if (ua.indexof('MicroMessage') == -1) {//說明不在微信中
    // 走不在小程序的邏輯
} else {
    wx.miniProgram.getEnv(function(res) {
        if (res.miniProgram) {
            // 走在小程序的邏輯
        } else {
            // 走不在小程序的邏輯
        }
    })
}

這樣基本上可以解決上面提到的次數(shù)敏感代碼執(zhí)行的問題。

一個小坑

提一個小坑，為了代碼的健壯，我習(xí)慣性在調(diào)用方法時，寫成下面的樣子：

if(wx && wx.miniProgram && wx.mingProgram.getEnv) {
    wx.mingProgram.getEnv(function(){})
}

但是，這么寫，在實(shí)際小程序里，wx一直都是undefined。
只能直接寫里面的判斷代碼，就好使了。
這是什么黑科技？？

不管怎樣，微信是爸爸，小程序有坑也得忍著。我們做得H5頁面，據(jù)說還不如小程序日活高。
真是要笑著活下去……
end