大家好，以下是《王者榮耀周邊商城》小程序的一些經驗總結，也許能幫到你，也許也幫不到，大家看著辦哈，因為時間有點早，所以文中有些實現不是最新的，最終請以官方文檔說明為準，廢話不多說，直接上高清無碼大圖。

 

以上截圖是之前的版本，中間做了改版，大家可以直接掃碼識別體驗：

項目結構

我們都知道，小程序有自己的一套實現規范，下面我們看下小程序的項目結構，如下圖：

d

• 一個入口文件：app.js
• 一個全局樣式：app.wxss
• 一個全局配置：app.json

 

頁面：pages下，每個頁面再按文件夾劃分，每個頁面4個文件

 

• index.js：實現頁面整個生命周期的控制邏輯，置頂顯示時的界面交互
• index.json：頁面配置，一個JSON對象，詳細可配置字段見這里
• index.wxml：UI結構渲染，可以理解為就是html，主要支持定制標簽，更多標簽見這里
• index.wxss：UI樣式渲染，可以理解為就是css，大部分css寫法都支持。

 

當然在4個文件基礎之下，還有一些通用的功能組件支撐它們的運行。每一個頁面都是這么幾個文件組成，非常規范統一，并且每一部分也都限定了內部實現框架和規范，所以在多人協作的時候，產出相對也就比較規范。

注：pages里面還可以再根據模塊劃分子目錄，孫子目錄，只需要在app.json里注冊時填寫路徑就行

以上是必須的文件和目錄，而實際中我們會增加別的目錄，如lib，comm和utils等等目錄。

 

框架設計

Web開發做得多了，你就會發現，大部分工作就是取數據，渲染UI，處理交互這三件事兒，小程序也不例外，所以按照這個框架邏輯，我們基于小程序本身的框架規范又擴展和細化了下，設計了下面的這套可直接應用于項目的開發框架。

 

下面我們繼續詳細理一下設計時的一些思路、出發點和具體的實現方式，窺其面更要知其理。

注：這里我沒有直接使用第三方的框架，因為我個人覺得要學習一套技術，還是需要從原生的模式開始著手，雖然前期會比較痛苦一點，但是這些付出都是值得的，因為你一旦搞明白了本來的邏輯架構和原理，你會發現什么框架都是信手拈來，而且你也更能理解框架這樣設計的優點和缺點。

 

工具類庫

 

Ajax

實現了promise的封裝，支持GET POST PUT和DELETE，這里設計的時候就確定為僅滿足單項目通用即可，所以實現的時候融入了部分業務層面的邏輯：

 

• 接口首次格式化，兼容標準的json和var形式接口（內部有大量var形式的接口）
• 直接判斷返回值在邏輯上是成功還是失敗
• 針對返回未登錄的情況，自動跳轉登錄流程

 

所以省去了業務調用側的反復判斷處理通用邏輯，使用更簡潔。

 

cache

其實，小程序自帶了緩存接口，有同步wx.setStorageSync，異步wx.setStorage的方法，但是實際在使用緩存的場景里，我們一般都是需要設置緩存有效時間的，本cache工具就是對小程序緩存接口的封裝，實現了對緩存有效期的支持。

 

Model實現

model層就不用多說了，主要是把數據處理部分獨立出來，便于統一服務和維護，這里重點強調下model內部的實現細節，這里有一個實現技巧可以用在其它別的地方。下面直接上代碼部分。

 

上面的代碼我們可以看到幾個關鍵點

1. 把參數處理和返回結果處理拆出來放到單獨的處理方法里，方法名稱保持統一：formatParams，formatResult

2. 同時最外層定義好默認的formatParams，formatResult，如果不做特殊處理，直接使用默認即可（建議不處理也調用下默認方法，規范流程）

3. 還有一點，model里方法命令有統一規范都是已get，add，update，del開頭

 

