特別說明：本文寫作時(shí)間為11月份，所以很多內(nèi)容可能不再適合最新版本，僅供參考； 
| 導(dǎo)語 隱隱覺得有幾本書要火《從入門到精通微信小程序》，《微信小程序開發(fā)權(quán)威指南》，《微信小程序之美》，《微信小程序之道》，《頸椎病康復(fù)指南》。。?？瓤?，跑偏了，什么？沒見過這幾本書？那你總聽過微信小程序的大名吧，作為移動(dòng)端的新起之秀，小程序牽動(dòng)了無數(shù)人的目光。作為有幸參與并推動(dòng)小程序成長(zhǎng)過程的團(tuán)隊(duì)之一，我們也不能甘（fang）于（qi）落（xuan）后（yao），經(jīng)過我們幾天的努力，這篇微信小程序開發(fā)經(jīng)驗(yàn)分享展現(xiàn)給大家。本篇文章主要就小程序的適配、小程序的生命周期、小程序的架構(gòu)、小程序的開發(fā)以及我們趟過的坑這幾點(diǎn)展開來講。 話不多說上干貨（內(nèi)容比較干，建議大家自備水壺）～

寫在前面：

小程序的定義： 
很多人問我，說的這么熱鬧，小程序到底是個(gè)什么東西？下面我先簡(jiǎn)單介紹一下。

官方這么定義小程序：

“小程序是一種不需要下載安裝即可使用的應(yīng)用，它實(shí)現(xiàn)了應(yīng)用“觸手可及”的夢(mèng)想，用戶掃一掃活著搜一下即可打開應(yīng)用。也體現(xiàn)了“用完即走”的理念，用戶不用關(guān)心是否安裝太多應(yīng)用的問題。應(yīng)用將無處不在，隨時(shí)可用，但又無需安裝卸載”。

小程序是一個(gè)由微信提供開發(fā)組件與開發(fā)規(guī)則，以js為主要開發(fā)語言，最終運(yùn)行在微信App內(nèi)的輕量型應(yīng)用，有著即掃即用的特點(diǎn)。它不是H5，但與H5一樣，小程序有著開發(fā)上手快、開發(fā)成本低的特性；它不是App，卻有著同樣的流暢度。小程序的出現(xiàn)使前端工程師可觸及的領(lǐng)域進(jìn)一步增大，可謂是迎來了前端工程師的春天～～

我們的小程序： 
小程序的點(diǎn)在一個(gè)“小”字，對(duì)程序大小要求有限制，對(duì)頁面嵌套的層級(jí)有限制，不適合過于重的交互。小程序不能跳出，不能調(diào)起外部應(yīng)用，消息推送折疊在微信內(nèi)部，相比于原生App有著很大的局限性。

但是，相比于H5，小程序又有著不可忽視的優(yōu)勢(shì)，固定化的入口，豐富的組件，系統(tǒng)控件的接口權(quán)限，接近App的使用流暢度，微信強(qiáng)大的生態(tài)圈...

結(jié)合上面兩點(diǎn)，我們認(rèn)為：小程序＝固定入口＋有體系的H5

根據(jù)這一點(diǎn)，我們仔細(xì)斟酌，提煉出體育用戶的核心訴求，將體育小程序的第一階段功能定位為賽程查詢、數(shù)據(jù)、資訊推送，第二階段的功能定位為視頻點(diǎn)播、個(gè)性化提醒（關(guān)注、預(yù)約、定制）。

關(guān)于小程序的適配：

眾所周知，微信App運(yùn)行在Android、iphone、iPad等多種屏幕尺寸和分辨率的設(shè)備上，不同終端的微信小程序用的是同一套代碼，需要照顧到一個(gè)“小程序”在多種不同大小屏幕的使用體驗(yàn)，所以在設(shè)計(jì)排版時(shí)推薦柵格式排版。而在代碼實(shí)現(xiàn)方面，微信官方比較推薦用Flex、rpx來實(shí)現(xiàn)小程序的適配。 

Flex布局是2009年，W3C提出的一種新的方案，可以簡(jiǎn)便、完整、響應(yīng)式地實(shí)現(xiàn)各種頁面布局。目前，它已經(jīng)得到了所有瀏覽器的支持。

