微信小程式的思考與實踐

weixin_34247155發表於2017-01-15

2017 年 1 月 9 日,是一個值得載入網際網路史冊的日子。這一天,張小龍和他的團隊,正式釋出了微信小程式。業界頓時一片譁然。作為前端開發攻城獅我們也有必要了解一下小程式對使用者、產品、設計、運營帶來什麼影響、文章最後從開發的角度對小程式的原理與實踐進行分析。

一、從使用者角度看小程式:

4378329-b6a245eeec4f6fc4.jpg
景點門票小程式的二維碼

1.無須安裝即可使用
2.掃一掃或搜一下就可開啟應用
3.用完即走
4.不用擔心安裝太多應用 (媽媽再也不用擔心我的手機記憶體不夠用了)
5.無處不在,隨時隨地可用。

它滿足使用者的核心訴求:使用應用不再必須去應用商店下載、註冊、登入,省去了一系列操作的麻煩。讓使用應用變得簡單方便。

二、從產品角度看小程式:

4378329-dd705f6feb0f5dec.png

自從進入移動網際網路時代,市場上出現了海量的app,微信小程式出現後會對移動網際網路產品產生什麼樣的影響呢?我們下面逐一分析探討:

1.微信小程式不可能替代app

微信小程式在定位上類似服務號中開發的功能,可能有所加強,但是,要想要實現APP的完整功能是不可能的。例如: 人臉識別(目前官方並沒有提供對應的api)等功能做不了。

還有不能做與騰訊衝突的業務,例如社交,否則將會直接被封殺。

推廣微信小程式也是難事,微信並不會提供“展位”功能,意思就是使用者想使用這個小程式,前提是知道這個小程式的存在,然後在微信搜尋框進行搜尋。雖然依託微信這個超級IP,但想讓使用者知道並去使用這個小程式,仍需要自己去推廣。

從某些方面而言,推廣APP比推廣小程式要好,避免為微信做了嫁衣。

所以微信小程式替代app是不可能的。

2.適合輕量級低頻產品

從微信小程式本身的理念來看,其始終秉承著使用者用完即走,不打擾使用者的原則。其原則決定著搭建在微信上的小程式本身就必須是輕量級的,並且是滿足使用者低頻需求的。我們都知道使用者的低頻需求一直存在,但是受限制於使用者活躍度來說,開發低頻需求的APP總是不那麼划算。同時使用者使用一次低頻需求就要下載一次APP,顯然太麻煩了。因此微信小程式對於低頻需求的產品來說是一個機會,但是需要注意的是微信小程式可以集合市面上的低頻需求,這樣使用者體驗會更好。

既然微信小程式適合低頻需求產品,那麼是不是高頻諸如購物、資訊類產品就不能做小程式了?回答顯然是不對的。建議對於一些高頻需求的產品可以分離出來一些關鍵需求嫁接在微信小程式上。

4378329-d6ab18c3e2d60c13.png

比如對於購物來說京東就做的非常不錯,京東微信小程式並沒有繁雜的商品列表頁,只保留了“搜尋商品”“我的訂單”兩個tab選單,剩下的就是優惠券展示頁,沒有什麼複雜的內容在上面。

3.總結
  1. 由於微信小程式開發成本低,如果是做創業產品可以先做微信小程式版,待壯大了再做app版,省錢省時間。未來輕量低頻的應用會大量出現在小程式上,輕量低頻app會相對減少。
  2. 如果您目前已經有一款使用者已經在高頻使用的app,不妨像京東那樣把關鍵的業務流抽離出來嫁接到微信小程式上,微信畢竟擁有龐大的使用者量,說不定某天微信使用者會在小程式搜尋框裡輸入您app的關鍵字。

三、從設計角度看小程式:

小程式要求介面重點突出、流程明確,並給出一系列具體的視覺規範,精確到行距,邊距等。原來app設計稿跟微信小程式視覺規範有差異的小夥伴,別指望原封不動挪過去用了。


4378329-ee0446ba0221902c.jpeg

四、從運營角度看小程式:

因為微信本身的剋制,讓微信小程式只能使用微信本身的賬號體系、不能分享轉發到朋友圈、不能模糊搜尋、入口極其有限等等。

產品運營的小夥伴是不是面對此就沒招啦,其實不然。比如微信小程式的主要入口是二維碼。二維碼最好的使用途徑就是線下的實體店,這樣對於滿足一些O2O行業的核心使用者需求還是很不錯的。同時微信小程式還可以置頂到微信聊天的列表中,這就要求運營者更加的創新性的引導使用者操作這一步,同樣道理的還有把小程式新增到手機桌面等等。因為其分享渠道限於微信聊天和社群,那麼小程式的口碑營銷和社群營銷可能又會引來新的一春。

