<code id="ymukc"><xmp id="ymukc">

小程序開發實踐總結 - WEB前端

小程序   2018-08-23 08:53:14 發布
您的評價:
     
0.0
收藏     0收藏
文件夾
標簽
(多個標簽用逗號分隔)

從微信發布小程序以來,各大公司紛紛跟進都想從微信這個流量池里撈一杯羹。我司也不例外,我們整個前端團隊這半年來基本上都是在開發小程序。前前后后也開發了四五個小程序了。總覺得要留下點什么,既是記錄那些年我們踩過的坑,也是希望大家別再掉坑。

那些年我們踩過的坑

  • css樣式不能引用本地圖片資源,只能引用線上資源( background-image ),引用本地圖片資源只能用 <image> 標簽。
  • {{}} 不能執行函數方法, {{}} 只支持基本的簡單運算和ES6拓展運算符。如價格格式化這種常用的處理,只能在js代碼中處理好然后再模板中渲染。 
    this.setData({
     price: this.formatPrice(this.data.price)
    })
    
  • 可以通過 wxs 模塊解決 {{}} 中不能執行函數的問題。可以做到模擬vue.js中過濾器的功能。 
    <!-- wxml模板 -->
    <wxs src="../../modules/formatPrice.wxs" module="tools" />
     
    <view>價格:{{tools.formatPrice(price)}}</view>
    // wxs模塊
    var formatPrice = function (price){
        price = price >> 0;
        return Number(price / 100).toFixed(2);
    }
     
    module.exports = {
        formatPrice
    }
    
  • 小程序不支持分享鏈接到朋友圈,暫時的通用做法是生成保存有頁面小程序碼的圖片到本地相冊。又用戶自行發朋友圈轉發。前端可以利用 canvas 來實現,減輕服務端壓力。但是會有圖片鋸齒不清晰的問題。建議預覽圖和保存到真機的圖片采用不同的尺寸。保存在真機的圖片按照750的寬度實現。相比于預覽圖要大一些,這樣保存到手機的圖片會清晰很多。
  • 小程序布局采用rpx單位,UI稿按照750的寬度出圖。可直接使用UI稿的尺寸。但是在某些機型上 1rpx 會無法顯示。可以用H5的方式實現1px效果。
  • iphoneX吸底按鈕的適配,可以用媒體查詢獲取wx.getSystemInfo獲取機型。 參考 
    @media only screen 
        and (device-width : 375px) 
        and (device-height : 812px) 
        and (-webkit-device-pixel-ratio : 3) { }
    
  • 頁面A -> 頁面B,頁面B的操作觸發了頁面A的數據更新。返回更新頁面A的數據,通常有兩種方式來實現(我司采用了方案二):
    1. 在頁面A監聽onShow事件,在onShow事件觸發時無腦更新頁面數據。
    2. 通過EventBus來實現跨頁面通信。
  • 復雜組件的開發,省市區三級聯動選擇器的開發,獲取微信地址庫的地址的編碼和業務采用的省市區編碼對不上。
  • 頁面路徑的層級,最大不能超過10層。
  • 小程序小程序分包加載,微信對小程序包的大小有如下限制。
  • 整個小程序所有分包大小不超過 8M
  • 單個分包/主包大小不能超過 2M

微信小程序主流框架對比

  • wepy
  • mpvue
  • Taro

wepy

wepy應該算是最早發布的小程序開發框架,提供了類vue.js的語法風格和特性,現階段應該也是應用最廣泛的框架吧。我開發的幾個小程序也都是采用了wepy這個框架。我先來說說當初為什么選擇這個框架的原因吧。

  1. 類Vue.js的語法風格,適合我們團隊原有的的技術棧
  2. 支持組件化(當時微信官方的API還不支持組件化)
  3. 支持加載外部npm包
  4. 支持ES6的寫法

前期使用wepy的過程中,wepy自帶bug。不過好在開發者響應及時,基本上都能覆蓋大部分場景。