rpx單位是小程序中css的尺寸單位，可以根據(jù)屏幕寬度進(jìn)行自適應(yīng)，規(guī)定屏幕寬為750rpx。如iPhone6的屏幕像素為375px，則750rpx＝375px，1rpx＝0.5px。同時(shí)小程序也支持rem: 規(guī)定屏幕寬度為20rem；1rem = (750/20)rpx 。 

Flex與rpx搭配可以解決大部分的適配，但遇到極端寬高比的情況，就需要變動(dòng)元素的排放位置。而小程序不支持Media Query，那就要通過js來進(jìn)行不同樣式的切換。小程序里獲得屏幕寬高的接口是異步的，實(shí)現(xiàn)響應(yīng)式布局盡量在app.js里盡早執(zhí)行防止頁面抖動(dòng)。

關(guān)于小程序的生命周期：

小程序的框架程序包含一個(gè)描述整體程序的app 和多個(gè)描述頁面的page。其中，app由三個(gè)文件構(gòu)成，公共設(shè)置的app.json 、公共樣式的app.wxss、主體邏輯的app.js 。每個(gè)page由四部分組成，頁面設(shè)置page.json、頁面文件page.wxml、頁面樣式page.wxss、頁面主體邏輯page.js。

與H5開發(fā)一樣，我們可以根據(jù)需求在app.js和page.js里添加程序在生命周期每個(gè)階段相應(yīng)的事件。比如在頁面onLoad的時(shí)候進(jìn)行數(shù)據(jù)的加載，onShow的時(shí)候進(jìn)行數(shù)據(jù)的更新。

一個(gè)page的生命周期從onLoad開始，整個(gè)生命周期內(nèi)onLoad、onReady、onUnload這三個(gè)事件僅執(zhí)行一次，而onHide和onShow在每次頁面隱藏和顯示時(shí)都會(huì)觸發(fā)。當(dāng)用戶手動(dòng)觸發(fā)左上角的退出箭頭時(shí)，小程序僅觸發(fā)app.onHide，下次進(jìn)入小程序時(shí)會(huì)觸發(fā)app.onShow以及當(dāng)前page.onShow。僅當(dāng)小程序在后臺(tái)運(yùn)行超過一定時(shí)間未被喚起、或者用戶手動(dòng)在小程序的控制欄里點(diǎn)擊退出程序、或者小程序內(nèi)存占用過大被關(guān)閉時(shí)，小程序被銷毀，會(huì)觸發(fā)app.onUnload事件。

一個(gè)完整的小程序執(zhí)行的生命周期如下： 

關(guān)于小程序的架構(gòu)：

如圖，每個(gè)小程序分為兩個(gè)線程，view和appServer。其中view線程負(fù)責(zé)解析渲染頁面（wxml和wxss），而appServer線程負(fù)責(zé)運(yùn)行js。appServer線程運(yùn)行在jsCore中（安卓下運(yùn)行在X5中，開發(fā)工具中運(yùn)行在nwjs中），所以js不跑在webview里，不能直接操縱DOM和BOM，這就是為什么小程序沒有window全局變量。

那js如何操縱頁面？js與頁面的交互靠setData和事件觸發(fā)，js通過setData來改變頁面數(shù)據(jù)，頁面通過下發(fā)事件來觸發(fā)js中對(duì)應(yīng)的響應(yīng)事件。setData同時(shí)會(huì)改變當(dāng)前頁面的Page函數(shù)里的data對(duì)象，注意異步數(shù)據(jù)setData以后一定要update，不然頁面上的數(shù)據(jù)不會(huì)及時(shí)更新。

最初版本里，小程序的所有js跑在同一個(gè)作用域下，開發(fā)過程中一不小心定義了相同的變量名就會(huì)導(dǎo)致其他頁面的數(shù)據(jù)錯(cuò)誤。在我們的推動(dòng)下，現(xiàn)在每個(gè)小程序頁面都是一個(gè)獨(dú)立的作用域，命名空間互不沖突。有人問，那我們想要全局變量怎么辦？又沒有window。微信提供的解決方案是在app.js中注冊(cè)全局變量，在每個(gè)頁面中通過getApp()函數(shù)獲取。

關(guān)于小程序的開發(fā)：

小程序開發(fā)入門簡(jiǎn)單，按照官方文檔上給的簡(jiǎn)易教程，可以快速建立一個(gè)小程序。但是實(shí)際上手開發(fā)會(huì)發(fā)現(xiàn)這樣幾個(gè)問題：

