1、長列表中如果每個item有乙個點贊按鈕，點選後點贊數字+1，此時點讚元件必須是乙個單獨引用的元件，才能做到差量資料更新，否則會造成整個列表資料過載。
2、長列表中每個item並不一定需要做成元件，取決於你的業務中是否需要差量更新某一行item的資料，如沒有此類需求則不應該引入大量元件。（點選item後背景變色，屬於css調整，沒有更新data資料和渲染，不涉及這個問題）
我們看一下這個優化示例的核心思路：
優化前：
//badfor="
(item,index) in list
" :key="
index
" :icon="
item.icon
" :title="
item.title
" :detail="
item.detail
">
下面是優化後的核心內容：
//good
for="
(item,index) in section
" :key="
index
" :begin="
item.begin
" :end="
item.end
">
import mysection
from
'./my-section.vue'//
my-section.vue
for="
(item,index) in list
" :key="
index
" :icon="
item.icon
" :title="
item.title
" :detail="
item.detail
">
created()
說一下其優化思路就是：將本來在乙個元件內的資料，分布在多個元件內，避免乙個元件內的資料量太大導致diff和同步到檢視層耗時太多。
比如乙個元件內的100條資料，變成了10個元件內的10條資料，將變更限制了再10條一組的資料元件內。
頁面初始化時，邏輯層如果一次性向檢視層傳遞很大的資料，使檢視層一次性渲染大量節點，可能造成通訊變慢、頁面切換卡頓，所以建議以區域性更新頁面的方式渲染頁面。如：服務端返回100條資料，可進行分批載入，一次載入50條，500ms 後進行下一次載入。
深層巢狀的節點在頁面初始化構建時往往需要更多的記憶體占用，並且在遍歷節點時也會更慢些，所以建議減少深層的節點巢狀。
有些nvue頁面在android低端機上初次渲染時，會看到從上到下的渲染過程，這往往都是因為元件過多導致的。每個元件渲染時都會觸發一次通訊，太多元件就會阻塞通訊。
1、如果是新頁面進入時背景閃白
"style
":
}
另外nvue頁面不存在此問題，也可以更改為nvue頁面。
2、如果是老頁面消失時背景閃白
優化建議 儲存效能優化。
在 應用中，海量的資料讀寫對磁碟訪問造成巨大壓力，雖然可以通過cache解決一部分資料讀壓力，但是很多時候，磁碟仍然是系統最嚴重的瓶頸。而且磁碟中儲存的資料是 最重要的資產，磁碟的可用性和容錯性也至關重要。機械硬碟是目前最常用的一種硬碟，通過馬達驅動磁頭臂，帶動磁頭到指定的磁碟位置訪問資料，由於每次...
React Native 效能優化建議
react native 雖然一直標榜媲美native的體驗，但實際使用下來，其渲染性還是非常低效，基於scrollview和listview兩大容器，在渲染上，相當於web端的table布局，需要等整個大table渲染完成才顯示頁面，也就是說，當容器內有大量的子元素，其白屏時間會非常長。如何讓re...
Android效能優化建議
android效能優化主要從卡頓 記憶體洩漏和崩潰 質量和邏輯 安裝包過大四方面入手。在使用時避免出現卡頓，響應速度快，減少使用者等待的時間，滿足使用者期望 同時減低 crash 率和 anr 率，不要在使用者使用過程中崩潰和無響應 節省流量和耗電，減少使用者使用成本，避免使用時導致手機發燙 安裝包...