序言

幾(ji)(ji)個(ge)月(yue)(yue)前，十分有幸參(can)加(jia)微信(xin)小程(cheng)序第一批(pi)內測(ce). 但那時，遠(yuan)沒有現在(zai)激動. 因為，那個(ge)時候并(bing)不曾意識到幾(ji)(ji)個(ge)月(yue)(yue)后, 微信(xin)小程(cheng)序將刷爆你的朋(peng)(peng)友圈。 21日深夜(ye)，微信(xin)官(guan)方放(fang)了一份(fen)關于”小程(cheng)序”的內測(ce)邀請函，某公(gong)眾號高調推送(song)一篇文章(zhang)，迅速引起朋(peng)(peng)友圈刷屏，很快便(bian)突破了10W+訪問. 甚(shen)至有人連夜(ye)通宵寫”小程(cheng)序”開(kai)發(fa)教程(cheng). 這(zhe)幾(ji)(ji)日，內測(ce)的幾(ji)(ji)個(ge)團隊紛紛給出開(kai)發(fa)體(ti)驗，于是我也把平日同(tong)事(shi)比較好奇(qi)的幾(ji)(ji)點問題以(yi)及自己的看(kan)法和心得總結出來.

開(kai)發(fa)體(ti)驗過程中，感覺到微信(xin)小程序(xu)(xu)應該(gai)算(suan)作一(yi)(yi)種(zhong) Hybird App，但并非像phoneGap一(yi)(yi)樣(yang)視圖完全(quan)依(yi)靠webview來(lai)顯現(xian)，然后通(tong)過封裝的(de)(de) Javascript 與Native API通(tong)訊. 小程序(xu)(xu)的(de)(de)視圖內(nei), 即可(ke)(ke)以(yi)(yi)(yi)包(bao)括webview，也可(ke)(ke)以(yi)(yi)(yi)包(bao)括native view. 互相覆蓋疊層展示. 相對(dui)來(lai)說，這種(zhong)開(kai)發(fa)難度更大，但是(shi)(shi)(shi)實現(xian)起來(lai)比單純的(de)(de)webview更加靈(ling)活. 同時對(dui)于(yu)H5中性能不足(zu)的(de)(de)地方，可(ke)(ke)以(yi)(yi)(yi)用(yong)Native實現(xian). 對(dui)于(yu)用(yong)戶體(ti)驗來(lai)說是(shi)(shi)(shi)更接近原生了(le). 小程序(xu)(xu)的(de)(de)應用(yong)框架(jia)MINA完成了(le)最(zui)難的(de)(de)部分，作為(wei)應用(yong)開(kai)發(fa)者的(de)(de)我(wo)們，只需要(yao)微信(xin)提供的(de)(de)wxml，wxss即可(ke)(ke)完成接近于(yu)H5的(de)(de)開(kai)發(fa)體(ti)驗，完全(quan)不必去了(le)解我(wo)所用(yong)的(de)(de)INPUT是(shi)(shi)(shi) webview 的(de)(de) INPUT 還是(shi)(shi)(shi) Native 的(de)(de) INPUT。接下來(lai)就一(yi)(yi)步(bu)一(yi)(yi)步(bu)帶你(ni)走(zou)進小程序(xu)(xu)的(de)(de)世(shi)界。

應用框架MINA

MINA 這個名(ming)字(zi)就由來就好比MariaDB名(ming)字(zi)的由來。:0)

這是(shi)開發(fa)給到(dao)的架(jia)構圖. 

 
從圖(tu)(tu)中可以(yi)看出，應(ying)用層(ceng)(ceng)和頁面(mian)視(shi)(shi)圖(tu)(tu)層(ceng)(ceng)之間的(de)(de)通訊是經由(you)系統(tong)層(ceng)(ceng)的(de)(de)JSBridge實(shi)現的(de)(de)，頁面(mian)單向接受來自應(ying)用邏輯(ji)層(ceng)(ceng)的(de)(de)數(shu)據(ju)流，應(ying)用邏輯(ji)層(ceng)(ceng)響應(ying)頁面(mian)視(shi)(shi)圖(tu)(tu)層(ceng)(ceng)的(de)(de)事件。頁面(mian)視(shi)(shi)圖(tu)(tu)層(ceng)(ceng)的(de)(de)每(mei)一個頁面(mian)由(you)wxss和wxml構成。而系統(tong)層(ceng)(ceng)JSBridage提供原生(sheng)各種能(neng)力支持.

