客戶端native效能

目前我們效能方面主要關注的點幀率、CPU、記憶體、流量、圖片、響應時間。以下對各點總結了下其標準、檢驗工具、問題排查。

一．     幀率

1.  標準：公司不同有可能不一致（遮蔽）

頁面靜默的時候GPU不應該再繪製（GPU呈現模式分析中沒有圖形變化）

2.  檢驗工具：自己公司開發的

3. 問題排查：

首先開啟手機上“開發者選項裡GPU呈現模式分析”檢視什麼操作下幀率繪製大於16ms，圖形有三種顏色：藍色、橙色、紅色。藍色表示測量繪製的時間；藍色的線很高的時候，有可能是因為你的一堆檢視突然變得無效了(即需要重新繪製)，或者自定義檢視的onDraw函式過於複雜。紅色表示執行時間；

6、動畫或者滑動過程是否觸發Layout動畫和滑動過程中在控制元件呼叫gone或者動態新增刪除重新設定paramsTextView重新設定文字以及重新設定

9、檢視佈局效能問題通過Incl Cpu Time百分比排序列表滑動過程中如果看到onMeasure或者onLayout大於25%以上的就應該可以判斷出當前這個介面的佈局效能不佳需要優化了。在列表滑動過程中也需要檢查getview這樣的函式的效能特別是佈局複雜的初始化時間會比較久。10、檢視佈局複用問題在列表滑動的過程中或者廣告Banner控制元件一般的做法都是應該複用佈局提升效能的但有時候因為覺得麻煩有些可能是動態新增的就沒有複用這些view導致在滑動過程中還是會出現infalte佈局的情況影響效能。跟蹤方法是在這個列表已經滑動過的情況下開始進行TraceView這個時候來回滑動不應該出現infalte如果出現了就是複用出現了問題。如下跟蹤發現有動態inflate button導致每次都額外增加了時間影響效能。還有一種判斷方法就是在進入介面的時候找出LayoutInflater.createViewFromTag函式找出它數量以及parents呼叫方檢查是否有問題。11、判斷佈局巢狀過多或者過於複雜把Call+RecurCalls/Total和CpuTime/Call放到最前面通過View/ViewGroup的draw呼叫次數和遞迴呼叫次數來判斷佈局的層級過多或者佈局Layout太多。也可以通過buildDisplayList函式的呼叫和遞迴呼叫次數來判斷佈局的層級過多或者是Layout太多。

二．  CPU

           1. 標準：CPU<75%，高CPU佔用時間不能太長，具體按實際情況定；靜默CPU<1%。

           2.  檢驗工具：公司開發的，用android studio也可以看

           3. 問題排查：

CPU突增，有可能是網路請求、複雜邏輯處理，具體情況要看這個時候的方法呼叫。高CPU佔用時間長的，有可能方法自己處理佔用時間長了，也有可能呼叫其他方法佔用時間長，也有可能反覆呼叫次數多了。這些具體情況可以用traceview工具檢視（用debug包），在操作時，點選那個紅點開始/結束(一般都是短時間的)，之後看具體情況。

出現的圖分上下兩部分，上面部分可以直接看執行緒的執行時間長短，執行情況，下面是具體分析CPU使用時間和呼叫次數。首先是按照Incl Cpu Time檢視佔用時間長的，和哪些函式佔用多，能找到具體方法。其次看Call+Recur Calls/Total（把Call+Recur Calls/Total和Cpu Time/Call放到最前面按照Call+Recur Calls/Total排序檢視執行次數多的隱患函式展開其子函式分析是否存在問題並通過Incl Cpu Time的CPU佔用比以及Incl Cpu Time的佔用百分比來判斷嚴重性特別是呼叫次數多的且Cpu Time/Call次數也多的應該重點排查。）

三．  記憶體

           1. 標準：。記憶體不能一直往上升：native應該沒什麼變化（c記憶體的分配），dalvik在一個範圍內波動（不能向上波動），不能波動太頻繁（記憶體抖動：記憶體抖動是因為大量的物件被建立又在短時間內馬上被釋放。影響幀率），具體按實際情況定

          2. 檢驗工具： 公司開發的，用android studio也可以看。

         3. 問題排查：

記憶體抖動時一般是頻繁GC，用Allocation Tracker來檢視在短時間內分配的記憶體物件，找到這些元凶。Android Studio中的Memory Monitor也能檢視程式的記憶體使用情況以及檢視GC的情況。灰色部分為free，藍色的為實際佔用的。

記憶體洩露：記憶體增長的情況是存在沒有被回收的情況，那麼大部分是回收時被某個地方引用了，其生命週期更長。或者是無效的引用!

A.在DDMS中， 可以看到堆的大小和實際使用的大小，單一操作進行反覆操作，在GC後，如果堆的大小一直增加，則有記憶體洩漏的隱患。

或者用adbshell dumpsys meminfo檢視dalvik heap會不會持續增長。

B.利用在MAT分析dump hprof檔案。

然後用MAT分析hprof檔案（如果是現存檔案了，不可讀取時，還需要轉換./hprof-conv 原檔案目標檔案）。

首先看overview中有沒有明顯的leak佔用率和problem。

再是用Histogram檢視，針對某個關鍵詞搜尋檢視後按照objects或者retained heap排序後，右鍵list objects 可以檢視被引用（incoming）或者引用。然後對這些引用可以右健Path to GC Roots-->exclue all phantom/weak/soft etc. reference 查出某個例項沒被釋放的原因。用這個方法可以快速找到某個物件的 GC Root，一個存在 GC Root的物件是不會被GC回收掉的。

或者dominator Tree中按照Retained Memory排序，找出比較大的，然後用Path to GC Roots看看其引用情況。在這個Path中，一般會發現我們app自己包的類，可以分析這個類是不是還是需要的。如果不需要，那說明可能存在記憶體洩露。此時，在對這個自己包的類檢視incoming references。看看到底是哪些引用導致它沒有釋放。

更多使用和檢視原因可以網上查詢MAT使用。

四．  流量

          1. 標準：沒有突增大的流量（一次請求頁面突增大於2M時應該排查什麼情況下產生，單個response資料返回最好不要超過50kb），沒有重複請求 ；頁面靜默時或者處於後臺（沒有任何操作）不應該有流量增加了（有的話就要排查下什麼再耗流量了）。這個size的限制主要考慮到非WiFi情況下耗流量和網路網速對資料傳輸的影響。

2.  檢驗工具：公司開發工具，抓包看資料請求，或者log檢視是否有什麼耗流量（比如預設上傳資料，大量圖片下載）

  五．圖片

      1. 標準：網路請求圖片<50kb；

      2. 檢驗工具：直接抓包看下載下來的圖片多大

  六. 響應時間

          1. 標準：activity響應時間<1s(原來的計算方法oncreate到onresume)-2s（從activiy的onCreate到layout的第五幀耗時）第二種方案：

  以Activity onCreate為起點，頁面檢測到檢視繪製5次後結束（通過監聽DecorView PreDraw事件。onCreate是業務執行時間真正開始，在PreDraw 5次後檢視框架基本已經載入完成。測試過程中發現，在第3次PreDraw之前，ActivityManagerDisplayed time已經計算出來，這也是為什麼通過ActivityManager Displayedtime不能反映載入耗時原因，而Activity onCreate 到onResume的時間跟柵欄這兩種方案，都只是ActivityManager Displayedtime過程的一部分

        2. 原始碼中埋點