微盟小程序性能優化要分享的內容分為三部分，啟動性能加載、首屏加載的體驗建議和渲染性能優化。
先講啟動性能加載的性能優化實踐，先看啟動加載過程的流程：
· 公共庫注入
· 資源准備（基礎UI創建，代碼包下載）
· 業務代碼注入和渲染
· 渲染首屏
· 異步請求
優化方案
1、控制代碼包大小
· 開啟開發者工具中的 “ 上傳代碼時自動壓縮 ”
· 及時清理無用代碼和資源文件
· 減少代碼包中的圖片等資源文件的大小和數量
· 將圖片等資源文件放到CND中
· 提取公共樣式
· 代碼壓縮，圖片格式，壓縮，或者外聯
· 公共組件提取，代碼復用
2、 分包加載
分包加載過程流程
在開發小程序分包項目時，會有一個或者多個分包，其中沒有分包小程序必須包含一個主包，即放置啟動頁面或者tabBar頁面，以及一些分包都需要用到的公共資源腳本。
在小程序啟動時，默認會下載主包並且啟動主包內頁面，如果用戶打開分包內的頁面，客戶端會把分包下載下來，下載完之后再進行展示。
· 分包加載流程
使用分包加載的優點：
· 能夠增加小程序更大的代碼體積，開發更多的功能
· 對於用戶，可以更快地打開小程序，同時不影響啟動速度
使用分包加載有哪些限制：
· 整個小程序所有分包不能超過8M
· 單個主包/分包不能超過2M
3、 運行機制優化
· 代碼中減少立即執行的代碼數量
· 避免高開銷和長時間阻塞代碼
· 業務代碼都寫入頁面的生命周期中
· 做好緩存策略
4、 數據管理優化
· 首屏請求數量盡量不能超過5個，超過的可以做接口合並（node層，服務端都可以處理）
· 對多次提交的數據可以做合並處理
接下來和大家聊一聊首屏加載的體驗建議和渲染性能優化。
二、首屏加載的體驗建議
· 提前請求
異步數據請求不需要等待頁面渲染完成。
· 利用緩存
利用storage API對異步請求數據進行緩存，二次渲染頁面，再進行后台更新。
· 避免白屏
先展示頁面骨架和基礎內容。
三、渲染性能優化
· 每次 setData 的調用都是一次進程間通信過程，通信開銷與 setData 的數據量正相關
· setData 會引發視圖層頁面內容的更新，這一耗時操作一定時間中會阻塞用戶交互
· setData 是小程序開發使用最頻繁，也是最容易引發性能問題的
· 在頁面列表中使用懶加載+動態移除非可視區域范圍內的內容，讓dom小下去
· 耗時比較長的js做到異步，不要阻塞進程（js屬於單線程）
· 少使用scroll-view,這個組件對性能的影響太大，單純的只是需要一塊區域滾動，可以使用view+css的方式實現
· 在頁面頻繁滾動觸發回調函數，會導致頁面卡頓，這時必須和防抖動函數或者節流函數相結合做一些處理
· 頁面中的圖片可以使用懶加載的方式（添加lazy-load屬性，只針對page與scroll-view下的image有效）
· 頁面跳轉要做一下限制，如果頁面快速點擊會出現跳轉多次的情況
避免不正當的使用setData
· 使用data在方法間共享數據，可能增加setData傳輸的數據量。data 應該僅僅包含與頁面渲染相關的數據
· 使用setData 傳輸大量的數據，通訊耗時與數據量成正比，導致頁面更新延遲 可能造成頁面更新開銷增加。所以setData 僅傳輸頁面需要的數據,使用setData 的特殊Key 實現局部更新
· 短時間內頻繁調用setData (操作卡頓、交互延遲 阻塞通信、頁面渲染延遲)，對連續的setData 調用進行合並
· 后台進行頁面setData (搶占前台頁面的渲染資源) 例如 活動定時器 再頁面切入后台時應該將關閉
避免不正當的使用onPageScroll
· 只在必要的時候監聽pageScroll 事件
· 避免在onPageScroll 中執行復雜的邏輯
· 避免在onPageScroll 中頻繁調用setData
· 避免頻繁查詢節點信息(SelectQuery) 部分場景建議使用節點布局相交狀態
· 監聽( IntersectionObserver) 替代
使用自定義組件
在需要頻繁更新的場景下，自定義組件的更新只在組件內部進行，不受頁面部分內容的復雜性的影響。