官方提供(gong)了開(kai)發(fa)者工(gong)具,雖然開(kai)發(fa)者工(gong)具和(he)微信客戶端(duan)實現的原(yuan)理大不(bu)一(yi)樣，但我們依(yi)然可以從這里(li)去(qu)理解頁面視圖層和(he)應用邏輯層.

開發者(zhe)工具和我(wo)們平時(shi)Chrome調(diao)試一樣，左(zuo)邊(bian)是(shi)頁(ye)面(mian)，右邊(bian)是(shi)控制臺(tai)。但不(bu)同的(de)(de)是(shi), 左(zuo)邊(bian)展示的(de)(de)頁(ye)面(mian)和右邊(bian)的(de)(de)代(dai)碼似乎不(bu)是(shi)運行在同一個(ge)環境(jing)。因為平時(shi)調(diao)試時(shi)，我(wo)們在console輸(shu)入document.body.outerHTML會打出頁(ye)面(mian)HTML代(dai)碼。在開發者(zhe)工具中只會打印(yin)出appservice的(de)(de)頁(ye)面(mian)內容(rong)。并非顯示頁(ye)面(mian)的(de)(de)內容(rong)。 

同(tong)時刷新(xin)左(zuo)(zuo)側區域，右邊代(dai)碼不會再次執行，除(chu)非(fei)點(dian)重啟(qi)按鈕(niu)。因此懷疑左(zuo)(zuo)側頁(ye)面和右側控(kong)制(zhi)臺(tai)并非(fei)同(tong)一環境, 可(ke)以認為左(zuo)(zuo)側頁(ye)面就(jiu)是(shi)架構(gou)圖中的(de)頁(ye)面視圖層，右側控(kong)制(zhi)臺(tai)(除(chu)了wxml Tab外) 就(jiu)是(shi)邏(luo)輯應(ying)用(yong)層。邏(luo)輯應(ying)用(yong)層想要更新(xin)頁(ye)面就(jiu)必(bi)須使用(yong):

1. this.setData({text: 'update text'});

除此之外，別無(wu)它(ta)法(fa)(fa)。妄想通過DOM操作、Zepto、或者其(qi)它(ta)框架(jia)來更(geng)新頁(ye)面是(shi)行不通的(de)，因(yin)為(wei)在(zai)應(ying)用邏(luo)(luo)輯層(ceng)(ceng)無(wu)法(fa)(fa)直接獲得頁(ye)面視圖(tu)層(ceng)(ceng)中的(de)DOM節點(dian)。甚至在(zai)手機(ji)(ji)客戶端上，完(wan)全(quan)(quan)沒(mei)有(you)window、document等(deng)全(quan)(quan)局對象(xiang)。  開發者工具(ju)只(zhi)是(shi)對整個架(jia)構的(de)模擬(ni)，其(qi)中應(ying)用邏(luo)(luo)輯層(ceng)(ceng)應(ying)該還是(shi)運(yun)行在(zai)webview之上的(de)，手機(ji)(ji)客戶端的(de)實現原理應(ying)該大(da)不一(yi)樣、應(ying)用邏(luo)(luo)輯層(ceng)(ceng)有(you)可能完(wan)全(quan)(quan)不運(yun)行在(zai)webview上，這也就是(shi)為(wei)何手機(ji)(ji)客戶端沒(mei)有(you)window、document等(deng)對象(xiang)。

數據綁定探究

小程序實現數據綁定(ding)的方式(shi)如下：

1. <view>{{msg}}</view>

視圖中以wxml語法(fa)添加一(yi)個節(jie)點(dian)，對于Vue或(huo)者是(shi)(shi)AngularJS用戶是(shi)(shi)不是(shi)(shi)感覺(jue)頗為親切(qie)和熟悉。唯(wei)一(yi)的區別就是(shi)(shi)沒有(you)v-text或(huo)者ng-bind的功能。

1. Page({
2. data: {
3. msg: 'Orginal msg'
4. },
5. onLoad: function () { this.setData({
6. msg: 'Updated msg'
7. });
8. }
9. });

更新數據時，對(dui)比(bi)三者(zhe)的(de)代碼實(shi)現：

1. // 微信小程序this.setData({
2. msg: 'Updated msg'});// Vuethis.msg = 'Updated msg';// AngularJS$scope.msg = 'Updated msg';

接著我(wo)們加入另外(wai)一個(ge)INPUT

