Hybrid App性能優化之路

 

主要從兩個方面講一下首屏數據展現耗時優化和局部滾動長行列表優化

首屏數據展現耗時優化

1.首屏渲染的通常時序能夠用以下的幾個步驟：

首先點擊打開頁面，建立webview，進行頁面的加載，頁面加載完後，發送cdn請求去拉一些js和css的數據。

首先看一下首屏數據渲染，時候不用cgi?

首先想到的一點就是利用緩存。讓cgi第一次拉取的數據是直接從緩存裏讀取出來的，等到加載完後再用實際的數據進行二次渲染；

可是這樣會有兩個問題：問題1–資源加載與cgi請求串行，就是咱們必須等待資源加載完成後，才能發起這個cgi請求；問題2–數據存在二次渲染，由於當新的cgi數據拉取回來了，要從新刷一遍；

因此咱們存在這樣的一個思考?

1.可否讓cgi請求與資源請求並行？

2.可否在第一次渲染時就渲染最新的數據？

咱們能夠思考進一步的優化方案：cgi預拉取方案

在head裏面寫一個jsonp發送cgi請求，這樣就達到了與資源並行的目的；將拉取的數據存在一個對象中，判斷數據是否返回，若是返回的話，就用新的數據進行渲染，若是沒有返回那麼仍是用上面的緩存數據；

然而，在不少狀況下，不少數據並不適合利用緩存的，好比一些頁面打開的很頻繁（一些熱門的帖子，常常打開），或者只看一次就不看了；並且localstorage自己也有大小限制；

那麼咱們還有別的優化方法嗎？

數據共享（工廠數據），提早渲染

好比下面的，兩邊不少數據都是同樣的，好比標題以及其餘的一些詳細信息

把一些公用的數據單獨提出出來，放在緩存中能夠共享，提早渲染；

上面是數據的共享，有時候一些圖片數據也是能夠共享的

如何在右邊大圖尚未請求以前，利用左邊已經緩存的小圖片；右邊能夠先使用小圖的拉伸大圖，先看到模糊的大圖，在看到清晰的大圖；

進行下一步，資源加載

如今都是組件化的開發頁面，可是組件開發在首屏加載中也會有一些問題

組件之間的邏輯耦合，是的加載一些非首屏的組件資源，這樣卻是首屏的js體積過大；

給出的方案是 分離組件，區分環境後加載

最後是打開頁面到穿件webview的優化

在點擊頁面到打開webview之間通常存在必定的延時，尤爲是android的機型，通常有1-2秒的打開時間，這是時候，能夠利用這段時間來儘可能作一些事情。

經過觀察者模式，去訂閱和觸發事件，從而在這段時間內，去拉取首屏的一些數據；

總結上面的幾點

局部滾動長列表優化

通常的滾動長列表能夠分爲兩種：一種是數目條數限定的，就幾十條數據的滾動，另外一種是無限滾動；

最初的實現方案是IScroll來解決；首先是數據有限狀況下時，IScroll仍是能夠的，在鬆手的時候稍微有點卡頓，可是在幾千條數據是，IScroll就卡的不行了。基本滾不動。也能夠經過測試工具來測試兩個頁面的FPS，用IScroll來作，數目有限是上下波動比較大，可是能用；數目上千後，FPS上下波動特別大，隨着列表數目的增長，卡頓現象愈來愈明顯；

IScorll卡頓的緣由是什麼呢？

優化方案一：不用IScroll,替換成div的局部滾動；

可是，在條目比較多時，若是滾動過快，也會出現一些閃白的問題，因此對於列表項較多的列表，不推薦直接使用div局部滾動的方式；

思考？？可否在利用div滾動特性的同時，規避滾動內容的閃白問題

優化方案二：利用div原生滾動內容層

因此採用一個折中的方案，內容層和滾動層分離，只需設置內容層的overflow：auto；

這樣基本能解決問題，可是在小米2等低版本的android手機上，會發現滾動不是平滑的滾動，而是跳躍式的滾動，也就是說，很快滾動到後面，中間的條目很快就滾過去了，這是由於scroll不是實時觸發的，而是結束後在進行樣式變動。

那咱們應該怎麼辦呢？ 

優化方案三：動態的增刪dom

思考？？咱們是否能夠不去滾動如此巨大的dom節點；在可視範圍內的dom，增長，在可視區域外的dom，進行刪除；

這種方式在PC上是沒什麼問題，可是在移動端，就會有layout，重繪重排；

優化方案四：使用canvas繪製列表

將列表繪製到canvas上，這樣整個列表就是一個dom元素；只繪製可視區域的列表項；

可是測試發現，小米手機問題是解決了，可是在三星手機上又有問題

經過canvas繪製列表能夠減小繪製的條目，FPS會有很大的提高，可是由此也證實一些機型，單純的canvas繪製操做上已經達到了性能瓶頸；渲染區域越大，性能越受限，並且canvas繪製的元素不支持無障礙化，不支持被讀屏軟件識別；

優化方案五：滾動依然使用模擬的滾動，滾動過程當中，複用dom

這樣，dom的個數只有可視區域內dom個數，與條目總的數目沒有關係；

測試結果：

總結一些上面的五種優化方案；