android應用加速最佳化與分析，兼談launcher最佳化。

標籤：

android應用開發使用java語言，java是開發門檻比較低，運行效率比較低，開發人員的素質相差比較大。導致java程式開發容易，最佳化和維護比較困難。個人認為java的核心在於自動化記憶體管理和跨平台，但其詬病也在這一塊，至於效率，隨著硬體的發展，越來越不再是人們考慮的重點。很多人會寫java程式，卻不怎麼會最佳化java程式，遇到記憶體泄露，遇到Null 物件，遇到逾時，遇到機率性的記憶體BUG，常常無從下手。因為能解決這些問題的工具實在太多了，這也說明java的最佳化是個世界性問題，問題的表象可能一個，但實質上引起的原因可能不只一種，需要選擇正確的工具才能找到問題點，用錯了工具還是兩眼抓瞎。不像C語言一個記憶體，一個堆棧調試可以解決大部分的程式問題。

公司有個WOSLauncher的啟動器項目，產品經理認識操作時動畫不流暢，開發的同事搞了一個多月，重構了大量代碼，效果依然不理想。拿到我這裡，最佳化三劍客一開，立刻找到問題點，幾分鐘後，最佳化效果立竿見影。我認為anroid最佳化的三劍客是systrace,traceview,hierarchyviewer,這三個工具可以解決了我工作中所有程式的最佳化。

我無意去對別人的代碼重構，這需要太多的時間，也不想去review項目組同志的所有代碼，這同樣需要花費很多的時間。直接使用工具。

1.首先使用開發人員模式內建的使用GPU過度繪製分析UI效能（開發人員模式，布局最佳化）

硬體加速,開啟 “Show hardware layers updates” 選項。（開發人員模式，變綠未加速）

使用GPU呈現模式圖及FPS考核UI效能研究，發現問題都不是很大

 

2.使用systrace研究，操作後獲得如果結果，圖中的紅點和黃色表明系統確實滑動不夠順滑，

點擊紅點使用M鍵，發現問題大概集中在三個方面，布局measure,CPU delay,view ondraw

 

3.使用hierarchyviewer工具可以最佳化布局，尋找measure,layout,ondraw存在的效能問題，然後開啟後就發現，存在紅點的view都是有效能問題，然後發現布局出在shortcut上，最終定位在google的檔案夾上。他有兩個view,一個ondraw逾時，花費了1.234MS，一個layout逾時，花費了0.597毫秒，這個Google的一個檔案夾，可能需要尋找替代方案

無法貼圖

3cpu的Scheduling delay問題，一般表示CPU比較忙，這個可以通過traceview分析，抓取traceview後分析，得到如下介面

無法貼圖

這個工具可以顯示APP中所有函數的執行時間，一般情況下，我們需要最佳化兩類函數，一是調用次數少，但每次花費時間長的函數，另一是本身花費時間不長，但調用次數非常多，使得本身消耗了大量的時間，最佳化的方法主要是重構code,修改演算法，尋找替代方案

點擊CPU TIME/call列可以使得所有函數每次調用消耗的平均時間按升序或者降序排列，點擊calls+recurcalls/total可以得到函數調用和遞迴調用的總次數和升序或者降序排列，一般可以直接略過非我們APP自訂類的系統的函數，直接研究我們自己包名類名的函數。

然後找到了一個耗時函數createMediumDropShow函數，這個函數使用了特效，開啟了extractAlpha,這是個很消耗時間的功能。createMediumDropShow本身消耗的時候佔了整個周期片斷的百分之三點四之多。嘗試開啟代碼最佳化之。去掉特效或者尋找替代方案後，再觀察。

4.開啟systrace工具觀察最佳化的成果，發現黃點和紅色消失了大半。

5.嘗試把google檔案夾移到固定欄上，不隨動畫重繪再測試，紅色警告全部消失

6.進一步最佳化黃色警告

7.開啟traceview,發現onMeasure成了耗時大戶，進一步使用開發模式裡的GPU過度繪製分析，發現有不太嚴重的過度繪製問題，ICON下的軟體名字字型呈現紅色，這是過度繪製的標誌。慢慢最佳化

8開啟hierarchyviewer工具再次分析，紅色都是有問題的布局，找到這些layout檔案，去掉嵌套，最佳化過於巨大的圖片，androidstudio對於布局，會給很多有用的建議。最佳化後運行之。

android應用加速最佳化與分析，兼談launcher最佳化。