微信小程序和androids開發對比分析

首頁 > 官网开云 > 小程序常見問題

時間：2016-10-18 17:00:00

國慶節尾巴上花了一點時間讀微信小程序的官方文檔,在對比之前自己做得androids，有了下麵的內(nei) 容。這篇文章將圍繞下麵幾個(ge) 方麵：

從開發模式（過程）上對比androids和小程序，比較兩種”模式”的異同
從實現功能上對比，主要是看看微信小程序的局限
自己的一些看法，微信的優勢

開發過程上的對比

在我看來,開發一款app，需要做的主要是界麵布局以及交互處理,然後是後麵的業(ye) 務邏輯處理。雖然平台不同，但是任務都是趨同的。下麵從(cong) 這兩(liang) 個(ge) 大的方麵進行對比一下。

小程序

微信把這個(ge) 小程序框架稱為(wei) “MINA”，並聲稱：

MINA(MINA IS NOT APP) 是在微信中開發小程序的框架。
MINA的目標是通過盡可能簡單、高效的方式讓開發者可以在微信中開發具有原生APP體(ti) 驗的服務。
MINA提供了自己的視圖層描述語言WXML和WXSS，以及基於(yu) JavaScript的邏輯層框架，並在視圖層與(yu) 邏輯層間提供了數據傳(chuan) 輸和事件係統，可以讓開發者可以方便的聚焦於(yu) 數據與(yu) 邏輯上。

個(ge) 人覺得第三點說得特別好。大概說清楚了開發者要幹什麽(me) 。大概就是以寫(xie) Web的方式寫(xie) 好前端，然後通過雙向數據綁定技術和業(ye) 務端交互,業(ye) 務端通過javascript代碼實現業(ye) 務處理,必要時調用微信接口完成一些處理。

一些生命周期函數

這裏所說的生命周期函數是指的整個(ge) 應用以及每個(ge) 頁麵的聲明周期函數,在androids中，對應著App、Activity類，而在小程序中,對應著App和Page兩(liang) 個(ge) 函數對象（注意,javascript是基於(yu) 原型和構造器的，而Java是基於(yu) 類的，所以這裏就造成了一些寫(xie) 法的不同）。以App為(wei) 例,下麵是一個(ge) 代碼實例:

App({ onLaunch: function () { console.log('App Launch') }, onShow: function () { console.log('App Show') }, onHide: function () { console.log('App Hide') } })

每個(ge) 小程序起起來時就會(hui) 有一個(ge) App實例，同理每個(ge) 頁麵打開也會(hui) 有一個(ge) Page實例（這個(ge) 鏈接打開往下滑還有生命周期函數的圖解），我們(men) 隻需要在這個(ge) 實例中添加自己的邏輯即可,唯一不同的是這是在javascript這種語言上寫(xie) 的（java和javascript的區別就像是雷鋒和雷峰塔，所以這裏形式上的不同還是蠻大的）。

視圖層代碼

前麵說了，寫(xie) 視圖層的體(ti) 驗有點像Web前端，主要是寫(xie) 多了androids，習(xi) 慣性地會(hui) 把界麵的樣式以及交互放在一塊兒(er) 寫(xie) （事實上就是你在xml上做的工作），而在Web端，需要html和css文件來共同完成。在小程序裏麵，對應的是WXML(WeiXin Markup Language)和WXSS(WeiXin Style Sheets)，注意雖然模式和web很像，但是在形式上算是微信自己開發的一套（所以你需要使用他們(men) 自己的標簽）。具體(ti) 來講，你需要做兩(liang) 件事：

在WXML中通過組件（微信所提供的標簽）構建頁麵結構，並且在其中完成數據綁定和事件綁定
在WXSS中完成樣式的定義，用以控製WXML中組件的樣式。WXSS具有CSS大部分特性,同時也有部分擴充。

基本上，視圖層很像在寫(xie) Web端。不過你也看到了，和androids比起來，限製因素在於(yu) 微信給你提供了組件，然後你最多改改樣式，更多的像自定義(yi) 組件什麽(me) 的就不可能了。

邏輯層代碼

不同於(yu) androids有一堆的組件（Activity、Service..）來支撐邏輯層，小程序就一個(ge) Page()函數(類似與(yu) App()函數，在框架裏麵填邏輯)，所以顯得很簡單。基本上，數據通過雙向綁定進行傳(chuan) 遞和刷新的，然後在page內(nei) 可以完成一些交互處理，更多的能力(訪問網絡、存儲(chu) )是通過微信的API完成的，這些api以wx.開頭，目前來看，不是太多，所以可以很快看完，當然也意味著其實可以完成的工作還著實有限，這個(ge) 後麵說。

工程組織

整體(ti) 來說,小程序的工程組織還是蠻清晰的,MINA程序包含一個(ge) 描述整體(ti) 程序的app和多個(ge) 描述各自頁麵的page，一個(ge) MINA程序主體(ti) 部分由三個(ge) 文件組成，必須放在項目的根目錄，是app.js,app.json,app.wxss，分別用作生命周期函數、配置文件和樣式文件，一個(ge) MINA頁麵由四個(ge) 文件組成，是.js,.wxml,.json,.wxss，分別用作生命周期函數、布局文件、配置文件和樣式文件，他們(men) 需要通過同名且放在同名文件夾下（方便框架通過名字路由）。比起androids來，套路應該是固定而簡單得多。

androids

再回頭看看androids開發，突然覺得可以玩的簡直是太多了…下麵簡單描述一下，肯定是不全的。

一些生命周期函數

