國慶節(jié)尾巴上花了一點時間讀微信小程序的官方文檔,在對比之前自己做得Android,有了下面的內(nèi)容。這篇文章將圍繞下面幾個方面:
在我看來,開發(fā)一款app,需要做的主要是界面布局以及交互處理,然后是后面的業(yè)務(wù)邏輯處理。雖然平臺不同,但是任務(wù)都是趨同的。下面從這兩個大的方面進(jìn)行對比一下。
微信把這個小程序框架稱為“MINA”,并聲稱:
MINA(MINA IS NOT APP) 是在微信中開發(fā)小程序的框架。
MINA的目標(biāo)是通過盡可能簡單、高效的方式讓開發(fā)者可以在微信中開發(fā)具有原生APP體驗的服務(wù)。
MINA提供了自己的視圖層描述語言WXML和WXSS,以及基于JavaScript的邏輯層框架,并在視圖層與邏輯層間提供了數(shù)據(jù)傳輸和事件系統(tǒng),可以讓開發(fā)者可以方便的聚焦于數(shù)據(jù)與邏輯上。
個人覺得第三點說得特別好。大概說清楚了開發(fā)者要干什么。大概就是以寫Web的方式寫好前端,然后通過雙向數(shù)據(jù)綁定技術(shù)和業(yè)務(wù)端交互,業(yè)務(wù)端通過javascript代碼實現(xiàn)業(yè)務(wù)處理,必要時調(diào)用微信接口完成一些處理。
這里所說的生命周期函數(shù)是指的整個應(yīng)用以及每個頁面的聲明周期函數(shù),在Android中,對應(yīng)著App、Activity類,而在小程序中,對應(yīng)著App和Page兩個函數(shù)對象(注意,javascript是基于原型和構(gòu)造器的,而Java是基于類的,所以這里就造成了一些寫法的不同)。以App為例,下面是一個代碼實例:
每個小程序起起來時就會有一個App實例,同理每個頁面打開也會有一個Page實例(這個鏈接打開往下滑還有生命周期函數(shù)的圖解),我們只需要在這個實例中添加自己的邏輯即可,唯一不同的是這是在javascript這種語言上寫的(java和javascript的區(qū)別就像是雷鋒和雷峰塔,所以這里形式上的不同還是蠻大的)。
前面說了,寫視圖層的體驗有點像Web前端,主要是寫多了Android,習(xí)慣性地會把界面的樣式以及交互放在一塊兒寫(事實上就是你在xml上做的工作),而在Web端,需要html和css文件來共同完成。在小程序里面,對應(yīng)的是WXML(WeiXin Markup Language)和WXSS(WeiXin Style Sheets),注意雖然模式和web很像,但是在形式上算是微信自己開發(fā)的一套(所以你需要使用他們自己的標(biāo)簽)。具體來講,你需要做兩件事:
基本上,視圖層很像在寫Web端。不過你也看到了,和Android比起來,限制因素在于微信給你提供了組件,然后你最多改改樣式,更多的像自定義組件什么的就不可能了。
不同于Android有一堆的組件(Activity、Service..)來支撐邏輯層,小程序就一個Page()函數(shù)(類似與App()函數(shù),在框架里面填邏輯),所以顯得很簡單?;旧?,數(shù)據(jù)通過雙向綁定進(jìn)行傳遞和刷新的,然后在page內(nèi)可以完成一些交互處理,更多的能力(訪問網(wǎng)絡(luò)、存儲)是通過微信的API完成的,這些api以wx.
開頭,目前來看,不是太多,所以可以很快看完,當(dāng)然也意味著其實可以完成的工作還著實有限,這個后面說。
整體來說,小程序的工程組織還是蠻清晰的,MINA程序包含一個描述整體程序的app和多個描述各自頁面的page,一個MINA程序主體部分由三個文件組成,必須放在項目的根目錄,是app.js
,app.json
,app.wxss
,分別用作生命周期函數(shù)、配置文件和樣式文件,一個MINA頁面由四個文件組成,是.js
,.wxml
,.json
,.wxss
,分別用作生命周期函數(shù)、布局文件、配置文件和樣式文件,他們需要通過同名且放在同名文件夾下(方便框架通過名字路由)。比起Android來,套路應(yīng)該是固定而簡單得多。
再回頭看看Android開發(fā),突然覺得可以玩的簡直是太多了…下面簡單描述一下,肯定是不全的。
App、Activity是肯定的,其實套路和小程序還是差不多的。只不過組織形式是類而不是函數(shù)對象。之前說了,這是因為Js和Java語言特性造成的。
通常來講,Android的界面在.xml
文件中定義,其實仔細(xì)想想就會發(fā)現(xiàn),在文件中,我們是同時定義了布局,和交互邏輯的,這是因為本質(zhì)上這些.xml
聲明都是View類的子類,我們通過重寫View的聲明周期方法來完成了對齊的樣式(onDraw以及LaoutParams)、以及交互的定義(各種on..listener)。所以在.xml
中更像是對這些對象進(jìn)行一系列實例化。至于雙向數(shù)據(jù)綁定,Android也開始支持了
這一層還是要復(fù)雜得多..放到后面對比來說吧。
…..不想說了,一方面寫法多,一方面相對于小程序也蠻復(fù)雜的。
要怎么對比呢?讀Android的開發(fā)文檔我之前看了一個星期,而微信小程序的文檔也就兩三個小時,從體量上說就知道無意Android功能要強(qiáng)大的多。所以基本上小程序能做的以外就是不能做的,這句話聽起來很廢話,但事實上是因為微信給的API有限,所以你基本上能把自己需求列出來,查一下API是否給出,沒給出的話基本上還是算了吧。下面我根據(jù)Android的APIguide(科學(xué)上網(wǎng))來羅列下小程序的局限。
這個應(yīng)該是最直觀的一點,因為實際上你所使用的視圖層是被微信進(jìn)一步封裝了的,小程序自定義控件還是蠻復(fù)雜的,因為MINA給出了繪圖(但是只能在<canvas/>
上作畫)和動畫(類似于Android中的屬性動畫)的功能,所以或許存在理論上的可能性。
這個要特別拿來說一下,官網(wǎng)原文是:
每個微信小程序都可以有自己的本地緩存,可以通過wx.setStorage(wx.setStorageSync)、wx.getStorage(wx.getStorageSync)、wx.clearStorage(wx.clearStorageSync)可以對本地緩存進(jìn)行設(shè)置、獲取和清理。
注意: localStorage是永久存儲的,但是我們不建議將關(guān)鍵信息全部存在localStorage,以防用戶換設(shè)備的情況。
所以微信小程序使用的是緩存而非有一個自己的數(shù)據(jù)庫,這里的緩存應(yīng)該類似于android的SharedPreference之類的,用鍵值對存的。而且小程序只能對文件進(jìn)行存的操作。所以說對于那種需要數(shù)據(jù)庫的應(yīng)用,小程序是不適合的。
Android中,Service是蠻重要的類,然后多線程與異步任務(wù)雖然復(fù)雜,但是能完成許多工作,但是小程序是不具有這種能力的,當(dāng)然其實你可以看到你也是可以異步讀寫的…所以微信應(yīng)該是只提供了部分功能的異步能力。
寫到這里,主要是想到了之前應(yīng)用需要鬧鐘模塊,需要讓系統(tǒng)定時通知應(yīng)用以完成特定的事件。而小程序其實是封裝在微信這個應(yīng)用之內(nèi)的應(yīng)用,所以理論上它是可以獲得系統(tǒng)服務(wù)的,但是,如果微信不給接口一切都白說,從API文檔中可以看到,微信還是提供了位置、網(wǎng)絡(luò)狀態(tài)等系統(tǒng)信息的,不過像通知這些服務(wù),是暫時沒有的。
這里的概念主要是對應(yīng)Android的隱式意圖和ContentProvider,這里Android提供了一種能力,讓應(yīng)用程序之間可以相互調(diào)用甚至相互操作數(shù)據(jù)(比如A打開B的音樂播放器,將A的網(wǎng)頁內(nèi)容保存到B的便簽中..這里主要是場景可擴(kuò)展),而微信中,這種能力被具體場景化了,比如你仍然可以調(diào)用相機(jī)拍照(微信調(diào)用隱式意圖幫你實現(xiàn)),其他的場景你卻無法實現(xiàn),因為微信沒有做這一層封裝。
這一點不知道要不要說..因為微信小程序其實就是一種”內(nèi)嵌網(wǎng)頁”的解決方案?只不過使用了類似于hybrid的解決方案。
在Android中許多業(yè)務(wù)已經(jīng)被MINA封裝了(網(wǎng)絡(luò)請求、websocket…)所以一方面你實現(xiàn)功能的成本降低了,另一方面這一部分優(yōu)化的空間并不是那么大。
因為我還是個Js的初學(xué)者,所以暫時不知道如何在微信小程序中使用輪子。但微信和web前端那一套還真不太一樣,所以也應(yīng)該沒法直接使用一些開源庫。(10.8更新,今天看到了LeanCloud已經(jīng)可以支持js開發(fā)了..也說明了可行性)
如前所說,如果說一般應(yīng)用的容器(不知道這個比喻恰不恰當(dāng))是操作系統(tǒng),那么小程序的容器則是操作系統(tǒng)下的一款應(yīng)用,自然而然的,它本身就是某個應(yīng)用下的一個子模塊。而這個模塊能有多少功能取決于微信寫了多少接口。
另一方面,因為這個容器是微信,至少我們可以假設(shè)這些接口的跨平臺特性,很可能我們調(diào)用的這些接口,會比我們自己寫android調(diào)用系統(tǒng)接口更穩(wěn)定,甚至依附于微信,我們可能少了諸如在某些手機(jī)系統(tǒng)中管理應(yīng)用生命周期、避免程序被殺死的麻煩。
總之,我的感受是