理解開(kāi)發(fā)平臺(tái)的特性，一個(gè)不錯(cuò)的角度就是從編程模式入手，看在這個(gè)平臺(tái)上開(kāi)發(fā)，需要如何書(shū)寫和組織自己的代碼，進(jìn)而搞清楚三個(gè)問(wèn)題：
數(shù)據(jù)如何獲取；
界面如何呈現(xiàn)；
交互如何傳導(dǎo)。
換而言之，就是從 MVC（Model-View-Controller）的視角去拆解這個(gè)平臺(tái)的特性，從而理解其開(kāi)發(fā)有何特點(diǎn)。
數(shù)據(jù)如何獲取
程序的本質(zhì)，可說(shuō)就是數(shù)據(jù)的呈現(xiàn)和加工。所以，看一個(gè)客戶端開(kāi)發(fā)平臺(tái)的基本能力，首先就要看能把哪些數(shù)據(jù)放在上面處理，有哪些局限？如果缺少了必要的數(shù)據(jù)獲取方式，那對(duì)于開(kāi)發(fā)者而言，巧婦也難為無(wú)米之炊。
從這點(diǎn)看，小程序提供的數(shù)據(jù)獲取方式非常豐富，大概涵蓋：
通過(guò) HTTPS 請(qǐng)求去服務(wù)端獲取數(shù)據(jù)。支持 HTTPS 是最基本的，小程序?qū)?HTTPS 有限制，除了要求通信協(xié)議是 HTTPS，出現(xiàn)的域名必須提前預(yù)設(shè)之外，還將應(yīng)用層協(xié)議限定到了 JSON 格式下。這一點(diǎn)，可能比任何一個(gè)已有客戶端平臺(tái)都更為嚴(yán)苛。站在小程序的平臺(tái)角度來(lái)看，通過(guò)這樣的協(xié)議規(guī)定，對(duì)應(yīng)用中流動(dòng)的數(shù)據(jù)有了更強(qiáng)的管控能力；而對(duì)于開(kāi)發(fā)者而言，則需要花些時(shí)間去調(diào)整自己的服務(wù)協(xié)議以便適應(yīng)小程序的要求。
可以在本地文件系統(tǒng)上存取數(shù)據(jù)。小程序提供了豐富的 API 供開(kāi)發(fā)者在手機(jī)系統(tǒng)上存取文件?？捎帽镜匚募?lái)做緩存、狀態(tài)記憶等，為開(kāi)發(fā)提供了便利。
可以讀寫設(shè)備中的一部分信息。小程序開(kāi)放了一些 API，幫助開(kāi)發(fā)者獲得設(shè)備上的基本信息，比如手機(jī)型號(hào)、屏幕尺寸、網(wǎng)絡(luò)狀態(tài)等。較為有價(jià)值的是可以選擇獲取手機(jī)上的圖片等多媒體文件，這給做圖像應(yīng)用提供了可能；并且，它還提供了羅盤、重力感應(yīng)器、地理位置等信息，對(duì)開(kāi)發(fā)者理解用戶所處的環(huán)境大有裨益。
從上面的介紹不難看出，小程序中的數(shù)據(jù)獲取方式，和一般瀏覽器提供的相仿（也就是和 HTML5 應(yīng)用能獲取的信息），比原生的客戶端更局限一些，但對(duì)于絕大多數(shù)的應(yīng)用而言足夠用了。
除此之外，小程序提供了微信生態(tài)中的一些數(shù)據(jù)，比如賬號(hào)信息等。這對(duì)于微信龐大的生態(tài)而言，只是非常小的一部分?jǐn)?shù)據(jù)，但卻是開(kāi)發(fā)小程序應(yīng)用中最值得利用的數(shù)據(jù)。
舉個(gè)例子，在其他平臺(tái)上，如果想要獲取微信的賬號(hào)信息，需要通過(guò)一次用戶授權(quán)。假如用戶暫時(shí)不想提供，則會(huì)使程序呈現(xiàn)“未登錄”狀態(tài)，給整個(gè)服務(wù)的展開(kāi)帶來(lái)困難。而在小程序中，只要用戶點(diǎn)開(kāi)，就意味著完成了授權(quán)，開(kāi)發(fā)者可以直接讀取到小程序的賬號(hào)信息，并同步到自己的服務(wù)端作為該用戶的身份標(biāo)識(shí)，從而實(shí)現(xiàn)“始終登錄”的狀態(tài)，使得后續(xù)服務(wù)可以更好地提供。
界面如何呈現(xiàn)
小程序剛發(fā)布的時(shí)候，一片人開(kāi)始驚呼 HTML5 的時(shí)代就要到來(lái)了，因?yàn)樾〕绦蛟诮缑鎸邮褂昧?HTML/CSS/JavaScript 這套 HTML5 的技術(shù)棧。但很快，隨著聰明的程序員們對(duì)小程序的理解進(jìn)一步加深，就發(fā)現(xiàn)小程序所說(shuō)的 HTML/CSS/JavaScript 和 HTML5 中的完全不是一回事，其差異基本等同于 Java 和 JavaScript。
在小程序中，和 HTML 對(duì)應(yīng)的是 WXML，保留下來(lái)的只有 HTML 的概念，而傳統(tǒng)的<div>、<a>標(biāo)簽都完全被拋棄了。和 Facebook 的 React 類似，小程序引入了自己的 HTML 標(biāo)簽，它和 <article〉、<section> 這樣的語(yǔ)義標(biāo)簽不同，小程序中的標(biāo)簽更像是傳統(tǒng)客戶端開(kāi)發(fā)中的組件（或者叫控件），每個(gè)組件都有自己背后的職能和使用方式。比如：如果需要展示圖片，就只能用標(biāo)簽，其他的都無(wú)法承載。而如果需要提供可選的文本，則只能使用<text>標(biāo)簽等。
這樣的方式帶來(lái)最大的問(wèn)題就是傳統(tǒng)的 HTML 頁(yè)面都無(wú)法在小程序中呈現(xiàn)（而小程序正好，沒(méi)提供類似 WebView 的客戶端控件）。比如有大量的內(nèi)容網(wǎng)站，其文章內(nèi)容都是存儲(chǔ)為一個(gè) HTML 片段，無(wú)法直接呈現(xiàn)在小程序中。如果需要展示，一個(gè)思路是構(gòu)建中間服務(wù)，將 HTML 轉(zhuǎn)譯成一種更簡(jiǎn)單利于渲染的中間格式數(shù)據(jù)，然后，在小程序端把中間格式的數(shù)據(jù)轉(zhuǎn)換成小程序的標(biāo)簽進(jìn)行呈現(xiàn)。我們?cè)谧觥拜p芒生活”的時(shí)候，正好設(shè)計(jì)并實(shí)現(xiàn)了一個(gè)轉(zhuǎn)義服務(wù)，將任意一個(gè) HTML 頁(yè)面轉(zhuǎn)換成中間格式（內(nèi)部名是 RAML），解決了內(nèi)容性 HTML 頁(yè)在小程序上的呈現(xiàn)問(wèn)題，
和 HTML 相比，小程序的 WXSS 算是比較完整地保留了 CSS 的特征，這一點(diǎn)還蠻出乎意料。WXSS 在語(yǔ)義上最大的不同，一是在于它支持了相對(duì)尺寸單位 rpx（responsive pixel），每 750rpx 等價(jià)于當(dāng)前設(shè)備的屏幕寬度，它的引入，把那種繁復(fù)的屏幕尺寸適配變得簡(jiǎn)單了不少。而和 CSS 的另一個(gè)不同是它更像傳統(tǒng)控件樣式用法，不支持 CSS3 那么多的選擇器，使用中更多的是一個(gè)控件一個(gè) class。
小程序中雖然支持 ES6 標(biāo)準(zhǔn)的 JavaScript，但窗口級(jí)的 JavaScript 卻完全被廢棄掉了，開(kāi)發(fā)者無(wú)法用 JavaScript 去調(diào)用 window、document 對(duì)象來(lái)修改界面元素完成邏輯。小程序中的 JavaScript 其實(shí)直接對(duì)應(yīng) Node.js 的用法，用來(lái)完成后臺(tái)業(yè)務(wù)邏輯，而不是直接控制交互。小程序的這個(gè)設(shè)計(jì)，使其可以用到 Virtual Dom 的方式來(lái)渲染界面，讓界面數(shù)據(jù)更新時(shí)的性能優(yōu)化成為可能，但付出的代價(jià)就是少了窗口級(jí) JavaScript 的那層膠水黏合，使得很多功能的開(kāi)發(fā)變得極其呆板和繁復(fù)。
交互如何傳導(dǎo)
所謂交互的傳導(dǎo)，是當(dāng)用戶和界面發(fā)生交互時(shí)，平臺(tái)框架通過(guò)何種方式告訴業(yè)務(wù)層，并將處理后的變化呈現(xiàn)回交互界面上。如果把 WXSS + WXML 繪制的頁(yè)面看成“前端”，把 JavaScript 撰寫的業(yè)務(wù)邏輯看成“后端”，你會(huì)發(fā)現(xiàn)，小程序的前后端交互特別像 Web 1.0 的模式，前端把交互行為封裝成事件（event）發(fā)送到后端，后端處理完成后，通過(guò) setData 方法將數(shù)據(jù)回傳到前端，
小程序提供的 Events，基礎(chǔ)的有類似單擊、長(zhǎng)按、觸摸、滑動(dòng)等，對(duì)于視頻播放器等控件，還有監(jiān)聽(tīng)播放、暫停等。這些事件比較基礎(chǔ)，沒(méi)有更高級(jí)的手勢(shì)、多點(diǎn)觸控等相關(guān)事件，但也還足夠讓開(kāi)發(fā)者具體了解用戶的輸入，進(jìn)而做出響應(yīng)。 而小程序給界面響應(yīng)的唯一方式，是通過(guò) Page 中的 setData API 對(duì)界面上的數(shù)據(jù)進(jìn)行更新，小程序會(huì)比較兩次調(diào)用期間數(shù)據(jù)的變化，來(lái)決策需要更新哪部分的交互界面。開(kāi)發(fā)小程序的坑
開(kāi)發(fā)小程序的日子，也是一個(gè)踩坑的歷程。簡(jiǎn)單總結(jié)，小程序中的坑大概來(lái)自這幾個(gè)方面：
Web 兼容性。小程序引入了 HTML/CSS 作為技術(shù)棧，并在其基礎(chǔ)上進(jìn)行了定制。很多開(kāi)發(fā)中的問(wèn)題都來(lái)自于“定制”，因?yàn)槟悴⒉恢滥牟糠质潜欢ㄖ?，哪部分是被繼承了。比如，你用了一個(gè) CSS 語(yǔ)法，發(fā)現(xiàn)并不生效，或者效果和瀏覽器中的不一樣，于是，只能換一個(gè)寫法，結(jié)果很有可能又會(huì)繼續(xù)發(fā)現(xiàn)，這個(gè)新的寫法可能效果也不對(duì)，于是只能繼續(xù)嘗試，如此反復(fù)，可能會(huì)消耗大量的時(shí)間。
開(kāi)發(fā)環(huán)境不穩(wěn)定。小程序的開(kāi)發(fā)，是基于微信自制的 IDE，但當(dāng)下，IDE 的穩(wěn)定性、易用性都非常差，時(shí)常出現(xiàn) Bug，你以為是程序?qū)戝e(cuò)了，但其實(shí)，是 IDE 的 Bug，重啟一下 IDE，一切都迎刃而解了。于是，當(dāng)你日后開(kāi)發(fā)小程序時(shí)出現(xiàn)某種異樣，先重啟 IDE，再看問(wèn)題還在不在，也許是種更節(jié)省時(shí)間的方式。
缺少真機(jī)調(diào)試環(huán)境。小程序的運(yùn)行時(shí)其實(shí)就是微信，微信幾乎沒(méi)提供任何真機(jī)上的調(diào)試工具（也不能說(shuō)完全沒(méi)有，有一個(gè)只能在真機(jī)上瞪著眼睛看的日志框）。在模擬器中調(diào)試好的程序，可能在真機(jī)上運(yùn)行起來(lái)并不如預(yù)期。比如，我們碰到過(guò)真機(jī)上白屏、位置錯(cuò)亂、動(dòng)畫(huà)效果不對(duì)，以及 Android 上至今還不能運(yùn)行等問(wèn)題。這對(duì)于稍微復(fù)雜的程序而言，頗為夢(mèng)魘，想做一些細(xì)粒度的調(diào)整和優(yōu)化，基本只能靠猜。
閉源且缺少學(xué)習(xí)資料。小程序整體上是閉源狀態(tài)（雖然模擬器和 IDE 部分可以通過(guò)反編譯來(lái)看），且缺少足夠的學(xué)習(xí)資料。如果一旦碰到控件如何使用、為什么這么用不對(duì)之類的問(wèn)題，就只能靠不停地試來(lái)解決，也需要耗費(fèi)大量時(shí)間。
簡(jiǎn)而言之，作為一個(gè)新的開(kāi)發(fā)平臺(tái)，微信小程序從本身的穩(wěn)定性，以及配套的工具鏈上都不算完善。對(duì)于早期開(kāi)發(fā)者而言，需要耗費(fèi)額外的精力去嘗試和探索，但這也許就是一個(gè)新平臺(tái)的價(jià)值和代價(jià)吧。
熱門推薦: 上海微信小程序 餐飲小程序 支付寶小程序 百度小程序 電商小程序?
?
??
