微信小程序開發思考總結：騰訊 “信用卡還款” 項目實踐

小程序概述

昨天晚上，微信團隊對外宣布，微信小程序開放公測。開發者可登陸微信公眾平臺申請，開發完成后可以提交審核，公測期間咱不能發布。

我們前一段時間也進行了小程序開發，現在來對之前的開發體驗做一個總結。

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）

現在我們來具體開發~

小程序的開發流程

一、獲取微信小程序的 AppID

二、創建項目

創建項目，需要通過開發者工具來完成。（工具在微信小程序公眾平臺下載）

三、編寫代碼

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

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

上圖左側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說明表示只支持單層選擇器，重構測試有時多層是支持的）

四、調試

開發完成后，我們進行調試查看效果，跟移動開發差不多，增加了手機端的log。

開發工具調試：

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

五、構建

小程序是采用類似node的本地加載模塊，不需考慮seajs中的模塊合并，只需要uglify即可。當然如果你采用ES6開發，那還是需要bebal一下。

六、測試環境

具體微信還在調整中…

七、發布

在開發工具中，進行全量提交，通過微信審核后，在微信小程序平臺進行最后發布。文件發布加載的流程如下：

八、版本更新

小程序的更新是在啟動時進行更新的，首先與客戶端版本進行對比，是否有新的版本，如果有新版本，小程序更新，再運行；否則，直接使用本地資源運行。

這樣小程序的整體開發發布就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月開始加入該項目的內測開發，期間經過了幾次地動山搖的調整，及不斷的痛苦的迭代，所幸的是框架、開發工具已經趨于完善穩定。期待小程序的正式亮相~~

 

 

 

來自：http://mp.weixin.qq.com/s?__biz=MzA3NTYzODYzMg==&mid=2653578147&idx=1&sn=dc8ed8974bd7086389155eecc82e524d&chksm=84b3b1a4b3c438b275dc04bc454b1177fce1e3175841bd09a3be23ca8bf17679e3be90556d68&scene=4