Android性能優化筆記（持續更新帖）

GPU分析辦法：

先定位問題緣由、後尋找解決辦法、最後驗證多種辦法的解決效果。卡頓問題快速定位的方法：

1. 打開開發者模式中GPU呈現模式分析，查看是那種顏色條高： 

2. 若是是藍色偏高，說明是單位消息裏CPU太耗時，得把方法的執行都打出來看看哪一個耗時。

3. 若是紅色偏高，說明GPU忙不過來。優化過渡繪製，使用離屏緩存來優化。

4. 黃色偏高，說明半透明GPU不只在忙着繪製你的window也還忙着繪製別的，可能的狀況爲透明window疊加多了，window裏的contentView有多個且相對複雜，或者GPU降頻了等等，想具體分析須要查看GPU的trace。

 

圖片列表優化思路：

內存圖片緩存仍是有三級：一級是bitmap列表，一級是LRU強引用，一級是弱引用。加載圖片時，先在弱引用緩存和LRU強引用中查找沒有被釋放的bitmap，若是存在並知足複用條件，則不建立bitmap，而使用該圖片內存，以後將其從弱引用或者LRU中移出放入bitmap列表強引用中。bitmap列表強引用保存了該圖片依賴的直接控件。當view的onDetachedFromWindow被調用則從bitmap列表中移除只有依賴該view的對象到LRU強應用中。若是LRU強引用滿了則放到弱引用中。

 

Service保活思路：

先從老式最基礎的開始：1.使用startService方式啓動一個獨立進程的服務，這樣系統會在service意外死亡後自動重啓。2. 使用RTC定時鬧鐘每5分鐘檢測一下（4.0以上基本無效）3.啓動linux守護進程，每幾分鐘檢測一下進程是否存在，不存在就startService（5.0如下除MIUI和華爲外有效） 4. 5.0以上使用JobScheduler代替鬧鐘定時檢測啓動 5. 啓動隱藏的前臺通知。但這些措施都不能100%保活。

 

關於軟件離屏緩存和硬件離屏緩存

系統默認全部的繪製都在一個內存塊進行，經過canvas的matrix棧來控制繪製每一個View的繪製區域，讓系統再次建立一個內存塊來繪製的方法有View的setLayerType（），能夠在內存或者是GPU上建立一塊內存，先繪製到該內存上，而後繪製到系統的那個內存上。

setLayerType(View.LAYER_TYPE_SOFTWARE, null); 啓動軟件離屏緩存

setLayerType(View.LAYER_TYPE_HARDWARE, null); 啓動硬件離屏緩存（硬件加速）

內存上Bitmap繪製比硬件加速下繪製慢了30倍

因此若是多個bitmap是在一個View的onDraw方法繪製的，那麼只須要在View的構造方法裏添加setLayerType(View.LAYER_TYPE_HARDWARE, null);可大大提高繪製效率。

通常使用離屏緩衝是爲了節省GPU執行錄製的繪製命令的時間，好比你的繪製操做不少，並且執行這些繪製時緩衝是有效的，好比平移整個listView。

若是你看到你的GPU柱狀條中的紅色很高，這時能夠考慮使用硬件離屏緩衝

通常在建立硬件離屏緩衝的時候，建立的那一幀是比較耗時的，因此你的動畫裏有個條線比較高，但能夠規避讓其不影響動畫性能。好比在動畫開始以前開啓離屏緩存。

 

關於軟引用的梗

在android低版本上，SoftwareRefrence是遵循java標準的GC回收流程，即只有觸發GC的狀況爲內存不足時，纔會去檢查SoftReference，但在高版本上，SoftReference被檢查的更頻繁了，即不是隻有內存不足時纔去檢查，其存在的機率與WeakReference接近。