比如,大量的內(nèi)容網(wǎng)站,其文章內(nèi)容都是存儲為一個 Html 片段的,這樣就無法直接呈現(xiàn)在小程序中。如果需要展示,一個思路是構(gòu)建一個中間服務(wù),將 Html 轉(zhuǎn)譯成一種更簡單利于渲染的中間格式數(shù)據(jù),然后,在小程序端把中間格式的數(shù)據(jù)轉(zhuǎn)換成小程序的標簽進行呈現(xiàn)。我們在做 [輕芒生活](http://s.qingmang.mobi/10c) 的時候,正好設(shè)計并實現(xiàn)了一個轉(zhuǎn)義服務(wù),將任意一個 Html 頁面轉(zhuǎn)換成中間格式(內(nèi)部名是 RAML),解決了內(nèi)容性 Html 頁在小程序上的呈現(xiàn)問題。
(在小程序中呈現(xiàn) Html 內(nèi)容頁)
和 Html 相比,小程序的 **WXSS** 算是比較完整的保留了 CSS 的特征,這一點還蠻出乎意料的。WXSS 在語義上***的不同,一是在于它支持了相對尺寸單位 `rpx` ,每 750rpx 等價于當前設(shè)備的屏幕寬度。這個相對尺寸單位的引入,把那種繁復(fù)的屏幕尺寸適配變得簡單了不少。而和 CSS 的另一個不同,是它更像傳統(tǒng)控件樣式用法,不支持 CSS3 那么多的選擇器,使用中,更多的是一個控件一個 class 這樣來使用。
小程序中雖然支持 ES6 標準的 Javascript,但窗口級的 Javascript 在小程序中完全被廢棄掉了,開發(fā)者無法用 Javascript 去調(diào)用 window、document 對象來修改界面元素完成邏輯。小程序中的 Javascript 其實直接對應(yīng) node.js 的用法,用來完成后臺業(yè)務(wù)邏輯,而不是直接控制交互。小程序的這個設(shè)計,使其可以用到 virtual dom 的方式來渲染界面,讓界面數(shù)據(jù)更新時的性能優(yōu)化成為可能,但付出的代價就是少了窗口級 Javscript 的那層膠水的黏合,使得很多功能的開發(fā)變得極其呆板和繁復(fù)。
交互如何傳導(dǎo)?
所謂交互的傳導(dǎo),是當用戶和界面發(fā)生交互式,平臺框架通過何種方式告訴業(yè)務(wù)層,并將處理后的變化呈現(xiàn)回交互界面上。如果把 WXSS + WXML 繪制的頁面看成 “前端”,把 Javascript 撰寫的業(yè)務(wù)邏輯看成 “后端”,你會發(fā)現(xiàn),小程序的前后端交互特別像 Web 1.0 的模式,前端把交互行為封裝成 **事件(event)** 發(fā)送到后端,后端處理完成后,通過 **setData** 方法將數(shù)據(jù)回傳到前端。
(小程序的交互傳導(dǎo))
小程序提供的 Events,基礎(chǔ)的有類似單擊、長按、觸摸、滑動,等等,對于視頻播放器等控件,還有監(jiān)聽播放、暫停等等。這些事件涵蓋算是比較基礎(chǔ)的,沒有更高級的手勢、多點觸控等相關(guān)事件,但也還是足夠讓開發(fā)者具體了解用戶的輸入,進而做出響應(yīng)。
而小程序給界面相應(yīng)的唯一方式,是通過 Page 中的 setData API 對界面上的數(shù)據(jù)進行更新, **小程序會比較兩次調(diào)用期間數(shù)據(jù)的變化** ,來決策需要更新哪部分的交互界面。
舉個實際的例子,假設(shè)開發(fā)者需要做一個滑動切換頁面的效果,在小程序中該如何實現(xiàn)?首先,是將變量數(shù)據(jù)引入渲染頁面:
可以看到, `distance` 是一個模版參數(shù),它初始值為 0,表示移動的距離。通過 **bindtouchstart** 等函數(shù)綁定上 Javascript 的方法,將事件回傳。
- movePage: function(event) {
- var status = {
- needUpdate: false,
- distance: 0
- }
- // 處理各種事件,計算是否需要刷新,和移動方向
- if ("touchstart" === event.type) {
- // 開始計算移動
- ...
- } else if ("touchend" === event.type) {
- // 判定移動的距離是否足夠.
- ...
- } else if ("touchcancel" === event.type) {
- // 被打斷就算了.
- ...
- } else if ("touchmove" === event.type) {
- // 計算移動距離
- ...
- }
- // 根據(jù)移動的距離,來更新界面
- if (status.needUpdate) {
- this.setData({
- distance: status.distance
- })
- }
- }
而在 Javascript 一端,則捕獲事件、計算偏移量,然后將新的偏移量送到前端界面。
從這里可以看到,小程序的交互模式,是典型的單向模式,前端回傳事件,數(shù)據(jù)單向的推到前端,而不是通過類似 “變量” “狀態(tài)” 這樣的方式來告知。這樣的模式下,開發(fā)者對界面變化的控制往往不可能太精準,整個核心,都依賴小程序?qū)纱螖?shù)據(jù)變化的 diff 計算,這個會最終影響整個交互的性能。
小程序開發(fā)模式的特點
至此,我們可以來總結(jié)一下小程序開發(fā)的一些特點了。整體來看,小程序是借了 Html5 的技術(shù)棧,行了傳統(tǒng)客戶端開發(fā)的模式,這一點和 React 等平臺會比較相近,可以視為 HTMLl5 的一個新分支。
從設(shè)計思路看,小程序做了大量的 “限制”,***的限制,是開發(fā)者其實是無法通過 Javascript 這樣的編程語言,直接對界面進行控制,而是通過數(shù)據(jù)驅(qū)動來間接實現(xiàn)。這對于缺少開發(fā)經(jīng)驗的人而言,是有益的事情,因為這降低了理解的門檻,但對于復(fù)雜的應(yīng)用而言,這個模式開發(fā)起來比較呆板,往往是一個變化多處修改,增加了理解代碼的成本。
開發(fā)小程序的坑
開發(fā)小程序的日子,也是一個踩坑的歷程。簡單總結(jié),小程序中的坑大概來自這幾個方面:
和 Web 的兼容性。小程序引入了 Html/CSS 做為技術(shù)棧,并在其基礎(chǔ)上進行了定制。很多開發(fā)中的問題都來自于 “定制”,因為你并不知道哪部分就被定制了,哪部分是被繼承了。比如,你用了一個 CSS 語法,發(fā)現(xiàn)并不生效,或者效果和瀏覽器中的不一樣,于是,你只能換一個寫法,結(jié)果很有可能,又會繼續(xù)發(fā)現(xiàn),這個新的寫法可能效果也不對,于是你只能繼續(xù)嘗試,如此反復(fù),可能會消耗大量的時間。
開發(fā)環(huán)境不穩(wěn)定。小程序的開發(fā),是基于微信自制的一個 IDE,但當下,IDE 的穩(wěn)定性、易用性都非常之差,時常出現(xiàn) Bug,你以為是你的程序?qū)戝e了,但其實,是 IDE 的 Bug,重啟一下 IDE,一切都引刃而解了。于是,當你日后開發(fā)小程序時出現(xiàn)某種異樣,先重啟 IDE,再看問題還在不在,也許是種更節(jié)省時間的方式。
缺少真機調(diào)試環(huán)境。小程序的運行時其實就是微信,微信幾乎沒提供任何真機上調(diào)試工具給你(也不能說完全沒有,有一個只能在真機上瞪著眼睛看的日志框)。你在模擬器中調(diào)試好的程序,可能在真機上運行起來并不如預(yù)期。比如,我們碰到過真機上白屏、位置錯亂、動畫效果不對,以及 Android 上至今還不能運行,等等問題。這對于稍微復(fù)雜的程序而言,頗為夢魘,想做一些細粒度的調(diào)整和優(yōu)化,基本只能靠猜。
閉源且缺少學習資料。小程序整體上是閉源狀態(tài)(雖然模擬器和 IDE 部分可以通過反編譯來看),且缺少足夠的學習資料,如果一旦碰到控件如何使用、為什么這么用不對,之類的問題,就只能靠不停的試來解決,也需要耗費大量時間。
***介紹下「輕芒小程序+」?!篙p芒小程序+」是由輕芒團隊提出的小程序解決方案,它將替內(nèi)容創(chuàng)業(yè)者免費搭建屬于自己的微信小程序,其創(chuàng)建的小程序在內(nèi)容發(fā)布之外,還將具有評論、筆記、付費閱讀等特色功能。輕芒小程序+ 不打算創(chuàng)建一個新的內(nèi)容平臺,而是將內(nèi)容創(chuàng)業(yè)者現(xiàn)有的自媒體賬號轉(zhuǎn)化成微信小程序。內(nèi)容創(chuàng)業(yè)者只要照常更新自媒體,這些內(nèi)容就能自動更新到小程序。
簡而言之,做為一個新的開發(fā)平臺,微信小程序從本身的穩(wěn)定性,以及配套的工具鏈上都不算完善,這對于早期開發(fā)者而言,需要耗費額外精力去嘗試和探索,但這也許就是一個新平臺的價值和代價吧。
網(wǎng)站標題:通過編程模式起底小程序開發(fā)技術(shù)特點
文章起源:http://m.fisionsoft.com.cn/article/dpsodds.html


咨詢
建站咨詢

