小程序開發整理

本文將基於我的淺薄的經驗來總結和整理一個基本小程序的從零開發到上線流程。從編碼上講小程序的開發很是簡單，不過這是相對於目前流行MVVM的框架下的WebApp開發來說的，換句話說再簡單也須要完整的視圖、腳本和樣式以及服務端支持，在整個流程依上來講仍然是一個不小的體系。

總體的基本架構像這樣：

 

準備工做

小程序最直接的優點就是能消除瀏覽器端的種種適配與兼容問題以及能使用許多微信客戶端提供的酷炫原生能力，而代價就是必須在微信後臺作好種種配置，並在申請和認證過程當中作出種種妥協。籠統來講必要的東西有一下幾樣：

1. 小程序主體

即必須在微信公衆平臺上註冊小程序並提供相關的主體信息，包括小程序名稱以及業務範圍，還有註冊完成後的認證工做，這些直接影響到開發完成後的審覈成功率。題外話是雖然如今小程序開放了我的的註冊，但小程序自己目的在於提供具體的服務，服務內容不明確恐怕難過審覈，這在筆者看來並不適合我的，終究只能玩玩罷了，我的小程序想上線還得先考慮清楚打算提供何種服務，以及沒有支付能力帶來的影響。

2. AppId、項目管理和https

小程序申請完成後便可在後臺獲得本身的AppId與AppSecret用於開發。直接使用微信開發者工具進行開發我的認爲是遠遠夠了，不過這工具對小屏幕的電腦不怎麼友好，開發工具內提供的能力已經基本夠用來編碼與測試了，目前發現客服消息是不能發起的，以及部分頁面佈局和樣式會和真機有出入等問題。
微信給出的小程序的代碼管理規則比較執拗，一個小程序分別會有一個開發版、體驗版和線上版本，而且在後臺添加指定權限的人員，開發者只能訪問開發版，體驗者只能訪問體驗版，整個小程序項目的代碼文件暴露出來的只有最表面的代碼文件，配置與依賴之類的都是不用開發者操心的。
還有一個重要的東西就是https，也就是開發者本身的WebApi服務器必須使用https協議進行通訊，這也是必須作的，由於小程序的架構下客戶端與WebApi徹底分離，認證就顯得很重要了。

總體搭建

如今專一於小程序的編寫，來說講小程序如何一點點搭建起來。
首先是通常目錄結構，這裏給出筆者的項目目錄結構：

其中assets用來放圖片圖標等資源，pages下是小程序的全部子頁面，utils下是封裝的工具代碼，包括網絡請求代碼等的封裝。
最後的三個app.xxx文件即小程序的全局配置。

• app.js內能夠處理頁面初始化時的參數處理等。
  好比說對外推廣了一個帶參數的小程序碼，由用戶掃描進入後，能夠在小程序首頁提取小程序碼附帶的參數，也能夠乾脆在app.js裏來提取，而且能夠在這個腳本中定義全局數據等。
• app.json內配置全局的標題啊背景色啊底部導航啊之類的以及子頁面也必須都在此先聲明。具體的配置規則見小程序的官方開發文檔。

• app.wxss即全局的樣式配置。
  其中小程序自帶的許多組件的樣式能夠直接覆蓋掉，選擇器直接寫組件名，好比說：

page{
       background: #fff;
   }
   view,navigator{
       box-sizing: border-box;
       font-size: 32rpx;
       overflow: hidden;
   }

　　　　　　page選擇器能夠覆蓋小程序頁面自己的樣式，view、navigator都是小程序具體的組件，就當是重寫過的div標籤來改。

具體頁面搭建

頁面

頁面的搭建主要工做就是小程序提供的一堆組件的使用，其中view組件拿來當div用，能夠在樣式表內重寫樣式，還有幾個很厲害的複雜組件，包括swiper-view能夠拿來作可滑動選項卡和輪播圖，image組件自帶了圖片的多種是配方式，以及多媒體組件和各類表單組件。除了組件以外就是一些指令的使用(借用angular的說法)，好比wx:if控制顯示，wx:for控制遍歷渲染，想吐槽的兩點，一是這些指令要記得加雙大括號來傳入變量值，不然傳的都是字符串，二是小程序的這些個指令的值僅支持直接的變量和值的比較，並不支持傳入方法，連String.split都不行，這直接致使數據格式化很蛋疼啊坐等改善。

腳本

腳本中要作的事有兩件。一是在頁面渲染的各個生命週期下執行相應的代碼，好比在頁面加載時初始化數據，在頁面隱藏(打開新的頁面但當前頁面已緩存)時保存數據，在頁面顯示(重新頁面後退會當前頁面)時更新數據，在頁面銷燬時關閉艦艇和輪訓等。二是執行視圖中綁定的各類點擊事件啊組件值更改的事件啊的回調，好比最普通的bindtap綁定了方法後，此方法需在腳本中定義，當用戶點擊後即會執行。關於小程序的js腳本想吐槽的是其this指針很是蠢，一個頁面裏得有很多 var that = this; 這個語句。

WebApi配合

WebApi是除了小程序客戶端自己外另外一塊須要開發者實現的東西，與公衆號的網頁開發同樣，分爲業務的Api交互和微信實時消息的轉發和處理兩個內容。總結下來經常使用的也就登陸狀態的保持(登陸其實微信幫忙完成了，Api這邊只須要生成本身的憑證用來與客戶端交互)，媒體文件的上傳與下載(用戶上傳下載的多媒體資源)，模板消息的發送以及支付回調處理等，固然本身這邊還要提供全部業務數據的接口。還有一個客服消息的轉發其實不須要本身來實現，用微信自帶的就夠了。

部分API能力

轉發

小程序的轉發和普通網頁配置JSSDK轉發相似，都是配置轉發的內容和回調，可是能配置的只有標題，好在不須要去踩JSSDK這個天坑了，那玩意對SPA是滿滿的惡意。並且小程序的轉發也不是非要用戶點擊右上角來實現了，能夠配置到具體的頁面按鈕上去。

客服

小程序端發起客戶會話很簡單，使用指定的組件便可，若是不是非要本身搭一個客服消息轉發API的話，加個客服消息組件就算是完成客服功能的接入了。

小程序碼與二維碼

小程序碼和二維碼如今變得成熟一些了，有多種碼能夠生成，有數量有限的和無限的，跳轉到具體頁面的和能帶參數的，其生成由WebApi來完成，小程序端管顯示和掃碼進入時的參數判斷就夠。

支付

小程序的支付很是簡單，調用指定接口便可，筆者看來這也極大的得益於免去了JSSDK這個禍害。

審覈與發佈

小程序的審覈是一個蛋疼的過程，如今好像是稍微舒服了一些，可是筆者項目上週的提交審覈(非首次)仍是持續了仨工做日。總的來講就是微信那邊會很認真的核對提交的小程序是否有業務的不明確以及頁面佈局或交互上的問題，對於不一樣行業的審覈也有不一樣，審覈時長很是看運氣很被動，我的看來這雖然嚴謹但更新一次版本的時間成本略高。

最後再提一點，是小程序的官方開發文檔仍是比較完善的，開發過程當中遇到什麼問題時，先沒必要急着去開發者社區抱怨或者去開發羣裏貼圖，多留意文檔裏那些說小不小的說明文字，真的解決不掉的話說不定還真是小程序本身的BUG，問別人也沒用，只能坐等更新啦。