Android lint工具是Android studio中集成的一個代碼提示工具，它主要負責對你的代碼進行優化提示，包括xml和java文件，很強大。編寫完代碼及時進行lint測試，會讓我們的代碼變得非常規范而且避免代碼冗余。讓我們及時發現代碼中隱藏的問題。

lint的使用時非常簡單的，我看可以用它實現代碼布局的優化，Java代碼的優化，不過我覺得根本解決問題還是得依賴于開發者的素質。

例子：我們需要刪除掉一些無用的變量和布局文件等，這對代碼的冗余有很大的幫助。

代碼提示我們在6行需要為ImageView添加ContentDescription屬性，突然感覺好強大。

其實我們還可以用它自定義搜索，主要是刪除一些無用的文件用的。

然后按要求優化下代碼就好了。

TraceView

TraveView是Android studio集成的一個性能優化工具，相信很多人都用過它，之前也專門講過，它主要計算工程內方法運行所占用的時間，調用次數，以此來優化App運行效率。

使用TraceView主要有兩種方式：

1.最簡單的方式就是直接打開DDMS，選擇一個進程，然后按上面的“Start Method Profiling”按鈕，等紅色小點變成黑色以后就表示TraceView已經開始工作了。然后我就可以滑動一下列表（現在手機上的操作肯定會很卡，因為Android系統在檢測Dalvik虛擬機中每個Java方法的調用，這是我猜測的）。操作最好不要超過5s，因為最好是進行小范圍的性能測試。然后再按一下剛才按的按鈕，等一會就會出現上面這幅圖，然后就可以開始分析了。

2.第2種方式就是使用android.os.Debug.startMethodTracing();和android.os.Debug.stopMethodTracing();方法，當運行了這段代碼的時候，就會有一個trace文件在/sdcard目錄中生成，也可以調用startMethodTracing(String traceName) 設置trace文件的文件名，最后你可以使用adb pull /sdcard/test.trace /tmp 命令將trace文件復制到你的電腦中，然后用DDMS工具打開就會出現第一幅圖了

步驟：1.選擇你要調試的進程。 
          2.點擊start mothod profiling，待圖標變黑。 
          3.選擇sample base profiling，等待一會，然后再次點擊這個按鈕停止（開始的時候紅點會變成灰色小方塊，停止的時候再次點擊這個按鈕就               好了）

注意事項：在第三步的時候，需要選擇監聽的屬性。

Trace base profiling

整體監聽，項目中所有方法都會監聽，資源消耗比較大。

sample base profiling

抽樣監聽，以指定的頻率進行抽樣調查，一般不要超過5s，需要較長時間獲取準確的樣本數據。

再次點擊start mothod profiling，就會生成檢測樣本。

整個界面包括上下兩部分，上面是你測試的進程中每個線程的執行情況，每個線程占一行；下面是每個方法執行的各個指標的值。

上面一部分是你測試進程的中每個線程運行的時間線，下圖中可以可以看到，主要只有一個main線程在執行。

下面是分析面板(Profile Panel) - 每一列內容 

Inclusive time - 函數本身運行花費時間 + 函數調用其他函數時間
Exclusive time - 函數本身運行花費時間。
Calls + RecurCall/Total 調用 + 重復調用次數 / 函數總調用次數
Cpu Time/Call 總的Cpu時間與總的調用次數之比

Profile Panel面板有一些參數需要注意下

1. Incl Cpu Time

define inclusive ： 全包括的

上圖中可以看到0（toplevel） 的Incl Cpu Time 占了100%的時間，這個不是說100%的時間都是它在執行，請看下面代碼：

public void top() { a(); b(); c(); d();}

Incl Cpu Time表示方法top執行的總時間，假如說方法top的執行時間為10ms，方法a執行了1ms，方法b執行了2ms，方法c執行了3ms，方法d執行了4ms（這里是為了舉個栗子，實際情況中方法a、b、c、d的執行總時間肯定比方法top的執行總時間要小一點）。

而且調用方法top的方法的執行時間是100ms，那么：

從上面圖中可以看到：

toplevel的 Incl Cpu Time 是1110.943，而io.bxbxbai.android.examples.activity.ExpandableLayoutMainActivity$SimpleAdapter.getItemView方法的Incl Cpu Time為12.859，說明后者的Incl Cpu Time % 約為1.2%

這個指標表示 這個方法以及這個方法的子方法（比如top方法中的a、b、c、d方法）一共執行的時間

2. Excl Cpu Time

理解了Incl Cpu Time以后就可以很好理解Excl Cpu Time了，還是上面top方法的栗子：

方法top 的 Incl Cpu Time 減去 方法a、b、c、d的Incl Cpu Time 的時間就是方法top的Excl Cpu Time 了

3. Incl Real Time

這個感覺和Incl Cpu Time 差不多，第7條會講到。

4. Excl Real Time

同上

5. Calls + Recur Calls / Total

這個指標非常重要！

它表示這個方法執行的次數，這個指標中有兩個值，一個Call表示這個方法調用的次數，Recur Call表示遞歸調用次數，看下圖：

我選中了一個方法，可以看到這個方法的Calls + Recur Calls 值是14 + 0，表示這個方法調用了14次，但是沒有遞歸調用

從Children這一塊來看，很多方法調用都是13的倍數，說明父方法中有一個判斷，但是這不是重點，有些Child方法調用Calls為26，這說明了這些方法被調用了兩遍，是不是可能存在重復調用的情況？這些都是可能可以優化性能的地方。

6. Cpu Time / Call

重點來了！！！！！！！！！！

這個指標應該說是最重要的，從上圖可以看到，133這個方法的調用次數為20次，而它的Incl Cpu Time為12.859ms，那么133方法每一次執行的時間是0.643ms（133這個方法是SimpleAdapter的getItemView方法）

對于一個adapter的getView方法來說0.643ms是非常快的（因為這個adapter中只有一個TextView，我為了測試用的）

如果getView方法執行時間很長，那么必然導致列表滑動的時候產生卡頓現象，可以在getView方法的Children方法列表中找到耗時最長的方法，分析出現問題的原因：

1. 是因為有過多的計算？
2. 還是因為有讀取SD卡的操作？
3. 還是因為adapter中View太復雜了？
4. 還是因為需要有很多判斷，設置View的顯示還是隱藏
5. 還是因為其他原因…

7. Real Time / Call

Real Time 和 Cpu Time 我現在還不太明白它們的區別，我的理解應該是:

1. Cpu Time 應該是某個方法占用CPU的時間
2. Real Time 應該是這個方法的實際運行時間
   
   

感謝閱讀，希望能幫助到大家，謝謝大家對本站的支持！