公司本著節(jié)流開元的思想，使用uniapp開發(fā)微信小程序/支付寶 小程序/抖音小程序，本人剛開始亦本著能用就行的思想進(jìn)行開發(fā)，但待項(xiàng)目基本成型時(shí)，領(lǐng)導(dǎo)關(guān)注起了we分析的數(shù)據(jù)，然后你懂得，牛馬的我要開始耕地了。。。

從we分析的指標(biāo)來(lái)看，有啟動(dòng)性能，網(wǎng)絡(luò)性能，運(yùn)行性能三個(gè)方面

1.啟動(dòng)性能

1）首先就是包的體積，我說(shuō)的一定是分包，分就完了
分包主要包括 代碼邏輯文件/資源，梳理好公共/分包資源，逐層拆解分包就好
盡量保證主包體積足夠小
2）不必要請(qǐng)求滯后
3）參考官方文檔 https://developers.weixin.qq.com/miniprogram/dev/framework/performance/tips/start.html

2.網(wǎng)絡(luò)性能

目前我這邊請(qǐng)求報(bào)錯(cuò)很低，主要還是騰信官方收集日志接口報(bào)錯(cuò)，暫未處理

3.運(yùn)行性能

運(yùn)行性能即頁(yè)面切換耗時(shí)
1） handleWebviewPreload
小程序頁(yè)面加載完成后，會(huì)預(yù)加載下一個(gè)頁(yè)面。默認(rèn)情況下，小程序框架會(huì)在當(dāng)前頁(yè)面 onReady 觸發(fā) 200ms 后觸發(fā)預(yù)加載。在安卓上，小程序渲染層所有頁(yè)面的 WebView 共享同一個(gè)線程。很多情況下，小程序的初始數(shù)據(jù)只包括了頁(yè)面的大致框架，并不是完整的內(nèi)容。頁(yè)面主體部分需要依靠 setData 進(jìn)行更新。因此，預(yù)加載下一個(gè)頁(yè)面可能會(huì)阻塞當(dāng)前頁(yè)面的渲染，造成 setData 和用戶交互出現(xiàn)延遲，影響用戶看到頁(yè)面完整內(nèi)容的時(shí)機(jī)。

{
  "window": {
    "handleWebviewPreload": "auto"
  }
}

我直接搞了個(gè)全局的，空閑預(yù)加載
2）preloadRule
此屬性顧名思義，預(yù)加載規(guī)則，他可以設(shè)置在加載某個(gè)頁(yè)面是預(yù)加載其他的分包資源

"preloadRule": {
    "pages/xxx/xxx": {
        "network": "all",
        "packages": ["__APP__", "pages/page1", "pages/page2", "pages/page3"]
    },
  }

2）經(jīng)過(guò)多方觀察，切換頁(yè)面耗時(shí)較大的頁(yè)面是因?yàn)檎?qǐng)求耗時(shí)較長(zhǎng)，故而我遍琢磨請(qǐng)求前置，有兩個(gè)思路
一 跳轉(zhuǎn)時(shí)發(fā)起請(qǐng)求，使用EventChannel將數(shù)據(jù)傳至目標(biāo)頁(yè)
二是在navigateTo的success或者complete回調(diào)中，獲取目標(biāo)請(qǐng)求函數(shù)直接調(diào)用，但要注意的是navigateTo的回調(diào)（success、complete），目標(biāo)頁(yè)onshow，onload的執(zhí)行順序存在不確定性，需要在目標(biāo)頁(yè)做好兼容，目前觀察大部分時(shí)候是ok的，且切換耗時(shí)下降了100多到200多ms
3）其他優(yōu)化細(xì)節(jié)參考官方文檔