小程序代碼在ios上很溜，但是安卓機上性能問題很多，低端安卓機對性能調優(yōu)更是要求賊高，稍不注意，頁面就能卡死。

性能問題基本都是cpu不夠用導致的卡頓，這種卡頓可能是1）dom太大，內存爆滿 2）js操作頻繁，js進程繁忙 3）渲染問題，可能是被js阻塞了，也有可能是所在環(huán)境的渲染機制不夠優(yōu)化

在本次為小程序開發(fā)的雙十一會場頁面時，總結出以下經驗

存在的性能問題及解決方案

在開發(fā)中發(fā)現(xiàn)在低端機上幾個小程序端需要注意的事：

  1. dom大了后，bindtap事件會不靈敏，短時間連續(xù)觸發(fā)的bindtap事件后續(xù)的會丟失。原生小程序測試時，3000個dom節(jié)點就有丟失現(xiàn)象。后來嘗試了使用touchstart和touchend去模擬，發(fā)現(xiàn)雖然touchstart很靈敏，但是touchend會丟失（個人猜測小程序的tap事件也是通過touchstart和touchend模擬的）。我們的大促會場600個商品時我算了下大約13000個dom節(jié)點，低端安卓機事件丟的很嚴重，間隔幾乎是秒級別才能觸發(fā)下一次事件。所以解決方案只能減小dom量，添加dom懶加載和動態(tài)移除的邏輯，經過多次測試，比較理想的效果是預加載2屏

2）滾動時setState卡頓嚴重，如果滾動時有觸發(fā)setState操作，那么setState成功可能發(fā)生在幾秒后，即使?jié)L動操作在幾百ms內就結束了。這就導致導航類功能的滾動跟隨效果在安卓機上反應特別慢，滾停到某個商品樓層后，過了1-2s才導航條才突然動一下，所以最終取消了安卓的滾動跟隨效果。（不根據(jù)版本取消效果，是因為發(fā)現(xiàn)即使是安卓較新的7.1版本在性能不好的機器上也會這樣）

3）白屏問題

快速瘋狂滾動頁面，前面的頁面沒渲染出就不停的往后滾，發(fā)現(xiàn)小程序不是優(yōu)先渲染可視區(qū)域，而是一定要把曾經滾過的區(qū)域按順序渲染了。所以如果快速瘋狂滾動，后面的內容白屏等待時間會很久?？紤]到正常用戶不會有這種需求，想看后面的內容可以通過樓層導航過去，而且這個問題我們也找不到解決方案，所以這個現(xiàn)象沒有處理。

注意事項

1）懶加載+動態(tài)移除非可視范圍內的內容，讓dom小下去

2）耗時的js操作異步化，不要阻塞主線程。落地一點說，小程序里不要做頻繁的setState操作，不在state里放跟視圖層無關的內容。譬如我之前為了代碼清晰，把導航功能模塊里的樓層位置信息放到了視圖層也用的一個變量里，其實視圖層并不直接用到這個信息，這個信息為了準確，又會在每次滾動后重新計算，導致頻繁setState，且set的是跟視圖層無關的數(shù)據(jù)，優(yōu)化后，性能提升很明顯。

3）還有跟小程序本身相關的，wx.createSelectorQuery系列接口都是異步的，會受主進程影響，如果主進程繁忙，這個接口返回時間會延遲很久也是s級別的，對于樓層導航和懶加載這種需要頁面各模塊位置信息的功能，不能每次操作都等這個接口返回，可以緩存數(shù)據(jù)，取緩存，然后用戶的操作觸發(fā)調接口更新緩存，在緩存有更新時，為了更準確，也可以主動觸發(fā)下需要位置信息的后續(xù)處理函數(shù)。

4）少用scroll-view，這個組件對性能影響實在太大，單純的只是需要一塊可滾動區(qū)域，請用css+view解決

5）不知道微信的小程序做了什么，滾動操作時進程異常繁忙，滾動停止后很久才是可操作和執(zhí)行js狀態(tài)，所以盡量少的觸發(fā)在滾動時的回調函數(shù)，節(jié)流函數(shù)必須合理用起來。

性能調優(yōu)是個漫長的取舍過程，需要不斷測試來獲取最優(yōu)效果。cpu只有那么多，一段時間只能干那么多事，那就要干效果較好最重要的事。