談談微信小程式

小深刻的秋鼠發表於2017-06-03

最近這段時間接觸了微信小程式開發,也有一段時間沒寫博文了,也來寫寫簡單的看法以及開發的部分問題與感想。

本文同步於個人部落格:www.imhjm.com/article/593…

微信小程式,何方神聖?

有人可能會困惑微信小程式跟微信內嵌H5有什麼區別?

其實如果你玩過微信小程式,你就能發現流暢度以及體驗方面,小程式是完勝的
本質其實就是hybrid(混合)的app
介於web app與native 原生app之間,具備豐富的呼叫手機各種功能的介面,同時又具備靈活性,跨平臺,維護成本也相當原生app較低,開發迭代速度也比較快

放一張網上的圖,可以看出這三者的區別

來自www.bittiger.io/blog/post/o…

談談微信小程式

“作業系統中的作業系統,生態中的生態”

有人這麼評價小程式是“作業系統中的作業系統,生態中的生態”
就像是微信裡面又開了一個app store一樣,然後裡面的app跟著微信自定義的規則來編寫,其實就是個微信作業系統中的app

一開始我是拒絕的,微信搞了自己的一套基於原生的規範,還做了大量的限制,所以當時我並沒有看好微信小程式,但是因為微信影響力的緣故,並且宣傳做得太好了,朋友圈、社群等等各種爆炸新聞,熱度、活躍度也非常高漲,各種《第一個小程式教程》《微信小程式入門指南》等等層出不窮,然後整理小程式教程的repos的star量都能達到幾k,讓人不由得想去探探小程式的究竟

談到生態的話,開放的時候,很多app很快就上線了相應的小程式,基本都是原生app功能性的弱化版,還有一些功能性較強的小應用之類的,比如什麼親戚計算器等等
然而,有人就會想著,小程式是否會打擊到原有app的流量以及下載,使用者是否會直接放棄原有的app?做小程式的效果反而適得其反?這確實要引起開發者們的思考

微信小程式,路在何方?

過了剛開始的火熱的階段後,小程式就陷入一段低迷,很多人開始覺得它是雞肋,只是微信鞏固它本身的超級流量而誕生的跟公眾號類似的內建應用罷了,流量難以轉入本身的app,使用者粘性也不高,正如小程式的特點“無須安裝、觸手可及、用完即走、無須解除安裝”

其實接觸過微信小程式後,發現有些東西其實是網上的誤導或者自身的誤解。

先來看看上面的問題,小程式是否會打擊到原有app的流量,其實這個問題很好解決,你只要看看這個應用跟使用者的互動度的高低,如果存粹是一些小工具的話,功能相對單一的話,毋庸置疑,必然打擊,我就簡單舉個例子,比如摩拜單車,我們其實只需要掃碼用車,根本不需要別的東西,我為何還要下載一個app應用,但是類似其他使用者互動度比較高的,比如滴滴出行,小程式功能就很簡單,只能供使用者簡單使用,打到快車,但是原生應用上則功能較為豐富,使用者往往不會解除安裝掉原生的app

說到上面功能的閹割,既然小程式只是一些app應用的弱化版簡化版,那小程式有何作用,它能帶來什麼收益?

曾經我也覺得它很雞肋,但是隨著最近小程式開發團隊的頻繁能力升級以及自己的接觸,彷彿看到了小程式是一塊尚未挖掘開的巨大市場。

首先是微信小程式的能力升級,先是開放個人開發者,然後公眾號支援新增轉發,再然後開放群相關能力,小程式碼以及資料分析能力也相應開放,著實讓人看到微信小程式背後開發團隊的活躍以及微信相關方面的重視,一些能力的升級讓小程式的推廣能力更強,讓開發者有更大的許可權去拿到使用者關係以及一些使用者資訊,讓體驗更好。

談談微信小程式

其次是「匿名聊聊」小程式帶來的啟發,匿名聊聊通過小程式碼在朋友圈推廣,可以跟分享小程式的朋友匿名聊天,瞬間刷爆朋友圈,有訊息透露,它四小時訪問量高達40萬,雖然因為微信不允許這種“影響朋友圈”的行為,最後被說由於“誘導分享“暫停服務了,但是我們從這裡可以看到小程式的強大影響力以及在社交關係上的強大優勢,在這個移動網際網路的時代,微信基本已經成為流量主體入口(根據questmobile資料,微信日活已經到達6億),微信一方面利用小程式來鞏固自己的流量超級入口地位,我們何嘗不可以利用它的流量以及實體使用者來給自己帶來紅利,就類似匿名聊聊這類的,正常使用者很少會去下載這樣的app,這就跟陌生交友這些類似了,但是在微信這個載體下就不一樣了,使用者身份是相對有保證的,使用者通過微信入口進入你的應用,通過微信使用者之間的關係就可以做很多事情了,也可以選擇跟本身app使用者連動,來使得使用者留存

但是值得注意的是,並不是所有小程式都能享受到微信流量的紅利,如果只是單純做一個app簡化版的小程式,又有何用,使用者無法看到你開發的微信小程式的優勢和方便所在,做不到吸引使用者,使用者就只會放棄你的產品,個人覺得,小程式不應該是所謂的“用完即走”,而是“用完很爽,下次還來”,打造一個精心製作的應用,利用微信小程式帶來的社交以及流量的優勢打造一個與原有app有所不同但是可以看到用心製作的精緻小程式,這樣使用者用完對產品認可,完全可以喚醒產品的更多使用者,不過,這就需要去試驗以及推敲,像「匿名聊聊」這種打著使用者心理將小程式玩成爆款的就是一個很好的例子