這個思路其實可以運用到任何場景，特別是在沒有任何限定框架的場景，我們只需要按照這個模式去實現，代碼一樣很清晰漂亮，比如我后面實現LOL內置競技場道具商店的時候，就是為了減少不必要的框架冗余代碼，就直接徒手寫的，同樣是拆分為model和view層，然后model按上面的規范實現，代碼同樣很清晰，強烈建議大家實踐下，簡單實用。

 

組件模式

在實現王者周邊小程序的時候，官方沒有開放自定義組件規范，所以我們還不能按照內置組件的實現方式來實現我們業務側自定義的組件，但是項目里又有公共組件的需求存在，那我們不管怎樣還是需要把組件獨立出來，不然重復代碼很蛋疼，維護成本也比較高，實際我們這里的組件實現模式還是比較簡單粗暴的，我們照樣把組件拆分為JS，WXML，WXSS三部分（或者只有一部分也行），然后通過不同的import方式引入到需要使用組件的page里就行。

 

注：雖然這里沒有使用官方的自定義組件規范，但是經過自己實現這個，也能大致了解到官方的自定義組件的實現方式和原理。

 

• JS引入：import 或者 require（建議小程序這里引入都用import，跟wxml和wxss比較統一，我對代碼有點小潔癖）
• WXML引入：和
• WXSS引入：@import

 

組件很多時候也需要處理頁面交互，相應事件，而小程序的事件綁定機制決定，事件處理方法必須是掛載到當前page對象下（實際是Page()方法定義的對象，內部引用是this），而組件的實現是單獨的文件，不在Page()方法里定義，那怎么辦呢？我這邊的實現方式是組件初始化的地方，傳遞當前的page對象（this）給到組件，然后組件內部的接口方法全部一次性extend到page上，同樣數據也是這個道理，WXML里面的數據方法只能是data對象，組件里的數據也需要掛載到這個對象上，這里強烈建議把組件內部的數據定義為一個單獨的對象掛載到data上，而不要直接掛載，如我們這里的購物車組件，實現就是下面這樣：

 

上面setData的時候，定義了shoppingCart對象，在它里面再定義具體的購物車組件需要的數據變量，而下面Object.assign一句就是把組件的方法掛載到當前使用組件的page上面去。

另外還要注意，在WXML里插入組件模塊的時候，template標簽的data屬性里的名稱請使用上面setData的名稱，比如購物車這里就是shoppingCart。

請大家現在實現的時候，使用官方標準的自定義組件規范

 

數據共享

小程序開發也涉及到多頁面間數據共享，這里針對不同的場景有幾種實現方式：

1、基于頁面的數據傳遞：直接在navigate的url后面增加參數即可，然后在接收的頁面onLoad方法里，通過參數（對象）接收即可，如下：

 

2、基于內存的數據共享：getApp方法，獲取全局的App實例對象，可以設置存取這個實例對象屬性來實現數據共享，如下：

 

上面這種方式，適合與啟動后的短期數據共享，關閉小程序數據會丟失。

 

3、基于本地緩存的數據共享：可以使用上面的cache組件，也可以使用原生的緩存接口實現，這種方式是可以在小程序關閉后還存在。

4、基于后臺服務的接口緩存：這個不多說，就是保持數據到服務器，多頁面通過接口調用。

 

開發規范

詳細的JS實現規范這就不講了，這里大致列一下我們在開發的時候，我們這邊簡單定義的一些規范，供大家參考。

 