App、Activity是肯定的，其實套路和小程序還是差不多的。隻不過組織形式是類而不是函數對象。之前說了，這是因為(wei) Js和Java語言特性造成的。

視圖層代碼

通常來講，androids的界麵在.xml文件中定義(yi) ，其實仔細想想就會(hui) 發現，在文件中，我們(men) 是同時定義(yi) 了布局，和交互邏輯的，這是因為(wei) 本質上這些.xml聲明都是View類的子類，我們(men) 通過重寫(xie) View的聲明周期方法來完成了對齊的樣式(onDraw以及LaoutParams)、以及交互的定義(yi) （各種on..listener）。所以在.xml中更像是對這些對象進行一係列實例化。至於(yu) 雙向數據綁定,androids也開始支持了

邏輯層代碼

這一層還是要複雜得多..放到後麵對比來說吧。

工程組織

…..不想說了，一方麵寫(xie) 法多，一方麵相對於(yu) 小程序也蠻複雜的。

功能上的對比

要怎麽(me) 對比呢？讀androids的開發文檔我之前看了一個(ge) 星期，而微信小程序的文檔也就兩(liang) 三個(ge) 小時，從(cong) 體(ti) 量上說就知道無意androids功能要強大的多。所以基本上小程序能做的以外就是不能做的，這句話聽起來很廢話，但事實上是因為(wei) 微信給的API有限，所以你基本上能把自己需求列出來，查一下API是否給出，沒給出的話基本上還是算了吧。下麵我根據androids的APIguide（科學上網）來羅列下小程序的局限。

自定義控件和布局

這個(ge) 應該是最直觀的一點，因為(wei) 實際上你所使用的視圖層是被微信進一步封裝了的，小程序自定義(yi) 控件還是蠻複雜的，因為(wei) MINA給出了繪圖（但是隻能在<canvas/>上作畫）和動畫（類似於(yu) androids中的屬性動畫）的功能，所以或許存在理論上的可能性。

數據存儲

這個(ge) 要特別拿來說一下，官網原文是：

每個(ge) 微信小程序都可以有自己的本地緩存，可以通過wx.setStorage（wx.setStorageSync）、wx.getStorage（wx.getStorageSync）、wx.clearStorage（wx.clearStorageSync）可以對本地緩存進行設置、獲取和清理。
注意： localStorage是永久存儲(chu) 的，但是我們(men) 不建議將關(guan) 鍵信息全部存在localStorage，以防用戶換設備的情況。

所以微信小程序使用的是緩存而非有一個(ge) 自己的數據庫，這裏的緩存應該類似於(yu) androids的SharedPreference之類的，用鍵值對存的。而且小程序隻能對文件進行存的操作。所以說對於(yu) 那種需要數據庫的應用，小程序是不適合的。

後台服務，多線程

androids中，Service是蠻重要的類，然後多線程與(yu) 異步任務雖然複雜，但是能完成許多工作，但是小程序是不具有這種能力的，當然其實你可以看到你也是可以異步讀寫(xie) 的…所以微信應該是隻提供了部分功能的異步能力。

對係統服務的獲取

寫(xie) 到這裏，主要是想到了之前應用需要鬧鍾模塊，需要讓係統定時通知應用以完成特定的事件。而小程序其實是封裝在微信這個(ge) 應用之內(nei) 的應用，所以理論上它是可以獲得係統服務的，但是，如果微信不給接口一切都白說，從(cong) API文檔中可以看到，微信還是提供了位置、網絡狀態等係統信息的，不過像通知這些服務，是暫時沒有的。

與其他應用交互

這裏的概念主要是對應androids的隱式意圖和ContentProvider，這裏androids提供了一種能力，讓應用程序之間可以相互調用甚至相互操作數據（比如A打開B的音樂(le) 播放器，將A的網頁內(nei) 容保存到B的便簽中..這裏主要是場景可擴展），而微信中，這種能力被具體(ti) 場景化了，比如你仍然可以調用相機拍照（微信調用隱式意圖幫你實現），其他的場景你卻無法實現，因為(wei) 微信沒有做這一層封裝。

內嵌網頁

這一點不知道要不要說..因為(wei) 微信小程序其實就是一種”內(nei) 嵌網頁”的解決(jue) 方案？隻不過使用了類似於(yu) hybrid的解決(jue) 方案。

性能優化

在androids中許多業(ye) 務已經被MINA封裝了（網絡請求、websocket…）所以一方麵你實現功能的成本降低了，另一方麵這一部分優(you) 化的空間並不是那麽(me) 大。

開源庫

因為(wei) 我還是個(ge) Js的初學者，所以暫時不知道如何在微信小程序中使用輪子。但微信和web前端那一套還真不太一樣，所以也應該沒法直接使用一些開源庫。（10.8更新,今天看到了LeanCloud已經可以支持js開發了..也說明了可行性）

最後的總結

如前所說，如果說一般應用的容器(不知道這個(ge) 比喻恰不恰當)是操作係統，那麽(me) 小程序的容器則是操作係統下的一款應用，自然而然的，它本身就是某個(ge) 應用下的一個(ge) 子模塊。而這個(ge) 模塊能有多少功能取決(jue) 於(yu) 微信寫(xie) 了多少接口。
另一方麵，因為(wei) 這個(ge) 容器是微信，至少我們(men) 可以假設這些接口的跨平台特性，很可能我們(men) 調用的這些接口，會(hui) 比我們(men) 自己寫(xie) androids調用係統接口更穩定，甚至依附於(yu) 微信，我們(men) 可能少了諸如在某些手機係統中管理應用生命周期、避免程序被殺死的麻煩。
總之，我的感受是