但是有個最大的坑點就是,wepy組件的實現方式。 組件使用的是靜態編譯組件,即組件是在編譯階段編譯進頁面的,每個組件都是唯一的一個實例。 多個組件共享同一個數據。并且靜態編譯組件。導致組件A,在頁面A和頁面B被引用,會copy兩份代碼到頁面A和頁面B內部。導致拆分組件并沒有對包的體積有任何減少。后期微信官方API支持組件化編程后,我們逐步把一些比較核心,體積較大的組件用原聲API重構了。

mpvue

由美團團隊開發,mpvue和wepy一樣也是在小程序上提供了類vue.js的開發體驗。作為后來者,搶占了很多wepy的市場份額(ps:我們團隊近期也在考慮從wepy遷移到mpvue)。這個框架的原理相比wepy要更加復雜一點,mpvue 修改了 Vue.js 的 runtime 和 compiler 實現,提供了更加接近于vue.js的開發體驗。

Taro

Taro是由京東團隊開源的一套遵循 React 語法規范的多端開發解決方案。本身我對React和Taro都不是很了解,就不多解釋了。具體可以看開發團隊的博客和代碼了解更多細節 多端統一開發框架 – Taro

我看小程序

我想從技術的角度來談談我對微信小程序的理解,我覺得小程序本身是一個非常優秀的Hybrid App的技術方案。有很多值得學的地方,可以應用到我們Hybrid App的技術方案設計中來。了解和學習小程序技術原理也能更好的優化我們的代碼。

渲染層和邏輯層分離

相比于之前常見的Hybrid的方案, 小程序使用了雙線程模型:小程序的渲染層和邏輯層是是分開的,邏輯層通過JSCore來解析和執行,渲染層是通過webview來渲染。之前的常見Hybrid離線包的方案大多使用webview同時實現頁面的渲染和js的解析。這樣做的的結果就是隔離了js的runtime,在js代碼中無法操作webview中的DOM對象和BOM對象。Js無法做任何和頁面渲染有關的操作。只能通過setData把數據從JsCore傳遞到webview。

獨立的JS運行環境,相比于webview同時處理頁面的渲染和JS的執行帶來了一些好處:

  1. js無法動態的在頁面插入節點和干預頁面的渲染,解決了安全和管控的問題,否則小程序的上線審核就變得毫無意義。
  2. 渲染層和邏輯層的分離,減輕了webview的壓力,js的執行和頁面的渲染可以并行,不會出現js執行卡主頁面渲染的情況。
  3. 多個頁面可以共享一個JS運行環境,數據很方便的共享,整個小程序的生命周期共享同一個上下文,接近App的體驗。

壞處在于:

  1. 多了很多webview和JSCore數據傳輸的消耗,數據需要序列化成字符串格式進行傳輸。

離線包加載

離線包加載,常見的Hybrid App通過webview加載H5頁面,前端頁面都是放在服務器端。雖說保證了靈活性。但是加載性能收網速影響大。頁面切換白屏時間長。小程序離線包的加載方式。一次性加載所有的前端資源到本地再解壓。大大提升了用戶體驗。不過微信官方為了防止下載離線包的時間過程,也嚴格限制了小程序包的體積。(分包加載情況下子包大小不能超過2M,也就是初次打開加載的資源不能超過2M)

多webview架構

多webview的頁面架構,小程序每新開一個頁面,都會用一個新的webview來渲染。為了防止webview對內存的消耗。小程序限制層級不能超過10層。

預加載webview

預加載webview,微信會預加載多一個wkwebview(ios平臺)放后臺,用戶打開小程序時省去初始化wkwebview時間。

 

來自:http://web.jobbole.com/95097/

 

六合特码资料
<code id="ymukc"><xmp id="ymukc">
<code id="ymukc"><xmp id="ymukc">

擴展閱讀

大前端的瑞士軍刀
移動端開發者眼中的前端開發流程變遷與前后端分離
程序員必看的書
對于“前端”開發我們需要什么?
NPM 與前端包管理

為您推薦

Dojo Mobile 1.7 入門
使用 AngularJS 開發一個大規模的單頁應用(SPA)
FreeMarker使用詳解
nginx+iis實現負載均衡
前端面試問題(二)-史上最全 前端開發面試問題及答案整理

更多

小程序
微信小程序
相關文檔  — 更多
相關經驗  — 更多
相關討論  — 更多