小程序開發(fā)經驗總結

五、小程序開發(fā)經驗

1、小程序存在的問題

小程序仍然使用WebView渲染，并非原生渲染

需要獨立開發(fā)，不能在非微信環(huán)境運行 。

開發(fā)者不可以擴展新組件。

依賴瀏覽器環(huán)境的js庫不能使用，因為是JSCore執(zhí)行的，沒有window、document對象。

WXSS中無法使用本地（圖片、字體等）。

WXSS轉化成js 而不是css。

WXSS不支持級聯(lián)選擇器。

小程序無法打開頁面，無法拉起APP。

2、小程序的優(yōu)點

提前新建WebView，準備新頁面渲染。

View層和邏輯層分離，通過數(shù)據驅動，不直接操作DOM。

使用Virtual DOM，進行局部更新。

全部使用https，確保傳輸中安全。

加入rpx單位，隔離設備尺寸，方便開發(fā)。

rpx（responsive pixel）:
可以根據屏幕寬度進行自適應。規(guī)定屏幕寬為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
iPhone6Plus  1rpx = 0.552px          1px = 1.81rpx

七、代碼運行

運行時,外面包裹define,代碼作為回到,當調用回調時,只傳入前面三個值,由于后面的變量都是局部定義的變量,就屏蔽了(window,document等這些變量.

其中O就是上面define('app.js',callback),的回調,回調值傳入了三個參數(shù),屏蔽了其他屬性

八、優(yōu)化建議(官方建議)

setData 工作原理

小程序的視圖層目前使用 WebView 作為渲染載體，而邏輯層是由獨立的 JavascriptCore 作為運行環(huán)境。在架構上，WebView 和 JavascriptCore 都是獨立的模塊，并不具備數(shù)據直接共享的通道。當前，視圖層和邏輯層的數(shù)據傳輸，實際上通過兩邊提供的 evaluateJavascript 所實現(xiàn)。即用戶傳輸?shù)臄?shù)據，需要將其轉換為字符串形式傳遞，同時把轉換后的數(shù)據內容拼接成一份 JS 腳本，再通過執(zhí)行 JS 腳本的形式傳遞到兩邊獨立環(huán)境。

而 evaluateJavascript 的執(zhí)行會受很多方面的影響，數(shù)據到達視圖層并不是實時的。

常見的 setData 操作錯誤

1. 頻繁的去 setData

在我們分析過的一些案例里，部分小程序會非常頻繁（毫秒級）的去 setData ，其導致了兩個后果：

• Android 下用戶在滑動時會感覺到卡頓，操作反饋延遲嚴重，因為 JS 線程一直在編譯執(zhí)行渲染，未能及時將用戶操作事件傳遞到邏輯層，邏輯層亦無法及時將操作處理結果及時傳遞到視圖層；
• 渲染有出現(xiàn)延時，由于 WebView 的 JS 線程一直處于忙碌狀態(tài)，邏輯層到頁面層的通信耗時上升，視圖層收到的數(shù)據消息時距離發(fā)出時間已經過去了幾百毫秒，渲染的結果并不實時；

2. 每次 setData 都傳遞大量新數(shù)據

由 setData 的底層實現(xiàn)可知，我們的數(shù)據傳輸實際是一次 evaluateJavascript 腳本過程，當數(shù)據量過大時會增加腳本的編譯執(zhí)行時間，占用 WebView JS 線程，

3. 后臺態(tài)頁面進行 setData

當頁面進入后臺態(tài)（用戶不可見），不應該繼續(xù)去進行 setData ，后臺態(tài)頁面的渲染用戶是無法感受的，另外后臺態(tài)頁面去 setData 也會搶占前臺頁面的執(zhí)行。

圖片資源

• 目前圖片資源的主要性能問題在于大圖片和長列表圖片上，這兩種情況都有可能導致 iOS 客戶端內存占用上升，從而觸發(fā)系統(tǒng)回收小程序頁面。
• 在 iOS 上，小程序的頁面是由多個 WKWebView 組成的，在系統(tǒng)內存緊張時，會回收掉一部分 WKWebView。從過去我們分析的案例來看，大圖片和長列表圖片的使用會引起 WKWebView 的回收。

代碼包大小的優(yōu)化

開發(fā)者在實現(xiàn)業(yè)務邏輯同時也有必要盡量減少代碼包的大小，因為代碼包大小直接影響到下載速度，從而影響用戶的首次打開體驗。除了代碼自身的重構優(yōu)化外，還可以從這兩方面著手優(yōu)化代碼大?。?/p>

1. 分包加載

   對小程序進行分包，可以優(yōu)化小程序首次啟動的下載時間
2. 清理沒有使用到的代碼和資源

目前小程序打包是會將工程下所有文件都打入代碼包內，也就是說，這些沒有被實際使用到的庫文件和資源也會被打入到代碼包里，從而影響到整體代碼包的大小。

預先加載數(shù)據

原理

小程序在啟動時，會直接加載所有頁面邏輯代碼進內存，即便 page2 可能都不會被使用。在 page1 跳轉至 page2 時，page1 的邏輯代碼 Javascript 數(shù)據也不會從內存中消失。page2 甚至可以直接訪問 page1 中的數(shù)據。

小程序的這種機制差異正好可以更好的實現(xiàn)預加載。通常情況下，我們習慣將數(shù)據拉取寫在 onLoad 事件中。但是小程序的 page1 跳轉到 page2，到 page2 的 onLoad 是存在一個 300ms ~ 400ms 的延時的。

渲染view線程和AppServcie是相互獨立的,對于AppServcie中js運行不會阻塞view的渲染

官方的示例也是采用這種方式: 先App中請求數(shù)據,在index.js使用數(shù)據