公司本着节流开元的思想，使用uniapp开发微信小程序/支付宝 小程序/抖音小程序，本人刚开始亦本着能用就行的思想进行开发，但待项目基本成型时，领导关注起了we分析的数据，然后你懂得，牛马的我要开始耕地了。。。
从we分析的指标来看，有启动性能，网络性能，运行性能三个方面
1.启动性能
1）首先就是包的体积，我说的一定是分包，分就完了
分包主要包括 代码逻辑文件/资源，梳理好公共/分包资源，逐层拆解分包就好
尽量保证主包体积足够小
2）不必要请求滞后
3）参考官方文档 https://developers.weixin.qq.com/miniprogram/dev/framework/performance/tips/start.html
2.网络性能
目前我这边请求报错很低，主要还是腾信官方收集日志接口报错，暂未处理
3.运行性能
运行性能即页面切换耗时
1） handleWebviewPreload
小程序页面加载完成后，会预加载下一个页面。默认情况下，小程序框架会在当前页面 onReady 触发 200ms 后触发预加载。在安卓上，小程序渲染层所有页面的 WebView 共享同一个线程。很多情况下，小程序的初始数据只包括了页面的大致框架，并不是完整的内容。页面主体部分需要依靠 setData 进行更新。因此，预加载下一个页面可能会阻塞当前页面的渲染，造成 setData 和用户交互出现延迟，影响用户看到页面完整内容的时机。
{
"window": {
"handleWebviewPreload": "auto"
}
}
我直接搞了个全局的，空闲预加载
2）preloadRule
此属性顾名思义，预加载规则，他可以设置在加载某个页面是预加载其他的分包资源
"preloadRule": {
"pages/xxx/xxx": {
"network": "all",
"packages": ["__APP__", "pages/page1", "pages/page2", "pages/page3"]
},
}
2）经过多方观察，切换页面耗时较大的页面是因为请求耗时较长，故而我遍琢磨请求前置，有两个思路
一 跳转时发起请求，使用EventChannel将数据传至目标页
二是在navigateTo的success或者complete回调中，获取目标请求函数直接调用，但要注意的是navigateTo的回调（success、complete），目标页onshow，onload的执行顺序存在不确定性，需要在目标页做好兼容，目前观察大部分时候是ok的，且切换耗时下降了100多到200多ms
3）其他优化细节参考官方文档
