微信小程式開發——進階篇

　　由于項目的原因，最近的工作一直圍繞着微信小程式。現在也算告一段落，是時候整理一下這段時間的收獲了。我維護的小程式有兩個，分别是官方小程式和一個遊戲為主的小程式。兩個都是用了wepy進行開發，就是這個：

　　由于是進階篇，是以一些有關于開發基礎的我就直接跳過，直接講我最近遇到的幾個需求場景。寫的急，可能順序有一些亂，還請見諒！

用什麼架構開發小程式？

　　現有的比較公認的有3個小程式開發架構：原生、wepy、mpvue。3者個有利弊：

原生架構：微信的親兒子，可直接在微信開發者工具中開發，友善調試，結構直接對應微信文檔，架構無縫更新，最快支援最新版本的開發基礎庫。缺點是原生開發提供的開發方式比較樸素，缺乏大量的文法糖和成熟的組建化模式。
wepy：出現的較早，有大量的開發者支援，已由此基礎上開發了大量的小程式，在早起原生架構不支援元件化時率先提出組建化小程式開發模式，并加入async/await的支援和類vue的文法。但本身和vue仍有差距，且不支援vuex類似的資料管理，更多解決的是view層的問題
mpvue：真正的vue開發模式，并且支援vuex 。可用vue-cli初始化項目，短期内就積累了11.38k的star（wepy：12.3k）成長迅速，但出現較晚，且基于mpvue的小程式還遠遠少于wepy。

　　我選用wepy主要是時間較早，mpvue還沒興起，wepy也是比較穩定，如果現在有個新的小程式要做，我很可能會選用mpvue。

小程式的調試vConsole

　　先來一個簡單的就是在非正式環境下啟動調試：點選菜單的三個點的按鈕-》打開調試-》重新開機小程式-》打開右下角的vConsole

　　當然文檔中還有遠端調試等，文檔寫的比較細，我就不多說了。

如何全屏展示小程式？

　　小程式有一個自己的

navigationBar，如果有APP開發經驗的同學應該知道，navigationBar也就是程式最頂部的一條，我們同常的開發頁面，也都是在navigationBar下方的主體區用标簽開發UI部分

　　如下面兩個圖檔，左邊的翻譯君官方小程式中上面就有這樣一個navigationBar用于展示自己的title和菜單按鈕；但是右側的小程式中就沒有這樣的navigationBar，而是頁面直接覆寫整個螢幕，開發了一個全屏的小程式。

　　那麼兩種模式有什麼差別呢？

有navigationBar的小程式上方有一個系統導航區，這個區域不可定制化，可以通過配置小程式的app.json（https://developers.weixin.qq.com/miniprogram/dev/framework/config.html）來配置或者在js中調用wx.API（https://developers.weixin.qq.com/miniprogram/dev/api/ui.html#wxsettopbartextobject）。
無navigationBar的小程式則完全相反，整個螢幕都是開發區域，都可以用前端标簽+樣式自定義。原有的菜單相當與浮在頁面的右上角。可控區域變大。

　　那是不是無navigationBar的模式更好？

　　模式的配置是在app.json中的window配置navigationStyle為default/custom（default：預設有navigationBar；custom自定義即無navigationBar全屏），值得注意的是這個屬性是在微信版本 6.6.0之後才有的（2018年2月左右，正好是我開發右側小程式的時候）

　　這兩種模式最好要保持風格統一，小程式的每一個page都會繼承這個屬性，最好不要在不同的頁面動态設定這個值。

　　如果有navigationBar的話不僅有title和菜單，還會在頁面跳轉後記錄跳轉曆史，并在右上角提供一個後退的按鈕比如下圖，如果全屏模式的話，就要自己維護導航曆史了。

　　navigationBar的模式下定制化較弱，背景色隻能是RGB，不帶透明度，不能有背景圖，如果有這種需求，就要用全屏模式；另外當我在頁面區域有一個蒙層或全屏的fixed（100%）時，navigationBar的模式也無法蓋到navigationBar區域。

　　選用哪種模式就要看你的設計風格和産品需求，并盡量風格統一。二者個有利弊，我建議工具類的用navigationBar顯得更整潔、正規；遊戲類的用全屏自定義，增加可操作區域。

頁面跳轉的次數限制

　　既然剛剛提到了navigationBar中的導航曆史，我們就說一下這個導航曆史棧的大小問題，目前的導航跳轉共有兩種方式：

