【騰訊Bugly乾貨分享】微信小程序開發思考總結——騰訊「信用卡還款」項目實踐

本文來自於騰訊bugly開發者社區，未經做者贊成，請勿轉載，原文地址：http://dev.qq.com/topic/58212d0fa7a7574c4f4cc3c5

做者：peggy

小程序概述

11月3日晚，微信團隊對外宣佈，微信小程序開放公測。開發者可登錄微信公衆平臺申請，開發完成後能夠提交審覈，公測期間暫不能發佈。

咱們前一段時間也進行了小程序開發，如今來對以前的開發體驗作一個總結。

1. 小程序是什麼？

微信小程序是一種介於原生app、和web app的hybrid。經過微信進行加載，實現相似原生app的流暢。相對原生app來講，小程序更加輕量、更新實時、跨平臺；相對web app來講，小程序資源離線，體驗更流暢。

微信小程序的設計目標是經過儘量簡單、高效的方式讓開發者能夠在微信中開發具備原生APP體驗的服務。

不說那麼多了， 先來看看小程序的效果：

看完效果，是否是對開發充滿好奇~

2. 小程序的實現機制

小程序的開發是基於微信提供的一套應用框架進行開發的。微信經過封裝微信客戶端提供的文件系統、網絡通訊、任務管理、數據安全等基礎功能，對上層提供了一套完整的Javascript Api，使得開發者可以很是方便的使用到微信客戶端提供的各類基礎功能，快速構建一個應用。框架設計以下：

框架提供了本身的視圖層描述語言 WXML 和 WXSS，以及基於 JavaScript 的邏輯層框架，並在視圖層與邏輯層之間經過單向數據綁定進行數據傳輸，使開發者更加聚焦於數據與邏輯上。

3. 支持的特性

接下來咱們來看一下，微信框架具體提供的特性：

wxml：一切皆組件（視圖組件）

• view組件（相似 H5中的div）
• input組件（type = digit，有帶小數點的9宮格鍵盤）
• modal彈窗組件 （對應的wxml、效果以下）（該組件已換js 實現wx.showModal()）

更多wxml組件，請查看微信公衆平臺小程序文檔

4. 功能API：

• 支付
• 微信信息的獲取
• 網絡請求
• 錄音
• 上傳/下載文件
• webSocket
• 訪問相冊

更多詳細的API，請查看微信公衆平臺小程序文檔

5. 其餘：

• 下發消息通知
• 簡要的統計（pv、uv）

如今咱們來具體開發~

小程序的開發流程

1、獲取微信小程序的 AppID

2、建立項目

建立項目，須要經過開發者工具來完成。（工具在微信小程序公衆平臺下載）

3、編寫代碼

首先咱們來看一下小程序的目錄結構：

微信對小程序的開發有些規定：

上圖左側3個文件是放在小程序的根目錄中，其餘文件由開發者自由控制。

• app.js是小程序的腳本代碼，用來監聽並處理小程序的生命週期函數、聲明全局變量
• app.json 是對整個小程序的全局配置，配置小程序是由哪些頁面組成，配置小程序的窗口背景色等。

• app.wxss 是整個小程序的公共樣式表

其中app.js,app.json是必需的。

小程序頁面是由同路徑下同名的四個不一樣後綴文件的組成：

• .js後綴的文件是腳本文件
• .json後綴的文件是配置文件
• .wxss後綴的是樣式表文件
• .wxml後綴的文件是頁面結構文件

在H5開發中，咱們是經過在頁面中，引入對應的css、js，而小程序開發不須要在wxml中引入，它們是經過相同的名稱，將頁面與邏輯js、樣式進行關聯匹配。

接下來，咱們動手具體開發吧~

框架：小程序內嵌微信框架，不需額外框架

通常來講咱們開始開發，都會從框架開始進行設計。而小程序在封裝了一個爲客戶端設計的框架，做爲小程序的開發者是基於該框架開發的，目前現有的框架不用考慮，而且也不須要考慮。

現有的框架基本都是創建在window、document對象上。小程序是沒有window、document，或者說沒有瀏覽器BOM這個宿主環境。你能夠理解爲小程序的宿主環境是相似node的宿主環境，而不是瀏覽器客戶端。關於這個環境的設計，感興趣的童鞋能夠參考PWS