關於開發微信小程式的感受

微信開發者工具

談談微信小程式

微信提供了自己的開發者工具(支援儲存編譯,ES5轉ES6,壓縮程式碼等),反正從釋出到現在也迭代好多版本了,目前直接使用它的編輯器開發覺得還可以,沒遇到很大的坑,除錯工具中css部分沒有盒子模型、computed style之類的這點還有待提高

小程式開發框架

對於小程式開發框架,文件是這麼寫的

小程式開發框架的目標是通過儘可能簡單、高效的方式讓開發者可以在微信中開發具有原生 APP 體驗的服務。

框架提供了自己的檢視層描述語言 WXML 和 WXSS,以及基於 JavaScript 的邏輯層框架,並在檢視層與邏輯層間提供了資料傳輸和事件系統,可以讓開發者可以方便的聚焦於資料與邏輯上。

小程式也的確實現了現代前端框架的資料與檢視繫結的特點,而不是dom的形式,但是它最大的缺點是缺少自定義元件化的特點,雖然框架中提供了import/include,還有template,還有它內建的元件,這些可以提供js模組化,還有wxml模板之類,但是遠遠達不到我們想要的,小程式很大程度跟vue很接近,包括一些繫結以及條件渲染與列表渲染等等,但是vue還有一個很大的特點就是元件系統,網站最基本就是html/css/js,但是其實我們就可以把應用抽象成元件樹,它們都是由一些可複用的元件構成,這樣構建速度會非常快,而且維護方便,極大地提升效率

談談微信小程式

談談微信小程式

但是小程式目前還不支援,只是它內建了一些基礎元件,不過之後會不會出現,無從得知
小程式目前比較明顯的缺點,就是元件化支援不夠,npm包下載不方便(需要自己拷貝進去,不支援node_modules),css一些屬性支援不足
不過這些可以用我們自己搭的腳手架,通過gulp/webpack編譯,讓它們支援一些我們想要的特性,騰訊Budly就開發了一個wepy框架,它學習了vue的風格,使用單檔案,通過拆解編譯形成小程式的wxml/wxss,具體我還沒用過,star量也1000+了,覺得思路很好贊一下
談談微信小程式

小程式DEMO:

project
├── pages
|   ├── index
|   |   ├── index.json  index 頁面配置
|   |   ├── index.js    index 頁面邏輯
|   |   ├── index.wxml  index 頁面結構
|   |   └── index.wxss  index 頁面樣式表
|   └── log
|       ├── log.json    log 頁面配置
|       ├── log.wxml    log 頁面邏輯
|       ├── log.js      log 頁面結構
|       └── log.wxss    log 頁面樣式表
├── app.js              小程式邏輯
├── app.json            小程式公共設定
└── app.wxss            小程式公共樣式表複製程式碼

使用wepy框架後目錄結構:(perfect!)

project
└── src
    ├── pages
    |   ├── index.wpy    index 頁面配置、結構、樣式、邏輯
    |   └── log.wpy      log 頁面配置、結構、樣式、邏輯
    └──app.wpy           小程式配置項(全域性樣式配置、宣告鉤子等)複製程式碼

回到微信小程式,開發時還遇到一些小坑,比如實現回到頂部,這個在瀏覽器輕鬆實現,但是小程式沒有提供bom/dom,唯一跟scroll搭上鉤的就只有一個元件scroll-view,但是我還需要頂部下拉載入(居然跟它的scrolltoupper事件衝突了?),只能用一些小技巧來規避這些問題,在切換時我想回到頂部,瞬間將列表項data設為空,再填入資料,這樣就回到頂部了,雖然也實現了效果,但是未必有些hack

再談談小程式的rpx單位吧

rpx(responsive pixel):
可以根據螢幕寬度進行自適應。規定螢幕寬為750rpx。如在 iPhone6 上,螢幕寬度為375px,共有750個物理畫素,則750rpx = 375px = 750物理畫素,1rpx = 0.5px = 1物理畫素。

裝置 rpx換算px (螢幕寬度/750) px換算rpx (750/螢幕寬度)
iPhone5 1rpx = 0.42px 1px = 2.34rpx
iPhone6 1rpx = 0.5px 1px = 2rpx
iPhone6 Plus 1rpx = 0.552px 1px = 1.81rpx

這個還挺不錯的,讓適配比較容易,不然在前端開發中還得使用rem、百分比等等一些技巧
不過需要注意
它官網提醒了在較小的螢幕上不可避免的會有一些毛刺,請在開發時儘量避免這種情況。
我也體驗到了這個毛刺
當你使用padding-bottom: 0rpx的時候你會發現其實是有縫隙的,但是0px是不會有的

總之,小程式整體來看還是不錯的,而且開發團隊也一直在努力,經常半夜兩三點更新發布小程式的能力?,也一直在往主流前端框架靠,支援了資料繫結、模組化、ES6等等,上手也很容易,不過要用它來做出一個讓使用者認可的精緻的產品還是需要費很大的心思的

最後

謝謝閱讀~
歡迎follow我哈哈github.com/BUPT-HJM
歡迎繼續觀光我的新部落格~(老部落格近期可能遷移)

歡迎關注

相關文章