寫在前面：

小程序的定義：

很多人問我，說的這么熱鬧，小程序到底是個什么東西?下面我先簡單介紹一下。

官方這么定義小程序：

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

小程序是一個由微信提供開發組件與開發規則，以js為主要開發語言，最終運行在微信App內的輕量型應用，有著即掃即用的特點。它不是H5，但與H5一樣，小程序有著開發上手快、開發成本低的特性;它不是App，卻有著同樣的流暢度。小程序的出現使前端工程師可觸及的領域進一步增大，可謂是迎來了前端工程師的春天～～

我們的小程序：

小程序的點在一個“小”字，對程序大小要求有限制，對頁面嵌套的層級有限制，不適合過于重的交互。小程序不能跳出，不能調起外部應用，消息推送折疊在微信內部，相比于原生App有著很大的局限性。

但是，相比于H5，小程序又有著不可忽視的優勢，固定化的入口，豐富的組件，系統控件的接口權限，接近App的使用流暢度，微信強大的生態圈...

結合上面兩點，我們認為：小程序=固定入口+有體系的H5

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

關于小程序的適配：

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

Flex布局是2009年，W3C提出的一種新的方案，可以簡便、完整、響應式地實現各種頁面布局。目前，它已經得到了所有瀏覽器的支持。

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

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

關于小程序的生命周期：

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

與H5開發一樣，我們可以根據需求在app.js和page.js里添加程序在生命周期每個階段相應的事件。比如在頁面onLoad的時候進行數據的加載，onShow的時候進行數據的更新。

一個page的生命周期從onLoad開始，整個生命周期內onLoad、onReady、onUnload這三個事件僅執行一次，而onHide和onShow在每次頁面隱藏和顯示時都會觸發。當用戶手動觸發左上角的退出箭頭時，小程序僅觸發app.onHide，下次進入小程序時會觸發app.onShow以及當前page.onShow。僅當小程序在后臺運行超過一定時間未被喚起、或者用戶手動在小程序的控制欄里點擊退出程序、或者小程序內存占用過大被關閉時，小程序被銷毀，會觸發app.onUnload事件。

一個完整的小程序執行的生命周期如下：

關于小程序的架構：

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

那js如何操縱頁面?js與頁面的交互靠setData和事件觸發，js通過setData來改變頁面數據，頁面通過下發事件來觸發js中對應的響應事件。setData同時會改變當前頁面的Page函數里的data對象，注意異步數據setData以后一定要update，不然頁面上的數據不會及時更新。

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

關于小程序的開發：

小程序開發入門簡單，按照官方文檔上給的簡易教程，可以快速建立一個小程序。但是實際上手開發會發現這樣幾個問題：

小程序的開發工具支持簡單的模塊化，page路徑可單獨設置，但是提交代碼包的大小有限制1M，而小程序沒有提供相應的文件壓縮與合并。

以前小程序框架的CSS不支持 import(現在支持了!)，所有樣式只能寫在一個文件里，不方便拆分，也不支持模塊化

CSS中圖片不支持相對路徑，需使用線上地址或base64的，在開發階段不方便

暫不支持es6(新版本也支持了!超哥棒棒噠)

不支持LESS SASS POSTCSS

頁面與頁面之間代碼復用性差

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

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

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

webpack還有一個小問題，就是在調試的過程中會生成許多不必要的文件，為了解決這個問題，我們寫了一個清理發布文件夾的腳本，每次打包完成后會自動運行，清理非最終所需文件。

一些坑和經驗：

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

關于開發工具的提交預覽功能，預覽功能需要在能訪問外網時才能使用，開發網不支持使用，自己生成的二維碼只有自己可以體驗。這對測試造成了一定的困擾。

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

關于我們：

短短一個多月，在小程序的開發過程中我們經歷了許多，也成長很多，在此非常感謝有這個機會發表自己的一點小見解，若有理解錯誤的地方盡請更正。