五、小程式原理與開發實踐:

1. 開發工具

微信提供了小程式開發工具整合了開發除錯、程式碼編輯及程式釋出等功能。除錯功能與谷歌瀏覽器除錯是一樣的,官方也說明了該開發工具是基於谷歌瀏覽器核心開發的。

4378329-97e932a7a5f0d1f8.jpeg
小程式開發工具
4378329-df0446c4f964c9e4.jpeg
小程式專案配置

專案配置中包含程式碼補全、壓縮等功能,簡直是保姆式開發...

2. 框架——MINA 基本原理

MINA(MINA IS NOT APP)就是微信小程式開發使用的框架。

4378329-6ce31241bf2cf938.png

MINA的核心是一個響應的資料繫結系統。
整個系統分為兩塊:檢視層(View)邏輯層(App Service)
MINA可以讓資料與檢視保持同步非常簡單。
當做資料修改的時候,只需要在邏輯層修改資料,檢視層就會做相應的更新。
<pre>

<view> Hello {{name}}! </view>
<button bindtap="changeName"> Click me! </button>

// App Service
// 初始資料建立
var helloData = {
name: 'WeChat'
}
// 註冊頁面.
Page({
data: helloData,
changeName: function(e) {
this.setData({
name: 'MINA'
})
}
})
<code></pre></code>

開發者通過MINA將邏輯層資料中的name與檢視層的name進行了繫結,所以在頁面一開啟的時候會顯示Hello WeChat!
當點選按鈕的時候,檢視層會傳送changeName的事件給邏輯層,邏輯層找到對應的事件處理函式邏輯層執行了setData的操作,將nameweChat變為MINA,因為該資料和檢視層已經繫結了,從而檢視層會自動響應改變為Hello MINA! 。
簡單來說,檢視層中繫結了name,在邏輯層中只需要對繫結的name操作就行了,而無需再獲取"DOM物件",因為這部分關聯工作MINA 已經做好了。

3. 頁面管理

MINA管理了整個小程式的頁面路由,可以做到頁面間的無縫切換,並給以頁面完整的生命週期。開發者需要做的只是將頁面的資料,方法,生命週期函式註冊進MINA中,其他的一切複雜的操作都交由MINA處理。

開發者使用app.json檔案對微信小程式進行全域性配置,決定頁面檔案的路徑、視窗表現、設定網路超時時間、多tab等

各個頁面的.json檔案來對本頁面的視窗表現進行置。 也就是隻需要配置app.json中的window配置項的內容,頁面中配置項會覆蓋app.json的window中相同的配置項。
<pre><code>
"pages":[

  "pages/index/index/index",

  "pages/index/openCardNav/openCardNav"

]
</code></pre>
pages接受一個字串陣列,來指定小程式由哪些頁面組成。每一項代表對應頁面的【路徑+檔名】資訊,陣列的第一項代表小程式的初始頁面。小程式中新增/減少頁面,都需要對pages陣列進行修改。檔名不需要寫檔案字尾,因為MINA會自動去尋找路徑.json,.js,.wxml,.wxss的四個檔案進行整合。

頁面生命週期:


4378329-c22e20421b907988.png
頁面生命週期
4. 基礎元件

MINA提供了一套基礎的(具有微信風格和微信邏輯的)元件,開發者通過組合各種基礎元件,建立自己的微信小程式。

<view>元件相當於h5裡面的<div>

4378329-7e1eb6a1b2d10775.jpeg
小程式元件
5. WXSS

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

定義在 app.wxss 中的樣式為全域性樣式

wxss檔案中可以@import 其它自定義wxss檔案

內聯樣式
<code><view style="color:{{color}};" /></code>

6. API

MINA提供豐富的微信原生API,呼叫微信功能十分方便(自個兒家產的當然用著方便),如獲取使用者資訊,本地儲存,支付功能等。

4378329-b29004c943e29ddd.jpeg
小程式api
7. 開發中遇到的問題
  1. wxss不支援在背景圖片background: url();
  2. mac環境下開發工具不太穩定

您的意見是我改善的東西,歡迎評論提建議,如果對您有幫助,請點個贊,謝謝~~
菲麥前端專題,匯聚前端好文,邀您關注!

相關文章