1. 1. JS模塊引入請使用import關鍵字，而非require，WXML引入模板用標簽，WXSS使用@import語法，三者統一
   2. 使用 let 代替var進行變量定義，使用const定義常量，如：let goods = 1，const SEX=’男’
   3. 所有方法和變量名稱都使用小寫camel模式，一般是動詞+名詞形式，盡量不要超過5個單詞，如：getList，setBackImage
   4. 所有用到的常量的地方都使用全大寫，下劃線分隔的形式，如：EGG_CHE
   5. 使用this轉換的地方，統一使用that，如：let that = this; 盡量使用箭頭函數，可保留this指向
   6. 所有自定義方法（onLoad，onShow等系統方法除外）必須使用規范注釋語法進行注釋
   7. 在page和model里定義方法的時候，直接使用getList(){} 即可，中間可以不用加function關鍵字
   8. 小程序聲明周期函數里（onLoad，onReady，onShow，onHide，onUnload等）不要直接寫復雜業務邏輯，復雜業務邏輯獨立成方法，這里只負責方法調用。
   9. 所有數據處理必須封裝到model里面，包括url地址，參數格式化，返回結果格式化都放到model里面，在page里使用的時候，基本不用做過多數據處理，一般都直接setData皆可,model規范請參考前面的說明。
   10. 如果1個功能在超過一個地方出現，那請實現為公用組件，組件實現請參考前面的說明。
   11. 在WXML模板里，如果同時有2個循環中都使用到了同樣的代碼片段，請使用template的方式定義，然后直接使用即可，不能重復寫.
   12. 所有地方都需要有對接口返回空數據的處理，界面上要有相應的提示和引導。
   13. 其它的可以定義規范的loading，成功失敗提示等，這里不多說了.

 

經驗分享

大家開發前，可以大致瀏覽下小程序的官方文檔，相對比較完善，遇到問題可以先查文檔，然后再去小程序社區里搜索相關帖子，一般問題都能解決，下面是我遇到的一些問題和相應的解決方案，也許你也會碰到，僅供參考。

1、setData相關經驗

設置多級對象值：this.setData({‘a.b.c.d’:value});

設置可變索引的數組值：

varkey="array["+index+"].text,

data ={key: 'changed data’};

this.setData(data);

 

2、swiper組件 current 問題

swiper組件切換數據源以后，current屬性也需要手動重置，不會默認恢復到第一幀，就可能出現當前current大于新數據源的長度，顯示會出問題

 

3、picker-view 初始值設置無效

picker-view初始化的時候，我們都會設置數據源和初始索引值，結果發現放到一次setData里既然不生效，分成2次setData就可以了，應該是設置數據源的時間點在初始值之后了，因為setData接收的是一個hash對象，而hash對象是沒有先后順序的，所以就可能存在初始值在數據源之前設置了，當然初始值不可能生效。

 

 

4、android 兼容性問題

從原理上我們知道，小程序本身還是基于不同的JS容器的執行的，所以由于IOS（jscore）和android（v8）上容器不一致，還是需要小程序開發者自己處理兩個平臺的兼容性，不過新版的微信升級后，目前ios和android的不一致的兼容性問題已經很少了，不要這里需要理解的是小程序雖然有規范，但是并沒有幫我們屏蔽底層的兼容問題，我們自己需要注意。

 

5、cookie 的問題

我們在開發web頁面的時候，肯定會使用到cookie，傳遞登錄信息等，但是小程序本身不支持cookie，所以需要應用到cookie的地方，可以轉換為參數，放到請求后面，我們上面的小程序登錄態就是放到了請求參數里。

 

但是在調用wx.request的時候，是可以設置cookie header頭的，所以如果后臺接口驗證的需要cookie支持，可以直接在這里設置即可，但是需要注意：android的版本的小程序會把cookie鍵名自動改為小寫，如果后臺是通過大寫讀取的話，可能就取不到值了，暫時還不確認新版是否已修復這個問題。

 

 

6、https 的問題

小程序要求所有請求接口都必須是https的，而且所有的域名都需要在小程序管理后臺去添加，如果碰到沒有添加的情況，開發調試階段可以在小程序開發工具的項目一欄下，把下面這句勾選，不過上線之前是一定要添加的，不然會出現本地怎么調都是好的，到了手機上就是不行。

 

 

7、關于支付

直接使用微信支付即可，不多講。

8、關于設計

如果有條件，小程序需要獨立的產品設計和規劃，照搬App或者H5版本不是最好的方案，因為小程序有自己的一套設計，交互規范，有基于微信的賬號體系，消息機制等基礎能力，我們都可以充分利用。

 

寫在最后

雖然版本有些老，但是還是希望對大家有些幫助，最后建議，大家如果在開發小程序的過程中遇到問題，可以第一時間在論壇里發帖求助哈，微信官方有開發同學直接回復大家。