小程序的開發(fā)工具支持簡(jiǎn)單的模塊化，page路徑可單獨(dú)設(shè)置，但是提交代碼包的大小有限制1M，而小程序沒有提供相應(yīng)的文件壓縮與合并。 
以前小程序框架的CSS 不支持 import（現(xiàn)在支持了?。?，所有樣式只能寫在一個(gè)文件里，不方便拆分，也不支持模塊化 
CSS中圖片不支持相對(duì)路徑，需使用線上地址或base64的，在開發(fā)階段不方便 
暫不支持es6（新版本也支持了！超哥棒棒噠） 
不支持LESS SASS POSTCSS 
頁面與頁面之間代碼復(fù)用性差

為此，我們引進(jìn)了webpack將開發(fā)目錄與發(fā)布目錄區(qū)分開來。webpack是一個(gè)前端資源加載／打包工具，它能把各種資源，例如JS（含JSX）、coffee、樣式（含less/sass）、圖片等都作為模塊來使用和處理。通過引入webpack，我們實(shí)現(xiàn)了對(duì)es6+sass+postcss的支持，更加靈活的模塊化體系，成功隔離了開發(fā)目錄和發(fā)布目錄。

如上圖所示，我們指定發(fā)布目錄到／pub，圖片和css抽取合并后生成wxss文件，例如allmatch頁面的資源文件全在component/allmatch文件夾內(nèi)，打包后生成的allmatch.wxss文件直接放在pub目錄下。

這里我要講一下，由于document、window對(duì)象的限制，Babel runtime相關(guān)、Commonchunk、code spliting、imports-loader等插件都不可用，想接入webpack的童鞋們要引起注意。在業(yè)務(wù)開始初期，這可花了我們好幾天在和新框架磨合（淚奔臉）～

webpack還有一個(gè)小問題，就是在調(diào)試的過程中會(huì)生成許多不必要的文件，為了解決這個(gè)問題，我們寫了一個(gè)清理發(fā)布文件夾的腳本，每次打包完成后會(huì)自動(dòng)運(yùn)行，清理非最終所需文件。

一些坑和經(jīng)驗(yàn)：

• page需在app.json里注冊(cè)才能被當(dāng)做頁面使用，利用這個(gè)現(xiàn)象可以創(chuàng)建一些公用template。
• 不要試圖去給view等標(biāo)簽設(shè)置樣式，會(huì)被過濾。
• document window等都不存在于jscore 中，所以大部分涉及dom操作的框架都不能直接拿來使用。
• 介于安全性考慮，new Function，eval 會(huì)被過濾掉。
• CSS 請(qǐng)用BEM的形式，因?yàn)閍pp里沒有自選擇器，為了防止微信提供的組件樣式被破壞，小程序也禁止使用層級(jí)選測(cè)器，最好提前養(yǎng)成好習(xí)慣。
• CSS里不要用圖片相對(duì)路徑，建議直接base64，wxml 里可以用圖片路徑。
• 關(guān)于接口，一年后服務(wù)器會(huì)只支持https協(xié)議的接口，所以，現(xiàn)在盡量統(tǒng)一為https。
• 關(guān)于登錄，目前小程序不支持cookie，而是采用前端利用微信提供的接口獲取登錄憑證code，server端再用code獲取密鑰session_key的方式對(duì)用戶數(shù)據(jù)完成加密解密，整個(gè)過程需要server端對(duì)已有的登錄體系進(jìn)行再次的封裝，而本地的登錄態(tài)可以利用微信提供的本地存儲(chǔ)進(jìn)行保存。

• 

• 關(guān)于開發(fā)工具的提交預(yù)覽功能，預(yù)覽功能需要在能訪問外網(wǎng)時(shí)才能使用，開發(fā)網(wǎng)不支持使用，自己生成的二維碼只有自己可以體驗(yàn)。這對(duì)測(cè)試造成了一定的困擾。

• image組件會(huì)有默認(rèn)圖片尺寸（320*240），無法完美適配寬高都不固定的多尺寸圖片。

關(guān)于我們：

短短一個(gè)多月，在小程序的開發(fā)過程中我們經(jīng)歷了許多，也成長(zhǎng)很多，在此非常感謝有這個(gè)機(jī)會(huì)發(fā)表自己的一點(diǎn)小見解，若有理解錯(cuò)誤的地方盡請(qǐng)更正。