1. <input value="{{msg}}"></input>

對于INPUT，小程序并不存在(zai)類似 ng-model 或者是(shi) v-model 的(de)(de)雙向(xiang)綁定(ding)指令，只能通過(guo) value 進行設置.  當用戶人工(gong)在(zai)INPUT中(zhong)(zhong)修(xiu)改(gai)其中(zhong)(zhong)的(de)(de)值后，發現 view 中(zhong)(zhong)的(de)(de)值并不會跟著變, 這里與 Vue 和(he) AngularJS 表現不一致. 

因為(wei)小(xiao)程序是應(ying)(ying)(ying)用邏輯層到(dao)頁面視(shi)圖層的(de)單(dan)向綁(bang)定(ding)，所(suo)以在應(ying)(ying)(ying)用邏輯層中(zhong)不(bu)會感知到(dao)值的(de)變(bian)化，而且也并(bing)不(bu)提(ti)供(gong)一個(ge) getData 的(de)方法去取到(dao)INPUT中(zhong)的(de)值，只(zhi)能(neng)通過事件響(xiang)應(ying)(ying)(ying)實現。而 Vue和(he) AngularJS 的(de)雙向綁(bang)定(ding)特性，人為(wei)在頁面上的(de)數(shu)據(ju)改變(bian)是可以直接反饋到(dao)邏輯代碼里的(de)。如果(guo)一定(ding)要實現類似功能(neng)，那就只(zhi)有通過響(xiang)應(ying)(ying)(ying)INPUT事件，實時更(geng)新(xin)view的(de)數(shu)據(ju).  我們再在 頁面加(jia)個(ge)按(an)鈕:

1. <button bindtap="btnTap">Button</button>

邏(luo)輯層加入響應事件：

1. btnTap: function () { this.setData({
2. msg: 'Updated msg'
3. });
4. }

手動改變INPUT值為其它時(shi)，INPUT的值卻并沒有(you)改回來。這里說明在 setData 操(cao)作(zuo)時(shi)，應用(yong)邏(luo)(luo)輯(ji)層會先檢測(ce)msg是否(fou)有(you)變化，而此時(shi)應用(yong)邏(luo)(luo)輯(ji)層感知不(bu)到到人為修改的INPUT值，因此 setData 操(cao)作(zuo)會被視為沒有(you)改變數據(ju)而不(bu)會去更新(xin)視圖。所(suo)以官(guan)方提供另外一(yi)種方法(fa)強制(zhi)更新(xin)視圖：

1. this.setData({
2. msg: 'Updated msg',
3. }, {forceUpdate: true});

至于(yu)為(wei)何在 setData 時要檢測數(shu)據是否變(bian)化過呢，而不(bu)是每(mei)次 setData 都去直接更新視圖(tu)呢？我猜想是在應用邏輯層數(shu)據傳(chuan)遞到頁面(mian)視圖(tu)層的(de)這(zhe)(zhe)個過程，并非像暜通H5中(zhong)dom.innerHTML = 'updated';一(yi)樣(yang)簡單，因此做(zuo)這(zhe)(zhe)個檢測也(ye)是起到對性能的(de)一(yi)種保護作(zuo)用吧。

再來看另外一種(zhong)情(qing)況，非當前執(zhi)行(xing)序列下更新數據。  修(xiu)改btnTap事件如下：

1. btnTap: function () { var self = this; this.setData({
2. msg: 'Updated by button tap'
3. });
4. setTimeout(function () {
5. self.setData({
6. msg: 'Updated by setTimeout'
7. });
8. }, 3000);
9. }

 但是結(jie)果并(bing)非像預期的(de)那樣三秒后改(gai)變文字。同理，此類情況如果是用AngularJS實(shi)現(xian)需要修(xiu)改(gai)為(wei)：

1. setTimeout(function () {
2. $scope.msg = 'Update by setTimeout';
3. apply();
4. });

添加一行apply();或(huo)者用提(ti)供的(de)$timeout方(fang)法。  而(er)Vue即便在(zai)setTimeout中也可(ke)(ke)以(yi)(yi)不作改變(bian)，直接(jie)賦值。因為(wei)它的(de)數(shu)據綁定是基于(yu)getter、setter的(de)。  所(suo)以(yi)(yi)在(zai)MINA中也可(ke)(ke)通過類似方(fang)法實現：