模塊化：形式上支持CommonJs，加載引用更像ES6

小程序形式支持CommonJS，經過require加載，跟node、seajs相似。可是經過require加載的是引用的賦值，而不是CommonJS中的值的緩存。

小程序的模塊書寫：

小程序的模塊運行（相似node，框架會自動添加外層define）：

模塊化：UI組件設計

在開發時，與視圖相關的組件模塊化時，咱們可能須要注意一下。例如彈框，在H5中，咱們通常是將其封裝成一個模塊組件，這樣能夠複用。在小程序中，視圖只能在wxml中，不能動態生成。

首先，咱們看一下微信的彈窗的視圖組件modal，微信以前給的api是這樣的(該組件微信已經使用其餘方式實現， 這裏用它來描述問題)：

看到這樣，你是否有聯想，若是一個頁面須要使用100個彈框，開發者須要建立100wxml組件，及註冊對應的100個肯定按鈕的事件，100個取消按鈕的事件。這顯然是不合理的。

能不能在框架上進行封裝成一個通用組件，開發者只需傳入對應的事件句柄便可?後期微信可能會考慮封裝吧~

NO~！

爲何呢？咱們從框架組件設計來看，框架自己採用面向狀態的編程方式，組件部分相似redux的設計（實際不是redux實現的）

組件的View在action操做後，只能經過action的業務處理進行更新View。而框架是單向數據綁定，沒法自動更新。 

對於這一類View組件自帶action的，建議進行必要再封裝。封裝能夠考慮aop的方式動態的註冊&卸載。

1. 定義組件的通用模版

2. aop方式封裝組件的邏輯

1）組件的默認配置：

2）組件的封裝實現

3. 組件的使用：

1）在頁面wxml中引入組件的模版

2）在頁面js中，隨時不限次數使用彈框

目前該組件微信已經封裝（api:wx.showModal()調用彈框），不過action不能自動更新的特性依舊存在，開發者若是須要自定義其餘帶有交互的UI組件時，依然會碰見以上問題，能夠參考以上解決思路。

具體頁面開發

對於業務頁面的開發，能夠將頁面視爲一個頁面組件。在這個頁面組件，完成了如下工做：

1. 負責初始化組件state（微信）
2. 負責組合子view組件造成頁面效果（開發者）
3. 肯定js 與view 匹配的數據（開發者）
4. 負責註冊業務邏輯對象提供的業務邏輯方法（開發者）
5. 負責管理業務邏輯對象（開發者）

1） index.wxml

2） index.js

頁面wxml與頁面js的通訊以下（簡化了微信框架的工做）

在頁面開發咱們須要注意的有：

• index.js中的data數據只讀

頁面js中，data數據是須要約定爲只讀。框架是單向數據綁定，修改data中的數據不會自動更新View；更新view，須要使用setData()方法。setData()更新View時，與data中的數據進行Diff比較，不一樣纔會更新。這樣若是直接修改data，很容易形成data中的數據與View不一致。

• setData單次設置的數據不能超過1024kB，須要避免一次設置過多的數據。
• template，這些模版具備本身獨立的做用域。
• 支持ES6中的…展開模塊數據。

｛｛…cardInfo｝｝，模版中的數據｛｛card_name｝｝、{{bank_simple_name}}，對應data中的數據就是data：｛cardInfo：｛card_name「」,bank_simple_name:「」｝｝，方便了對子view的控制。

這樣就完成了頁面級的開發~~YES！

小程序與H5的區別

在具體寫代碼，小程序與H5的開發有什麼區別呢？

javascript：

（一）限制：

• 經過傳入字符串來執行代碼的能力都禁用了

出於安全考慮，凡是經過傳入字符串來執行代碼的能力都禁用了。具體被禁掉的原生功能有：new Function、eval、Generator。這是同時也比較有效的避免了相似H5 中xss的問題。

禁掉的這些功能，對咱們開發來講影響比較顯著的應該是字符串轉json，以往咱們都是經過new Function、eval來處理後臺cgi的返回。（移動端通常封裝在zepto之類的框架中），小程序開發須要改變一下具體實現。

• 與瀏覽器BOM相關的api都是沒有的。

在這些BOM中，對開發影響最大的應該是沒有cookie。由於其餘功能例如storage，小程序有相似的處理方法。而cookie在web開發中是與後臺登陸相關的。

