小程序開發之初體驗

小程序出現了這麼久，一直沒有機會深刻接觸，最近由於項目須要進行小程序開發。首先固然是把官方文檔看一遍啦。

 

從文檔能夠了解到，小程序開發不一樣於以往的網頁開發。小程序是基於雙線程模式，運行環境分爲渲染層（多個）和邏輯層(一個)，兩種線程間的通訊由微信客戶端（Native）作中轉，邏輯層發送網絡請求也由 Native 轉發。

 

通訊

渲染層和邏輯層經過 setData 進行通訊，調用 this.setData 會把數據異步傳遞給渲染層，有必定的消耗。能夠將合併多個 setData，減小 js 的編譯執行；同時傳輸的數據量也不宜過大。當頁面進入後臺時，setData 一樣會搶佔前臺頁面的執行，所以後臺頁面不該該有 setData 的操做。

 

關於基礎庫
渲染層WebView層注入的稱爲WebView基礎庫，邏輯層注入的稱爲AppService基礎庫，內置在微信客戶端 

 

邏輯層

邏輯層框架基於 JavaScript，核心是響應的數據綁定系統，讓視圖與數據可以很是簡單的保持同步（和流行的響應式框架相似）。

整個小程序只有一個 App 實例，能夠經過 getApp() 獲取到該實例，添加全局數據。

 

頁面生命週期

 

 

頁面路由

小程序全部頁面路由均由框架進行管理，框架以棧的形式維護全部頁面。

每新開一個頁面，都會建立一個 webview ，爲了防止內存的過多消耗，所以最多可存放 10 個頁面，超過會致使頁面建立失敗。

在頁面棧未滿時，每新開頁面都會進行 webview 的預加載，縮短新頁面的展現時間。

可使用 getCurrentPages() 獲取當前頁面棧。

navigateTo，redirectTo 只能打開非 tabBar 頁，navigateTo 會往頁面棧添加新的頁面，而 redirectTo 當前頁面出棧，新頁面入棧。

switchTab 只能打開 tabBar 頁面，當 Tab 切換時，清空原有的頁面棧，並銷燬棧內除已聲明的 Tabbar 頁的其餘頁面，即 Tabbar 頁初始化以後不會被銷燬，可是頁面棧中只留下新的 Tab 頁面。

切換頁面可能會存在延遲，最好作跳轉節流處理。

 

關於樣式
組件不受外部組件樣式控制

background 不能引用本地資源，但能夠轉爲 base64 後訪問

 

關於 API
wx：小程序宿主環境提供的全局對象
幾乎全部小程序的 API 對掛載在 wx 對象下（除了 Page/App 等特殊構造器）
大可能是異步

 

關於事件

事件分爲冒泡事件、非冒泡事件，catch、capture-catch 事件會阻止後續事件的觸發

 

原生組件
webview 僅渲染一個佔位元素，客戶端在這塊佔位元素上疊一層原生界面。所以原生組件層級比全部 webview 渲染的組件高。

原生組件脫離在WebView渲染流程外，帶來最主要的限制是一些CSS樣式沒法應用於原生組件，例如，不能在父級節點使用overflow:hidden來裁剪原生組件的顯示區域；不能使用transformrotate讓原生組件產生旋轉等。

最爲常見的問題是，原生組件會浮於頁面其餘組件之上（至關於擁有正無窮大的z-index值）使其它組件不能覆蓋在原生組件上展現。想要解決這個問題，能夠考慮使用cover-view和cover-image組件。這兩個組件也是原生組件，一樣是脫離WebView的渲染流程外，而原生組件之間的層級就能夠按照必定的規則控制。

 

關於啓動及更新

啓動分爲熱啓動、冷啓動。每次冷啓動都會檢查是否有更新版本，若是有，異步下載新版本代碼包，並同時啓動客戶端本地的包，所以新版本在下次冷啓動纔會啓用，可使用 wx.getUpdateManager API 進行更新處理。