1. setTimeout(function () {
2. self.setData({
3. msg: 'Updated by setTimeout'
4. });
5. self.update();
6. }, 3000);

 所以看到這里，MINA在做數據綁定的(de)時候和AngularJS的(de)臟數據檢查機制很像呢。

請求后臺接口

小程序提供了一系列(lie)網(wang)絡請(qing)(qing)求(qiu)(qiu)API，支持 HTTP 請(qing)(qing)求(qiu)(qiu)、webSocket請(qing)(qing)求(qiu)(qiu)、以(yi)及上傳下(xia)載文件。  但前提條(tiao)件是(shi)在后(hou)臺配置(zhi)好了合法(fa)域名(ming)，只有合法(fa)域名(ming)的請(qing)(qing)求(qiu)(qiu)才(cai)被允(yun)許。 

因(yin)為業(ye)務只涉及到(dao) HTTP 請(qing)求(qiu)(qiu)(qiu), 所以這里只討論(lun)由wx.request發(fa)起的(de) HTTP 請(qing)求(qiu)(qiu)(qiu)。  官方規定(ding)最多只允許5個并(bing)發(fa)請(qing)求(qiu)(qiu)(qiu)，并(bing)且暫時不提(ti)供(gong)定(ding)制的(de)方法(fa)。 

 這個讓我聯想到了多數瀏覽器(qi)對單(dan)個域名最高(gao)并發數量設置(zhi)為6個。與(yu)之(zhi)不同的是：

瀏覽器的(de)策略是針(zhen)(zhen)對單域名，但(dan)(dan)小程序中是針(zhen)(zhen)對所有請求(qiu)(但(dan)(dan)因為合(he)法(fa)域名只有一個(ge)(ge)，所以(yi)也就不存在多(duo)域名的(de)問題)。  瀏覽器在單個(ge)(ge)域名請求(qiu)超過6個(ge)(ge)時(shi)，只是會暫時(shi)阻塞后續(xu)請求(qiu)，直至某個(ge)(ge)請求(qiu)完成(cheng)，但(dan)(dan)小程序似乎在多(duo)于(yu)5個(ge)(ge)請求(qiu)并發時(shi)直接(jie)報錯。

先忽略這個問題，那么(me)，線上已經(jing)開發好了(le)的接口是否可(ke)以直接使用呢？那就看以下幾點：

小程序有新的(de)AppId，如果以(yi)前接(jie)口是(shi)針對(dui)老的(de)AppId開發(fa)的(de)話(hua)，那肯(ken)定不(bu)適用。  自從 iOS9 推出(chu) ATS 特性后(hou)，要(yao)(yao)求(qiu)(qiu) App 內訪問的(de)網絡必(bi)(bi)須使用 HTTPS 協議(yi)(yi)以(yi)保證網絡鏈路安全，所(suo)以(yi)小程序也需要(yao)(yao)接(jie)口支持 HTTPS 協議(yi)(yi)。  客戶(hu)端對(dui)于 HTTP 協議(yi)(yi)的(de)一些特性不(bu)完(wan)全支持，比(bi)如 cookie。因此如果接(jie)口從 cookie讀數(shu)據的(de)，就需要(yao)(yao)修改(gai)(gai)為(wei)從參(can)數(shu)讀取。同理(li)寫(xie) cookie 也需要(yao)(yao)修改(gai)(gai)為(wei)返(fan)回在(zai)(zai)(zai) body 中，然(ran)后(hou)在(zai)(zai)(zai)邏輯層用 storge API模擬實現 cookie。另外(wai)還(huan)有一些比(bi)如返(fan)回 Content-type必(bi)(bi)須為(wei) utf-8，否則(ze)客戶(hu)端解析亂(luan)碼等問題，都需要(yao)(yao)在(zai)(zai)(zai)接(jie)口改(gai)(gai)造時注意。  出(chu)于安全考慮，部分(fen) header 用戶(hu)是(shi)無法自行定義的(de)，如果接(jie)口中存在(zai)(zai)(zai) Referer 校(xiao)驗(yan)等類似問題的(de)話(hua)可能要(yao)(yao)重新修改(gai)(gai)校(xiao)驗(yan)規則(ze)。  請求(qiu)(qiu)由客戶(hu)端發(fa)出(chu)，因此為(wei)方便跨域(yu)的(de) jsonp 請求(qiu)(qiu)就沒有存在(zai)(zai)(zai)的(de)必(bi)(bi)要(yao)(yao)。