小程序中是沒有Cookie的，爲了兼容目前大部分web app 的登陸管理是使用cookie的。小程序在請求發送時，客戶端能夠動態的給請求設置Header發送報文的cookie。

注意一下cookie自己不能在客戶端進行讀寫。

由於沒有cookie，H5中的csrf問題理論上是根本解決了。小程序是否存在其餘客戶端安全問題，須要技術、時間來檢驗~

（二） 優化

• 登陸：

H5中，經過微信受權通常採用url重定向的方式獲取code；在小程序中，經過wx.login獲取code，這樣避免了以前登陸重定向的問題。

• storage：

小程序用storage替代了H5中的localstorage、sessionstorage。storage對每一個小程序的大小是10M，支持同步和異步。

• 微信支付路徑再也不受限

（三） 不便

1）每一個頁面是須要手動在app.json中進行註冊。若是沒有註冊，是不執行該頁面的。
2）打開的頁面有5個的限制，在開發時須要主要控制打開頁面的數量

wxss：

• wxss 再也不支持媒體查詢
• 增長了app的flex佈局
• 引入rpx的概念

rpx（responsive pixel）: 能夠根據屏幕寬度進行自適應。規定屏幕寬爲750rpx。如在iPhone6上，屏幕寬度爲375px，共有750個物理像素，則750rpx = 375px = 750物理像素，1rpx = 0.5px = 1物理像素。

• wxss中，不能使用背景圖片。這跟框架的設計思想認爲一切皆組件有關
• wxss動畫不支持（目前）
• 不支持多層選擇器.classA {} – 支持； .classA  .classB {} – 不支持 （api說明表示只支持單層選擇器，重構測試有時多層是支持的）

4、調試

開發完成後，咱們進行調試查看效果，跟移動開發差很少，增長了手機端的log。

開發工具調試：

手機客戶端：點擊右上角開啓調試

5、構建

小程序是採用相似node的本地加載模塊，不需考慮seajs中的模塊合併，只須要uglify便可。固然若是你採用ES6開發，那仍是須要bebal一下。

6、測試環境

具體微信還在調整中…

7、發佈

在開發工具中，進行全量提交，經過微信審覈後，在微信小程序平臺進行最後發佈。文件發佈加載的流程以下：

這樣小程序的總體開發發佈就Over了~

我的對小程序產品的見解：

優點：

1. 低門檻下載，做爲微信的一環，能夠經過微信直接進入，便可使用。幾乎能夠認爲是網頁，沒有下載門檻。
2. 跨平臺，微信客戶端底層封裝，支持小程序跨平臺
3.開發成本低，經過以前的開發對比，小程序的開發比web app 的開發成本還低，而且前端的資源存放、發佈運維都集成在微信中（若是和騰訊雲功能合加，純屬聯想~~ 呵呵）
4. 頁面仿原生，體驗更流暢
5. 小程序可使用微信的支付功能

侷限：

1. 開發基於微信框架，部分功能受限，不支持現有的其餘第三方插件；
2. 小程序頁面只能同時打開5個，若是交互流程較長難以支持；
3. 小程序包大小限制爲1M（目前），全部只適合輕量級

關於微信框架api 的具體內容，請參考

https://mp.weixin.qq.com/debug/wxadoc/dev/index.html

建議在開發小程序時不要以web app的開發思惟去思考~

結語  

  
從8月開始加入該項目的內測開發，期間通過了幾回地動山搖的調整，及不斷的痛苦的迭代，所幸的是框架、開發工具已經趨於完善穩定。期待小程序的正式亮相~~

---

更多精彩內容歡迎關注bugly的微信公衆帳號：

騰訊 Bugly是一款專爲移動開發者打造的質量監控工具，幫助開發者快速，便捷的定位線上應用崩潰的狀況以及解決方案。智能合併功能幫助開發同窗把天天上報的數千條 Crash 根據根因合併分類，每日日報會列出影響用戶數最多的崩潰，精準定位功能幫助開發同窗定位到出問題的代碼行，實時上報能夠在發佈後快速的瞭解應用的質量狀況，適配最新的 iOS, Android 官方操做系統，鵝廠的工程師都在使用，快來加入咱們吧！