<navigator>元件（https://developers.weixin.qq.com/miniprogram/dev/component/navigator.html）
wx.api調用（https://developers.weixin.qq.com/miniprogram/dev/api/ui-navigate.html）

　　在wx.navigateTo(OBJECT)的文檔中明确的寫出 “注意：目前頁面路徑最多隻能十層。” 也就是說導航曆史棧大小是10，但是我實際開發中發現基本到5的時候就已經報錯了。

　　為了避免出現曆史棧滿了的情況，建議大家在跳轉到不需要有傳回的頁面調用wx.reLaunch(OBJECT) 關閉所有頁面，打開到應用内的某個頁面。這個API可以清空曆史棧，或者當使用者跳轉到首頁的時候，主動清空曆史棧。

小程式打開另一個小程式

　　我這次要做的一個很大的功能就是小程式的互相調起，而且打開同一公衆号下關聯的另一個小程式。（注：必須是同一公衆号下，而非同個 open 賬号下）。

　　比較貼心的是，雖然可以指定打開對應小程式的版本（開發、體驗、正式），但是正式的隻能打開正式的，避免了測試代碼上線的風險。

　　在這裡小程式一共提供了兩種方法，但是并不是兩種方法可以通用替換的：

　調用API wx.navigateToMiniProgram(OBJECT) （https://developers.weixin.qq.com/miniprogram/dev/api/navigateToMiniProgram.html）
<navigator>使用元件（https://developers.weixin.qq.com/miniprogram/dev/component/navigator.html）

　　二者不可替換，在API wx.navigateToMiniProgram(OBJECT) 的文檔中寫到：

　　也就是說API wx.navigateToMiniProgram(OBJECT)有可能随時被廢棄掉，但是與之對應的API：wx.navigateBackMiniProgram(OBJECT)卻沒說要廢棄。

　　新的調轉方式 <navigator>的文檔中又寫到：

　　也就是說API的調用有可能廢棄，新的元件功能，還要看目前的庫夠不夠新。是以需要開發者做好相容處理。

wx.canIUse判斷API可用性

　　對于上面的情況在微信小程式的開發過程中還有很多，我們不能依靠版本号來判斷可用性，那樣的成本是巨大的且不好管理，還好微信提供了wx.canIUse（https://developers.weixin.qq.com/miniprogram/dev/api/api-caniuse.html?search-key=can）來輔助判斷API的可用性。它的強大住處在于不僅僅能判斷js的API還能判斷元件的可用性：

　　這樣就不怕微信API的變化了。

小程式的關閉

　　有一些場景需要我們關閉小程式，但是文檔中并沒有這樣一個API，我在開發中一個小程式打開另一個後，被打開的小程式在完成任務後許喲啊關閉自身，最開始我用的方法是利用微信的bug，後退大于導航曆史的層數，即：　　

wepy.navigateBack({
          delta: 10
        })

　　這樣就會觸發關閉小程式，但是後來這個bug被修複了，我又找到了另一個方法，即wx.navigateBackMiniProgram(OBJECT)，直接傳回。但是對于非被調起的小程式，還是沒有方法。

小程式的webview

　　小程式作為一款類APP的的開發生态，齊必然可以加載H5頁面，使用的就是小程式的元件<web-view> (https://developers.weixin.qq.com/miniprogram/dev/component/web-view.html)。如圖：

　　有兩點值得注意的是：

　web-view會自動鋪滿小程式（不包含navigatorBar的内容區），也就是說，要用就必須是作為一個頁面，絕對不能作為頁面的一部分，可能是考慮安全性。
被加載的頁面必須是在小程式背景配置了業務域名的，這是一個域名白名單。而且配置的過程需要又一個域名校驗的過程，小程式會生成一個校驗檔案，放在對應域名的根路徑下，隻有通路到了這個檔案，才能校驗通過。也就是說自己維護的或者與對方達成一緻的才能作為三方H5頁面來通路。

開發設定域名白名單

　　既然說到了剛剛的域名白名單，就要提一下小程式的域名開發設定（下圖）。小程式中如果想對伺服器發出http請求，就同樣需要陪着這樣一個白名單，但是不需要校驗檔案。

分享的回調不能拿到是否分享成功

　　這個是微信API的一個變化，無論是小程式、公共号H5還是APP分享到微信，都無法擷取是否成功，微信隻鼓勵好内容的使用者自發分享，不鼓勵獎勵形式的誘導分享。也就是說無論成功還是使用者中途cancel掉，都會已success的回調傳回。