綜上所述，在(zai)請求(qiu)后端接(jie)口上大體還是和以(yi)前(qian)體驗差不多的(de)。

客戶(hu)(hu)端(duan)請求(qiu)是(shi)(shi)由客戶(hu)(hu)端(duan)發(fa)(fa)(fa)起(qi)的(de)比較好(hao)理解，因為之前就判(pan)斷客戶(hu)(hu)端(duan)的(de)應用邏輯層代碼(ma)不是(shi)(shi)運(yun)(yun)行(xing)在webview上(shang)。小程序(xu)開(kai)發(fa)(fa)(fa)者(zhe)工具的(de)應用邏輯層代碼(ma)應該是(shi)(shi)運(yun)(yun)行(xing)在webview上(shang)的(de)，那么它的(de) http 請求(qiu)是(shi)(shi)由 node 發(fa)(fa)(fa)起(qi)的(de)還是(shi)(shi) webview 發(fa)(fa)(fa)起(qi)的(de)呢？  出于好(hao)奇研究了一下，發(fa)(fa)(fa)現(xian) wx.request 在開(kai)發(fa)(fa)(fa)者(zhe)工具中是(shi)(shi)由 webview 發(fa)(fa)(fa)起(qi)的(de) xhr 請求(qiu)： 

既然是 webview 發起(qi)的(de) xhr 那么肯定就會(hui)受(shou)到瀏覽器跨域安(an)全(quan)策略的(de)限制(zhi)。

 分別(bie)在(zai)普通瀏(liu)覽器和(he)小程序開發(fa)者工具的 console 中注入 jQuery 后(hou)執行：

1. $.get('//www.qq.com');

可以發現普通瀏覽器會在(zai)xhr.send()時報(bao)錯，但(dan)開發者工(gong)具不會，而且能正常返回(hui)結果。

普通瀏覽器(qi): 

小程序開發者工(gong)具: 

由此可見，開(kai)發者工具使用了一些手段(duan)屏蔽或者繞過(guo)了 webview 的跨域安(an)全策略。

后記

以(yi)上(shang)體驗(yan)都是在(zai)手機充值(zhi)小程序的(de)開發過程中的(de)心得與(yu)體會(hui)，希(xi)望能(neng)通過梳理的(de)幾點問題能(neng)夠(gou)大(da)致了(le)解到小程序的(de)工(gong)作方式。因為我們的(de)業務(wu)比較簡單，使(shi)用(yong)到的(de)技(ji)術可能(neng)只(zhi)是MINA中的(de)冰山一角，所(suo)以(yi)本(ben)文涉及的(de)內容有一定的(de)局(ju)限性，后續(xu)新的(de)心得與(yu)體會(hui)也會(hui)在(zai)這里補充，更新。

從8月初開(kai)(kai)(kai)發小(xiao)(xiao)程序到現(xian)在，起初每天(tian)工作超過15個(ge)小(xiao)(xiao)時，從剛開(kai)(kai)(kai)始一(yi)步一(yi)個(ge)坑，框架改(gai)了又改(gai)到現(xian)在框架基(ji)本(ben)穩(wen)定，開(kai)(kai)(kai)公內(nei)測。這(zhe)一(yi)切都離不開(kai)(kai)(kai)WX GG們的(de)辛苦努力(li)，這(zhe)幫天(tian)才GG們賣(mai)得(de)一(yi)手(shou)好萌(meng)，寫得(de)一(yi)手(shou)好代碼(ma)，更(geng)重要的(de)是他們精力(li)充沛，無時無刻都在幫我們定位問題(ti)，解決問題(ti)。付出的(de)努力(li)是值得(de)的(de)，從現(xian)在小(xiao)(xiao)程序的(de)轟動趨(qu)勢來看，小(xiao)(xiao)程序注定要創建(jian)一(yi)個(ge)***。

最后，手機充值(zhi)小程(cheng)序(xu)(xu)井然有序(xu)(xu)的在進行著一步一步的迭(die)代，這個(ge)過程(cheng)更加順暢得心應(ying)手，感謝(xie)手機充值(zhi)團隊的產品、后臺、視覺、重構(gou)等同學付出的努力，希望大家多多支持(chi)手機充值(zhi)，也希望在小程(cheng)序(xu)(xu)上(shang)線(xian)之日(ri)，手機充值(zhi)小程(cheng)序(xu)(xu)能(neng)以最優雅的姿態與大家見面。